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
mvordeme wrote:
> I've switched on debug logging for slimproto. It generates quite a lot
> of data.
Inded, but I should have said that "info" is good enough
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
mvordeme wrote:
> 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
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
I think I've founded the reason why. Do you run any of my bridge that
might loose connection/reconnect regularly? See
https://github.com/Logitech/slimserver/pull/625
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
mvordeme wrote:
> Today, the LMS ran out of file handles again, but this time, they were
> all sockets. It had been running for 2 months.
There is an issue with cli_sockets when players are disappearing/coming
back. I've not been able to figure it out yet
LMS 8.2 on Odroid-C4 -
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.
Is there any pattern in those files? Size? Filename? File type?
___
unix mailing list
unix@lists.slimdevices.com
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
See https://github.com/Logitech/slimserver/pull/553 if you want to give
it a try. I'm checking files with
Code:
lsof +D /tmp -a -p 80292
And I can confirm that nothing is left open with AAC and with FLAC files
are removed automatically. At
philippe_44 wrote:
> I do remember very well the discussion. I have made a few additional
> tests and in fact the DESTROY happens as expected when the cache is set
> to 10 but it need to be created with 10, not modified later at runtime
> as I was doing before.
>
> Still, that does not solve
mherger wrote:
> No, AFAIK, 500 is the number of cached tracks. After that, they
> should
> be closed but I'm not sure that works as expected. I've reduced
> that to
> 10 and traced DESTROY it's very unclear to me when it happens,
> except
> when you terminate the slimserver process. The
No, AFAIK, 500 is the number of cached tracks. After that, they should
be closed but I'm not sure that works as expected. I've reduced that to
10 and traced DESTROY it's very unclear to me when it happens, except
when you terminate the slimserver process. The code is in
/usr/share/perl5/Slim
mvordeme wrote:
> 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
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
mvordeme wrote:
> 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
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
mvordeme wrote:
> 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
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
mvordeme wrote:
> 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.
If the files are the issue (or possibly a side effect of the issue -
objects not being garbage collected), then I think you have to find out
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 &
mvordeme wrote:
> 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.)
Here is the code in charge of limits
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
bpa wrote:
> Great that you solved it. Even better that it was not something obvious.
I hope that the FreeBSD team will solve it quickly, because setting the
locale to C can cause problems with file names.
A huge thanks to everyone that helped me to figure it out.
https://audiodigitale.eu
Simonef wrote:
> Big News.
> Starting LMS with LC_ALL=C instead of LC_ALL=en_US=UTF-8 solves the
> bug.
>
> My first reaction was "How the f a locale setting can cause a memory
> leak of 12GB in an OS used by servers (Netflix included as an
> example)??" Because this seems to be a bug of the
philippe_44 wrote:
> I re-read the pipeline code and I can only think that BSD screws up
> either with the reader/writer/source socket by not releasing buffer when
> using localhost sockets or in that code
> >
Code:
> >
> if ($writelen) {
>
>
bpa wrote:
> There have been user of LMS on FreeBSD system for a good while and
> transcoding is bound ot be used - yet I don't recall crash report.
>
> Could it be that the behaviour (i.e. don't shrink memory allocation from
> "high water" mark is normal for FreeBSD) is normal FreeBSD and
philippe_44 wrote:
> The 'pipeline_pending_bytes' are not released either when being shrunk
> or re-assigned to the substr() of $pendingBytes. In any case,
> unfortunately, it looks like an obscure BSD+Perl issue that will be
> quasi-impossible to track w/o a full system and my FreeBSD VM is a
I re-read the pipeline code and I can only think that BSD screws up
either with the reader/writer/source socket by not releasing buffer when
using localhost sockets or in that code
Code:
if ($writelen) {
main::DEBUGLOG &&
Maybe you could have a look at song.pm and pipeline.pm. I did that
yesterday but could not see anything that would trigger a question, but
more eyes always help
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
mvordeme wrote:
> 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
mherger wrote:
> > Files opened in /tmp are expected, this is the cache for scanning
> remote
> > tracks
>
> I vaguely remember having discussed the risk of those filehandles in
> your AAC seeking PR. Could there be an issue that sometimes we store a
> reference to it outside the track
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
mvordeme wrote:
> But 450? And all of them are still open in LMS.
>
> Files containing binary data only seem to end like this:>
Code:
> >
TsgpdrollsbgprollEbudtaZmeta!hdlrmdirappl-ilst%toodataLavf58.20.10freeZMmdat
> >
Yes, the Max is set a 500
Simonef wrote:
> As already stated before:
> 4 local flacs (random)
> No plugin involved.
> With every kind of audio processing, sox, FLAC, lame.
> This does not happen only if there Is no transcoding involved.
If this issue happens with any use of pipelining then I think there
would be many
mherger wrote:
> > I tried the command and played 4 tracks (with transcoding)
>
> What kind of tracks? And what kind of transcodings are involved? Are you
>
> using any kind of 3rd party plugin which is involved in the transcoding
>
> process? If so: can you reproduce the issue after
I tried the command and played 4 tracks (with transcoding)
What kind of tracks? And what kind of transcodings are involved? Are you
using any kind of 3rd party plugin which is involved in the transcoding
process? If so: can you reproduce the issue after remvoving it, only
using default
Files opened in /tmp are expected, this is the cache for scanning remote
tracks
I vaguely remember having discussed the risk of those filehandles in
your AAC seeking PR. Could there be an issue that sometimes we store a
reference to it outside the track object? Thus it doesn't get freed when
bpa wrote:
> This looks like MPEG4 header - I recognise the udta and mdat
>
> IIRC LMS reads the start (e.g. x number of bytes)of the files/stream
> (maybe into a temp file) before it can tell a player to stream.
In Slim::Utils::Scanner:Remote.pm - the routine streamAudioData - reads
bpa wrote:
> There is buffering of data withing LMS and so file compression will
> affect how much is buffered. A lot of buffering is associated with a
> file handle.
> Perl will only garbage collect resources associated with a file handle
> when it is closed and no longer in use.
>
> As a
mvordeme wrote:
> 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
> >
This looks like
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 |
Files opened in /tmp are expected, this is the cache for scanning remote
tracks
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2,
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
The majority of these file handles point to temp files most of which are
less than 100 k in size:
Could you peek into some of them to try to understand what they are?
What music service(s) would you be using? I've seen reports about Spotty
writing to /tmp (which I thought I did fix
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:
bpa wrote:
> As a sanity check, you can check whether number of handles increases
> after playing a pipeline process started/finished with something like
> lsof -p | wc -l
As a reference,I did a quick test playing a file to a player and it is
the only activity on LMS.
File handles go up by
Simonef wrote:
> . While the transcoding software used (sox, flac lame or whatever)
> is always correctly closed, the size of slimserver.pl grows A LOT and
> the ram usage of slimserver.pl never goes down.
> So I'm pretty sure that it's leaving some handles/objects around open.
> And there
bpa wrote:
> A long time ago, on some Linux distros, there was a problem with
> pipelining when the transcoding process would not shut down properly and
> become a zombie - this would mean many resources in LMS would not be
> released as handles were not closed etc.
>
> It is a wild shot but
Simonef wrote:
> The memory leak is present on *BSD. And it seems also of linux arm
> platforms (as said by another user)
> I've NOT experienced this bug in debian x64
A long time ago, on some Linux distros, there was a problem with
pipelining when the transcoding process would not shut down
bpa wrote:
> I got a little lost on platforms being used.
> Your initial report was on a FreeNAS.
> Then you later said bug does not happen in Debian 64bit.
>
> Can you clarify the problem happens only when pipelining on either Linux
> based or FreeBSD based system ? or just on FreeBSD based
Simonef wrote:
> No, the bug has to do with the pipelining. I have passed the witness to
> philippe44 to analyze the code.
I got a little lost on platforms being used.
Your initial report was on a FreeNAS.
Then you later said bug does not happen in Debian 64bit.
Can you clarify the problem
mherger wrote:
> > @mherger I made a pull request on slimserver-vendor
> Would that PR fix the issue you've reported here?
No, the bug has to do with the pipelining. I have passed the witness to
philippe44 to analyze the code.
https://audiodigitale.eu
@mherger I made a pull request on slimserver-vendor
Would that PR fix the issue you've reported here?
___
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix
philippe_44 wrote:
> Sorry my bad: from memory, I was remembering
>
> And for some reasons I thought it meant your actual system was 32 bits
Oh! no problem. If you need some help for testing or other things don't
hesitate to contact me.
@mherger I made a pull request on slimserver-vendor
Simonef wrote:
> What?
> all the system I have tested on are 64bit, Perl version 5.32
Sorry my bad: from memory, I was remembering
>
> With Debian 64bit this bug does not seem to happen at all.
>
And for some reasons I thought it meant your actual system was 32 bits
LMS 7.9 on Pi 3B+ &
philippe_44 wrote:
> Yous aid it does not happen with x64, right? What Perl version is this
> on x86?
What?
all the system I have tested on are 64bit, Perl version 5.32
https://audiodigitale.eu
Simonef's Profile:
philippe_44 wrote:
> Have you tried with transcoding but without use of sox (choose a
> transcoding requirement that does not need it like "ops mp3" or "mp3 mp3
> transcode forced by bitrate limitation. The idea is to see if this is
> specific to an external transcoder, especially sox, or if
Simonef wrote:
> Same problem if transcoding without sox. Flac->mp3 and Flac->pcm dont
> use SoX and shows the same beahviour.
> I just tried with lms 7.9.4, same behaviour again.
>
> w/o transcoding it seems to not happen at all.
Excellent, that seems to point around the pipeline then
LMS
philippe_44 wrote:
> Have you tried with transcoding but without use of sox (choose a
> transcoding requirement that does not need it like "ops mp3" or "mp3 mp3
> transcode forced by bitrate limitation. The idea is to see if this is
> specific to an external transcoder, especially sox, or if
Simonef wrote:
> Thanks a lot for the encouragement.
> It seems to be correlated proportionally to the type of transcoding you
> want to do.
> As an example:
> With very small files and light transcoding (to MP3 for ex) It takes
> hours to show a minimum RAM usage above the normal (where normal
mvordeme wrote:
> 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
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
mherger wrote:
> >> You'll need to install Devel::NYTProf for your Perl. And then run
> with
> >> above parameter. Please note that running LMS this way can generate a
> >> ton of data which will take a while to analyze by the NTYProf tools.
> But
> >
> > Ok installed all the dependencies
You'll need to install Devel::NYTProf for your Perl. And then run with
above parameter. Please note that running LMS this way can generate a
ton of data which will take a while to analyze by the NTYProf tools. But
Ok installed all the dependencies required. Had to fix some of them
because very
But then you are not playing HTTPS services, right? I know it sounds
like a silly question but I want to make sure before I dig again into
all the contorted SSL elements activated in LMS. There are many things
there, its difficult to find its way sometimes. For example the code
for NB sockets
mherger wrote:
> > I tryed to set (server.memory) logging to debug to find out the cause
> of
> > the memory leak but I get:
> > Slim::bootstrap::tryModuleLoad (286) Warning: Module
> > [Slim::Utils::MemoryUsage] failed to load:
>
> You'll need to install Devel::NYTProf for your Perl. And then
I tryed to set (server.memory) logging to debug to find out the cause of
the memory leak but I get:
Slim::bootstrap::tryModuleLoad (286) Warning: Module
[Slim::Utils::MemoryUsage] failed to load:
You'll need to install Devel::NYTProf for your Perl. And then run with
above parameter. Please
mherger wrote:
> > Before every test written below I restarted LMS, to have a sort of
> > baseline.
> > Player: squeezelite-x on windows and squeezelite-R2 on linux. Under
> file
> > types Flac->PCM is selected.
>
> Could you please try again with all custom transcoding disabled?
>
> What
mherger wrote:
> > Before every test written below I restarted LMS, to have a sort of
> > baseline.
> > Player: squeezelite-x on windows and squeezelite-R2 on linux. Under
> file
> > types Flac->PCM is selected.
>
> Could you please try again with all custom transcoding disabled?
>
> What
Before every test written below I restarted LMS, to have a sort of
baseline.
Player: squeezelite-x on windows and squeezelite-R2 on linux. Under file
types Flac->PCM is selected.
Could you please try again with all custom transcoding disabled?
What plugins are you using?
mherger wrote:
> > About replicating... Just playing some local flacs or from Qobuz, in
> > both cases the leak happens
>
> Could you try to replicate using only Qobuz? What formats are you
> streaming? On what players? Could transcoding be involved?
I did some tests:
LIBRARY INFO:
Total
About replicating... Just playing some local flacs or from Qobuz, in
both cases the leak happens
Could you try to replicate using only Qobuz? What formats are you
streaming? On what players? Could transcoding be involved?
___
unix mailing list
I would suspect that it has to do with database management. Possibly
linked to online music integration.
How big is your local library (number of tracks)
How big is your qobuz library.
server.log and scanner.log would be the place to start.
piCorePlayer a small player for the Raspberry
paul- wrote:
> You cannot see memory leaks from htop output. All that it shows you is
> memory used.
Of course, but based on memory used you can understand if a memory leak
Is happening. If usually a process takes from 100 to 400MB of RAM and
now It continues to grow until the whole 12GB are
You cannot see memory leaks from htop output. All that it shows you is
memory used.
piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please 'donate'
paul- wrote:
> Going to offer some proof? or information on how to replicate what you
> see?
Proof:
33146
About replicating... Just playing some local flacs or from Qobuz, in
both cases the leak happens
+---+
|Filename:
Going to offer some proof? or information on how to replicate what you
see?
piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please 'donate'
I registered a memory leak of over 12GB(not using It on PCP), when RAM
Is full the process Is closed ofc.
Version: 8.1.2 - 167469
Is there already a fix?
Thanks,
Simone
https://audiodigitale.eu
Simonef's Profile:
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
mvordeme wrote:
> 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.
8.2 is the next feature release, 8.1.1 is the closer bug fix of 8.1
(here
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 |
mvordeme wrote:
> Thanks. So it may already be fixed. I am still on 8.1.0 - 1608064080 @
> Tue Dec 15 22:13:24 CET 2020.
yes, you need the nightly - Michael has not released yet an "official"
version
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3.
mvordeme wrote:
> 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?
I tried as well with the version that
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
mvordeme wrote:
> 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?
Just out of curiosity, I tried to
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 |
philippe_44 wrote:
> So "unfortunately" no. Can you try with a player that natively supports
> mp4/aac? I'd like to rule-out faad
Found it this time, was my bad :eek::mad::mad::mad::eek:
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3,
mvordeme wrote:
> I'll have an eye on whether it always affects the same tracks.
philippe_44 wrote:
> I think I've identified a corner case that could explain the last block
> of a track being skipped
So "unfortunately" no. Can you try with a player that natively supports
mp4/aac? I'd like
1 - 100 of 181 matches
Mail list logo
