Bug 440343 - k3b fails to verify written data: "No tracks to verify found"
k3b fails to verify written data: "No tracks to verify found"
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: k3b (Show other bugs)
11
All Linux
low Severity low
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
: Reopened
: 430656 446340 (view as bug list)
Depends On:
Blocks: 444344
  Show dependency treegraph
 
Reported: 2008-04-02 19:04 EDT by Michael Schwendt
Modified: 2014-01-12 19:07 EST (History)
25 users (show)

See Also:
Fixed In Version: 1.0.5-9.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-01 09:12:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
k3b output into a terminal when run from command line (16.90 KB, text/plain)
2008-07-23 03:49 EDT, Tero Nieminen
no flags Details
another output from k3b with "no tracks to verify" (no HAL erros this time) (7.69 KB, text/plain)
2008-07-23 08:50 EDT, Tero Nieminen
no flags Details
strace output from k3b as mentioned in comment #54 (292.25 KB, text/plain)
2008-11-01 17:12 EDT, Tom Horsley
no flags Details
debug output from k3b as mentioned in comment #54 (2.84 KB, text/plain)
2008-11-01 17:13 EDT, Tom Horsley
no flags Details
strace output - Comment #75 (3.42 KB, text/plain)
2009-06-26 00:07 EDT, Robin Laing
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 157186 None None None Never

  None (edit)
Description Michael Schwendt 2008-04-02 19:04:33 EDT
After one of the F8 kernel updates, k3b fails to verify
written data, such as ISO images. I stumbled into this while burning
F9-Beta disc1.

  kernel 2.6.24.3-50.fc8 : k3b FAILS

  kernel 2.6.23.15-137.fc8 : k3b SUCCEEDS

With the older kernel it is not reproducible.

When I posted about it,
https://www.redhat.com/archives/fedora-list/2008-April/msg00237.html
I pointed out that "readcd dev=/dev/sr0" can read out the ISO image
fine with both kernels. But k3b fails.
Comment 1 Brad 2008-04-02 20:08:50 EDT
I have seen the exact same behavior with all the .24 kernels(up to
2.6.24.4-64.fc8 so far). I can burn the exact same iso on the same disk (rw)
with .23 without issue. I am on 64bit F8.
Comment 2 Rex Dieter 2008-04-03 08:00:03 EDT
*** Bug 430656 has been marked as a duplicate of this bug. ***
Comment 3 Michael Schwendt 2008-04-04 11:35:27 EDT
With F9-Beta the "verify written data" step fails earlier,
directly after automatically ejecting+reloading the tray:
"No tracks to verify found."

$ uname -r
2.6.25-0.121.rc5.git4.fc9

Needless to say, the burnt CD is fine (and readcd can confirm
that without problems).
Comment 4 Michael Schwendt 2008-04-05 07:24:00 EDT
Another test, since I just had to burn a CD-RW:

  kernel-2.6.23.15-137.fc8 : SUCCESS

  kernel-2.6.24.4-64.fc8 : FAILURE

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!

They don't appear in the good-kernel-k3b-output.
Comment 5 Sebastian Vahl 2008-04-06 11:14:22 EDT
I was only able to do a short test, because I've had problems to install a
2.6.23 on my normal machine. And I only had access to this test machine this sunday.

Test was done with k3b-1.0.4-5.fc8 on i386. Media was Fedora-8-i386-rescuecd.iso
and a CD-RW.

Kernel: 2.6.24.3-34.fc8
k3b: verify failed
SHA1SUM: ok

2.6.24.4-64.fc8
k3b: verify failed
SHA1SUM: ok

Kernel: 2.6.23.15-137.fc8
k3b: verify succeeded
SHA1SUM: ok
Comment 6 Sebastian Vahl 2008-04-06 11:15:46 EDT
Oh, sorry. This was intended to be a answer to
https://bugzilla.redhat.com/show_bug.cgi?id=430656#c6
Comment 7 Michael Schwendt 2008-04-18 16:15:49 EDT
Rawhide/F9 still affected, too (as in comment 3):

kernel-2.6.25-0.234.rc9.git1.fc9.i686
k3b: No tracks to verify found.
Comment 8 Tom Horsley 2008-04-27 16:59:13 EDT
Looks like bug 444344 may be a duplicate of this.
Comment 9 Robin 2008-04-30 15:27:48 EDT
I just had the same issue.  First time I tried to burn to a DVD since getting
this computer.  After burning the downloaded ISO image using k3b, the verify
failed.  I checked the checksum using 
    
    sha1sum /dev/sr0

was different than the source sha1sum.

I burned the ISO image using 

   wodim -v dev=/dev/cdrom driveropts=burnfree CAELinux2008.iso

and then ejected and reloaded media and finally confirmed the sha1sum.


[rlaing@eagle1 TEST]$ sha1sum /dev/sr0
b207d27d9803487e332ad5f372a22e74dd14cc6f  /dev/sr0

[rlaing@eagle1 TEST]$ sha1sum CAELinux2008.iso
b207d27d9803487e332ad5f372a22e74dd14cc6f  CAELinux2008.iso



kernel-2.6.24.4-64.fc8
k3b-1.0.4-5.fc8

Hope this gets fixed soon.

I couldn't find anything in the log files.

Two DVD-R and one DVD-RW failed with k3b.  No issues using wodim.

No messages in k3b's lastlog.log file.


Comment 10 Andre Robatino 2008-04-30 20:39:43 EDT
"sha1sum /dev/sr0" is not reliable, though it might by luck work on some
hardware.  To check reliably, you need to know the exact size of the ISO, which
you can do using the isoinfo command, then read off that exact size using dd. 
The rawread script from

http://www.troubleshooters.com/linux/coasterless.htm

does this automatically, it's just an 18-line Bourne shell script.  (I tried
using readcd to do the same thing but couldn't figure out the proper usage.)  To
be sure that wasn't why the original DVD failed to verify, try that instead.
Comment 11 Michael Schwendt 2008-05-01 05:59:46 EDT
readcd dev=/dev/scd0  then '11' and RETURN several times
as all defaults are appropriate.
Comment 12 Andre Robatino 2008-05-01 06:18:22 EDT
Doesn't work.  For the Fedora 8 i386 DVD, it returns a file of 3424911360 bytes
instead of the correct size of 3424749568 bytes for Fedora-8-i386-DVD.iso, which
rawread handles properly.  The two files match up to the size of the smaller
one, but sha1sum won't work properly with the extra padding.  This is the same
problem I had earlier, which caused me not to use readcd.  Is there another way
to get readcd to get the exact-size file without the padding?  If not, maybe
this should be reported as a bug or RFE against wodim (the package that readcd
belongs to).
Comment 13 Michael Schwendt 2008-05-01 06:56:44 EDT
I refer to the working _old_ kernel at the top of this ticket. Here:

| Enter selection: 0 (0 - 20)/<cr>:11
| Capacity: 1672241 Blocks = 3344482 kBytes = 3266 MBytes = 3424 prMB
| Sectorsize: 2048 Bytes

which is 3424749568 with F8 i386 DVD. The size you refer to
is 79 sectors more than that. Strange.

Anyway, bugzilla is inappropriate for long discussions. Let's not
flood this bug report with too many comments. Problems related to
padding instead of DAO/SAO-mode writing are not interesting either.
Something in the 2.6.24* kernels breaks k3b image verification.
Comment 14 Landon Kelsey 2008-05-15 13:43:31 EDT
I downloaded K9 at a time when 1000000000 other people were doing the same.

The sha1sum test passed.

I burned 4 copies with K3B.

Burning an ISO image with verification fails

prob because the image does not compare to "files"

However, using kdiff3, I verified that all 4 copies are identical.

Thank heavens for kdiff3!!!

k3b also failed to copy a single track from

JS Bach's St Matthew's Passion! I forced it to work and the CD does

not work in any device except the computer!
Comment 15 Brad 2008-05-15 19:00:21 EDT
2.6.24.7-92.fc8 still has the problem.
Comment 16 Brad 2008-06-07 13:27:58 EDT
2.6.25.4-10.fc8 seems to have a new variant on the issue. When the drive opens
after the write (but before it starts to verify), it spits out an error unable
to access drive.
Comment 17 Phil Smith 2008-06-10 18:16:23 EDT
I get the same in Fedora 9 i386 with ordinary PC and LiteOn DH20A3P.
Verify fails with "No tracks to verify found." before even trying.
k3b-1.0.4-6.fc9.i386
kernel-2.6.25.4-30.fc9.i686

Same again on another machine running Fedora 9 x86_64.

Also Settings->Advanced->Do not eject has no effect: it still ejects.
Comment 18 Marc 2008-06-12 05:35:53 EDT
Since the recent KDE updates (yesterday), K3b on F9 won't burn anything now, as
well as the "No tracks to verify found" problem.  It keeps coming up with  write
error message, and ejects the medium.
Comment 19 Marc 2008-06-19 04:13:20 EDT
(In reply to comment #18)
> Since the recent KDE updates (yesterday), K3b on F9 won't burn anything now, as
> well as the "No tracks to verify found" problem.  It keeps coming up with  write
> error message, and ejects the medium.

Further testing revealed that F9 doesn't work with my Optiarc DVD writer.  I
know the device works because I tested it on another system just in case.  I
installed an old CD burner that I know is working, instead of the Optiarc, and
K3b now works again.  The Optiarc kept producing 'write error' and
'input/output' errors.
Comment 20 Steven M. Parrish 2008-06-23 15:33:30 EDT
*** Bug 444344 has been marked as a duplicate of this bug. ***
Comment 21 Steven M. Parrish 2008-06-23 15:34:46 EDT
*** Bug 446340 has been marked as a duplicate of this bug. ***
Comment 22 Brad 2008-06-23 17:01:09 EDT
Kernel-2.6.25.6-27.f8 is now down to No Tracks found. Disks are of course just
fine. This has become a real PITA. I HAVE to verify the disks I burn. This means
that I am still running 2.6.23.15-137.fc8. If you need us to provide some more
information or to try something then just ask.
Comment 23 Brad 2008-06-23 17:03:09 EDT
Michael Schwendt

Can you bump the severity of this up, please? It will not allow me to do so as
you are the starter of the bug.
Comment 24 Michael Schwendt 2008-06-24 08:54:48 EDT
Bug was set to ASSIGNED by John Poelstra on 2008-04-21.
Perhaps John has news for us or any questions?

[somebody closed bug 444344 (k3b) as duplicate, so I re-added the
external KDE ticket here]

[severity is ignored by many unless set by maintainers themselves]
Comment 25 John Poelstra 2008-06-24 13:40:39 EDT
Once triaged a bug moves to ASSIGNED.
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Comment 26 Rex Dieter 2008-06-25 15:15:09 EDT
Michael Schwendt pointed out:
"k3b 1.0.5 changelog says: 
* Always wait for the drive to become ready before starting verification."

I'm spinning some k3b-1.0.5 builds so people can test:

F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=53847
F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=53848

feedback appreciated.
Comment 27 Brad 2008-06-25 15:41:17 EDT
Still same error here on:

Installed Packages
Name   : k3b
Arch   : x86_64
Version: 1.0.5
Release: 2.fc8
Size   : 27 M
Repo   : installed


[fred@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.25.6-27.fc8 #1 SMP Fri Jun 13 16:17:54 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux


Thanks for trying


Comment 28 Michael Schwendt 2008-06-25 16:25:54 EDT
Progress here:

2x success with CD-RW
  Fedora 8 i686
  k3b-1.0.5-2.fc8
  kernel-2.6.25.6-27.fc8

With k3b-1.0.4-5.fc8 as double-check, "No tracks to verify found."

k3b 1.0.5 is very nervous when reloading the disc. It immediately
opens a dialog "No medium present". I let it auto-close itself
each time.
Comment 29 cornel panceac 2008-06-25 17:03:12 EDT
there are many reports on the web suggesting the problem is (or was) wodim.

google "k3b fail to verify cd wodim"

btw, it's happening on f9 too.

$ rpm -q wodim
wodim-1.1.6-11.fc9.i386

while on homepage

http://www.cdrkit.org/

"2008/03/17
Cdrkit 1.1.7.1 has been released."

Comment 30 Brad 2008-06-25 17:08:02 EDT
If wodim is to blame why would the same version work fine with the .23 kernel
(just boot to different kernel no other change)?
Comment 31 Michael Schwendt 2008-06-25 17:56:45 EDT
Re: comment 29

There is cdrkit 1.1.8 already from end of May. It's included
in Fedora Development.

That Fedora 9 is affected has been mentioned early on in this
ticket.
Comment 32 Michael Schwendt 2008-06-29 10:57:05 EDT
New comments at http://bugs.kde.org/show_bug.cgi?id=157186#c12
say that this bug is still reproducible in k3b 1.0.5 with Debian.
Comment 33 Phil Smith 2008-06-30 10:07:36 EDT
(In reply to comment #26)
> Michael Schwendt pointed out:
> "k3b 1.0.5 changelog says: 
> * Always wait for the drive to become ready before starting verification."
> 
> I'm spinning some k3b-1.0.5 builds so people can test:
> 
> F-8: http://koji.fedoraproject.org/koji/buildinfo?buildID=53847
> F-9: http://koji.fedoraproject.org/koji/buildinfo?buildID=53848
> 
> feedback appreciated.

Success: disc load window popped up and automatically disappeared.
F9 with kernel 2.6.25.6-55.fc9.x86_64, k3b-1.0.5-2.fc9.x86_64
Old k3b-1.0.4-6 failed with no tracks to verify in a test just minutes before
installing the new rpm.
Comment 34 Marc 2008-07-01 04:00:33 EDT
Still fails to verify data with the error message "No tracks to verify found" on
the K3b F9 respin F-9:
http://koji.fedoraproject.org/koji/buildinfo?buildID=53848
(k3b-1.0.5-2.fc9.i386.rpm).  Data burns successfully, and CD drawer opens after
burn, but closes ready for verify and immediately on the drawer closing, the
error message comes up, as before.  On checking the data on the DVD manually,
all data have burned successfully to the DVD (DVD+RW).

System: F9 on an i686, Pentium 4 1800, LG DVD burner, 750MB memory,
kernel-2.6.25.6-55.fc9.i686.rpm

All the latest F9 package updates applied as of 30/06/2008
Comment 35 Brad 2008-07-01 04:12:33 EDT
I am also using an LG burner. How about you Michael Schwendt and others?
Comment 36 Michael Schwendt 2008-07-01 06:10:58 EDT
LG (GSA-H10N)
Comment 37 Phil Smith 2008-07-01 07:06:18 EDT
LiteOn 20A3P has this problem (can't test k3b-1.0.5-2.fc9.x86_64 fix yet)
and yet my NEC ND-4570A on an identical machine/OS has no problem at all.
LiteOn LH-20A1P has this problem and is fixed by k3b-1.0.5-2.fc9.x86_64.
Comment 38 Marc 2008-07-02 03:56:49 EDT
I don't know if anyone else has tested it, but I tried the package
k3b-1.0.5-3.fc9.i386.rpm, which was on the F9 testing repository last evening,
and it seems to fix the verify problem in F9. 

It pops up an extra window telling me to load the disk that has just been
burned, but it automatically loads it after a second or two, then successfully
verifies the data.
Comment 39 Brad 2008-07-02 14:40:44 EDT
1.0.5-3.fc6.64bit still fails here. I get the popup window, it automatically
reloads the disk, and then it fails "No track found to verify".
Comment 40 Brad 2008-07-03 14:07:30 EDT
linux localhost.localdomain 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:05:49 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux

New kernel did not help either. Same error but did not see popup this time.
Comment 41 Brad 2008-07-11 14:27:56 EDT
1.0.5-4.fc8.64bit still fails here. No tracks to verify.

Post #39 should have been FC8 too.
Comment 42 mattg 2008-07-15 07:39:44 EDT
Fedora 8 / k3b-1.0.5-3.fc8 / kernel-2.6.25.9-40.fc8

It is still happening to me, as well -- most of the time.  Roughly 75% of my
DVD-R burns, the burn will complete, k3b will eject & reload the disc, and then
spit out the "No tracks found to verify" message.  But 25% of the burns will
successfully recognize the burned disc and successfully verify it.

What I have noticed lately, in general, is that it is taking longer for the
system to recognize & mount DVD media after the tray is closed.  This has
affected not only k3b for me, but also some shell scripts I'd written years ago
to mount & read from DVD-R.  In my scripts, I had to add a 10-second sleep
between "eject -t" and "mount" to allow the disc to be recognized.

Maybe this is affecting k3b too.  Perhaps a configurable delay could be added to
the verifications process to allow k3b more time to see the disc after reclosing
the tray?   Just a thought.

My drive is a "LITE-ON  DVDRW LH-20A1P   KL05"
Comment 43 Brad 2008-07-17 14:50:09 EDT
 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:31:41 EDT 2008 x86_64 x86_64 x86_64
GNU/Linux and 1.0.5-4 still gives the No tracks to verify.
Comment 44 Tero Nieminen 2008-07-23 03:49:09 EDT
Created attachment 312432 [details]
k3b output into a terminal when run from command line
Comment 45 Tero Nieminen 2008-07-23 03:54:15 EDT
Hopefully the above attachemnt gives more insight into what goes wrong with k3b
burn/verify. I just happened to run k3b from command line and got he output just
attached (there would appear to be problems with HAL with k3b).

Additional info:

---
[ttn@mad112g ~]$ uname -a
Linux mad112g.cc.jyu.fi 2.6.25.9-40.fc8 #1 SMP Fri Jun 27 16:25:53 EDT 2008 i686
i686 i386 GNU/Linux
[ttn@mad112g ~]$ 
[ttn@mad112g ~]$ rpm -qa|grep k3b
k3b-extras-nonfree-1.0.3-1.lvn8
k3b-1.0.5-3.fc8
[ttn@mad112g ~]$ 
---
Comment 46 Tero Nieminen 2008-07-23 08:50:20 EDT
Created attachment 312475 [details]
another output from k3b with "no tracks to verify" (no HAL erros this time)

The HAL problem seemed to go away with a reboot (kernel appears to have been
updated since last reboot:). No tracks to verify in k3b still persists though.
Here's another output from terminal of k3b failing to find any tracks to
verify.

Version details below:

---
[ttn@mad112g ~]$ uname -a
Linux mad112g.cc.jyu.fi 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:39:51 EDT 2008
i686 i686 i386 GNU/Linux
[ttn@mad112g ~]$ rpm -qa|grep k3b
k3b-extras-nonfree-1.0.3-1.lvn8
k3b-1.0.5-3.fc8
[ttn@mad112g ~]$ 
---

PS. The burnt DVD still automounts and would appear to be ok.
Comment 47 Brad 2008-07-27 17:36:27 EDT
Linux localhost.localdomain 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 01:40:51 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux

k3b-1.0.5-4.fc8

No tracks found to verify.
Comment 48 Brad 2008-08-14 03:05:55 EDT
Linux localhost.localdomain 2.6.25.14-69.fc8 #1 SMP Mon Aug 4 14:00:45 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux


Still the same, no tracks to verify found.

If you guys need any more information just ask.
Comment 49 Michael Schwendt 2008-08-31 16:16:29 EDT
$ rpm -q kernel
kernel-2.6.26.3-12.fc8

"No tracks to verify found" has returned.
Comment 50 Brad 2008-09-13 13:27:26 EDT
Linux localhost.localdomain 2.6.26.3-14.fc8 #1 SMP Wed Sep 3 03:17:52 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

"No tracks to verify found".
Comment 51 Brad 2008-10-02 11:47:58 EDT
Name       : kernel
Arch       : x86_64
Version    : 2.6.26.5
Release    : 28.fc8

"No tracks to verify found".
Comment 52 Tero Nieminen 2008-10-21 07:30:56 EDT
(In reply to comment #46)
> Created an attachment (id=312475) [details]
> another output from k3b with "no tracks to verify" (no HAL erros this time)
> 
> The HAL problem seemed to go away with a reboot (kernel appears to have been
> updated since last reboot:). No tracks to verify in k3b still persists though.
> Here's another output from terminal of k3b failing to find any tracks to
> verify.
> 
> Version details below:
> 
> ---
> [ttn@mad112g ~]$ uname -a
> Linux mad112g.cc.jyu.fi 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:39:51 EDT 2008
> i686 i686 i386 GNU/Linux
> [ttn@mad112g ~]$ rpm -qa|grep k3b
> k3b-extras-nonfree-1.0.3-1.lvn8
> k3b-1.0.5-3.fc8
> [ttn@mad112g ~]$ 
> ---
> 
> PS. The burnt DVD still automounts and would appear to be ok.
> 

It seems (for me at least) that the verify problem only occurs with DVDs - CDs burn and verify ok with k3b.

T:Tero
Comment 53 Tom Horsley 2008-10-26 16:06:00 EDT
I had accumulated enough data to fill a backup DVD, so I decided to try
my F10 beta rawhide system with k3b to see how things work with latest
kernel.

It wrote all the data, ejected the disk, then the disk stayed ejected.
I tried pushing the try back in manually, but k3b was completely hosed
at 100% cpu, pushing the tray back in didn't do anything to help. I had
to kill -9 the k3b process.

This is a 64 bit system, the kernel and k3b installed are:

kernel-2.6.27.4-47.rc3.fc10.x86_64
k3b-1.0.5-6.fc10.x86_64

By the way, eject -T can correctly both eject and reload the dvd
drive on this system, so I'm not sure why k3b wasn't able to reload the
disk.

I just finished a comparison of checksums, and in addition to the
problem with doing the verify, I get an I/O error when I try to read
one of the files from the DVD (all the others read OK and match the
checksums). This was a dual layer DVD-R, possibly the file with the
I/O error crosses layers? (Not sure how to tell the physical layout).
Comment 54 Tom Horsley 2008-11-01 17:11:20 EDT
Tried another dual layer writing experiment again, this time on 32 bit
fedora 10 beta: kernel-2.6.27.4-68.fc10.i686, k3b-1.0.5-6.fc10.i386.

Once again it wrote all the data, ejected the tray, then never reloaded
the tray in order to do the verify. Pushing the tray back in manually
didn't help, mounting the media manually didn't help, it just never
started the verify operation.

Unlike the previous experiment, it didn't go into an infinite CPU loop.
The GUI remained responsive to things like the cancel button, but it
just never started the verify.

Also the write was completely successful this time. A manual comparison
of the sha1sum for all the files on the DVD and the originals from the
had disk shows a perfect match, so that is better than the previous
experiment. (Don't know if this was media related, I was using 8x
DVD+R DL this time instead of DVD-R DL).

I'll attach an strace of a few seconds of it sitting around not doing the
verify in case that can tell anyone anything, and also the debug output
from k3b saved after cancelling the verify operation.
Comment 55 Tom Horsley 2008-11-01 17:12:57 EDT
Created attachment 322185 [details]
strace output from k3b as mentioned in comment #54
Comment 56 Tom Horsley 2008-11-01 17:13:58 EDT
Created attachment 322186 [details]
debug output from k3b as mentioned in comment #54
Comment 57 Bug Zapper 2008-11-26 05:22:02 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 58 Rex Dieter 2008-11-26 08:44:51 EST
reassigning -> rawhide, still hearing reports of this on fedora-test list.
Comment 59 Juhani Jaakola 2008-12-09 11:16:53 EST
I upgraded from Fedora 7 to Fedora 9 and K3B verify does not work any more!

If I burn a DVD, the disc is ejected and is never reloaded, so verify fails. If I verify the files manually afterwards they are all OK.

Then I checked option "Do not eject medium after write process" and then I burned the F10 CD image. I got error "No tracks to verify found". Afterwards command "cmp /dev/cdrom F10-i686-Live.iso" does not find any differences.

Command "eject -T" is able to eject and reload the disc.

My system is fully updated but I'm using kernel 2.6.25-14.fc9.i686 because the newer kernels break my rt2500pci network and bluetooth browsing... This is my third major bug with Fedora 9!

$ uname -a
Linux tik.jsoft.fi 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT 2008 i686 athlon i386 GNU/Linux
$ rpm -qa | grep k3b
k3b-1.0.5-3.fc9.i386
k3b-extras-freeworld-1.0.5-4.fc9.i386
$ rpm -q hal
hal-0.5.11-2.fc9.i386
Comment 60 Rex Dieter 2008-12-09 11:37:57 EST
For those of you reporting failure to verify/reload, if you haven't done so already, please provide the make/model of your burner.
Comment 61 Juhani Jaakola 2008-12-09 12:18:06 EST
My CD/DVD burner is:

$ dmesg | grep 1:0:0:0
scsi 1:0:0:0: CD-ROM            HL-DT-ST DVDRAM GSA-4167B DL10 PQ: 0 ANSI: 5
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg1 type 5

K3B shows this in its log:

HL-DT-ST DVDRAM GSA-4167B DL10 (/dev/sr0, ) [CD-R, CD-RW, CD-ROM, DVD-ROM, DVD-R, DVD-RW, DVD-R DL, DVD+R, DVD+RW, DVD+R DL] [DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW] [SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite]
Comment 62 William H. Haller 2008-12-09 12:26:11 EST
There seems to be one consistency for me in F9 which might be of interest. When I burn a DVD, I first make sure there is enough RAM, restarting Konqueror if necessary.

Next I press the burn menu button in k3b to get the burn dialog and then physically load the DVD. The important bit is that I don't actually press burn in the burn dialog window until the Devices recently plugged in pop up window has displayed AND DISAPPEARED. If I press burn before it goes away, I frequently have failures to verify. If I wait till it disappears, it will verify OK. This may be some localized effect on my box only, but it does seem remarkably consistent here.
Comment 63 Tom Horsley 2008-12-10 20:15:13 EST
My current symptom continues to be that k3b ejects the tray after
writing, then never reloads it. Meanwhile k3b itself goes into
a 100% cpu bound state (I checked with strace - it is not making
any system calls).

This is on x86_64 fedora 10 with a dvd writer that calls itself:

TSSTcorp CDDVDW SH-S203N

I'm using Circuit City NEXXTECH DVD+R DL media at the moment.

The actual writing always seems to be successful as verified after
the fact by checksum comparisons of the individual files.
Comment 64 Tom Horsley 2008-12-24 15:29:41 EST
Today, I wrote another dvd with identical results as comment #63 above,
but today I had free time to download a batch of debuginfo rpms and
attach to k3b and find out what the heck it was doing. I was watching when
it finished writing the DVD and the 100% cpu spike hit instantly as soon
as it ejected the media. At the micro level, I found it executing
this 4 instruction loop it will clearly take a while to get out of:

x/4i $pc
_ZN18K3bVerificationJob9readTrackEi+1128:
  378=   0x0000003fc37c1558 <+1128>:         addq $0x1,%rdx
  379    0x0000003fc37c155c <+1132>:         movq (%rax),%rax
  378    0x0000003fc37c155f <+1135>:         cmpq %rdx,%r14
  378    0x0000003fc37c1562 <+1138>:         ja 0x3fc37c1558 <+1128> # aka: jnbe
p/x $rdx
$3: $rdx = 0x27283bcc690
p/x $rax
$4: $rax = 0x2d96b50
x/1x $rax
0x02d96b50: 0x0000000002d96b50
p/x $r14
$5: $r14 = 0xffffffffffffffff

I suppose $rdx will eventually wrap around to -1, but in the time
it took to download and install the debuginfo rpms and attach to the
process, it apparently only made it to 0x27283bcc690, so it still has
a ways to go.

If you trust the debuginfo generated by g++ (always a risky proposition :-),
that corresponds to the loop in this template:

template <class T>
Q_INLINE_TEMPLATES Q_TYPENAME QValueListPrivate<T>::NodePtr QValueListPrivate<T>::at( size_type i ) const
{
    Q_ASSERT( i <= nodes );
    NodePtr p = node->next;
    for( size_type x = 0; x < i; ++x )
        p = p->next;
    return p;
}

Apparently p->next == p, so that will go for a while without hitting
a NULL pointer or anything like that.

And that was invoked somewhere (directly or indirectly) on this line

if( d->toc[d->tracks[trackIndex].trackNumber-1].type() == K3bDevice::Track::DATA ) {

which is in the void K3bVerificationJob::readTrack( int trackIndex )
function. (I'm getting the impression it believes it has already
started the verify, even though it never appeared to make any attempt
to reload the DVD).

At the macro level, the walkback looks like:

#0  0x0000003fc37c1558 in QValueList<K3bVerificationJobTrackEntry>::operator[](
                             unsigned long long i = cannot retrieve value)
                             at qt-3.3/include/qvaluelist.h line 378
#1  0x0000003fc37c1558 in K3bVerificationJob::readTrack(
                             int trackIndex = 1750384256)
                             at k3bverificationjob.cpp line 243
#2  0x0000003fc37c263f in K3bVerificationJob::slotDiskInfoReady(
                             class K3bDevice::DeviceHandler * dh = 0x7f226853d9b0)
                             at k3bverificationjob.cpp line 224
#3  0x0000003fc37c2877 in K3bVerificationJob::qt_invoke(
                             int _id = 15,
                             struct QUObject * _o = 0x7fff767386c0)
                             at k3bverificationjob.moc line 147
#4  0x0000003fc15605bc in QObject::activate_signal(
                             class QConnectionList * clist = 0x7f22681f2c10,
                             struct QUObject * o = 0x7fff767386c0)
                             at qobject.cpp line 2359
#5  0x0000003fc377e4e8 in DeviceHandler::finished(
                             class K3bDevice::DeviceHandler * t0 = 0x7f2268558b40)
                             at k3bdevicehandler.moc line 126
#6  0x0000003fc378013e in DeviceHandler::customEvent(
                             class QCustomEvent * e = 0x7f22681f7b90)
                             at k3bdevicehandler.cpp line 319
#7  0x0000003fc156070b in QObject::event(class QEvent * e = 0x7f22681f7b90)
                             at qobject.cpp line 758
#8  0x0000003fc14fecc2 in QApplication::internalNotify(
                             class QObject * receiver = 0x7f2268558b40,
                             class QEvent * e = 0x7f22681f7b90)
                             at qapplication.cpp line 2638
#9  0x0000003fc14ffc71 in QApplication::notify(
                             class QObject * receiver = 0x7f2268558b40,
                             class QEvent * e = 0x7f22681f7b90)
                             at qapplication.cpp line 2361
#10  0x0000003fc31d703d in KApplication::notify(
                              class QObject * receiver = 0x7f2268558b40,
                              class QEvent * event = 0x7f22681f7b90)
                              at kapplication.cpp line 550
#11  0x0000003fc1500b34 in QApplication::sendEvent(
                              class QObject * receiver = cannot retrieve value,
                              class QEvent * event = cannot retrieve value)
                              at kernel/qapplication.h line 523
#12  0x0000003fc1500b34 in QApplication::sendPostedEvents(
                              class QObject * receiver = 0,
                              int event_type = 0) at qapplication.cpp line 3302
#13  0x0000003fc14ad018 in QEventLoop::processEvents(unsigned int flags = 4)
                              at qeventloop_x11.cpp line 147
#14  0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201
#15  0x0048c04e in K3bJobProgressDialog::startJob(
                      class K3bJob * job = 0x2d8e300)
                      at k3bjobprogressdialog.cpp line 622
#16  0x0055a6a7 in K3bProjectBurnDialog::slotStartClicked()
                      at k3bprojectburndialog.cpp line 239
#17  0x00587d6f in K3bDvdBurnDialog::slotStartClicked()
                      at k3bdvdburndialog.cpp line 297
#18  0x0047cafc in K3bInteractionDialog::slotStartClickedInternal()
                      at k3binteractiondialog.cpp line 346
#19  0x0047d013 in K3bInteractionDialog::qt_invoke(
                      int _id = 79,
                      struct QUObject * _o = 0x7fff767391e0)
                      at k3binteractiondialog.moc line 254
#20  0x0000003fc15605bc in QObject::activate_signal(
                              class QConnectionList * clist = 0x2cd6260,
                              struct QUObject * o = 0x7fff767391e0)
                              at qobject.cpp line 2359
#21  0x0000003fc1561efd in QObject::activate_signal(int signal = 69)
                              at qobject.cpp line 2328
#22  0x0000003fc1598207 in QWidget::event(class QEvent * e = 0x7fff76739660)
                              at qwidget.cpp line 4705
#23  0x0000003fc14fecc2 in QApplication::internalNotify(
                              class QObject * receiver = 0x2d00e10,
                              class QEvent * e = 0x7fff76739660)
                              at qapplication.cpp line 2638
#24  0x0000003fc14ffe2a in QApplication::notify(
                              class QObject * receiver = 0x2d00e10,
                              class QEvent * e = 0x7fff76739660)
                              at qapplication.cpp line 2424
#25  0x0000003fc31d703d in KApplication::notify(
                              class QObject * receiver = 0x2d00e10,
                              class QEvent * event = 0x7fff76739660)
                              at kapplication.cpp line 550
#26  0x0000003fc149d148 in QETWidget::translateMouseEvent(
                              const union _XEvent * event = 0x3)
                              at qapplication_x11.cpp line 4339
#27  0x0000003fc149c0bb in QApplication::x11ProcessEvent(
                              union _XEvent * event = 0x7fff76739b70)
                              at qapplication_x11.cpp line 3603
#28  0x0000003fc14ad0b2 in QEventLoop::processEvents(unsigned int flags = 4)
                              at qeventloop_x11.cpp line 195
#29  0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201
#30  0x0048aeb3 in K3bInteractionDialog::exec(bool returnOnHide = true (69))
                      at k3binteractiondialog.cpp line 592
#31  0x0054d0f1 in K3bDataView::slotBurn() at k3bdataview.cpp line 177
#32  0x00547736 in K3bView::qt_invoke(
                      int _id = 46,
                      struct QUObject * _o = 0x7fff76739d90)
                      at k3bview.moc line 98
#33  0x0000003fc15605bc in QObject::activate_signal(
                              class QConnectionList * clist = 0x7f2268215630,
                              struct QUObject * o = 0x7fff76739d90)
                              at qobject.cpp line 2359
#34  0x0000003fc1561efd in QPtrVector<QConnectionList>::at(
                              unsigned int i = cannot retrieve value)
                              at qobject.cpp line 2328
#35  0x0000003fc1561efd in QSignalVec::at(
                              unsigned int index = cannot retrieve value)
                              at kernel/qsignalslotimp.h line 86
#36  0x0000003fc1561efd in QObject::activate_signal(int signal = 69)
                              at qobject.cpp line 2324
#37  0x0000003fc3e93067 in KAction::qt_invoke(
                              int _id = 12,
                              struct QUObject * _o = 0x7fff76739e60)
                              at kaction.moc line 215
#38  0x0000003fc15605bc in QObject::activate_signal(
                              class QConnectionList * clist = 0x7f2268211840,
                              struct QUObject * o = 0x7fff76739e60)
                              at qobject.cpp line 2359
#39  0x0000003fc1561efd in QPtrVector<QConnectionList>::at(
                              unsigned int i = cannot retrieve value)
                              at qobject.cpp line 2328
#40  0x0000003fc1561efd in QSignalVec::at(
                              unsigned int index = cannot retrieve value)
                              at kernel/qsignalslotimp.h line 86
#41  0x0000003fc1561efd in QObject::activate_signal(int signal = 69)
                              at qobject.cpp line 2324
#42  0x0000003fc1598207 in QWidget::event(class QEvent * e = 0x7fff7673a2e0)
                              at qwidget.cpp line 4705
#43  0x0000003fc14fecc2 in QApplication::internalNotify(
                              class QObject * receiver = 0x7f22681c4000,
                              class QEvent * e = 0x7fff7673a2e0)
                              at qapplication.cpp line 2638
#44  0x0000003fc14ffe2a in QApplication::notify(
                              class QObject * receiver = 0x7f22681c4000,
                              class QEvent * e = 0x7fff7673a2e0)
                              at qapplication.cpp line 2424
#45  0x0000003fc31d703d in KApplication::notify(
                              class QObject * receiver = 0x7f22681c4000,
                              class QEvent * event = 0x7fff7673a2e0)
                              at kapplication.cpp line 550
#46  0x0000003fc149d148 in QETWidget::translateMouseEvent(
                              const union _XEvent * event = 0x3)
                              at qapplication_x11.cpp line 4339
#47  0x0000003fc149c0bb in QWidget::isDesktop()
                              at qapplication_x11.cpp line 3603
#48  0x0000003fc149c0bb in QApplication::x11ProcessEvent(
                              union _XEvent * event = 0x7fff7673a7f0)
                              at qapplication_x11.cpp line 3569
#49  0x0000003fc14ad0b2 in QEventLoop::processEvents(unsigned int flags = 4)
                              at qeventloop_x11.cpp line 195
#50  0x0000003fc15175fb in QEventLoop::enterLoop() at qeventloop.cpp line 201
#51  0x0000003fc15174bc in QEventLoop::exec() at qeventloop.cpp line 148
#52  0x004a032a in main(
                      int argc = 1,
                      char ** argv = 0x7fff7673aa00) at main.cpp line 150
#53  0x000000318fa1e572 in __libc_start_main(
                              int (* main)() = 0x4a0060 main+0,
                              int argc = 1,
                              char ** ubp_av = 0x7fff7673acd8,
                              int (* init)() = 0x5afd70 __libc_csu_init+0,
                              void (* fini)() = cannot retrieve value,
                              void (* rtld_fini)() = cannot retrieve value,
                              void * stack_end = 0x7fff7673acc8)
                              at libc-start.c line 220
Comment 65 Brent R Brian 2009-02-14 12:54:34 EST
bug 457441 deals with the rt2500pci issue, if you are interested
Comment 66 Matt Johnston 2009-05-12 21:40:29 EDT
We're seeing the same issue of 100% CPU in K3bVerificationJob::readTrack, with:

Updated Fedora 10 x64
k3b 1.0.5-6.fc10
kernel 2.6.27.21-170.2.56.fc10.x86_64
LG DVDRAM GSA-4167B burner
DVD-R media

There was a >2GB file, so k3b prompted something about UDF - no idea if that is relevant.
Comment 67 Michael Schwendt 2009-05-26 04:50:15 EDT
There is a request from [upstream] Sebastian Trüg "to test with K3b 1.65.0".
Comment 68 Bug Zapper 2009-06-09 05:31:20 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 69 Tom Horsley 2009-06-13 20:52:12 EDT
In the interests of science, I just tried to write a DVD-R in
my newly installed fedora 11 system, and I get the same failure mode
as always. It gets to the verify step, ejects the disk, and
never reloads it, going into a 100% cpu loop instead of doing anything
useful. This is with:

k3b-1.0.5-8.fc11.x86_64
kernel-2.6.29.4-167.fc11.x86_64

Also as always, verifying the files by hand shows that the write
worked fine.
Comment 70 Fedora Update System 2009-06-15 15:47:46 EDT
k3b-1.0.5-9.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc11
Comment 71 Fedora Update System 2009-06-15 15:48:35 EDT
k3b-1.0.5-9.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc9
Comment 72 Fedora Update System 2009-06-15 15:48:41 EDT
k3b-1.0.5-9.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/k3b-1.0.5-9.fc10
Comment 73 Marc 2009-06-17 04:03:53 EDT
Just updated to k3b-1.0.5-9.fc11 with k3b-libs-1.0.5-9.fc11.i586.rpm on an Intel 875 motherboard, and LG DVD burner using a re-writable DVD and tracks were successfully verified.  K3b appears to prevent ejecting the media after burning to allow verification.  This seems to be a good fix to the verifying data problem, at least in F11.
Comment 74 Fedora Update System 2009-06-18 07:40:01 EDT
k3b-1.0.5-9.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update k3b'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-6524
Comment 75 Robin Laing 2009-06-26 00:05:39 EDT
On F11, k3b-1.0.5-9.fc11.x86_64 still doesn't verify the data.  I just downloaded and tried to run this version.  It was better than k3b-1.0.5-8.fc11.x86_64 which just stopped.  Now at least the DVD is ejected and reloaded before k3b freezes.

ps aux shows

robin    19387 24.7  1.5 568236 62116 ?        Rl   21:32   4:47 /usr/bin/k3b

What is interesting is k3b is using about 100% of one processor.
19387 robin     20   0  554m  60m  19m R 99.3  1.5  10:22.15 k3b

strace -fp 19387 provides the attached file output.

I hope this gets fixed.
Comment 76 Robin Laing 2009-06-26 00:07:45 EDT
Created attachment 349506 [details]
strace output - Comment #75
Comment 77 Fedora Update System 2009-06-30 17:21:08 EDT
k3b-1.0.5-9.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 78 Fedora Update System 2009-06-30 17:39:04 EDT
k3b-1.0.5-9.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 79 Fedora Update System 2009-06-30 17:39:31 EDT
k3b-1.0.5-9.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 80 Rex Dieter 2009-06-30 18:40:10 EDT
Re-opened per comment #75
Comment 81 Tom Horsley 2009-07-01 09:01:30 EDT
I just used k3b-1.0.5-9.fc11.x86_64 to successfully write a DVD+R DL
disk and verify after writing! I can't even remember the last time that
worked :-). I've got an atapi Pioneer DVD-RW DVR-117D drive now (the
drive I had when I first chimed in to this bug died a while ago).
Comment 82 Rex Dieter 2009-07-01 09:12:19 EDT
Interesting.

Let's go with closing this then, per the positive feedback, for anyone with remaining issues, please open a new bug.
Comment 83 cornel panceac 2009-07-01 09:27:46 EDT
well, i believe cleaning up this issue is a good thing (by starting a new bug), but i'm not that sure the isse is fixed, because recently, more often than not, k3b verified the writing. however, i'm positive i've seen somewhere a message from sebastian trueg askin' for testing of this issue on recent builds of k3b, like 1.66.X. are somewhere fedora rpms for 1.6x series?
Comment 84 Rex Dieter 2009-07-01 10:05:47 EDT
k3b-1.6x builds are in rawhide, and kde-redhat/unstable repos for F-10/F-11
Comment 85 cornel panceac 2009-07-01 11:43:41 EDT
thnx a lot.
Comment 86 Brad 2009-07-01 13:10:30 EDT
I suspect that closing this bug is more about the politics than about technical matters. This bug has been open since F8 and there are MANY such bugs. Fedora has been taking a lot of heat about these "legacy" (multi release) bugs. When this bug is closed the problem will just sit (as this bug did for so long) and very little work is likely to be done on it until it reaches old age (like this bug).
Comment 87 Rex Dieter 2009-07-01 13:18:33 EDT
Brad, are you still having problems and/or can you contribute something constructive here?
Comment 88 Brad 2009-07-01 13:24:13 EDT
Yes, the bug still exists with me on F11 and 105-9, so does the disk transfer bug introduced in F7.
Comment 89 Rex Dieter 2009-07-01 13:34:05 EDT
To be clear, this is bug tracking the issue of getting the error: 
No tracks to verify found

Are you still seeing this or something else?
Comment 90 Robin Laing 2009-07-13 00:57:53 EDT
Using k3b-1.0.5-9.fc11.x86_64
KDE desktop fully updated.

I have been to busy to look into this until tonight.

Will not verify any DVD I have tried to record.  Either Video or DATA DVD. 

Program ejects the DVD and reloads only to have k3b freeze.

k3b won't redraw the screen as it is now just blank windows.

This is what was shown in the terminal window when I ran k3b




[robin@eagle1 ~]$ (K3bDevice::HalConnection) initializing HAL >= 0.5                      
Mapping udi /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N to device /dev/sr0
/dev/sr0 resolved to /dev/sr0                                                             
/dev/sr0 is block device (0)                                                              
/dev/sr0 seems to be cdrom                                                                
bus: 6, id: 0, lun: 0                                                                     
(K3bDevice::Device) /dev/sr0: init()                                                      
(K3bDevice::Device) /dev/sr0 feature: CD Mastering                                        
(K3bDevice::Device) /dev/sr0 feature: CD Track At Once                                    
(K3bDevice::Device) /dev/sr0 feature: DVD Read (MMC5)                                     
(K3bDevice::Device) /dev/sr0 feature: DVD+R                                               
(K3bDevice::Device) /dev/sr0 feature: DVD+RW                                              
(K3bDevice::Device) /dev/sr0 feature: DVD+R Double Layer                                  
(K3bDevice::Device) /dev/sr0 feature: DVD-R/-RW Write                                     
(K3bDevice::Device) /dev/sr0 feature: Rigid Restricted Overwrite                          
(K3bDevice::Device) /dev/sr0 feature: Layer Jump Recording                                
(K3bDevice::Device) /dev/sr0 unknown profile: 2                                           
(K3bDevice::Device) /dev/sr0: dataLen: 60                                                 
(K3bDevice::Device) /dev/sr0: checking for TAO                                            
(K3bDevice::Device) /dev/sr0: checking for SAO                                            
(K3bDevice::Device) /dev/sr0: checking for SAO_R96P                                       
(K3bDevice::Device) /dev/sr0: checking for SAO_R96R                                       
(K3bDevice::Device) /dev/sr0: checking for RAW_R16                                        
(K3bDevice::Device) /dev/sr0: checking for RAW_R96P                                       
(K3bDevice::Device) /dev/sr0: checking for RAW_R96R                                       
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72                                
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68         
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4    
(K3bDevice::Device) /dev/sr0 : 22160 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 16620 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 11080 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 5540 KB/s                                                  
(K3bDevice::DeviceManager) setting current write speed of device /dev/sr0 to 22160        
Could not resolve /dev/hdd                                                                
/dev/hdd resolved to /dev/hdd                                                             
(K3bDevice::Device) could not open device /dev/hdd for reading                            
                    (No such file or directory)                                           
could not open device /dev/hdd (No such file or directory)                                
Could not resolve /dev/hdc                                                                
/dev/hdc resolved to /dev/hdc                                                             
(K3bDevice::Device) could not open device /dev/hdc for reading                            
                    (No such file or directory)                                           
could not open device /dev/hdc (No such file or directory)                                
/dev/scd0 resolved to /dev/sr0                                                            
(K3bDevice::DeviceManager) dev /dev/sr0 already found                                     
/dev/sr0 resolved to /dev/sr0                                                             
(K3bDevice::DeviceManager) dev /dev/sr0 already found                                     
(K3bDevice::DeviceManager) found config entry for devicetype: HL-DT-ST DVD-RAM GSA-H54N   
First sec data area: 43:41:33 (LBA 196608) (402653184                                     
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)                            
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)                                              
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)                                             
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)                                
DiskInfo:                                                                                 
Mediatype:       DVD+R                                                                    
Current Profile: DVD+R                                                                    
Disk state:      empty                                                                    
Empty:           1                                                                        
Rewritable:      0                                                                        
Appendable:      0                                                                        
Sessions:        0                                                                        
Tracks:          0                                                                        
Layers:          1                                                                        
Capacity:        510:01:29 (LBA 2295104) (4700372992 Bytes)                               
Remaining size:  510:01:29 (LBA 2295104) (4700372992 Bytes)                               
Used Size:       00:00:00 (LBA 0) (0 Bytes)                                               
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72                                
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68         
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4    
(K3bDevice::Device) /dev/sr0 : 22160 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 16620 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 11080 KB/s                                                 
(K3bDevice::Device) /dev/sr0 : 5540 KB/s                                                  
Devices:                                                                                  
------------------------------                                                            
Blockdevice:    /dev/sr0                                                                  
Generic device:                                                                           
Vendor:         HL-DT-ST                                                                  
Description:    DVD-RAM GSA-H54N                                                          
Version:        1.00                                                                      
Write speed:    3324                                                                      
Profiles:       DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW                                                                                    
Read Cap:       DVD-ROM, DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW                                         
Write Cap:      DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-R, CD-RW                                                                             
Writing modes:  SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R, Restricted Overwrite, Layer Jump                                                                                
Reader aliases: /dev/sr0, /dev/scd0                                                             
------------------------------                                                                  
adding udi   /org/freedesktop/Hal/devices/volume_empty_dvd_plus_r                               
First sec data area: 43:41:33 (LBA 196608) (402653184                                           
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)                                  
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)                                                    
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)                                                   
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)                                      
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72                                      
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68               
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4          
(K3bDevice::Device) /dev/sr0 : 22160 KB/s                                                       
(K3bDevice::Device) /dev/sr0 : 16620 KB/s                                                       
(K3bDevice::Device) /dev/sr0 : 11080 KB/s                                                       
(K3bDevice::Device) /dev/sr0 : 5540 KB/s                                                        
(K3bDevice::HalConnection) lock queued for /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N                                                                                          
(K3bDevice::HalConnection) unlock queued for /org/freedesktop/Hal/devices/storage_model_DVD_RAM_GSA_H54N                                                                                        
First sec data area: 43:41:33 (LBA 196608) (402653184                                           
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)                                  
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)                                                    
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)                                                   
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)                                      
DiskInfo:                                                                                       
Mediatype:       DVD+R                                                                          
Current Profile: DVD+R                                                                          
Disk state:      incomplete                                                                     
Empty:           0                                                                              
Rewritable:      0                                                                              
Appendable:      1                                                                              
Sessions:        1                                                                              
Tracks:          1                                                                              
Layers:          1                                                                              
Capacity:        510:01:29 (LBA 2295104) (4700372992 Bytes)                                     
Remaining size:  47:00:36 (LBA 211536) (433225728 Bytes)                                        
Used Size:       463:00:68 (LBA 2083568) (4267147264 Bytes)                                     
(K3bDevice::Device) /dev/sr0 current profile 0. Checking current profile list instead.          
(K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed.                              
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 8                                       
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE reports bogus dataLen: 8                          
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via 2A: 4                       
(K3bDevice::Device) /dev/sr0 : 8468 KB/s                                                        
(K3bDevice::Device) /dev/sr0 : 7056 KB/s                                                        
(K3bDevice::Device) /dev/sr0 : 4234 KB/s                                                        
(K3bDevice::Device) /dev/sr0 : 2824 KB/s                                                        
removing udi /org/freedesktop/Hal/devices/volume_empty_dvd_plus_r                               
(K3bDevice::Device) /dev/sr0 current profile 0. Checking current profile list instead.          
(K3bDevice::Device) /dev/sr0: GET CONFIGURATION length det failed.                              
ASSERT: "i <= nodes" in /usr/lib64/qt-3.3/include/qvaluelist.h (376)                            
First sec data area: 43:41:33 (LBA 196608) (402653184
Last sec data area: 553:42:61 (LBA 2491711) (5103024128 Bytes)
Last sec layer 1: 00:00:00 (LBA 0) (0 Bytes)
Layer 1 length: 00:00:01 (LBA 1) (2048 Bytes)
Layer 2 length: 553:42:61 (LBA 2491711) (5103024128 Bytes)
DiskInfo:
Mediatype:       DVD+R
Current Profile: DVD+R
Disk state:      incomplete
Empty:           0
Rewritable:      0
Appendable:      1
Sessions:        1
Tracks:          1
Layers:          1
Capacity:        510:01:29 (LBA 2295104) (4700372992 Bytes)
Remaining size:  47:00:36 (LBA 211536) (433225728 Bytes)
Used Size:       463:00:68 (LBA 2083568) (4267147264 Bytes)
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 22160 KB/s
(K3bDevice::Device) /dev/sr0 : 16620 KB/s
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s




This is an strace of k3b after it reloads the disk.  This is a thread that is created from k3b.  It is not under the PID for k3b.  I had to use strace -ff -p{pid} -o{file_name} to get anything.

This just repeats over and over.



futex(0x7f8437d33fc0, FUTEX_WAKE_PRIVATE, 1) = 0                                                
uname({sys="Linux", node="eagle1.tardis.localdomain", ...}) = 0                                 
open("/dev/sr0", O_RDONLY|O_NONBLOCK)   = 16                                                    
ioctl(16, SG_IO, {'S', SG_DXFER_NONE, cmd[6]=[00, 00, 00, 00, 00, 00], mx_sb_len=64, iovec_count=0, dxfer_len=0, timeout=5000, flags=0x3, status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0, info=0}) = 0                                              
close(16)                               = 0                                                     
futex(0x7f8437d33f94, FUTEX_WAIT_PRIVATE, 1, {1, 999997206}) = -1 ETIMEDOUT (Connection timed out)



I had to killed k3b with killall k3b.  

KDE recognizes the DVD and prompts for what to do with the DVD.

Hope it gets fixed.

Should I open a new bug for k3b not verifying?
Comment 91 Marc 2009-07-16 04:02:35 EDT
Just following-up on comment 73 above, I've burned data to a re-writable DVD again and again successfully verified the tracks on an i686.  This is also after the recent swathe of updates (to 9th July 2009).  It would seem the problem is now with some fc11.x86_64 set-ups, as others with i686 set-ups don't seem to be reporting further verifying tracks issues.
Comment 92 Robin Laing 2009-07-22 02:47:04 EDT
Reference to Comment 90.

Last night I recorded a DVD and it verified the DVD.  Tonight I burned a DVD and it failed to verify.

The only difference was last night K3B didn't eject the DVD while tonight it did.

K3B seems to freeze as soon as KDE's device notifier shows that the disk has loaded into the player.  K3B is now dead to the world and needs to be killed to get the drive back.
Comment 93 Thomas Pifer 2009-07-26 18:47:18 EDT
I'm experiencing the same issue as comment 91: I just upgraded to x86_64 and while the bug is fixed on i586, it seems that it still exists on x86_64.
Comment 94 Marc 2009-07-27 04:21:36 EDT
Just added F11 updates (to 19th July 2009) and K3b on an i686 now ejects after immediately after burning and automatically re-loads immediately to verify the data (as it used to do), which it verifies successfully. This seems to have reverted K3b to the normal set-up before the verify data problems occurred, at least on an i686. Perhaps this re-load sequence is connected with the problems remaining with .x86_64 set-ups?
Comment 95 Marc 2009-08-18 04:20:46 EDT
Following recent updates, K3b once again fails to verify data on an i686.  It burns the data, ejects and reloads ready for verification, but instead of verifying the data, it mounts the media and freezes.  This is on kernel-PAE-2.6.29.6-217.2.7.fc11.i686.rpm
Comment 96 Robin Laing 2009-10-06 01:26:35 EDT
An update.  Yesterday I burned a couple of DVD's and k3b came up with an error message that it couldn't eject the media between the burn and verify phases.  Tonight using the same procedure, the DVD's are ejecting again but not verifying.

I am now back at getting the "device notifier" popping up when the DVD is re-loaded and then k3b hangs waiting for the DVD player.  I have to manually kill k3b to get the DVD drive back and to continue using k3b.

If the drive doesn't eject, then the media is tested.

I see that this bug is closed due to ERRATA, what errata and can a link be provided?  It would have been nice to see that this is related to a kernel problem.  What bug?
Comment 97 Rex Dieter 2009-10-06 01:45:52 EDT
Please refer to early comments and comment #89 in particular.  This bug is tracking the "No tracks to verify found" issue.

If experiencing something *other* than this, commenting here is... not productive.  Please file a new bug.

Note You need to log in before you can comment on or make changes to this bug.