[regression] nautilus/totem no longer recognises '.m3u' files

I can confirm this bug. It happens on my computer too.

Note that the URIs of the files might simply be file names:

Song One.ogg
Song Two.ogg
Song Three.ogg

Rhythmbox is also broken.

1) Choose Music/Playlist/Load from file...
2) Navigate to a .m3u file and choose Open.

RESULT:
no files are imported.

EXPECT:
playlist to be imported.

Note that if you manually drag each song from Nautilus and drop it onto
Rhythmbox, you can build a Rhythmbox playlist by hand. This is not a great
workaround but at least it's something.

Thanks for your comments Steve, but this is a slightly unrelated issue. If you
care about these changes to be made, could you please file them as an extra bug
report?

the m3u files has to use "#EXTM3U", that's NOTABUG

The 'EXT' stands for 'Extended' and denotes an extension to the normal "format".
 m3u itself is just a "simple list of files/URLS" (aka a playlist) and does not
have the extra metadata that extm3u adds, hidden in the comment lines:

  http://www.schworak.com/programming/music/playlist_m3u.asp

I have not yet come across a downloadable playlist link that has contained this
information. As there appear to be more 'normal' m3u files than ones containing
extensions I would like to reopen this bug.

basically a m3u is a plain text file, the mime detection works with some special
pattern, want do you suggest for this one?

The only thing that makes a text file different from a playlist is the extension
'.m3u'.

Logically, if it smells like a text file and looks like it has the extension
'.m3u', then there seems to be no reason to disagree that it probably /is/ an
'.m3u' file.

(The crucial bit being 'disagree'---I don't think there should be an error
message unless it can be positively identified using MIME matching as something
that is /not/ a text file).

I have experienced this problem as well and am curious to know what additional
information is needed to confirm this bug.

the mimesystem doesn't care about the filename to get the type, that's why a
.m3u without the "#EXTM3U" is not distinct of some text

Raising the priority as this is a regression and there's no other way to easily mark it.

This upload fixes the issue:

 shared-mime-info (0.17-0ubuntu3) dapper; urgency=low
 .
   * debian/patches/090_cvs_fixes_multimedia.patch:
     - CVS fixes for .qtl, .wmv, .wma
   * debian/patches/100_m3u_fix.patch:
     - make .m3u listed correctly and not as text (Ubuntu: #23272)