Rockbox Development > Feature Ideas
Save downscaled album art in database as cache
saratoga:
Apple converts the image files on the PC before copying them to the device, which is what's recommended when using rockbox too. If you want to look into doing it on device I suppose you could save an additional .bmp of the resized image and then skip the jpeg version on subsequent loads. Since you can't save as jpeg it's a little less efficient but the resized images would be small anyway.
Yakov5776:
--- Quote from: saratoga on December 27, 2024, 12:38:48 AM ---I suppose you could save an additional .bmp of the resized image and then skip the jpeg version on subsequent loads. Since you can't save as jpeg it's a little less efficient but the resized images would be small anyway.
--- End quote ---
Yeah, I started messing with the source to implement this functionality but it isn't very straightforward. buffering.c:load_image is where the AA image finally gets parsed and formatted in bmp format, but unfortunately, id3 data is already lost at that point and i don't have any other ideal way of caching the albumart bmp to a file name which can correspond with the album and artist name.
I already have logic to load that bmp cache filename if it exists before attempting to load the embedded art but I'm not so satisfied with the way it's being checked.
--- Code: ---/* Check if a cached BMP file exists within the .rockbox directory
*
* id3 - metadata of the current track.
* buf - buffer to store the path of the cached BMP file.
* buflen - size of the buffer.
*
* Return true if a cached BMP file is found, false otherwise.
*/
bool check_cached_bmp(const struct mp3entry *id3, char *buf, int buflen)
{
char path[MAX_PATH + 11]; /* need room for filename and null termination */
const char *artist = id3->albumartist != NULL ? id3->albumartist : id3->artist;
if (!id3 || !buf || !artist || !id3->album)
return false;
snprintf(path, sizeof(path), ROCKBOX_DIR "/albumart/cache/%s-%s.bmp",
artist, id3->album);
printf("Path: %s\n", path);
if (file_exists(path))
{
strmemccpy(buf, path, buflen);
logf("Cached album art found: %s", path);
return true;
}
return false;
}
--- End code ---
This is what I got so far and an integration with the database would be a lot better and possibly more efficient in terms of storing and indexing cached album art.
Any pointers would be appreciated. (Be easy on me, this is the first time I've worked on a vast open-source C codebase like this one)
Also on a side note: I was wondering why album art loading can't be done while the song is playing, why does it wait for that to load before it can actually start playing? It does load the default album art before loading the embedded one so you should assume that the embedded one would load on a separate thread from actual playback.
saratoga:
Album art already has an ordered list of places to look on load. You just need to add one more location, wherever you cache the resized file. Then if the cached item is there, it will be loaded, if not it will continue down the list as normal.
The database is a system for generating playlists from file tags. Since album art doesn't really relate to playlists, it doesn't make sense to tie this to the database. Just make one cached item per file or per folder and you can use the existing load logic to pick the cached item when available.
Yakov5776:
--- Quote from: saratoga on January 01, 2025, 11:46:41 AM ---Album art already has an ordered list of places to look on load. You just need to add one more location, wherever you cache the resized file. Then if the cached item is there, it will be loaded, if not it will continue down the list as normal.
--- End quote ---
That's a good idea, although it should be an opt-in/opt-out situation so users have the choice to use album caches, as this may not be ideal for users who have a lot of albums and already have fast loading album arts and therefore the caches are redundant, I was thinking maybe there should be some dimensions qualifier before it gets stored.
--- Quote from: saratoga on January 01, 2025, 11:46:41 AM ---The database is a system for generating playlists from file tags. Since album art doesn't really relate to playlists, it doesn't make sense to tie this to the database. Just make one cached item per file or per folder and you can use the existing load logic to pick the cached item when available.
--- End quote ---
That's true, but the database system was modulized in a way where you could add other processes to the procedure and it doesn't have to be strictly limited to just indexing file tags.
In fact, I think it's more befitting to cache album arts while the database is indexing so then you don't don't have to play your whole music library before you have subsequent caches for any large album arts.
saratoga:
I think you should get your caching system working first and then think about how you want to rework other systems.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version