Tvheadend

The error -5 means EIO - the TCP connection was closed by the server. That's the reason why the session is NOT terminated correctly (shutdown command). The 503 error - what we can do with it ? It's fatal error and it should not occur when you don't share tuners with something else. Yes, we can close the mux reception early, but it's all we can do.

The server is broken (firmware). I can reproduce these errors with the original firmware on Inverto boxes (Grundig gssbox, Telestar Digibit R1, Invert IDL-400s). Perhaps, the megasat firmware is based on this. But it's bug in the firmware (connection with the client is terminated early or server crashes so everything is lost).

I would report this to the hardware vendor to fix their firmware. Note that SETUP+PLAY causes socket close on the server side.. Then the "tuner" is busy so server returns 503 until RTSP timeout is reached. Really firmware bug.

Just note that based on the bad experience with Inverto firmwares - I started https://github.com/perexg/satip-axe to eliminate server bugs using the light minisatip server - rock solid solution for me now.

I would like to agree if it wasn't possible to connect to the SATIP box using SATIP clients on both the iPad and the Windows machine while TVH refuses to move on. And usually this condition can be resolved by "service tvheadend restart".
That being said, I think it's a bit early to lean back and fingerpoint at the hardware vendor.
Sure, the server boxes firmware might be implemented in a certain way which makes it harder to TVH to interface with it given the fact that the SATIP Spec only details out the positive scenarios while theres no to little guidance on how to handle error conditions.
However I wouldn't consider it an option to reprogram the boxes firmwares with minisatip for the average user.
Keep in mind, the boxes that are in the market have passed the SATIP certification and they do work with the above mentioned client apps, so it might be very difficult to get the vendors to change things as long as the issues cannot be shown using certified hardware and apps.

Coming to what we can do:
In my opinion, both scenarios should be handled by TVH in a reasonable way in terms of internal cleanup which might involve disposing and recreating / restarting the associated "Subscription" object that is in a bad state.
I have observed a condition in which the RTSP -5 error occured but wasn't handled at all, the underlying process just sits around complaining about "no input detected". While this might make sense for integrated DVB hardware cards where communication errors are very unlikely to happen, I think the situation for network attached tuners is quite different. Communication errors / breakdowns should be expected and handled maybe by retrying the communication sequence.
Also, in both scenarios I'm not seeing any further RTSP communication while the "Subscriptions" are in bad state. If trying to access a channel, the subscriptions first enter "Testing" for a while, then "Bad", but no "SETUP" / "PLAY" on the communication end.

If this error occurs, it's really serious one. I don't say that I'm against to include some hacks to improve the latencies, but the problem is that the server is in some "dead" state for a while (at least Inverto firmwares behaves in that way). Nothing helps - there is already a TEARDOWN hack, but it works only in some use cases. Basically, TVH really pushes the server implementation hardly, and it's really amazing how bad the firmwares are. So - if you like to do some hacks - go ahead. I'll include them.

And I think that your argumentation that preliminary connection close on networks are very likely to happen - no, it's false argumentation. We are in realtime world. If this error happen, it's serious. The RTSP client just doesn't know what the server does in this case (the RTSP session state is lost), so it's better to wait for recovery like the current implementation does before pushing new requests.

Again - the server is failing, any recovery process is bad and unpredictable.

Note that TVH has already configuration options to run OTA EPG grabbers to night hours and you can force to use only one tuner to keep things consistent for "streaming hours".

I have to agree with jaroslav, i dont think implementing hacks for sat>ip in tvhis the way to go, its not the job of tvh to handle bad firmware on tuners.

satip-axe with digibit r1 has been rock solid with me, use this tuner and fw with tvh for best result is my advice.

Thanks guys, I'll do some more investigation re. the above scenarios and let you know if I come across something helpful. I agree that the hacking beyond the specification is not the right thing todo. All I'm saying is that in the outlined scenarios, I was able to access the device using other apps while TVH considered the tuners as being in a "bad" state and wouldn't recover.

Re. the RTSP error 5: From a quick read of the spec, I would assume that following a SETUP which returned a session id, a TEARDOWN would be expected to close the session and free up resources in the server, even if a PLAY command inbetween failed. I'm not seeing that in the trace and I wonder whether it is correct or not since the spec leaves room for interpretation.

I'll try to limit the EPG grabbers to off hours - thanks for the hint!

I did some more testing involving a second setup which replaced TVH with "DVBViewer Recording Service" on a Windows machine, which is a SW package with roughly the same features as TVH. I decided to give it a try because DVBViewer is "SATIP certified" and I wanted to see if I could replicate the errors with that setup. While there were no obvious lockups, it became clear that the Megasat device is not designed to handle multiple SATIP sessions from the same consuming device: When accessed from two Kodi instances via DVBViewer RS, it was not possible to tune into two different channels simultaneously. Always one Kodi instance stopped replay when a channel was selected on the other one.
When doing the same test using native SATIP client apps on different devices, it was no problem to view and zap through different channels one each of the devices.
Interestingly, the Megasat manual always stresses that it is up to four individual devices to which the box can stream a Satellite programme, so it seems that it was not designed for the use-case of one device with one IP address consuming each of the streams. I wonder if this is covered somewhere in the SATIP spec or part of the certification test cases.

Is there a compatibility list somewhere showing which boxes do work with TVH? I'd be more than happy to share my results for when other users make their buying decision.

On another note: The Unicable feature of the box is flawed as well which is why I'll be returning mine and have it exchanged for one of the Inverto 400s clones.
Please feel free to close this issue.

You can use multiple IP addresses - TVH allows the IP address configuration per tuner. Just add the extra addresses to your system's network config.

Hi,
I got the same SatIp Tuner, and ran into similar Problems as Timo.
It looks like, the SatIp server closes the http connection after
every rtsp request. Also one speciality of this box, the Session
is malformed, it contains a space in the beginning of the id.

I had a look into the source code and the network trace.
What happens ist the following :
tvh : RTSP Setup
ms : RTSP Ok
ms : Fin/Ack
tvh : RTSP Play on the closed connection

Hm, after a couple of retries, the server is now okay with reusing the connection,
and is working as expected. I'll try to debug it tomorrow a bit more.

Just a note here, the behaviour of the firmware is valid in respect to the SatIp Spec 1.2.2
"An RTSP session generally spans multiple TCP connections (e.g. one TCP connection per request - response)."
The correct fix seems to be, to open a new connection for every request, or at least include an
option for firmwares, that need these.

Server must not close the connection before timeout. Yes, client may do multiple TCP connections for one session.

Anyway, it appears the this server does not like multiple sessions from same IP - see comments 8 and 9. Try one tuner and then try to add other tuners using different IPs.

I'm only using one tuner for now and have these issues