View Issue Details

IDProjectCategoryView StatusLast Update
0014374MediaMonkey (current)Synchronizationpublic2020-04-06 17:26
Status closedResolutionfixed 
Product Version4.1 
Target Version4.1.18Fixed in Version 
Summary0014374: WiFi-Sync: Incomplete/slow sync when some network files are inaccessible
DescriptionOn clean device no MMA tracks/playlists and new MMW profile it is needed around 10 constant syncs restarts to sync all tracks without single one failed and to update auto playlists changes correctly.

Note initial 425 tracks synced fast and correctly every other sync that had even one failed track was slow and it took 10-30 sec per track to be copied even only <20 tracks were synced.

After 8th sync when there was no failed tracks sync updates any subsequent sync worked normally eg. few tracks updated and playlists updated within seconds. as seen in 9'th sync.

Failed tracks on sync Log ID: QL5LRSKC33
Description: failed tracks
Possibly false positive, but log check just in case.
Description: 2nd sync
Second sync is much slower than 1st one even only 31 tracks uploaded. starting third sync
Log ID: 2H651Z2WKN
Description: 3rd sync
way much slower and 11 tracks failed.
Description: 4th sync very very slow now only 7 tracks failed.
Description: 5th each time it is slower and slower even less tracks are synced few less failed
Description: 6th only Two failed
Description: 7th one from 6th sync passed one failed left
Description: 8th No failed tracks
Log ID: 15Z4AIQ2E7
Description: 9th Finally sync update works as designed within 10 seconds few updated tracks only and no failed syncs.

Uploaded MMW sync log file on ftp "MMA/bugs/bug14374/" (Note: during DBG log I also played tracks that fail in sync eg. "116_mark_oh_-_united_(single_long_version)")
TagsNo tags attached.
Fixed in build1848


related to 0014379 closedLudek MediaMonkey (current) Find more from same doesn't work for tracks on the network 
related to 0014594 closedLudek MediaMonkey (current) Wi-Fi sync fails in some cases (related to temporal network dead links) 
related to 0014791 assignedLudek MediaMonkey (current) Playback: Network tracks do not resume on wake up from sleep 
related to 0016471 feedbackrusty MediaMonkey for Android Wi-Fi Sync: Playlists fail to update correctly when select by 'Random (refresh all)' is used 



2017-09-01 02:08

developer   ~0048635

I can confirm same behavior on two more devices.

Steps to reproduce:
1. Clean MMA install no MMW profile
2. press Sync now
3. SDCard
4. Select few playlists (few Auto playlists with files number limit <5 with random sort) totaling 500-700 files
5. Use Sync Now till no failed tracks are shown and only few tracks are synced along with those few auto playlists

NOTE: Sone tracks are located on LAN (wired in my case to QNAP Server)


2017-09-01 05:10

administrator   ~0048637

Last edited: 2017-09-01 05:11

View 2 revisions

fyi, I only tested Wi-Fi/USB syncs with smaller numbers of files (e.g. 50-100) and didn't observe any slowdowns or interruptions.


2017-09-01 10:31

developer   ~0048640

Last edited: 2017-09-01 10:52

View 4 revisions

Rusty, based on the MMW log Peke was testing Wi-Fi sync.

And based on the MMW log the slowdowns seems to be related to image serving, preparing the artwork JPG file took 30 seconds, looking into it...

To reproduce you need to clear the image cache, in the Peke case it is C:\Users\Peke\AppData\Local\Temp\MM_UPNP_Images\


2017-09-01 19:01

developer   ~0048649

Last edited: 2017-09-01 19:02

View 2 revisions

Peke, I cannot replicate, in my case all images are prepared/served in portion of a second, but in your log it takes from 30 to 50 seconds.

I added more ODS, please use MediaMonkey.exe from MMA/bugs/bug14374/
and generate new log.

Don't forget to delete C:\Users\Peke\AppData\Local\Temp\MM_UPNP_Images\ before the test to force re-creation of the images.


2017-09-01 22:37

developer   ~0048651

Last edited: 2017-09-01 23:13

View 3 revisions

There was no need to remove temp cache as playlists always add new tracks and cache is still small so there is high chance to get to create/prepare cache file.
Uploaded new log file "2017-09-02 new log file.rar"

Accompanying new MMA logs
Log ID: GPZ31ZUNTA Description: new sync 1 3/5 failed tracks
Log ID: PN1LRQIBK7 Description: new sync 2 No failed tracks

Note: Device is on charger, not moved and have Excellent WiFi connection


2017-09-02 12:28

developer   ~0048652

Thx, the slowdowns are somehow related to accessing files on network, e.g. just accessing cover list and getting file info for
\\QNAPNAS\Download\pyload\Music\The Official UK Top 40 Dance Singles Chart 02.09.2012 DreamsRG\26 LMFAO - Party Rock Anthem ft. Lauren Bennett GoonRock.mp3
took more than 30 seconds!

I added even more debug messages to see more (as it is still unclear what is causing the slow access).

I updated the EXE, please generate one more debug log. Thx.


2017-09-04 11:39

developer   ~0048656

Last edited: 2017-09-04 12:04

View 4 revisions

Based on the last log just call of System.SysUtils.FileExists() on \\QNAPNAS\Download\rtorrent\complete\100 OF THE VERY BEST 12 INCH AND EXTENDED FROM THE 80'S\093 Dire Straits - Money For Nothing ( Extended ).mp3
took more than 15 seconds.

Actually it seems that this network file is inaccessible?
Improved the checking of network file accessibility in build 1848, i.e. workarounded the freezing.

New EXE is uploaded, please test again whether everything is OK and generate new log. Thx.


2017-09-05 09:37

developer   ~0048660

Last edited: 2017-09-05 10:22

View 3 revisions

Based on the last Peke's log there are still some places in MMW where accessing the unavailable network files from \\QNAPNAS\ takes long time/freezes. Assigned to me for a fix.

Peke also indicated when opening Track properties -> Artwork it takes almost a minute to remove please wait dialog.

EDIT: Fixed and supplied new EXE to Peke to confirm the fixes


2017-09-06 01:05

developer   ~0048664

verified 1848