Bug 151816 - K3b can't reload media for verification
Summary: K3b can't reload media for verification
Status: RESOLVED DUPLICATE of bug 156684
Alias: None
Product: k3b
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Sebastian Trueg
URL:
Keywords:
: 152226 157767 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-03 17:30 UTC by Roberto Malinverni
Modified: 2008-04-19 16:35 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch to revert the change causing the regression (3.30 KB, patch)
2007-12-07 19:38 UTC, Kevin Kofler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto Malinverni 2007-11-03 17:30:41 UTC
Version:           1.0.4 (using KDE KDE 3.5.7)
Installed from:    Fedora RPMs
Compiler:          gcc 4.1.2 rpm shipped with Fedora 7
OS:                Linux

After successfully burning a data dvd with "verify written data" option, the dvd is ejected but after that it isn't reloaded: the tray remains open. If I close the tray manually, the process hangs (the timer continues to run, but nothing happens).
This happens with a NEC 3500AG and a LG 4163B - the previous version of K3b worked fine
(apart from the "erasing failed" message after the pre-formatting step of dvd+rw burning).
Comment 1 Roberto Malinverni 2007-11-03 17:32:27 UTC
sorry, I wasn't clear: KDE is installed via Fedora RPM; K3b is compiled from source with GCC 4.1.2
Comment 2 mauro.sacchetto 2007-11-11 03:09:05 UTC
I have just the same trouble with the same version of K3b
on Debian Sid (KDE 3.5.8). All official packages.
DIsk is ejected, but remain out of the tray and verification
doesn't start. Closing manually the tray is vain...
MS

Comment 3 David Spicer 2007-11-11 16:59:41 UTC
Exactly the same problem here.  K3b 1.0.4 using KDE 3.5.8, Arch Linux, packages installed from Arch repositories.
Comment 4 firewalker 2007-11-14 22:02:05 UTC
Same as the  message above (#3).
Comment 5 siege2050 2007-12-01 10:34:16 UTC
Same here on Linux from scratch system. Previous version worked okay.
Comment 6 Rex Dieter 2007-12-07 14:41:14 UTC
confirmed.
Comment 7 Rex Dieter 2007-12-07 14:42:09 UTC
*** Bug 152226 has been marked as a duplicate of this bug. ***
Comment 8 Kevin Kofler 2007-12-07 19:38:13 UTC
Created attachment 22403 [details]
Patch to revert the change causing the regression

I believe this regression is caused by this change:
 * Do only reload the medium before verification if necessary, i.e. if the
newly written
   track cannot be read otherwise (many old drives depend on this). Hopefully
this will
   at least work around the aweful "DMA disabled" bug for many users.

(I can't imagine any of the other changes from 1.0.3 to 1.0.4 causing this, and
this change looks very related.)

Until Sebastian Trüg comes up with a real fix, here's a patch which reverts
that change.
Comment 9 Roberto Malinverni 2007-12-08 21:22:20 UTC
The patch works for me, thanks!
Comment 10 Rex Dieter 2007-12-10 16:07:21 UTC
Sebastian, this bug is now over a month old, any comment/insights here?
Comment 11 Paul Philippov 2007-12-20 22:27:34 UTC
confirmed on gentoo
Comment 12 Johnathon Weare 2007-12-21 12:04:08 UTC
confirmed on KDE 3.5.8, Kubuntu 7.10 (+backports), k3b 1.0.4, (2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux)

This is on a Dell laptop. Burning finishes, ejects, then can only be cancelled. 
Comment 13 Rex Dieter 2007-12-21 19:22:07 UTC
fwiw, fedora is now including the patch (from comment #8) to revert the problematic code, at least until we get any upstream comment/feedback.
Comment 14 firewalker 2008-01-03 15:50:55 UTC
Someone else found that verification will work if k3b is set not to eject the medium after the write process has finished (Settings -> Advanced, Miscellaneous, Do not eject medium after write process). It works for me too.
Comment 15 Rex Dieter 2008-02-13 14:02:55 UTC
*** Bug 157767 has been marked as a duplicate of this bug. ***
Comment 16 Rex Dieter 2008-02-25 15:50:14 UTC

*** This bug has been marked as a duplicate of 156684 ***
Comment 17 François Valenduc 2008-03-29 16:05:30 UTC
This patch doesn't solve the problem for me. If I don't prevent from ejecting the disk after the burn, the verification process doesn't start and ends with this error: "no track to verify".