[DaveBlake]

Changing art on artist/album information dialog, where this can be seen immediately....

Art update on Music Lib Media Window
There was a bug, only noticeable on certain navigation routes and with artists/albums without a unique folder for art, that after changing artist or album art on info dialog the new art was given to the ".." item not the artist/album on the underlaying media window. That took some finding, but have fixed it.

Updating song items with new artist/album art
I set out to do this because it seemed a nice feature to have (in addition to the artist or album media window showing the change immediately), but I have hit problems.

The currently playing song as shown on the player OSD does get updated, but the items on the current playlist screen do not. The current playlist screen is a little different from the media window, the list of queued items is kept internally. Art appears to update if you have not visited this screen before changing the art, but once loaded to that internal list the art does not reload. I clear the current playlist cache, old art persists. So far I have not found a way to get it to reload.

I have made no attempt to propagate artist or album art changes made via JSON to any songs showing on the GUI at the time.

Question: since I can't update the current playlist art with artist/album changes (made via GUI or JSON), do I drop updating the player OSD art?? I guess I have to for consistency, but kind of sad about it

I will (before it is suggested) add that I am very reluctant to go as far as disabling "Choose Art" whenever there are items playing or queued to play. I think that would be even more confusing for users than not have the current playlist show art changes immediately.

[docwra]

I can only restate that changing the artwork on the OSD is not important to me personally. Seems a shame to loose it just for playlists support though, a very small likelyhood but I guess it might confuse 1 in a million users

[scott967]

FWIW on Aeon MQ5, in the musicplaylist window ListItem.Art(fanart) is used as a background full-screen image which works for both songs and music videos.  MusicPlayer.cover is shown as the main image (doesn't work for music video of course).  Is MusicPlayer.Cover the same as Player.Art(album.thumb) or Player.Art(song.thumb)?

scott s.
.

[rmrector]

It would be sad to see it go, but maybe it should. This same thing affects the video library, so it might be better to tackle it as a bigger project Kodi-wide.

It also seems that when it switches to the next song, currently playing artwork will (or can) pull artwork from that old cache of the playlist window, so even though it changes the currently playing song, if the next song is from the same album or artist it can end up with the old artwork, which throws another wrench in the helpfulness of changing artwork for the currently playing song.

@scott967 MusicPlayer.Cover is likely "thumb", which will be the song thumb if there is one, otherwise it falls back to "album.thumb".

[DaveBlake]

Updating song items with new artist/album art
I set out to do this because it seemed a nice feature to have (in addition to the artist or album media window showing the change immediately), but I have hit problems.
....

While waiting for PR review/approveal I have improved things. I'm a persistent guy, so I found a way to update the current playlist with updated artist and album art

There were a couple of reasons why old art kept popping back up - cache and an internal list - but finally got to grips with that.  I have still made no attempt to propagate artist or album art changes made via JSON to any songs showing on the GUI at the time. But give a guy a break, it is something that I put on my (also long) come back to it list.

I have also improved the "I just changed the contents of the folder.jpg but can't see it in Kodi until tomorrow" problem with local art. Now on art selection both the local thumb and the current art, if it is from a local file, gets recached and so will appear on the "Choose Art" dialog as it actually is including any recent changes that the user may have made to the contents of that image file.

What remains cached, and thus you still don't see immediate changes, are the image files on your drives that you have previously browsed as part of image selection but not chosen.  The caching is useful for broswing when files contents are stable, so rather than disable it I think the way forwards is to add a new button to the Image Selection dialog to optionally refresh the cache for the current folder. More work on that list! But anyway we move forwards step at a time.
 

And all "Container.Art(*)" has disappeared when navigating into a list of albums from an artist, or songs from an album or artist. I think I noticed this with the previous build, but forgot to mention it.

I think I have solved that too, but do test when you can.
 
However there is still a delay with getting a test build up for you all to try as the current master crashes on exit in Windows platforms. That fix is due to merge soon, so then I can rebase etc.....

[scott967]

However there is still a delay with getting a test build up for you all to try as the current master crashes on exit in Windows platforms. That fix is due to merge soon, so then I can rebase etc..... 

 
Yes, always fun dealing with architecture changes.

scott s.
.

[DaveBlake]

Test build available here PR13672 win64.

I am even hoping to merge this later today and then it will be in the nightly, but we will see.
This work is now in the nightly build