erland;563513 Wrote:
> If you look in the log for rows which message part starts with "Scanning
> track: ", you can look at the timestamps to see how long it takes to
> scan a single track. Based on this you can calculate the total scanning
> time by multiplying it with the total number of tracks.
>
> I'm not sure if the log contained all entries between two "Scanning
> track: " rows but if it did it means that a single track takes about
> 2/100 of a second, which means that it should be able to scan about 50
> tracks per second if my math is correct. With the 115024 tracks which
> your database seems to contain this should result in a scanning time
> around 40 minutes plus a few minutes for the refresh and delete
> operations in the beginning.
>
> So based on this it sounds like it should have been finished a long
> time ago.
>
> Try searching in the log for "Performing rescan" or "Performing module
> rescan", maybe there is some cycle so it continues to run the scanning
> multiple times ?
>
> Custom Tag scanning module reads all tracks and print their values when
> debug logging is enabled, it will only store the tags which you have
> configured it to store.
As of yesterday there were only two instances of "Performing rescan" or
"Performing module rescan":
Code:
--------------------
[10-07-21 09:22:35.5261] Plugins::CustomScan::Scanner::fullRescan (695)
Performing rescan
[Snip]
[10-07-21 09:33:22.6524] Plugins::CustomScan::Scanner::moduleRescan (741)
Performing module rescan
--------------------
The log including those values is attached. I also attach a file with
everything logged with debug level logging switched on. It seems that
both CustomTag and RatingTag is actually running although the web UI
reports that only CustomTag is running. As I said I tried your method
for having a simultaneous scan first but as the web UI did not indicate
that anything was running I clicked manual scan for only CustomTag.
erland;563513 Wrote:
> I suspect this might cause part of the differences, the optimized my.tt
> usually gives big improvements in larger libraries on computers with
> lot of memory. As an example, it might mean that the scanning itself is
> pretty fast but there is some of the SQL statements executed in the
> beginning or end that takes a lot of time without the optimized my.tt
> file.
>
> Possibly the tag mapping logic might also cause some performance
> problems but I suspect it doesn't as it's only perl code and no extra
> data access.
I will stop SBS now and replace my.tt and try again. I must also
restore my TrackStat data and suspect that it also will take a long
time although I have manually corrected the paths.
Thank you for your assistance!
+-------------------------------------------------------------------+
|Filename: Debuglevel.log.txt.zip |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=10330|
+-------------------------------------------------------------------+
--
vagskal
2 x SB3 (wired), Receiver (wireless), Boom (wireless), Controller, iPeng
on iPod Touch, muso on remote computer running Win 7 | 7.5.2 on Win XP
------------------------------------------------------------------------
vagskal's Profile: http://forums.slimdevices.com/member.php?userid=20778
View this thread: http://forums.slimdevices.com/showthread.php?t=49483
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
