indexArtwork : feature request

[eseb63]

Hello,

Here are some needs when using indexArtwork :

1. We can choose custom images for the index entries with indexArtwork=folder setting; we need then to create images for indexTag values : it's quite easy for some indexes (Artist, composer, ...) but for others not (Genre, Period, Item, Work...).
   PS : I prefer not to use indexArtwork=all and keep control of what is displayed
   
   Would it be possible, if a picture is not found for an index value, to get the index entry one ? the index entry picture would be the default picture for its values, overrided by the tag value picture if any.
   .
2. I use artist tag as LastName, FirstName [instrument]
   
   I use also an instrument index tag, but since it is not possible to get the list of artists playing a given instrument, you suggested that I create index tags pianist, violinist etc... which I did on the form lastName, firstName (see https://forum.minimserver.com/showthread.php?tid=7475)
   
   So i would need that picture searching ignore the suffix if any, to avoid having to duplicate artist images (one with suffix, one without).
   
   This ties in with the request you accepted in this thread to ignore the suffix for reverseName (https://forum.minimserver.com/showthread.php?tid=7466)
   .
3. Endly, it would be handy that a picture would be shown, regardless the name form. lastName, firstName vs firstName lastName : it would avoid having to rename all pictures if changing reverseName option.
   

With 2 and 3, a picture <lastname, firstname.png> would be shown for these index values :

• lastname, firstname
• firstname lastname
• firstname lastname (suffix)
• firstname lastname [suffix]
• lastname, firstname (suffix)
• lastname, firstname [suffix]
  

What do you think about these suggestions ?

[simoncn]

Thanks for these suggestions. See below for my responses.

(02-04-2025 11:38)eseb63 Wrote:  Would it be possible, if a picture is not found for an index value, to get the index entry one ? the index entry picture would be the default picture for its values, overrided by the tag value picture if any.

This would be possible and I think it is a good idea. I will put it on my to-do list.

Quote:I use artist tag as LastName, FirstName [instrument]

I use also an instrument index tag, but since it is not possible to get the list of artists playing a given instrument, you suggested that I create index tags pianist, violinist etc... which I did on the form lastName, firstName (see https://forum.minimserver.com/showthread.php?tid=7475)

So i would need that picture searching ignore the suffix if any, to avoid having to duplicate artist images (one with suffix, one without).

This ties in with the request you accepted in this thread to ignore the suffix for reverseName (https://forum.minimserver.com/showthread.php?tid=7466)

Quote:Endly, it would be handy that a picture would be shown, regardless the name form. lastName, firstName vs firstName lastName : it would avoid having to rename all pictures if changing reverseName option.

When designing the index artwork feature, I considered various options for how artwork files should be named (original tag value, tag value as modified by tagOptions/tagValue/tagFormat, etc.) The chosen approach was that the artwork filename must match the index entry shown in a control point when browsing. This is simple for the user to understand and enables MinimServer browsing and searching to perform efficiently.

Allowing alternatives for image filenames and describing in the user guide how and when these alternatives can be used would add significant complexity for users. It would make the implementation more complex and impact browsing and searching performance because of the need to parse every index entry for characters such as comma, parentheses and brackets and look for an alternative image filename. It would also require inverting the reverseName mapping, which isn't possible in some cases (Ralph Vaughan Williams, John Eliot Gardiner, Josquin des Prez).

For all these reasons, I don't think it would be a good idea to change the current design and implementation.

As you have pointed out, the current design means that with some tagging and indexing schemes it might be necessary to create multiple files containing the same image. Perhaps it would be possible to do this with a script that automates making copies of image files as required.

[eseb63]

(07-04-2025 14:02)simoncn Wrote:  

Quote:Would it be possible, if a picture is not found for an index value, to get the index entry one ? the index entry picture would be the default picture for its values, overrided by the tag value picture if any.

This would be possible and I think it is a good idea. I will put it on my to-do list.

Thanks a lot!

(07-04-2025 14:02)simoncn Wrote:  Allowing alternatives for image filenames and describing in the user guide how and when these alternatives can be used would add significant complexity for users.

Just for ignoring the suffix or the name form ? many user guide chapters are more complex than that i think

(07-04-2025 14:02)simoncn Wrote:  It would make the implementation more complex and impact browsing and searching performance because of the need to parse every index entry for characters such as comma, parentheses and brackets and look for an alternative image filename. It would also require inverting the reverseName mapping, which isn't possible in some cases (Ralph Vaughan Williams, John Eliot Gardiner, Josquin des Prez).

I had some doubt about the performance impact, so i am not surprised by your position ; does minimServer use a cache for the index images ? if so, when is it populated , during browsing or launching a rescan ?

if ReverseName handling is the more problematic, just ignoring the suffix might be a good compromise between features and performances ?

What do you recommend as a maximum image resolution to maintain performance?

[simoncn]

In the early years of MinimServer, I tried to satisfy every user request. This added significant complexity and MinimServer started to acquire a reputation of being very powerful but also very difficult to configure and use.

Because of this, I am now very careful not to add too much complexity when designing a new feature or extending an existing feature. This higher bar inevitably means that some user requests cannot be satisfied. Existing older features have been left unchanged (even if over-complex) because I don't want to break things for users.

An important aspect of complexity is the interaction between different features. The concept of a suffix is currently confined to the reverseName option, which means anyone not using this feature doesn't need to understand it. Adding this (and name reversal) into the description of the index artwork feature would cross the boundary between these different features and would require people reading about index artwork to also read about name reversal and understand it to some extent, if only to satisfy themselves that they can safely ignore it.

There is a cache for index artwork images. Designing this to get acceptable performance with large libraries was a significant challenge and I would prefer not to revisit how it works (for example, to allow different index entries to map to the same image file). This cache is populated dynamically while browsing and cleared when the user browses to a different section of the browse tree. This is because MinimServer doesn't keep the whole browse tree in memory but rebuilds it dynamically in response to browsing requests.

MinimServer itself is not performance-sensitive to image resolution but image resolution does affect browsing performance because larger images need to be sent across the network to control points and processed by them. I cannot give a figure for how large is too large because this depends on network speed and how efficiently the control point handles requests for images. For example, some control points request the same image multiple times in a very short space of time.

[eseb63]

(09-04-2025 21:43)simoncn Wrote:  MinimServer started to acquire a reputation of being very powerful but also very difficult to configure and use.

indeed, minimserver is really powerful; mastering this power requires spending hours reading and assimilating the documentation, and testing, but it is worth it !

(09-04-2025 21:43)simoncn Wrote:  An important aspect of complexity is the interaction between different features. The concept of a suffix is currently confined to the reverseName option, which means anyone not using this feature doesn't need to understand it. Adding this (and name reversal) into the description of the index artwork feature would cross the boundary between these different features and would require people reading about index artwork to also read about name reversal and understand it to some extent, if only to satisfy themselves that they can safely ignore it.

I'm not entirely convinced. I think you're overestimating the complexity for the user to understand the concept of suffixes and noun form inversion, which is quite simple. Users who would be put off by this probably abandoned minimServer long ago for other, more realistic, complexities, in my opinion.

But you're the only judge , so I'll duplicate the images if necessary.

[eseb63]

For those who are also affected by duplicate index images, a workaround is to create symbolic links: this works well according to my tests