Bug 322096

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