View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011278 | MMW v4 | Synchronization | public | 2013-09-17 03:19 | 2021-05-17 09:28 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Fixed in Version | 4.1 | ||||
| Summary | 0011278: Wifi Sync: Possible out of space issue when conversion is faster than copying | ||||
| Description | During a wifi sync that any converted files is removed as soon as it has been synced/copied to the device. On large sync (when copying is too slow) this can lead to a large UPnP Cache and can cause failed sync due to running out of space. | ||||
| Steps To Reproduce | At 190 files of the sync the cache was up to 2.5GB for the sync. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=12&t=74266 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1683 | ||||
|
|
It may be an issue of conversion running much faster than sync as at near the end of sync the amount of files is reducing while still more than 200 files needing to be synced. Safeguards are needed however. Either sync adheres to UPnP cache size setting or waits with conversion when drive is full until some files are removed after they're synced to device and/or maintains some free space (especially important on system drive). |
|
|
Yes, the converted file is deleted once is copied to the device. If the conversion is faster than copying then MM uses the same rules as for UPnP. i.e. if the max quota (default 5G) is over or if there is not enough space then MM deletes the oldest converted file(s). So out of space exception shouldn't happen, but I am maybe seeing another issue, going to verify it... |
|
|
I verified that currently if there is not enough space (even after clearing UPnP cache) then this dialog is shown: 'There isn't enough free space to convert all files. Please clear space in the temporary directory: C:\...' [Retry] [Cancel] But I found a problem there, the code is old and it doesn't take into account the others threads (that are converting tracks simultaneously) when checking free space. This needs to be fixed. Also you seem to be right that in case of sync (both USB/Wifi) MM should rather wait for copying the tracks (that will free the space). And probably UPnP cache shouldn't be cleared during WiFi sync as it could be undesirable for some users. |
|
|
Fixed in build 1670. |
|
|
It would be impossible to create any converted video files as I've only set 75MB as UPnP cache, still they're created. Also it can only do 4 at a time (4 cores) so if cache size was respected it wouldn't be able to create file 5 and on. |
|
|
On 1681 MMW ran out of space, which is shown in the log, however there was no feedback to the user. (Note that MMW was actually failing to sync anything to device, thus cache was filling up (Using ASUS Transformer)) Debug on FTP. |
|
|
In the log I see that you performed USB auto-sync and that the pre-converted video files (MPG -> MP4 converted) failed to transfer to the device with MTP error code 80042003 You are true that there was a bug and the pre-converted file was not deleted immediatelly when it failed to transfer, it was deleted immediatelly only when successfully copied. => This is fixed in MMW build 1683. Nevertheless I wonder why the files fail to transfer to your Transformer. Looking at the MTP error codes here: http://msdn.microsoft.com/en-us/library/windows/desktop/ff801091(v=vs.85).aspx 0x80042003 indicates that the session handle of the operation is not a currently open session. This indicates an internal error in the MTP stack. Out of curiosity, is this MTP issue new for you with this device? I have never observed this myself, does it always fail to transfer these video files to the device? Googling it I guess it could be same issue as here: http://www.transformerforums.com/forum/asus-video/6996-plays-mkv-fine-but-cant-copy-mkv-files-tablet-via-windows-7-a-2.html ? There some users indicated that it is surprisingly related to DivX codec and if they changed file extension of the file then the file could be copied fine to the device, I guess it can be it (see the link for details)? |
|
|
It is new that no files were transferred. I've had sync issues in the past, but that was somewhere along the sync and likely due to HDD space running out. I can't recall if this was an internal or external sync (I believe internal), but I never had issues with internal sync. I've done wifi syncs which have been more successful (log 8D0NO8FGHH captures wifi sync where some files failed). |
|
|
I think in this case if MMW encounters an error copying files to the device there should be a way for the user to know and cancel sync. Interrupting sync could be a problem though (as some will leave PC). Solutions: 1) MMW could halt sync and ask user to continue (will annoy some) 2) MMW could halt failed file type sync and ask user to continue with those or not (slightly better) 3) MMW keep syncing, but displays dialog with info on copy failure. This should contain information on file, file type, type of copy failure and user options to cancel sync, cancel sync of failed file type (continuing with other file types). Option 3 has the benefit that sync will continue for those who left the PC (for sync overnight), as well as a providing an option to cancel for those with large syncs (mine would have lasted more than a day for nothing) all the while providing useful feedback on what is failing. |
|
|
But the error handling is already implemented for quite some time, if there is a file copy error, MMW shows the dialog "There was a problem synchronizing the following item(s):" with list of items that is displayed for 10 seconds when the error occurs and then again on the end of the whole sync. Wasn't it the case for you? EDIT: I have to correct myself, actually the error log is shown once on the end of whole sync: 0006219 |
|
|
I wasn't at the PC so can't attest to any temporary error messages. I canceled sync manually as soon as I saw (I saw problems in DBGView) that sync was failing to copy the video files to the device. In this case it was me catching the problem in DBGView and then checking on device for files that discovered the problem. Otherwise sync would have continued for a day for nothing (waste of resources). |
|
|
Resolved, the original issue has been fixed in 1683 The MTP issues are not fixeble by us, the error handling (shown log on the end of sync is all right). |
