GNOME Bugzilla – Bug 329194
[gnomevfssrc] emusic.com previews don't work
Last modified: 2006-02-21 19:32:20 UTC
Steps to reproduce: Open any emusic preview URL in Totem for example: http://www.emusic.com/samples/m3u/song/10870399/13464647.m3u Or the direct link from inside the m3u file in playbin like for example: http://dl.emusic.com/s/ZYG-vB7l1gYRnQDE2EdrOH29wYDAOVl-5P1MJOSUu7-9g7PFfTsRwOmraNe0K_v7x7Dzm3n_oCu-iDnOkPYDy200/10870399/13464647/Destroy_Everything_You_Touch.mp3 Stack trace: I am attaching a log file of playbin with -v and one GST_DEBUG=*:5 to this bug report. Other information:
Created attachment 58387 [details] -v log from playbin
GST_DEBUG log available here: http://www.linuxrising.com/files/playbin2.txt.bz2
Christian, does it segfault? Hang? Give you a nice error? What does the user see in totem?
The user get a message saying 'Internal Data flow error'
Created attachment 58809 [details] [review] possible fix for gnomevfssrc I think this is gnomevfssrc falsely erroring out instead of EOSing out. With the above patch the behaviour is better, but still not perfect (totem sometimes just stays in 'Playing' mode at 0:30, sometimes it goes correctly into 'Paused' mode at 0:30).
I tried using the neonhttpsrc. From the command line it seems to work correctly (unlike gnomevfssrc (without this patch)), but I am unable to get it working with Totem atm. Having some trouble compiling core atm., and I need a new core to update plugins-base.
The hang/weird EOS behaviour in totem is fixed now as well in totem CVS. Can't test with an up-to-date neonhttpsrc, as my neon version isn't recent enough, but it works with gnomevfssrc where it didn't before. Was a totem issue anyway.