Comments (43)
hpannenb
commented on June 11, 2024
1
@9000h I am not that familiar with compiling so it might need some time for me to check and integrate it in my PROD vdr. Any help appreciated since this is not my "bread-and-butter" work. :-)
Compiling worked so far. I need to perform it again for a VDR version 2.4.0. How to achieve this?
I finally made it installing a VDR 2.4.0 as basis. Once I have Octopus NET enabled I will let You know.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
1
I have no DiSEqC in use or configured.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
1
section 3.6.1
https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
1
Due to the fact the symptoms shown seem not to be related to the satip plugin itself I will close the issue right now. Thanks for all Your support.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
@rofafor I changed the SATIP>IP device to a minisatip driven. This changes the error in the logs just a little. The generic behaviour seems to be the same. So I suppose there is something in the VDR or satip plugin's code struggling with EPG scan in conjunction with SAT>IP.
Mar 7 11:08:10 vdr-server vdr: [437] SATIP: Idle timeout - releasing [device 0]
Mar 7 11:08:10 vdr-server vdr: [437] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
Mar 7 11:19:03 vdr-server vdr: [437] SATIP: Idle timeout - releasing [device 0]
Mar 7 11:19:03 vdr-server vdr: [437] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
Mar 7 11:29:54 vdr-server vdr: [437] SATIP: Idle timeout - releasing [device 0]
Mar 7 11:29:55 vdr-server vdr: [437] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
Mar 7 11:40:47 vdr-server vdr: [437] SATIP: Idle timeout - releasing [device 0]
Mar 7 11:40:47 vdr-server vdr: [437] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Still the same situation even with updated OctopusNet 1.1.6.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
can you try
#61 (comment)
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Unfortunately - if I am not fully mistaken - Your workaround does not help on the VDR server I set up. The part with Detected 14 RTP packet errors [device 0] errors with Octopus NET leads to the glitches in the VDR client I mentioned above. Changing to a minisatip based SAT>IP receiver I just have the SATIP: Idle timeout - releasing [device 0] errors; less/no glitches in the picture of the VDR client.
Feb 5 16:53:25 vdr-dev-1 vdr: [1309] SATIP: Detected 14 RTP packet errors [device 0]
Feb 5 16:58:49 vdr-dev-1 vdr: [1311] SATIP: Idle timeout - releasing [device 0]
Feb 5 16:59:01 vdr-dev-1 vdr: [1309] SATIP: Detected 15 RTP packet errors [device 0]
Feb 5 17:03:53 vdr-dev-1 vdr: [1311] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb 5 17:04:16 vdr-dev-1 vdr: [1309] SATIP: Detected 14 RTP packet errors [device 0]
Feb 5 17:09:41 vdr-dev-1 vdr: [1311] SATIP: Idle timeout - releasing [device 0]
Feb 5 17:09:53 vdr-dev-1 vdr: [1309] SATIP: Detected 15 RTP packet errors [device 0]
Feb 5 17:14:45 vdr-dev-1 vdr: [1311] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb 5 17:15:08 vdr-dev-1 vdr: [1309] SATIP: Detected 14 RTP packet errors [device 0]
Feb 5 17:20:33 vdr-dev-1 vdr: [1311] SATIP: Idle timeout - releasing [device 0]
Feb 5 17:20:45 vdr-dev-1 vdr: [1309] SATIP: Detected 15 RTP packet errors [device 0]
Feb 5 17:25:37 vdr-dev-1 vdr: [1311] SATIP-ERROR: Tuning timeout - retuning [device 0]
Feb 5 17:26:00 vdr-dev-1 vdr: [1309] SATIP: Detected 14 RTP packet errors [device 0]
Feb 5 17:31:25 vdr-dev-1 vdr: [1311] SATIP: Idle timeout - releasing [device 0]
Feb 5 17:31:36 vdr-dev-1 vdr: [1309] SATIP: Detected 15 RTP packet errors [device 0]
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
BTW, on client side I do not have these errors because the client's SATIP config does not update EPG information. Only the server does that showing the errors.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
do you have a Fritzbox in between, if yes set the interfaces to full power.
you can also try to increase the kernel params, it may help in regards to the RTP errors catalinii/minisatip#21 (comment)
do you have dead channels in your channels.conf?
for the Octopus NET S2 V1.1.5 , there is probably a version 1.1.6 but I'm not sure as I have only minisatip and a IDL400S for tests
is the Transport mode in vdr set to Unicast? (minisatip can do UDP and TCP, the octopus is UDP only)
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
The SAT>IP and VDR client and server are directly connected to a (managed) switch; no Fritz!Box in between. Dead channels might be radio only but I can check and reduce a little. Transport mode is unicast.
I set Octopusnet to "Enforce strict SAT>IP" today and it seems to help a little on VDR client side; monitoring the situation now.
With "standard" distribution satip plugin the PROD server logs show:
Feb 5 18:45:08 vdr-server vdr: [282] SATIP: Detected 1 RTP packet error [device 0]
Feb 5 18:51:24 vdr-server vdr: [284] SATIP: Idle timeout - releasing [device 0]
Feb 5 18:51:36 vdr-server vdr: [282] SATIP: Detected 1 RTP packet error [device 0]
Feb 5 19:02:15 vdr-server vdr: [284] SATIP: Idle timeout - releasing [device 0]
Feb 5 19:02:28 vdr-server vdr: [282] SATIP: Detected 1 RTP packet error [device 0]
Feb 5 19:13:08 vdr-server vdr: [284] SATIP: Idle timeout - releasing [device 0]
Feb 5 19:13:20 vdr-server vdr: [282] SATIP: Detected 1 RTP packet error [device 0]
Feb 5 19:14:32 vdr-server vdr: [284] SATIP: Idle timeout - releasing [device 0]
Feb 5 19:26:33 vdr-server vdr: [284] SATIP: Idle timeout - releasing [device 0]
Feb 5 19:26:45 vdr-server vdr: [282] SATIP: Detected 2 RTP packet errors [device 0]
Idle timeout reoccurs approx. each 11 mins.. Situation remains nearly the same as mentioned at the top of this issue. Client side glitches are now under investigation.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
as long you do not get something like "SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]", you may check your managed switch firmware and try to disable QOS settings, and on the "client" if your distribution has a valid CURL version
avoid wlan and powerline if possible
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Octopusnet was update a while ago to 1.1.6. Curl is version 7.58.0. QOS is disabled; "green" features are disabled on the switch.
If I disable the EPG update setting in satip on the VDR server everything is running flawlessly. Satip is started on client and server with option -d 1. Audio/picture glitches on the client are much more present with Octopusnet than minisatip device and immediately disappear in case the server's satip does not update the EPG data any more.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
no idea but -d2 which is the default if I'm not wrong is may one thing you can try.
what LNB/switch do you use, is it receiver powered?
from vdr-plugin-satip.
9000h
commented on June 11, 2024
I had one Unicable switch in the past doing strange things after some runtime.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
I can give it a try but i doubt it works. If I set client and server to default -d 2 I think the concurrent use of the same devices will lead to ressource conflicts for both (client & server) accessing both devices.
As mentioned: If I turn off the EPG update option in satip on the VDR server side the issue does NOT occur any more.
Additional check:
Okay. It turned out I need to set satip to -d 1 for the client and the server otherwise I do get conflicts using the two DVB-S2 devices of Octopus NET.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
how did your SAT setup looks like LNB/switch/cabling?
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
I use
- a Quad-Switch-LNB for direct connectivity to receivers.
- 2 cables for the SAT>IP receiver
- 2 cables connected to other DVB-S2 receivers.
- VDR 2.4.0 client (BeeBox, VAAPI, softhddevice) & server (LXC on Proxmox) are yaVDR Ansible based on Ubuntu 18.04.
- SAT>IP receiver 1 is Wetek Play based on minidvblinux
- other SAT>IP receiver is Octopus NET S2 (not in use due to this issue leading to client video glitches; glitches not in scope here)
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Hi. No further advise? I can try to debug or drill down the situation in case I know what details to provide. From the situation now I get the impression either minisatip or OctopusNet devices show these RTP or SATIP-ERROR errors when the satip plugin "releases" or "retunes" one of the two DVB-S2 tuners whereas the other one is still beeing in use. On OctopusNet this happens much more often than with minisatip device.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
diseqc config ?
# # input 1: 19.2E
#1:
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 99999 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 99999 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
I checked again with both the minisatip driven SAT>IP receiver versus the Octopus NET.
What I determine is the minitsatip RTP errors occur during the TEARDOWN action; to me it looks the cseq error occurs due to the fact the old minisatip does not give a response to the TEARDOWN.
WIth Octopus Net the client's video/audio glitches occur much more frequent; correlated to when the VDR server excutes a TEARDOWN.
In both cases the situation gets better when I disable the EPG scan function in the VDR server's satip plugin.
Client setting:
grep "^satip" /var/lib/vdr/setup.conf
satip.CICAM = 0 0
satip.DisabledFilters =
satip.DisabledSources =
satip.EnableCIExtension = 0
satip.EnableEITScan = 0
satip.EnableFrontendReuse = 1
satip.OperatingMode = 2
satip.TransportMode = 0
The server setting's difference is the EnableEITScan = 1.
Both client & server satip parameter is -d 1; both use the satip (2.4.1-GIT-43b60b1). The Wetek Play has two DVBS2 tuners.
MiniSatip Device /MLD 5.x on Wetek Play(minisatip/0.7.4):
Server:
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.40/) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.40/stream=1?addpids=120&delpids=116) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.40/stream=1?addpids=120&delpids=116) Response 200 in 1 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.40/) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.40/) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.40/stream=1?addpids=107&delpids=120) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.40/stream=1?addpids=107&delpids=120) Response 200 in 0 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.40/) [device 0]
Feb 15 16:29:16 vdr-server vdr: [259] SATIP1: bool cSatipTuner::SetSource(cSatipServer*, int, const char*, int) (111332, src=1&freq=11332&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=34, 0) [device 0]
Feb 15 16:29:16 vdr-server vdr: [259] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (192.168.178.40) [device 0]
Feb 15 16:29:16 vdr-server vdr: [259] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (src=1&freq=11332&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=34) [device 0]
Feb 15 16:29:16 vdr-server vdr: [259] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsSet, smExternal) current=tsLocked internal=0 external=0 [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsLocked to tsSet [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipTuner::Disconnect() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Teardown(const char*) (rtsp://192.168.178.40/stream=1) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] curl_easy_perform() [rtsp.c,400] failed: RTSP CSeq mismatch or invalid CSeq (85)
Feb 15 16:29:16 vdr-server vdr: [282] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=failed [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Teardown(const char*) (rtsp://192.168.178.40/stream=1) Response 0 in 10 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipRtsp::Reset() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipRtsp::Destroy() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipRtsp::Create() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipTuner::Connect() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::SetInterface(const char*) () [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Options(const char*) (rtsp://192.168.178.40/) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Options(const char*) (rtsp://192.168.178.40/) Response 200 in 0 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://192.168.178.40/?src=1&freq=11332&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=34, 38466, 38467, 0) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipRtsp::ParseHeader() [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: virtual void cSatipTuner::SetSessionTimeout(const char*, int) (1614129524, 30000) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: virtual void cSatipTuner::SetStreamId(int) (1) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://192.168.178.40/?src=1&freq=11332&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&sr=22000&fec=34, 38466, 38467) Response 200 in 1 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsTuned, smInternal) current=tsSet internal=0 external=0 [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsSet to tsTuned [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.40/stream=1) [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP5: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.40/stream=1) Response 200 in 1 ms [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsLocked, smInternal) current=tsTuned internal=0 external=0 [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsTuned to tsLocked [device 0]
Feb 15 16:29:16 vdr-server vdr: [282] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.40/) [device 0]
On client side far less symptoms like video/audio glitches but sometimes RTP errors.
Octopus Net:
Server:
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.19/stream=1?delpids=820) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.19/) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.19/) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Play(const char*) (rtsp://192.168.178.19/stream=1?addpids=830) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.19/) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1399] SATIP1: bool cSatipTuner::SetSource(cSatipServer*, int, const char*, int) (112343, src=1&freq=12343&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34, 0) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1399] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (192.168.178.19) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1399] SATIP1: cString cSatipRtsp::RtspUnescapeString(const char*) (src=1&freq=12343&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1399] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsSet, smExternal) current=tsLocked internal=0 external=0 [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsLocked to tsSet [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipTuner::Disconnect() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Teardown(const char*) (rtsp://192.168.178.19/stream=1) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipRtsp::Reset() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipRtsp::Destroy() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipRtsp::Create() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipTuner::Connect() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::SetInterface(const char*) () [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Options(const char*) (rtsp://192.168.178.19/) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Setup(const char*, int, int, bool) (rtsp://192.168.178.19/?src=1&freq=12343&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=27500&fec=34, 59992, 59993, 0) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipRtsp::ParseHeader() [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: virtual void cSatipTuner::SetSessionTimeout(const char*, int) (1533499281, 60000) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: virtual void cSatipTuner::SetupTransport(int, int, const char*, const char*) (59992, 59993, (null), (null)) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: virtual void cSatipTuner::SetStreamId(int) (1) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsTuned, smInternal) current=tsSet internal=0 external=0 [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsSet to tsTuned [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.19/stream=1) [device 0]
Feb 16 07:04:58 vdr-server vdr: [1404] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
As a symptom on client side there is a glitch in video/audio:
Feb 16 07:04:58 vdr vdr: audio/alsa: avail underrun error? 'Datenübergabe unterbrochen (broken pipe)'
Help is very much appreciated.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
I believe the issue is probably the audio errors you see, but anyway the minisatip 0.7.4 is also a very old version.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
On the server side I use satip version satip (2.4.0-GIT-299296b) now. For about 10 minutes there are no video/audio symptoms on client side nor RTP packet errors on client & server.
I was too fast but the client symptom occurs less frequent now since the change on server side.
Server/satip (2.4.0-GIT-299296b):
Feb 16 09:59:37 vdr-server vdr: [1376] SATIP: Detected 1 RTP packet error [device 0]
Client/satip (2.4.1-GIT-43b60b1):
Feb 16 09:59:37 vdr vdr: audio/alsa: avail underrun error? 'Datenübergabe unterbrochen (broken pipe)'
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
With satip (2.4.0-GIT-b697e43) on the VDR server the situation remains "more stable" on client & server than with the most actual one showing less occurance of SATIP: Detected 1 RTP packet error [device 0]
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
It starts to show the client's symptoms when I use satip (2.4.1-GIT-19e3057) on the server. Even with switching off the "FrontendReuse" parameter for satip the situation is different than with satip (2.4.0-GIT-b697e43) on the server where this function was not built in.
Server/satip (2.4.1-GIT-19e3057)/satip.EnableFrontendReuse=0:
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: virtual void cSatipTuner::SetSessionTimeout(const char*, int) (0371591002, 60000) [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: virtual void cSatipTuner::SetupTransport(int, int, const char*, const char*) (48568, 48569, (null), (null)) [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: virtual void cSatipTuner::SetStreamId(int) (2) [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsTuned, smInternal) current=tsSet internal=0 external=0 [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsSet to tsTuned [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.19/stream=2) [device 0]
Feb 16 12:16:40 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 12:16:41 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::Describe(const char*) (rtsp://192.168.178.19/stream=2) [device 0]
Feb 16 12:16:41 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::ValidateLatestResponse(long int*) result=ok [device 0]
Feb 16 12:16:41 vdr-server vdr: [1338] SATIP1: bool cSatipTuner::RequestState(cSatipTuner::eTunerState, cSatipTuner::eStateMode) (tsLocked, smInternal) current=tsTuned internal=0 external=0 [device 0]
Feb 16 12:16:41 vdr-server vdr: [1338] SATIP1: void cSatipTuner::UpdateCurrentState(): Switching from tsTuned to tsLocked [device 0]
Feb 16 12:16:41 vdr-server vdr: [1338] SATIP1: bool cSatipRtsp::Receive(const char*) (rtsp://192.168.178.19/) [device 0]
Client/satip (2.4.1-GIT-43b60b1)/satip.EnableFrontendReuse=1:
Feb 16 12:16:41 vdr vdr: audio/alsa: avail underrun error? 'Datenübergabe unterbrochen (broken pipe)'
Am I heading towards a wrong direction? Any help appreciated.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Additional info to my minisatip setup:
I updated the minisatip on my Wetek Play to a more actual one. SInce that time the errors
... SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.178.40/ [device 0]
disappeared. I think the new minisatip "understands" the TEARDOWN properly now. As I remember from traces with TRAC 0x0013 my previous minisatip version did NOT respond to a TEARDOWN.
This is an excerpt of the current server side log:
Feb 28 13:14:16 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
Feb 28 13:24:46 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
Feb 28 13:35:17 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
Feb 28 13:45:46 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
Feb 28 13:56:16 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
Feb 28 14:06:46 vdr-server vdr: [375] SATIP: Idle timeout - releasing [device 0]
But: The OctopusNET issue is still valid.
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
One RTP packet error is quite normal after the SETUP as the plugin needs to synhcronize packet sequence numbers with the first packet. If there's actually one packet missing, it's just 188 bytes and due to the stream error correction you won't see any glitches either.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
cannot speak for the Octopus Net but as expected the current minisatip version works well with the plugin
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
My current situation with OctopusNet is the vdr client produces the glitches connected to OctopusNet's tuner1 in case the vdr server is closing/reconnecting on/with the tuner2. I will recheck with the current satip version and the changes You applied.
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
IIRC, the offending commit, that makes your issues worse, seems to be this one: 19e3057#diff-9c8927d3306e2cc693aef6f6334aa85fd8cf30917459b744839d9722b4dad583
Correct However, it shouldn't make any difference as default satip.EnableFrontendReuse=1 should end up to return true as before and the needsDetachReceivers = true; should be the same as well due to the if (Receiving()) check of the code block. However, you could try to revert the latter one, if there are some hiding timing issues.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Hi @rofafor I do not get the clue on what I should eactly do now in the code. The situation is still appearing: (Random?) Glitches on the client side and the same log entries on server side as initially mentioned with OctopusNet with RTP errors
Mar 4 18:02:41 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:02:53 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
Mar 4 18:13:12 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:13:24 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
Mar 4 18:23:42 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:23:54 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
Mar 4 18:34:12 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:34:24 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
Mar 4 18:44:42 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:44:54 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
Mar 4 18:55:13 vdr-server vdr: [393] SATIP: Idle timeout - releasing [device 0]
Mar 4 18:55:25 vdr-server vdr: [391] SATIP: Detected 1 RTP packet error [device 0]
The error above re-appears even if server is running attached to tuner2 w/o any client attached to tuner1 of OctopusNet.
Version in use satip (2.4.1-GIT-55362a2).
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Compiled and used satip (2.4.1-GIT-ba0b04b) - SAT>IP Devices now for the server. No other client attached to the OctopusNet.
Here is the log sequence (TRAC 0x001f) were the RTP error occurs after "tsIdle" state.
vdr-server-log-sequence.txt
and with a little bit more trace (TRAC 0x004f)
vdr-server-log-trac-004f.txt
from vdr-plugin-satip.
9000h
commented on June 11, 2024
Hmm, if it's not happen with minisatip then it could be the Octopus NET or minisatip behaves different but I think it is as close as possible to the spec.
the spec says
Please note that when no signal is being received, the signal is being lost,
or no PID is available, the SAT>IP server shall nevertheless issue an empty
RTP packet at least every 100ms.
I think only a packet capture can show the difference clearly
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
@9000h are You referring to the SAT>IP spec.? Which version? I do not find the mentioned excerpt in V1.2.2.
Only thing I recognise from my logs is the RTP error occurs each time the DESCRIBE request / responses are beeing handled.
So I suppose we do not need packet captures yet but an analysis in this area first.
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
The error above re-appears even if server is running attached to tuner2 w/o any client attached to tuner1 of OctopusNet.
I don't see any errors there. The idle timeout is just a dirty mechanism to release devices as VDR's EIT scan won't produce any proper events to track, and that one RTP packet error in the beginning of session is usually just packet sequence number synchronizing. The latter one could be fixed, but it would make the code more complex and I did prefer the simplicity back then.
About those artifacts during EIT scan: do those happen with other SAT/IP clients as well or is this just vdr-satip related? This was a common problem it less powerful devices and therefore there's a setup option to disable the EIT scanning in the plugin.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
The error above re-appears even if server is running attached to tuner2 w/o any client attached to tuner1 of OctopusNet.
I don't see any errors there. The idle timeout is just a dirty mechanism to release devices as VDR's EIT scan won't produce any proper events to track, and that one RTP packet error in the beginning of session is usually just packet sequence number synchronizing. The latter one could be fixed, but it would make the code more complex and I did prefer the simplicity back then.
Understood. Most probably the syslogs shows errors of between 1 and 3 RTP packets.; most likely during the tsSetup phase. Interestingly they re-occur in the given interval as seen above in this issue. This seems to be related my vdr-server is enabled to update PID/names of the channels in DVB section; an EIT scan (in EPG section) should only happen regularily in an 5 hours interval.
About those artifacts during EIT scan: do those happen with other SAT/IP clients as well or is this just vdr-satip related? This was a common problem it less powerful devices and therefore there's a setup option to disable the EIT scanning in the plugin.
The same SAT>IP based VDR client (N3150) and VDR server (LXC on Xeon based host) connected to the "minisatip" based SATP>IP server shows less/no artifacts. So I am currently in doubt about relation to "low power" devices but I do not want to exclude this thesis. I will need to compare the situation with my prior VDR client or another i.e. Kodi 19 based frontend.
from vdr-plugin-satip.
rofafor
commented on June 11, 2024
If your minisatip setup misbehaves as well, then there's a bug somewhere. Finding such bug without a similar setup is quite hard, so you need to dig out the malfunctioning code, so I can suggest a fix for it. Go into VDR's Setup/EPG menu or use SVDRP to force EPG scan and see whether artifacts occur. If yes, you can disable EIT scanner / section filters as a quick fix. Then I would start tweaking the cSatipDevice::MaySwitchTransponder and cSatipDevice::ProvidesTransponder implementations.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
About client artifacts:
Hi. I gave it a try to check from one more powerful (WIndows10 & Ubuntu;1GBit/s NIC; Intel only!) system with streaming from the OctopusNet with HTTP only.
Two VLCs on same system connect to two different HD channels/transponder on same OctopusNet. 1st stream keeps on streaming. When I connect/disconnect the 2nd stream I recognise slight audio interrupts in 1st stream. Disconnecting/reconnecting (stop/start in VLC) I determine sometimes additional video artifacts and audio interrupts in the 1st stream. This is most probably the same "effect" as I recognised with SAT>IP of vdr access. Right now I am a bit puzzled.
P.S. Same effects in case a VLC connects from a secondary system.
from vdr-plugin-satip.
9000h
commented on June 11, 2024
Hmm, and with minisatip and VLC do you see the same?
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Hmm, and with minisatip and VLC do you see the same?
I checked this with two parallel streams towards the minisatip device stopping/starting the stream in VLC. I discovered no artifacts or audio interrupts so far. Only (small) audio interrupts can be recognised during re-tuning; not always but they appear once a while (which is not as annoying as with the OctopusNet).
from vdr-plugin-satip.
9000h
commented on June 11, 2024
so it looks like the Dish/LNB is fine, for the OctopusNet I cannot help but you may check the LNB setup
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
so it looks like the Dish/LNB is fine, for the OctopusNet I cannot help but you may check the LNB setup
The LNB Setup in the OctopusNet is set to "automatic". I suppose I need to factory reset the OctopusNet, retest and in case get in touch with the Digital Devices Support. I will also check the (VLC streaming) situation connecting a system directly to the OctopusNet without any network switches/routers in between. Just to be on the safe side.
from vdr-plugin-satip.
hpannenb
commented on June 11, 2024
Edit: I found the cause for the client video and audio glitches after more detailed investigations. Overall I could drill down to the Quad LNB which was not working properly any more. After replacing it with a new one the issue is not occuring any more on the client.
from vdr-plugin-satip.
Related Issues (20)
- channel switching issue HOT 66
- ClearQAM/ATSC support? HOT 3
- ERROR: SATIP poller thread HOT 5
- channel retune issue HOT 20
- missing quirk for Inverto IDL-400s HOT 4
- Plugin uses all available tuners of AVM Fritz! box when using wirbelscan
- vdr-2.5.1 crash HOT 1
- New release? HOT 4
- question about your website HOT 1
- Glitches when switching channels HOT 6
- create satip.h HOT 4
- README/log improvements: list names of supported devices ("description"), quirks, ... HOT 2
- Plugin does not start fresh connection after Curl timeout HOT 2
- PIDs are added and removed again within milliseconds HOT 9
- Returncode 404 from minisatip is not handled HOT 6
- Session times out on EXIP418 when timeout is equal to eMinKeepAliveIntervalMs HOT 9
- 250ms delay between commands is missing sometimes HOT 1
- plugin reports signal strength in dBm wrong to vdr, if server reports zero signal strength HOT 8
- octopus: "RTSP/1.0 455 Method Not Valid in This State" followed by vdr crash
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vdr-plugin-satip.