Playlists: show #EXTM3U text?

[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: [Select]

#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

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]

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

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).

[7o9]

... 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 ...

You have some reasonable arguments in your second and third post. Much better than calling the people you need to address your concerns 'daft'.

Parsing the #EXTM3U would be more efficient than reading metadata from each file, that makes sense.

But reading the metadata already works and exists so in that sense adding the parsing of the #EXTM3U data is more work, not in the last place because that patch does not work yet.

I also think many more people have metadata in files than #EXTM3U info in their playlists, but that is mostly a feeling. Having both options would be good, no argument there.

[Frankenpod]

I also think many more people have metadata in files than #EXTM3U info in their playlists, but that is mostly a feeling. Having both options would be good, no argument there.

I dunno, that data is in all my playlists, as exported from mediamonkey.  I suspect any media manager will have the option to include it in exported playlists. 

[raffraffraff]

Much better than calling the people you need to address your concerns 'daft'.

I don't know where you got that idea. You're taking offense on behalf of people who I did not offend - because as far as I know, nobody ever made the suggestion to source playlist viewer data from ID3 tags. I was simply prefacing my feature request with my opinion that it would be a daft idea to use tags if #EXTM3U data was already loaded in memory.

EDIT: Never mind, I re-read my post and it wasn't 100% clear that I was talking about using ID3 tags for this specific purpose.

[amachronic]

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.

If / when you get it working, I'd be happy to merge this. Just seeing the filename has always bugged me! BTW, it's quite easy to push patches to gerrit - you can sign in with github, then you just have to add your public key. More info if you are interested: https://www.rockbox.org/wiki/UsingGit.

The option to use the database is not a bad idea. If you have the database loaded to RAM then you have the information in memory anyway, just like with extm3u. I agree it'd be horrifically slow if you're just using the on-disk database, or tried to read it directly from the files.