GNOME Bugzilla – Bug 94289
[cdparanoia] refusing to change state when cd is not in drive
Last modified: 2008-08-13 17:41:50 UTC
The cdparanoia drive refuses to change state when the tray is open. It does do so though when the tray is closed again. We need this in RB because, when cd cd drive is opened while playing from it, the cd stream should stop. We could ofcourse just lock the door while playing, and we'll do it as workaround for now, but it's just a lot nicer to be able to change cds without having to worry about states and stuff.
Actually, we cannot lock the tray because when stuff crashes the tray wont open anymore ;)
As I see it, cdparanoia should do the following under an "error condition", i.e., CD being ejected: - PLAYING: send an EOS event and throw a 'media ejected' signal (or possibly error) - PAUSED or READY: throw a media ejected signal - NULL do nothing If the tray is open, and the element is in the PAUSED or READY state, the element is in an inconsistent state, and any attempts to change the state READY->PAUSED or PAUSED->PLAYING should throw an error. Changes toward NULL are ok. This does not handle 1) closing the tray when a play button is pressed, or 2) automatically playing when a disk is inserted. The former *could* be done during the NULL->READY state transition, depending on a parameter, but I don't recommend it. I would prefer to see a separate interface to control the availability of the CD tray resource. I'd like to hear comments from other gstreamer developers on the media-ejected signal vs. error issue.
Looking at this further, this bug requires changes in cdparanoia to be fixed. Basically, libcdparanoia never returns control to the application when the disk is ejected. The cdparanoia application has the same behavior.
*** Bug 336197 has been marked as a duplicate of this bug. ***
Created attachment 69134 [details] A short python script that produces a segfault on setting pipeline state to NULL in response to a transport-error A simple script to reproduce a segfault that I encountered while trying to write a pygst cd player / ripper. To handle the situation where the cd-drive is opened during playback I tried stopping the pipeline in response to transport-error from cdparanoia. When I do I get the following error: (no debugging symbols found) (no debugging symbols found) [New Thread -1226667088 (LWP 7746)] [New Thread -1236497488 (LWP 7750)] [New Thread -1245246544 (LWP 7752)] [New Thread -1253639248 (LWP 7753)] [Thread -1253639248 (LWP 7753) exited] Handling cdparanoia transport-error (gst-cdparanoia-debug.py:7743): GStreamer-WARNING **: trying to join task 0x82d0a98 from its thread would deadlock Program received signal SIGSEGV, Segmentation fault.
+ Trace 69426
Thread NaN (LWP 7750)
Created attachment 69135 [details] A short python script that produces a segfault on setting pipeline state to NULL in response to a transport-error A simple script to reproduce a segfault that I encountered while trying to write a pygst cd player / ripper. To handle the situation where the cd-drive is opened during playback I tried stopping the pipeline in response to transport-error from cdparanoia. When I do I get the following error: (no debugging symbols found) (no debugging symbols found) [New Thread -1226667088 (LWP 7746)] [New Thread -1236497488 (LWP 7750)] [New Thread -1245246544 (LWP 7752)] [New Thread -1253639248 (LWP 7753)] [Thread -1253639248 (LWP 7753) exited] Handling cdparanoia transport-error (gst-cdparanoia-debug.py:7743): GStreamer-WARNING **: trying to join task 0x82d0a98 from its thread would deadlock Program received signal SIGSEGV, Segmentation fault.
+ Trace 69427
Sorry for posting that attachement twice. I thought the first time that the browser had hung.
The signal is emmited form the streaming thread. You cannot change the state in the streaming thread, hence that warning. You can post an application message or add an idle callback to stop the element from the main thread instead. Trying to figure out how we can prevent the element from crashing.
following commits make the element not crash anymore. Now the element hangs again in cdparanoia. Moving to enhancement, this is unlikely to get fixed soon. * gst/gstpad.c: (gst_pad_activate_pull), (gst_pad_activate_push), (gst_pad_stop_task): When pad (de)activation failed for some reason, restore the old activation mode and set the pad to flushing instead of assuming the pad is deactivated. If the _task_join() failed, reinstall the task on the pad so that it can be stopped later and return an error. * libs/gst/base/gstbasesrc.c: (gst_base_src_change_state): If the parent state change function failed, don't assume we can safely stop the source, this will be done when the pads are deactivated.
*** Bug 358146 has been marked as a duplicate of this bug. ***
*** Bug 481637 has been marked as a duplicate of this bug. ***
Testing 'cdparanoiasrc ! fakesink', the pipeline completes with EOS when I eject the CD. "EOS" doesn't seem like the correct behavior, though. On further reflection, it appears paranoia_read() returns valid buffers after the CD has been ejected.
> On further reflection, it appears paranoia_read() returns valid buffers after > the CD has been ejected. So basically this is still a bug in libcdparanoia then, right?
Waiting to hear back from monty about that. His first comment was that it may be that my CD-ROM drive just happens to return 'no error' after the CD has been ejected.
Fixed in r15177 in cdparanoia subversion: ------------------------------------------------------------------------ r15177 | xiphmont | 2008-08-12 23:30:12 -0700 (Tue, 12 Aug 2008) | 20 lines Correct a small raft of transport errors that have crept in due to insufficient testing while keeping up with constant kernel API churn. Among other things, density det for very old drives has been broken for some time, as was command set scanning. Correct SGIO error detection such that sense keys are being properly parsed and then the results actually returned somewhere when errors happen. Add a new error return code for the cdrom going missing in the middle of an operation (404 amusingly enough; no really, it was the next in sequence) and propogate that error upwards through the various layers; errno is also set to ENOMEDIUM. Allow main application read loop to bail on such a 404. Continue working on cache detection fun