Playlist file size is limited to 1024bytes.

[dex3]

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.

[piratejon]

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.

[ib]

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?

[piratejon]

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

[piratejon]

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.

[piratejon]

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

[piratejon]

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.

[ib]

output from playing the playlists

[ib]

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

Are you running Linux or Windows?

[piratejon]

issue present in old release

[piratejon]

issue no longer present in current

[piratejon]

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!