View Issue Details

IDProjectCategoryView StatusLast Update
0011842MediaMonkey 4Synchronizationpublic2017-12-18 14:40
Reportermarek Assigned To 
PriorityurgentSeveritymajorReproducibilitysometimes
Status closedResolutionfixed 
Target Version4.1.10Fixed in Version4.1.10 
Summary0011842: Wi-Fi sync: in some cases MMW returns HTTP 202
DescriptionMMW returns response code 202 during wifi sync. This is mostly related to tracks that are autoconverted. MMW this returns in situation when tracks should be already converted and ready for download.

Btw this bug occurs quite often for approximately two months (approximately 150 occurrences in last two builds)

I went through the logs and I have following info:

1. log: Track were converted and sent as prepared to MMA. First try to download failed on connection timeout. Second try failed on HTTP 202 response.

2. log: Tracks were converted and sent as prepared to MMA. At least one track (/storage/emulated/0/Music/José José/Mujeriego/10 Dile Gracias A La Vida.mp3) was successfully downloaded. Next track (from same batch/DIDL of prepared tracks) failed on HTTP 202 response. The tracks was /storage/emulated/0/Music/Kardinal Offishall/Not 4 Sale/03 Dangerous.mp3

3. log: 280 tracks were converted at once. I.e. MMA received DIDL with 280 prepared tracks. Download of first track failed on 202 (/storage/extSdCard/Music/Coldplay-A Rush of Blood to the Head/1002-Coldplay-In My Place.mp3). I have attached the xml with prepared tracks (please note that the xml might not be complete due to trimming of log rows).

4. log: This is most interesting but rare. This time the track was without hash, so it shouldn't be converted. At least one track was downloaded successfully (/storage/sdcard1/Music/Linkin Park/Hybrid Theory/12 Linkin Park - Pushing Me Away.m4a). But it took only 1700 ms .. 3 104 KB. Quite weird. After that, its lyrics were downloaded. Next track failed on HTTP 202 (/storage/sdcard1/Music/Linkin Park/Live from SoHo (iTunes Exclusive) - EP/03 Linkin Park - Shadow of the Day (Live).m4p).

I can add some toast message to inform user about necessity of sending MMW logs. I don't have any contact.
TagsNo tags attached.
Fixed in build1765

Relationships

related to 0011278 closedLudek MediaMonkey 4 Wifi Sync: Possible out of space issue when conversion is faster than copying 
parent of 0014594 closedLudek MediaMonkey 4 Wi-Fi sync fails in some cases (related to temporal network dead links) 
child of 0011275 closedLudek MediaMonkey for Android WiFi Sync: Tag changes (rating/playcount) are posted after building sync-list 

Activities

marek

2014-02-06 17:44

developer  

http202.xml (507,844 bytes)

Ludek

2014-02-06 20:19

developer   ~0039527

Last edited: 2014-02-07 12:33

View 7 revisions

I have revised the MMW code several times and haven't found a problem.

MMW returns 202 (Accepted) only if the file isn't converted yet or the conversion is in progress, but once the track was added on the list of already converted tracks then it should always return 200.

The only situations I can think of are:
1) User would change auto-convertion settings during the WiFi sync
2) User would manually delete the pre-converted file

But both these sound quite unprobable/rare cases.

I also haven't been able to simulate it another way so MMW log would be really helpful here as I don't have enough info.

Out of curiosity, isn't there a single forum report related to this WiFi sync failure?? We could contact such a user via forum link to generate MMW log.

Ludek

2014-02-07 12:31

developer   ~0039533

Last edited: 2014-02-07 12:31

View 2 revisions

Because MMA logs are useless in this situation, Marek changed it and MMA shows this error on the end of sync requesting the user to contact us.

Assigned back to me to review it again once we have contact/MMW log. And to add assertion directly to MMW 4.1.1 re this issue.

Ludek

2014-02-10 10:03

developer   ~0039545

Last edited: 2014-02-10 10:06

View 3 revisions

Re: 2) there is a speculation that an application removes the prepared files from temp when disk begins to be full, but it is just speculation.

To prevent this MMW should keep max 20 files in the temp when conversion is faster than copying (to be fixed in 4.1.1)

Ludek

2014-02-11 12:33

developer   ~0039559

Last edited: 2014-02-11 16:38

View 9 revisions

Finally one user contacted us so we could find more, even without MMW log I was able to reproduce (based on his MMA screenshot).

The key factor to reproduce is that at least 1 new file needs to be uploaded to the server, this is the trigger (4 months old regression caused by fixing 0011275:0037674).

I fixed it on MMW side in build 4.1.1.1693, but there is an easy and low risk workaround on MMA side though. If MMA would ask for converted list after file uploads and before initiation of the auto-conversion then this issue won't occur.

Assigned to Marek to implement the workaround (so that it works with 4.1.0.1692 correctly).

marek

2014-02-11 19:09

developer   ~0039564

Last edited: 2014-02-11 19:14

View 3 revisions

I tried it but it didn't help. It failed with http 202 again. Log is attached - it is the last sync...

Is there anything else I can try or we will leave it as is ?

marek

2014-02-11 19:11

developer  

log-conversion-upload.LOG (235,185 bytes)

marek

2014-02-11 20:15

developer   ~0039565

According to IM conversation, I have added a different workaround that works well.

Fixed in build 227

marek

2014-03-03 15:31

developer   ~0039751

Last edited: 2014-03-03 15:33

View 2 revisions

This issue still occurs.

Observed situations:

same as 1 in description)
 - MMW 4.1.1.1693
 - I have forwarded user's email to Ludek
 - Sync started and continued till connection problems. Connection was re-established but MMW returned 202 when first file after reconnection was tried to download.

similar to 3 in description)
 - MMW 4.1.1.1693
 - I don't have user's email.
 - It fails when some files were converted and sent as converted... it failed with http 202. One track was paired during sync. No track was uploaded.

marek

2014-03-13 20:43

developer   ~0039869

Request to contact us was added to build 232 of MMA. So we are waiting for email.

Ludek

2014-04-08 09:11

developer   ~0040076

Last edited: 2014-04-22 22:15

View 6 revisions

UPDATE:
So far we got two emails, one hasn't replied and the other (Alex) wrote:
"I'll see what I can do! I think I ran a maintenance cycle on MM Windows while MM Android was syncing. If I can reproduce I'll report back.
Weirdly MM Windows "lost" my Gold registration. It's been registered for months and then suddenly yesterday it wasn't. Could this be related somehow? I think this happened before the autoconversion error.
Many thanks!
Alex"

So in the Alex's case MMW lost Gold license while he was WiFi syncing with MMA and running DB maintenance at the same time, I requested more info from him, but he hasn't replied so far. The Gold licence lost during WiFi sync was reason for the HTTP 202.

-------------------------
UPDATE 2:
Another user (Elton):

A few days ago MMA showed a message about an error, I don't even remember what, asking to contact support, but I didn't as it happened just once so far. But I trust MMA is sending logs automatically, because I don't remember sending you any log or complain recently.
Anyway, I just installed the debug version and I'll try to send you a debug log if it happens again.

Ludek

2014-05-19 11:50

developer   ~0040214

Last edited: 2014-05-19 11:50

View 2 revisions

Finally we got useful log from user Marc.

Fixed in build 4.1.2.1705.

peke

2014-06-14 22:50

developer   ~0040279

Verified 1707

Ludek

2015-10-26 09:01

developer   ~0043179

Last edited: 2015-10-26 10:38

View 3 revisions

Re-opened, based on MMA logs this issue still happens in some environments.

Contacted the user and waiting for a debug log...

Ludek

2015-10-26 10:31

developer   ~0043180

Last edited: 2015-10-26 10:56

View 6 revisions

Further analyzing is showing that it could be a regression in 4.1.9 related to 0012837 - the timestamp solution there, grabbling more info...

Marek indicated that 95% of the logs are from 4.1.9 so there is a high probablity that it was caused by the timestamp solution in 0012837 , namely by an improper Date Added value in DB?

Fixed in 4.1.10.1765 as a possible cause (to be confirmed though), also still waiting for some MMW logs...

Ludek

2015-11-25 09:35

developer   ~0043399

Closing, several users confirmed the fix via emails.