View Issue Details

IDProjectCategoryView StatusLast Update
0011481MMASynchronizationpublic2013-12-10 19:01
Reporterrusty Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.4 
Target Version1.0.4Fixed in Version1.0.4 
Summary0011481: Some playlists get synched with multiple copies of the tracks within
DescriptionWhen completing a wifi auto-sync for a device that already has content on it (i.e. MMA analyses the local content vs the content in MMW), some Static playlists appear on the device with multiple duplicates of the playlist tracks.

e.g. delete db on MMA, then run MMA, and do a WiFi sync using the sync profile that already exists in MMW. If the playlist consists of Track 1, Track 2, Track 3, then after the sync it will consist of Track 1, Track 2, Track 3, Track 1, Track 2, Track 3.



Log: V3QP1AXRI1
Additional InformationTested with GS3/JB 4.1
TagsNo tags attached.
Fixed in build197

Relationships

has duplicate 0011524 closedLudek MMW v4 Playlists sync from Android device (with MMA) unnecessarily (over USB) 
related to 0011505 closedmartin MMA Duplicate tracks appear in the library (after unnecessary syncs??) 
related to 0010166 closedmartin MMA Scans are never-ending for some devices/environments 
related to 0011517 closedmarek MMA Some podcast episodes re-download with each sync 
related to 0011559 closedmarek MMA Duplicated playlists in MMA after USB sync (regression) 

Activities

rusty

2013-11-19 05:54

administrator   ~0038334

Last edited: 2013-11-19 15:34

I still haven't been able to figure out what causes this, but another user has observed the problem as well:
http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=74175#p377896

OLV-481060 (contains DB)

rusty

2013-11-22 06:24

administrator   ~0038351

In testing build 186 today, I've found that this problem occurs for playlists that aren't even on the sync list!! Could it be that this is a problem re. scanning of playlists into the MMA library, rather than a problem with WiFi sync?

rusty

2013-11-24 06:35

administrator   ~0038367

Last edited: 2013-11-24 06:37

One other possibly relevant point: this is only occurring on one of my devices, and it just so happens that it's the only device that has multiple storage locations recognized by MMA. Not sure if that's relevant, but I was thinking that perhaps playlists are being stored to > 1 location and that might somehow be causing the problem...

Also, today, the bug manifested itself differently: the playlist has duplicate tracks consecutively e.g. track1, track1, track1, track2, track2, track2, track3, Track3, track3,....

marek

2013-11-26 19:00

developer   ~0038382

I suspect that it is caused by incorrect storing of playlists to storage. So I've added sending of log there (build 187). Please send another log if it occurs again.

rusty

2013-11-27 20:48

administrator   ~0038402

Last edited: 2013-11-27 20:49

New log ID from user Irankine using build 186:
FNHD7RS4BS (this is the second of 2--another immediately preceeds it).

marek

2013-11-28 23:30

developer   ~0038421

Unfortunately the log wasn't uploaded (some network error). Where I can find a contact to Irankine user? It is probably stored on his device as /MediaMonkey/logs/log-FNHD7RS4BS.zip . So we need this file to be sent manually.

rusty

2013-11-29 17:27

administrator   ~0038426

Waiting for update from user. Also, cc:ed Marek on forum thread with the user, so marek can contact the user directly.

marek

2013-12-02 14:57

developer   ~0038458

Neither second log was uploaded. Waiting for user. He will send it via mail.

rusty

2013-12-02 21:27

administrator   ~0038467

User has posted debug information at ticket OLV-481060

marek

2013-12-04 18:15

developer   ~0038485

Fixed in build 191

There were more issues:

The trigger was updating situation when size of file in MMA and MMW was different. Comparing of size was recently added due to redownload of manually changed file in MMW or MMA.

1. The size was different because "Copy Artwork to file tags" in Tagging in MMW was enabled and adding of artwork changed the size. So it was re-downloaded each sync.

2. Size was compared for tracks with enabled autoconversion. It caused sync failure.

3. Bug in redownload of tracks caused duplicates.

rusty

2013-12-06 19:59

administrator   ~0038561

Last edited: 2013-12-06 20:04

Tested MMA 192 / MMW 1675 and this issue can still be replicated as follows:

1 clean device (i.e. remove /MediaMonkey and /Playlist directories and delete app data), but retain existing sync profile in MMW
2 perform wifi sync
--> Playlists sync as expected (1 autoplaylist, 5 static playlists)
3 Play a track from the autoplaylist, and change another track's rating from the autoplaylist
4 perform wifi sync
--> metadata updates to MMW
5 Do the same test in MMW i.e. play a track from the autoplaylist, and change a track's rating from the autoplaylist
6 perform wifi sync
--> metadata updates to MMW, but this time the playlist also updates (not sure why--the change in metadata shouldn't have resulted in a change to the playlist)
--> upon examining the autoplaylist in MMW, the number of tracks has doubled!!

Note: MMA/MMW are configured for bi-di sync

MMA debug log submitted: AQ0GQ9S9FN

EDIT: the really strange thing is that when I open the playlist itself, and look at the track numbers, I see only 1066 tracks (the correct number of tracks). However, when I look at the playlists view, it shows 'Good stuff' 2132 tracks!!

So the bug is twofold:
a) the playlist is updated unnecessarily (even though all sync operations were over wifi--there was no switching between wifi and USB)
b) the number of tracks listed in the playlists view doubles, even though the playlist itself remains with the same number of tracks.

Ludek

2013-12-07 11:14

developer   ~0038577

Last edited: 2013-12-07 11:35

I cannot replicate and I also don't understand how this could happen, because auto-playlists are not bi-di synced at all.
i.e. changes in an auto-playlist in MMA are not propagated to MMW, because auto-playlist is defined by rules.


Neverthless by testing this I found another issue (regression?), tested both MMA 189 and MMA 192 and after performing USB sync of an auto-playlist, the auto playlist is twice (duplicated) in MMA !!!
I verified that it is not MMW issue, because MMW writes it only once to mmstore.db.synced and as M3U, tracked as 0011559

The really strange thing is that the first playlist is correct (includes 8 files), but the second includes 32 files! Every file is 4 times there, so the playlist looks like:
1,2,...,6,7,8,1,2..8,1,2,..,8,1,..,8
so it has symptomps of this issue!

This seems to be always reproducable on my end, so Marek ask me if you can't replicate and need more info.

marek

2013-12-10 15:00

developer   ~0038658

I think that Ludek's issue was fixed in 0011559

b) But Rusty's issue is something different. Only the number of tracks wasn't correctly updated. Will be fixed in build 197

a) I am not able to reproduce it but I have some details from log.

19:44:34 - first wifi sync
             - modification of rating was sent to MMW
             - no playlist was changed
19:44:58 - end of sync
19:48:48 - Good stuff playlist was somehow changed in MMW. I don't know how. Maybe Ludek knows what can change the modified time.
19:49:09 - second wifi sync
             - no playlist is updated from MMA to MMW!
             - no modification is sent from MMA to MMW!
             - Good stuff playlists is newer in MMW so it is updated from MMA to MMW. It still contains 1066 tracks.

Ludek

2013-12-10 15:30

developer   ~0038662

Last edited: 2013-12-10 15:39

Assigned to Rusty for testing whether the issue still occurs in MMA 197+

Rusty, I guess that content of the auto-playlist has changed, how is the auto-playlist defined? Note that MMW checks auto-playlist content before each sync and if the content has changed then it updates its timestamp in order to propagate the changes to MMA.

If you are sure that this is not the case then please generate MMW log.

rusty

2013-12-10 17:16

administrator   ~0038668

a) The bug still occurs with MMA197/MMW1677. Uploaded debug log to the ftp server. It shows a simplified test case:
6610 Initiated wifi sync (bidi disabled)
12182 Played 'Somewhere they can't find me in MMW'
14260 Changed rating of Anji from 3.5 to 5
14504 Plugged in device
17254 Initiated usb auto-sync
43125 Accepted confirmation dialog (having disabled the proposed deletions)
43327 Playlists are updated

Note: I see that all playlists are copied--not just the one associated with the edited tracks. So this may be related to Time Synchronization (issue 4 at 0011298).

p.s. we may want to open this in a new bug since the original issue seems to be resolved.

b) fixed--the number of tracks in the playlist is now shown correctly

Ludek

2013-12-10 18:18

developer   ~0038673

Last edited: 2013-12-10 18:55

This seems to be another test case with the USB sync after WiFi sync, nevertheless I see this in the log:
TAndroidDBHandler.WritePlaylist, PC change: 2013-10-25 18:09:04, Device change: 2013-10-25 18:08:59

i.e. 5 second difference for each playlist, but this is ignored, MMW playlist needs to be at least 10 seconds newer than MMA playlist to re-write.
The 5 seconds is there because MMW takes the time shift between Device and PC from MMA DB (22 seconds in your case). i.e. 0011524:0038527 issue

Nevertheless I see that M3U were re-copied, this seems to be because MMA creates them slightly differently during WiFi sync thus MMW re-copy them.
MMW doesn't recopy them if the M3U file is exact bit copy (issue 0011068).
Note that this is corect, because if e.g. MMW creates M3U with extended info / UTF-8 / Linux line separator. Then MMW correctly overwrites the M3U on the device to respect M3U settings in MMW.

That said I don't see a bug here.

rusty

2013-12-10 19:00

administrator   ~0038674

a) Re. the message that appears during USB sync, that is confusing to the user, since it appears that playlists sync even though they shouldn't. That said, it's a pretty minor issue.

As far as the originally reported problem, it seems to be resolved.