View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012082 | MMW v4 | Synchronization | public | 2014-06-26 14:53 | 2015-10-29 10:32 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 4.1.10 | ||||
| Summary | 0012082: Some tracks occasionally sync repeatedly / unnecessarily | ||||
| Description | Testing MM 1.0.6.285 against MM 4.1.3 --> some tracks sync repeatedly. Unclear why. | ||||
| Additional Information | MM debug logs uploaded to ftp: 1084 Initiated wifi sync --> 53 tracks synced (even though it was preceded by another sync operation) 30111 Initiated another wifi sync --> 53 tracks synced (even though they were already synced by the previous sync operation)! Note: MMA log: JACB1HQ8SV | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1765 | ||||
|
|
Assigning to Rusty to retest with 4.1.6 / 1.1.0. |
|
|
Tested MMW 4.1.9.1759 vs MMA 1.1.3.477 and this can be replicated by editing the ratings of a track in MMA that matches an auto-conversion rule. e.g. 1 Set an auto-conversion rule to convert tracks > 192 kbps to VBR V4 2 Create Playlist A with TrackA @200kbps and TrackB @160kbps 3 Wi-Fi sync the tracks to a portable device -->sync occurs and TrackA autoconverts and TrackB syncs without autoconverting 4 Initiate Wi-Fi sync again -->no tracks resync (as expected) 5 Change the rating on both tracks in MMA -->TrackA resyncs, but TrackB doesn't! Neither track should have resynced. Edit: I just noticed that if the playcount of tracks changes in MMW (i.e. if I play the tracks), then the tracks resync as well (I didn't confirm, whether this is limited to tracks that match the auto-conversion rule, but it appears to be the case). |
|
|
re-assigning back to me to generate logs as this isn't consistently replicable. |
|
|
I was able to replicate this (play the track and then sync --> track resyncs), though still not consistently: Log ID: QJRS7Z409H Description: bug 12082. 'Renegades' re-syncs even though it's already on the device and the only change is that it had been played. |
|
|
It is caused by different hash values so MMA thinks that the autoconverted track has changed. Added new logs to build 481 to find out the value of hash - to determine whether the issue is on MMA or MMW side. Please generate new logs |
|
|
I've been unable to replicate this :-( If it recurs I'll save the logs. |
|
|
I was able to replicate this bug by following the steps described at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82557 i.e. 1 Wi Fi Sync 2 In MMW edit the name of a playlist (Bronski --> Bronski test 111) and delete one of the tracks from the middle of the playlist 3 Autosync --> One of the tracks from the playlist resynced Debug log: TH94SRH2SU |
|
|
I was able to replicate this bug by following the steps described at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82557 i.e. 1 Wi Fi Sync 2 In MMW edit the name of a playlist (Bronski --> Bronski test 111) and delete one of the tracks from the middle of the playlist 3 Wi Fi Sync --> One of the tracks from the playlist resynced (not sure why only one of them) Debug log: TH94SRH2SU I'm not sure if this is the same issue as in the original report, however, what I think is happening here is that MMA deletes the original Playlist, and then re-downloads the renamed playlist. Then for _some_reason_ only some of the tracks are re-downloaded--hopefully the debug log will tell you why. |
|
|
Here's another instance that just occurred with build 485: 1 Played a bunch of tracks in MMA in the course of testing playback 2 Downloaded a couple of tracks in MMA via UPnP Download 3 Initiated Wi-Fi Autosync --> Tracks from Step 2 were auto-deleted (as expected) --> 2 Tracks that had been played 'Comtine...' and 'Yesh Tikva' were re-downloaded Debug log: H760RM3E5Y |
|
|
0012082:0043104 Wifi sync from 1. is not visible in log so I don't know what size was the file. But I can see that the file is redownloaded because the size differs. I don't know why. It is on MMW side. MMA stores size from MMW to DB for compairing. Maybe you changed settings of artwork? That they are not attached to media files ? 0012082:0043113 The track is redownloaded because the hash was missing in MMA - i.e. it was not previously autoconverted OR it was downloaded from UPnP and therefore the hash was not stored to MMA. We now store many our specific elements - like sync ID but autoconversion hash is missing. So during sync, the tracks are correctly paired but track is redownloaded because it is different. Only played tracks are redownloaded because we update playcount from MMA to MMW and MMW then sends counted playcount (and other metadata) back to MMA. During this process the hash and size are compared and therefore only updated (played) tracks are redownloaded. This is quite correct. |
|
|
ok, it seems that similarly to 0012596 we should serve not only the ID via UPnP, but all the custom UPnP metadata like the hash, disc number, bookmark, LTP etc. Fixed in build 4.1.10.1765 i.e. whenever UserAgent contains 'MediaMonkey' then _all_ the custom metadata are served. |
