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
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
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
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
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
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.
Michael
Have you been able to make any progress with replicating the issues in
an environment with embedded artwork files?
Thanks
Paul
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]
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?
paulster's Profile: http://forums.slimdevices.com/member.php?userid=23073
View this thread: http://forums.slimdevices.com/showthread.php?t=110772
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
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).
>
>
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
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
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
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
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
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
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 always run the current version of Debian without issues for the
last 10 years or so, but since upgrading my LMS server to Debian 10
(Intel x64) I've noticed that the web interface keeps becoming
unresponsive for periods of about 10 seconds, and then it catches up.
In some cases the music
mherger wrote:
> I'm sorry to spoil the party: it has nothing to do with the browser or
> its zoom setting. It was simply a problem with the page rendering caused
>
> by using icons for items which don't have any. I disabled the icons
> server-side, which fixed the layout issue.
Michael
DJanGo wrote:
> Did you press [ctrl] and scroll down with your mouse wheel??
> Your chars seems a bit big(ger) than std.
Genius! I reset the zoom and now it's rendering properly.
Interestingly, when I increased the zoom it still appeared to render
properly, so I have no idea what caused this.
mherger wrote:
> This is not a LMS change, but the way Spotify wanted us to implement the
>
> search history years ago. It's always been that way: you get a menu of
> recent searches once you've done a search.
Thanks, but have you seen how it's rendering on Firefox? It looks a
mess, with the
I updated my release of 7.8.1 because of the documented issues with
software players in Michael's other thread, and have noticed some
weirdness in the official Spotify interface since I did, pertaining to
search.
In 7.8.1 - 1426671206 hovering over the Search text gave a direct search
text entry
29 matches
Mail list logo
