We couldnt make out the reason for my buddys long scan times, maybe a
hardware fault after all. He decided we postpone further diagnostics
until well both switch to Linux Mint 20, hopefully July or so.
@BJW: Thanks for the kind words! Long time ago
:-)
Moonbase: 'The Problem Solver'
Good to see Moonbase again, I love ur ver of vbrfix.
Anyway, here is something that seems like it's still needed:
https://forums.slimdevices.com/showthread.php?49429-feature-request-file-vs-track-calculator
using: win7 64 + lms 7.9 & duet & ipads w/the logitech app, and ipeng
on an ipod
Will ask him when he’s back from his current business trip. Anything
special to be looked for, or any debug settings to be made?
The scan times from Settings/Information would already be a good start.
--
Michael
___
discuss mailing list
Will ask him when hes back from his current business trip. Anything
special to be looked for, or any debug settings to be made?
Moonbase: 'The Problem Solver' (http://www.kaufen-ist-toll.de/moonbase)
Moonbase's Profile:
regularly takes much more than *20 hours* for the same.
20 hours is too much. Check the scanner.log file and the server's status
page. Where is it spending all this time?
--
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
Dont want to hijack the thread but a close friend and I observe a
similar difference: On the same ~150k tracks library (mixed FLAC/MP3), I
usually get between *815 minutes* for an update scan, while his machine
regularly takes much more than *20 hours* for the same.
We both use the same LMS
pinkdot wrote:
> Difference in scanned files could be a permission issue on the server.
> So, check the top folder's permission and apply these setting to all
> underlying folders. This can easily be done in Files.
>
Very interesting tip this, didn't try it until now, I assumed everything
was
Roland0 wrote:
> It should be a A1 certified card (not A2, as they are not well supported
> on Linux, and are actually slower in practice)
>
>
> You should use something that can monitor and log the whole scan
> process, as the workload varies depending on the scan phase (see below)
>
>
>
"Maximum" means that LMS' database cache is set to grow to a maximum of
500MB.
No, it's basically unlimited.
--
Michael
___
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/discuss
echable wrote:
Thanks for the tip on the update - how can I be automatically notified
about these updates?
Why isn't there a normal Synology package repository/ advice about the
update showing up in package centre like with other packages!
Synology doesn't allow me to push LmsUpdate to the
>
> Sandisk high-speed SD card on the XU4, those SD-card classifications are
> so all over the place now that I can't remember but I think it is the
> fastest category SD Card available.
>
It should be a A1 certified card (not A2, as they are not well supported
on Linux, and are actually
Tried looking for scanner logs: Settings - Information - The two log
files at the bottom. The NAS one was empty, because of the update I did
earlier today I suppose, the XU4 one has identical info in both files
and none of it to do with library scanning:
[19-11-16 15:35:24.1341]
echable wrote:
> Thanks for the tip on the update - how can I be automatically notified
> about these updates?
Why isn't there a normal Synology package repository/ advice about the
update showing up in package centre like with other packages!
Synology doesn't allow me to push LmsUpdate to
echable wrote:
> Hmmm, did manual install of the package, downloaded from your mirror for
> my ds415play, stopped and started package, LMS information still showing
> same version, 7.9.2 - 0028.1572699180 @ Sat Nov 2 14:19:59 CET 2019
Previous version was 0027.
-DS718+, RPI 2 ('myMPD'
Hmmm, did manual install of the package, downloaded from your mirror for
my ds415play, stopped and started package, LMS information still showing
same version, 7.9.2 - 0028.1572699180 @ Sat Nov 2 14:19:59 CET 2019
Thanks for the tip on the update - how can I be automatically notified
about these updates? Why isn't there a normal Synology package
repository/ advice about the update showing up in package centre like
with other packages!
Otherwise, thanks again for the package, great work!
echable wrote:
>
>
> Also, someone please friggin' explain the difference in number of files
> found between two LMS servers scanning the exact directories when NO
> changes have been (by me, maybe by LMS itself) made in between the two
> scans :)
>
> (BTW sorry if I'm messing up with the
I should add: both the XU4 and the NAS had just been factory reset and
had nothing but LMS installed on them.
echable's Profile: http://forums.slimdevices.com/member.php?userid=69542
View this thread:
mherger wrote:
> > RAM almost certainly won't be the root cause, LMS doesn't use that
> much
> > (~500MB for LMS should be ample. To make sure, check
> > settings>performance if you even have enabled high memory settings,
> and
> > check actual usage with e.g htop), and for a scan, memory-based
Roland0 wrote:
> RAM almost certainly won't be the root cause, LMS doesn't use that much
> (~500MB for LMS should be ample. To make sure, check
> settings>performance if you even have enabled high memory settings, and
> check actual usage with e.g htop), and for a scan, memory-based caching
>
d6jg wrote:
> Apologies. Where did I get the idea of a Pi from? No idea.
> Ignore meDiet Pi was mentioned, maybe that was it.[emoji3]
Sent from my SM-G900F using Tapatalk
slartibartfast's Profile:
slartibartfast wrote:
> He isn't using a Pi and the slow server is installed on the NAS.
>
> Sent from my SM-G900F using Tapatalk
Apologies. Where did I get the idea of a Pi from? No idea.
Ignore me
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo TS606 ->
d6jg wrote:
> As the library is on the NAS the bottleneck is probably the network
> interface on the Pi
>
> Up until Pi4 the NIC was 100mb and shares the same bus as the USB ports.
> It was the Pi's weakest point.He isn't using a Pi and the slow server is
> installed on the NAS.
Sent from my
As the library is on the NAS the bottleneck is probably the network
interface on the Pi
Up until Pi4 the NIC was 100mb and shares the same bus as the USB ports.
It was the Pi's weakest point.
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo TS606 -> Celestion
RAM almost certainly won't be the root cause, LMS doesn't use that much
(~500MB for LMS should be ample. To make sure, check
settings>performance if you even have enabled high memory settings, and
check actual usage with e.g htop), and for a scan, memory-based caching
is basically irrelevant
echable wrote:
>
> Since the disk read speed logically can't be the bottleneck, it must be
> the 1gb RAM on the NAS vs. the 2gb RAM on the xu4 that makes the
> difference ? Or the LMS build ?
RAM almost certainly won't be the root cause, LMS doesn't use that much
(~500MB for LMS should be
echable wrote:
> Hey, GREAT tip about the 7.9.2 build! Thank you very much! I ended up
> installing the one from the SynoCommunity repo and am now reinstalling
> from scratch the pinkdot build.
In the end, full library scan on XU4 took 06:38:30, on the DS415PLAY it
took 19:11:59.
And library
mherger wrote:
> > One setting up on a Synology DS415PLAY (Intel Atom Dual Core 1.6GHz,
> > DDR3 1GB RAM, WD 4*6TB disks, Logitech Media Server Version: 7.7.6),
> in
> > about 12 hours it has scanned only about 6000 songs. This should be
>
> That certainly sounds wrong. Shouldn't take more
One setting up on a Synology DS415PLAY (Intel Atom Dual Core 1.6GHz,
DDR3 1GB RAM, WD 4*6TB disks, Logitech Media Server Version: 7.7.6), in
about 12 hours it has scanned only about 6000 songs. This should be
That certainly sounds wrong. Shouldn't take more than a few minutes.
Please check
29 matches
Mail list logo
