Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: deadbeef +album art +disable caching of thumbnails (Read 3332 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

deadbeef +album art +disable caching of thumbnails

i am curious to know if album art caching in deadbeef can be disabled, so there is no more thumbnails generated, while album art is still active and shown?

Re: deadbeef +album art +disable caching of thumbnails

Reply #1 –
So you want it to open and read your music files every time you scroll through the playlist or wherever there is album art to display?

Re: deadbeef +album art +disable caching of thumbnails

Reply #2 –
Quote from: kode54 on
So you want it to open and read your music files every time you scroll through the playlist or wherever there is album art to display?

Some artwork is already stored locally in files and it makes little sense to copy them to another location and then attempt to keep track of when that location becomes stale. On the other hand, artwork may also be found from web locations, and not cache would be a problem.  Or not, different solutions work best on different platforms and with different configurations. Loading hundreds or thousands of thumbnails over the internet every time you open an app isn't good, but loading a single image each time a track changes could be done without a cache.

Work is in progress to allow cache-less artwork, but it isn't in the current release version. You might try to compile the latest dev version but possibly not very stable right this second. I'm not even 100% sure what the eventual "cache-less" behaviour is going to be, but certainly moving in the direction you're looking for.

Re: deadbeef +album art +disable caching of thumbnails

Reply #3 –
Meanwhile, foobar2000, at least with the mobile version, is already using an album artwork cache, which includes pre-scaling the images to the requested sizes and adding them into the cache. Problems already happen when some piece of code doesn't request a large enough size for the screen real estate covered, yet sometimes also problems are encountered where too many large images are cached and the app runs out of memory and crashes.

Re: deadbeef +album art +disable caching of thumbnails

Reply #4 –
Quote from: kode54 on
So you want it to open and read your music files every time you scroll through the playlist or wherever there is album art to display?
exactly, even if it may be a bit slow to resize large images occasionally.

@lithopsian: thank you for answering.

this is good news, really looking forward to the new version of deadbeef.

indeed, cache-less album art is what i am looking for. especially when folder.jpgs are already present, there should be no need to copy them all over to another location.

i already tinkered with 'album art's' options in the hope of being able to turn off the caching, but lots of files were still populated in a quick manner (in the cache dir). so i went with album art completely disabled (for now) :(

Re: deadbeef +album art +disable caching of thumbnails

Reply #5 –
What about people who have their album art embedded, though? Wouldn't having to extract the covers cause visible delays? Even more so for people with music library on a network share.

Re: deadbeef +album art +disable caching of thumbnails

Reply #6 –
I'm not talking occasionally. I'm talking reloading the artwork each time you scroll past a particular album in a playlist.

Re: deadbeef +album art +disable caching of thumbnails

Reply #7 –
Deadbeef currently has a fairly sophisticated internal pixmap caching system to reduce the need to go even as far as the disk cache for artwork during scrolling and resizing. While it is possible, indeed intended, to have thumbnail pixmaps evicted when they are not visible and the memory is needed for artwork that is visible, the in-memory cache is dynamically sized to avoid thrashing. In most cases this avoids any interrupts during scrolling or other changes to the visibility of images in the player. Resizing artwork in the playlist or artwork panel is done using the internal pixmaps and a high-quality version is only reloaded from the disk cache when resizing is complete.

So the need for cached artwork on disk has been much reduced since it was first written. The current work will reduce it even further so that most artwork can come direct from source. I hesitate to say "all" because I don't know if the disk cache will be entirely eliminated, but certainly it is being described as "cache-less". Sorry that I'm not more up to date with the exact details.