View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011826 | MMA | Synchronization | public | 2014-02-01 22:21 | 2014-09-28 01:23 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.4 | ||||
| Target Version | 1.0.4 | Fixed in Version | 1.0.7 | ||
| Summary | 0011826: Wifi Sync fails on BLU DASH | ||||
| Description | I did a successful sync, then did a second sync that included more items and it failed and MMA jumped to home screen. Debug log (capturing both syncs) on FTP. MMA log 4RST732FQ (several others have been submitted from this device over the past week). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 304 | ||||
|
|
It seems that the Audiobooks Playlist is causing problems. I disabled it for sync and added another Playlist and sync worked. Any clues in log as to why Audiobooks fails to sync? |
|
|
It seems to be related to really long list of tracks for autoconversion. And it looks like it occurs when you turn off the phone (or maybe the screen times out). There is an issue that is most probably in implementation of sqlite database. But could you please try to generate new log. I want to verify my assumption. Thanks. |
|
|
Should I only sync the Audiobook Playlist (it seems to be the one failing) or do the full sync for the log? It seems that although MMW is auto-converting files that MMA is stuck on the downloading... screen which is the screen prior to the screen showing the actual files being downloaded. |
|
|
Well yes, that is the phase when it fails. I need a second log, but it might be with the same synclist. I think that in your case it is related to number of autoconversions. So you can try it with the audiobooks only. But I don't know whether it occurs. It doesn't matter what you will sync. I just need another log from failed sync. |
|
|
It is syncing right now, which means it has gotten further than normally (with Audiobooks enabled). In this case I kept the screen alive and it spend several minutes on the Downloading, preparing download... screen. Much longer than my Samsung phone (which has several complex AutoPlaylists to prepare). However it's set to sync more files (0000323:0002500 vs. 0000198:0001000 on the Samsung). So your hunch of screen time out during Downloading, preparing download... screen as the source of the failure may be correct. |
|
|
Sync seems to have run fine (device was off due to low battery when I returned). Do you need me to try to let sync fail by letting screen time out? If so should I let screen timeout during Downloading state? |
|
|
Yes, that would be great.. I have no idea why it might be related to screen timeout but it looks like it is. We have to inspect the code. But new log that confirms it will be very helpful. |
|
|
Ran a new test where I kept screen alive till delete confirmation. Sync was successful (most files including Audiobooks were already on device). |
|
|
Fixed in build 304 It was already fixed and there were changes in SQLite database that helped to fix it too. |
|
|
Verified 303 |
