Playlists do not handle \r or mixed newline formats

Bug #181553 reported by mdmcginn on 2008-01-09
14
Affects Status Importance Assigned to Milestone
totem-pl-parser
Fix Released
Low
totem-pl-parser (Ubuntu)
Low
Ubuntu Desktop Bugs
Nominated for Jaunty by Robert Ancell

Bug Description

Binary package hint: totem

When I edit an M3u playlist in gedit 2.20.3, specifically by rearranging the songs by cutting and pasting lines within the file, I get messages such as, "Totem could not play 'File://home/michael/Music/ws.letbelight.h.mp3 /home/michael/Music/bach-bwv852a-grant.mp3'." I'm editing a file that I originally created in Windows Notepad on Windows XP. If I use Notepad through WINE to edit the file, I don't have any problems. If I type the playlist directly into gedit. it also works. I wonder if the problem comes when some lines end with CR/LF and some with LF. The working file is at http://biographiks.com/totem-bug-2.m3u and the non-working file is at http://biographiks.com/totem-bug.m3u I'm using Totem Movie Player 2.20.0 using xine-lib version 1.1.7 and GNOME

ProblemType: Bug
Architecture: amd64
Date: Wed Jan 9 10:54:53 2008
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/totem
NonfreeKernelModules: nvidia
Package: totem-xine 2.20.0-0ubuntu3
PackageArchitecture: amd64
ProcCmdline: totem file:///home/michael/Desktop/Classical.m3u
ProcCwd: /home/michael
ProcEnviron:
 PATH=/home/michael/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: totem
Uname: Linux chesed 2.6.22-14-generic #1 SMP Tue Dec 18 05:28:27 UTC 2007 x86_64 GNU/Linux

mdmcginn (mcweb) wrote :
mdmcginn (mcweb) wrote :

My sample links were wrong: instead of m3 they should be m3u.

description: updated
mdmcginn (mcweb) on 2008-01-09
description: updated
Pedro Villavicencio (pedro) wrote :

Thanks for the report, can you attach that playlist to the report for testing with it? thanks.

Changed in totem:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
mdmcginn (mcweb) wrote :
mdmcginn (mcweb) wrote :
Pedro Villavicencio (pedro) wrote :

Thanks, it seems that the file is somewhat broken the second line said "/home/michael/Music/bach-bwv852a-grant.mp3^M" that's why totem didn't catch up the file, i don't think it's a totem bug rather a broken file, thanks.

Changed in totem:
status: Incomplete → Invalid
mdmcginn (mcweb) wrote :

 If there were a recognized standard for m3u files, you could say that an m3u file was broken. But since there is no official standard, it's hard to say that a file doesn't meet the standard. I think that Totem should be able to read any plain-text list of music files, separated by carriage returns and/or line feeds. The files were created with basic plain-text editing software. I don't think we can open a bug on gedit or Windows Notepad, since they seem to be doing what they're supposed to do. The mp3 files aren't broken, in case you were wondering. See http://hanna.pyxidis.org/tech/m3u.html for more about the adhoc m3u format.

mdmcginn (mcweb) wrote :

Changing status back to Incomplete, since the m3u file is as valid as any file can be that has no standard to meet.

Changed in totem:
status: Invalid → Incomplete
mdmcginn (mcweb) wrote :
Pedro Villavicencio (pedro) wrote :

May you take a look with "vi" to that file? There's an extra ^M on the 6 line remove that character and it should work, can you test that? thanks.

mdmcginn (mcweb) wrote :

Yes, it does work. But I believe that Totem should work on all m3u files created using Windows Notepad or gedit. It shouldn't be necessary to use vi to edit them. Can Totem ignore that extra ^M?

Pedro Villavicencio (pedro) wrote :

to be send upstream by someone interested on it, for forwarding instructions please take a look to https://wiki.ubuntu.com/Bugs/Upstream/GNOME ; leaving this as incomplete until it gets forwarded, thanks.

Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

Changed in totem:
status: Incomplete → Invalid
Fred Reiss (frr42) wrote :

Please reopen this bug!

Many Internet radio stations change servers frequently, and the the only way to get an updated server list is to download an m3u or .pls file. When I want to listen to internet radio, it's a real pain to have to download a playlist file, open it up in a text editor, and change the carriage returns to newlines.

The cause of the problem appears to be in totem-pl-parser/plparse/totem-pl-parser-pls.c, lines 161 to 167:

 /* figure out whether we're a unix pls or dos pls */
 if (strstr(contents,"\x0d") == NULL) {
  split_char = "\n";
 } else {
  split_char = "\x0d\n";
  dos_mode = TRUE;
 }
 lines = g_strsplit (contents, split_char, 0);

This if statement should have a third branch to account for files that use \r as a line separator.

Robert Ancell (robert-ancell) wrote :

Fred - have you experienced an Internet radio station that uses '\r' as newline separators? Totem supports '\r\n' (DOS) or '\n' (Unix) as line separators.
mdmcgin - the issue you are experiencing is you have mixed newline characters in the playlist file - this is not a valid DOS or Unix text file. Have you experienced a server sending files like this? I do however agree with lack of a spec Totem should be able to handle these cases as ^M is not a valid filename character.

affects: totem (Ubuntu) → totem-pl-parser (Ubuntu)
Changed in totem-pl-parser (Ubuntu):
status: Invalid → Triaged
summary: - Totem ignores LF in Windows m3u playlists but not CR/LF
+ Playlists do not handle unexpected whitespace
summary: - Playlists do not handle unexpected whitespace
+ Playlists do not handle \r or mixed newline format
summary: - Playlists do not handle \r or mixed newline format
+ Playlists do not handle \r or mixed newline formats
Changed in totem-pl-parser:
status: Unknown → New
Fred Reiss (frr42) wrote :

Yes, it looks like bug 307492 describes the same problem as this one.

FYI, the specific stations that I've had problems with were:
http://smoothlounge.com/streams/smoothlounge_128.pls
http://smoothlounge.com/streams/smoothlounge_64.pls

These stations appear to be run by the same folks that run smoothjazz.com.

Changed in totem-pl-parser (Ubuntu):
status: Triaged → In Progress
Robert Ancell (robert-ancell) wrote :

Fixed upstream

Changed in totem-pl-parser (Ubuntu):
status: In Progress → Fix Released
Changed in totem-pl-parser (Ubuntu):
status: Fix Released → Fix Committed
Robert Ancell (robert-ancell) wrote :

Patch now in SRU in bug 372602

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package totem-pl-parser - 2.26.2-0ubuntu1

---------------
totem-pl-parser (2.26.2-0ubuntu1) karmic; urgency=low

  * New upstream release (LP: #372602)
    - Fix video/mp4 files played from YouTube showing "get_video" as the video
      name (LP: #346661)
  * debian/patches/20_handle_playlist_newlines.patch
    - Handle various newline formats in playlists (LP: #181553)

 -- Robert Ancell <email address hidden> Wed, 06 May 2009 12:09:58 +0200

Changed in totem-pl-parser (Ubuntu):
status: Fix Committed → Fix Released
Changed in totem-pl-parser:
status: New → Fix Released
Changed in totem-pl-parser:
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.