GNOME Bugzilla – Bug 131306
Handle unsupported radio streams gracefully
Last modified: 2006-01-15 08:55:50 UTC
Is it possible to recognise and handle unsupported radio streams gracefully: Examples: 1) http://www.bbc.co.uk/6music/ram/dsatg2.ram - causes rb to hang when played 2) http://stream.servstream.com/ViewWeb/BBCRadio_music/Event/BBCRadio6.asx - brings up four error boxes each with the legend: "creating uri "mms://212.58.231.99/b3o6c011s3?digest=0140036b32wbh2psswmtG1CdsVM1bh57ahja4==BBCRadio_music" (Success)" (but does not hang rb)
Example 1 causes an outright crash thought the backtrace looks pretty unhelpful... any suggestions? backtrace for Example 1): (gdb) run Starting program: /usr/bin/rhythmbox [Thread debugging using libthread_db enabled] [New Thread -1084407136 (LWP 5429)] INFO ( 5429: 0) Initializing GStreamer Core Library version 0.6.3 INFO ( 5429: 0) CPU features: (c1c7fbff) MMX 3DNOW MMXEXT INFO ( 5429: 0) registry: loaded user_registry in 0.000228 seconds (/home/cy/.gstreamer/registry.xml) INFO ( 5429: 0) registry: loaded global_registry in 0.149927 seconds (/var/cache/gstreamer-0.6/registry.xml) [New Thread 27106224 (LWP 5430)] [New Thread 134085552 (LWP 5431)] [New Thread 91638704 (LWP 5432)] [New Thread 58702768 (LWP 5433)] [New Thread 117390256 (LWP 5434)] [New Thread 29207472 (LWP 5435)] Program exited with code 01. (gdb) thread apply all bt (gdb) backtrace for Example 2): (gdb) run Starting program: /usr/bin/rhythmbox [Thread debugging using libthread_db enabled] [New Thread -1084366176 (LWP 5264)] INFO ( 5264: 0) Initializing GStreamer Core Library version 0.6.3 INFO ( 5264: 0) CPU features: (c1c7fbff) MMX 3DNOW MMXEXT INFO ( 5264: 0) registry: loaded user_registry in 0.000229 seconds (/home/cy/.gstreamer/registry.xml) INFO ( 5264: 0) registry: loaded global_registry in 0.157594 seconds (/var/cache/gstreamer-0.6/registry.xml) [New Thread 25156528 (LWP 5265)] [New Thread 58702768 (LWP 5266)] [New Thread 69192624 (LWP 5267)] [New Thread 92158896 (LWP 5268)] [New Thread 130845616 (LWP 5269)] Entity: line 3: error: xmlParseEntityRef: expecting ';' /212.58.231.99/b3o5c011s2?digest=014006048211pO4Y9fmAp8/dNb3NYS2JXzUQg=&provider ^ Entity: line 4: error: xmlParseEntityRef: expecting ';' /212.58.231.99/b3o6c011s3?digest=0140060482XsHKkMz+/NvGOuf+CkMi7nP5bVI=&provider ^ Entity: line 3: error: xmlParseEntityRef: expecting ';' /212.58.231.99/b3o5c011s2?digest=014006048211pO4Y9fmAp8/dNb3NYS2JXzUQg=&provider ^ Entity: line 4: error: xmlParseEntityRef: expecting ';' /212.58.231.99/b3o6c011s3?digest=0140060482XsHKkMz+/NvGOuf+CkMi7nP5bVI=&provider ^ [New Thread 27257776 (LWP 5270)] Program exited normally.
For the example 1 problem, this is the same as Bug#156783, and it is an error in the stream description, not in rhythmbox. However, rhythmbox could handle this gracefully as other players do.
Bug #156783 describes similar issues.
This still occurs with cvs. The problem appears to be that error_cb is getting called with error=NULL. Adding "if (error == NULL) return;" will top the crashes, and display other errors. If passing the callback a NULL error of an okay thing for GStreamer to do (I'm not sure), then that should fix it - but if GStreamer shouldn't be doing that, we should file a bug against GStreamer. Backtrace with an assert checking for error=NULL
+ Trace 62065
I committed a small fix that should stop the error=NULL crash (the cause is fixed in gstreamer cvs).
Closing since the first problem is bug 156783, and the second one is fixed.