View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011524 | MMW v4 | Synchronization | public | 2013-11-27 22:44 | 2013-12-10 03:22 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1 | Fixed in Version | 4.1 | ||
| Summary | 0011524: Playlists sync from Android device (with MMA) unnecessarily (over USB) | ||||
| Description | 1 Perform WiFi sync for several playlists 2 Perform USB auto-sync --> MMW prompts to update the playlists on the server, even though everything is already in sync from Step 1! Tested with MMW 1672 and MMA 187 This doesn't occur consistently--it always occurs with my GS3/JB 4.3, but doesn't occur with a Nexus 5/JB 4.4. Both devices are 1 minute ahead of the time on the PC. Any ideas? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1676 | ||||
| duplicate of | 0011481 | closed | rusty | MMA | Some playlists get synched with multiple copies of the tracks within |
| related to | 0011511 | closed | Ludek | MMW v4 | When browsing Android device with MMA, MMW doesn't display play history correctly |
| related to | 0011298 | closed | marek | MMA | USB Sync: Playlists are sometimes disappearing |
| related to | 0011545 | closed | marek | MMA | When browsed in MMW, unplayed tracks show a last played date of 1/1/1970 |
|
|
Note also: Podcasts were resynced over USB to the device as well--even though they had already been WiFi synced. It seems that somehow, MMW thinks that certain playlists and tracks were modified. Could it be related to 0011354 (the 'Not an valid integer value' bug occurred at the beginning of that sync operation). |
|
|
The only problem may be in the timestamp, if both devices are 1 minute ahead, then probably MMW failed to get the correct time delta over USB, but hard to predict without provided debug log, can you generate debug log? |
|
|
Debug log illustrating the USB Auto-sync subsequent to Wifi sync appears in bug 0011298. |
|
|
In the log I see lines like this: TAndroidDBHandler.SyncBackPlaylist? : PlaylistName: boney list1 PC change: 2013-11-26 23:03:19, Device change: 2013-11-26 23:03:52 i.e. for many playlists the device playtlist is 30 seconds newer, so it confirms my speculations. It failed to get the time delta over MTP, I do it by uploading a dummy file (file_time_delta) that has 0 KB and by downloading it back via MTP, this way I am able to get the time delta, but in your case it failed for some reason. If you create file called 'file_time_delta' (without extension) and copy it into the device via Windows Explorer, does it show date modified correctly? Based on the log I guess it doesn't work for your device and shows a value like 01/01/1970? |
|
|
When I create 'file_time_delta' and copy it to the device via Windows Explorer, it gets copied with the correct timestamp. However, I suspect that you're on to something, because another user (see ticket: FVK-203242 ) is experiencing problems with faulty play history synchronization, where last played dates show non-sensical times in 1969/1970! |
|
|
Faulty play history synchronization is not related to this bug, Android/Linux systems uses data values in seconds from 01/01/1970, so the data was probably zero. But looking at the ticket the 01/01/1970 is shown only in MMW interface for device tracks. Note that I can also replicate it, 01/01/1970 is shown for all MMA tracks in my case, it is because in MMA's DB the media.last_time_played = null - tracked as 0011545 --------------------- Back to the original issue: I currently ignore time shift values that are greater than 100 days, there zero was used in your case. I made some steps in build 1673 that could prevent from this, if I cannot get the time shift (like in case of your device) then I retry it several times with several different filenames and different delays between writing and reading the dummy file_time_delta file. So please retry with 1673 and generate log |
|
|
I used the log attached to issue 0011523 on FTP and I see that unfortunatelly it doesn't help :-( The time shift is still 114 years in your case, in addition I made a mistake in 1673 and such a value is not ignored now!!!, so I reverted the changes from 1673 and we need to continue finding a solution. EDIT (by Rusty): According to Ludek, the ramification of the reversion is that playlists (and not tracks, because tracks have individual timestamps) may be synced unnecessarily because MMW/MMA can't properly ascertain the timeshift between the PC and the device. The workaround is to sync exclusivelly via USB or exclusivelly via WiFi. |
|
|
Reverted in 1675. To understand: This issue is quite a special, you performed WiFi sync where MMA find that the device is 1 minute ahead, then subsequently MMW fails to find this and therefore it thinks that the device playlist is 1 minute newer. It does not affect tracks, because for tracks we sync only metadata updates and each individial metadata update has its own timestamp. Workaround for this issue is to sync exclusivelly via USB or exclusivelly via WiFi, nevertheless I guess I will need to resolve it by comparing exact content of each playlist, because I cannot rely on getting the proper time shift between PC and device as we can see, and I don't see another solution how to get the time shift via USB :-( |
|
|
Further IM discussion revealed that the best solution fornow seems to be: If MMW fails to get the proper time shift over MTP, then it would use the value from MMA's DB, i.e. MMA will store the time shift in MMA's DB and update it on each WiFi sync. Marek, could you add this kind of info to MMA's DB? |
|
|
Added to MMA build 192 It is in Info table as server_delta_time in seconds. Positive values are in case of MMW time is before MMA time. |
|
|
Fixed in build 1676 + verified that both values (using file and using DB) are same, so should work fine. The value from DB is used only when the value got using file is more than 100 days (like in your case). |
|
|
Verified 1677 |
