Mnyb wrote:
> The logs are text files , the web UI hints at their exact location . If
> your on a recent LMS version there is even a link to download the whole
> log as a zip file .
>
> Pasted snippets does not help in all cases , so attach both logs as zip
> files .
>
> The forum allows you
sordidman wrote:
> Thank you for answering: I really appreciate it.
>
> Yeah,- I am sorry that i am at work and cannot cut and paste my scanner
> logs: but I am getting an "error, cannot read file, only read 1 byte of
> 10"
>
> I have a 24,000 or so item DB, and the scan stops after about 2
kidstypike wrote:
> "Trying to commit transactions before..." is a red herring, this is
> quite normal.
>
> What is your problem? Is the scan not completing?
Thank you for answering: I really appreciate it.
Yeah,- I am sorry that i am at work and cannot cut and paste my scanner
logs: but I am
sordidman wrote:
> Hi,
>
> Thank anyone in advance for any help. I am getting this same error. I am
> running Thursday night or Friday night's build 1/27 of 7.9x. I have a
> new iMAC that I transferred the LMS server software to. I believe that
> I'm running OSx Sierra. I went into the
mr-b wrote:
> Hi
>
> I updated to LMS7.9 recently and checked the scanner log to see the
> improved scanning times, but discovered that my scan was still taking
> quite a while to complete. It is scheduled to clear and rescan at 7:00
> AM using the Rescan Music Library plugin.
> In scanner.log
Aha - I had assumed that "(scan) - All Scan Logging" covered all the
scan options, but I needed to change the other scan options too.
Artwork.db is down from 1GB to 93MB(!) and cache.db from 10MB to 1MB.
Timing is much better now with the db wiping taking around 4m 40s and
Total Time: 01:39:50.
Unfortunately some of the debug logging seems to have gone so I can't
tell where the delay is e.g.
...
I've set these to debug - which other ones need changing?
database.sql
plugin.songscanner
You don't need this one
scan
Set all scan.* flags
--
Michael
Yes that is much better.
I've set "(scan) - All Scan Logging" to debug already.
I'm missing the previous lines like
main::main (250) Cache init...
Slim::Utils::Strings::loadStrings (126) Retrieving string data from
string cache: C:\ProgramData\Squeezebox\Cache\strings.8664.bin
But wiping the dbs is only 6mins for you now. Set all the entries that
start with scan to debug.
reinholdk's Profile: http://forums.slimdevices.com/member.php?userid=36070
View this thread:
OK I deleted the artwork and cache db files (I didn't before as I hadn't
been asked directly and didn't want to erase potential diagnostic data)
but today's scan time went up to nearly 5 hours! :-(
Unfortunately some of the debug logging seems to have gone so I can't
tell where the delay is e.g.
mherger wrote:
>
> But is the cleanup/wipe DB stage any faster now, with the smaller file?
>
Definitely. Wiping the smaller artwork db is instant (<1sec).
>
> I'd still go with the max parameter. With 20k tracks it won't use
> gigabytes of memory. I'm even using it on my poor little
I uploaded two artwork dbs. Both have a similar record count (~9k), but
the first (744MB) was after a full scan without deleting the
cache+artwork dbs before, the second (29MB) after a full scan with
deleting the dbs before.
BTW: your files as well as mr-b's confirmed what I was expecting. In
I uploaded two artwork dbs. Both have a similar record count (~9k), but
the first (744MB) was after a full scan without deleting the
cache+artwork dbs before, the second (29MB) after a full scan with
deleting the dbs before.
But is the cleanup/wipe DB stage any faster now, with the smaller
I uploaded two artwork dbs. Both have a similar record count (~9k), but
the first (744MB) was after a full scan without deleting the
cache+artwork dbs before, the second (29MB) after a full scan with
deleting the dbs before.
I had the db memory set to high previously, since the recommendation
But the 9min delay after "Scanner done init..." is still there. Wiping
the db?
Shut down LMS.
Delete cache.db and artwork.db
restart LMS
I already had mentioned that you should do this because a change I did
about two years ago requires the files to be re-built from scratch. Your
file did
mr-b wrote:
> But the 9min delay after "Scanner done init..." is still there. Wiping
> the db?
Yes. And included in this are 6:30mins for wiping your artwork db.
I'll upload my db later also.
reinholdk's Profile:
The scan time seems to have dropped by 40 mins after disabling the
itunes and MusicMagic plugins. Not sure why that is.
But the 9min delay after "Scanner done init..." is still there. Wiping
the db?
The artwork pre-cache is set to pre-cache album artwork (don't recall
ever changing it).
Will send
Oh, one more thing: could you guys please drop me a copy of your artwork.db?
https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a
Thanks!
--
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
[17-01-26 07:01:05.4452] Slim::Utils::PluginManager::load (241) Loading
plugin: MusicMagic
Are you using MusicIP? If not: disable this plugin
[17-01-26 07:01:05.6757] Slim::Utils::PluginManager::load (241) Loading
plugin: iTunes
Are you using iTunes integration? If not: disable this
Latest scan log - with a 9m delay after Scanner done init...
Code:
[17-01-26 07:00:58.9831] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1484464959, Sun Jan 15 07:29:05 CUT 2017) perl 5.014001
[17-01-26 07:00:58.9839] main::initializeFrameworks
it's clear that the delay is caused here
Code:
sub wipeAllData {
...
Slim::Utils::ArtworkCache->new()->wipe();
Yep, that's it. And it actually makes sense: this call would delete all
rows from the database. And as there are about four entries or more
I guess from this part of the scanner.log
Code:
[17-01-26 20:25:14.7036] Slim::Schema::wipeDB (388) End schema_clear
[17-01-26 20:27:24.4625] Slim::Schema::wipeAllData (2135) Wiped the database.
it's clear that the delay is caused here
Code:
Did another clear with database.sql set to debug. This time there
was a delay of 2:10 minutes. Library.db was 44 MB and artwork.db was 744
MB.
The scanner.log:
Code:
[17-01-26 20:25:11.1634] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1483603909,
We're slowly drilling down that rabbit hole... add database.sql to the
debug statements and you should see what is going on during that pause,
too (plus a lot of additional debug output during the scan - make sure
you turn off all those debug statements again)
--
Michael
Could this come from the artwork db? It's probably no yet big enough on
the second try?
reinholdk's Profile: http://forums.slimdevices.com/member.php?userid=36070
View this thread:
If the delay would come from wiping the db, why could it be so
significantly different between two consecutive scans?
At least in my tries the second shows no delay. Maybe the OP could
verify?
reinholdk's Profile:
mherger wrote:
> That's a bit surprising. Looking at the code I thought the delay was
> coming from deleting the db table contents. But that would have come
> with some IO.
There was some, but very very few compared to the peak shown in the
graph at the end of this phase.
Here's this morning's scan - similar time, no settings changed. But this
time I wonder why there is a 9 minute delay after Scanner done Init?
As I mentioned in my previous response, the scanner would wipe all data
from the tables. I wouldn't be surprised if that took some time with
100k
I watched a performance graph of the scanner and there was no CPU, few
IO and a bit of memory allocation activity in this 'delay' phase.
That's a bit surprising. Looking at the code I thought the delay was
coming from deleting the db table contents. But that would have come
with some IO.
--
Forgot to give the info about the importers in use:
Code:
[17-01-25 22:27:46.5192] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1483603909, Thu Jan 5 08:19:47 CUT 2017) perl 5.014001
[17-01-25 22:27:46.5209] Slim::Utils::Prefs::init (279) Error:
This time I see a 'delay' of 1:26 min for a clear
Code:
[17-01-25 21:19:38.2853] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1483603909, Thu Jan 5 08:19:47 CUT 2017) perl 5.014001
[17-01-25 21:19:38.2869] Slim::Utils::Prefs::init (279) Error:
mherger wrote:
>
> What library size?
>
> No, the removing stage would be reported in the standard output. But you
>
> could answer the questions I asked the OP, maybe it'll ring a bell.
>
My library size is 20k tracks. I'll check and report back.
Here's this morning's scan - similar time, no settings changed. But this
time I wonder why there is a 9 minute delay after Scanner done Init?
Not quite sure what you mean by importers. I have mostly the default
plug-ins plus Cast Bridge.
Changed server.plugins to debug logging for next time.
Code:
[17-01-24 16:50:21.7563] Slim::Schema::forceCommit (2149) Warning: Trying to
commit transactions before DB is initialized!
[17-01-24 16:50:23.5680] Slim::Utils::Strings::loadStrings (126) Retrieving
string data from string cache:
mherger wrote:
>
>
> Are you sure you made the log settings stick? Could you please add debug
>
> logging for 'server', too?
>
> What importer plugins are you using (iTunes, some of Erland's, etc.)?
> Please next
> time provide a full scanner.log file.
>
> --
>
> Michael
Ok the log
I'm also seeing this kind of big 'delay' at the beginning of a clear and
rescan often (Windows).
What library size?
Guess it's the phase where the old records are removed from the db. It's
much faster when I stop LMS, delete the cache and restart.
No, the removing stage would be reported in
I'm also seeing this kind of big 'delay' at the beginning of a clear and
rescan often (Windows).
Guess it's the phase where the old records are removed from the db. It's
much faster when I stop LMS, delete the cache and restart.
Well it was just half an hour delay this time.
See, it's much faster now :-).
[17-01-23 20:13:53.9013] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1484464959, Sun Jan 15 07:29:05 CUT 2017) perl
5.014001
[17-01-23 20:13:54.6147] Slim::Schema::forceCommit (2149) Warning:
Well it was just half an hour delay this time.
[17-01-23 20:13:53.9013] main::main (205) Starting Logitech Media Server
scanner (v7.9.0, 1484464959, Sun Jan 15 07:29:05 CUT 2017) perl
5.014001
[17-01-23 20:13:54.6147] Slim::Schema::forceCommit (2149) Warning:
Trying to commit transactions before
Ok I changed (scan) - All Scan Logging to debug (and anything else with
scan in it) and set max db memory.
The scanner log looks the same though i.e. it seems not to have started
actual scanning yet after scan initiation:
[17-01-23 20:13:53.9013] main::main (205) Starting Logitech Media Server
I updated to LMS7.9 recently and checked the scanner log to see the
improved scanning times, but discovered that my scan was still taking
quite a while to complete. It is scheduled to clear and rescan at 7:00
AM using the Rescan Music Library plugin.
You're on Windows? Make sure you set the
That is odd, I have the same entry in my scanner log as you have, but
there no such delay.
I see you have approx 100k files. I have over 150K files so the number
of files shouldn't matter.
Do you have some more info about your setup?
What machine are you running LMS on?
Is your Music DB located
Hi
I updated to LMS7.9 recently and checked the scanner log to see the
improved scanning times, but discovered that my scan was still taking
quite a while to complete. It is scheduled to clear and rescan at 7:00
AM using the Rescan Music Library plugin.
In scanner.log I see the above error and
43 matches
Mail list logo
