I was never able to get this new version built, which I know is
definitely down to user error.
If this is newer build of Audio::Scan then does it not make sense to add
it to the nightlies since there are other people reporting the same
issue?
mherger wrote:
> It certainly should be there. How did you download that folder?
I downloaded the entire ZIP file and then extracted that and browsed to
the subfolder.
Paul Webster wrote:
> You might not have spotted it because of their unconventional choice to
> not treat upper and lower
It is there
Code:
buildme.sh libpng update to 1.6.37 15 days ago
You might not have spotted it because of their unconventional choice to
not treat upper and lower case as the same ... so the lowercase stuff
comes after the end of the uppercase
I don't know if I'm losing my mind, but I didn't find buildme.sh within
that folder.
It certainly should be there. How did you download that folder?
--
Michael
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
mherger wrote:
> Grab a copy of
> https://github.com/Logitech/slimserver-vendor/tree/public/7.9/CPAN
>
> Then run
>
> ../buildme.sh Audio::Scan
>
> from inside that folder.
Michael
I don't know if I'm losing my mind, but I didn't find buildme.sh within
that folder.
Am I missing something
I didn't have the problem for a long time, but it appeared again three
or four days ago. I grabbed the latest daily build and haven't had the
problem since.
lemppari's Profile:
EDIT: The upgraded LMS alone doesn't fix it. Can you give me a pointer
It would have surprised me...
to compiling Audio::Scan to replace the standard LMS one as that's not
something I've had to attempt before.
Grab a copy of
paulster wrote:
> Thanks Michael. I'll try the update first as that's easy to apply and
> then look at the Audio::Scan compile if it's still playing up.
>
> EDIT: The upgraded LMS alone doesn't fix it. Can you give me a pointer
> to compiling Audio::Scan to replace the standard LMS one as
mherger wrote:
> Unfortunately I still don't have any good idea how to continue the
> search... lemppari hasn't provided much information.
>
> What you could try to do is re-compile Audio::Scan yourself
> (https://metacpan.org/release/Audio-Scan). LMS seems to be hanging while
> reading the
Unfortunately I still don't have any good idea how to continue the
search... lemppari hasn't provided much information.
What you could try to do is re-compile Audio::Scan yourself
(https://metacpan.org/release/Audio-Scan). LMS seems to be hanging while
reading the image data from the flac
Bumping this because I still keep getting my server freeze up and my
music interrupted. I need a means of troubleshooting this.
paulster's Profile: http://forums.slimdevices.com/member.php?userid=23073
View this thread:
Any thoughts on how to track this down then from my end if it's behaving
for you? If lemppari and I are both experiencing the same issue after
upgrading it doesn't seem to be something unique to my environment and
seems more likely that the change in Perl version has upset something.
The fact
Easiest way to trigger it seems to be to hit play on the album in the
left side of the web interface and then on the right side of the screen
use the next button above the now playing art to skip to track 2.
I did this several times successfully. No hiccup whatsoever...
--
Michael
Logitech Media Server Version: 7.9.2 - 1564003588 @ Wed Jul 24 23:48:00
CEST 2019
Hostname: lnx-03
Server IP Address: ***
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: x86_64-linux
Perl Version: 5.28.1 - x86_64-linux-gnu-thread-multi
Audio::Scan: 1.02
Thanks for the test files! Alas - still working as expected. Here's my
system information:
Logitech Media Server Version: 7.9.2 - git-f7c969295 @ 2019-09-03
17:20:15 +0200
Hostname: debian10
Server HTTP Port Number: 9000
Operating system: Debian - EN - utf8
Platform Architecture: x86_64-linux
mherger wrote:
> Could you please answer my questions from my previous post? And would
> you mind sharing a file which causes the problem for you? I'm not sure I
>
> have any flac with embedded artwork.
>
I just tried an album that I knew was problematic before with the images
pulled out of
mherger wrote:
I'll have to test flac with embedded images. I think the test files I
copied all came with cover.jpg instead of embedded artwork.
Have you been able to make any progress with replicating the issues in
an environment with embedded artwork files?
I'm sorry, have forgotten about
mherger wrote:
> I'll have to test flac with embedded images. I think the test files I
> copied all came with cover.jpg instead of embedded artwork.
Michael
Have you been able to make any progress with replicating the issues in
an environment with embedded artwork files?
Thanks
Paul
Not sure if it's relevant, but it seems we've both upgraded to Debian 10
rather than done a clean install. Have you tested with embedded images
rather than images in the folder?
I'll have to test flac with embedded images. I think the test files I
copied all came with cover.jpg instead of
[19-08-12 09:39:44.6769] Slim::Schema::Track::coverArt (372) Retrieving
artwork for:
file:///data/music/Library/Contemporary/FLAC/CDs/Muse/Simulation%20Theory/01.%20Algorithm.flac
Is everybody seeing this issue using FLAC files with embedded artwork?
Would you see the same behaviour with
Probably off target, but:
Is this the first time that Debian x86-64 has seen Audio::Scan v1.02 ?
Debian Buster is perl v5.28. Previous Debian has perl v5.24.
I don't think Audio::Scan v1.02 made it to x86-64 perl v5.24.
i386 and various arms seemed to get it, but not x86-64.
This is weird. I added
SLIMOPTIONS="--perfwarn=0.5"
to /etc/default/logitechmediaserver and restarted logitechmediaserver
and after that Web UI seems to be working just as fast as before in
previous version of Debian. I don't have time now to play more with
this. I'll get back with more
mherger wrote:
> > Same slowness here. I can confirm the unresponsiveness after
> upgrading
> > to Debian 10.
>
> I've installed Debian 10 in a VM with 2MB of RAM, and it's running as
> expected. I didn't have a large library though. Would you see the
> slowness with only a few hundred
Perfmon:
Code:
[19-08-12 09:40:15.6961] Page Build 30.02915 : Page: music/58797d6e/cover
[19-08-12 09:40:15.6965] IO 30.03066 : Slim::Web::HTTP::processHTTP
Server:
Code:
[19-08-12 09:39:39.5642]
paulster wrote:
> Setting artwork.imageproxy to INFO or DEBUG didn't yield anything in the
> log. I did notice what when I set artwork to INFO that there is a 30
> second gap between the two requests for image data when you start
> playing a new album, so it may be whatever is requesting the
lemppari wrote:
> Same slowness here. I can confirm the unresponsiveness after upgrading
> to Debian 10.
Could you please run LMS with --perfwarn, too (as outlined up the
thread)?
Michael
http://www.herger.net/slim-plugins - Spotty, MusicArtistInfo
Same slowness here. I can confirm the unresponsiveness after upgrading
to Debian 10.
I've installed Debian 10 in a VM with 2MB of RAM, and it's running as
expected. I didn't have a large library though. Would you see the
slowness with only a few hundred tracks, too?
--
Michael
Same slowness here. I can confirm the unresponsiveness after upgrading
to Debian 10.
lemppari's Profile: http://forums.slimdevices.com/member.php?userid=1775
View this thread:
mherger wrote:
> > What's the URL format to force a resize?
>
> http://yourserver:9000/music/35b5770b/cover_240x240_m
>
> Just vary the 240x240
Tried a bunch of image IDs and sizes. Instant response to the browser
with the resized images, and nothing logged in perfmon.log
What's the URL format to force a resize?
http://yourserver:9000/music/35b5770b/cover_240x240_m
Just vary the 240x240.
--
Michael
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
What's the URL format to force a resize?
paulster's Profile: http://forums.slimdevices.com/member.php?userid=23073
View this thread: http://forums.slimdevices.com/showthread.php?t=110772
Please run the resizing test.
mherger wrote:
[19-08-03 10:42:22.3803] Page Build 30.11536 : Page:
music/35b5770b/cover_240x240_m
If you loaded one such image with slightly modified parameters (239x239
- it's the resulting image size) to make sure it's not taken from the
cache, would it
mherger wrote:
> >[19-08-03 10:42:22.3803] Page Build 30.11536 : Page:
> music/35b5770b/cover_240x240_m
>
> If you loaded one such image with slightly modified parameters (239x239
>
> - it's the resulting image size) to make sure it's not taken from the
> cache, would it really take
[19-08-03 10:42:22.3803] Page Build 30.11536 : Page:
music/35b5770b/cover_240x240_m
If you loaded one such image with slightly modified parameters (239x239
- it's the resulting image size) to make sure it's not taken from the
cache, would it really take that long to load? Where is the
bpa wrote:
> There are lots of 30 sec timeouts - I picked ImageProxy as it looked
> promising and already got log messages. It seems not ImageProxy but
> maybe something related - I'll look at other possible 30 secs timeouts.
The log message "Resizing" is called after a call to LMS
paulster wrote:
> I agree that looks like it's a timeout value, since it's always 30
> seconds almost to the millisecond.
>
> Setting artwork.imageproxy to INFO or DEBUG didn't yield anything in the
> log. I did notice what when I set artwork to INFO that there is a 30
> second gap between
bpa wrote:
> It is unusual to see every warning with a value very close to 30 secs
> even with I'm guessing different image sizea
>
> 30sec "feels" likes a timeout value - now to find where 30 secs is used
> as a timeout (or a lesser amount with retries, such as 10sec with 3
> retries).
>
>
paulster wrote:
> I jumped around a couple of tracks (and got the 30s log entry each time)
> (the first three), and then just left an album playing, and there's a
> log entry created for the beginning of each track:
It is unusual to see every warning with a value very close to 30 secs
even
Found this random one as well after all the image ones when I checked
the logs today:
Code:
[19-08-03 16:14:37.0496] Request 102.74706 :
Slim::Control::Queries::statusQuery
I jumped around a couple of tracks (and got the 30s log entry each time)
(the first three), and then just left an album playing, and there's a
log entry created for the beginning of each track:
Code:
[19-08-03 10:41:34.9038] Request 0.72406 :
mherger wrote:
> Ok, something about the web server seems to be utterly wrong. >30s to
> get an image isn't good. Would the log file continue like that?
I switched off the logging once I'd captured that, because I was able to
reproduce the problem immediately. It does seem to be sporadic
[19-08-02 17:08:32.1099] Request 0.62725 :
Plugins::Spotty::Connect::_connectEvent
[19-08-02 17:08:32.1120] IO 0.63400 : Slim::Web::HTTP::processHTTP
[19-08-02 17:08:33.4516] Request 1.31422 :
Plugins::Spotty::Connect::_connectEvent
[19-08-02 17:08:33.4534] IO
mherger wrote:
> > So it's definitely in the core product.
>
> Ok, that's good to know. Next you could run slimerver.pl with
> "--perfwarn=0.5". That would log stuff which took longer than half a
> second to perfmon.log.
Code:
[19-08-02 17:08:27.2705] Logging
osveda wrote:
> @bpa: I put output of wget in cli in the posting above.
>
> I tested all day on it. I first installed a complete new system
> (raspbian) and LMS on top. It did not change anything, same slow
> navigation. Then I switched the SD-card to a new rpi and tested this
> one. The new
osveda wrote:
> You are right, sorry for that. I made a last update in my former post
> and will leave it with that.
OK but if you want to follow up it is better to start a new thread of
your own as it is difficult to follow two different problem in the same
thread.
bpa wrote:
>
> (...)
> 1. From original description, your problem look to be network related
> and/or hardware related - this is different to OP issue and a bit of a
> thread hijack.
>
You are right, sorry for that. I made a last update in my former post
and will leave it with that.
osveda wrote:
> @bpa: I put output of wget in cli in the posting above.
>
> I tested all day on it. I first installed a complete new system
> (raspbian) and LMS on top. It did not change anything, same slow
> navigation. Then I switched the SD-card to a new rpi and tested this
> one. The new
Michael
Havent tried it in failsafe mode yet, but that wont tell me where the
problem lies particularly, just whether or not its in the core product.
I realised that Ive been streaming a bunch of music the last week or so
using Spotty, and thats been much better. Went back to my local
Any way you can think of to diagnose the lock-ups in LMS that this
thread is actually about? It seems to be much better since I got the
July 24 build, but definitely isn't working nearly as well as it was on
Debian 9.
bpa asked you to run in --failsafe mode. Did you do that? You mentioned
osveda wrote:
> On the cli of rpi the url's are reachable:
On the CLI the URls were redirected - your wget may not have been.
Try wget with "-v" to get full info (e.g. redirection) and also try the
wget on the redirected URL
Michael
Any way you can think of to diagnose the lock-ups in LMS that this
thread is actually about? It seems to be much better since I got the
July 24 build, but definitely isn't working nearly as well as it was on
Debian 9.
Thanks
> clear cache? reboot LMS? reboot nas? reboot router?
Did all, nothing helped
mherger wrote:
> > I am on a rpi (raspbian 9.9). My last install (lost the number) of
> LMS
> > was more then a year ago. Runs great for a year. Nothing changed but
> > since a week (maybe bit more) LMS is getting
After a little messing with this, my problem seems to be related to pcP
6.0 and players on my network that are running older versions of pcP.
Something that will probably get worked out in later versions I
suspect.
Howard
Howard Passman wrote:
> I'm on Logitech Media Server Version: 7.9.2 -
I am on a rpi (raspbian 9.9). My last install (lost the number) of LMS
was more then a year ago. Runs great for a year. Nothing changed but
since a week (maybe bit more) LMS is getting slower and slower. Tried
Please define "getting slower and slower". Is it playing the music
slowly? Is the
clear cache? reboot LMS? reboot nas? reboot router?
toby10's Profile: http://forums.slimdevices.com/member.php?userid=12553
View this thread: http://forums.slimdevices.com/showthread.php?t=110772
I am on a rpi (raspbian 9.9). My last install (lost the number) of LMS
was more then a year ago. Runs great for a year. Nothing changed but
since a week (maybe bit more) LMS is getting slower and slower. Tried
lots of stuff but nothing helped. Installed the latest download
I'm on Logitech Media Server Version: 7.9.2 - 1564003588 and LMS is dog
slow in responding. Unfortunately I upgraded to an RPI4, piCorePlayer
6.01 and the new LMS all in one fell swoop. Not sure which or if it is a
combo that is the culprit. I use almost no Plugins and of course
everything
bpa wrote:
> LMS is single thread which means a badly behaved plugin or more recently
> some https network problems can "lock" the system as WebUI and player
> are all network comms.
>
> Your LMS seems to be up to date (10 Jul by the datestamp). On 20 Jun
> some changes were made to LMS to fix
Fwiw I noted that the server log was empty when trackstat hangs my Lms
too. After disabling this one specific plugin I've not had any other
plugins cause this issue, but it used to work ok so I'm a bit baffled as
to why that behaviour has changed.
-Transcoded from Matt's brain by Tapatalk-
bpa wrote:
> Also check your OpenSSL libraries are up to date
Also, make sure that you have the -ca-certificates- package installed.
It provides root certificates for verifying secure SSL/TLS connections.
You almost certainly do, but it is worth checking, as an absence of root
certificates
LMS is single thread which means a badly behaved plugin or more recently
some https network problems can "lock" the system as WebUI and player
are all network comms.
Your LMS seems to be up to date (10 Jul by the datestamp). On 20 Jun
some changes were made to LMS to fix some blocking code on
I've been able to get the problem to occur again with a clean logging
period, and I didn't get anything at all in the server log, so I think
those previous errors were related simply to it losing connection with
the players.
This definitely feels like it's related to the Perl version in Debian
paulster wrote:
> I don't use TrackStat, but I have the following plugins installed:
> iPlayer
> Custom Browse
> Hide Menus
> Kids Play
> Multi Library
> Power Save
> Switch Player
> Spotty
> YouTube
>
> I'm seeing these entries repeatedly in the log file, so I don't know
> whether it's an
paulster wrote:
>
> I'm seeing these entries repeatedly in the log file, so I don't know
> whether it's an issue with the web interface since the Perl change:
> [19-07-08 21:29:06.2822] Slim::Web::Cometd::handler (422)
> errorNeedsClient: 00:25:31:04:70:cb, status, -, 10, menu:menu,
>
I don't use TrackStat, but I have the following plugins installed:
iPlayer
Custom Browse
Hide Menus
Kids Play
Multi Library
Power Save
Switch Player
Spotty
YouTube
I'm seeing these entries repeatedly in the log file, so I don't know
whether it's an issue with the web interface since the Perl
I've seen solid hangs in Lms since upgrading perl versions and it seemed
to be to do with the trackstat plugin. Do you use this?
Though I suspect it's more to do with a perl behaviour change. To me it
seems more likely that a method is being used which previously ran in
the background in
paulster wrote:
> Any thoughts?
Any messages in server.log ? such as network access problems
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread:
67 matches
Mail list logo
