View Issue Details

IDProjectCategoryView StatusLast Update
0012082MediaMonkey 4Synchronizationpublic2015-10-29 10:32
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version4.1.10 
Summary0012082: Some tracks occasionally sync repeatedly / unnecessarily
DescriptionTesting MM 1.0.6.285 against MM 4.1.3
--> some tracks sync repeatedly. Unclear why.

Additional InformationMM 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
TagsNo tags attached.
Fixed in build1765

Relationships

related to 0012596 feedbackmartin MediaMonkey for Android Tracks downloaded via UPnP don't seem to match correctly 

Activities

rusty

2014-11-26 18:33

administrator   ~0041168

Assigning to Rusty to retest with 4.1.6 / 1.1.0.

rusty

2015-09-22 15:52

administrator   ~0042960

Last edited: 2015-09-22 18:20

View 2 revisions

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).

rusty

2015-09-30 18:35

administrator   ~0043020

re-assigning back to me to generate logs as this isn't consistently replicable.

rusty

2015-10-01 04:09

administrator   ~0043021

Last edited: 2015-10-01 04:18

View 2 revisions

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.

marek

2015-10-01 18:19

developer   ~0043030

Last edited: 2015-10-01 18:19

View 2 revisions

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

rusty

2015-10-02 11:31

administrator   ~0043041

I've been unable to replicate this :-(

If it recurs I'll save the logs.

rusty

2015-10-13 17:54

administrator   ~0043101

Last edited: 2015-10-13 21:04

View 3 revisions

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

rusty

2015-10-13 21:07

administrator   ~0043104

Last edited: 2015-10-14 12:54

View 2 revisions

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.

rusty

2015-10-14 12:48

administrator   ~0043113

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

marek

2015-10-14 14:30

developer   ~0043115

Last edited: 2015-10-14 14:31

View 2 revisions

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.

Ludek

2015-10-29 10:24

developer   ~0043202

Last edited: 2015-10-29 10:33

View 2 revisions

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.