GNOME Bugzilla – Bug 305150
faad plugin doesn't recognize end-of-song?
Last modified: 2005-06-09 15:58:28 UTC
Distribution/Version: Gentoo Using the gstreamer backend to amarok, .mp3 files work perfectly, but the end of an .m4a file is not recognized (amarok plays the song correctly but never goes on to the next one.) In the relevant bug in the amarok bugzilla, http://bugs.kde.org/show_bug.cgi?id=91181 the amarok developers indicate that this is a bug in the gstreamer plugin. I just upgraded to the 0.8.8.2 pre-release version of the plugin and am still seeing this problem.
I don't really know anything about gstreamer, but my primitive investigation suggests that the problem has to do with the way the "eos" event propagates. Amarok is listening for a signal from "decodebin0". In the .mp3 case, when the end of the song is reached, an "eos" is generated from the head of the pipeline ("filesrc3") and propagates through "decodebin0" which then generates the signal. In the .m4a case, the only "eos" signal I can see seems to be generated from "faad0" which is sitting partway down the pipeline, at the tail end of "decodebin0". Hence "decodebin0" never generates the signal that amarok wants. I am not sure how the system is _supposed_ to work, so not sure whether this bug is correctly filed. I'll attach debug output later -- bugzilla won't let me attach the one I have because it says it's too big.
The issue seems to be that the "eos" event generated by "faad0" causes all elements downstream from it in the pipeline to pause; as a result they stop requesting data. If they had continued requesting data, the object "filesrc3" at the head of the pipeline would have generated an "eos" itself; this is how it works when amarok plays an mp3 file. A possible fix therefore is to tell "faad0" not to produce an "eos" event; then it keeps requesting data and "filesrc3" then produces an "eos", which propagates down the pipeline as desired. In particular, all components of "decodebin0" then receive the event, and "decodebin0" then fires the signal for which amarok is listening. This fixes the problem for me; I'm not knowledgeable enough about gstreamer to know whether it might have any unwanted side effects, so I can't claim that it is the proper fix for the bug, but it at least seems to be a workaround. I'll attach a patch below.
Created attachment 46890 [details] [review] workaround for end-of-song problem playing .m4a files
This looks acceptable. Need to test it a bit more before applying, though... Thanks for the patch already.
Today I ran across an .m4a for which amarok can't detect the end even with that patch applied -- so it might not have been the right fix after all, sorry.
Can you attach one problematic file fixed by your fix and one more file still failing?
I am not sure if I can do that, because of copyright problems -- all the .m4a files I have are ones which I purchased from the iTunes music store and then stripped the encryption from. For whatever it's worth, I encountered this problem when playing _any_ .m4a file before applying the patch.
Nevermind then; I applied a different fix. Please test CVS and reopen if any file is still problematic. Attach one such file then, or send it privately.