View Issue Details

IDProjectCategoryView StatusLast Update
0014594MMW v4Synchronizationpublic2020-12-04 15:35
Reporterrusty Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Fixed in Version4.1.20 
Summary0014594: Wi-Fi sync fails in some cases (related to temporal network dead links)
DescriptionUpon testing MMW 4.1.19 (updated install, new sync profile) vs MMA 1.3.2.743 (clean install), I've repeatedly experienced a problem in which synchronization fails, apparently in related to failed auto-conversion (see attached images and logs).

The problem occurs as follows:
1) Install MMA (to Nexus 5x / Android 8.1)
2) Configure sync profile in MMA (adding 2 playlists to the the auto-sync list: Channukah and 4 Stars +)
3) Close MMA
4) In MMW, modify the auto-conversion rules for the newly created sync profile
5) In MMA initiate auto-sync
--> Sync fails after copying 2 tracks (up to line 7557 in the MMW log). Playlists also fail to sync (although M3U files do appear to have been copied to the /Playlists directory). See image 1.
6) Initiate auto-sync again
--> Most tracks and playlists sync however there's an error indicating that 5 of the tracks failed to sync. See image 2.

MMA debug log: PFP9ML69DV
MMW log (attached)

Note:
- The first time that this error occurred (I don't have a log of this), all syncs subsequent to the initial sync also failed but in a strange manner: the sync appeared to succeed, but all of the missing tracks and playlists failed to sync).
- The problem is triggered by tracks that are in the playlist that have dead links. For some reason this seems to break wi-fi sync--sometimes permanently.
TagsNo tags attached.
Attached Files
14594_sync1.png (158,499 bytes)   
14594_sync1.png (158,499 bytes)   
14594_sync2.png (137,141 bytes)   
14594_sync2.png (137,141 bytes)   
bug14594.7z (385,826 bytes)
Fixed in build1860

Relationships

related to 0012721 closedmarek MMA Failed conversion error appears when it shouldn't  
related to 0014374 closedpeke MMW v4 WiFi-Sync: Incomplete/slow sync when some network files are inaccessible 
related to 0014505 closedLudek MMW v4 Network Playback: Non Accessible tracks block Playback 
related to 0017166 closedLudek MMW 5 Upgrade to 5.x from 4.x: Artwork may fail to shown on first run 
child of 0011842 closedLudek MMW v4 Wi-Fi sync: in some cases MMW returns HTTP 202 

Activities

Ludek

2017-12-18 14:38

developer   ~0049421

Last edited: 2017-12-18 19:43

Tested clean install of MMA 1.3.1 and MMW 4.1.19 according to Rusty's steps and (same as Peke) was unable to replicate the issue.

But based on the Rusty's MMW log sync was terminated by MMA because of the "Marek's error", we called it "HTTP 202 issue" in the past ( 0011842 ).

1) MMA asked for sync-list
2) MMA asked for some of the files on the sync-list, namely 36,340,2879,181,185,186,234,3832,3995,412,10,1625,441,13584,5560,735,795,1641,6198,6,6583,6759,16447,20474 etc. -- which started conversion of those tracks, but MMA didn't asked for track 12777 at all (it is the problematic track, see item 6 later)
3) MMA asked for "already converted list" and MMW served track ID 36 that has been already converted meanwhile.
4) MMA successfully downloaded track ID 36
5) MMA asked for "already converted list" again, but there was no new track converted, conversion was still in process so MMW returned empty list (without the 'Completed' container notifying MMA that the conversion is still in progress)
6) MMA asked for the track 12777 which started conversion of this track and returned HTTP 202 to notify MMA that this track is being converted
=> MMA terminated the sync (Marek's error on sync2.png screengrap)

So I don't see any reason for the Marek's error, in the past this error meant that already converted track returned HTTP 202 again (i.e. converting again), but track 12777 has never been on the "already converted list" and MMA asked the track for the first time!!

rusty

2017-12-18 18:32

administrator   ~0049425

Last edited: 2017-12-18 19:16

Update: To review, there are 2 issues:
1) The initial sync on a clean install always stops with the 'Marek error message' when sync reaches a track on the sync list that has a dead link.
2) On one occasion, subsequent syncs all failed as well. MMA indicated that the sync completed, but the missing tracks and playlists did not sync.

The the bug occurs consistently for me. i.e. each time I do a clean install and sync a playlist that contains a couple of tracks with a dead link --> the problem occurs.

Note: the only non-default sync settings in my test environment are:
1) Enabled: Auto-sync device content
2) Enabled: Delete unselected content copies
3) In MMW, Enabled: Auto-conversion for 'Any audio, Above 192 Kbps'

EDIT: note though that upon further testing, I'm unable to replicate the problem, so I'm no longer sure what the trigger actually is :-(

marek

2017-12-18 20:05

developer   ~0049428

It is exactly as Ludek described. In step 6) MMA asked for track 12777 because no AC tracks were prepared. This track should not be converted according synclist. So MMW should not respond HTTP 202:

<item id="0DeviceID=026a8181bab3c7ab.0.b6e37985-2a4e-4b88-8dc8-87525a9d6b25_ItemID=12777.mp3" parentID="0" restricted="1">
    <dc:title>Everything She Wants
    </dc:title>
    <dc:creator>Wham!
    </dc:creator>
    <dc:date>1984
    </dc:date>
    <upnp:artist role="Performer">Wham!
    </upnp:artist>
    <upnp:artist role="AlbumArtist">Wham!
    </upnp:artist>
    <upnp:album>Make It Big
    </upnp:album>
    <upnp:genre>Pop
    </upnp:genre>
    <upnp:albumArtURI dlna:profileID="JPEG_TN">http://192.168.0.161:62514/100000366.jpg
    </upnp:albumArtURI>
    <upnp:originalTrackNumber>2
    </upnp:originalTrackNumber>
    <upnp:PlayCounter>1
    </upnp:PlayCounter>
    <upnp:rating>80
    </upnp:rating>
    <upnp:MM_TargetPath>\Music\Wham!\Make It Big\02 Wham! - Everything She Wants.mp3
    </upnp:MM_TargetPath>
    <upnp:MM_LastModified>2015-07-21 15:08:40
    </upnp:MM_LastModified>
    <upnp:MM_LastTimePlayed>2015-07-14 14:05:54
    </upnp:MM_LastTimePlayed>
    <upnp:MM_ArtworkModified>1899-12-30 00:00:00
    </upnp:MM_ArtworkModified>
    <upnp:MM_VolumeLeveling>0
    </upnp:MM_VolumeLeveling>
    <upnp:MM_TrackGain>-999999
    </upnp:MM_TrackGain>
    <upnp:MM_AlbumGain>-999999
    </upnp:MM_AlbumGain>
    <upnp:MM_ItemID>12777
    </upnp:MM_ItemID>
    <upnp:MM_TrackType>0
    </upnp:MM_TrackType>
    <res duration="0:05:02.000" bitrate="165000" sampleFrequency="44100" nrAudioChannels="2" protocolInfo="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000">http://192.168.0.161:62514/DeviceID=026a8181bab3c7ab.0.b6e37985-2a4e-4b88-8dc8-87525a9d6b25_ItemID=12777.mp3
    </res>
    <upnp:class>object.item.audioItem.musicTrack
    </upnp:class>
  </item>

Ludek

2017-12-18 20:55

developer   ~0049429

Last edited: 2017-12-18 21:39

In MMW code I see that the hash code isn't there only when the track (to be converted) is a deadlink (this was due to 0012721 ), but this file isn't a deadlink. So it seems that there is an inconsistent "deadlink state" of this file. I see it is a network file so it might be inaccessible just temporary (verifying further...), but at least we have a clue finally.

EDIT: The inconsistent "deadlink state" is caused by our optimizations in 4.1.18 (0014374, 0014505)
Assigned to me for a fix.

Ludek

2017-12-18 22:34

developer   ~0049430

Last edited: 2017-12-18 22:42

Fixed in 4.1.20.1860 and merged to 5.0.0.2089

Note that I had to modify the original fix of 0012721 , so dead-links that needs to be converted are not in the "Unable to download" error list in MMA anymore.
This is fixed by Marek in the next MMA build (0012721).

peke

2017-12-19 13:19

developer   ~0049439

Verified 1860

rusty

2018-01-25 15:42

administrator   ~0049559

Verified 1864.