| Summary: | K3B has issue verifying burn | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kris <krisgamrat> |
| Component: | non-core programs | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bugwatch, darrella, krisgamrat |
| Priority: | P5 | ||
| Version: | 3.5.13.x [Trinity] | ||
| Hardware: | amd64 | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Kris
2011-09-26 10:58:29 CDT
This bug exists in GIT (2013-05-22) in Slackware 14.0. I tried burning a 2.8 GB data DVD. The burn is successful but not the verification. When enabling "Verify written data," the tray ejects automatically at the (Overall progress) 50% progress marker, but after the tray closes the verification process halts immediately with an Error and the tray reopens. Text in stdout/stderr that might be related: (K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed. I see that message three times. Another possible error message: TQGDict::hashKeyString: Invalid null key That the process halts immediately after the tray closes is peculiar. By "immediate" I am implying the operating system does not yet have time to read the disk, let alone Trinity/K3B. Conversely, I had no problem verifying a full CD ISO image. I noticed in the intermittent dialog that appears while the system and K3B reinitialize after ejecting/closing the tray, that some of the characters did not display correctly. Some kind of UTF problem? (In reply to comment #1) > This bug exists in GIT (2013-05-22) in Slackware 14.0. > > I tried burning a 2.8 GB data DVD. The burn is successful but not the > verification. > > When enabling "Verify written data," the tray ejects automatically at the > (Overall progress) 50% progress marker, but after the tray closes the > verification process halts immediately with an Error and the tray reopens. > > Text in stdout/stderr that might be related: > > (K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed. I see that > message three times. > > Another possible error message: > > TQGDict::hashKeyString: Invalid null key > > That the process halts immediately after the tray closes is peculiar. By > "immediate" I am implying the operating system does not yet have time to read > the disk, let alone Trinity/K3B. > > Conversely, I had no problem verifying a full CD ISO image. I noticed in the > intermittent dialog that appears while the system and K3B reinitialize after > ejecting/closing the tray, that some of the characters did not display > correctly. Some kind of UTF problem? Minus having incorrect characters in the dialog, I too have no issues with CDs, only with the DVDs. This tests true on both 3.5.13-sru and R14. I will check for those error messages next time I burn DVDs. I think I found the problem with the goofy characters in the dialog. I'm searching through the commits to see whether there was a reason for the changes. Goofy characters fixed in commit e8fb3858. (In reply to comment #2) > (In reply to comment #1) > > This bug exists in GIT (2013-05-22) in Slackware 14.0. > > > > I tried burning a 2.8 GB data DVD. The burn is successful but not the > > verification. <snip> An added note: from personal testing, it doesn't seem to matter the distro (I've tested in Debian Squeeze & Wheezy and Arch), nor the size of the DVD. I have had this happen on a 4.4GB DVD. Hopefully a clue that the verification fails the instant the tray closes. I'll guess the problem is k3b tries to start verifying the instant the tray closes rather than wait for the system to reinitialize and that causes the failure. Odd the same behavior does not occur with a CD. With a CD the dialog appears requesting a disk but the dialog disappears automatically after the system and k3b reinitialize. (In reply to comment #6) > Hopefully a clue that the verification fails the instant the tray closes. I'll <snip> For me, it fails *before* I can close the tray, on two separate laptops (neither one has a motorized tray). This would suggest (at least to me) that the failure occurs when the eject signal is sent to the drive, not when it closes. I found a work-around: In Settings->Configure K3b->Advanced, Enable/check "Do not eject medium after write process." There remains a bug when the user ejects the disk after the burn because k3b is not waiting correctly for the system to reinitialize. I wish I knew C++ better, but looks like the code for waiting is in /libk3b/jobs/k3biso9660imagewritingjob.cpp:268. |