View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011961 | MMW v4 | Synchronization | public | 2014-03-18 15:31 | 2014-05-22 20:15 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1.2 | Fixed in Version | 4.1.2 | ||
| Summary | 0011961: Duplicate tracks are missing from playlists | ||||
| Description | Sync has a feature that causes duplicate tracks to silently not sync on the assumption that users don't want dups on their devices. There are a couple of problems with this as it results in playlists missing tracks if a track within a playlist is considered 'identical' to another track on another playlist that points to a different file. For example in the case where tracks b and B are different versions of the same track, and: Playlist 1 contains: a b c Playlist 2 contains: d B e When the playlists are synced, MMA/MMW consider that b and B are identical, resulting in the following playlists on the device in which Playlist 2 is missing tracks! : Playlist 1 contains: a b c Playlist 2 contains: d e Similar instances of this bug can occur if the user selected the Artist of track b/B, and only synced playlist 2. The issue also occurs if multiple instances of the track appear _within_ a playlist. So the question is: 1) If the user has these tracks in their library, and chose to sync them, should MMA/MMW really be automatically not syncing them (especially considering that there's no option for this)? I think that this is particularly bad for playlists. NOTE: according to the user USB Sync doesn't result in the bug, whereas Wi-Fi Sync does?! 2) If we're not able to change this without much risk, should we add an error message to the 'some tracks failed to sync dialog' for Duplicate tracks: x > | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=72375#p385933 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1704 | ||||
| related to | 0011772 | closed | Ludek | MMW v4 | Some tracks that MM mistakenly considers as duplicates fail to sync |
| related to | 0011321 | closed | Ludek | MMW v4 | Playlist contains duplicates when more tracks point to the same location on the device |
| related to | 0006343 | closed | Ludek | MMW v4 | MediaMonkey fails to auto-sync duplicate tracks |
| related to | 0011913 | closed | Ludek | MMW v4 | Duplicate Titles fail to sync to Apple devices |
| related to | 0006219 | closed | Ludek | MMW v4 | Synchronization errors should be logged |
| related to | 0011919 | assigned | martin | MMA | Mixed up or Missing album art (Per-track Album Art) |
|
|
This only affects files that would result in a duplicate filename on device no? In my setup I have: Playlist 1 file a file b Playlist 2 file b File mask is setup so that file a and b (same track, different album) have duplicate filename (in Playlist name folder) thus only file a gets synced (I want that). Now would file b on Playlist won't be or will be synced (it isn't a duplicate filename for file a as it is in its own Playlist folder) (I would like it to be)? |
|
|
Rusty, if I understand correctly, you are suggesting to revert 0011321 ? I agree with LowLander that it would be rather unexpected, i.e. if the file isn't synced then it should also be excluded from the playlist. Note that this behaviour is consistent with USB sync. |
|
|
No--that's not really what I'm saying. I guess what I'm saying is that the fix in 0011321 fixed a symptom but not the problem. The problem described in 0011321 was that playlists contained duplicates _because mmw assigned identical filenames to different tracks_. Rather than eliminating the duplicates in the playlists, shouldn't MMW ensure that _different_ filenames are used for each of the different tracks that are synced? |
|
|
OK, so you are suggesting that MM shouldn't respect the target mask and add a numbering to the filenames in such a cases? Note that this is actually possible by using <AutoNumber> mask (introduced in 0006343), you can use <AutoNumber> mask, this way every duplicate in playlist will have its own filename on the device. But this way also same songs (with same IDs) are created with different filenames on the device (according to the <AutoNumber> mask). One way or the other this issue is quite sporadic and not a big deal IMHO, so I would rather avoid to do a change now (e.g. it could bring some regressions related to bi-di sync) |
|
|
Yes--I suppose that assigning unique filenames in cases where there's a conflict is the only way to deal with this issue. The other possible approach is to leave things as is, but to consider this a reportable sync error, so that users at least are made aware that some tracks haven't synced. I think that both approaches are valid, and if there's a risk of regression with the first, it might be worth using the second for 1.0.4 / 4.1.1 since it's strange when MMA/MMW syncs and the numeber of tracks doesn't match, and there's no error. Note that there's already a duplicate tracks string re. 'Files to edit' that we could use in MMW. If reporting this as an error is somehow problematic, we can push it and I'll add this to the KB for now. |
|
|
I'd rather not see this reverted. I prefer that if user assigns duplicate name to file on device that only 1 copy is synced as the user can already circumvent the problem by changing the destination mask (like using <Auto Number). However there may be a problem if in my described scenario Playlist 2 doesn't get file b as it wasn't synced because of duplicate filenames in Playlist 1 (note syncing file b to Playlist 2 would not be a duplicate filename as Playlist folders are used in my destination mask). |
|
|
I agree that playlist items count should be the same in MMA and MMW. So, we need to resolve this situation somehow. I wouldn't consider error reporting, since sync should be a silent operation (unless something really critical happens). So we should assign unique filenames to different tracks, i.e. add a suffix '_1', '_2', ... when needed. I don't consider the issues as critical though and should be scheduled as MM 4.1.1 fix by Ludek. |
|
|
Note that the error reporting of this has been already added in 1663, but was removed in 1668 as irritating, see 0006219:0037812 Nevertheless I agree with lowlander that many users prefer that if user assigns duplicate name to file on device that only 1 copy is synced as the user can already circumvent the problem by changing the destination mask (like using <Auto Number), note that this is not the case for Apple devices where users can't set the destination mask (0011913) and duplicates are created. |
|
|
Note that there's a difference between AutoNumber usage and the unique filenames suggestion: AutoNumber creates duplicate files even if the very same track is in multiple playlists or multiple times in one playlist. The unique filenames solution would sync just one file per MMW track. |
|
|
An alternative solution to the problem would be an option. An option would have as benefit that it would work consistently across all device sync (including Apple). The option likely needs at least 2 (non-Apple should have 3) choices: - Don't sync duplicate filenames on device (for Apple this could be don't sync duplicate Artist - Title files) - Sync duplicate filenames on device (append number to each duplicate copy) (for Apple this would be Artist - Title). - Sync same file in Library multiple times if different filenames on device (not for Apple devices) The latter option would be a good option for users who sync files to for example Playlist folders, or use things like Auto-Number. I guess the latter option should be applicable independent of the first 2. The key here (in making a choice) is that currently there is no way to prevent duplicates (which some users, myself including) from being synced other than the current implementation, but users can still with the current implementation get the duplicates if they want to. |
|
|
I don't think that a config is needed for Apple devices, because Apple devices have no target filename configuration at all and all filenames looks like /iTunes_Control/Music/F06/_Ja2.mp3 But adding the suffix '_1', '_2' for Android devices without an option would probably really result in negative feedback from users because it would actually results in duplicates in MMA library. Currently the default mask for MMA is \Music\<Album Artist>\<Album>\<Track#:2> <Artist> - <Title> so the duplicate filename is created only if also the metadata are same and thus there would be duplicates when navigating MMA library (which many users won't like). On the other hand one can argue that if anyone have dups in MMW library then he should expect them in MMA library too. So an option would be useful here from user's perspective, but adding it complicates the things further (mainly from testing perspective), there would be further bunch of test cases depending on the checkstate(s) of the new option(s), so I would rather avoid adding it for this reason. |
|
|
I'd also rather avoid a new option, which is why I believe that the suffix version is the best way to go. |
|
|
I also more and more tend to the suffix version. This way it would be consistent with Apple devices. It probably isn't so risky, but has a small performance impact, because we need to get information about filename used in the last sync (DeviceTracks table in MM.DB), but this we already do during USB sync. |
|
|
So we're removing a feature some want to do something that is already possible? |
|
|
Yes, you seem to be true that it can be also considered as removing a feature (from user perspective). Thinking about it again I wonder whether a change is really needed, because user can configure/adjust this by changing the default target mask. If he wants to sync duplicates he can change the mask from \Music\<Album Artist>\<Album>\<Track#:2> <Artist> - <Title> to \<path> or \<folder><filename> this way even duplicates in different folders will be synced, because they will have the same structure as on the PC drive, the problem is when they are located on more PC drives, then one can use <random> mask, so I suspect that adding <random> to the target mask really makes every filename unique. The downside of using <random> mask is that user needs to keep '[ ] Enforce use of sync mask for files already on device' disabled (is default) otherwise MM would want to re-copy the files on each sync. |
|
|
The user shouldn't have to change the target mask. i.e. MM/MMA in the _default configuration_ should have a 1:1 correspondence between tracks/tracks in playlists on the device and tracks/tracks in playlists in the library. Anything different is confusing to the majority of users. Yes, some users will want: a) > 1 copy of a track on the device per track in the library (e.g. sync mask <Playlist>/<Artist>-<Title> ) b) < 1 copy per track if the sync algorithm determines that tracks are identical BUT, re. b) our current implementation is faulty anyhow i.e. it results in partial track/playlist synchronization for all of the cases that follow (good for case i, but not desirable in cases ii/iii): i) when tracks are duplicates ii) when tracks aren't duplicates, but are missing metadata resulting in an identical path iii) when tracks aren't duplicates & aren't missing metadata, but have a faulty mask that results that results in an identical path (e.g. /<Artist>-<Title>) for both files on the device Furthermore, Ludek/Marek can confirm, but I suspect that non 1:1 correspondence may cause other sync problems (e.g. if a playlist is modified on sync to the device to eliminate "duplicates", and the user then makes a change to the playlist, then when the playlist is updated in the library all the "duplicates" will be removed!). Considering the above, I'm not sure if it's worth the effort to add an option for non 1:1 synchronization. As to _how_ to implement the default sync, hopefully Ludek can recommend. Modifying the default mask would be simplest, but as pointed out, most of the proposed masks have other issues, and using a mask also means that the user can get rid of the unique identifiers. But if we do decide to go this route, we could add <SyncSuffix> to the default mask (which differs from <Auto-number> in the sense that it would preserve 1:1 correspondence of tracks). |
|
|
Issue is documented at http://www.mediamonkey.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=175 |
|
|
If we agree that we have to do something about it, it seems that it's either adding of _1, _2 suffixes, as described earlier, or the more configurable approach of adding <SyncSuffix> mask as suggested by Rusty. The latter has definitely advantage of being configurable, even though it's probably also a little clumsy in the sense that all masks will have to include this (kind of) meaningless part. I'm slightly inclined to the second solution, even though I'd consider renaming it to something like <DeDuplicate> and have it ready to be used also e.g. in AutoOrganize, etc. |
|
|
I'm not that keen an adding this to the mask because: a) it should be enabled by default and it looks clumsy b) it's a bit confusing as a mask--i.e. in some cases it'll add a suffix (when multiple track IDs result in a namespace conflict), but in others (e.g. if the mask causes the same TrackID to be written twice) it doesn't. c) it would require another round of translation (though perhaps I could take care of that manually; if we go this route it would need to be a very simple translation such as <Duplicate#> ) My inclination, at least in the short term, would be to implement the feature silently at the beginning of the next beta cycle, and collect feedback. If it turns out to be a major problem, we can go with a mask or a UI option. |
|
|
Implemented the auto numbered suffix solution as suggested by Rusty and Jiri in the last notes. This 1:1 correspondence simplifies the things a lot (from dev perspective, from user perspective and from testing perspective too), so my inclination is also for this approach. |
|
|
Verified 1704 |
|
|
Verified 1705 |
