>Are you seeing this every time you run a new & changed scan, even if
>there are no changes?
Just tried again, and it seems to be back to normal speed.
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
I'm not seeing any unusual slowness. I just ran a new & changed scan in
7.5 trunk, r30453 (MySQL). It took the normal amount of time, 05:32 for
my FLAC library of 27,044 tracks.
--
JJZolx
Jim
JJZolx's Profile: http://fo
Just installed todays build 7.5e 30441 and it appeared to do a full
rescan.
Using SQLite and the time was about normal for a 7.5e rescan.
--
slate
Main: Duet -> Beresford Caiman -> Carver A-500x -> B&W 704
Office: Duet -> Technics SU-V50 -> Stax SR84 Pro
Server: Zotac IONITX-A, 4 GB, 1 TB WD E
Philip Meyer;529457 Wrote:
> >whoah - I'm getting this now.. (7.5e 30424)
> >
> Note that I'm seeing this in 7.5/trunk with MySQL. I haven't tried my
> 7.5 embedded installation yet.
Are you seeing this every time you run a new & changed scan, even if
there are no changes?
--
JJZolx
Jim
>whoah - I'm getting this now.. (7.5e 30424)
>
Note that I'm seeing this in 7.5/trunk with MySQL. I haven't tried my 7.5
embedded installation yet.
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
Phil Leigh;529381 Wrote:
> whoah - I'm getting this now.. (7.5e 30424)
>
> [10-03-31 15:30:43.3633] Slim::Control::Request::execute (1935) Error:
> While trying to run function coderef
> [Slim::Utils::SQLiteHelper::_notifyFromScanner]: [Unable to
> replace_with: x:\Cache\squeezebox-scanner.db do
whoah - I'm getting this now.. (7.5e 30424)
[10-03-31 15:30:43.3633] Slim::Control::Request::execute (1935) Error:
While trying to run function coderef
[Slim::Utils::SQLiteHelper::_notifyFromScanner]: [Unable to
replace_with: x:\Cache\squeezebox-scanner.db does not exist at
/Slim/Utils/SQLiteHelp
I didn't see anything relevant in the checkin comments - maybe a change
was done further in the past; I haven't scanned for a while.
--
Philip Meyer
Philip Meyer's Profile: http://forums.slimdevices.com/member.php?userid=9
Looks like Andy may have changed something that required a major rescan
(artwork maybe?)
A second rescan was back to its normal speedy self...
--
Phil Leigh
You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (L
also on my system (w7 ultimate32).
terribly slow...
Christian
--
Schindler
Schindler's Profile: http://forums.slimdevices.com/member.php?userid=8461
View this thread: http://forums.slimdevices.com/showthread.php?t=76668
Me too - it looks like a new/changed scan is detecting my entire library
as "changed"...
--
Phil Leigh
You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Aud
My scanning is horrendously slow too...
I'm on 7.5 Embedded r30424
--
cbemoore
cbemoore's Profile: http://forums.slimdevices.com/member.php?userid=163
View this thread: http://forums.slimdevices.com/showthread.php?t=76668
7.5/trunk SVN 30441.
A rescan for new/changed files usually takes ~ 5 - 8 mins for my server. This
evening, it took significantly longer - 57 mins, 52 mins of which were for the
directory scan.
Any reason why directory scan should be slower all of a sudden?
Phil
__
I'm having similar trouble but in version: 7.3.3 - 27044
In addition, I'm finding that the rescan for "Look for new and changed
music" does not fully complete.
It generally makes it through the directory scan and usually gets stuck
on the Merge Various Artists scan. It's clear from the row of l
frank1969;447127 Wrote:
>
> An old id 3 tag stays in Your database "foever" or at least till the
> next complete re-scan which takes 4 or 5 times the time of an update
> scan
>
> Example:
> I had a song in my database with artist tag "Robbie Williams + Kylie
> Minogue". Now I change this to "Ro
Well, sry to contradict You but I still think the scanner needs urgent
improvement concering changing and removing tag-data.
An old id 3 tag stays in Your database "foever" or at least till the
next complete re-scan which takes 4 or 5 times the time of an update
scan
Example:
I had a song in my
>I think scanning is definitely a bit faster than in 7.3.x, just maybe
>not dramatically faster.
I think the first phase of the scanning is slower.
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
andyg;446503 Wrote:
> Logging won't slow it down. I haven't profiled scanning under MySQL
> yet, maybe there are some easy improvements, but at this point as long
> as it's not slower or broken that's good enough for 7.4.
I think scanning is definitely a bit faster than in 7.3.x, just maybe
not
Logging won't slow it down. I haven't profiled scanning under MySQL
yet, maybe there are some easy improvements, but at this point as long
as it's not slower or broken that's good enough for 7.4.
--
andyg
andyg's Profile:
Philip Meyer;446431 Wrote:
> This appears to be taking longer in 7.4/trunk since noweb-sqlite changes
> have been merged in.
>
> It appears to be scanning every file, rather than only files that have
> newer timestamps (the scanner log is reporting that it is scanning every
> file).
Scanning is
This appears to be taking longer in 7.4/trunk since noweb-sqlite changes have
been merged in.
It appears to be scanning every file, rather than only files that have newer
timestamps (the scanner log is reporting that it is scanning every file).
Phil
_
21 matches
Mail list logo
