ralphy wrote:
> 'squeezelite-1.9.8-1324-test4-win64.zip'
> (https://www.dropbox.com/s/zw96827qrilim58/squeezelite-1.9.8-1324-test4-win64.zip?dl=1)
> adds a short delay before both of the continue statements in
> slimproto.c.
As an additional test, I've also provided a 'win32 build of squeezelit
fpo wrote:
> No luck yet.
>
> Let me explain my reasoning: What I saw when I attached the Visual
> Studio Debugger to squeezelite and interruped it while in 100% cpu load
> was, that its from one thread and this thread sometimes had its priority
> elevated slightly, presumably when in kernel co
I have the same issue.
Actually i am running LMS 8.1.0 on a Synology DS220+ as Docker
container.
Works flawless, but when i use Squeezelite X in Win 10 20H2 i have the
same dropouts mentioned here. Very high cpu load, 30 seconds dropout.
Same on my notebook and PC.
-
@ ralphy
I don't see any *volatile* modifier in the code although there is data
shared among threads, e.g. the read/write positions of the buffers.
Is that by design?
Everything seems to be synchronized via mutexes, however, if I
understand volatile correctly, data updated on one thread could
foopydog wrote:
>
> I would like to know: is this the *actual* solution?
>
> Using a larger buffer would cure certain problems, such as overrunning
> the boundary of the struct from malloc. But it might also only side-step
> the problem, only to re-emerge later on, because the problem is
> som
ralphy wrote:
> ...
> Please try 'squeezelite-1.9.8-1324-test3-win64.zip'
> (https://www.dropbox.com/s/put1qx5j9flhajv/squeezelite-1.9.8-1324-test3-win64.zip?dl=1).
No luck yet. See my log below with lines inserted where I detect cpu
load.
[22:52:50.094] process_strm:280 strm command t
[22:52
I found another thread which directly addresses this issue with "audio
stopping for 30 seconds".
https://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)&p=986931&viewfull=1#post986931
It was also referenced elsewhere i
fpo wrote:
> Still dropouts although the timing has changed slightly. I see however
> no difference at the packet level with regard to the response of the
> client towards a KeepAlive probe from the host, i.e. still no [Keep
> Alive Ack] from the client at the stream socket. Can't see a fault in
ralphy wrote:
> ...
> squeezelite-1.9.8-1324-test2-win64.zip
> ...
Still dropouts although the timing has changed slightly. I see however
no difference at the packet level with regard to the response of the
client towards a KeepAlive probe from the host, i.e. still no [Keep
Alive Ack] from the
ralphy wrote:
> squeezelite-1.9.8-1324-test1-win64.zip had keepalive set on the
> slimprotocol 3483 port.
>
> 'squeezelite-1.9.8-1324-test2-win64.zip'
> (https://www.dropbox.com/s/8ljybktgtuqp37l/squeezelite-1.9.8-1324-test2-win64.zip?dl=01)
> enables keepalive on the stream socket, which is no
fpo wrote:
> Unfortunately no change, dropouts still. The KeepAlive behavior seems
> unchanged. You say you have enabled KeepAlive on the *slimprotocol*
> socket. Is this the one with port 9000 or 3483. It is needed on port
> 9000.
>
> Here is the traffic on port 9000 prior to the 100% cpu time
ralphy wrote:
> Thanks for continuing to help track down this problem.
>
> I've built a 'win64 r1324-test1 build with keepalive enabled on the
> slimprotocol socket'
> (https://www.dropbox.com/s/tfqsic51owbwty5/squeezelite-1.9.8-1324-test1-win64.zip?dl=1)
> to try.
Unfortunately no change, dro
fpo wrote:
> The doc for WSAECONNABORTED 10053:
>
Software caused connection abort. An established connection was
> aborted by the software in your host computer, possibly due to a data
> transmission time-out or protocol error.
>
> mentions *protocol error* as a possible cause for the abort.
gordonb3 wrote:
> Except that 10053 points to either the client or some network component
> closing the socket. If LMS closed the connection you would have seen a
> 10054.
> ...
The doc for WSAECONNABORTED 10053:
Software caused connection abort. An established connection was
aborted by the so
gordonb3 wrote:
> Except that 10053 points to either the client or some network component
> closing the socket. If LMS closed the connection you would have seen a
> 10054.
>
> Should also note that retransmit requests are not done by the receiver
> (i.e. the peer waiting for some response) but
fpo wrote:
> SO_KEEPALIVE is optional under Windows. I can't see that squeezelite has
> SO_KEEPALIVE enabled on the socket. It seems LMS will just reset the
> socket after some default timespan, at least I see a "TCP Reset" frame
> from the host.
Except that 10053 points to either the client or
If SO_KEEPALIVE is the primary issue, then the assumed race condition
may not be a race condition at all.
Just looking at the code in slimproto.c the function slimproto_run() may
enter a loop with 100% cpu time if the socket is reset but not yet
closed and this condition is not checked. The loop
foopydog wrote:
> ...
> The Squeezelite client has a socket open, and suddenly, there is no
> socket. Consider: SqueezeLite on RaspberryPi with TinyLinux has no
> issues, but only Windows machines have the issue. While the source code
> for SqueezeLite is (almost) identical between these two OS,
fpo wrote:
> To me, what I found, points to a possibly spurious race condition, which
> may be hard to reproduce on a specific machine. E.g. I can avoid
> triggering the dropouts when using a big stream buffer like -b 16384. It
> may very well be, that error 0x2745 is a *consequence* of a race
>
fpo wrote:
> I'm also experiencing dropouts. While reproducible, the exact timing of
> the dropouts depend on circumstances like stream buffer size and mp3
> bitrate.
> When loging to a terminal with -d all=sdebug the dropouts do occur. When
> logging same to a file with -f however, the dropout
That sort of rings a bell...
You might find some interesting pointers here:
https://serverfault.com/questions/735515/tcp-timeout-for-established-connections-in-windows
gordonb3's Profile: http://forums.slimdevices.com/mem
bpa wrote:
> A few years ago - some 3rd party security software used to insert
> themselves into the Winsock stack to catch malware which used "pipes" -
> a few caused strange problem with LMS.
> To check if the security software was the problem, it had to be
> uninstalled, disabling it was *not
ralphy wrote:
> ...
> Yes, I did remove the test versions and have adding new r1323 32/64
> windows binaries.
> ...
I tested with v1.9.8.1323/64. Sometimes a title runs through till the
end, but in most cases still dropouts after 3 minutes. Symptom is again
100% cpu time on one core.
Testing w
fpo wrote:
> I'm also experiencing dropouts. While reproducible, the exact timing of
> the dropouts depend on circumstances like stream buffer size and mp3
> bitrate.
> When loging to a terminal with -d all=sdebug the dropouts do occur. When
> logging same to a file with -f however, the dropout
ralphy wrote:
> The error codes are documented 'by microsoft here.'
> (https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--9000-11999-)
>
> I'm displaying the error code in hex, I should have prefixed it with
> *0x*2745
>
> But the description is vague.
>
> WSAECONNABOR
foopydog wrote:
> Ok, so I got the test3 build, and ran some more tests.
> Looking at the patch file, I see that the changes. Now
> slimproto.send_packet() is now showing the last_error instead of
> strerror(last_error).
> The same change was made to stream.send_header().
>
> When I ran the t
gordonb3 wrote:
> you'll most likely be looking at some kind of malware blocker.
A few years ago - some 3rd party security software used to insert
themselves into the Winsock stack to catch malware which used "pipes" -
a few caused strange problem with LMS.
To check if the security software wa
Yeah, that was one of the two returns I expected to see.
The `vague description`is somewhat of a trademark for Microsoft - I
guess it helps them sell courses in understanding WTF might be going on
and in fact most people that do are very proud to be able to call
themselves MCSE when they pass. W
The error codes are documented 'by microsoft here.'
(https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--9000-11999-)
I'm displaying the error code in hex, I should have prefixed it with
*0x*2745
But the description is vague.
WSAECONNABORTED
10053 (0x2745)
An establish
ralphy wrote:
> I uploaded '1318-test3'
> (https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/squeezelite-1.9.8-1318-test3-win32.zip/download)
> which prints the error code for the slimproto socket calls as well.
> You'll find a patch file included in that zip with the change
d6jg wrote:
> There is definitely something in the one of the latest Windows update
> that causes some issues with networking where the Red Cross status on
> drive mapping occurs post boot up but doesnt restore when you try to
> access. If you restart it then works. Ive not got to the bottom of
gordonb3 wrote:
> It's a sort of OS license-/resource saving mechanism of the workstation
> that acts as a `server` to forcibly close the connection if it hasn't
> seen any activity on it for some time. When you click the deactivated
> mapping it instantly reconnects, but of course if you have s
There is definitely something in the one of the latest Windows update
that causes some issues with networking where the Red Cross status on
drive mapping occurs post boot up but doesnt restore when you try to
access. If you restart it then works. Ive not got to the bottom of it
yet.
Also Ive no
foopydog wrote:
> Also, looking at the code yesterday, I did notice that the "retry" code
> exists in 2 places: send_packet() and slimproto_run().
> It seems that the change you made was only to send_packet(), and the
> handle 2745 was found there. The other one still shows "unknown error".
>
foopydog wrote:
> >> Do note that RAID 5 is a three disk configuration, so one of your
> disks must function as a spare. Does SSM tell you which one is which,
> i.e. which one is the spare?
>
> Actually that's not correct. Raid-5 has one-disk redundancy, but there
> is no concept of a "spare".
ralphy wrote:
> Have you had a chance to 'try this'
> (https://forums.slimdevices.com/showthread.php?113554-SqueezeLite-on-Windows-pausing-interruption-dropout-of-audio-every-5-minutes&p=1002509&viewfull=1#post1002509)?
Ok so I got the new build, and tested again today. The outages happened,
as
>> Apparently the Synology shell is something of a virtualization layer
on top of the actual OS.
Yes, sort of. The user-interface for Synology DSM runs on linux. It's
not a virtualization layer as such, but just a user-interface on top of
regular linux. In the case of my Storage Manager, it does
foopydog wrote:
> No, this is the 32-bit build 1313 which ralphy put up to help
> troubleshoot this issue.
>
> >>applications report 8-byte length winsock errors that need to be
> masked 0x to resolve to a usable 10xxx decimal error code.
>
> In that case, it would be helpful to use a
Oh... That's pretty interesting. Apparently the Synology shell is
something of a virtualization layer on top of the actual OS. Shame that
the SSM tool does not display vital drive information like LCC, but with
a 20 minute sleep setting I would not expect issues with park/unpark.
Should this be t
gordonb3 wrote:
> Is SqueezeLite a 64-bit app?
No, this is the 32-bit build 1313 which ralphy put up to help
troubleshoot this issue.
>> it possible that your hard drives are set to park when they are not
in use?
Yes. here is how they are set up:
32835
Hibernation happens after 20 minutes,
Thanks for the explaination around the unknown error strings. I'll look
into that for the 64bit build. For this session, I'm building 32bit
only and squeezelite still can't resolve the error code to a string.
In an effort to determine what the unknown socket errors are, I've
uploaded an 'r131
Would have been nice if the log had displayed the winsock error code
rather than print `unknown` trying to be more verbose about it. Is
SqueezeLite a 64-bit app? I've seen applications report 8-byte length
winsock errors that need to be masked 0x to resolve to a usable
10xxx decimal error
ralphy wrote:
> Well that's more encouraging than your initial test results. 'This is
> the change'
> (https://github.com/ralph-irving/squeezelite/commit/8f76e82c5d27fddc821412f9f01f5170f930070d).
>
> I'd already pulled the r1313 test build before seeing your post.
>
> Thanks for the suggestio
ralphy wrote:
> Well that's more encouraging than your initial test results. 'This is
> the change'
> (https://github.com/ralph-irving/squeezelite/commit/8f76e82c5d27fddc821412f9f01f5170f930070d).
>
> I'd already pulled the r1313 test build before seeing your post.
>
> Thanks for the suggestio
foopydog wrote:
> Ok, i'm with you, thank you. The build 1313 definitely DID help. After a
> few hours of listening, I got fewer interruptions. It paused twice in
> the first 15 minutes, but after that, it only paused once or twice over
> a few hours.
>
> What was the change you made?
Well th
ralphy wrote:
> Thanks for trying it. I wouldn't have asked you to test if I hadn't
> made a change that I thought would address your issue.
>
> I've had a few similiar reports recently, however, I'm unable to
> reproduce it on either of the 3 flavours of windows I have available.
>
> For the
foopydog wrote:
> Per your suggestion, i've taken the 1.9.8-1313 build of the 32-bit
> SqueezeLite.
> After running smoothly for 9 minutes, the first dropout was heard. The
> sound resumed about 1 minute later.
> The behavior seems to be the same as before.
>
> I'm curious to know if there w
d6jg wrote:
> @ralphy
> Is there a W64bit version and is this likely to fix what I can only
> describe as an occasional burping noise which I think occurs when cross
> fading across different sample rates and sometimes kills the instance of
> Squeezelite?
No. r1313 is only a test build to try
ralphy wrote:
> Please try the ' 1.9.8-1313 win32'
> (https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/squeezelite-1.9.8-1313-win32.zip/download)
> build.
Per your suggestion, i've taken the 1.9.8-1313 build of the 32-bit
SqueezeLite.
After running smoothly for 9 minutes,
ralphy wrote:
> Please try the ' 1.9.8-1313 win32'
> (https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/squeezelite-1.9.8-1313-win32.zip/download)
> build.
@ralphy
Is there a W64bit version and is this likely to fix what I can only
describe as an occasional burping noise wh
Please try the ' 1.9.8-1313 win32'
(https://sourceforge.net/projects/lmsclients/files/squeezelite/windows/squeezelite-1.9.8-1313-win32.zip/download)
build.
Ralphy
*1*-Touch, *5*-Classics, *3*-Booms, *1*-UE Radio
'Squeezebox client builds'
(https://sourceforge.net/projects/lmsclients/files/) '
I really need help to solve my problem. Hopefully someone out there can
provide some insight.
I've been running Squeezebox for years, and my server is a Synology
DS918+ running DSM 6.x.
I was running LMS 7.9.1 and recently upgraded to 8.0.1. My issue exists
on either version of LMS.
I have us
52 matches
Mail list logo
