View Issue Details

IDProjectCategoryView StatusLast Update
0011278MediaMonkey 4Synchronizationpublic2021-05-17 09:28
Reporterlowlander Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version4.1 
Fixed in Version4.1 
Summary0011278: Wifi Sync: Possible out of space issue when conversion is faster than copying
DescriptionDuring 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 ReproduceAt 190 files of the sync the cache was up to 2.5GB for the sync.
Additional Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=12&t=74266
TagsNo tags attached.
Fixed in build1683

Relationships

related to 0011842 closedLudek Wi-Fi sync: in some cases MMW returns HTTP 202 
related to 0012440 closedLudek No feedback to user that temp drive has insufficient free space 
related to 0010472 closedLudek Auto-Conversion fills drive 

Activities

lowlander

2013-09-17 03:49

developer   ~0037569

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).

Ludek

2013-11-03 21:55

developer   ~0038160

Last edited: 2013-11-03 22:01

View 4 revisions

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...

Ludek

2013-11-06 19:48

developer   ~0038210

Last edited: 2013-11-06 20:01

View 4 revisions

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.

Ludek

2013-11-06 20:10

developer   ~0038212

Fixed in build 1670.

lowlander

2013-11-06 23:03

developer   ~0038213

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.

lowlander

2013-12-21 18:00

developer   ~0038941

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.

Ludek

2013-12-22 13:10

developer   ~0038960

Last edited: 2013-12-22 14:08

View 15 revisions

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)?

lowlander

2013-12-22 18:40

developer   ~0038969

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).

lowlander

2013-12-22 18:45

developer   ~0038970

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.

Ludek

2013-12-22 19:40

developer   ~0038972

Last edited: 2013-12-22 20:18

View 5 revisions

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

lowlander

2013-12-22 21:28

developer   ~0038987

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).

Ludek

2014-02-13 16:58

developer   ~0039580

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).