GNOME Bugzilla – Bug 559654
tuning in to last.fm only works randomly
Last modified: 2009-02-27 16:02:07 UTC
Please describe the problem: Quite often you have to close and restart banshee for last.fm to work. It will always get the data for the overview page, but quite often no actual tracks for any station. Steps to reproduce: 1. Start banshee on os x 2. Check if the last.fm part will get tracks for a station and play them 3. if not, close and restart till it does Actual results: Sometime last.fm stations work, sometimes not. Expected results: That tuning into a station and playing stuff works more reliably. Does this happen every time? Not 100%, but very often. Other information:
The problem appears to be in 'Media.Playlists.Xspf/Playlist.cs::DefaultBaseUri'. When running from a bundle on OSX, System.Environment.CurrentDirectory is '/', and not the assembly path. Therefore, playlist parsing fails and songs are not added to the lastfm/radio playlists. It seems to me that relying on CurrentDirectory to point to the assembly path is incorrect and we should be using the following instead? System.Reflection.Assembly.GetEntryAssembly().Location;
*** Bug 559653 has been marked as a duplicate of this bug. ***
Created attachment 123397 [details] [review] Don't use Environment.CurrentDirectory to determine base uri. This patch removes the use of Environment.CurrentDirectory to determine the base uri in Playlist.cs. I'm not sure why the base uri is required for Xspf parsing, but when running from a bundle on OSX the CurrentDirectory is '/' which leads to an InvalidUri exception during parsing. Relying instead on System.Reflection to determine the base uri fixes this issue.
Huh, I'm not sure why either of the CurrentDirectory or the GetEntryAssembly().Location are there at all. When would their values ever be useful? Seems like the default_base_uri should just be null. Does that make sense? If so, can you test it, make sure things still work?
It looks like DefaultBaseUri is used in cases where the base document doesn't contain an 'xml:base' attribute. An instantiated Uri object must always be valid, therefore setting DefaultBaseUri to null isn't possible. So, what's required here is setting DefaultbaseUri to a valid URI. In some cases Environment.CurrentDirectory is not valid, so we need something else. I guess the assembly path is always going to be valid? Why not just hardcode it to something sensible?
Created attachment 125371 [details] Test app demonstrating the issue. This app tunes a lastfm station and creates an Xspf playlist from the result. This shows how setting Xspf.Playlist.DefaultBaseUri to Environment.CurrentDirectory breaks on OSX when running from a bundle. Compile and run as follows to simulate running from a bundle: pushd / && mono --debug /path/to/PlaylistTest.exe [lastfm-username] [lastfm-password] && popd
Created attachment 125372 [details] This is the playlist recieved from lastfm in the above test app.
http://www.xspf.org/xspf-v1.html#rfc.section.6.2 explains the rules for relative uris in xspf
Having looked at the XSPF docs, base_uri is required but not contained in the response from last.fm. So we can either use: 1) 'The base URI is the URI used to retrieve the entity.' or; 2) 'The base URI is defined by the context of the application.' We're currently using option 2, i.e. defaulting to Environment.CurrentDirectory.. which is not guaranteed to be a valid URI. So, in the case where option 2 fails, can we use option 1 and just set it to the original URI?
Created attachment 129545 [details] [review] Patch: If creating the default base uri using the cwd fails, default to Location.
Looks fine, please commit.