Opened 10 years ago

Closed 9 years ago

#2225 closed defect (worksforme)

Playlist file size is limited to 1024bytes.

Reported by: dex3 Owned by: beastd
Priority: normal Component: core
Version: HEAD Severity: normal
Keywords: playlist Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: yes

Description

Summary of the bug:
Mplayer reads only 1024 bytes of playlist file specified by "-playlist" option.

How to reproduce:
Just create playlist file and give it a try, press ">" several times to trigger bug.

Attachments (6)

playlist2225.txt (1.2 KB ) - added by piratejon 9 years ago.
This playlist is 1,200 bytes and illustrates the issue described in mplayer ticket 2225.
playlist2225-b.txt (2.0 KB ) - added by piratejon 9 years ago.
This playlist is 2,047 bytes and causes mplayer to fail to play the media file whose name spans the 1,024th byte.
playlist2225-c.txt (2.0 KB ) - added by piratejon 9 years ago.
This playlist, at 2,048 bytes, is identical to the previous 2,047 byte file, with the addition of a single carriage return. mplayer successfully plays all the lines in this file.
playlists.log (14.8 KB ) - added by ib 9 years ago.
output from playing the playlists
r37379.log (13.3 KB ) - added by piratejon 9 years ago.
issue present in old release
SVN-r37610-5.3.0.log (15.1 KB ) - added by piratejon 9 years ago.
issue no longer present in current

Download all attachments as: .zip

Change History (12)

comment:1 by piratejon, 9 years ago

I believe I have observed this issue as well. I am running SVN-r37379. I have a 1,085-byte playlist in which I noticed the last file would not play. mplayer indicated it could not open the file but only gave the first few characters of its name. After ensuring I could play the file on its own (i.e. media file is probably not corrupt) I changed the order of the playlist and observed the file previously in the last position, now in the second to last, would play ok, but the file now in the last position would not play, due to mplayer trying to fetch it only by the first few characters. I looked at a hex dump of the playlist and observed mplayer was ignoring all the bytes after 1,023, hence the unexpectedly shortened last filename. My Rust friends might gloat if they could understand what was happening, but I cast void pointers with pride while they are hoarse from arguing with a "borrow checker". I figured mplayer could not have gotten along as long as it has with only 1KiB playlist support, so I doubled the playlist file length by appending it to itself, to see what would happen, and at 2,170 bytes mplayer was able to play any file in the playlist including the last file. I chopped off the last couple files from the doubled playlist (now 2,044 bytes), and mplayer once again only acknowledges the first 1,023 bytes of playlist text. I renamed some files and tried some more examples to conclude that mplayer ignores bytes after the 1,023rd when there are fewer than 2,048 in total. n Therefore I would amend the steps to reproduce as:

  1. prepare a playlist containing between 1,024 and 2,047 bytes (inclusive).
  2. play the playlist: $ mplayer -playlist playlist.txt

Expected result: all the files in the playlist are played in order

Actual result: mplayer attempts to fetch the last file by only whatever of its bytes come before 1,024 and fails.

comment:2 by ib, 9 years ago

Actually, there is no limitation in the length of the playlist file (besides memory).

Could you please provide a playlist sample (attach file) that doesn't work?

by piratejon, 9 years ago

Attachment: playlist2225.txt added

This playlist is 1,200 bytes and illustrates the issue described in mplayer ticket 2225.

comment:3 by piratejon, 9 years ago

Thank you for your inquiry. I have attached the file as requested. This file is 1,200 bytes. The first 25 media files play just fine. When mplayer tries to advance to the 26th line, it fails. The 26th line is "0000000000000000000000000000000025.flac". mplayer should try to play it but instead tries to play "00000000000000000000000", which is upto the 1,023rd byte of the file, as explained in my prior comment. I understand there may not be an explicit upper limit on the playlist size. For playlists between 1,024 and 2,047 bytes, any bytes after 1,023 are ignored. A workaround for such playlists is to make them longer by adding bytes to get over 2,047 bytes. Attached, a playlist (playlist2225-b.txt) with the first 26 lines and newlines until 2,047 bytes, illustrates the same issue. A similar playlist (playlist2225-c.txt) with the first 26 lines and newlines until 2,048 bytes, does not exhibit the issue.

by piratejon, 9 years ago

Attachment: playlist2225-b.txt added

This playlist is 2,047 bytes and causes mplayer to fail to play the media file whose name spans the 1,024th byte.

by piratejon, 9 years ago

Attachment: playlist2225-c.txt added

This playlist, at 2,048 bytes, is identical to the previous 2,047 byte file, with the addition of a single carriage return. mplayer successfully plays all the lines in this file.

by ib, 9 years ago

Attachment: playlists.log added

output from playing the playlists

comment:4 by ib, 9 years ago

I can't reproduce (see playlists.log).

Are you running Linux or Windows?

by piratejon, 9 years ago

Attachment: r37379.log added

issue present in old release

by piratejon, 9 years ago

Attachment: SVN-r37610-5.3.0.log added

issue no longer present in current

comment:5 by piratejon, 9 years ago

It was my mistake to not try it on the newest release first. I uploaded the log so you did not think I am crazy, but it does seem now to be fixed. Thanks!

comment:6 by ib, 9 years ago

Analyzed by developer: set
Resolution: worksforme
Status: newclosed
Note: See TracTickets for help on using tickets.