Index Artwork

[simbun]

I just caught that I wasn't actually indexing AlbumArtist, I was using AlbumArtistSort instead (and labelling it) because I thought it would be a lighter operation to just change the .displayFormat rather then the .value and .sort attributes.

(28-12-2022 14:48)simoncn Wrote:  The selection of auto index art for AlbumArtist index entries is based on items in the index selection, not albums.

This bit confused me, but from what you said subsequently I assume you just meant that it's based on entries from the [n] items and not from [n] albums index, even though that index may not actually be shown because of the listViewAlbums setting?

(28-12-2022 14:48)simoncn Wrote:  This means the artwork search order is the search order described for audio files in this section, so a disc image would be used in preference to an album image.

Similarly, the artwork selection order for AlbumArtist index entries is based on items.sortTags, not Album.sortTags. It should be similar to the order that the user would see in the 'n items' list.

I hadn't compared it to the Artist index before because I don't use it, but I'm not seeing any difference, is that correct bearing in mind the original quote?

Quote:For example, the Artist index entry for Pink Floyd will show an album cover from one of the Pink Floyd albums in your library

If the Artist index is supposed to show Album artwork I find it surprising that the AlbumArtist wouldn't given that the Artist index could include track artists. If Artist is supposed to work I could easily use this instead of AlbumArtist as I always have AlbumArtist populated.

(28-12-2022 14:48)simoncn Wrote:  The code for choosing an automatic image for an artist or album artist needs to be simple and efficient because it is run for all entries in an Artist or AlbumArtist container when the user selects Artist or AlbumArtist. For example, clicking on Artist for an artist container that contains 1000 artists runs this code 1000 times before showing anything to the user. MinimServer works internally on lists of items and this is why an item-based approach is used. This is the reason for the "as far as possible" disclaimer in the User guide description.

Given how performant MinimServer is I thought you might be storing the sort order during the initial file index, but if you're doing it realtime then I completely understand!

Thanks for taking the time to respond.

[simoncn]

(28-12-2022 21:14)simbun Wrote:  I just caught that I wasn't actually indexing AlbumArtist, I was using AlbumArtistSort instead (and labelling it) because I thought it would be a lighter operation to just change the .displayFormat rather then the .value and .sort attributes.

It makes no difference which index tag you are using. The implementation is the same for all index tags. **

Quote:This bit confused me, but from what you said subsequently I assume you just meant that it's based on entries from the [n] items and not from [n] albums index, even though that index may not actually be shown because of the listViewAlbums setting?

That's correct.

Quote:I hadn't compared it to the Artist index before because I don't use it, but I'm not seeing any difference, is that correct bearing in mind the original quote?

Yes, see ** above.

Quote:If the Artist index is supposed to show Album artwork I find it surprising that the AlbumArtist wouldn't given that the Artist index could include track artists. If Artist is supposed to work I could easily use this instead of AlbumArtist as I always have AlbumArtist populated.

Again, see ** above. I think there is some confusion from my Pink Floyd example. The image can be any artwork image for any item in the contents underneath the index entry. For indexes containing audio files (for example, Artist, AlbumArtist, 'n albums', 'n items' and folders), this includes images for audio files, groups, discs and albums. For indexes containing playlists (for example, 'n playlists' and folders), this includes images for playlists. The same principle applies to indexes containing network streams and/or folders. The typical case will be to show an album cover but all other image types are possible.

Quote:Given how performant MinimServer is I thought you might be storing the sort order during the initial file index, but if you're doing it realtime then I completely understand!

Every index in MinimServer is created dynamically because of intelligent browsing. For example, if Genre is selected before Composer, the Composer index for Genre > Choral > Composer will have different contents than the Composer index for Genre > Concerto > Composer, so each of these Composer index entries needs its own bespoke image selection. There is some caching of images once they have been computed but switching to a different container clears this cache. For example, cached images for Genre > Choral > xxx are cleared when the user switches to Genre > Concerto.

The top-level index images are cached until the next rescan but it would not be reasonable to have a different scheme for selecting these images than the scheme for selecting all other images at lower levels.

[simbun]

(28-12-2022 23:38)simoncn Wrote:  I think there is some confusion from my Pink Floyd example.

So the example did throw me because it refers specifically to album covers, but I also was unsure if your previous reply was specifically addressing AlbumArtist because, that's what I was asking about, or because it differed to Artist, but your first reply in your last post clarified that:

(28-12-2022 23:38)simoncn Wrote:  It makes no difference which index tag you are using. The implementation is the same for all index tags.

I've mocked up some data and can see it representative of what's in the items list so I'm clear about all that now. Thanks for the clarification.

(28-12-2022 23:38)simoncn Wrote:  The top-level index images are cached until the next rescan but it would not be reasonable to have a different scheme for selecting these images than the scheme for selecting all other images at lower levels.

I can only begin to imagine the tightrope you must be walking between functionality, flexibility and performance so I absolutely understand there have to be compromises, and they're even easier to accept when there are usually ways of addressing them e.g. placing the actual cover in indexArtwork/AlbumArtist or whatever index I see it in.

Thanks Simon.

[simoncn]

I have updated the wording of the Pink Floyd example to refer to artwork images instead of album covers.

Thanks for your kind words regarding tightrope walking. Fortunately, when walking a tightrope in software it is always possible to make another attempt to add further refinement without having suffered bone-breaking injuries!

[simoncn]

(27-12-2022 16:06)simoncn Wrote:  Thansk for letting me know about this. I have made some more changes that should make artwork images work as intended for the AlbumArtist, All Artists and Artist indexes. With these changes, the following rules apply.

The fix for the All Artists subfolder problem is available now in MinimServer update 232. The final implementation is slightly different from what I described in post #48 and is as follows:
1) For selections in the Artist index, the Artist subfolder is searched first for an image, followed by the AlbumArtist subfolder.
2) For selections in the AlbumArtist index, the AlbumArtist subfolder is searched first for an image, followed by the Artist subfolder.
3) For selections in the All Artists index, the Artist subfolder is searched for an image.
4) In all cases, if no image is found in the subfolders described above, the top-level folder is searched.

This enables the user to either place all artist images in the Artist subfolder and see the same image in all indexes (the simplest approach) or use the AlbumArtist and Artist subfolders to show different images for the same artist in the AlbumArtist and Artist indexes.

I have added a new section to the User guide describing how this works.

[Peter StreamMagic]

All artwork is showing up now.
Thanks!!
Another question: I tried to do the update using the configuration web page on my iPad but could not find a way to achieve this.

[simoncn]

The configuration web page does not currently provide a way to install an update. Update 232 is an automatic update, so it will be installed automatically when you relaunch MinimServer.

Support for installing the latest update directly from the configuration web page will be added soon.

[Peter StreamMagic]

(31-12-2022 16:20)simoncn Wrote:  The configuration web page does not currently provide a way to install an update. Update 232 is an automatic update, so it will be installed automatically when you relaunch MinimServer.

Support for installing the latest update directly from the configuration web page will be added soon.

That clarifies the matter, I was looking for something that doesn't exist yet
Thanks for all the work done during 2022!!
Happy New Year and best wishes for 2023!

Peter

[simoncn]

Thanks, Peter! Your contributions and suggestions are much appreciated.

Happy New Year to you and all other forum members!

Simon

[simoncn]

MinimServer update 233 (just released) provides a "one click" Install button on the Minimserver configuration web page for installing new MinimServer and MinimStreamer updates. You won't see this button after installing update 233 but you will see it when later updates are released.