View Issue Details

IDProjectCategoryView StatusLast Update
0005529MMW v4DB/FileMonitorpublic2015-02-05 15:13
Reporterrusty Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status feedbackResolutionopen 
Product Version3.1 
Target Version4.0.7 
Summary0005529: Multi-attribute field splitter characters that aren't field splitters don't display consistently
DescriptionThe current design of MM is that multiple attribute field splitters (e.g. '|') can represent a splitter OR the character '|'. This is _very_ confusing to users because:

1) they don't know whether they are seeing a splitter or a '|'

2) users are confused about why scans of "|" characters don't split the field

3) in the case of a single artist: 'Artist1|Artist2' , the only way to split this into 2 artists is to first edit the field to 'Artist1-Artist2' (i.e. change the | character to something else and commit the change) and then re-edit the field back to 'Artist1|Artist2'. Very confusing.

4) in the special case of a single artist: 'Artist1;Artist2', when the splitter configuration is changed to '; ', on restart, the artist is changed to 'Artist1;;Artist2'. This was implemented in order to prevent the confusion described in 1/2/3, however, it is confusing in and of itself because:
i) it only occurs with the '; ' separator
ii) it only occurs for displaying a single artist that contains a ';' that isn't a splitter. BUT if the user tries to enter 'Artist1;;Artist2' in order to enter a single artist field, the field becomes split into Artist1;Artist2

I believe that the simplest solution to all of these problems is to change the logic of MM so that as soon as the separator configuration is changed and MM is restarted:
A) All tracks containing the separator character appear as split (i.e. in the tree, find more from same, etc...)
B) All tracks that contain tags that are actually split, show the separator character

One might object to this on the grounds that it could result in unintended changes / edits to a user's tags, however, one could also argue that the changes would be transient, at least until the user modified the tags containing the split fields, at which point the split would be committed to a tag.

To make this completely unambiguous to the user, we can move the option:
'Split multiple-value fields with:' from Library > Appearances to Library > Tags and Playlists > Tags , and perhaps make it optional.

Setting this to 'urgent' rather than 'immediate' because there are workarounds, and because the problems only occur on initial scan in specific circumstances (when the splitter is configured to a commonly used character), and lastly, because the path forward is unclear.
Additional Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37290
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=20185
TagsNo tags attached.
Fixed in build

Relationships

related to 0005467 closedjiri Multi-attribute fields aren't displayed correctly in several different cases 
related to 0004938 closedrusty Make separator configurable for multi-attribute properties 
related to 0005528 closedjiri Multi-attribute field configuration: spacing is confusing 

Activities

jiri

2009-06-09 13:59

administrator   ~0018262

I don't think I can agree. The separator is only there in order to _visually_ separate items (like Artists) that are really technically separated in tag or DB. If you think about it this way, then I'd say that the current implementation makes perfect sense. Otherwise, if changing the configured separator from ';' to '|', we should not only separate items containing '|', but also back join items than contained ';' (to be consistent in the logic), which doesn't make much sense to me.

The only small problem I see is the inconsistency between ';' and other separators. ';' indicates to user by doubling (i.e. ';;') that there isn't a separator, but ordinary ';' character. For some reason this isn't implemented for other separators than ';'. If fixed, I'd say that everything will be perfectly clean and easy to use.

rusty

2011-05-08 22:26

administrator   ~0024943

We should eventually make the fix proposed by Jiri in the previous comment, but it's not critical for 4.0.