totem no longer able to play m3u playlists

confirming, but if i open it with nautilus (double click on the m3u file) totem shows the content of it, but if i try to open the file with totem from the file menu it doesn't work and it shows the message "decodebin cannot decode plain text files" does the same happens to you?

For me, double-clicking in nautilus opens totem and produces the error "An error occurred GstDecodeBin: This appears to be a text file." The same happens with File>Open...
In both cases, the content of the m3u is not shown, only the filename of the m3u.

I can confirm this on my 64-bit system (latest Intrepid) as well. double-clicking and file->open both get me "Could not determine type of stream." Once I got the above mentioned "text file" error but cannot re-create it.

Console output :
** Message: Error: Could not determine type of stream.
gsttypefindelement.c(797): gst_type_find_element_activate (): /play/decodebin0/typefind

I have determined exactly what the playlists need to be interpreted properly! Adding "#EXTM3U" (no quotes of course) as the first line in the m3u playlist file causes totem to interpret it properly. Now, the strange thing is that the playlist files that totem writes don't have this required header. I happened to have one playlist that another program had written, and it did have this header.

I have attached a unified diff of the changes that I made to the totem-pl-parser source, file: totem-pl-parser-lines.c

This will make totem save playlists in a format that it can read (probably good). The other problem of making totem compatible with old-style m3u playlists I'll look into when I have time - someone who's actually a dev, please check this patch and let me know if it was acceptable or if it needed "cleaning up" to conform with coding standards. I'm trying to become a better coder but I don't know the ubuntu/debian standards at all. Also please comment on if this was a good way to submit a patch.

I have changed this bug to be for the totem-pl-parser package because I have found that this is where the bug actually lies.

thank you for your work on the issue, since you seem to have a good idea about the issue could you open the bug on bugzilla.gnome.org where the people writting the code will read it? an ubuntu bug triager could send the bug for you but that would not be efficient to discuss the changes

Sure. I'll see what happens.

Bug 551610 on bugzilla.gnome.org if anyone is interested.

thanks for sent it upstream, the fix was also committed there, thanks.

This is not the right fix.

http://bugzilla.gnome.org/show_bug.cgi?id=551610 is about fixing the code *writing* m3u to add the missing #EXTM3U header. So this is not about *reading* m3u. And worse, this is the wrong bug as EXTM3U is about Extended M3U playlists, while here, this is about simple M3U playlists.

See http://assistanttools.com/articles/m3u_playlist_format.shtml

this is working fine for me now with intrepid, can anybody else try? thanks.

I still have this problem, cannot play any livestreams with totem.

Whenever I play a livestream, I get

"An error occurred.
Failed to connect stream: Invalid argument"

It just worked for me. Totem was able to play a number of playlists/livestreams. Was this fixed in one of the updates?

I think what has been fixed is extended m3u files, i.e. files with a #EXTM3U header.

Unfortunately for me, it's far from satisfactory:

$ find . -name \*.m3u -exec grep EXTM3U {} \; | wc -l
10
$ find . -name \*.m3u | wc -l
248

4% while in hardy, they all play just fine.
The bug was initially reported by me with a clear way to reproduce, yet it is marked as fixed while it is obviously not. Re-opening.

I am currently able to play livestreams but it's a bit unstable: just had a complete system crash, had to reboot. The radio was playing "I wish I was a punk rocker" if that helps. :)
Cannot reproduce as that song is rarely played.

Haha, but I really had a complete system crash playing a live stream on totem.

I have tracked the (initial) bug down to totem_pl_parser_mime_type_from_data().

The m3u is first detected as audio/x-mpegurl (which is correct), then later on, it is detected as text/plain by g_content_type_guess() based on its content (which is correct too).

The problem is that text/plain is then tested only against a list of dual_types, not including m3u (which is in a list called special_types), so totem_pl_parser_mime_type_from_data() fails, making the url "unhandled" by totem-plparser. It is then passed by totem to gstreamer.

This should probably go upstream.

Linked to http://bugzilla.gnome.org/show_bug.cgi?id=556060

Confirmed fixed upstream.
Here is the debdiff attached.
Preview deb is in my PPA.

the bug has been fixed upstream now

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Fix in intrepid-proposed confirmed. .m3u files work fine.

Copied intrepid-proposed version to jaunty.

Copied to intrepid-updates.