View Issue Details

IDProjectCategoryView StatusLast Update
0010166MMAGeneralpublic2022-03-12 01:14
Reporterrusty Assigned To 
PriorityimmediateSeveritymajorReproducibilitysometimes
Status closedResolutionfixed 
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.
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.
TagsNo tags attached.
Fixed in build201

Relationships

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

Activities

jiri

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.

peke

2012-12-08 00:11

developer   ~0033763

Last edited: 2012-12-08 00:11

Possible introduction of Regression like 0010176

rusty

2012-12-11 18:10

administrator   ~0033828

Last edited: 2012-12-11 18:11

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

jiri

2012-12-11 21:29

administrator   ~0033832

Many new fixes that could affect this in build 77.

peke

2012-12-13 00:46

developer   ~0033849

Last edited: 2012-12-13 00:47

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

jiri

2013-01-22 16:23

administrator   ~0034585

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

peke

2013-02-16 00:45

developer   ~0034973

Verified 100

peke

2013-02-28 02:16

developer   ~0035157

Last edited: 2013-02-28 02:19

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

marek

2013-04-25 11:00

developer   ~0035767

Fixed in build 125

peke

2013-04-28 20:31

developer   ~0035836

Verified 125

rusty

2013-08-22 18:36

administrator   ~0037239

Last edited: 2013-08-22 23:13

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

rusty

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.

marek

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

marek

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.

marek

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

rusty

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

rusty

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?

jiri

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

rusty

2013-08-27 15:21

administrator   ~0037300

Last edited: 2013-08-27 15:36

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.

marek

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.

martin

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.

rusty

2013-10-03 17:54

administrator   ~0037743

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

Uploaded debug: PLWOMFKO5G

rusty

2013-10-03 19:52

administrator   ~0037747

Last edited: 2013-10-03 19:53

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!

martin

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

martin

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.

rusty

2013-11-07 22:00

administrator   ~0038224

Last edited: 2013-11-07 22:25

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.

rusty

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)

rusty

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.

rusty

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)

rusty

2013-11-26 17:50

administrator   ~0038380

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

rusty

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.

martin

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.

peke

2022-03-12 01:14

developer   ~0067239

Scanning progress is handled differently in latest version.