Thanks for your response guys, I did some more testing and I have a
pretty good idea of what is actually happening, but don't have time to
post all the details right now, maybe tomorrow.

Just to quickly answer your questions.

bpa wrote: 
> 
> You have virtualised system - can you give more detaisl (e.g. Ubuntu
> virtualised under Windows ?)

I am running LMS on Ubuntu 20.04.2 LTS server virtualized on ESXi v7, I
am pretty sure virtualization does not have anything to do with this
issue though. 

bpa wrote: 
> 
> The FIN/RST issue can come about from packets not arriving. Years ago
> one cause of this was a Windows security s/w inserted into network chain
> and then holding onto last packet for "examination"
> 
> You seem to have suqeezelite , wireshark and LMS logs. Can you see if a
> packet goes missing - probably LMS to Client  ? 
> 
I am running Wireshark on the client side, so screenshots that I posted
are showing what's arriving, but I did run Wireshark on the server as
well and packets do match up. RST packet is indeed coming from the
server, not necessarily LMS itself, most likely kernel TCP stack.


ralphy wrote: 
> There have been 'similiar discussions in the squeezelite thread'
> (https://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)&p=981302&viewfull=1#post981302).
> 
> The discussion goes on for many pages and I have not been able to
> reproduce the problem, but several users have reported the issue.
> 
> Do you also get socket errors in the squeezelite logs?

Thanks for posting the link, I have not seen it, but will look at it
later. No socket errors in the logs. The issue that I am having I think
is the same as was discussed in this thread
https://forums.slimdevices.com/showthread.php?113554-SqueezeLite-on-Windows-pausing-interruption-dropout-of-audio-every-5-minutes.
I don't have an older version of squeezelite to test, but I suspect
older version did not handle the condition of socket disappearing (RST
packet arriving and Windows destroying TCP receive buffers) very well
and thus people were seeing 100% CPU usage and error messages in the
log. Handling of that condition was addressed, but the underlying cause
of the issue was not. People simply worked around it by increasing
buffer size.


------------------------------------------------------------------------
lngxa's Profile: http://forums.slimdevices.com/member.php?userid=71826
View this thread: http://forums.slimdevices.com/showthread.php?t=114661

_______________________________________________
Squeezecenter mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/squeezecenter

Reply via email to