Bug 157186

Created attachment 23423 [details]
Log from K3b

Created attachment 23424 [details]
Error messages printed to the terminal

Created attachment 23425 [details]
output of strace

having the same problem on 2 machines here, both debian testing/unstable and 2.6.24-kernel (tested with 2.6.24.2 and 2.6.24.3)

i'll attach the k3b log and strace output of one of the machines below.

Created attachment 23785 [details]
k3b-log

Created attachment 23786 [details]
k3b-strace

I believe I reproduced this twice (on 2 burn attempts) with testing/unstable and Linux 2.6.24. The bug reporter reported using Linux 2.6.24 too. I'll try remembering to report whether this persists with 2.6.25.

I confirm the same behaviour on Ubuntu 8.04.
Here's the bug report I filed.
https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/207265

I encounter exactly the same bug under gentoo (see http://bugs.gentoo.org/show_bug.cgi?id=209578).

For Fedora 8 it is tracked as https://bugzilla.redhat.com/440343
(k3b fails to verify written data). I've found that with a kernel
downgrade to 2.6.23.15-137.fc8 k3b verifies fine. With newer kernel
versions it is broken in Fedora 8, 9 and newer.

With the presumably bad kernel, the only difference in k3b debug
output is this after reloading the tray for verification:

(K3bDevice::ScsiCommand) failed: 
                           command:    SET SPEED (bb)
                           errorcode:  70
                           sense key:  NOT READY (2)
                           asc:        3a
                           ascq:       0

Followed by a couple of:

(K3bDevice::ScsiCommand) failed: 
                           command:    READ (10) (28)
                           errorcode:  70
                           sense key:  NOT READY (2)
                           asc:        3a
                           ascq:       0
(K3bDevice::Device) /dev/sr0: READ 10 failed!

Those messages don't appear when running the good kernel.

I'm having the same problem with my Debian lenny installation for ages. 
The interesting thing is problem is happening with my Optiarc AD-7173A drive only. My HP Pavilion DV6100 checksums just fine (which .

I have two AD7173As. One is on my home pc and one is on the office PC. The installation of the office PC is a disk clone of home. My home setup is installed as Lenny beta-1 and surviving since. This installation used 3 different burners and the fails started after I installed the AD-7173A.

In my case, these failures are independent of kernel and hardware that drives the burner (My home PC was upgraded recently and the bug didn't go away).

When I got home, I'll do a test burn and attach the logs here (Currently I don't have blank DVDs here)

Also, this bug is persistent in K3B 1.0.5 testing package in debian

Created attachment 25703 [details]
Debug output of K3B 1.0.5 on debian

I've burned ubuntu 8.04 to a CDRW and verified. As usual it failed. md5sum
command verifies iso is written correctly. Burner is a NEC-AD7173A

Created attachment 25912 [details]
K3B Debug output

Weird. Since I was not happy with my optiarc's (NEC) write quality, swapped it
with a brand new Samsung SH-S203N and it exhibits this bug too. Debugging out
from K3B is attached.

This remains broken for many users.

(In reply to comment #15)
> This remains broken for many users.
> I have developed a patch that solved this problem for me. It does require that you recompile k3b. The patch is for version 1.05. If you are interested in trying the patch I would be glad to forward it to you. Basically I discovered that the failure to verify was coming from a incorrectly calculated checksum for the written data.  The md5sum on the copy was actually correct but it would indicate a failure because the written checksum did not match the one from the copy.  

Jim, why not attach your patch here?

Although, the same k3b works with old kernels (and old Linux distributions), and there are theories that the checksum is only miscalculated with newer kernels because after ejecting and reloading the tray [with problems for some users] k3b reads wrong data.

Created attachment 28197 [details]
Patch for k3b version 1.0.5 md5sum errors on iso files with late kernels

I'm sceptical for several reasons (and being a user where verification currently only fails for DVDs not CDs or CD-RWs):


1) You modify the K3bChecksumPipe class without updating

  libk3b/projects/datacd/k3bisoimager.cpp
  libk3b/jobs/k3bdvdcopyjob.cpp

which also use it. With your patch, the code in there would need to reset the MD5 digest manually now, too.


2) Your changes to k3biso9660imagewritingjob.cpp:

   d->checksumPipe.close();
+// added to reset checksum pipe before starting cksum accum
+  d->checksumPipe.extreset();
   d->checksumPipe.readFromIODevice( &d->imageFile );

You here added a public method to reset the MD5 digest manually. Is that necessary? Or does this only hide a different bug? A few lines below the original code would perform the reset after preparing the disc writer:

    d->checksumPipe.open( K3bChecksumPipe::MD5, true );

This method is supposed to reset the digst. Instead, you disabled it to not call reset() in favour of doing it manually via extreset(). Where's the difference? In side-effects elsewhere? What am I missing?


3) Your change to k3bverificationjob.cpp:

+   // display the two sums
+        emit infoMessage( i18n("Written source checksum = %1 ").arg(d->tracks[d->currentTrackIndex].checksum), INFO);
+        emit infoMessage( i18n("ReadBack of copy checksum = %1 ").arg(d->md5Job->hexDigest()), INFO);
+

This is only added debug output. Useful, however. What would be interesting to add is to also print the source checksum of the ISO file on hard-disk.

d->md5Job is a K3bMd5Job object which calculates the MD5 digest from the on-disc data. It isn't based on K3bChecksumPipe and is unrelated. Noticing how many users get "No tracks to verify found" with recent kernels instead of a verification error, I rather believe the unsuccessful verification is related to the trackindex (and preparing for disc read) instead of calculating a wrong checksum for the source data while burning.

*** This bug has been confirmed by popular vote. ***

can someone please test with K3b 1.65.0?

I can confirm. Debugging output in attachment

Created attachment 35001 [details]
k3b 1.66.0 log (debugging output)

*** Bug 157332 has been marked as a duplicate of this bug. ***

In an attempt to clean up old bugs that are not valid for K3b 2.0 (=KDE SC 4.x port) anymore, this is now being marked as UNMAINTAINED.
If this bug is still valid for 2.0, please reopen it.