View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013123 | MMW v4 | Synchronization | public | 2016-02-11 04:26 | 2016-05-21 00:21 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Windows | OS | 7 | OS Version | - |
| Product Version | 4.1.11 | ||||
| Target Version | 4.1.12 | Fixed in Version | 4.1.12 | ||
| Summary | 0013123: USB: Synchronization reports not enough space | ||||
| Description | On Initial Sync MMW 1783 copied all the tracks to SDCard for MMA 546 and as sync profile is set to have one playlist that always sync 5 Random tracks from Library sync always have only 5 tracks to sync. USB sync each time wants to delete existing due teh not enough space and re-sync. Wi-Fi Works flawlessly (Last sync in LOG) Uploading LOG, Profile, ScreenShot, MM.DB, and LGVerizon Files on FTP | ||||
| Steps To Reproduce | Steps to reproduce: 1. Sync only playlists not music (1 Static with 300-500 Tracks, 2 Static 5-10 tracks, 1 Auto-Playlist That will randomly select 5 non played accessible library tracks totaling around 2GB) 2. Delete content disabled 3. Sync With USB 4. Wait till sync finishes 5. Re-Connect Device 6. Go To profile and only ~39MB needs to be sync eg. 5 Tracks 7. Press sync. 8. If full sync (in my case 2gb where there was only 1.3gb free) is larger than free space on device than MMW prompts for Deletion even only 39MB needs to be synced. (See uploaded JPG. File) 9. Cancel Sync 10. Init Wi-Fi Sync 11. Only 5 tracks are synced | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1784 | ||||
|
|
Peke indicated that the same issue happens with 4.1.10 In the debug log I see that MMW wanted to re-upload 429 files because: 1. The files were not found as synced by MMW (probably due to device profile deletion?) 2. Either file timestamp in PC changed or there was a size mismatch, i.e. file size in MMW differs from the size noted in MMA's database (mmstore.db.media._size). But based on revision it seems that MMW shouldn't re-upload in case of size mismatch, but only when file timestamp is newer in PC. The size mismatch condition is there from the time of MM 2.5 when there was no bi-di sync yet. Nevertheless in this case it seems that MMW really must count the size badly for some reason, because those 429 files will be only re-uploaded so the needed space should be sufficient. So the issue is the false positive warning. Looking into code I don't see a reason for it, I had a suspection about zero or bad filesize in mmstore.db, but it doesn't seem to be the case |
|
|
Peke, I uploaded new MediaMonkey.exe to FTP: staff_files/forPeke/MediaMonkey.exe Please generate debug log using it, based on your log it is unclear why MMW did not have the info that the file was synced by MMW previously, it looks like if you deleted the device profile so the info was lost. Did you delete the profile? Then MMW wanted to recopy because it thought that the files was not uploaded by MMW and there was size/timestamp mismatch. It is also unclear why it counted the space estimation badly, I should see more in the new log. |
|
|
Based on the update log: 1) Peke can no longer reproduce the unsufficient space message 2) The reasons for re-uploading the tracks are that: a) MMW cannot find them as synced by MMW (device profile could be deleted) b) MMW takes incorrect timestamp from mmstore.db (media.date_sync_mediastore), it is 1970-01-01 00:00:02 and thus thinks that the device file is older than the PC version and wants to re-upload it I should probably use rather media.date_sync in this case, the strange thing is that in Peke's mmstore.db the media.date_sync is null for many tracks that were by evidence synced from MMW, looking into this... |
|
|
Item 2b) Fixed in 4.1.12.1784 and also added skipcount sync (was missing in case of USB sync) Item 1 (the original issue) is not reproducible by Peke anymore, but I enhanced debug messages so we should see more if it happens again. EDIT: Thanks to 0013126:0044137 the reason for 2A is also clear now, it is probably the same cause as for 0013126:0044137 (on write-limited KitKat devices) |
|
|
Verified 1795 No regressions found |
