GNOME Bugzilla – Bug 414834
Problem adding mp3s to rhythmbox from a remote host.
Last modified: 2010-03-30 11:30:59 UTC
That bug has been opened on https://launchpad.net/bugs/84449 "... When I try to add the same file to the rhythmbox music database, I get the gstreamer error "failed to change state". Also I cannot open the music files with totem. I've tested gnome-vfs with gnomevfs-ls, gnomevfs-cat and gnomvfs-info. All three work fine on the files, nautilus, totem and rhythmbox have problem with. ... http://librarian.launchpad.net/6389270/01%20I%20Wouldn%27t%20Want%20To%20Be%20Like%20You.mp3 File which cannot be added to the music database ... I've tested your gst-launch line above with one working file and with one that does not work. Also I activated the verbose feature. The detailed results are in the attached files. Here a quick summary: gst-launch-0.10 --verbose playbin uri=ftp://xxxxxxxx:xxxxxxxx@syrius/music/70er/The\ Alan\ Parsons\ Project/The\ Best\ Of\ The\ Alan\ Parsons\ Project/03\ Games\ People\ Play.mp3 Setting pipeline to PAUSED ... /playbin0/decoder/typefind.src: caps = application/x-id3 Pipeline is PREROLLING ... after that, the program stops. I waited several minutes, but nothing happend. In contrast to that, the working file produced the following output: ... > Could you get a log with "GST_DEBUG_NO_COLOR=1 GST_DEBUG=5 gst-launch-0.10 playbin uri=... &>log"? ... http://librarian.launchpad.net/6611119/log-B the requested log Jep. Additional I've created a log for a working URI. But it is rather large (247 MB). So I do not add it. Both files look quite similar except for the last 200-300 lines."
the interesting bit is in a failed state change in id3demux: 0:00:01.412101000 7560 0x8051a08 WARN GST_PADS gstpad.c:671:gst_pad_set_active: Failed to activate pad id3demux0:sink 0:00:01.413354000 7560 0x8051a08 LOG GST_REFCOUNTING gstobject.c:352:gst_object_unref:<id3demux0:sink> 0x8102400 unref 3->2 0:00:01.413401000 7560 0x8051a08 LOG GST_REFCOUNTING gstobject.c:352:gst_object_unref:<id3demux0> 0x8142000 unref 4->3 0:00:01.413418000 7560 0x8051a08 DEBUG default gstelement.c:2366:gst_element_pads_activate:<id3demux0> sink pads_activate failed 0:00:01.413567000 7560 0x8051a08 INFO GST_STATES gstelement.c:2189:gst_element_change_state:<id3demux0> have FAILURE change_state return 0:00:01.413603000 7560 0x8051a08 INFO GST_STATES gstelement.c:1840:gst_element_abort_state:<id3demux0> aborting state from READY to PAUSED 0:00:01.413621000 7560 0x8051a08 LOG GST_STATES gstelement.c:2228:gst_element_change_state:<id3demux0> exit state change 0 0:00:01.413638000 7560 0x8051a08 DEBUG GST_STATES gstelement.c:2148:gst_element_set_state_func:<id3demux0> returned 0 0:00:01.413656000 7560 0x8051a08 LOG GST_REFCOUNTING gstobject.c:352:gst_object_unref:<id3demux0:sink> 0x8102400 unref 2->1
This is with a very ancient version of gstreamer and gst-plugins-base. Could you check if this is still happening with the latest versions? This case should be handled properly by GstTagDemux and id3demux now if I understand the debug log properly.
Also happens with current versions occasionally - the files in question are on an NFS share on my file server in this case: [zlatko@disclosure]:~$ stowes list gst.*10 Listing packages in /usr/local/stow matching [ gst.*10 ] (8 matches): I GStreamer-0.10 I gst-ffmpeg-0.10.4 I gst-plugins-bad-0.10.7 I gst-plugins-base-0.10.19 I gst-plugins-good-0.10.8 I gst-plugins-ugly-0.10.8 I gst-python-0.10.11 I gstreamer-0.10.19 [zlatko@disclosure]:~$ The symptoms are the same as above, hanging after "Pipeline is PREROLLING ..." until I interrupt it: [zlatko@disclosure]:~$ gst-launch-0.10 --verbose playbin uri=file:///home/zlatko/mp3/mp3/tiamat/the_sleeping_beauty__live_in_israel/01__in_a_dream.mp3 Setting pipeline to PAUSED ... /playbin0/decodebin0/typefind.src: caps = application/x-id3 Pipeline is PREROLLING ... ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... /playbin0/decodebin0/wavparse0.src: caps = NULL /playbin0/decodebin0/id3demux0.src: caps = NULL /playbin0/decodebin0/typefind.src: caps = NULL FREEING pipeline ... [zlatko@disclosure]:~$ I'll attach the gzipped debug log as well.
Created attachment 111628 [details] debug log
The question in comment #2, whether this issue still exists on more recent versions, has been answered in comment #3: It does. Thus reopening.
Somehow wavparse is involved in this file and it thinks the file is 0 bytes long. Can you provide this file (or the first MB or so) ?
No, unfortunately not - I've replaced it with OGG some time ago. OTOH, I can't remember having seen this problem ever since then in Rhythmbox. Currently installed versions: [zlatko@disclosure]:~$ stowes list gst.*10 rhythm Listing packages in /usr/local/stow matching [ gst.*10, rhythm ] (12 matches): I clutter-gst-0.10.0 I gst-ffmpeg-0.10.9 I gst-plugins-bad-0.10.17 I gst-plugins-base-0.10.25 I gst-plugins-good-0.10.17 I gst-plugins-ugly-0.10.13 I gst-python-0.10.17 I gst-rtsp-0.10.4 I gstreamer-0.10.25 I gstreamermm-0.10.5.2 I pidgin-rhythmbox-2.0 I rhythmbox-0.12.6
I'm closing as INCOMPLETE then. Please reopen if you have any news.