HUMAX Digital UHD 4tune+ - SATIP-ERROR: Detected invalid status code 454 about vdr-plugin-satip HOT 19 CLOSED

It looks like that your server sometimes invalidates the active session for no reason. Now, there are two things you could try:

1. Add stream id into keep-alive messages
2. Disable keep-alive messages

bool cSatipTuner::KeepAlive(bool forceP)
{
   ...
  if (forceP && !isempty(*streamAddrM)) {
     cString uri = GetBaseUrl(*streamAddrM, streamPortM);
     // option #1: add stream id into keep-alive messages
     if (streamIdM >= 0)
        uri = cString::sprintf("%sstream=%d", *uri, streamIdM);
     // end of option #1
     // option #2: disable keep-alive messages
     return true;
     // end of option #2
     if (!rtspM.Options(*uri))
        return false;
     }
   ...
}

Does the server work properly with other clients?

from vdr-plugin-satip.

Thanks for the quick answer and suggestions. I tried both options (tuner.c was the correct place, right?), but neither version solved the problem.

As for other clients: Tvheadend, on the few versions I tried, freezes/crashes the server (the receiver part of the device keeps working, but I have to unplug the power cable to get the server part started again). Same story with an older version of your plugin that I had previously installed from a repository. Think it was 2.2.3. With the current version from git that never happens anymore. Have not tried the vtuner/satip combination yet that I saw mentioned on a vdr forum. It looked very complicated to set up.

DVBViewer Lite (Windows) and the HD+ app for Android worked when I tried them, but I haven't tested them extensively yet because neither platform was my intended target. So can't say how reliably they work. I guess I'll have to do on the weekend.

from vdr-plugin-satip.

Yes, please. It would be great, if you'd be able to tcpdump all RTSP & RTCP packets during one hour with a working Windows client and with a vdr-satip setup.

from vdr-plugin-satip.

sure, but I'm not familiar with traffic sniffing at all. Can you please point me towards what command to use to get the desired output?

Would "tcpdump -i [interface name, eth0 in my case] udp port 554 -w filename.txt" be correct to use on the vdr setup? I know the server uses port 554. With Wireshark on windows I could use basically the same filter from what I understand, right?

Thanks again for you help!

from vdr-plugin-satip.

Ok, I ended up using "tcpdump -i eth0 -A -s 0 -w [filename].pcap port 554" and hope that captured the information you asked for. I used the same channel each time and just kept that channel running for about an hour. Captured DVBviewer Lite on Windows and twice with your plugin, once unmodified and also with the option 1 you suggested yesterday.

satipdumps.zip

from vdr-plugin-satip.

It seems that Humax just can't handle the VDR. VDR is constantly scanning all the PMT pids, but DVBViewer is kind of static by setting pids only at startup.
Now, you could try...

• increasing the ePidUpdateIntervalMs in tuner.h into one second or even greater to slow down the pid scanning
• or simply dropping all pid updates after connecting by initializing a 10 second timer (tuner.c#140) and disabling updates according to it (tuner.c#410).

from vdr-plugin-satip.

I don't know how to do the 2nd one, sadly I don't know any programming, but setting the ePidUpdateIntervalMs to a higher value worked really well. No errors at all anymore. Set it to a really high number, 30 seconds, for now though after 1, 5 and 10 seconds all troubled the server at least occasionally. Will see what number I'll be able to settle with eventually.

So thank you again. Even more so because it was my server and not the fault of your plugin.

from vdr-plugin-satip.

That's great to hear. Can you provide me the "Adding server" line from your VDR logs, so I'll add a special quirk for the Humax?

from vdr-plugin-satip.

Oh, sure. It is

SATIP: Adding server '192.168.0.210|DVBS2-4|HGS-1000S SAT>IP SERVER 192.168.0.210' Filters: none CI: no Quirks: none

from vdr-plugin-satip.

That patch produces error sequences like

Sep 26 23:49:45 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:49:45 bananapipro vdr[21057]: [21063] SATIP-ERROR: Keep-alive failed - retuning [device 0]
Sep 26 23:49:45 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:49:45 bananapipro vdr[21057]: [21063] SATIP-ERROR: Connect failed [device 0]
Sep 26 23:51:47 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:51:47 bananapipro vdr[21057]: [21063] SATIP-ERROR: Keep-alive failed - retuning [device 0]
Sep 26 23:51:47 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:51:47 bananapipro vdr[21057]: [21063] SATIP-ERROR: Connect failed [device 0]
Sep 26 23:53:48 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:53:48 bananapipro vdr[21057]: [21063] SATIP-ERROR: Keep-alive failed - retuning [device 0]
Sep 26 23:53:48 bananapipro vdr[21057]: [21063] SATIP-ERROR: Detected invalid status code 454: rtsp://10.0.0.2/ [device 0]
Sep 26 23:53:48 bananapipro vdr[21057]: [21063] SATIP-ERROR: Connect failed [device 0]
Sep 26 23:53:50 bananapipro vdr[21057]: [21062] SATIP: Detected 3 RTP packet errors [device 0]

tcpdump: patched.txt

Also, I don't know if it's related to the changes in the patch, or if it was a mere coincidence, but the humax also locked up in the way that I had to unplug it to get the server part started again. That hadn't happened at all since I updated from the 2.2.3 release version to one from git a week or two ago. The lockup/crash happened before I started logging, so I don't have any logs for it.

from vdr-plugin-satip.

The latest capture revealed another possible bug. Humax announces 60s timeout, but we're sending keep-alive messages with 60.05s interval and it might be, that this tiny difference might make Humax to invalidate the session. Could you change the following line in tuner.c#L366:

- timeoutM = (timeoutP > eMinKeepAliveIntervalMs) ? timeoutP : eMinKeepAliveIntervalMs;
+ timeoutM = (timeoutP > eMinKeepAliveIntervalMs) ? timeoutP - 1 : eMinKeepAliveIntervalMs;

from vdr-plugin-satip.

That doesn't work too well either.

Sometimes it doesn't switch to the channels at all, and if it does there are the packet losses and picture errors that I originally opened the issue for. The server part of the Humax also crashed/locked up two more times while using this patched version, once with tcpdump running so maybe it caught something. I'm relatively sure it's connected to the changes.

I made three logs. The first one is just general usage. No crash, but the other errors will be in there

patched2.txt

2nd log is a short one for the switching channels issue because I didn't know how easily visible that is in the first log. 1st and last channel didn't work, the ones inbetween did.

switchingchannels.txt

Lastly, the log during which the humax server crashed.

crash.txt

from vdr-plugin-satip.

Next time when you're debugging use only one active device. The network logs are rather heavy to read while multiple devices are accessing the server simultaneously. The server doesn't crash totally, but prevents any new resources to be created. The keep-live interval isn't the one I was expecting, so make sure that the only source code modification is commenting the earlier mentioned timeoutM setting line instead of trying to modify the value.

from vdr-plugin-satip.

oh right, I forgot to change it back to one device, sorry.

This is the tcpdump with only that line commented out, without the quirk patch added to the source.

timeout.txt

from vdr-plugin-satip.

Thanks. Great capture, but unfortunately I couldn't spot anything wrong or odd. Everything seems to be working quite nicely, but suddenly Humax misses its' session and vdr-satip has to re-tune that's causing some artifacts on the screen. Sorry, I can't figure out what to do next.

from vdr-plugin-satip.

Don't worry, you helped tremendously already with the advice to change the ePidUpdateIntervalMs.

from vdr-plugin-satip.

So, which value you ended up? I could add a proper quirk for it for the next release.

from vdr-plugin-satip.

I haven't spent too much time figuring the lowest possible value out yet because I've been more fiddling around with newer tvheadend builds instead of vdr as a backend the last few days. I know 20 seconds still caused that error, albeit in longer intervalls than normal. 25 and 30 seconds didn't cause that error in my tries (or maybe the errors are just so far apart that they don't happen in normal tv watching scenarios, not sure).

from vdr-plugin-satip.

Thanks for the info. I'll be closing the issue now as you've been shifting to another software. If any new information appears, please, re-open the issue.

from vdr-plugin-satip.