View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013374||MediaMonkey (current)||DB/FileMonitor||public||2016-06-19 15:54||2016-06-21 21:12|
|Status||closed||Resolution||unable to reproduce|
|Target Version||4.1.13||Fixed in Version||4.1.13|
|Summary||0013374: Rescan is slow in 4.1.13|
|Description||Users are reporting that scanning is much slower with 184.108.40.2069 comparing to 220.127.116.118|
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
|Tags||No tags attached.|
|Fixed in build||1800|
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.
||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?|
Tests with empty DB, scanned 61GB of audio files from external drive:
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):
So it seems, there could be some problem when rescanning already existing files in DB, not in scanning new files.
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.
Fixed in build 18.104.22.1680 (thanks to the user's logs) - regression was introduced while adding 0012406 )