GNOME Bugzilla – Bug 569175
Directly opening http audio stream makes totem hang 60s
Last modified: 2015-03-15 17:19:42 UTC
When I launch totem "http://mp3.streampower.be/stubru-high", totem hangs for some time (probably the 60 seconds timeout in the backtrace) before starting to play the audio stream. Replacing http by icy, works around this problem. Some backtraces while it's hanging: (gdb) thread apply all bt
+ Trace 211879
Looks like it's taking GVFS a while to get a response from the server, which is odd because it responded in a timely fashion for me. If you try to download from the URI using wget, what happens? This is probably a dupe of bug #559628 though, since the problem in Totem is just that adding to the playlist isn't async. *** This bug has been marked as a duplicate of 559628 ***
The problem is that it's trying to parse it as a playlist in the first place. Need to check what the playlist parser is doing actually.
Works fine here. The problem is likely to be in totem-pl-parser, though I failed to reproduce with totem-pl-parser 2.24.3 and the current trunk. Which versions of totem-pl-parser, libsoup, and gvfs are you using? libsoup-2.24.2.1-1.fc10.i386 gvfs-1.0.3-4.fc10.x86_64 $ time ./test-parser -d http://mp3.streampower.be/stubru-high ###################### parsing ################ _get_mime_type_for_name for 'http://mp3.streampower.be/stubru-high' returned 'application/octet-stream' URI 'http://mp3.streampower.be/stubru-high' was opened successfully in _get_mime_type_with_data _get_mime_type_with_data for 'http://mp3.streampower.be/stubru-high' returned NULL, ignoring URI 'http://mp3.streampower.be/stubru-high' unhandled real 0m2.366s user 0m0.034s sys 0m0.035s
I see this 60s time-out with both Totem 2.26.1 and Rhythmbox 0.12 now. In Totem, I can work-around the problem by using icy:// as protocol. This problem does not happen with http://mp3.streampower.be/mnm_hits-high.mp3, but it does with http://mp3.streampower.be/stubru-high, which are both hosted on the same server. Could the missing extension make a difference? $ rpm -qa totem rhythmbox gvfs *soup* *totem* *gstreamer*| sort gstreamer0.10-a52dec-0.10.11-1plf2009.1 gstreamer0.10-cdparanoia-0.10.22-3mdv2009.1 gstreamer0.10-debug-0.10.22-2mdv2009.1 gstreamer0.10-dts-0.10.11-3plf2009.1 gstreamer0.10-faac-0.10.11-3plf2009.1 gstreamer0.10-faad-0.10.11-3plf2009.1 gstreamer0.10-ffmpeg-0.10.7-1mdv2009.1 gstreamer0.10-flac-0.10.14-1mdv2009.1 gstreamer0.10-gnomevfs-0.10.22-3mdv2009.1 gstreamer0.10-mms-0.10.11-3plf2009.1 gstreamer0.10-musepack-0.10.11-3plf2009.1 gstreamer0.10-plugins-bad-0.10.11-3plf2009.1 gstreamer0.10-plugins-base-0.10.22-3mdv2009.1 gstreamer0.10-plugins-base-debug-0.10.22-3mdv2009.1 gstreamer0.10-plugins-good-0.10.14-1mdv2009.1 gstreamer0.10-plugins-ugly-0.10.11-1plf2009.1 gstreamer0.10-pulse-0.10.14-1mdv2009.1 gstreamer0.10-python-0.10.14-2mdv2009.1 gstreamer0.10-soup-0.10.14-1mdv2009.1 gstreamer0.10-tools-0.10.22-2mdv2009.1 gstreamer0.10-x264-0.10.11-3plf2009.1 gstreamer0.10-xvid-0.10.11-3plf2009.1 gvfs-1.2.2-1mdv2009.1 lib64baconvideowidget-gstreamer0-2.26.1-1mdv2009.1 lib64gstreamer0.10_0.10-0.10.22-2mdv2009.1 lib64gstreamer-plugins-base0.10-0.10.22-3mdv2009.1 lib64soup-2.4_1-2.26.1-1mdv2009.1 lib64totem-plparser12-2.26.1-1mdv2009.1 lib64totem-plparser-mini12-2.26.1-1mdv2009.1 rhythmbox-0.12.0-7mdv2009.1 totem-common-2.26.1-1mdv2009.1 totem-gstreamer-2.26.1-1mdv2009.1 totem-mozilla-2.26.1-1mdv2009.1 totem-pl-parser-i18n-2.26.1-1mdv2009.1
Sorry, I missed the fact that it was marked as a duplicate. Feel free to close it again if necessary.
(In reply to comment #5) > Sorry, I missed the fact that it was marked as a duplicate. Feel free to close > it again if necessary. > Bastien decided it wasn't a duplicate after all, so this bug remains open. :)
From IRC: <|Frederik> I'm discussing it on #nautilus. For me gvfs-cat http://mp3.streampower.be/stubru-high hangs too <|Frederik> thanks to help from #nautilus, I found that killall -9 gvfsd-http first, fixes the problem. There's probably a gvfsd bug somewhere So reassigning to gvfs.
killall -9 gvfsd-http fixes the issue. gvfsd-http might have become in a confused state because I installed some new gvfs versions and I always suspend/resume my system. I'll reopen in case this comes back and I have more information.
Reopening bug, I reproduced it and it has nothing to do with suspending/resuming the machine and/or updating gvfs. It happens out of the blue when listening with Rhythmbox to that audio stream. After a random time, the sound stops playing. From that moment on, when you try to play the same station, it will hit the 60s gvfs/dbus time-out, after which the playing really starts. I closed rhythmbox, and netstat shows that gvfsd-http is still connected with the remote server: tcp 65948 0 local-ip:55057 194.78.112.10:80 ESTABLISHED 7360/gvfsd-http This is what is going over that connections: # tcpdump -netttti eth0 -vv "port 80 and host mp3.streampower.be" tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 2009-04-16 09:40:26.171310 00:15:9b:18:12:0d > 00:21:70:ac:b0:8a, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 56, id 33341, offset 0, flags [DF], proto TCP (6), length 52) 194.78.112.10.80 > local-ip.55057: Flags [.], cksum 0x7e62 (correct), seq 2866546080, ack 3007618985, win 5792, options [nop,nop,TS val 1023715894 ecr 203178059], length 0 2009-04-16 09:40:26.171375 00:21:70:ac:b0:8a > 00:15:9b:18:12:0d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 47979, offset 0, flags [DF], proto TCP (6), length 52) local-ip.55057 > 194.78.112.10.80: Flags [.], cksum 0xe69e (correct), seq 1, ack 1, win 0, options [nop,nop,TS val 203298048 ecr 1023640547], length 0 2009-04-16 09:42:26.160940 00:15:9b:18:12:0d > 00:21:70:ac:b0:8a, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 56, id 33342, offset 0, flags [DF], proto TCP (6), length 52) 194.78.112.10.80 > local-ip.55057: Flags [.], cksum 0x7acb (correct), seq 0, ack 1, win 5792, options [nop,nop,TS val 1023727894 ecr 203298048], length 0 2009-04-16 09:42:26.161025 00:21:70:ac:b0:8a > 00:15:9b:18:12:0d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 47980, offset 0, flags [DF], proto TCP (6), length 52) local-ip.55057 > 194.78.112.10.80: Flags [.], cksum 0x11e7 (correct), seq 1, ack 1, win 0, options [nop,nop,TS val 203418038 ecr 1023640547], length 0 2009-04-16 09:44:26.151126 00:15:9b:18:12:0d > 00:21:70:ac:b0:8a, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 56, id 33343, offset 0, flags [DF], proto TCP (6), length 52) 194.78.112.10.80 > local-ip.55057: Flags [.], cksum 0x7733 (correct), seq 0, ack 1, win 5792, options [nop,nop,TS val 1023739894 ecr 203418038], length 0 2009-04-16 09:44:26.151224 00:21:70:ac:b0:8a > 00:15:9b:18:12:0d, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 47981, offset 0, flags [DF], proto TCP (6), length 52) local-ip.55057 > 194.78.112.10.80: Flags [.], cksum 0x3d2f (correct), seq 1, ack 1, win 0, options [nop,nop,TS val 203538028 ecr 1023640547], length 0 At that time gdb shows this for the gvfsd-httpd process: 87 int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout); (gdb) thread apply all bt
+ Trace 214498
Thread 1 (Thread 0x7fa95a1786f0 (LWP 7360))
I cannot reproduce this. Various stuff has changed since the original report (gdbus, port to SoupSession, etc.). Closing as obsolete.