View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014520 | MMA | Synchronization | public | 2017-11-06 22:55 | 2017-11-26 01:37 |
Reporter | rusty | Assigned To | |||
Priority | immediate | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Target Version | 1.3.2 | ||||
Summary | 0014520: In some cases, hundreds of tracks are deleted unnecessarily | ||||
Description | There have been 2 reports of sync failures in which Wi-Fi sync deletes hundreds or even thousands of tracks from a device unnecessarily, and then resyncs the tracks (rather than just deleting the tracks that aren't on the sync list). QAH-965-95985 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=88557 Neither Peke nor myself have been able to replicate, however, both reports contain log files. | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
I really see that these tracks are deleted but I do not see any reason. MMA requests list of tracks for deletion and MMW returns this list. It would be better to generate MMW log to be able to see why these tracks are chosen for deletion. It might be caused by two different duplicate profiles. I have verified the logs and these logs have storageInfo.xml files with the same GUID. But that doesn't mean anything. Force resync on mask change is disabled. We do not have log where tracks are redownloaded. That would be helpful to compare. Assigning to Ludek to analyze from MMW perspective. |
|
Waiting for further confirmations from users, but so far it looks that it was caused by combination of random sort and limiting the playlist somehow. e.g. user created playlist with Played > 90 days Limit to 2000 tracks Sort: random In that case it is expected that another set of 2000 tracks is selected on each sync. |
|
Confirmed the suspicion via ticket QAH-965-95985 and forum, so resolving as "no change required" -- although I guess that this behaviour has always been confusing (also for me). We could probably re-evaluate this for MM5 and make such a auto-playlist (with random sort order) more persistent. Currently such an auto-playlist has different content on each sync (or re-load). I would rather expect to generate the random order only once and have a [randomize] button in the playlist header? I remember that I have already suggested this in the past, but Jiri argued that current behaviour is fine and user can get random tracks to the device this way, but as we can see this behaviour can be also undesired and extremely confusing. |