My system is probably experiencing a buffer underrun. (Evidence: the repeatable error can be avoided by using an intermediate image file.) Yet K3b reports this as a bogus permissions problem. In systems I've used (Ubuntu, Fedora), wodim issues this warning very early: /usr/bin/wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits. I wonder if this is why, when a later wodim failure occurs, K3b reports: cdrecord has no permission to open the device. You may use K3bsetup to solve this problem. In any case, wodim (AKA cdrecord) certainly does have permission to open the device. In the middle of the "Debugging Output", 3823 lines into 7720, there is a cryptic error report from wodim: Track 01: 3745 of 4351 MB written (fifo 100%) [buf 99%] 6.3x. Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 00 1D 42 DC 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 72 0B 00 00 00 00 00 0E 09 0C 00 00 00 02 00 00 Sense Key: 0x0 No Additional Sense, Segment 11 Sense Code: 0x00 Qual 0x02 (end-of-partition/medium detected) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 229.558s timeout 200s /usr/bin/wodim: A write error occured. /usr/bin/wodim: Please properly read the error message above. This last line is kind of funny. Clearly K3b isn't properly reading the error message properly. But then again, I don't know how to either. I'm pretty sure is represents a buffer underrun but I cannot see how. It looks to me as if there are many bug reports that, at their heart, are Errno 5 conditions from wodim, part way into a burn, that are not clearly diagnosed. Here are a few: https://bugs.kde.org/show_bug.cgi?id=273603 https://bugs.kde.org/show_bug.cgi?id=259360 https://bugs.kde.org/show_bug.cgi?id=237439 https://bugs.kde.org/show_bug.cgi?id=287034 https://bugs.kde.org/show_bug.cgi?id=314519 Reproducible: Sometimes Steps to Reproduce: 1. several, but not all, "projects" fail on my system 2. hit the burn button, without ticking "create image" 3. wait about 15 minutes for the burn to fail Actual Results: A badly reported failure, as described under "Details" Expected Results: burn works OR a clear and accurate diagnostic is produced. The computer is an older notebook with Optiarc DVD RW AD-7530A EX31 drive (but the problem could be reproduced with an external USB DVD burner). The source of the data for on-the-fly burning was an external USB 2.0 hard drive, formatted with NTFS. It is quite possible that this source could cause hiccups in the data delivery latency. Once "create image" was ticked, each the failures we experienced went away. It surprised me that the failures were repeatable since I would have expected some nondeterminacy. The debugging information says: Driveropts: 'burnfree' I would have expected this to recover from any buffer overrun. How can I tell if my drives actually have the corresponding feature? Why would it not work? See http://pastebin.ca/2418313 for a mildly edited version of the debugging output from one run. I had to delete a lot of repetitive lines to fit within the pastebin.ca size limit. More details and discussion here: http://forum.kde.org/viewtopic.php?f=153&t=108537
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
This problem only occurred on an old slow notebook. A decade later I don't have it or any similar computer. So I won't try to duplicate the problem. Since nobody else has reported it, I guess it wasn't important.