View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005467 | MMW v4 | DB/FileMonitor | public | 2009-04-03 18:39 | 2009-05-15 19:03 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0005467: Multi-attribute fields aren't displayed correctly in several different cases | ||||
| Description | 1) If the user changes the separator from '; ' to '& ', MM will not automatically split tracks with '& ' in them even on restart. 2) If the user e.g. sets '&' as the splitter and then scans a track containing Artist = U2 & BB King, then the Artists are not split up in terms of how they're represented in MM. i.e. in the tree the user sees: U2 & BB King wherease they'd also expect to see one entry for U2 and another for BB King. 2b) A related problem is that post-scan if the user tries to modify the Artist from 'U2 and BB King' to 'U2 & BB King', MM will automatically change it to U2&BB King (assuming & is the separator). 3) If the separator is changed (e.g. from '& ' to '; '). And immediately after changing it (without rebooting), the user edits a track Artist from 'ArtistA& ArtistB' to 'ArtistA; ArtistB' -->Upon reboot, MM will show the track with Artist='ArtistA;; ArtistB'! | ||||
| Steps To Reproduce | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37290 | ||||
| Additional Information | If this is high-risk, we can push beyond 3.1. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1233 | ||||
| related to | 0004938 | closed | rusty | Make separator configurable for multi-attribute properties |
| related to | 0003712 | closed | jiri | Multiple definition fields: sometimes spaces are auto-deleted |
| related to | 0005529 | feedback | jiri | Multi-attribute field splitter characters that aren't field splitters don't display consistently |
|
|
Yes, it works this way, i.e. after changing the separator, MM doesn't modify all tracks in Library and apply the new separator. The separator is only applied when user scans tracks or edits them. It might look like a bug, but it actually prevents problems in case user modifies the separator inadvertently. The second problem is actually also by design, the separator is always formatted as configured (i.e. '&' or '& ' or ' & '). I know it isn't perfect, but I don't think we should do anything about it for 3.1 and even then, I don't see what else to do. The only good way seems to be to completely redesign multi-artist support, as I suggested in another Mantis issue, but we decided to defer it. |
|
|
I've numbered and clarified the original report so that the discussion makes more sense. I've also added item 3). Re. item 1), the problem is that it doesn't actually work as you described. i.e. rescanning a directory will _not_ cause tracks within it to be split even if they contain a splitter. Repro steps: -Splitter configuration is '; ' -Track A has Artist=Artist1; Artist2 -Track B has Artist=Artist3| Artist4 1) Change splitter config to '| ' 2) Restart MM --> Track A appears with new '| ' splitter and is correctly displayed in the tree --> Track B appears with '| ' splitter, but isn't correctly displayed in the tree (as you described) 3) Rescan directory containing Tracks A and B --> No change (track B still appears in the tree as 'Artist3| Artist4' ! 4) Remove Track B from library and rescan directory --> No change (track B still appears in the tree as 'Artist3| Artist4' ! 5a) Manually edit Track B's Artist field to 'Artist3; Artist4' --> Track B artist attributes are SPLIT (despite the fact that the splitter is now supposed to be '| ' !! 5b) Alternatively, if step 5b is taken instead of 5a: Edit Track B artist to 'Artist3& Artist4'. Then re-edit to 'Artist3| Artist 4' --> the artists are split as expected. So basically scanning doesn't seem to work correctly, though editing does (although that still doesn't explain case 5a). |
|
|
Sorry for the confusion, I was certainly wrong - scanning shouldn't have any effect. The configurable separator is only how individual artists are separated in MM interface, it has nothing to do with actual tags (that's also one of the reasons we have this in Appearance sheet of Options dialog). To make everything clear, here is an example: OGG track is tagged as: ARTIST: U2 ARTIST: BB | King I.e. user (using MM or some other tagger) already propertly created a multi-artist track. After scanning, the track is shown in MM interface as: 'U2; BB | King' If the separator is configured as '| ', the track is shown after a new scan as: 'U2| BB | King' But MM still sees artists as 'U2' and 'BB | King' (which is definitely confusing, but perfectly normal and correct - given how we can currently implement it). User should choose as rare separator as possible (the default ';' is very good in this aspect). 5a) Fixed in build 1233. This really was a bug. |
|
|
Verified 5a in build 1233. |
|
|
Re-opening as lower priority for item 3) |
|
|
3) It isn't a bug, ';;' is used as a representation of ';' in case ';' is configured as a separator. Question is, whether the same scheme (i.e. doubled characters) should be used even in cases when user has other than ';' separator configured. I don't think it's overly important. |
|
|
3) I think it is a bug as it only occurs in some cases. Here's how to repro: Set separator to '| ', reboot, and tag a couple of track with the separator. Change separator to from '| ' to '; '). And immediately after changing it (without rebooting), edits a track Artist from 'ArtistA| ArtistB' to 'ArtistA; ArtistB' -->Upon reboot, MM will show the track with Artist='ArtistA;; ArtistB'! I think that the problem only occurs if edits are made without rebooting, but their may be other cases as well. |
|
|
3) However, this is correct behaviour: When you change '| ' to '; ', but don't reboot, '| ' is still in effect, and so entering ';' is understand literally, i.e. not as a separator, but as a semicolon. Then, after reboot, ';' is understood to be a separator and so real semicolon is shown as ';;' (as designed). |
|
|
Closing because 5a is verified, and remaining items are tracked in 0005529. |
