getmusicbee.com

General => MusicBee Wishlist => Topic started by: euyep93 on March 09, 2021, 08:00:59 AM

Title: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 09, 2021, 08:00:59 AM
Frist of all, thank you to the author of the software, I love how musicbee works, or at least I did...

I use google drive for backup/sync, and want to keep musicbee on there so I can be up and running in the event of a restart etc.

Great, you offer a portable version!

However, I cannot stop it from reading the album art embedded in my mp3s and then converting to 524x524 24bit PNG's, often up to 1MB in size, for each of my 2000+ Albums and storing them in a subfolder. This results in over 3GB of, in my opinion, redundant PNG files that are taking up space on my SSD as well as my google drive.

I tried resizing the png's to 256x256 and optimising them, this did save 75% disk space on average, but I then found musicbee would insist on over-writing them with higher resolution images, even though it would initially load them and display them.

My music is stored on my high IOP nvme laptop drive,  I really doubt that it is worth caching these images?

IF the argument is to make scrolling through albums faster - it would be good to just have the option to have music bee read the cover image from the mp3/album each time. If the majority of us are OK with the loading and scrolling of web based music libraries, I cannot see that there is a strong argument for a loacl disk based cache of files on the same disk. it can only really save a few ms, cant it? especially with nvme drives.

But if you do insist, can you at least configure the cache to be stored in a temporary location so that it can ignored by backup/sync solutions easier? google drive sucks at excluding folders, but really I would just prefer it didnt exist at all.

PLEASE will you consider an option to disable the artwork cache for artwork already stored locally?
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: frankz on March 09, 2021, 01:11:10 PM
But if you do insist, can you at least configure the cache to be stored in a temporary location so that it can ignored by backup/sync solutions easier? google drive sucks at excluding folders, but really I would just prefer it didnt exist at all.

https://getmusicbee.com/forum/index.php?topic=19555.msg116994#msg116994
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 09, 2021, 05:24:38 PM
I'm pretty sure that google drive or any other backup solution will still back the files up. Thank you though.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: hiccup on March 09, 2021, 05:36:29 PM
Another approach could be this:

First create a copy of all the MusicBee folders that you want synced to Google, and then sync that location instead of the original one.
With a sync application such as SyncBackFree you can create such a copy at one mouse click, or automate it at a regular interval.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: sveakul on March 09, 2021, 07:57:49 PM
PLEASE will you consider an option to disable the artwork cache for artwork already stored locally?

+1 for the Wishlist request.  In the meantime, I clear the artwork cache in my Portable version whenever I feel the need with a batch file--double click and done:

Code
@ECHO OFF

Set dir="c:\MusicBee\AppData\InternalCache\AlbumCovers"

Echo Deleting all files from %dir%
del %dir%\* /F /Q

Echo Deleting all folders from %dir%
for /d %%p in (%dir%\*) Do rd /Q /S "%%p"
@echo Folder deleted.

exit
Just change the Set dir path to match yours and save wherever as a *.bat file.  You could also just browse to the cache path in File Explorer and delete the contents of "AlbumCovers" manually but what fun is that.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 02:23:36 AM


+1 for the Wishlist request.  In the meantime, I clear the artwork cache in my Portable version whenever I feel the need with a batch file--double click and done:


Well, what I do for now is remove the write permission for the artwork cache folder, so that musicbee cannot write the PNG's to the folder. However this stops musicbee from displaying the coverart, except for the currently playing mp3. It's kinda janky that musicbee fails to display the image because it cannot /write/ out the image it /can/ read from the embedded mp3.

This saves my google drive from filling up with GB's of redundant data, but it does mean that musicbee is not so nice to use for me.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: sveakul on March 10, 2021, 05:03:00 AM
The PNG caching behavior for embedded artwork surprised me also.  I should mention that my batch file does basically the same thing as "Tools->Advanced->Reset Artwork Cache"--'basically" in the sense that the latter axes the folder itself vs. just the content, and takes more clicks than the batch file.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: frankz on March 10, 2021, 05:49:56 AM
I think this artwork caching is pretty common behavior.  Imagine MB scanning thousands of music files and extracting embedded artwork from each one every time you wanted to display a view and then deleting those files when you changed views only to recreate those files when you return to it.  100 albums is 1000-1500 individual files.  Untenable!  Obviously Steven at some point weighed the storage cost of cached artwork vs the performance cost of live-loading artwork and decided the storage cost was worth it.  

I've been using MB since mid-2017 with an 11,000+ album library, and my album art cache is just over 908Mb.  I've been using iTunes for Apple Music for 6 months and the album artwork cache there is 1.97Gb!  For me in MB, the "ArtistBackdrops" folder is the killer at 2.45Gb.

What isn't common behavior is being entirely unable to prevent a subfolder from being backed up to a backup solution.  I use carbonite for my offsite backups, and disabling a folder from the backup is as simple as deselecting a check box in Folder Properties.  I use Acronis for my local backups and it's equally easy to disqualify a folder through their software.  I can't imagine that Google wouldn't provide this basic functionality.  Actually, I can imagine it because Google pretty much hates their end users.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 06:09:16 AM
I think this artwork caching is pretty common behavior.  Imagine MB scanning thousands of music files and extracting embedded artwork from each one every time you wanted to display a view and then deleting those files when you changed views only to recreate those files when you return to it.  100 albums is 1000-1500 individual files.  Untenable!  Obviously Steven at some point weighed the storage cost of cached artwork vs the performance cost of live-loading artwork and decided the storage cost was worth it. 

While what you say is true in that sense, that doesnt mean it is the best way or the only way of doing it. When you first import your music in to the library, the PNG's are only created once you start scrolling and the album cover comes in to view. When you do this, it is a little slow, but I suspect the slowness is not the reading of the jpeg embedded in the first MP3 (it only needs to read one MP3 not all of them for album art), but the conversion to PNG and then writing it out. On top of those operations, it also attempts to read the PNG from the cache and will insist on recreating it if the PNG id not the preset dimension. All of these things add to the slowness of loading the album art when scrolling "on the fly". I firmly believe that a quad core CPU with 16GB of RAM and TLC NVME storage is more than capable of reading a jpeg from 20 album mp3's in a few ms.

Furthermore, it would seem the cached PNG's are taken out of memory once they are out of the view, as they arent particularly quick to load even from this  "cache".


What isn't common behavior is being entirely unable to prevent a subfolder from being backed up to a backup solution.  I use carbonite for my offsite backups, and disabling a folder from the backup is as simple as deselecting a check box in Folder Properties.  I use Acronis for my local backups and it's equally easy to disqualify a folder through their software.  I can't imagine that Google wouldn't provide this basic functionality.  Actually, I can imagine it because Google pretty much hates their end users.

I'm not here to speak for using google drive as a backup solution; for me it suits my needs and although it is clunky, it is reliable and I enjoy some of the features. I dont want to get into a discussion about backup solutions though; this isnt really about that, but about the possibility of giving musicbee the option to stop it from caching files that really do not need to be when they are present on the same disk. I suspect it's not just me that wouldnt expect a music player to start swallowing up their disk space.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: Steven on March 10, 2021, 06:12:44 AM
Actually, I can imagine it because Google pretty much hates their end users.
do you mean hates their cattle? i am sure they love the advertisers!  :)
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: frankz on March 10, 2021, 06:36:22 AM
I firmly believe that a quad core CPU with 16GB of RAM and TLC NVME storage is more than capable of reading a jpeg from 20 album mp3's in a few ms.
You do know that MB is designed to run on systems besides your own, right?

Actually, I can imagine it because Google pretty much hates their end users.
do you mean hates their cattle? i am sure they love the advertisers!  :)
:D
The PNG caching behavior for embedded artwork surprised me also.  I should mention that my batch file does basically the same thing as "Tools->Advanced->Reset Artwork Cache"--'basically" in the sense that the latter axes the folder itself vs. just the content, and takes more clicks than the batch file.
The beauty of sveakul's elegant solution is that you can schedule it to run automatically through Window Task Scheduler.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 06:40:24 AM
You do know that MB is designed to run on systems besides your own, right?
Yes, that's why I'm asking for an option... ya know, it'd be optional to disable the cache ;) you can choose, it would not affect you if you want to continue using the default cache operation

But as it goes, pretty much everyone has at least 4 cores, 8GB ram and majority probably have an SSD boot drive at the least

But also imagine this behaviour on mobile versions.. dbpoweramp on my phone does not cache album covers yet it's blazing fast browsing by album cover.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 06:47:41 AM

The beauty of sveakul's elegant solution is that you can schedule it to run automatically through Window Task Scheduler.

The creation and deletion of data is not good practice for an SSD, particularly cheaper QLC drives.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: hiccup on March 10, 2021, 07:26:31 AM
What are your objections to the solution I presented you?
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 07:30:56 AM
Well, it's a work around, not a solution, plus thats ok if the sync software isnt running, otherwise it's going to uploading 3.5GB of data and deleting it periodically. But given that you went to the effort of knocking up a script for this issue suggests that my wishlist request is valid at least.

If the softwares author doesnt agree or perhaps doesnt deem it important enough to fix, that's fine, it is just a request.

I'll probably continue to use musicbee anyway

Thanks
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: hiccup on March 10, 2021, 07:33:45 AM
Well, it's a work around, not a solution. But given that you went to the effort of knocking up a script for this issue suggests that my wishlist request is valid at least.
Thanks
My solution was not the script but using a free app such as SyncBackFree as a middle man.
Well at least you now have two possible solutions for your issue.

Both are free, not hard to setup, and can be fully automated.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 10, 2021, 07:37:16 AM
Well, it's a work around, not a solution. But given that you went to the effort of knocking up a script for this issue suggests that my wishlist request is valid at least.
Thanks
My solution was not the script but using a free app such as SyncBackFree as a middle man.
Well at least you now have two possible solutions for your issue.

Both are free, not hard to setup, and can be fully automated.

OK sorry, but either way im not looking for workarounds, i'm making a wishlist suggestion for musicbee itself.
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: hiccup on March 10, 2021, 07:38:14 AM
good luck
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on March 15, 2021, 07:34:47 AM
good luck

Thanks, can only hope!
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: Sofocl on March 17, 2021, 12:16:54 PM
+1 to optimize the cache.

Here is my request on a similar topic;
https://getmusicbee.com/forum/index.php?topic=13948
Title: Re: Please stop converting and caching embedded album covers - 3.5GB of cache!
Post by: euyep93 on September 09, 2021, 03:04:59 PM
Was hoping this might make it into 3.4, still wishing! ;)