Artwork storage option is resetting to default on reboot

[JMuller]

Before :
After closing and opening MusicBee again :
MusicBee 3.3.7082, also happened with 6902.

This is particularly annoying when I edit albums and the PNG covers get resaved as JPG because this option was reset. It would be great if 1. the bug was fixed and the checkbox made persistent through reboots and 2. the option was file format insensitive, ie only the name matters and not whether it's JPG or PNG or whatever else.
Implementing 2. would also fit with the other cover options that allow a lot of liberty in the naming and format of the cover.

[redwing]

That's not a bug. If no option is selected, the third option defaults to get selected on restart. If you want a different behavior, post a wishlist item.

BTW I saw your another post too and strongly advise against using too a big image file either for embedded or linked. That slows down the GUI quite a bit, and personally I spend a lot of time for resizing linked artwork to a smaller size and converting png to jpg.

[JMuller]

I'll follow your advice and open a wishlist item, thank you. I like having high resolution artwork, I have many detailed covers and resizing them down to 1000 or 500 pixels seems wasteful. I could keep the originals of course, but they'd still not be visible from within MusicBee.

Besides, MusicBee uses thumbnails, so why would image size matter at all as long as you don't access the original by double clicking the cover ? I did notice slowdowns when accessing albums with large covers, but I don't understand why this happens despite thumbnails.

[redwing]

Probably depends on the layout. I am always using track info panel with artwork shown and the artwork size affects the GUI. The artwork tab of tag editor does the same. Also see this:

There is nothing wrong with the file you sent. Of course you are using huge embedded artwork (8MB for the file sent) so everytime these files are updated the entire picture needs to be loaded into memory. If you are doing actions that load (eg. showing the picture for the selected file in the track info panel will potentially mean a lot of files get loaded/ released) or save these files a lot then even though memory is still available it can become fragmented and hence fail. It might even be one corrupt file amongst all the files that doesnt cause an immediate failure.
Also I dont know what the FLAC library that MB uses is doing behind the scenes when encountering huge tags.

[Steven]

large size artwork will mainly be an issue if its embedded in the music file (it needs to be loaded and saved every time tags are changed) or when you have "Selected Tracks" set in the Track Info panel (although for v3.3 i recall i did make some improvements).
Of course there is also a one-time hit for generating the thumbnails used the various panels

[Steven]

Re: the reported issue, i dont think its a bug but i do agree the default behaviour is not ideal and i see you created a wishlist item for it

[JMuller]

Thank you ! What is this Track Info panel you mentioned ? I don't see any "Selected Tracks" option where I looked.

I do notice latency whenever I click on an album that has a high resolution cover. It happens every time too, it's not just a first-time thing.
Here's how my layout looks :

[redwing]

What is this Track Info panel you mentioned?

Go to View> Arrange Panels, then you will see "track information" element.

[JMuller]

Many thanks. However, I see no "Selected tracks" option here either.


I'll play with the other options and report back

[JMuller]

I really don't get it. The latency happens when I click on an album with a high resolution cover, in the main panel ("files" element). It's reproducible, even if I click to expand, click to close and click again to expand, the latency remains. I went into options for the "files" element, and disabled the cover altogether within the track list. Still the same. It's a 20 MB cover, so it makes sense that there'd be latency the first time. What I don't understand is that it should be thumbnailed afterwards.

[hiccup]

Until your specific issues/requests perhaps get addressed, I have some advice.

I also have some very hi-res images of albumart. (often photographs of LP covers)
I store them unprocessed in the album (sub) folder as a source, but they are not very practical or useful in a mediaplayer, MusicBee included.

So I process them with Photoshop, square them, fix them up a bit, and save them as jpg at maximum 1600x1600.
The filesize is always less then 1 MB, they look absolutely perfect in MusicBee, and I encounter no issues with them at all.

Also I hope you realize that for example a 1500x1500 good quality jpg will beat a 1000x1000 png in picture quality every single time, and will probably be something like a third or less in file size.

I'm sorry that this is not an answer or a solution to your questions, but I hope it's something useful for you to consider.

[JMuller]

No need to apologize, I appreciate the answer. I'm aware that I could have 2 versions of the cover, but I would like to have a library that is as clean as possible. I know it's very subjective, but duplicate covers feel messy. I also have a 4K monitor, so even 1500x1500 doesn't fill the entire screen when I open it in MusicBee, be it by double clicking the cover or just in compact mode.

[hiccup]

That would be 2160 pixels, correct?
Can I assume most of your album art is a lot smaller than that?
I believe 1200x1200 is a very common resolution these days.
They won't display full-screen on your monitor either.

So if your desire is actually to be able to see all your album art full-screen, that could be a candidate for a wishlist request.
I think I created one myself in the past, if that's the case, you could see if you can find it and support it, or create a new one.

That might at this moment be a more realistic goal to achieve than getting a music player/manager to accommodate for 20MB album art without any issues or delays...

[Steven]

I really don't get it. The latency happens when I click on an album with a high resolution cover, in the main panel ("files" element). It's reproducible, even if I click to expand, click to close and click again to expand, the latency remains. I went into options for the "files" element, and disabled the cover altogether within the track list. Still the same. It's a 20 MB cover, so it makes sense that there'd be latency the first time. What I don't understand is that it should be thumbnailed afterwards.

its not using thumbnails in the expanded panel, but thats from a historical reason.
So i have made a change but i am not committing to include it in v3.3 final

https://getmusicbee.com/patches/MusicBee33_Patched.zip

[CritterMan]

i have made a change but i am not committing to include it in v3.3 final

Would be much appreciated if you could. I was in the process of deciding if I should report the sluggishness as a bug or request a change as a wishlist item.