Version: unspecified (using KDE 4.6.3) OS: Linux Data discs (as opposed to Audio CDs or discs that don't need mounting per se) aren't ejected by the Device Notifier's eject button - just unmounted. I still have to manually reach over and hit the drive's physical eject button to actually spit out the disc. Dolphin is similarly glitchy. Eject there just unmounts, though then trying to eject again actually works. Curiously, Audio CDs don't have this problem. They are ejected using the eject button (at least they were - now they don't show up in Device Notifier at all, but that's another problem), probably because they aren't mounted like data discs. Reproducible: Always Steps to Reproduce: Insert a data disc (CD, DVD, Blu-Ray) into your optical drive. Mount it. Then try to eject it using the device notifier. Actual Results: The disc is unmounted, but not ejected. Expected Results: The disc is unmounted, and then immediately also ejected.
I can confirm the exact same behavior on my core i7 Sandy bridge machine. Gentoo gcc 4.5.3-r1 kde 4.6.5 fresh install.
could it be an avx-bug? which components would I have to rebuild? What machine/processor are you on? Smells like a race-condition: first eject, then unmount...
Works for me as expected in 4.7.4... May be a pure 4.6 bug. Can you reproduce on 4.7/4.8?
4.7.4 reproduced, but with better results: just 5 of 7 fail to unmount (same disc). A workaround would be an eject-button on even unmounted discs, as the disc is still in the drive.
Let me clarify the issue. The problem is one needs to click eject twice for a mounted data cd to be ejected, the first time it gets unmounted, the second time actually ejected. This happens in both Dolphin and in the device notifier. Please confirm that this is the case. Thanks __J
(In reply to comment #5) > Let me clarify the issue. > The problem is one needs to click eject twice for a mounted data cd to be > ejected, the first time it gets unmounted, the second time actually ejected. > This happens in both Dolphin and in the device notifier. > Please confirm that this is the case. > > Thanks > __J No. In my case it didn't eject at all. (In reply to comment #4) > 4.7.4 reproduced, but with better results: just 5 of 7 fail to unmount (same > disc). > A workaround would be an eject-button on even unmounted discs, as the disc > is still in the drive. Yes.
Works for me in 4.9rc2 and also in 4.8.4, please re-open if the bug persists in 4.9 final
Still there in 4.9.0 (Gentoo build) for me : Insert DVD Video disk Click Open with VLC [VLC Running, watching...] Close VLC Click the eject button on the device notifier [The disk is unmounted but not ejected as it should be]
The same for me (Gentoo, kde-4.9.2). Does anybody have an idea how to debug this one?
I can rep, but when ejecting for the first time, I get the following error from udisks "A job is pending on /dev/<devicename>" Does any of you guys get the same message? Lukas? any ideas?
I guess the problem ist the implementation of UDisksOpticalDrive::eject(). When the disk is mounted, this method uses a non-blocking DBus call to unmount the disk, followed by a call to eject it. There is probably a chance that udisks receives the eject request before the unmount is complete. Replacing c.call(msg, QDBus::NoBlock); by c.call(msg, QDBus::Block); in solid/solid/backends/udisks/udisksopticaldrive.cpp fixed this problem for me (KDE 4.8.4, Debian package).
lukas? can you comment on this? (In reply to comment #11) > I guess the problem ist the implementation of > UDisksOpticalDrive::eject(). When the disk is mounted, this method > uses a non-blocking DBus call to unmount the disk, followed by a call > to eject it. There is probably a chance that udisks receives the eject > request before the unmount is complete. Replacing > > c.call(msg, QDBus::NoBlock); > > by > > c.call(msg, QDBus::Block); > > in solid/solid/backends/udisks/udisksopticaldrive.cpp fixed this > problem for me (KDE 4.8.4, Debian package).
just my 2 cents: turning this call into a blocking call is not at all a good idea, but if this really solves the issue, then we should consider making a two-round call as we do with crypto devices. All in all I still do not quite understand why we need to call eject twice to be honest
I'll look into it... but it's quite possible that the unmount action doesn't finish before the eject is called
Git commit cbbabc7963f212b8e4d00edd8eaf56fe855ac8c0 by Lukáš Tinkl. Committed on 15/11/2012 at 16:48. Pushed by lukas into branch 'KDE/4.10'. eject the optical drive with the unmount option fixes #274982 - The 'eject' action only unmounts data CDs rather than ejecting them M +1 -9 solid/solid/backends/udisks/udisksopticaldrive.cpp http://commits.kde.org/kdelibs/cbbabc7963f212b8e4d00edd8eaf56fe855ac8c0
Git commit cd4b4377f1f989cc7e3ed088e01ae0cca1872115 by Lukáš Tinkl. Committed on 15/11/2012 at 16:48. Pushed by lukas into branch 'KDE/4.9'. eject the optical drive with the unmount option fixes #274982 - The 'eject' action only unmounts data CDs rather than ejecting them M +1 -9 solid/solid/backends/udisks/udisksopticaldrive.cpp http://commits.kde.org/kdelibs/cd4b4377f1f989cc7e3ed088e01ae0cca1872115
This patch maybe doesn't solve the problem: now I cannot eject the CD anymore, or after a long time. ARE YOU GOOD???????
*** This bug has been marked as a duplicate of bug 311613 ***