View Issue Details

IDProjectCategoryView StatusLast Update
0013374MMW v4DB/FileMonitorpublic2016-06-21 21:12
ReporterLudek Assigned To 
PriorityimmediateSeveritymajorReproducibilityalways
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 4.1.13.1799 comparing to 4.1.12.1798

Forum thread:
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=85117&sid=35e760a342f09b8cfc3722564ce0440d&p=424569

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
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=85117&sid=35e760a342f09b8cfc3722564ce0440d&p=424569
TagsNo tags attached.
Fixed in build1800

Relationships

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

Activities

Ludek

2016-06-19 16:18

developer   ~0044983

Last edited: 2016-06-19 16:31

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:
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=85117&sid=35e760a342f09b8cfc3722564ce0440d&p=424569#p424713

Ludek

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?

michal

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.

Ludek

2016-06-19 18:23

developer   ~0044986

ok, it corresponds to what user is describing here:
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=85117&p=424717#p424714

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

Ludek

2016-06-19 19:14

developer   ~0044987

Last edited: 2016-06-19 19:21

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

peke

2016-06-20 13:35

developer   ~0045002

Verified 1800