View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011560 | MMW v4 | Synchronization | public | 2013-12-08 21:22 | 2016-07-22 09:56 |
Reporter | marek | Assigned To | |||
Priority | urgent | Severity | major | Reproducibility | sometimes |
Status | resolved | Resolution | not fixable | ||
Platform | Windows | OS | 7 | OS Version | - |
Product Version | 4.1 | ||||
Target Version | 4.1 | ||||
Summary | 0011560: Usb sync with MMA fails sometimes | ||||
Description | I've made two syncs in a row. Only one playlist was on synclist. I observe some issues with this scenario. Scenario A (log-usbsync1.LOG): 1. First sync - ok 2. I have deleted all tracks in MMA (I didn't delete the playlist). 3. Second sync - confirmation dialog with update of playlist from MMA to MMW occurred. I didn't check the checkbox. 4. Error dialog with many copy failures was displayed. 5. Nothing was synced Scenario B (log-usbsync2.LOG): 1. First sync - ok 2. I have deleted 8 of 9 tracks. It doesn't matter. I tried to delete all tracks as in A and it occurred too. (I didn't delete the playlist). 3. Second sync - confirmation dialog with update of playlist from MMA to MMW occurred. I didn't check the checkbox. 4. Nothing was synced. So there are following issues: a) The confirmation dialog shouldn't occur because the playlist wasn't changed. Modified time is the same. It should be only updated in MMA. b) Error dialog in scenario A c) In both syncs the tracks were not resynced to MMA. I have checked the both DB on SD card (mmstore.db and mmstore.db.copy) and both was refreshed, i.e. without the deleted tracks. The strange thing is that MMW knew about changed playlist but didn't know about the tracks. After this occurs I am not able to sync anymore. After some time or maybe reconnection it works again. I will investigate more. Please note that logs contain more syncs. Look at last sync. This is a blocking issue for me because I cannot test other USB sync issues. I will create new build 193. Because build 192 contains regression. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Fixed in build | |||||
|
Btw. why you don't delete the mmstore.db.copy file when sync is finished ? |
|
In both logs it seems that deletion of the tracks in MMA somehow broken MTP transfer for you, I see that then every file failed to transfer to the device with error code: 8007001F I have not found that error code here: http://msdn.microsoft.com/en-us/library/windows/desktop/ff801091(v=vs.85).aspx , but by googling it I found this: http://speedmaxpc.com/library/errorcodes/windows-media-player/8007001f.htm All other issues are just consequences of the failed file transfers, also the the confirmation dialog to copy playlist back is consequence of this, because it failed to transfer the dummy file_time_delta file to find time shift between PC and device, nevertheless this has been already covered by 0011524 (in MMW 1676). I guess that once this happens then also Windows Explorer fails to transfer a file to the device, right? I will try if I can replicate and find a workaround. |
|
I cannot replicate the failed file transfer after deltion of tracks in MMA, in my case it is transferred always correctly (Galaxy Nexus, Android 4.2.1). Nevetheless the second issue is related to the fact that MMW doesn't update the device content before each sync (0008342), i.e. it still think that the tracks are in MMA even when they have been deleted, I fixed it in build 1677 so that for Android devices with database the contents are always re-scanned before each auto-sync: 0008342:0037842 |
|
Note that Peke also cannot replicate the failed MTP file transfers experienced by Marek, one way or the other based on the error code it is something on the MTP layer and we probably can't do much about it on MMW side. I will continue solving this with Marek once he experiences this again (to find whether there is a workaround). |
|
Marek indicated that his MTP troubles were caused by USB cable, after replacing USB cable the things work better, resolving ... |