View Issue Details

IDProjectCategoryView StatusLast Update
0013374MediaMonkey (current)DB/FileMonitorpublic2016-06-21 21:12
ReporterLudek Assigned To 
Status closedResolutionunable to reproduce 
Product Version4.1.13 
Target Version4.1.13Fixed in Version4.1.13 
Summary0013374: Rescan is slow in 4.1.13
DescriptionUsers are reporting that scanning is much slower with comparing to

Forum thread:

I seem to be able to replicate the issue, in my case (on 10000 files):
4.1.12: Search and update took 13 seconds
4.1.13: Search and update took 29 seconds
Additional InformationKAR-489-59767
TagsNo tags attached.
Fixed in build1800


related to 0013379 closedLudek Track may re-sync needlessly when build was used and track folders were re-scaned 
child of 0012406 closedLudek Auto-Sync: Artwork isn't updated for already synced files 



2016-06-19 16:18

developer   ~0044983

Last edited: 2016-06-19 16:31

View 2 revisions

In my case it was a test error, I tested 4.1.12 regular versus 4.1.13 debug.

With 4.1.12 debug it takes 59 seconds (13 seconds with regular).

I also checked all changes between 1798 and 1799 and there isn't any change that could have an impact on scanning speed so I suppose a user test error too.

Asking here:


2016-06-19 16:30

developer   ~0044984

Michal, could you please also verify/test/check to ensure that there is nothing between 1798 and 1799 that could have an impact on this?


2016-06-19 17:53

developer   ~0044985

Tests with empty DB, scanned 61GB of audio files from external drive:
1798: 7:40
1799: 7:32 (slightly faster probably because of some HDD caching)

Rescanned the same data, so no new file is added (tried twice to exclude difference in caching, gave same results):
1798: 27s
1799: 1:10

So it seems, there could be some problem when rescanning already existing files in DB, not in scanning new files.


2016-06-19 18:23

developer   ~0044986

ok, it corresponds to what user is describing here:

Asked him to attach logs to ticket KAR-489-59767 as I cannot replicate and don't see a change that could cause this.


2016-06-19 19:14

developer   ~0044987

Last edited: 2016-06-19 19:21

View 4 revisions

Fixed in build (thanks to the user's logs) - regression was introduced while adding 0012406 )


2016-06-20 13:35

developer   ~0045002

Verified 1800