• Status Unconfirmed
  • Percent Complete
  • Task Type Patches
  • Category Playlists
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by polygonal - 2007-08-24

FS#7652 - EXTM3U support

EXTM3U is a format based on the standard m3u format. It adds a comment line before filename in .m3u or .m3u8 file in the format of
where xxx is track length in seconds, yyy is the title.

For more info, see:

Supporting EXTM3U format has several potential benefits:
1. Instead of displaying filenames, track title and length can easily be viewed when viewing playlist (currently I think there is a patch that does it by opening each file).
2. Length of playlist can be readily calculated by summing, which can have some interesting applications such as finding how much time is left in current playlist. (Currently this is not possible yet with this patch, but I’m still thinking of possible solutions).

Of course, you have to have playlists in EXTM3U format to get the benefits. There are widely available tools to generate EXTM3U or add information to existing normal m3u playlists. In the future I might add functionality to Rockbox to save EXTM3U playlists (only if database is enabled and ready) or a plugin.

The current patch is able to parse EXTM3U information and use it in playlist viewer. To see it work, you have to set your track display option in the playlist menu to display EXTM3U information; otherwise, filename will be displayed. Two display options are added: title only and title plus track length.

This patch should have very minimal impact on normal playlist usage. A parse function and a few booleans values to existing structures are added, but the parsed title and filename share the same buffer (since they won’t be displayed at the same time). Specifically, beside a quick initial reading of header to determine if a playlist is EXTM3U and a few boolean checks, current playlist parsing/viewing routines are not changed if playlist is not EXTM3U or EXTM3U information is not needed for display.

Enough of me babbling :D Here is the patch. I did some limited testing, so it probably is not foul-proof yet.

oop, found a bug:

it would be helpful if I actually attach the patch…

A few changes:

1. fixed an unclosed fd (I don't know why I opened a new fd in the first place…)
2. removed some unnecessary setting checks
3. added codepage conversion for non-m3u8/non-utf8 playlists
4. general code tidying - killed some tabs, fixed some ill-phrased/misleading comments, removed an unused pointer in a struct
5. sync'd the new lang ids to the end of the lang file

I think this patch does what it claims to do well enough; it is probably not very useful for people with no EXTM3U playlists, but it does/should not affect the speed, efficiency, etc. of current playlist reading/viewing for normal playlists.

I'm planning to write a plugin to convert normal playlists to EXTM3U, but that's only after I have the time to take a look at how plugins work.

jac0b commented on 2007-10-01 23:42


jac0b commented on 2007-10-18 22:52


jac0b commented on 2007-12-16 22:21


Thank you very much for this patch… this is very very useful, especially to complement the iPod to RockBox Playlist Converter.

I have tested this patch in my iPod Video 5G and it works perfectly.

debar commented on 2008-01-11 04:09

Is this patch out of date? I applied it to the most recent SVN and I do not see the option to change the track display to extm3u information in the playlist menu.

Did you get hunk errors while patching? Did you see the usual options (like full path or just filename)?

debar commented on 2008-01-11 13:21

The only hunk errors I got were for the english.lang file, which I manually appended. I now realize that I was looking in the wrong menu for the setting. This patch is okay other than the english.lang file, which is easy to manually fix. Thanks.

I think the patch is broken. Starting from number 10, the track numbers mess up. Check out the attached image.

Does the index numbers mess up with the options in SVN (like filename only)? I don't think I changed anything about the indexes… Can others confirm this behavior?

Forget it, I just noticed the patch was applied partly. I got no hunk errors too. Weird.

Thanks for your reply though.

I just installed Rockbox on my Ipod and wish this patch were included with the build. I don't have an environment or the experience to patch and recompile under Windows Vista.

sharn commented on 2008-02-12 14:45

This fixes a patch error on the english.lang file for current versions in SVN

Looking at this patch and what I was doing with, it seems to me we could update the control file format to include the track and artist info after the filename if we are using EXTM3U playlists. With it present in the control file, we can extract it on the display and we can use it to output EXTM3U directly from the player.

sharn commented on 2008-02-20 14:54

I found a couple of issues with this patch.

1) with a large playlist (~2500 entries), viewing the playlist adds a lot of lag to scrolling and viewing. It noticeably and significantly worse than viewing a playlist without the patch and without EXTM3U data. I assume this is because EXTM3U data effectively doubles the size of the playlist file that rockbox must read into memory and manage.

I also fixed and made some changes to FS6084 which extracts tag data at the time you view the list and was surprised to find that it does not introduce scroll lag in the playlist view as compared to no patch (viewing filenames or full path). Of the three approaches, EXTM3U patch, FS6084 fixed patch, and no patch, EXTM3U performed the worst on my player (Ipod 5.5 30G) and FS6084 and no patch having no discernable scroll lag difference with a largish list (~2500 entries)

2) Upon reboot of the player, the EXTM3U data is not present. You must go and reload the playlist from the playlist file to get it displayed. This is because rockbox uses the control file to reconstruct the playlist on restart. the control file format does not currently include the EXTM3U data so it is not reloaded.

I did make a patch to make "save playlist" save the playlist in EXTM3U format if the user has already selected one of the EXTM3U view options for the playlist viewer. It extracts that tag data and puts the header and EXTM3U formatting in the playlist_save function. I didn't spend time figuring out how to calculate the time data and just put a bogus value just to get it to work. once I saw the performance issues noted in 1 while scrolling large EXTM3U playlists, I didn't spend any more time with it. I can provide the patch if someone is curious though i would expect the above 2 issues are more critical to repair for eventual inclusion in RB.

Hi, please feel free to improve this patch since the much dreaded carpal tunnel syndrome is preventing me from typing too much (and certainly from doing any type of programming…). As for your two issues:

1) I don't understand why that happened (but then I never have any playlist that is larger than 50 or so). However, your assumption about "EXTM3U data effectively doubles the size of the playlist file that rockbox must read into memory and manage" is false because this patch actually reads EXTM3U data into the filename buffer (i.e. overwriting the filename buffer) and only an extra int for the track length since I made the assumption that filename and extm3u data will never be displayed at the same time. So the memory usage should be about the same unless there is bugs in the patch. I did, however, use twice the MAX_PATH for formatting purpose, so that might cause some overhead? You can probably try replacing all the MAX_PATH*2 to just MAX_PATH and see if the performance improves or not. It should not be a big deal though, since only very, very, very long extm3u data will become truncated because of this change.

Also, make sure you are testing in same enviroment: if there happens to be some audio buffering going on while you are viewing the playlist, then it would not be surprising that there are lags in scrolling.

2) That is because the playlist control file only records the names of the files in the playlist, not the playlist itself, so on restart, rockbox would take the content of the playlist control file as if it is a playlist created on-the-fly. I think modifying the control file to include tag data is a bad idea, but this behavior should be easily changed by somehow specifying the name of the playlist file in the playlist control file format, then rockbox can behave upon reboot as the same as the playlist is loaded again.

jac0b commented on 2008-05-07 01:35

Got hunk errors on this patch. I tried to figure it out but couldn't.

Hunk #10 FAILED at 603.
Hunk #13 FAILED at 836.
2 out of 14 hunks FAILED – saving rejects to file apps/playlist_viewer.c.rej

jac0b commented on 2008-05-21 00:14

I think I fixed it


Available keyboard shortcuts


Task Details

Task Editing