|
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 :-(
|
|
|
|
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).
|
|
|
|
Verified 1860 |
|
|
|
Verified 1864. |
|
