View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011842 | MMW v4 | Synchronization | public | 2014-02-06 17:44 | 2017-12-18 14:40 |
| Reporter | marek | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Target Version | 4.1.10 | Fixed in Version | 4.1.10 | ||
| Summary | 0011842: Wi-Fi sync: in some cases MMW returns HTTP 202 | ||||
| Description | MMW 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1765 | ||||
| related to | 0011278 | closed | Ludek | MMW v4 | Wifi Sync: Possible out of space issue when conversion is faster than copying |
| parent of | 0014594 | closed | Ludek | MMW v4 | Wi-Fi sync fails in some cases (related to temporal network dead links) |
| child of | 0011275 | closed | Ludek | MMA | WiFi Sync: Tag changes (rating/playcount) are posted after building sync-list |
|
|
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. |
|
|
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. |
|
|
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) |
|
|
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). |
|
|
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 ? |
|
|
According to IM conversation, I have added a different workaround that works well. Fixed in build 227 |
|
|
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. |
|
|
Request to contact us was added to build 232 of MMA. So we are waiting for email. |
|
|
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. |
|
|
Finally we got useful log from user Marc. Fixed in build 4.1.2.1705. |
|
|
Verified 1707 |
|
|
Re-opened, based on MMA logs this issue still happens in some environments. Contacted the user and waiting for a debug log... |
|
|
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... |
|
|
Closing, several users confirmed the fix via emails. |
