mherger wrote:
> >> Running this kind of stuff in a loop would likely only hit SQLite's
> >> buffer - which is not representative either.
> >>
> > Not sure about that. If I were to speculate: SQLite doesn't seem to
> do
> > any real query caching, and the buffer seems very limited, leading to
Respect what you are doing , perl seems to vary between 5.8 to 5.24 in
the user base .
5.26 ;-)
Ill test when its aviable no need to rush i have modest collection of
50k tracks and a reasonably fast machine anyway.
It should be available now. Please keep a copy of the old package: I
don't
mherger wrote:
> > Dang so Linux mint 18 has such old Perl version :)
>
> Guess why I have 5.10 binaries? Because my system is still CentOS 6
> based. That's an old Perl :-).
>
> --
>
> Michael
Respect what you are doing , perl seems to vary between 5.8 to 5.24 in
the user base .
Ill test
Dang so Linux mint 18 has such old Perl version :)
Guess why I have 5.10 binaries? Because my system is still CentOS 6
based. That's an old Perl :-).
--
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
mherger wrote:
> > I did not get the latest version for some reason using the amd64
> deb...
> >
> > Perl Version: 5.22.1 - x86_64-linux-gnu-thread-multi
>
> The reason is explained in the announcement :-). I'll add that to the
> todo list.
> --
>
> Michael
Dang so Linux mint 18 has such
Running this kind of stuff in a loop would likely only hit SQLite's
buffer - which is not representative either.
Not sure about that. If I were to speculate: SQLite doesn't seem to do
any real query caching, and the buffer seems very limited, leading to a
weird spiking performance profile:
I did not get the latest version for some reason using the amd64 deb...
Perl Version: 5.22.1 - x86_64-linux-gnu-thread-multi
The reason is explained in the announcement :-). I'll add that to the
todo list.
--
Michael
___
discuss mailing list
I did not get the latest version for some reason using the amd64 deb...
Logitech Media Server Version: 7.9.2 - 1536946607 @ Fri Sep 14 20:16:26
CEST 2018
Hostname: SqueezeVM
Server IP Address: 192.168.1.82
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture:
Tbh given how many apps go for the complexity of full blown
mysql/postgres when they are only storing a few configuration items I'm
amazed lms works so well with sqlite underneath.
-Transcoded from Matt's brain by Tapatalk-
--
Hardware: 3x Touch, 1x Radio, 2x Receivers, 1 HP Microserver NAS
mherger wrote:
> Running this kind of stuff in a loop would likely only hit SQLite's
> buffer - which is not representative either.
>
Not sure about that. If I were to speculate: SQLite doesn't seem to do
any real query caching, and the buffer seems very limited, leading to a
weird spiking
FWIW: I just pushed support for DBD::SQLite 1.58 on select platforms to
7.9. See https://forums.slimdevices.com/showthread.php?109460 for details.
--
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
I've just updated my LMS to use the latest DBD::sqlite (1.58) and could
run some benchmarks, then downgrade to 1.34 and re-run them.
The question is how to benchmark (re-scanning the library is simple, but
not really representative of normal use) - how did you measure the 20%
performance gain?
mherger wrote:
> > I've been running LMS with 'updated modules / libraries '
> >
> (http://forums.slimdevices.com/showthread.php?107040-Howto-update-perl-modules-bundled-with-LMS)
> > (DBD::SQLite 1.54 (sqlite 3.13.0)) since 03/2017 on a RPi3 without
> any
> > issues.
>
> Great! Any
DJanGo wrote:
> Hi Michael,
To answer my own "question" - maybe...
eg running a clean scan from scratch -> no library.db (with the std.
"old" Sqlite Version) on 7.92 (latest) needs 38min.
running a clean scan over the gui on the same hardware/software needs 22
mins.
The is some very little
mherger wrote:
> That's an odd one. In my previous tests this was constant. Every test I
> did was a massive slow down in FTS. But I always did delete the
> library.db to start from scratch for every test. Now I repeated the test
>
> for the same collection, without deleting that file, and
I've been running LMS with 'updated modules / libraries '
(http://forums.slimdevices.com/showthread.php?107040-Howto-update-perl-modules-bundled-with-LMS)
(DBD::SQLite 1.54 (sqlite 3.13.0)) since 03/2017 on a RPi3 without any
issues.
Great! Any improvements you've experienced?
I can confirm
mherger wrote:
>
> Running from the source would allow you to replace DBD::SQLite (inside
> the CPAN folder). Please share your experience. I'm still considering
> updating... Just have to figure out what was causing the slow-down in
> the fulltext indexing.
>
I've been running LMS with
If you want to run LMS from the source, grab a copy from
https://github.com/Logitech/slimserver. Then run "perl slimserver.pl".
Running from the source would allow you to replace DBD::SQLite (inside
the CPAN folder). Please share your experience. I'm still considering
updating... Just have to
mherger wrote:
>
> You're running LMS from a different computer than where the files are
> saved? This kind of I/O might be the bottleneck during the scan. But I
> could imagine that when TrackStat is doing its job, it's LMS server side
>
> only, no access to the files. I might be wrong.
My library is 30k tracks (on a NAS) and the bottleneck is I/O for sure,
the SATA died and wiped out the disks, so I rebuilt it with Win7 booting
from a USB drive.
You're running LMS from a different computer than where the files are
saved? This kind of I/O might be the bottleneck during the
mherger wrote:
> > Thanks for the research. Long story, short.. my interest is due to a
> > low powered wintel system grinding to a stop when doing a full rescan
> > due to Trackstat. So I was looking at the db and noticed the old
> > version and hence the interest. Is there anyway of
> >
Thanks for the research. Long story, short.. my interest is due to a
low powered wintel system grinding to a stop when doing a full rescan
due to Trackstat. So I was looking at the db and noticed the old
version and hence the interest. Is there anyway of
decompressing/patching a wintel system
Thanks for the research. Long story, short.. my interest is due to a
low powered wintel system grinding to a stop when doing a full rescan
due to Trackstat. So I was looking at the db and noticed the old
version and hence the interest. Is there anyway of
decompressing/patching a wintel system
Ok, I thought I'd give it the quickest try I could, running a test on my
dev machine (2017 MBP, SSD, 16GB RAM). Here are the results:
DBD::SQLite 1.58 (sqlite 3.22.0)
Discovering files/directories:
/Users/mh/Documents/SqueezeZeugs/flac10 (107993 of 107993)
Complete 00:00:19
Scanning
Is there any reason why LMS is using such an old SQLite version, 3.7.7.1
which dates back to 2011.
There are many potential reasons. Call it laziness, or "never touch a
running system", or lack of priorities, premature optimization, lack of
time...
Updating the library for all platforms is
Hi
Is there any reason why LMS is using such an old SQLite version, 3.7.7.1
which dates back to 2011.
Looking through the SQLite release log there seem to be pretty
impressive performance gains made over the years so just wondering why
this hasn't been rolled into LMS. (DBD-SQLite-1.58
26 matches
Mail list logo
