View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011772 | MMW v4 | Synchronization | public | 2014-01-21 20:35 | 2014-02-04 00:37 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0011772: Some tracks that MM mistakenly considers as duplicates fail to sync | ||||
| Description | 0011754 was in which tracks were synced and deleted repeatedly when MM considered the tracks to be duplicates. Unfortunately, the fix seems to cause MM to fail to sync tracks that aren't duplicates even though they might appear to be. For instance: if Hallelujah by Hannah Trigwell is on autoplaylist 'Good Stuff' and Hallelujah by John Cale is on a playlist 'Unrated', and both Unrated and Goodstuff are on the auto-sync list, then Hallelujah by John Cale won't sync, if the Hannah Trigwell version has already synced!! I'm not sure what logic is being used to determine what "duplicate" tracks shouldn't be synced, but it may be simpler that if the user has selected a track to the auto-sync list, it should be synced--even if it's a dup. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1690 | ||||
| related to | 0011754 | closed | Ludek | Wi-Fi Sync: Some tracks sync repeatedly for no reason |
| related to | 0011321 | closed | Ludek | Playlist contains duplicates when more tracks point to the same location on the device |
| related to | 0011378 | closed | Ludek | Files with same metadata are skipped during synchronization |
| related to | 0006343 | closed | Ludek | MediaMonkey fails to auto-sync duplicate tracks |
| related to | 0006979 | closed | jiri | Incorrect defaults for MTP Device (Creative Vision) |
| related to | 0011961 | closed | Ludek | Duplicate tracks are missing from playlists |
|
|
Rusty, in this case it is most probably just instance of 0006343 / 0011321 / 0011378 i.e. it is not a regression, but it has always worked like this: - if both the tracks point to the same device location (\Music\<Album Artist> - <Album>\<Track#:2> <Title>) on the device then one of them is skipped, because there cannot be two songs in one device location. You can generate debug log to confirm my speculation that both the tracks points to the same device location, but I am almost sure that this is the case. In that case I would resolve this issue as "no change required" or postpone. |
|
|
Your speculation is correct (though I've uploaded a log anyhow since the filenames shouldn't have been identical because one was a flac file and the other aac--but this is a minor issue). I wonder though, whether we should change the path for music from: \Music\<Album Artist> - <Album>\<Track#:2> <Title> To \Music\<Album Artist> - <Album>\<Track#:2> <Artist> - <Title> in order to avoid this bug. |
|
|
OK, the mask changed as suggested in build 1690. Test note: Just the defaults were changed, so you need to use [Reset device settings...] button OR delete/create new device profile. |
|
|
Note: http://www.ventismedia.com/mantis/view.php?id=6979#c21831 at 0006979 indicates that in an earlier build we modified the sync paths to match those of WMP to deal with other issues. Hopefully most such problems are no longer relevant, but based on this, perhaps we should instead defer this change to the beginning of a new beta cycle, and write a KB article? |
|
|
From SVN history I see that 0006979:0021831 was about adding 'Music' and 'Video' folders as root, e.g. '\Classical\'-> '\Music\Classical\ , '\Movies\..' -> '\Video\..' , but the path for music was unchanged. We modified only the actual filename as part of this issue, so I think it was quite low risk change and we can keep it as is. |
|
|
Verified 1692 |
