View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014374 | MMW v4 | Synchronization | public | 2017-08-31 21:41 | 2023-10-27 14:40 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.1 | ||||
| Target Version | 4.1.18 | ||||
| Summary | 0014374: WiFi-Sync: Incomplete/slow sync when some network files are inaccessible | ||||
| Description | On 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. Log ID: 6MJFFI1A6T 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. Log ID: 4N5V1TBHTY Description: 4th sync very very slow now only 7 tracks failed. Log ID: 8RFMAI4WHS Description: 5th each time it is slower and slower even less tracks are synced few less failed Log ID: 4MCS2BIUBW Description: 6th only Two failed Log ID: T5ZTBVY5JW Description: 7th one from 6th sync passed one failed left Log ID: NHVH5JBFQR 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)") | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1848 | ||||
| related to | 0014379 | closed | Ludek | MMW v4 | Find more from same doesn't work for tracks on the network |
| related to | 0014594 | closed | Ludek | MMW v4 | Wi-Fi sync fails in some cases (related to temporal network dead links) |
| related to | 0014791 | closed | Ludek | MMW 5 | Playback: Network tracks do not resume on wake up from sleep |
| related to | 0016471 | feedback | rusty | MMA | Wi-Fi Sync: Playlists fail to update correctly when select by 'Random (refresh all)' is used |
| related to | 0019387 | closed | michal | MMW 5 | Playing numerous inaccessible tracks slows UI interactions |
|
|
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) |
|
|
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. |
|
|
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\ |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
verified 1848 |
