GNOME Bugzilla – Bug 332390
[GstQueue/GstPad] queue pauses immediately when linked, playing musepack songs works only every second try
Last modified: 2006-04-10 20:09:20 UTC
Hi, when using musepackdec from plugins-bad 0.10.1 in rhythmbox or banshee it's only possible to play a file with every second try. The first time works, when restarting that song or changing to another one it skips fast through the song without playing anything and hangs at the end. When playing another song afterwards the game begins again This happens with all musepack files I tested. Bye
Ok, some new informations... When a song (no matter what format) was played before a musepack file it always fails. When a musepack file is played as the first song it works. When a musepack file failed to play and this one or another is played afterwards this one works.
And when seeking while it's skipping fast through the song it works again from the position where one seeks to
Ubuntu bug about it: https://launchpad.net/malone/bugs/32664
Ok, I've taken a look at the code and have some new informations... (btw, why doesn't latest totem and rhythmbox allow --gst-* parameters? would've been very nice...) First of all, there are 3 three small memleaks (at least from my understanding and comparing with mad). You can get a patch for them at http://slomosnail.de/~slomo/temp/gstmusepackdec.c.diff The broken behaviour can also be reproduced with totem by adding two songs to the playlist. The only difference here is, that it's possible in totem to restart one mpc song over and over again while it only worked every second time in banshee and rhythmbox. Also totem isn't skipping fast through the song judging from the slider but pauses. Everything else is exactly the same. When skipping through the song (or pausing in totem) the offset of GstBuffer *out is increasing fast in gst_musepackdec_loop() and is pushed to the pad. So I guess either the decoding yields broken samples or the pushing to the pad isn't propagated through the pipe. (sorry when my obversations aren't helpful or my conclusions are wrong, I don't know much about gstreamer internals)
Thank god this is observed by others as well. I was afraid that I broke something by using plugins-bad from CVS previously and plagued the Quod Libet developers with this here http://www.sacredchao.net/quodlibet/ticket/508 I cannot add more useful information, though :(
Apart from the fact, that untagged MPCs do in fact work here, of course :)
Nah, I can reproduce it, just haven't found time to get to the bottom of it yet. Interesting though ... are you saying this only ever happens with APE-tagged MPCs, but never ever happens with untagged MPCs, belshazzar?
With the proviso that I only tested on two mpc+cue-sheet images that I found laying around. I could of course try removing some tags again...
Gah, it's an (impossible?) adventure creating tagless mpcs on Linux. Had to resort to my virtual machine with Foobar2000. So, removing all tags doesn't work , but creating virgin mpcs doesn't reveal alternating skipping at all.
While I also get the problem only with tagged files (id3+ape or just ape, doesn't matter, haven't tried id3-only yet), at first glance this seems to be a problem in playbin or some state-change bug. The second instance of musepackdec gets a FLOW_NOT_LINKED return value when pushing the first buffer, so nothing ever reaches the sink in the second run (musepackdec as in CVS just ignores NOT_LINKED flows and keeps on going until it reaches the end of the file, but that's just a minor implementation glitch and doesn't make a difference). Why it only happens with musepack files though, and only with tagged ones, that I don't know (yet).
I've been seeing strange stuff too: 1- some songs finish about 3 seconds earlier than "predicted", and RB doesn't change to the next song: just stalls there; 2- some songs just don't play, I see the slider moving over the entire song in a few seconds My songs are all tagged, but don't ask me what kind of tagging, that's beyond my knowledge :P
You can create tagless Musepack files on with http://www.sacredchao.net/quodlibet/wiki/Development/Mutagen and the simple Python script "import mutagen.apev2; mutagen.apev2.delete(filename)". I'm still unable to reproduce this bug in Quod Libet, my Musepack files are playing back fine.
Joe, could you try playback in totem of your musepack files? just add two musepack files to the playlist... This only happens with the 0.10 version of the plugin btw It happens for me for files with only APE2 tags and for files with ID3 and APE2 tags (I don't have something else). When removing the APE2 tags I don't have this problem anymore and everything plays fine.
With a build of Totem using GStreamer 0.10, I can reproduce the bug. However, I still cannot reproduce it in Rhythmbox 0.9.3.1, nor Quod Libet SVN. I'm using GStreamer 0.10.3, -good 0.10.2, and -bad 0.10.1, and the same (tagged) files for all three.
Comparison points on current Ubuntu Dapper: (1) Quod Libet 0.18 silently reads through entire musepack files (without audibly playing) in a couple seconds and fails to segue correctly; (2) Totem (using Gst) plays single files from its playlist correctly (but fails to segue correctly); (3) gst-launch plays single files correctly. Tagged files, Gst 0.10.3, -good 0.10.2, and -bad 0.10.1 are used.
(In reply to comment #15) > (1) Quod Libet 0.18 silently reads through entire musepack files (without > audibly playing) in a couple seconds and fails to segue correctly; I would make sure your volume is turned up, and that Quod Libet is using the correct soundcard, because this is an entirely new symptom. I suspect it's playing out of an onboard card or something, and is really just behaving like Totem.
(In reply to comment #16) > I would make sure your volume is turned up, and that Quod Libet is using the > correct soundcard, because this is an entirely new symptom. I suspect it's > playing out of an onboard card or something, and is really just behaving like > Totem. ...only a four-minute musepack file should not elapse in three seconds in QL 0.18. This seems to be the symptom Tim-Philip describes above. Seeking to the beginning of the file allows that single file to play correctly, but QL 0.18 does not continue to the next musepack playlist item (identical to Totem).
Any new insights concerning this problem? Not being able to listen to my 555 sonatas for harpsichord inhibits my analytical abilities...
In core/base 0.10.4 Musepack files play back properly in both Totem and Quod Libet for me (as opposed to 0.10.3 when they worked in Quod Libet but not Totem). Could this (or at least Sebastian and Belshazzar's problems; not sure about Daniel's) have been #323542?
At least in current Ubuntu Dapper[0], the same symptoms exist for totem-gstreamer (will play an mpc but will not continue to the next mpc) and quod libet 0.18 (will play an mpc after seeking to the beginning of it). [0] core/base 0.10.4, bad[Ubuntu multiverse] 0.10.1
Same as Daniel for me with totem. But in banshee it seems to work now... I'll try for some more time to see if it's really fixed ;) Same versions as Daniel have...
So, what kind of dark magic are you up to there, piman? Ubuntu has no noteworthy deltas for Gstreamer against Debian currently. libgstreamer0.10-0/unknown uptodate 0.10.4-1ubuntu1 gstreamer0.10-plugins-base/unknown uptodate 0.10.4-1ubuntu2 gstreamer0.10-plugins-good/unknown uptodate 0.10.2-2ubuntu2 gstreamer0.10-plugins-bad/unknown uptodate 0.10.1-0ubuntu1 gstreamer0.10-plugins-ugly/unknown uptodate 0.10.2-0ubuntu2 I even went to CVS HEAD and back, no change. And the playbin plays fine here. Can I even play a sequence there to see whether playback gets stuck? So it got EOS (end of stream?), what now? Note, that I never got that with vorbis like Chr. Schaller. And what role is the Glib supposed to here? $ gst-launch-0.10 playbin uri=file:///home/Le < >/01.mpc Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock3 Got EOS from element "playbin0". Execution ended after 89637110000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
yeah, it worked only one time for some reason... so yes, this bug is still there
I can still reproduce it with CVS of everything. It's some kind of race condition, probably in playbin/decodebin somewhere, haven't managed to track it down yet. FWIW, % GST_DEBUG=*:5 whateverapp 2>/dev/null makes things work just fine here that don't work otherwise (which is even more annoying because I can't get the full debug output of when it doesn't work right ...)
Created attachment 61456 [details] [review] patch for testing (HACK) against gst-plugins-base CVS If anyone here is running gst-plugins-base from CVS and able to reproduce the problem, it would be great if you could give the above patch a try if it fixes the problem for you too. It fixes the problem for me, but it's hard to say whether that's just coincidence or if it actually works. Note: this patch is just a quick hack to see if the problem is where I think it is. It most likely has unwanted side-effects or might even introduce other bugs. It's just to quickly test stuff.
Tim, this fixes it for me
Yes, confirming restored MPC playback at this stage.
Although the "fix" has some negative side effects like breaking typefinding in banshee ;) But it's definitely a start :)
How does it break typefinding? That is to say, what method is banshee using? The patch only changes stuff that uses playbin, which seems like a strange thing for a typefinding mechanism to be using. I'd be interested in seeing a debug log that captures the broken behaviour if anyone has one.
No idea why it didn't work back then... it works fine now with that patch... sorry :/ Maybe the nfs share where all my files are on was broken at that point and worked again after installing a version without the patch (banshee's typefinding uses "gnomevfssrc ! typefind", so no playbin in there)
I don't know if this is a similar bug but my issues with mpc playback in gstreamer-0.10 is pretty severe. I was checking out amarok last week and that was the first time I used gstreamer for playback on linux (always used foobar2000 in wine before). I initially thought it was amarok bug so I filed a report over there: http://bugs.kde.org/show_bug.cgi?id=123823 Basically gst gets stuck on a file when it gets to the end. In the process it also renders my computer unusable for minutes. I tried the patch in this thread to CVS and the issue is still there. This might be a new bug so I want some confirmations on it.
Created attachment 61713 [details] GST_DEBUG=*:4 log when it doesn't work (bzip2'ed) This is the *:4 log from when it doesn't work with a small test program that plays song 1 for a few second in playbin, then sets playbin to NULL and tries to play another song. Things go haywire in the READY => PAUSED state change, it never reaches PAUSE and musepackdec's task stops when it gets not-linked from downstream (only *:4, as things start working when I try with *:5).
This patch seems to break subtitles for me though (Matrix trailer from matroska samples download page).
I have similar symptoms as Tim. When I play MPC song in QL it's going well, but when it ends program starts to consume whole RAM and computer is almost unuseable. The song doesn't change to another one in playlist. Even when I manually change song to mp3, QL is still consuming whole RAM but computer is a bit faster. When I try to seek through the MPC song QL at once consumes whole RAM and PC is frozen (mouse can hardly move) until Out of Memory Killer does its job and kills QL. I have quodlibet 0.18, gst-plugins-musepack/bad 0.10.0 and gst-plugins-base 0.10.4
Moving to -base, as I think this is a playbin bug. FWIW, inserting a g_usleep (G_USEC_PER_SEC/2); or so in gst_musepackdec_sink_activate_pull() before gst_pad_start_task() makes things work reliably here as well (but is evil of course).
*** Bug 335869 has been marked as a duplicate of this bug. ***
Looks like a GstQueue and/or GstPad bug: 0x804d840 - 0:00:06.900252 gstqueue.c(448):gst_queue_link_src:<preroll_audio_src0> queue linking source pad 0x804d840 - 0:00:06.920517 gstqueue.c(458):gst_queue_link_src:<preroll_audio_src0> starting task as pad is linked 0x80e5460 - 0:00:06.920xyz gstqueue.c(769):gst_queue_push_one: pad peer: (nil) 0x80e5460 - 0:00:06.920974 gstqueue.c(785):gst_queue_push_one:<preroll_audio_src0> pausing queue, reason not-linked 0x804d840 - 0:00:06.921366 gstpad.c (1765):gst_pad_link: linked preroll_audio_src0:src and abin:sink, successful gst_pad_link() calls the link function before setting GST_PAD_PEER(srcpad), so it can happen that the gst_pad_push() from the task that the link function starts will find GST_PAD_PEER still to be NULL when it tries it. <wtay> we should probably set the peer before calling the link function, when it fails, we unset the peer again <wtay> or in queue start the task when the linked signal is called on the source pad
Created attachment 62984 [details] [review] set pad peers before calling link functions (and unset on failure)
2006-04-08 Tim-Philipp Müller <tim at centricular dot net> * gst/gstpad.c: (gst_pad_link): Must set peer pads before calling the link function, otherwise a task started from a link function might get a flow-not-linked result when trying to push because the other thread where the linking happens hasn't had a chance to set the peers yet. This might happen for example when a queue gets linked to a downstream element, as queue starts a streaming task when its source pad gets linked. Happens in real life when playing back flac/musepack files in playbin (#332390).
I can confirm that this patch fixes musepack playback when applied on 0.10.4... good work Tim... thanks :)