EXTM3U format support?

[polygonal]

I have half a mind to try my hand on adding extm3u support to existing playlist code (that is if I can figure out most of it out before college starts again...) . Extm3u should be a much more elegant solution to display track title instead of filename in playlist viewer, and should provide a way to find out how long a playlist is and how much time is left in the playlist without opening each file. Given the structure of extm3u file, effects on non-extm3u user should be very little to none since extm3u writes extra info in comments.

So I want to find out:
1. Is this feature actually wanted? I don't know how many people actually use extm3u format. (basically normal m3u file with extra information....)
2. What do the core devs think about the idea of this? (i.e. this is just unnecessary? or this is probably nice if nicely implemented?)
3. Has anyone tried anything similar so that I can steal something ;P

[bluebrother]

1. Is this feature actually wanted? I don't know how many people actually use extm3u format. (basically normal m3u file with extra information....)

I don't think it's bloat as it adds functionality without breaking anything or removing compatibility. So while I don't really need that feature I think it would be a nice addition.

2. What do the core devs think about the idea of this? (i.e. this is just unnecessary? or this is probably nice if nicely implemented?)

IMO it would be nice -- there was discussion about that and iirc there is also a task about that in the tracker. Not sure how easy that would be to find ...

3. Has anyone tried anything similar so that I can steal something ;P

not that I know of -- at least not for Rockbox.

[Bagder]

I don't know the specifics of the 'extm3u' format, but beware of the fact that rockbox doesn't load the entire m3u into ram and the dynamic treatment of it also adds a fair share of complexity to the code....

So, I'm just saying that it is probably going to be slightly harder to add support for than what you imagine before you read the code!

[polygonal]

I don't know the specifics of the 'extm3u' format, but beware of the fact that rockbox doesn't load the entire m3u into ram and the dynamic treatment of it also adds a fair share of complexity to the code....

So, I'm just saying that it is probably going to be slightly harder to add support for than what you imagine before you read the code!

I won't post this before I tried to decode the playlist code a bit In the beginning I won't bother with the dynamic playlist; I'll support extm3u for existing playlists only at first. Extm3u is actually a very easy format; all it does is adding useful information as comments in the existing m3u format. The current playlist code is well suited for my purpose, since the playlist file parser already ignores the comment lines (lines starting with #). The only thing I need to do is add a new function to read a line from the m3u file backward from a specified index stored in playlist->indices, and call the function when the playlist viewer requests the filename info, etc. I'm not sure if I make sense or not, but I'll give it a shot.

[soap]

...should provide a way to find out how long a playlist is and how much time is left in the playlist without opening each file.

I was not aware EXTM3U provided a way to do such a thing.  As a user I find that information the ONE thing I miss on my WPS.

[Llorean]

It offers a length, in seconds, for each song, so if you parsed the whole playlist and summed it you'd know how much remained.

[polygonal]

Initial patch FS#7652. Very basic functionality for now; only works for existing playlists that are already in EXTM3U format.

I was not aware EXTM3U provided a way to do such a thing.  As a user I find that information the ONE thing I miss on my WPS.

I still don't know how to implement this though. I could  add an array of all track lengths to the current playlist structure, but that can takes up a lots of space... Parse the playlist file every time the playlist remaining time is requested is plainly too inelegant.  And of course, I need to figure out how to fit the EXTM3U scheme into dynamic playlist before this is even possible; otherwise it will only work for existing playlists.

And a question for all: Is saving playlist in EXTM3U format functionality in Rockbox a good idea? If database is ready, the information needed is only a function call away (and this functionality should be disabled if database is not ready or user specifies otherwise in settings).

[polygonal]

EXTM3U definitely does not fit into the current control file / dynamic playlist format; and IMO modifying the current scheme for such a trifle does not worth it. There are other ways to find out remaining time in a playlist, but those probably have nothing to do with the EXTM3U format anyway. I wrote a (buggy but mostly working) patch for myself that calls the database for track title when viewing playlist, so that eliminate my initial need for EXTM3U.

I still think support of EXTM3U format is nice though since it is (sort of) standard. The patch FS7652 I think works but needs quite a bit of cleaning up as I read through it again. So I'll probably improve it and keep it in sync if I have time, and add functionality to save EXTM3U or a plugin to convert normal m3u to EXTM3U if I have still more time, but for now I'm switching myself back to study mode and pack up for college dorm

EDIT: Getting titles from the database is really slow on my ipod... I was tricked because it was fast on the simulator. Maybe EXTM3U is still the way to go.

[Exitao]

I would certainly like to know who this works for you.  

In fact, aside from encouragement (that's the only way I think I'm qualified to help), my biggest reason to replay is to sucbscribe to this thread.

So I hope you post back when you have any information.

[Febs]

my biggest reason to replay is to sucbscribe to this thread.

You do not need to reply to the thread to subscribe.  Just use the "notify" button at the top of the thread.

[Exitao]

Doh!

I thought that was to "notify" mods if the thread aws bad.   Apologies andThanks!

[AlexP]

Doh!

I thought that was to "notify" mods if the thread aws bad.

That'd be the report to moderator button!  

[polygonal]

I would certainly like to know who this works for you.  

In fact, aside from encouragement (that's the only way I think I'm qualified to help), my biggest reason to replay is to sucbscribe to this thread.

So I hope you post back when you have any information.

Also, it's probably a better idea to subscribe/watch the flyspray task rather than watching this thread, since when I submit an updated patch there, there is really no reason for me to keep replying myself on this thread.

[mikeage]

I also tried reading the database (course it was tagcache back then)

http://www.rockbox.org/tracker/task/6084

The performance was abysmal. Never found a good way to improve it... my patch died due to a lack of interest and way to proceed... I hope you can do better

[polygonal]

I also tried reading the database (course it was tagcache back then)

http://www.rockbox.org/tracker/task/6084

The performance was abysmal. Never found a good way to improve it... my patch died due to a lack of interest and way to proceed... I hope you can do better

Yeah, I don't know why the tagcache searches for known filenames are so slow. I can think of a much faster way to deal with this, but it is much more complicated:

1. If a playlist is not dynamic (already existing), then try to display title only if the playlist is EXTM3U
2. If a playlist is dynamic:
     1. if initiated from filebrowser, set up a tagcache search based on a "containing" clause of the dir name and retrieve the entries, which should be fast since the current database tagtree works this way and it is quite fast.
     2. if initiated from database, use the same tagcache search used by tagtree to retrieve needed information.
And for both ways I need to figure out where to put the information - either save a temp file in EXTM3U format for the dynamic playlist or save the tagcache search struct inside the playlist struct.

But I need in depth reading of both the tagcache and playlist code first, and I probably won't have much time at this moment....