Make playlists use the database info of a song instead of its file name

[nezzled]

Hello! I would like to sync music with iTunes to use both Rockbox and the default iTunes firm, but because iTunes makes gibberish file names it would make navigating playlists annoying. Is there a way to make them use the embedded tags/database info instead of their file names? I know I can technically work around this by renaming them but I would prefer to do it the other way.

[Bilgus]

the problem here is playlists are independent of the database system and looking up the tag info for each file would likely make it slow but I'll look into it

[Bilgus]

Here is the first try at a patch that does this
ATM it reads every file from disk which is only when you are in the viewer OFC

https://gerrit.rockbox.org/r/c/rockbox/+/5807

if you let me know what device I can get you a build to try

Updated a bit:
this thing would be pretty slow with large playlists on a slow disk
in that case hopefully you are loading your database to RAM
and this will take advantage of it to speed up the access

[Bilgus]

This is now in the latest dev version

[Bilgus]

After optimizing this for a while and getting it working decently with on disk playlists its so terribly slow when trying to view the current playlist I might as well just remove it alltogether

[Frankenpod]

Seems to work acceptably for me (7th gen ipod, flash modded, database loaded to ram). 

As most of my files are named according to the content anyway, it's not really a huge difference, but just tried it on some that are only named "track01" "track02" etc, and it seems to work and playlists appear in perfectly acceptable time.  It's useful for such tracks that I ripped a bit too lazily.  As it's a user-selectable option I'd vote for keeping it.

Possibly I haven't tried it on sufficiently long playlists though?

(I'm assuming this is the thing that comes under general settings/playlists/playlist viewer settings/"Track display")

[Bilgus]

the main issue I have with this is all the things I have to do to make it work (decently) for anyone else

for instance, making the number of tracks buffered [lower] makes the wait acceptable on first load but it quickly makes scrolling annoying
fix that by keeping track of how long we took to load and start tweaking how many we load per chunk

track search uses the same settings and now they do different things, time for setting flags or yet another setting

IDK I gave it a try I feel that this will cause more issues than its worth, I would only consider enabling the option if the playlist was already in ram
try looking at that playlist on first boot before its in ram bet you won't like the wait

I think I'd rather give you a way to add tags to playlist or something

[Frankenpod]

Fair enough, your decision.  Maybe the performance depends on the target (available RAM?).  Plus I haven't tried any particularly long playlists.

Could it be done so it can only be selected if the database is successfully cached in RAM?

[Bilgus]

I'm testing with playlist containing 10000+ tracks and yes the available ram makes all the difference in the world

I really don't like adding a bunch of specialized code if I can help it its hard to keep up with

ATM I think the way forward is to support EXTM3u

chris_s found a FS patch that has most of what I want already
https://www.rockbox.org/tracker/task/7652

Give me a few days the current patch needs updated and I've already identified a few issues to work thru

after I get that working I'll work on a plugin to allow conversion between the two types

[Frankenpod]

To be honest, it's possible I've misunderstood this thing entirely.

  Just tried it on a playlist of podcasts (only about 150 entries), and I don't actually include podcasts in the database (podcast directory has a 'database.ignore' file in it), yet it still seems to work.

  The podcast file names are different from the titles (because I downsample them to lower bitrates and rename them to save space on the ipod) so it's definitely showing the title tag rather than the file name in the 'current playlist' display, if I select that option in the settings. As that's not in the database I don't actually understand how it's doing that.

[Bilgus]

what the [removed] patch does is parses/reads the metadata from the file directly on disk if the db is not in-ram or if it doesn't find the track

what I'm likely going to do is allow extended m3u playlists so the data is in the playlist and then you only have to look at one (much smaller/denser) file

the other option is to make cue sheets and read the data from those (similar idea but separate files)

[Bilgus]

so two options:
First: use exm3U files
advantages:
    single file
    only generated once
    new playlist can be stored in the format
    playlist searches become much more versatile
   most of the code is already in FS
disadvantages:
    not backwards compatible (plugin to convert between the two)
    slower to parse
   
Second: use cue sheets (db of track info per playlist)
advantages:
    doesn't touch the playlist (backwards compatible)
    most of the code is already in RB
   
disadvantages:
    clunky (you need to keep track of two files and they might diverge)
    need to generate the cue sheet before using

[Frankenpod]

Well, I've no preference between those two. 

When you say 'not backwards compatible', you mean in relation to any existing playlists people have already created on the player itself?

 I mostly have playlists exported from media monkey, and they are all extended format anyway.  Playlists created on the player are just temporary as far as I'm concerned, so I wouldn't, myself, be bothered about keeping compatibility in that regard.  Maybe other users would, though.

[Bilgus]

not backwards compatible as in if a playlist is made with the latest it woldn't work on older versions (3.15 for instance)
like I said thats not such a concern but still a disadvantage

are you able to use those exm3u playlist in rb directly as a regular playlist? if so then thats great and I think ill move forward with option 1

[Frankenpod]

Not at home, so can't check to see what exactly I set media monkey to export.  But looking at the playlists I have on the player in a text editor, they start with #EXTM3U

and have entries like

#EXTINF:230, R.E.M. - Finest Worksong
..\Music\R.E.M\Document\01 Finest Worksong.mp3

So I assume those are exm3U playlists?  And RB doesn't seem to have any problems with them.