gvfsd-cdd prevents cd drive from opening

[Holger Koch]

Since Hardy when ripping CDs with Grip the application is unable to eject the CD automatically after ripping. It is possible to trigger the drive to open manually but only for a short moment, after one second the drive closes again, then it is not possible to open the drive unless grip is closed. sudo lsof /dev/scd0 revealed that the process gvfsd-cdd is connected to the CD drive. Killing this process enables the application to auto-eject the CD again. But each time a new CD is mounted the process starts again.

[Sebastien Bacher (seb128)]

thank you for your bug report. could you describe easy steps to trigger the bug? does inserting the CD and pressing the drive button after having mounted works correctly?

[Holger Koch (atarax)]

when i insert a cd and push the eject button on the drive, it opens without problem. even with grip running (and ripping) the cd can be ejected this way. but when i rip right until the end of a whole cd (or a preselected number of tracks) and (according to my grip setting) the automatic eject should be performed (what does not happen), i can manually open the drive for one second only by pushing its eject button. it closes again (eventhough the cd is not being mounted again!) and remains locked until i close grip. this is the standard behaviour i observed. but this behaviour is not regular. sometimes in rare cases the automatic eject is being performed as it should be. and sometimes the drive can be manually opened after the one-second-opening. so one has to try a few times (selecting only one track to be ripped) to reproduce this bug.

i hope this helps

[Sebastien Bacher (seb128)]

does eject <device> work when you get the issue?

[Holger Koch (atarax)]

i guess you talk about a terminal command? if so it does, but it's pretty much the same behaviour as if i open the drive manually: the tray opens only for one second then closes again.

one exeption:

i just had one incidence where i let grip rip and encode a single track, after that the auto eject failed to work as usual. i entered 'eject scd0' in the command line and the tray opened for a second and closed again. when i entered 'eject scd0' for a second time the tray opened and remained open.

i repeated this process but not using the command line but the physical eject button of the drive. here when first pressing the eject button the tray opens only for a second and closes. but when i press the eject button again, the tray remains closed until i press it for a third time. but maybe it's only that you have to wait some time anyway for the drive to be "ready" for an eject process, because it needs to be unmounted etc. i have always been surprised, why grip always freezes completely everytime while you mount or unmount the cd drive...

sorry no real hard evidence for bug tracking but that's all i have.
btw: did you get any similar behaviour on your machine?

[Sebastien Bacher (seb128)]

not confirming on my installations no, ejecting just works fine but I don't use grip, could an issue in this software

[Holger Koch (atarax)]

well it worked flawless with gutsy before the release of gvfs...

[Sebastien Bacher (seb128)]

the issue is likely an upstream one, could you open the bug directly on bugzilla.gnome.org where people writting the code will read it?

[Sebastien Bacher (seb128)]

thank you for sending the bug to GNOME, could you update the launchpad but to give the GNOME bug number reference next time though?

[Holger Koch (atarax)]

the bug ist tracked by gnome at http://bugzilla.gnome.org/show_bug.cgi?id=550353

[Sebastien Bacher (seb128)]

upstream states that's an application bug