drmatt wrote:
> What surprises me is just that one plugin is able to lock the whole
> server. I didn't expect that to be the case, I thought LMS ran
> multi-threaded and individual plugins wouldn't be able to be so evil.
>
Unfortunately its single threaded so its very easy for a plugin to
drmatt wrote:
> Well I can tell you it's not doing system calls while it's hung, it's
> purely spinning in user code:
>
>
> # strace -fp 24410
> strace: Process 24410 attached
>
> [..tens of seconds elapse..]
>
> ^Cstrace: Process 24410 detached
If its related to the TrackStat plugin it
Well I can tell you it's not doing system calls while it's hung, it's
purely spinning in user code:
# strace -fp 24410
strace: Process 24410 attached
[..tens of seconds elapse..]
^Cstrace: Process 24410 detached
--
Hardware: 3x Touch, 1x Radio, 2x Receivers, 1 HP Microserver NAS with
CypherMK wrote:
> I think this may have solved the freezing issue. Will test further. I
> did enable "rescan refresh" and disabled "enable musicbrainz tags".
What surprises me is just that one plugin is able to lock the whole
server. I didn't expect that to be the case, I thought LMS ran
erland wrote:
>
> Disabling only the Enable musicbrainz tags option can also help in
> some setups since the musicbrainz handling part in the refresh operation
> might be the cause to the problem. You should be able to see in the
> server.log which part of the refresh operation that takes
CypherMK wrote:
> So as long as I don't move stuff around, it's ok?
I think so but its about 10 years since I wrote this code so I might
have forgotten about some situation.
CypherMK wrote:
> Is there a way to make this scan to be triggered by CLI or maybe a http
> request? So I can run
erland wrote:
> There are two options in TrackStat for its refresh operation, one for
> refresh at startup and one for refresh after rescan, if you disable both
> in TrackStat settings page you should not have the problem that LMS
> hangs. The side effect of disabling them is that you will loose
GoodVibrations wrote:
> OK workaround.
> But I guess you'll have an unresponsive system as soon as you scan for a
> new album.
>
There are two options in TrackStat for its refresh operation, one for
refresh at startup and one for refresh after rescan, if you disable both
in TrackStat settings
I will add a new album later to see if it hangs. Last scan was normal.
But I I had no albums added.
CypherMK's Profile: http://forums.slimdevices.com/member.php?userid=62798
View this thread:
CypherMK wrote:
> I have set to scan for new music at 4 in the morning every day. So I
> don't know if the system hangs at night.Check the scanner log.
Sent from my Pixel 3a using Tapatalk
slartibartfast's Profile:
GoodVibrations wrote:
> OK workaround.
> But I guess you'll have an unresponsive system as soon as you scan for a
> new album.
>
> I don't think a solution is on the horizon.
> Just a few weeks ago, Erland offered to let another take over the
> maintenance of his plugins. So he clearly has no
OK workaround.
But I guess you'll have an unresponsive system as soon as you scan for a
new album.
I don't think a solution is on the horizon.
Just a few weeks ago, Erland offered to let another take over the
maintenance of his plugins. So he clearly has no time himself. Don't
know if he even
CypherMK wrote:
> Also have the same issue:
> https://forums.slimdevices.com/showthread.php?112837-Trackstat-causing-100-cpu-usage-on-Raspberry-PI-4=986328#post986328
>
> So there is no real solution to this?
I have a workaround for my problem. I went to trackstat settings and
changed this
Also have the same issue:
https://forums.slimdevices.com/showthread.php?112837-Trackstat-causing-100-cpu-usage-on-Raspberry-PI-4=986328#post986328
So there is no real solution to this?
CypherMK's Profile:
Same TrackStat problems here, using LMS 8.0.
Best regards,
Dennis.
::Please vote:::
'::bug 1330:: New music should work on creation date'
(http://bugs.slimdevices.com/show_bug.cgi?id=1330)
'::bug 17963:: New and changed doesn't handle changed files '
mrw wrote:
> No harm in asking on that thread. You never know, he may have found a
> solution later.
> I sympathize. Time spent with no good result. I guess breakage/loss of
> third party plugins is always going to be a risk.
>
I just asked on the other thread. :-)
I know Erlands plugins are
GoodVibrations wrote:
> I can't find any solution mentioned anywhere by the original poster,
> drmatt.
No harm in asking on that thread. You never know, he may have found a
solution later.
GoodVibrations wrote:
>
> This whole mess has been a disheartening experience.
>
I sympathize. Time
GoodVibrations wrote:
> Just discovered this setting:
>
> 30722
>
> This was set to High, and I changed it to Max.
>
> I then rebooted.
> Now it "only" takes 2h18m for the system to become responsive
>
> I'm guessing that it's Trackstat that has become a problem.
> I will now clear the
mrw wrote:
> Someone else reported problems with Trackstat after upgrading to 7.9.2.
> Perhaps they have solved it.
>
> -Perl 5.28, general dpkg update woes, and a new problem with
> Trackstat?-
>
GoodVibrations wrote:
>
>
> Trackstat starts refreshing and now the system hangs again!!
> My guess, it will hang for around 2 hours.
>
> My conclusion:
> Trackstat has become useless after 7.9.1.
Someone else reported problems with Trackstat after upgrading to 7.9.2.
Perhaps they have
Ok. I deleted Trackstat DB.
Rebooted, and LMS was immediately responsive and available!
I then started a scan.
Code:
[20-06-14 12:41:25.3016] Slim::Music::Import::runImporter (511) Starting
Slim::Media::MediaFolderScan scan
.
[20-06-14 12:45:32.0806]
Just discovered this setting:
30722
This was set to High, and I changed it to Max.
I then rebooted.
Now it "only" takes 2h18m for the system to become responsive
I'm guessing that it's Trackstat that has become a problem.
I will now clear the Trackstat DB and then try a reboot without
Thank you very much bpa.
I just did this. But it gave me nothing unusual in the server.log:
Code:
2020-06-14 08:23:21 squeezeboxserver_safe started.
[20-06-14 08:23:27.5943] main::init (387) Starting Logitech Media Server
(v7.9.3, 1591161343, Thu Jun 4 04:16:22
atrocity wrote:
> In my experience, TrackStat will bring the server to its knees after a
> scan, at least on my 100,000 track library. I've just gotten used to it
> and only scan when I don't need to access that server for a while.
>
> Though I only see the problem for maybe 2 hours, not 9.
bpa wrote:
> No . Offhand I don't know how to add command line option to a service, I
> think they are called startup parameters and the parameter will be
> "-d_startup"
Just checked. Assuming your system is "usual"
There is a file /etc/default/logitechmediaserver
It will have a content
GoodVibrations wrote:
>
> Seeing that Trackstat took a long very long time to synchronize I'm a
> bit suspicious of this.
In my experience, TrackStat will bring the server to its knees after a
scan, at least on my 100,000 track library. I've just gotten used to it
and only scan when I don't
GoodVibrations wrote:
> Like this?
> service logitechmediaserver start -d
No . Offhand I don't know how to add command line option to a service, I
think they are called startup parameters and the parameter will be
"-d_startup"
bpa wrote:
> Start slimserver with -d_startup command line option to see whether
> install is OK.
Like this?
service logitechmediaserver start -d
GoodVibrations's Profile:
GoodVibrations wrote:
> Sound advice.
> But my problem is I have absolutely no idea what the issues are...
> I can't find anything in any logs. Just a squeeze process that runs 100%
> for 9-10 hours after every reboot/scan.
>
> I did a minor upgrade from 7.9.1 to 7.9.2. Nothing else.
> After
bpa wrote:
> My advice, forget about plugins for the moment and get your system
> running and clear of other issues before dealign with plugins.
Sound advice.
But my problem is I have absolutely no idea what the issues are...
I can't find anything in any logs. Just a squeeze process that runs
So I kill'ed the processes, cleared cache.db and started in failsafe.
And that works.
So my guess is that it's a plugin-problem.
Seeing that Trackstat took a long very long time to synchronize I'm a
bit suspicious of this.
So I removed failsafe and rebooted and waited for it to respond (9+
GoodVibrations wrote:
> I just accepted an update to the CastBridge plugin.
> The server then restarts, and has now gone into the "woods" to do god
> knows what?!
>
> Oh well. I guess It'll be back in another 9-10 hours...
All the "bridge" plugins are very large about 30Mb and they come from
I'd like to help, but I'm on Windows. If I had your issue I'd terminate
all Squeezebox-related processes: squeezesvr, scanner, squeeze*. I'd
also clear all Squeezebox-related cache.
Restart Squeezebox in safe mode. I'm not sure how this is done in linux.
Try adding --failsafe or -failsafe to
I just accepted an update to the CastBridge plugin.
The server then restarts, and has now gone into the "woods" to do god
knows what?!
Oh well. I guess It'll be back in another 9-10 hours...
Code:
[20-06-11 16:52:59.3242] main::init (387) Starting Logitech Media
Been running a rock stable setup on Debian for more than 12 years now.
I almost never "fiddle" with it, so I'm more than a little rusty with my
own system. That's the price you pay when it just works. :-)
But the other day I got tired of it bugging me with a message about an
upgrade being
35 matches
Mail list logo
