Rockbox Development > Starting Development and Compiling
Developed a new patch (ID3 tag data in playlist rather than filename) - now...
chiark:
Hi Folks
I've been using Rockbox since Monday, when I got my first iPod - the OEM UI is not bad, however the flexibility of RockBox is brilliant!
I'm impressed that Rockbox is able to work with iTunes-loaded music, however the filename obfuscation is frustrating when viewing playlists.
Apologies if this is the wrong place to ask - I realise it's not compiling related, but...
I've written a patch to playlist_viewer.c, specifically the format_name routine, that does the following:
- if the option to display full pathname is used, do the following check otherwise skip and just show the standard short filename
- compare the start of the filename with "/ipod_control" - if not, just use the filename otherwise:
- request information from the tagcache and use this as the playlist name. If this fails
- request information from the file's metadata, if this fails
- just use the filename
When the tagcache is not in RAM or the code drops into inspecting the file itself it's quite slow so should check that the tagcache is available.
Next step would be to modify the playlist options to allow the user to control whether to use the tagcache (or ID3) for all files, just for ipodcontrol files, or for none, and the format of the ID3-derived string as artist, album, track number etc could all be used.
Is this something that I should develop further as I think it's incredibly useful for people who do use iTunes...
Cheers,
Nick.
Llorean:
Wasn't there already a patch like this that was denied? Does yours offer a significant performance benefit over it?
chiark:
I've searched through for flyspray for playlist and id3 and couldn't see anything...
Performance isn't an issue providing the tagcache is in RAM it seems - when hitting the disk, it is slow though. I've tried to mitigate this by only applying the lookup to stuff in /ipod_control which is the only place it's absolutely needed.
On etiquette, is it OK to continue discussing this in this forum?
bluebrother:
There was a patch doing something similar by getting the information from the database. It has a major speed penalty though, and because of that it was rejected. Note that the default search on Flyspray doesn't look into tasks that are closed.
Also, restricting such a thing to /iPod_Control only doesn't make sense to me -- if such a feature gets in people will want to use it for e.g. other badly names files as well (and I bet user will want to be able customizing what information is displayed).
chiark:
Thanks for the info.
As long as the data is in the tag cache, the speed penalty on the ipod 5g that I've got is not noticeable. When it pulls the information from the disk, it's fairly painful.
As for ipodcontrol only, that was an idea to address the performance issue of reading from disk in a practical way - it's a good point though, this is something that is useful for all files providing there's no performance hit.
From debugging prints, it seemed that the format_name routine gets called twice for everything visible in the playlist: is there a reason for this, and could the second call be eliminated? Eliminating the double call out to tagcache or metadata would help for sure.
This is something that I'm finding useful as I'm using iTunes to load files on. If I stop doing that, I guess the issue goes away!
I'll develop it a little further to include a preferences section, and investigate the performance further.
Is there any simple way I can check at runtime that the tagcache is loaded into RAM?
Prefs could be amended to:
--- Code: ---
From To
Track Display Track Display
- Track Name Only - File name only
- Full Path - Full File Path
- Track name from ID3 (needs RAM tagcache)
- Track and Album from ID3 (needs RAM tagcache)
--- End code ---
I'll see if I can find the other patch...
Navigation
[0] Message Index
[#] Next page
Go to full version