mherger wrote:
> >> Awesome. Thanks, bpa and philippe_44 for helping to analyze and fix
> >> this. Can you check in this change to the repository of LMS 8?
>
> Thanks guys! I committed this change to LMS8. It'll be out there in a
> bit. Please let me know if I got it the wrong way :-)
>
> --
Awesome. Thanks, bpa and philippe_44 for helping to analyze and fix
this. Can you check in this change to the repository of LMS 8?
Thanks guys! I committed this change to LMS8. It'll be out there in a
bit. Please let me know if I got it the wrong way :-)
--
Michael
schup011 wrote:
> Now it works!!! I cannot produce any dead connections any more. They are
> all closed after the timeout. The log shows that.
>
> Awesome. Thanks, bpa and philippe_44 for helping to analyze and fix
> this. Can you check in this change to the repository of LMS 8?
That's great.
Here is the log file. I had the timeout first set to 8 seconds.
[20-08-21 08:55:34.2418]
First, I reproduced the case of getting no body data from the server.
[20-08-21 09:04:55.9254]
Then, I tried "normal" internet radio stations
[20-08-21 09:23:16.0842]
Then, I gave my own server "normal"
I got it running. There was a $self-> in the setTimer line missing. I
inserted a log command to check:
Code:
# After reading headers, some callers may want to continue and
# read the body
sub read_body {
my $self = shift;
my $args = shift;
I got the info how to change HTTP.pm.
Unfortunately, LMS does not start with the change. I double checked
several times. Can you check again?
schup011's Profile: http://forums.slimdevices.com/member.php?userid=66557
View
I have found the file but in fact I could not figure out how to write on
it. Posted forum question.
I am back from my vacation, but fortunately, I found I way how to
reproduce this also at home. I have a similar setup here. In fact, by
insanely trying different satellite radio channels and
schup011 wrote:
> I think I know how to mount that partition. Nothing needs to be
> compiled? (Sorry, I am not familiar at all with the LMS tool chain).
No, no compilation for that part
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3,
philippe_44 wrote:
> You should but I dont remember how to access the non RO partition. Ask
> a question on the picore thread
I think I know how to mount that partition. Nothing needs to be
compiled? (Sorry, I am not familiar at all with the LMS tool chain).
schup011 wrote:
> Can I do it on a piCorePlayer system?
You should but I dont remember how to access the non RO partition. Ask
a question on the picore thread
LMS 7.9 on Pi 3B+ & Odroid-C2 - *SqueezeAMP!*, 5xRadio, 3xBoom, 4xDuet,
1xTouch, 1 SB3. Sonos PLAY:3, PLAY:5, Marantz NR1603,
philippe_44 wrote:
> That's interesting... If you know how to do that, can you edit file
> /usr/share/perl5/Slim/Networking/Async/HTTP.pm, go to function
> "read_body" and replace with
>
> >
Code:
> >
> # After reading headers, some callers may want to continue and
schup011 wrote:
> Actually I added Reliable plugin only yesterday to see whether this
> could help - it did not do anything to my specific problem.
>
> Anyway, I did it again with Reliabe Plugin deactivated. This time, it
> took a little more channel switches to reproduce the situation where
philippe_44 wrote:
> For mp3 or any stream? Because for mp3, they do by design
I seem to have only MP3 with my local server.
schup011's Profile: http://forums.slimdevices.com/member.php?userid=66557
View this thread:
schup011 wrote:
> In my logs, it seems that the "scanning" http connection and the real
> "playing" (in a working case where the server provides a valid audio
> stream) overlap for a couple of seconds.
For mp3 or any stream? Because for mp3, they do by design
LMS 7.9 on Pi 3B+ & Odroid-C2
philippe_44 wrote:
> Ive updated that section of LMS heavily recently. I will read this
> thread but LMS does close any connection used for scanning. For most
> formats, scanning has to be done before streaming starts. Only mostly in
> mp3 is there streaming in parallel with scanning (and in
I will try a summary: I can reproduce a case where LMS does not close
this first "scanning" Http connection. This occurs in case the server
accepts the connection, but does not provide an audio stream. Player
state remains buffering, and LMS does not close its connection. No
matter what I do
I will try a summary: I can reproduce a case where LMS does not close
this first "scanning" Http connection. This occurs in case the server
accepts the connection, but does not provide an audio stream. Player
state remains buffering, and LMS does not close its connection. No
matter what I do
schup011 wrote:
> Maybe I am thinking too simply, but to me it's quite clear now:
>
> We have to check the section where LMS reads a first portion of the
> stream in order to get info about bitrate, codec and so on. The
> conditions to close that http connection by calling
>
Maybe I am thinking too simply, but to me it's quite clear now:
We have to check the section where LMS reads a first portion of the
stream in order to get info about bitrate, codec and so on. The
conditions to close that http connection by calling
Slim::Networking::Async::disconnect have to be
OK, now with netstat -p:
Normal working case:
Code:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program name
tcp1 0 collePlayer:43002 collePlayer:9000
bpa wrote:
> This is why Wireshark logs are good - it records the whole conversation
> but it can be a lot of work to analyse unless you can make the network
> very quiet. So it is last resort.
>
> Can you use the "-p" option on your netstat ? this will show program
> and PID
>
>
>
> My
schup011 wrote:
> Please note that calling netstat takes a couple of seconds, therefore I
> could not get "intermediate" states, like a connection being established
> and closed shortly after.
This is why Wireshark logs are good - it records the whole conversation
but it can be a lot of work
> Is VDR using HTTP 1.1 "actively" and are TCP connection being kept open
> between HTTP requests from same source ?
I am not able to answer that.
schup011's Profile: http://forums.slimdevices.com/member.php?userid=66557
bpa wrote:
> Please show netstat log and do not "assume" anything. When chasing bugs
> you have to be pedantic. Confirm the TCP connection against the
> originating process id and the executable of the process id.
>
> Is VDR using HTTP 1.1 "actively" and are TCP connection being kept open
>
schup011 wrote:
> I confirmed that behaviour with netstat. Usually, when I hear the audio,
> there is one connection established. During the above described "First
> point of failure", I see two connections established (I assume one from
> LMS, one from Squeezelite). During the second mode, I
I have a general problem. This system here is at a holiday apartment. I
am leaving tomorrow and will return only in winter. Therefore, I can do
any tests until tonight, but not after that. Sorry.
But I appreciate very much your help, thanks a lot!
bpa wrote:
> OK - I have a lot on now so won't be able to look at this again until
> weekend. Netstat and Wireshark are still relevant and would provide
> useful info.
>
> Can you clarify another point - in first post you say- 'In this case,
> the piCorePlayer display gets stuck at
schup011 wrote:
> No! Sorry! You are looking at the wrong point of the log.
>
> The error occurs before. The connection HTTP=GLOB(0x6021268) is never
> closed by LMS!!! And playing state there is
>
> The one after that (0x5ffd1f0), where the VDR server declines the
> connection with the 503
bpa wrote:
> No it looks like connection was closed an stream put into IDLE state.
>
> To check actual state of network connections and not just the last
> message shown on Jivelite, use netstat
>
> Alternatively, if you want to check whether TCP connection is closed or
> left hanging in
bpa wrote:
> No it looks like connection was closed an stream put into IDLE state.
>
> >
Code:
> >
> [20-08-18 21:27:38.6939] Slim::Networking::Async::disconnect (251) Close
Slim::Networking::Async::Socket::HTTP=GLOB(0x5ffd1f0) => 29
> [20-08-18 21:27:38.6991]
schup011 wrote:
> Yes, sure, the 503 response is the effect that the streaming server
> denies a new connection, and that one (in log: HTTP=GLOB(0x5ffd1f0)) is
> closed properly by LMS. But the one before (HTTP=GLOB(0x6021268)), and
> that is the root cause in my opinion, is not closed. And
bpa wrote:
> The log shows that LMS closed the TCP connection. The 503 connection
> comes from VDR server and is the reply to the GET.
> >
Code:
> >
> [20-08-18 21:27:38.3582] Slim::Player::Song::getNextSong (252) scanning URL
http://192.168.0.100:3000/ES/1052
>
bpa wrote:
> The log shows that LMS closed the TCP connection. The 503 connection
> comes from VDR server and is the reply to the GET.
> >
Code:
> >
> [20-08-18 21:27:38.3582] Slim::Player::Song::getNextSong (252) scanning URL
http://192.168.0.100:3000/ES/1052
>
schup011 wrote:
> You misunderstood my writings. I am not interpreting the log, but have
> added - more or less precisely - my perception, i.e. the point of time
> when I heared the player playing the radio station (if it did).
The log shows that LMS closed the TCP connection. The 503
bpa wrote:
>
>
> Can you check the end point of connection from the VDR server and
> determine the status of the initial LMS connection and status of the 2nd
> connection from Squeezelite.
I am not sure whether I am able to I have an integrated piCorePlayer
setup with player and LMS on
bpa wrote:
> Your interpretation of LMS log about getting audio is not quite right.
> With direct streaming Audio is read directly by the squeezelite by a
> separate HTTP GET which is not logged by LMS. The small fragment of
> audio retrieved by LMS after header is only used to parse the
>
Your interpretation of LMS log about getting audio is not quite right.
With direct streaming Audio is read directly by the squeezelite by a
separate HTTP GET which is not logged by LMS. The small fragment of
audio retrieved by LMS after header is only used to parse the
audiostream for sample
bpa wrote:
> I'll check log again but Reliable plugin means connection is always
> proxied and never direct.
For the latest server log, I have deactivated the Reliable Plugin.
Streaming method setting was and is direct.
bpa wrote:
> I'll check log again but Reliable plugin means connection is always
> proxied and never direct.
For the latest server log. I had deactivated the Reliable Plugin.
Streaming method setting was and is direct.
schup011 wrote:
> Actually I added Reliable plugin only yesterday to see whether this
> could help - it did not do anything to my specific problem.
>
> Anyway, I did it again with Reliabe Plugin deactivated. This time, it
> took a little more channel switches to reproduce the situation where
bpa wrote:
> I noticed you are using a "Reliable" plugin.
>
> Please test with this removed - This plugin does "special" things with
> TCP connection to ensure when they drop they are reconnected
> automagically.
> >
Code:
> >
> [70-01-01 20:14:40.9156]
I noticed you are using a "Reliable" plugin.
Please test with this removed - This plugin does "special" things with
TCP connection to ensure when they drop they are reconnected
automagically.
Code:
[70-01-01 20:14:40.9156] Slim::Player::Song::open (468) Opening
bpa wrote:
> There are some other ideas to try - mainly concentrating on direct
> connection and understanding what squeezelite is doing. If a mod is
> needed it is easier to modify squeezelite.
>
> Just to be sure what is happening - can you get a log with player.source
> set to INFO when
There are some other ideas to try - mainly concentrating on direct
connection and understanding what squeezelite is doing. If a mod is
needed it is easier to modify squeezelite.
Just to be sure what is happening - can you get a log with player.source
set to INFO when playing a VDR radio
bpa wrote:
> Thinking a bit more.
>
> If HTTP connection is established LMS will wait for audio. With internet
> radio station it is the radio station that breaks a connection with LMS.
> LMS is content to wait to fill buffer before initiating playing, if far
> end (i.e. VDR) is acking all TCP
bpa wrote:
> Thinking a bit more.
>
> If HTTP connection is established LMS will wait for audio. With internet
> radio station it is the radio station that breaks a connection with LMS.
> LMS is content to wait to fill buffer before initiating playing, if far
> end (i.e. VDR) is acking all TCP
bpa wrote:
> I don't know enough about VDR and if I understand the issue correctly,
> with LMS when a new stream is being started while another is playing
> (i.e. stream has not been stopped) I think there will be overlap with
> one HTTP connection open and a second connection being opened.
Thinking a bit more.
If HTTP connection is established LMS will wait for audio. With internet
radio station it is the radio station that breaks a connection with LMS.
LMS is content to wait to fill buffer before initiating playing, if far
end (i.e. VDR) is acking all TCP request to say link is
schup011 wrote:
> In this special case where the server does not provide audio, LMS
> remains stuck at "Connection being established", and it isn't even
> possible to pause it. But latest when I request another stream, the old
> (stuck, not working) HTTP connection should be really closed by
bpa wrote:
> I don't understand this sentence ? Please clarify - has audio stopped
> and HTTP is still active ?
>
> On LMS - a stream is not "stopped" if it is just "paused" - single short
> press on "||" just pauses a stream.
In this special case where the server does not provide audio, LMS
It is a Opera DVB-S USB box connected to a Raspberry Pi Zero W, with
Raspbian Buster and VDR on it. The VDR software has a plugin called
streamdev-server, which provides the Http server and forwards the audio
stream.
VLC codec info says: MPEG Audio layer 1/2 (mpga).
It is a Opera DVB-S USB box connected to a Raspberry Pi Zero W, with
Raspbian Buster and VDR on it. The VDR software has a plugin called
streamsev-server, which provides the Http server and forwards the audio
stream.
VLC codec info says: MPEG Audio layer 1/2 (mpga).
schup011 wrote:
> BTW: It is no TCP over Satellite. It is a DVB-S satellite receiver,
> which provides a local http streaming server. I have only mobile (LTE)
> internet here on my mobile phone
What is the model/make of satellite decoder ?
Is the stream really HTTP/MP3 - many DVB-S
schup011 wrote:
> It just does not close the HTTP connection in case the server does not
> provide audio.
I don't understand this sentence ? Please clarify
bpa's Profile:
schup011 wrote:
> BTW: It is no TCP over Satellite. It is a DVB-S satellite receiver,
> which provides a local http streaming server. I have only mobile (LTE)
> internet here on my mobile phone
What format (i.e. transport & codec) is coming out of DVB-S decoder ?
I'd still try "proxied"
BTW: It is no TCP over Satellite. It is a DVB-S satellite receiver,
which provides a local http streaming server. I have only mobile (LTE)
internet here on my mobile phone
schup011's Profile:
It is MP3. I tried both proxied and direct streaming. The behaviour did
not change. It just does not close the HTTP connection in case the
server does not provide audio.
schup011's Profile:
Satellite connection because of long transit time have "unusual" TCP
parameter such as large window sizes. This may be part of the issue.
What is the format of the stream ?
If its http/AAC ir http/MP3 then it will be played "direct" by
squeezelite and so LMS has less control over it (eg. if
d6jg wrote:
> I think you will need to post LMS version no etc
Ok, sorry. I am currently on 8.0.0, 1597263993, but I had the same issue
on 7.9.x before.
piCorePlayer 5.0.1, Squeezelite 1.9.2-1158
System is running on a Pi Zero W.
schup011 wrote:
> Hi guys,
>
> I have problems with streaming radio from an own satellite radio
> streaming server (don't have wired internet here), which is a separate
> Raspberry Pi with a VDR installation on it.
>
> My squeeze setup, here acting as streaming client, is a piCorePlayer
>
Hi guys,
I have problems with streaming radio from an own satellite radio
streaming server (don't have wired internet here), which is a separate
Raspberry Pi with a VDR installation on it.
My squeeze setup, here acting as streaming client, is a piCorePlayer
with integrated LMS and Jivelite on
61 matches
Mail list logo
