View Issue Details

IDProjectCategoryView StatusLast Update
0010166MediaMonkey for Android[All Projects] Generalpublic2013-12-13 16:08
Status resolvedResolutionfixed 
Product Version1.0.1 
Target Version1.0.4Fixed in Version1.0.1 
Summary0010166: Scans are never-ending for some devices/environments
DescriptionThere have been several reports of MMA not completing scans of device content.

Zombiefly indicated that he submitted a debug log, but I don't see it...

No fix required at this point--needs more investigation.
TagsNo tags attached.
Fixed in build201


related to 0009650 closedjiri MediaMonkey for Android Scanning never completes in some cases 
related to 0010213 closedmartin MediaMonkey for Android Crash after Update 
related to 0010552 closedLudek MediaMonkey (current) Nexus 7, JB 4.2.2, MTP sometimes freezes  
related to 0011481 closedrusty MediaMonkey for Android Some playlists get synched with multiple copies of the tracks within 
related to 0010176 closedmarek MediaMonkey for Android MMA started to Show Duplicates (Regression) 
related to 0011501 closedmartin MediaMonkey for Android Playlist creation sometimes fails during scan 
related to 0011507 closedrusty MediaMonkey for Android Scanning isn't detecting modifications to files 
related to 0012936 resolvedmartin MediaMonkey for Android MediaStore sync takes too long 



2012-12-07 18:28

administrator   ~0033736

It's probably resolved in build 73 or 74 due to a lot of fixes based on crash reports from users.


2012-12-08 00:11

developer   ~0033763

Last edited: 2012-12-08 00:11

View 2 revisions

Possible introduction of Regression like 0010176


2012-12-11 18:10

administrator   ~0033828

Last edited: 2012-12-11 18:11

View 2 revisions

User reports that this is still open at:

Note: for many users this is fixed by removing the /MediaMonkey folder


2012-12-11 21:29

administrator   ~0033832

Many new fixes that could affect this in build 77.


2012-12-13 00:46

developer   ~0033849

Last edited: 2012-12-13 00:47

View 2 revisions

Reopened due the possible relation with 0010213 as after crash scan icon never goes away


2013-01-22 16:23

administrator   ~0034585

According to recent crashlogs (or a lack of them), this is probably resolved.


2013-02-16 00:45

developer   ~0034973

Verified 100


2013-02-28 02:16

developer   ~0035157

Last edited: 2013-02-28 02:19

View 2 revisions

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


2013-04-25 11:00

developer   ~0035767

Fixed in build 125


2013-04-28 20:31

developer   ~0035836

Verified 125


2013-08-22 18:36

administrator   ~0037239

Last edited: 2013-08-22 23:13

View 3 revisions

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


2013-08-22 18:58

administrator   ~0037240

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.


2013-08-23 10:15

developer   ~0037246

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...


2013-08-23 12:43

developer   ~0037248

Folder processing for folders view can take a long time during mediastore sync too. Assigning to Martin to review whether optimization is possible there.


2013-08-24 10:29

developer   ~0037251

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...


2013-08-26 16:20

administrator   ~0037273

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).


2013-08-26 17:36

administrator   ~0037274

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?


2013-08-27 11:54

administrator   ~0037296

Assigning to Marek to review playlists scanning, as it seems to be the last part that needs to be reviewed...


2013-08-27 15:21

administrator   ~0037300

Last edited: 2013-08-27 15:36

View 2 revisions

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.


2013-09-12 15:37

developer   ~0037486

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.


2013-09-23 16:40

developer   ~0037645

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.


2013-10-03 17:54

administrator   ~0037743

Tested build 167, and scanning 0000198:0001000 files took 10 minutes.

Uploaded debug: PLWOMFKO5G


2013-10-03 19:52

administrator   ~0037747

Last edited: 2013-10-03 19:53

View 2 revisions

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!


2013-10-15 12:06

developer   ~0037904

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


2013-10-17 13:24

developer   ~0037928

It seems that the slowdown is due to the generation of album arts. I have added logs, please attach log from build 172.


2013-11-07 22:00

administrator   ~0038224

Last edited: 2013-11-07 22:25

View 2 revisions

Uploaded debug log of a scan that was going on for 32 minutes and counting:

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.


2013-11-12 18:49

administrator   ~0038269

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)


2013-11-22 04:00

administrator   ~0038350

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.


2013-11-24 02:05

administrator   ~0038366

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)


2013-11-26 17:50

administrator   ~0038380

Raising priority to 'immediate' as this is slowing down sync testing.


2013-12-06 03:41

administrator   ~0038547

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.


2013-12-13 16:08

developer   ~0038761

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.