Track titles in playlists

[chrisjj]

Apropos

a lot of developers consider Rockbox pretty much feature complete

does RB yet show track titles in (EDIT:) M3U playlists? This fairly basic feature is standard in all the DAPs' manufacture firmware I've seen for the last ten or so years, but I cannot find it in RB.

[saratoga]

I think playlists generated dynamically from the database can do this though, since the tags are parsed and stored in the DB you don't need to read the tags. 

From M3U would be hard though, I guess you'd have to check and see if the tags were in the database and show them.  Not sure if anyone has looked at that. 

[chrisjj]

I think playlists generated dynamically from the database can do this though

I was thinking of file playlists e.g. M3U. Sorry not to say. I have edited the original message to clarify.

From M3U would be hard though, I guess you'd have to check and see if the tags were in the database and show them.

I think you'd only need to read the tags from the files, with caching.

Not sure if anyone has looked at that.

I find this was implemented for RB in 2006. But apparently not officially adopted. I wonder why. From what remains of it (which sadly does not include the code - in SourceForge), it looked good.

[saratoga]

You can't read them from the files because the tags aren't necessarily available until the file is about to be decoded (because the current file may be large enough to occupy all available buffer memory preventing reading of the next file). 

[chrisjj]

An app can read the tag without reading the entire file.

[saratoga]

You can't read any of the file (tag or otherwise) until it has been buffered.  You can't random access files like on a PC, they're streamed in blocks roughly the size of the audio buffer (usually between a few hundred KB up to perhaps 55MB on a handful of devices with a lot of RAM).  So depending on the device and the bitrate you might be able to see the tags of the next file, but often not beyond that. 

Edit:  you may not realize this, but playlists aren't just lists of files that a user can show.  They're actually used to control what is streamed when the compressed audio buffer runs low.  Thats why everything from the database to the file browser always generates one when you start playback.  Theres no way to get the Nth file without first passing through the N-1 file.

[chrisjj]

You can't read any of the file (tag or otherwise) until it has been buffered.

An app can read the tag without buffering the whole file. I presume that's how the RB 2006 patch operated. Sadly since the SourceForge RB seems to have been wiped for some reason, we can't check the code.

playlists aren't just lists of files that a user can show.  ... Theres no way to get the Nth file without first passing through the N-1 file.

Makes you wonder how RB manages to play a one-file playlist, doesn't it?

[saratoga]

I don't think that patch you linked has anything to do with what you're suggesting. 

[chrisjj]

What that patch does is display tracks as metadata-derived names instead of raw filenames. This is what every modern DAP OF I have seen does, and is very much what I'm suggesting.

[saratoga]

Maybe I was unclear before, but the database can absolutely do that. 

[chrisjj]

the database can absolutely do that.

Not in playlists, AFAICT. Do please correct me if I am wrong.