Support and General Use > Audio Playback, Database and Playlists

Playlists: show #EXTM3U text?

(1/2) > >>

raffraffraff:
About a month ago I revived a Shanling Q1 with Rockbox. Great! But I was kinda shocked to see playlists only show the track name. While sourcing artist + title from tracks metadata is obviously a daft idea on most devices, surely it isn't hard to show #EXTM3U data if it's already present in the file?


--- Code: ---#EXTINF:246,Soundgarden - Spoonman
\Music\Soundgarden\Superunknown\Spoonman.mp3
#EXTINF:309,The Who - Baba O'Riley
\Music\The Who\Who's Next\Baba O'Riley.mp3
#EXTINF:427,dEUS - Bad Timing
\Music\dEUS\Pocket Revolution\Bad Timing.mp3

--- End code ---

So, gimme everything after the comma! This feature requests was mentioned on the forum in 2006: https://forums.rockbox.org/index.php?topic=6438.0
Someone even pushed a patch for this back in 2007, but presumably the code has moved on significantly since then (or maybe not?): https://www.rockbox.org/tracker/task/7652

I'm surprised that more people don't want to see artist and track name in playlists

7o9:
Why is sourcing artist + title from tracks metadata a daft idea?

Track metadata seems an excellent source for this kind of information. You have dedicated metadata fields that are very convenient. #EXTM3U requires additional parsing.

Personally I do not see the value at all of having #EXTM3U data in playlist files.

raffraffraff:

--- Quote ---Why is sourcing artist + title from tracks metadata a daft idea?
--- End quote ---

Take this with a pinch of salt because I'm no rockbox expert. But the slowest component in pretty much any computer system is storage, even a computer with a super fast SSD. Disks are orders of magnitude slower than anything else. On my MP3 player, the SD card performance is gonna be terrible. Therefore my goal is to reduce disk IO as much as possible. Let's compare the two methods after we copy a new 1000 track playlist to a rockbox:

1. You load the .m3u file (100kb = 1000 tracks with #EXTM3U data). Now that it's in memory, you can parse it quickly in memory. The string you wish to show is right there above the file path.

2. You load the .m3u file (50kb = 1000 tracks without #EXTM3U data). Now it's in memory, but that's no good because you have to look up artist and title in the ID3 tags of every file in the playlist. You can try to load 1000 of them when the playlist is opened, or you could optimize it so you only perform lookups for the tracks shown on screen, and lazy-load the rest as you very slowly scroll. Bare in mind that you'll be hitting that crappy SD card with a lot of reads every time you open a playlist or scroll up and down. Each MP3 file is, what, at least 3mb in size? Again, you can probably optimize the file reads to grab the header data if it's positioned right at the start of the track. But you have to detect the type and version of each tag (eg: ID3v1, ID3v2.4 etc). So how is parsing ID3 tag data from each MP3 file any easier than parsing the plain-text "Artist - Title" string right out of the #EXTM3U text in the playlist (which is already in memory), aside from the disk IO overhead?

Perhaps there's some option to use the Rockbox Database. I personally don't bother with the database, so I don't know what its data structure is. But even still, you need to load the .m3u playlist and then perform database lookups for every track using the filename as a lookup key. Bare in mind that there may be some file path conversion to do, because the .m3u is probably using relative paths and the database may not. There may be a need to do some file path conversion (eg: changing delimiters from '\' to '/' or whatever)

raffraffraff:
For anyone else wondering, the 2007 patch that intended to bring EXTM3U data to the playlist viewer doesn't can't be applied directly to the latest Rockbox source code. But it's an amazingly simple thing to modify it to work - the surrounding code is practically unchanged in over 14 years! Unfortunately, the feature doesn't work, even after I enable it in the settings. I might dig in later to figure out why, since I've got the build tools and source code on my laptop. If anyone's interested in the patched source, I can push it to github.

For now I've changed my playlist view settings to show the full path. Not great, but better than nothing.

Frankenpod:
I think that option to show the full path (which will show you the artist/album, if your music is organised that way) was itself only added very recently.  At the time I thought that change would do what you originally asked about, but turned out it wasn't doing that.
I think I agree with your reasoning about using EXTINF vs tag information.  Be good if someone could get that patch working.  I'm not in a position to do anything with the rockbox code so all I can do is agree with you that it would be nice if someone else could do it!

(not only do I lack expertise but my linux machine is currently not in working condition).

Navigation

[0] Message Index

[#] Next page

Go to full version