Yes, it would be. It is something you probably only notice when there is
another clock next to it, or maybe if you use a player as your alarm
clock. Since the Pi hardly ever needs a reboot, it is a useful feature.
scaleo home server 2105 & picoreplayer 8.1.0 | logitech media server
8.3.0 |
I like the new feature, thanks. It keeps configuration of the time
server in a single place.
scaleo home server 2105 & picoreplayer 8.1.0 | logitech media server
8.3.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero
This seems to very random. For weeks and months, the socket count
remains stable, and then suddenly, the server is stuck and needs to be
restarted.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control 20120716.103808 |
transporter & duet & touch &
1000 sockets in two months would have been more than 15 sockets per day,
but right now, everything is quiet. The LMS has 39 open file handles in
total, of which 15 are sockets. That number has increased by one since I
am watching it (which was before I started logging).
scaleo home server
Actually not. Originally, we used to shut down our WiFi overnight, but
since our daughter has been on an unpredictable time schedule for a few
months, we leave it up 24/7. I mean, now and then a player loses the
connection, but I'd be surprised if it should happen frequently enough
to explain
Today, the LMS ran out of file handles again, but this time, they were
all sockets. It had been running for 2 months.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 &
Here is the list. They all belonged to the user tc with access mode 600:
Code:
~$ find /tmp -type f -maxdepth 1 -user tc -perm 600
tc@piCoreServer:~$ find /tmp -type f -maxdepth 1 -user tc -perm 600
AUi4vaEOf9
jgDv0YCpyz
dukSVaJOYO
Yu5XG1ABnC
hdElUQPHie
This time, a large number of temp files had been left behind after I had
shut down the LMS.
Code:
~$ find /tmp -type f -maxdepth 1 -user tc -perm 600 | wc -l
612
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server
Today, the server is dead again. The difference is that now, there are
no open file handles. Memory consumption is at 617 MB, and there are 958
temp files around:
Code:
Mem: 1911440K used, 42912K free, 127048K shrd, 5900K buff, 1157512K cached
CPU: 0.2% usr 0.0% sys
I can confirm that no open file handles are left behind, only the number
of files in /tmp/ is growing. I'll keep an eye on the files and on the
memory consumption.
philippe_44 wrote:
> I'm checking files with
> >
Code:
> >
> lsof -r +D /tmp -a -p your_pid
>
I installed tonight's development build and will give it a spin. Thanks
a lot for your help.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero
That is a fact which makes investigating the problem difficult. When
there are 500 open file handles, it is difficult to keep track of what
is happening.
I understand from the code that with a memory configuration of high, the
process should not use up more than 500 MB of memory. Is that
I am not sure about all the debugging stuff, but it appears to me that
it is not a matter of configuring things but of changing the code. I
have tried to increase the amount of logging for a few items but didn't
learn much. Where is all the code? The directory containing the
slimserver.pl only
I had found two different types of files, one of which had been
identified somewhere above in the discussion. So far, I have not been
able to actually see it happen. Every time I observe the system, all new
file handles are closed again after a few minutes. I have been thinking
about writing a
Now it is finally dead and does not play anything any more. The file
handle count is up to 1024 and memory consumption is above 1 G. The
system has almost no space for buffers any more. It already stopped
playing hi-res FLAC files weeks ago.
Code:
$ sudo lsof -p 32307 |
Trying to find a pattern, but no success, so far. I thought that maybe
the mechanism of releasing the files is working in general but leaving
the odd file behind. In that case, must of those files should be rather
new. This doesn't seem to be the case.
Code:
Date |
Meanwhile, the LMS is using almost 800 M of memory. The process is
holding a total 696 of open file handles, of which 20 are sockets, 12
are files in /mnt/mmcblk0p2/tce/slimserver/Cache/ and 656 are files in
/tmp/. All these files do actually exist, and all existing temp files
seem to be
Seems that I need to get my head around that funny Perl syntax after
all. In the LMS settings, I can choose between normal, high and maximum
database size. It is set to "high" for machines with 1+ GB of memory,
which should be fine. 2 GB is a little too much.
scaleo home server 2105 &
Loading this discussion with more stuff: The number of file handles on
my Pi has now exceeded 500, memory is at 580 M. I'll keep an eye on it.
(For the protocol: Today, I have been listening to Deezer Smart Radio
for some time.)
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media
philippe_44 wrote:
> Yes, the Max is set a 500 internallyOk, so file handles should be fine and
> probably not related to the
growing memory consumption.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control 20120716.103808 |
transporter & duet &
I believe that if there really is an issue with file handles on my Pi,
it is not the same that Simone has reported. My open file handles are
back down to 459 and memory usage is up to 562 M. Since it looks like
for every transcoded stream, a temp file is left over, but the number of
file handles
But 450? And all of them are still open in LMS.
Files containing binary data only seem to end like this:
Code:
Tsgpdroll sbgprollEbudtaZmeta!hdlrmdirappl-ilst%too dataLavf58.20.10freeZMmdat
scaleo home server 2105 & picoreplayer 6.1.0 |
I am only using Tidal. My wife is listening to web radio, but since it
doesn't require transcoding, I don't expect it to leave temp files
behind.
I just had a quick look at a few of those files. They contain mainly
binary data. Some of them end with XML like this:
Code:
I am not entirely sure what happened just now. The track I was playing
was cut short by maybe half a minute and the next track started. The
number of file handles went up by another 4 and after some time went
down by 1. Also at the moment, the contents of /proc/32307/fd and the
output of lsof
On my Pi, the number of file handles goes up by 4 when starting playback
and immediately drops again when playback stops. This appears to be good
news at first sight, but nevertheless, the LMS process has piled up the
impressive number of 459 open file handles in the last 21 days:
Code:
Just for your encouragement, since you seem pretty well on your way
without interference from my side: It seems that I can observe the leak
as well with standard transcoding settings, only it is so subtle that I
will probably upgrade my LMS before the Pi runs out of memory. My LMS is
up since
Greg Erskine wrote:
> Has anyone worked out the actual time drift of a Raspberry Pi?My 4B seems to
> drift less than 2 seconds per day.
Code:
$ date
Sat Jan 16 21:15:23 CET 2021
tc@piCoreServer:/etc/sysconfig$ sudo /usr/bin/getTime.sh
Hm, I just did
Code:
sudo ./lms-update.sh --release devel -s -r -u
as prescribed. But I don't expect there to be any differences so far,
anyway.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.2.0 | server power control
8.1.0 was a nightly at the time. Version numbers seem a little volatile
at the moment. Everything is fine with 8.2.0 - 1609139175 @ Mon Dec 28
09:23:00 CET 2020. Thanks a lot.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.1.0 | server power control 20120716.103808 |
Thanks. So it may already be fixed. I am still on 8.1.0 - 1608064080 @
Tue Dec 15 22:13:24 CET 2020.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.1.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert
I found a test track, if you are interested. When you play the live
album "Showtime, Storytime" by Nightwish, the last three seconds of the
second track "Wish I Had an Angel" go missing. On which branch are you
intending to fix it?
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media
Oh, this is cool. I actually watched a lot of YouTube over the holidays
and didn't have a chance to pin down a certain track on Tidal. Thanks a
lot for your dedication.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.1.0 | server power control 20120716.103808 |
I'll have an eye on whether it always affects the same tracks.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.1.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero 140
So far, Tidal has been playing without any problems. No stuck
connections.
The skipping of the last few seconds of a track seems unrelated. It
occurs now and then. I have no idea how to pin it down.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.1.0 | server power
bpa wrote:
> mvordeme's persistence "a voice in the wilderness" and narrowing
> problem down to network was essential.It was something that annoyed me almost
> every day, but that made it
reproducible and easy to investigate. If I knew Perl, I would even had
looked at the code, but as it
philippe_44 wrote:
> - When transcoding, the Tidal server does not send the close sequence
> (at least I don't see it in wireshark)
Doesn't it have to send something, or else the O/S wouldn't report the
connection as CLOSE_WAIT?
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media
One thing I found out just now: Whenever I skip the currently playing
track, the connection is closed properly. The new connection is using a
different port, so I don't think it is the old connection reused. Only
when a track is played to the end does the connection hang around. I
could have a
bpa wrote:
> I'm not sure of the Tidal and new AAC support details, but within Perl,
> normally a TCP connection is an "object".
> TCP conection is closed when an explicit "close" is performed or when
> TCP connection object is destroyed (i.e. no variable has a references to
> it).
> Object
Restarting the LMS moved the counters a little.
Code:
tc@piCoreServer:~$ head -n2 /proc/net/netstat | cut -d' ' -f 51-55
TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout
TCPAbortOnLinger
191 3667 46 503 0
scaleo home server
Players are currently re-buffering. Time to check the stats.
Code:
tc@piCoreServer:~$ netstat -tn 2> /dev/null | grep CLOSE_WAIT | wc -l
110
bpa wrote:
> To see if there is some odd network activity at the same time as the
> playback issues,
The columns seem to be shifted by one.
Code:
tc@piCoreServer:~$ head -n2 /proc/net/netstat | cut -d' ' -f 51-55
TCPAbortOnData TCPAbortOnClose TCPAbortOnMemory TCPAbortOnTimeout
TCPAbortOnLinger
137 2918 24 275 0
What about all those open
Code:
tc@piCoreServer:~$ cat /proc/net/netstat | cut -d' ' -f 1,35,41
TcpExt: TCPLostRetransmit TCPTimeouts
TcpExt: 6863 13430
IpExt:
IpExt:
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.0.1 | server power control
si
Code:
TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts
PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps ArpFilter TW
TWRecycled TWKilled PAWSActive PAWSEstab DelayedACKs DelayedACKLocked
DelayedACKLost ListenOverflows
unfortunately, not:
Code:
tc@piCoreServer:~$ netstat -ts
netstat: invalid option -- 's'
BusyBox v1.30.1 (2019-06-20 23:16:54 EDT) multi-call binary.
Usage: netstat [-ral] [-tuwx] [-enWp]
Display networking information
-r Routing table
-a
Playing the third track after restart:
Code:
tc@piCoreServer:~$ sudo netstat -tnp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp0 0 192.168.178.101:3483
Alright, I decided to change my mindset and try to get to the bottom of
this myself. This looks very much like a connection leak.
LMS running for half a day:
Code:
tc@piCoreServer:~$ netstat -tnp
netstat: can't scan /proc - are you root?
Active Internet connections
Can this discussion be moved?
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.0.1 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero 140
I re-wired mains and network to the pi and, while I was at it, updated
the LMS to Logitech Media Server Version: 8.0.1 - 1607087403 @ Fri Dec 4
14:26:56 CET 2020. It is still showing the same behaviour. I noticed one
more thing. A few tracks before Tidal streaming breaks and the pCP
interface
The same thing again today. The moment Tidal gets stuck, the pCP web
interface does not load properly any more. And I noticed another thing:
I configured the Transporter to power down the audio section when off.
It was sitting there, clicking about once per minute. It seems that the
entire
Tidal got stuck again, today, and I tried a few more things.
- On the Receiver, the MPEG-4 podcast did not play, either. It showed
the same behaviour as tracks from Tidal, i.e. re-buffering and now and
then playing a few seconds.
- On squeezelite, Tidal tracks would still play, but
Next time the LMS goes into denial, I can just try to play it. Do I
simply need the Podcasts plug-in?
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.0.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert
No, I only pay for compressed audio. 320 kBit AAC is what the Controller
shows.
scaleo home server 2105 & picoreplayer 6.1.0 | logitech media server
8.0.0 | server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero 140
I have not updated for a week, now, because I didn't want to introduce
new uncertainties. The version is Logitech Media Server Version: 8.0.1 -
1606059084 @ Sun Nov 22 16:49:21 CET 2020.
It is buffering. The Controller will show rebuffering ... and only now
and then a short snippet will play.
A few results. When Tidal streaming got stuck again, today, I checked a
few things.
- The faad and flac processes had the same memory footprint as usual.
- The LMS would still spawn new faad and flac processes when skipping
tracks.
- Local FLAC files (16 bit / 44.1 kHz) would play fine
Currently, my FLAC library is on the other server, but I'll copy a few
albums and test.
Right now, I only have a Touch which used to be able to play Tidal
natively. There have been no problems with that, as far as I know.
"Seeking" within a track didn't work any more, last time I checked, but
What I don't understand about the memory: The file system looks like
there are 2.6 G of virtual file system in memory, which is not possible,
and which would not leave 1.9 G of memory for the processes, so in some
way, the numbers need interpretation. I wrote "out of memory" because
that is my
For a few days, now, I have been running a piCorePlayer 6.1.0 with LMS
on a Pi 4 B with 2G of memory. I mainly use the Pi to transcode AAC
streams from Tidal. There are no additional plug-ins installed.
I observe the following behaviour: After the LMS is started, it will run
without complaints
I just read here that the file
/tmp/slimupdate/update_url might be in the way.
scaleo home server 2105 | logitech media server 8.0.0 |
server power control 20120716.103808 |
transporter & duet & touch & boom & radio | rotel rc-995 & rmb-100 |
nubert nuvero 140
58 matches
Mail list logo
