Reoccuring RTP errors with Octopus NET S2 V1.1.5/1.1.6 #63
Comments
hpannenb
changed the title
|
@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. |
|
Still the same situation even with updated OctopusNet 1.1.6. |
|
can you try |
|
@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. :-) I finally made it installing a VDR 2.4.0 as basis. Once I have Octopus NET enabled I will let You know. |
|
Unfortunately - if I am not fully mistaken - Your workaround does not help on the VDR server I set up. The part with |
|
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. |
|
do you have a Fritzbox in between, if yes set the interfaces to full power. |
|
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. With "standard" distribution satip plugin the PROD server logs show: 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. |
|
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 |
|
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. |
|
no idea but -d2 which is the default if I'm not wrong is may one thing you can try. |
|
I had one Unicable switch in the past doing strange things after some runtime. |
|
I can give it a try but i doubt it works. If I set client and server to default 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: |
hpannenb
changed the title
hpannenb
changed the title
|
how did your SAT setup looks like LNB/switch/cabling? |
|
I use
|
|
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. |
|
diseqc config ? |
|
I have no DiSEqC in use or configured. |
|
I checked again with both the minisatip driven SAT>IP receiver versus the Octopus NET. Client setting: The server setting's difference is the Both client & server satip parameter is MiniSatip Device /MLD 5.x on Wetek Play(minisatip/0.7.4): On client side far less symptoms like video/audio glitches but sometimes RTP errors. Octopus Net: As a symptom on client side there is a glitch in video/audio: Help is very much appreciated. |
|
I believe the issue is probably the audio errors you see, but anyway the minisatip 0.7.4 is also a very old version. |
|
On the server side I use satip version 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): Client/satip (2.4.1-GIT-43b60b1): |
|
With |
|
It starts to show the client's symptoms when I use Server/satip (2.4.1-GIT-19e3057)/satip.EnableFrontendReuse=0: Client/satip (2.4.1-GIT-43b60b1)/satip.EnableFrontendReuse=1: Am I heading towards a wrong direction? Any help appreciated. |
|
Additional info to my minisatip setup: This is an excerpt of the current server side log: But: The OctopusNET issue is still valid. |
|
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. |
|
cannot speak for the Octopus Net but as expected the current minisatip version works well with the plugin |
|
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. |
|
IIRC, the offending commit, that makes your issues worse, seems to be this one: 19e3057#diff-9c8927d3306e2cc693aef6f6334aa85fd8cf30917459b744839d9722b4dad583 |
|
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 The error above re-appears even if server is running attached to tuner2 w/o any client attached to tuner1 of OctopusNet. |
|
Compiled and used Here is the log sequence (TRAC 0x001f) were the RTP error occurs after "tsIdle" state. |
hpannenb
changed the title
|
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 I think only a packet capture can show the difference clearly |
|
@9000h are You referring to the SAT>IP spec.? Which version? I do not find the mentioned excerpt in V1.2.2. |
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. |
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.
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. |
|
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 |
|
About client artifacts: P.S. Same effects in case a VLC connects from a secondary system. |
|
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). |
|
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. |
|
Due to the fact the symptoms shown seem not to be related to the |
|
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. |
Hi,
on my vdr headless server with yavdr-ansible (VDR 2.4.0 + vdr-plugin-satip) using SATP>IP only I determine many reoccuring RTP errors with my Octopus NET S2 (SAT>IP Server 1.1.5 and 1.1.6) when vdr server's EPG scan is enable. This also happens when the SATIP>IP only client is not beeing used.
Extract of /var/log/syslog:
VDR parameter for the vdr-plugin-satip is set to "-d 1";I am using it for the client as well to have a dedicated SATIP device for client and server.
Extract of the setup.conf:
This is the more detailed debug from the log:
Help is very much appreciated. The issue sometimes leads to glitches in picture and audio on the receiving client and yet I do not know if it is OctopusNet or vdr-plugin-satip related.
Thanks,
Holger.
The text was updated successfully, but these errors were encountered: