GNOME Bugzilla – Bug 662909
banshee won't open playlist first time, but the second
Last modified: 2012-03-25 07:38:40 UTC
Originally reported at: https://bugs.launchpad.net/bugs/759339 Binary package hint: banshee I've got the ugly codecs installed. But when I go to open the .pls file that soma.fm spits out, nothing happens! If I add it manually and try to listen to the feed, it doesn't work. But upon trying to listen to it a second time, suddenly it plays. Obviously it supports it, it just isn't processing the metadata correctly and getting to playing the stream the first time around. Definitely not working correctly, this is a bug. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: banshee 2.0.0-1ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic x86_64 NonfreeKernelModules: nvidia Architecture: amd64 Date: Tue Apr 12 19:56:19 2011 InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110330) ProcEnviron: LANGUAGE=en_CA:en LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: banshee UpgradeStatus: Upgraded to natty on 2011-04-09 (3 days ago)
What do you mean with "Needs 2.1?". The version you chose for the bug is 2.2.0. Changing the summary because this may be a more generic problem, as reported in http://permalink.gmane.org/gmane.comp.gnome.mono.banshee/12010 Can we have some debug logs attached please?
Here is some debug output showing the problem, starting from when I attempted to load CBC Radio Two Classical and it failed, and finishing when I loaded it again and it worked. [20 Warn 12:05:35.841] CBC - CBC Radio Two Classical (on CBC Radio Two Classical) <00:00:00> [<unknown>] - System.Net.WebException: The request timed out (in `System') at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0 at System.Net.HttpWebRequest.GetResponse () [0x00000] in <filename unknown>:0 at Banshee.Playlists.Formats.PlaylistParser.Parse (Hyena.SafeUri uri) [0x00000] in <filename unknown>:0 at Banshee.Streaming.RadioTrackInfo.LoadStreamUri (System.String uri) [0x00000] in <filename unknown>:0 [20 Debug 12:05:36.012] Starting - Saving Metadata to File [25 Debug 12:05:36.019] Finished - Saving Metadata to File [1 Debug 12:05:49.637] (libbanshee:player) bp_stop: setting state to GST_STATE_NULL [26 Debug 12:05:49.791] Starting - Saving Metadata to File [27 Debug 12:05:49.798] Finished - Saving Metadata to File [20 Debug 12:05:49.964] Parsed 3 URIs out of CBC - CBC Radio Two Classical (on CBC Radio Two Classical) <00:00:00> [<unknown>] [20 Debug 12:05:50.036] Playing Radio Stream - http://1651.live.streamtheworld.com/CBC_R2_CLASS_H_SC [20 Debug 12:05:50.038] Player state change: Idle -> Loading [1 Debug 12:05:52.389] Player state change: Loading -> Loaded [1 Debug 12:05:52.395] (libbanshee:player) [gapless] Triggering track-change signal [1 Debug 12:05:52.396] (libbanshee:player) [gapless] Triggering track-change signal [1 Debug 12:05:52.410] Player state change: Loaded -> Playing [1 Debug 12:05:52.429] Creating Pango.Layout, configuring Cairo.Context [1 Debug 12:05:52.429] Creating Pango.Layout, configuring Cairo.Context [1 Debug 12:05:53.423] TrackInfoDisplay RenderAnimation: 32.00 FPS
any news for this issues?
Update: A few Banshee updates ago, around the beginning of December, it seemed like the issue was solved. Banshee was connecting to radio streams immediately. However, in the last week, the problem has returned, and is now worse. Radio streams fail to connect two, three, even four times, before finally connecting. I hope this bug is fixed soon. Thanks. Also, I notice that this bug status is "need info". What other info is needed?
Created attachment 210316 [details] [review] small patch Hi, It is not a patch but a file to replace because I have not git on this pc. So, here is a file to replace: src/Core/Banshee.Services/Banshee.Playlists.Formats/PlaylistParser.cs It will add a retry system with 5 attempts. Banshee are not reponssible for missconnect to web link but at least, we can try several time.
Created attachment 210317 [details] [review] retry system on playlist typo correction
Hey Olivier, is that difficult to install git in that system? Don't make this difficult to review please :)
to be honest I done it at work so I have no access. I will post a patch tonight and test it on my pc.
For the record, there's portable git[1] which can be used without administrative access. [1] http://code.google.com/p/msysgit/
Created attachment 210382 [details] [review] internet playlist retry system oki here is a real patch PS: thansk for the tips with git
Created attachment 210383 [details] [review] retry system for internet playlist
Comment on attachment 210383 [details] [review] retry system for internet playlist Thanks for the patch ! I've committed a modified version: - Only try 3 times, and sleep for one second between each try - You need to recreate the request, just calling GetResponse again doesn't work, as the request is marked as canceled.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Why Thread.Sleep 1 second whereas timeout is ever set to 5 seconds so you have 6 second between each attempt? if you want so increase httpWebRequest timeout is enough... Imo, we can remove this Thread.Sleep And my previous code recreate a webrequest each time... so do not understand why you said that I call getResponse on the same. anyway, happy that you commit that!
(In reply to comment #14) > Why Thread.Sleep 1 second whereas timeout is ever set to 5 seconds so you have > 6 second between each attempt? if you want so increase httpWebRequest timeout > is enough... Imo, we can remove this Thread.Sleep Yeah, that Sleep is probably overkill, I just wanted to give the server some time to "recover" from the request. > And my previous code recreate a webrequest each time... so do not understand > why you said that I call getResponse on the same. Oh, right, I first re-worked the patch to replace the recursive call by a loop, but then I forgot about that change. It is my change which caused the WebRequest to not be re-created. Sorry about the confusion.
ok fine, it is just to understand how to improve my coding skills because I was thinking this patch was good to go without any modification. loop and recursive call is just a mater of taste.