View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010166 | MMA | General | public | 2012-12-06 21:23 | 2022-03-12 01:14 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.1 | ||||
| Target Version | 1.0.4 | Fixed in Version | 1.0.1 | ||
| Summary | 0010166: Scans are never-ending for some devices/environments | ||||
| Description | There have been several reports of MMA not completing scans of device content. http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=68918 http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=68919 Zombiefly indicated that he submitted a debug log, but I don't see it... No fix required at this point--needs more investigation. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 201 | ||||
| related to | 0009650 | closed | jiri | MMA | Scanning never completes in some cases |
| related to | 0010213 | closed | martin | MMA | Crash after Update |
| related to | 0010552 | closed | Ludek | MMW v4 | Nexus 7, JB 4.2.2, MTP sometimes freezes |
| related to | 0011481 | closed | rusty | MMA | Some playlists get synched with multiple copies of the tracks within |
| related to | 0010176 | closed | marek | MMA | MMA started to Show Duplicates (Regression) |
| related to | 0011501 | closed | martin | MMA | Playlist creation sometimes fails during scan |
| related to | 0011507 | closed | rusty | MMA | Scanning isn't detecting modifications to files |
| related to | 0012936 | resolved | martin | MMA | MediaStore sync takes too long |
|
|
It's probably resolved in build 73 or 74 due to a lot of fixes based on crash reports from users. |
|
|
Possible introduction of Regression like 0010176 |
|
|
User reports that this is still open at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=69030 Note: for many users this is fixed by removing the /MediaMonkey folder |
|
|
Many new fixes that could affect this in build 77. |
|
|
Reopened due the possible relation with 0010213 as after crash scan icon never goes away |
|
|
According to recent crashlogs (or a lack of them), this is probably resolved. |
|
|
Verified 100 |
|
|
This still can happen when: 1. Device is scanning 2. MMW creates db_copy_request to fetch Content 3. Scan never ends and mmstore.db.copy is never created NOTE: In case it gets created it is locked causing 0010552, then in case db_copy_request and mmstore.db.copy is manually deleted MMA Freezes and needs to be forcefully stopped. DDMS log and Video file is uploaded to FTP |
|
|
Fixed in build 125 |
|
|
Verified 125 |
|
|
Builds 157/158 exhibit endless scanning on startup for a device with 2 playlists and aprox 3000 tracks. I uninstalled the app from the device, deleted the /MediaMonkey directory from both the internal/external cards, and then Ran MMA --> scanning for 10+ minutes. Uploaded log BK87OFTYBH Note also: mma failed to terminate after exiting the app |
|
|
The problem went away after I deleted several playlists from the device. Here's the situation wrt playlists that existed: /sdcard/Playlists (internal): Good stuff.pla (0B), Hebrew.pla (0B), Sync Test.pla (0B) /extSdCard/Playlists (external): Good stuff.m3u, Hebrew.m3u When I deleted the 3 0B playlists on the internal card, the problem went away. Note: I believe those 0B playlists were created upon attempting to sync via USB using an earlier build--I'll retest; but regardless, such playlists shouldn't trigger this sort of problem. |
|
|
This problem was caused by really long MediaStore sync. There probably isn't relationship with these playlists. When you started it next time, it was already partly done... MediaStore has weird implementation of genres in earlier versions of API. And thus it takes so long. I will discuss it with Martin (who made this part of sync) and we can probably optimize it at least for newer APIs... |
|
|
Folder processing for folders view can take a long time during mediastore sync too. Assigning to Martin to review whether optimization is possible there. |
|
|
I've completely removed separate genre synchronization, that was made at the end of mediastore sync. It is working for all APIs. Sync of genres is now made immediately with tracks. Rusty, please retest with your library. It depends on number of genres and media. But my MediaStore sync was done in half the time now. But still...folders view preparation takes long-time... |
|
|
Tested build 159 on the same device and so far it has taken > 50 minutes to complete the scan. See log 6J1PM6U6VE (and another log immediately preceding that one). |
|
|
Note that when I deleted .m3u files from the device prior to running MMA, it seemed to take less time--could it be that the existance of .m3u files somehow slows down the scanning process? |
|
|
Assigning to Marek to review playlists scanning, as it seems to be the last part that needs to be reviewed... |
|
|
fyi: I tested earlier builds (152, 156) and the problem exists there as well. However, I'm not certain what causes the slow scanning as the issue occurs even when all playlists have been deleted. |
|
|
It is not caused by playlists. It is preparation of folder structure in DB. Martin already tried to optimize it so I don't know if anything can be improved. Reassigning back to him and I will forward him the log too. |
|
|
Added summary log messages to all sync parts and printing it at the end. If the issue is still occurring, complete log from new build 166 should be helpful. |
|
|
Tested build 167, and scanning 0000198:0001000 files took 10 minutes. Uploaded debug: PLWOMFKO5G |
|
|
I just did another test by deleting all content, deleting /MediaMonkey directories, and then doing a clean install of MMA. Then auto-sync via USB. --> endless scanning (so far > 30 minutes) Uploaded debug: 8JJQE85HZP EDIT: strangely, after I submitted the debug log, the 'hourglass' disappeared! |
|
|
Obviously something happened at 8JJQE85HZP Summary from logs: PLWOMFKO5G items time(ms) time(min) items/s MediaSync 1072 468110 7,8 2,3 FolderSync 1072 137775 2,3 7,8 8JJQE85HZP items time(ms) time(min) items/s MediaSync 1091 1639097 27,3 0,7 FolderSync 1091 126892 2,1 8,6 Summary from my devices: Nexus 7 items time(ms) time(min) items/s MediaSync 1253 361868 6,0 3,5 FolderSync 1253 101879 1,7 12,3 Mk16i items time(ms) time(min) items/s MediaSync 896 228381 3,8 3,9 FolderSync 896 72475 1,2 12,4 |
|
|
It seems that the slowdown is due to the generation of album arts. I have added logs, please attach log from build 172. |
|
|
Uploaded debug log of a scan that was going on for 32 minutes and counting: FWZ87VAH1T Note: after submitting the debug log, the 'hourglass' disappeared, so I wonder if perhaps the problem is that the 'hourglass' keeps displaying long after the scan has completed. |
|
|
I've just submitted 2 new debug logs using build 183. They were sent after MMA was scanning for 1.5 hours: Log 1: unknown ID (I forgot to note it) Log 2: NT9WLH2MDK (sent immediately after the first log) |
|
|
fyi, I submitted a new debug log using the latest build 186. Note also that the issue does not occur on all devices; it occurs on a Samsung Galaxy S3/JB 4.1, but not on a Sony Experia Pro/ICS 4.03. |
|
|
Note: I believe that part of the delay is related to 0011481--the fact that playlists are getting larger and larger with each install/sync (e.g. some playlists now have 5x of each track (1 playlist has 68k tracks). So I suggest that we first fix 0011481, and then see if this issue still remains. It's possible, though, that 0011481 is directly related to the scanning process itself... Note also, another possible bug: if I exit MMA while the scan is in progress, and then (after MMA has terminated) restart MMA, then the scanning process doesn't continue. One would have expected that if Playlist scanning was incomplete, that either: a) The process would continue once MMA restarted b) The process would continue until it completed and then MMA would terminate (less preferable, as it would consume resources against the user's wishes) |
|
|
Raising priority to 'immediate' as this is slowing down sync testing. |
|
|
Build 191b (a test build) took 10 minutes to scan 1100 tracks + 6 playlists. No synch operation was done--all tracks pre-existed on the device prior to a clean install of the build. |
|
|
Rusty results: VideoSync: 17 items 11,6 item/s MediaSync: 1125 items 2,1 item/s PlaylistSync: 2160 items 22,9 item/s FolderSync: 817 items 3,8 item/s My results with Nexus7: VideoSync: 17 items 10,3 item/s MediaSync: 1074 items 2,08 item/s PlaylistSync: 2186 items 22,9 item/s FolderSync: 389 items 3,3 item/s Same behaviour for both devices now. We should focus to improve MediaSync in future. Fixed in build 201. |
|
|
Scanning progress is handled differently in latest version. |
