View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011199 | MMA | Navigation | public | 2013-08-26 19:39 | 2013-11-08 16:41 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.4 | ||||
| Target Version | 1.0.4 | Fixed in Version | 1.0.4 | ||
| Summary | 0011199: Deleting large playlists takes several minutes | ||||
| Description | When the user attempts to delete a playlist that contains a lot of tracks, it takes several minutes to do so. e.g. a playlist of 1500 tracks takes 3 minutes to delete, during which the UI is locked and 'Deleting...' is displayed. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 182 | ||||
|
|
Note that the behavior isn't consistent. Performance seems to be much worse when deleting multiple playlists (or possibly when deleting playlists that were synced via USB). |
|
|
Also, I'm not certain that the problem is specifc to playlists. Upon synching where 2 tracks are auto-deleted, deletion of the second of 2 tracks takes ~5 minutes! This makes me wonder whether the behaviors described above have the same cause as those described in 0011201, and are cause by some sort of failure at the UPnP layer. (note: when these bugs occur, networking via the browser or ES File Explorer works fine i.e. there is no generalized networking problem). |
|
|
I just submitted 2 debug logs illustrating this (identified by 'bug 11199'). In the logs, I performed a wifi sync and 44 tracks were auto-deleted, but on the 44th track, mma is taking a really long time to delete the track. I sent the logs while mma was in process of deleting the track. |
|
|
I just submitted a log in which I manually deleted 3 playlists. But this time it only took 0000025:0000030 seconds: QHG7Y37L3K (still much longer than it should take). |
|
|
re 0037398 - this delay was caused by connection timeout after deletion of last file. But UI is not changed...there is no reason. Process flow is ok. Sync continued after successful second attempt. |
|
|
The strange thing is that these delays consistently seem to happen at deletion of the last file (or when downloading, at the second to last file). You can see this in the logs at 0011216. Note: this bug is currently tracking 2, possibly unrelated issues: 1) delay (can be minutes) at the last/second to last sync operation 2) delay (~20 seconds) when manually deleting playlists (though in some non-replicable cases it was taking 2-3 minutes) Re. the second issue: I've uploaded a new log: KW8DVT6753 |
|
|
1) Fixed in build 163 I've added some new messages indicating current sync progress so it doesn't look like delete is frozen. |
|
|
2) Added log messages, new log from build 163 is needed...thanks |
|
|
Debug log from build 167 uploaded: ERAUKQ8GOT Deleted playlist 'Good stuff' (0000198:0001000 tracks) took ~15s |
|
|
After discussion over IM, assigning to Martin because it looks like issue in TransactionManager. |
|
|
Fixed in build 181. |
|
|
Tested 181, and deleting playlist: 'Good Stuff' (consisting of 1078 tracks) still takes ~15s. |
|
|
Marek didn't include my commits to build 181. So he is going to create new one 182. It should take less than 1s now. |
|
|
Verified 182. |
