handle_playlist_entry_cb() doesn't handle the non-URI paths coming from .m3u playlists
Submitted by Brian J. Murrell
Link to original bug (#608046)
Description
As mentioned on the ML, even on master, the parsing of M3U playlists seems defective. Here's what I've discovered:
In parsing the playlist, an instance of totem_pl_parser_new() is created and given the RB function handle_playlist_entry_cb() as the callback to handle entries from the playlist:
g_signal_connect (parser,
"entry-parsed", G_CALLBACK (handle_playlist_entry_cb),
source);
handle_playlist_entry_cb() is defined as:
static void handle_playlist_entry_cb (TotemPlParser *playlist, const char *uri, GHashTable *metadata, RBGenericPlayerPlaylistSource *source)
and that's where things go awry. It would seem that argument 2 is not always a URI (method://path/...), especially when given the playlist entries from an M3U file, which are bare pathnames.
The problem is that the stack of functions executed on "uri" from handle_playlist_entry_cb() down the call-stack all assume that uri is an actual URI and the stack ends up in default_uri_from_playlist_uri()->rb_uri_append_uri() which tries to execute g_file_new_for_uri() on this "uri". Of course it fails because it's not actually a URI. I would think that for a simple pathname, rb_uri_append_path() in fact needs to be used.
Indeed, with the following patch, parsing M3U lists works. It's an obvious hack though and I'm not quite sure where in your API you feel that this difference might fit though.
diff --git a/plugins/generic-player/rb-generic-player-source.c b/plugins/generic index 13acd33..4c7b4cc 100644 --- a/plugins/generic-player/rb-generic-player-source.c +++ b/plugins/generic-player/rb-generic-player-source.c @@ -599,7 +599,7 @@ default_uri_from_playlist_uri (RBGenericPlayerSource *source return g_strdup (uri); }
-
full_uri = rb_uri_append_uri (mount_uri, uri);
-
full_uri = rb_uri_append_path (mount_uri, uri); g_free (mount_uri); rb_debug ("%s => %s", uri, full_uri);
Version: HEAD