Support and General Use > User Interface and Voice

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

<< < (4/5) > >>

Bilgus:
Awesome, I already started messing with the cue sheets and I already see a few short comings in the existing viewer so it'll need some work.
- trying to load a entry currently it only supports a single file. nope it just doesn't allow multiple entries and files too AFAICT
- the buffer is not continuously filled like the playlist viewer so thats more code to write too (otherwise it limits the size)

and code or a plugin to generate them
I'm thinking of basically you feed it a playlist and it converts to a cue file

In option 1 feed it a playlist and if you have a setting enabled for extm3u it gets converted on the first save
but one thing is that both viewers take the plugin buffer as scratch space so making either viewer a plugin could make performance worse
and therefore I guess it depends on what results in the best performance with the least amount of code in core

ATM I'm thinking thats probably option 2 as this is unencumbered by the current playlist stuff, has relatively low overhead for the rest of us
and won't break much else if anything when I introduce a bug :)

I'm open to suggestions either way.

I envision a context menu item in the playlist viewer that states 'use as cue' which then loads the playlist file and writes the data from the metadata of the files themselves

after conversion when the playlist is selected again the .cue file with the same name is instead loaded in the cue viewer with the currently playing track selected (if it exists)
later you might have changed the playlist so you delete the .cue file your playlist reappears in the viewer and you can again generate a .cue file

nezzled:
I just noticed this post got some traction, sorry for not replying at all.
The cue sheets seem like a fine solution, from my limited knowledge of the topic sidecar files suck in theory but may be required considering the variance of the processing power of the platforms that rockbox runs on (although I assume you've already accounted for that)
In any case, I'm on fairly newish hardware so I'll test the patch you sent and see if it works well for me. Thanks!

nezzled:

--- Quote from: Bilgus on July 05, 2024, 05:16:33 PM ---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

--- End quote ---
This worked perfectly. I'm using a 6/7g with flashmodded storage so it's pretty speedy for me. I understand this likely won't make it into the actual rockbox build (at least in its current form) but for me this works wonderfully. Thank you so much!

iPodVT:
Sorry for not chiming in on this topic sooner.

My longtime solution to this problem has been to have two copies of my music library on my iPods:  one copy is synced directly from iTunes (with its cryptic file namings) and the other copy is a clone from the Mac's iTunes music library directory (~/Music/iTunes/iTunes Media/Music) to a directory at the root of my iPod's storage.  I have Rockbox build its database from only the cloned library directory.  When I make changes to the Mac's iTunes music library I use iTunes to update its synced copy of the library, and I use a Mac app called FreeFileSync to update the iPod's cloned copy of the library.  I also export my iTunes playlists and then process them with a Mac app called M3U8 Converter which resolves the issues I used to have with exported playlists whose pathnames contain diacriticals.  That app also has a built-in find/replace function which can simultaneously convert the playlists' Mac pathnames to the iPod's pathnames.

At some point I will reach the limit of the 256GB storage I have in my iPods - when I get there I will increase the storage in the iPods that have 64MB RAM, and abandon keeping an iTunes synced library on the iPods that are limited to 32MB RAM in order to avoid the eventual problem of exceeding the Apple firmware database's limitations.

Bilgus:
I've been stuck on this cue viewer for a few days now. So far I have it indexing the file and saving that to ram (or disk if necessary)

I think I'm going to load chunks of the desired metadata on the fly with the index to speed up file seeking within the cue sheet file

its still several steps but hopefully less time consuming than the hoops that IpodVT goes thru

Navigation

[0] Message Index

[#] Next page

[*] Previous page