philippe_44 wrote:
> Just checked at least for RP: the protocol handler of RP (the part of
> the plugin that tells LMS how to stream data for a given source and
> collect metadata) tells LMS that interactive streams cannot be paused,
> so LMS stops them. I vaguely remember a simialr thing for
Just checked at least for RP: the protocol handler of RP (the part of
the plugin that tells LMS how to stream data for a given source and
collect metadata) tells LMS that interactive streams cannot be paused,
so LMS stops them. I vaguely remember a simialr thing for Qobuz where
(for no good
SamY wrote:
> Thanks! Working well now for my needs except for the following minor
> glitch:
>
> * "Pause" stops playback completely for streaming FLAC sources such as
> Radio Paradise and Qobuz, meaning they can't be resumed. It works fine
> for other streaming formats, including OGF
SamY wrote:
> Thanks! Working well now for my needs except for the following minor
> glitch:
>
> * "Pause" stops playback completely for streaming FLAC sources such as
> Radio Paradise and Qobuz, meaning they can't be resumed. It works fine
> for other streaming formats, including OGF
philippe_44 wrote:
> I'm made some updates in 2.1.12.11 to try to accomodate all permutations
> and combinations and it works of my CCV. Re forward/backward that will
> not work as CC don't have (in their default receiver app) away to send
> remote commands. The pause/play/mute is state
SamY wrote:
> Testing now with 2.1.12.10 and muting/unmuting is now working perfectly
> as far as I can tell. Thanks!
>
> As mentioned previously, I had also been experimenting with the
> "pause/resume" Google Assistant commands and was getting mixed results.
> With this version, I am now
philippe_44 wrote:
> Congratulations, you managed to find a good old LMS bug that I have that
> ability to fall onto (I'm not saying to solve...) like a good truffle
> pig. When un-muting, LMS does a slow volume ramp-up. Except that when
> interrupted by user, the requested volume should be set
SamY wrote:
> This problem is not limited to CC audio. It is easily reproducible on
> any CC via Google Assistant. In case you can't recreate it, what logging
> options would be useful? I don't see the LMS commands anywhere in the
> log. Are the mute/unmute requests handled with "mixer muting
I remember that discussion now but I think this one is a bit different.
Im thick but I did not find a mute command in Google home ui
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW,
2xChromecast
philippe_44 wrote:
> Can you send a log of whats happening there? As said my ability to test
> with an audio CC is limited currently (just a video CC mainly). But in
> any case, that command, as said above due to the way LMS handles mute,
> will have some limitations
This problem is not
SamY wrote:
> Now that the dust has settled, I'd like to report a simple and easily
> recreatable problem in the new "mute/unmute" Google Assistant voice
> support.
>
> The "mute" voice command now correctly syncs with LMS, the client app
> correctly showing the current volume as unchanged but
Now that the dust has settled, I'd like to report a simple and easily
recreatable problem in the new "mute/unmute" Google Assistant voice
support.
The "mute" voice command now correctly syncs with LMS, the client app
correctly showing the current volume as unchanged but in the muted
state. I'm
SamY wrote:
> Very nice! Looks like a fix/workaround is imminent. Are you planning to
> open a Windows bug report (or whatever MS calls them these days)? BTW, I
> see that v2.1.12.5 has been released. Any changes related to this issue?
No, 2.1.12.5 is about mute. Re Windows I dont think this
philippe_44 wrote:
> Here is my pick on the topic and @ralphy's test seems to confirm that
> https://forums.slimdevices.com/showthread.php?114661-Music-streaming-stops-intermittently=1069220=1#post1069220
Very nice! Looks like a fix/workaround is imminent. Are you planning to
open a Windows
SamY wrote:
> I agree with you on the OP's analysis and clear explanation of the
> problem. Having that level of understanding will contibute greatly
> towards achieving a real solution.
>
> My testing with version 2.1.12.3 is looking very good. Google Home
> volume commands to my Nest Mini
SamY wrote:
> I don't have any groups currently set up but will try to do some
> testing. I would imagine that, if there are issues of that nature, you
> will be hearing about them here soon enough. I did run into a problem of
> sorts when, flush with my success at changing the LMS volume with
SamY wrote:
> I don't have any groups currently set up but will try to do some
> testing. I would imagine that, if there are issues of that nature, you
> will be hearing about them here soon enough. I did run into a problem of
> sorts when, flush with my success at changing the LMS volume with
philippe_44 wrote:
> The other scenario is really verifying that in a non-group configuration
> there is no regression and especially when you have a group and you
> decide to play (from LMS) on one speaker, what happens in term of volume
> for that speaker and for the group if you use it later
SamY wrote:
> I agree with you on the OP's analysis and clear explanation of the
> problem. Having that level of understanding will contibute greatly
> towards achieving a real solution.
>
> My testing with version 2.1.12.3 is looking very good. Google Home
> volume commands to my Nest Mini
philippe_44 wrote:
> The OP did an perfect job analyzing the issue, I wish I've seen it
> before. That confirmation + some reading lead me to try something more,
> but I don't think I'll move back to the "throttle" mode yet. I've
> suggested @ralphy to try something similar for the squeezelite
philippe_44 wrote:
> The OP did an perfect job analyzing the issue, I wish I've seen it
> before. That confirmation + some reading lead me to try something more,
> but I don't think I'll move back to the "throttle" mode yet. I've
> suggested @ralphy to try something similar for the squeezelite
SamY wrote:
> Wow! That thread is an eye-opener. It does appear to be the same ongoing
> buffering issue with the Windows TCPIP client protocol and even possibly
> the same "Moby Dick" problem I mentioned previously that only occurred
> when running my product's client component on a Windows
philippe_44 wrote:
> BTW, just to show that this is not just "us"
> https://forums.slimdevices.com/showthread.php?114661-Music-streaming-stops-intermittently
Wow! That thread is an eye-opener. It does appear to be the same ongoing
buffering issue with the Windows TCPIP client protocol and even
SamY wrote:
> You're preaching to the choir, as they say. I deal with the same issue
> in the Denon/Marantz AVR Control plugin, syncing the volume between
> LMS's linear 0-100% scale and the AVR's logarithmic dB scale of 0-MAX,
> where the value of MAX can be customized in the AVR's setup menu
philippe_44 wrote:
>
> NB: one of the most painful issue in these volume alignement is that LMS
> has a its own strange volume levels (0
128 or a more linear mode that
> does not really help) and its not always easy, as silly as it sounds,
> to have a stable point when CC changes to N on
SamY wrote:
> If the answer to that question is "no", a compromise workaround might be
> to at least bypass re-syncing the CC volume with LMS at each track
> change for those players. Then the volume could continue to be
> controlled by the CC player until the next time it was changed by the
>
SamY wrote:
>
> So, assuming that there is a valid reason to ignore group volume
> changes, the question would seem to be "Is it possible to distinguish a
> stereo pair from a player group and only ignore group volume changes?".
If the answer to that question is "no", a compromise workaround
SamY wrote:
> ...when I change the volume using Google Home, these lines seem to be
> generated in the log:
>
> >
Code:
> > [20:36:13.831] CastSocketThread:590 [006D9698]: type:RECEIVER_STATUS
(id:84)
> [20:36:14.320] CastSocketThread:590 [006D9698]:
philippe_44 wrote:
> I can probably find a home and a mini and see. Now, if you re-pair them,
> when you try to change the volume, can you put the castloglevel on? This
> will be verbose but will tell me if the message of volume change is
> missed or if it is not processed properly.
I have not
SamY wrote:
> Okay. I reinstalled v1.82.2 and the problem also occurs there (along
> with the return of the track skip-ahead TIME_WAIT problem). I think the
> reason I didn't notice the volume change problem previously is that I
> generally would only listen to streaming sources on that Nest
SamY wrote:
> I'm planning to do that later today. I've been using them as a stereo
> pair with LMS for quite a while though and don't recall having a problem
> like this. I'm also going to try going back to the pre-dev version as
> another test.
Okay. I reinstalled v1.82.2 and the problem
Paul Webster wrote:
> Mine is not a stereo pair.
> Maybe you can temporarily break the pairing to see if it starts to work
> properly.
I'm planning to do that later today. I've been using them as a stereo
pair with LMS for quite a while though and don't recall having a problem
like this. I'm
Mine is not a stereo pair.
Maybe you can temporarily break the pairing to see if it starts to work
properly.
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer - kiss, absolute, scala, jazzfm etc), kcrw, abc
australia and cbc/radio-canada
and,
Paul Webster wrote:
> Works here and mine at same version - incidentally this is a recent
> version and, in theory at least, adds support for Matter.
I have two Minis set up as a stereo pair, which appears to LMS as one
player. I wonder if that somehow makes a difference. Do either of you
have
SamY wrote:
> Mine is (are) at version 1.56.324896.
>
Works here and mine at same version - incidentally this is a recent
version and, in theory at least, adds support for Matter.
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer - kiss,
What if the U.S. Constitution was created and maintained on the
Slimdevices forum. H
"Oh! Sorry to startle you. Didn't you see my second edit (I like to call
them amendments) regarding the right to carry these things around in
public in case they are needed to fend off rebellions and
SamY wrote:
> No change in LMS ui volume display, as there is with other CC devices.
> Using the same vol management settings for all so "no" on disabled.
> Yours works, huh? Maybe a different firmware version? Mine is (are) at
> version 1.56.324896.
>
> EDIT: Edits should be disabled until
philippe_44 wrote:
> Does it work with versions 1.8x? Im asking to be 100% sure because I
> dont recall having made modifications there.
>
> [edit]: I just tried on a mini and it still works as before. You dont
> see a change in LMS ui? Any chance the volume feedback has been disabled
> just
SamY wrote:
> I don't recall it ever happening until the dev version but I'd have to
> reinstall the old one to check for sure.
Have you seen the edit Ive made to my message?
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
philippe_44 wrote:
> Does it work with versions 1.8x? Im asking to be 100% sure because I
> dont recall having made modifications there.
I don't recall it ever happening until the dev version but I'd have to
reinstall the old one to check for sure.
Sam
SamY wrote:
> The 2.1.12.2 plugin is now working reliably for me in passthrough mode
> on Windows with every codec and bitrate I have tried. The only problem I
> have now is that the "Feedback to LMS" function of "Player volume
> management" does not function correctly with my Google Nest Minis
philippe_44 wrote:
> The 2.1.12.2 is fixing that issue, not in a way I prefer, but that seems
> to be the only option. You don't see the problem happening on higher
> bitrate because that very special sequence only happens is the N+1 track
> is small enough to fit in the buffers but compressed
SamY wrote:
> So are you able to make sense of why the "TIME_WAIT issue" happens only
> when both sides of the connection are running Windows?
>
> (Let it go, Sam. Let it go...)
It still happen when the 2 parts are Windows but separated computers,
just very occasionally, compared to « all the
philippe_44 wrote:
> The 2.1.12.2 is fixing that issue, not in a way I prefer, but that seems
> to be the only option. You don't see the problem happening on higher
> bitrate because that very special sequence only happens is the N+1 track
> is small enough to fit in the buffers but compressed
SamY wrote:
> Thanks, but I'm beginning to lose interest as I hardly ever play my old
> mp3 rips anyway. I did run some tests last night and found that the
> error is much less likely to occur with higher bitrate CBR tracks and
> nearly always happens with VBR content. The thing I find most
>
philippe_44 wrote:
> If you add logs like « -d all=info -d stream=debug » you will see the
> streaming buffer filling up and throttling down. That helps a lot
> identifying the timing a sizing of the exchanges
Thanks, but I'm beginning to lose interest as I hardly ever play my old
mp3 rips
If you add logs like « -d all=info -d stream=debug » you will the
streaming buffer filling up and throttling down. That helps a lot
identifying the timing a sizing of the exchanges
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz
SamY wrote:
> Hey, Philippe. Just out of curiosity, what would you expect to happen
> when I reverse my most recent test scenario and run LMS on a Linux box
> with the plugin binary running on Windows, which I'm getting ready to do
> now?
And the answer is (drum roll) ... exactly what
Hey, Philippe. Just out of curiosity, what would you expect to happen
when I reverse my most recent test scenario and run LMS on a Linux box
with the plugin binary running on Windows, which I'm getting ready to do
now?
Sam
'This'
(https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting)
looks like a good reference to use when analyzing a network trace of a
Windows TCP/IP client connectivity problem.
Sam
philippe_44 wrote:
> :)
>
> A test with a Linux box would be very welcome. Have you tried a larger
> tcptimedwaitdelay? There might some min set by the stack anyway and it
> is also supposed to be at least 2 times the maximum segment lifetime
> (msl). So its difficult (and especially with
urknall wrote:
> It's not a problem with the plugin, this is network protocol related.
>
> As far as i know, the discovery service is based on mdns, like many
> other services: airplay, airprint etc.
> The idea is to identify the members of a network, without having a fully
> configured dns
SamY wrote:
> Looks like you're closing in on it. As a reminder, if it is relevant, I
> ran a test earlier after adding a TcpTimedWaitDelay registry entry with
> a value of 30 seconds, overriding its default value of 2 minutes and,
> after rebooting, the errors still occurred after the same
philippe_44 wrote:
> Well, in fact I misread the wireshark and the FIN request from the LMS
> is ACKnowledged by the bridge's stack but what was missing is the FIN
> from the bridge. It should be sent when closing the connection in
> return, but I don't because do it in time I don't see it fast
SamY wrote:
> If this is the same bug that virtually killed the cross-platform
> enterprise client/server product I worked on years ago (and it's looking
> more and more like it is), it's been around since at least Windows NT
> and will probably outlive me unless you come up with a solution,
>
philippe_44 wrote:
> Unfortunately I'm away from my Win11 machine for a while. I can try
> remotely but it's a bit more difficult
If this is the same bug that virtually killed the cross-platform
enterprise client/server product I worked on years ago (and it's looking
more and more like it is),
Paul Webster wrote:
> Are you repeating it on Win11 environment?
Unfortunately I'm away from my Win11 machine for a while. I can try
remotely but it's a bit more difficult
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
Are you repeating it on Win11 environment?
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer - kiss, absolute, scala, jazzfm etc), kcrw, abc
australia and cbc/radio-canada
and, via the extra \"radio now playing\" plugin lots more - see
And for me it looks like a nasty windows bug because the FIN,ACK should
be sent by the TCP stack automatically, I dont think there is a need to
the peer to call shutdown() for the FIN,ACK to be sent
Envoyé de mon iPad en utilisant Tapatalk
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio,
Paul Webster wrote:
> Feels promising though ...
>
> Why is the application layer blocked and can it be unblocked (even with
> some sort of timer kludge just as a workaround initially)?
Its purposely blocked (in fact throttled down) otherwise I have a
different issue where some servers close
Feels promising though ...
Why is the application layer blocked and can it be unblocked (even with
some sort of timer kludge just as a workaround initially)?
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer - kiss, absolute, scala, jazzfm
Problem understood (sort of) but not solved. @Paul, you were right, it
is related to TIME_WAIT but in a bizarre wait. Consider the following
TCP dumps
Code:
success
3684 381.383533 192.168.6.15192.168.6.194 TCP 54 [TCP
Retransmission] 9000
SamY wrote:
> So I guess that returns LMS to the list of possible suspects, right?
Not sure or not in a direct way. I think Im close to understanding the
issue: the last segment of the file is transmitted while the client is
busy and not processing data (or much data) from the kernel layers.
philippe_44 wrote:
> Unfortunately, I've edited my comment, it happens as well on separated
> hosts but wiresharks logs confirm it's 2 minutes, at almost the
> millisecond
So I guess that returns LMS to the list of possible suspects, right?
Sam
Some additional information: I will double check tomorrow but it seems
that all data is actually being sent (at least seen by wireshark on the
sending end). What seems to happen is that either the FIN is not sent by
the server or a packet is not acknowledged by the client but after that
last
SamY wrote:
> Great minds etc, etc... :D
> I tried that earlier today while searching for tcpip-related settings
> that default to 2 minutes. Tried changing it to 30 secs as some tuning
> sites recommend but it made no difference. The 2-minute error intervals
> remain, so it appears to be
philippe_44 wrote:
> Some semi-happy sniffing indeed... So it's clearly an abrupt shut-off
> from Windows side (RST, ACK - not a proper FIN, ACK) but I still have no
> idea why. I've tried the following and it would be interesting if you
> could confirm: the squeezecast app can run on
Paul Webster wrote:
> Apologies in advance if this has already been considered ...
> If the break is at 120 seconds (plus a tiny bit) then maybe the Windows
> TcpTimedWaitDelay is kicking in because of something that it thinks did
> not get acknowledged 2 minutes earlier.
>
> There is a
Apologies in advance if this has already been considered ...
If the break is at 120 seconds (plus a tiny bit) then maybe the Windows
TcpTimedWaitDelay is kicking in because of something that it thinks did
not get acknowledged 2 minutes earlier.
There is a registry key available to adjust from
SamY wrote:
> It's all good news to me. I don't have to mess with packet sniffers.
>
> Same here. So what's the significance of the 2 minutes? Are you running
> Win10 Home or Pro? I was thinking that might make a difference. Running
> Home here. Would the LMS Network streaming mode come into
philippe_44 wrote:
> Good and bad news. I've been able to reproduce that on my Win10 system.
> I've set the right log to show you the pattern, it's easier with the
> stream set to debug
It's all good news to me. I don't have to mess with packet sniffers.
>
> On my machine, it's a systematic
SamY wrote:
> Here is the log file with 2.1.12.1. Not using "underrun". I decided to
> let the whole album play this time. As you will see, the read errors all
> occur within a few seconds of 2 minutes (not 3) after the beginning of a
> new track and are completely and predictably repeatable,
SamY wrote:
> Okay. I'll wait for your test results. Are you running Windows 10 or 11
> on your test machine? I'm still on 10 but plan on upgrading soon.
Its Win11
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
philippe_44 wrote:
> If you could capture the whole exchange and put the pcap on the same
> Dropbox, that would tell me precisely what happens at the network level
> and if keep alive packets are sent and if there is a throttle down flow
> and so on. Super valuable. I hope Ill be able to
SamY wrote:
> I'll get comfortable. I know what it is and may have used it many years
> ago. I don't think you'll have any problem reproducing it though.
If you could capture the whole exchange and put the pcap on the same
Dropbox, that would tell me precisely what happens at the network level
philippe_44 wrote:
> Thats quite a challenge and a motivation! Are you comfortable with
> wireshark if I cant reproduce the issue?
I'll get comfortable. I know what it is and may have used it many years
ago. I don't think you'll have any problem reproducing it though.
Sam
philippe_44 wrote:
> If this works for you
> https://www.dropbox.com/sh/ovk1k4ois2f1o3z/AAB32RvjelvSHZ7-8AqE3vBFa?dl=0
My Dropbox account was expired and I had to create a new one. Tried to
pm you here but your mailbox is full (didn't know that was a thing).
Here it is:
Thats quite a challenge and a motivation! Are you comfortable with wire
shark invade I cant reproduce the issue?
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW,
2xChromecast Audio, Chromecast v1 and
philippe_44 wrote:
> This log has the error code as I added it and its 10054, sort of as
> expected. You can see explanation here and there is more to read on
> 10054. Its really frustrating that the keep-alive changes Ive made in
> 2.1.12..1 still does not solve it
>
>
SamY wrote:
> Sure. Do you have a preferred sharing method? It's an 82MB zip file.
If this works for you
https://www.dropbox.com/sh/ovk1k4ois2f1o3z/AAB32RvjelvSHZ7-8AqE3vBFa?dl=0
LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch,
1xSB3. Sonos PLAY:3, PLAY:5, Marantz
philippe_44 wrote:
>
> Ill setup a dedicated Win10 machine, can you share your tracks?
Sure. Do you have a preferred sharing method? It's an 82MB zip file.
Sam
SamY's Profile:
This log has the error code as I added it and its 10054, sort of as
expected. You can see explanation here and there is more to read on
10054. Its really frustrating that the keep-alive changes Ive made in
2.1.12..1 still does not solve it
SamY wrote:
> Here is the log file with 2.1.12.1. Not using "underrun". I decided to
> let the whole album play this time. As you will see, the read errors all
> occur within a few seconds of 2 minutes (not 3) after the beginning of a
> new track and are completely and predictably repeatable,
jw111 wrote:
> Hi Philippe,
>
> I had not used LMS for a while. My LMS server interface was not showing
> any of my Chromecast Audios or Squeezeboxes. I found that my remaining
> two Squeezeboxes were not powering on. I had another Squeezebox that I
> was not using so I got it working. It
philippe_44 wrote:
> No, not for a first test. Your use case should not need « underrun ». It
> might work with, but its a workaround. What Im trying to understand is
> why does windows close the connection after 3 mins of no activity. Ive
> added a throttle down of streaming when reaching a
philippe_44 wrote:
> Try using the underrun option of gapless. This seems to be a windows
> specific issue were sockets are closed by something when they
> dont display activity after 3 mins
Yes, with that option specified I'm not seeing the issue. In fact, I'm
not seeing any issues with
Paul Webster wrote:
> I donÂt think it matters if other devices are present.
>
> Which version of Chromecast Bridge are you running?
>
> Are there any clues in the logs that you can access from the plugin
> settings page?
1.82.2
The logs when I was not seeing Chromecasts or Squeezeboxes said
I dont think it matters if other devices are present.
Which version of Chromecast Bridge are you running?
Are there any clues in the logs that you can access from the plugin
settings page?
Paul Webster
author of \"now playing\" plugins covering radio france (fip etc),
planetradio (bauer -
Hi Philippe,
I had not used LMS for a while. My LMS server interface was not showing
any of my Chromecast Audios or Squeezeboxes. I found that my remaining
two Squeezeboxes were not powering on. I had another Squeezebox that I
was not using so I got it working. It showed up on the LMS menu, but
SamY wrote:
> Sounds good. Do I still need to specify the "underrun" streaming option?
No, not for a first test. Your use case should not need « underrun ». It
might work with, but its a workaround. What Im trying to understand is
why does windows close the connection after 3 mins of no
philippe_44 wrote:
> Now that I've returned to dev repository, you can get 2.12.1.1 directly
> from there, it contains a different option to try to keep the socket
> open and a log for me to see the raw error
Sounds good. Do I still need to specify the "underrun" streaming option?
Sam
SamY wrote:
> I also checked it with VirusTotal last night and agree that it's most
> likely a false positive. However given the "severe" nature of this
> particular malware, I am proceeding with caution.
Now that I've returned to dev repository, you can 2.12.1.1 directly from
there, it
Paul Webster wrote:
> VirusTotal not showing any issues with it.
> https://www.virustotal.com/gui/file/cc1644cbf191af0109c5d5465aae32e3ec8c919edca72f19dc74a0a9274a2a4a
> Note - not all scanners run against it but my suspicion is a false
> positive.
I also checked it with VirusTotal last night
humax99 wrote:
> I have revisited the None (No Transcoding) option with 2.1.11 and it
> appears more stable but not fault less. The breaks appear shorter and
> less frequent but they still occur.
>
> Now moved on to 2.1.12 announced on LMS this evening (UK time) for
> further testing!
>
>
philippe_44 wrote:
> Maybe an issue with DietPi os version. I have an Orange Pi0 with Armbian
> and I just tried to run the app and it works.
Thanks, I'll try armbian instead of dietpi. yesterday I have installed
lms on windows machine, everything works there!
VirusTotal not showing any issues with it.
https://www.virustotal.com/gui/file/cc1644cbf191af0109c5d5465aae32e3ec8c919edca72f19dc74a0a9274a2a4a
Note - not all scanners run against it but my suspicion is a false
positive.
Paul Webster
author of \"now playing\" plugins covering radio france
SamY wrote:
> Hmmm Well this is not good. I tried to download the zipped
> executable and received an error message that a "severe" virus was
> detected and the download was blocked. Not sure how to proceed from
> here. I was going to try downloading the squeeze2upnp.zip file that you
>
philippe_44 wrote:
> Yep... sorry for the confusion. Here you go
Hmmm Well this is not good. I tried to download the zipped
executable and received an error message that a "severe" virus was
detected and the download was blocked. Not sure how to proceed from
here. I was going to try
SamY wrote:
> Just saw this after my last post. I will be glad to test it. However,
> the name of the zip file leads me to believe it is not the squeeze2cast
> executable. I can't unzip it on my phone but can you verify that it's
> the correct file?
>
> EDIT: Just verified that it's the
SamY wrote:
> Philippe, I think you need to take a couple of days off. You obviously
> have me confused with another user --- not surprising given the recent
> tsunami of activity. I didn't send you any files and my problem is with
> squeeze2cast, not squeeze2upnp. Maybe you should take a break
1 - 100 of 2237 matches
Mail list logo
