Fritzbox response quirk broken due, response code parsed incorrectly

[retrofan1979]

Hello,

I noticed when I try to do a channelscan with DVBViewer Pro and TransEdit with minisatip as SAT>IP server, it rejects the connection. However, when I play an SAT>IP URL it streams just fine. Also when analyzing a mux with TransEdit it works fine. Only a channelscan fails. Hope you can fix it. I'm using a Fritz!Box 6690 cable. See logfile attached.

[retrofan1979]

minisatip.log

[xxj737]

pid=all
Not Supported

[retrofan1979]

Thanks, but with TransEdit I can scan a mux with over a 100 pids, so no problems here. When I want to do a normal channelscan I get this error.

[xxj737]

for example

[retrofan1979]

with SAT>IP server (DVB-C) of Fritz!Box 6690 Cable I have no problems at all, but with minisatip the channelscan fails, so it seems a bug in minisatip? Hope you can fix it.

[retrofan1979]

Fritzbox:

[retrofan1979]

minisatip:

[retrofan1979]

I found out when selecting option "Open whole transponder" in TransEdit it will scan one mux at the time. With Fritzbox this option isn't needed. When trying to scan all muxes with minisatip, it shows the error again. Channelscan in DVBViewer still fails.

[retrofan1979]

[Jalle19]

Have you tried running minisatip with -k?

• -k Emulate pids=all when the hardware does not support it, on enigma boxes is enabled by default

[retrofan1979]

Thanks for the suggestion, I tried it now, but still no luck.

[retrofan1979]

No other suggestions? Maybe someone else with Fritzbox can try? @lars18th or @9000h perhaps?

[catalinii]

Can you add -l satipc to the command oine and upload a poad again?

[retrofan1979]

Can you add -l satipc to the command oine and upload a poad again?

Hi @catalinii : thanks, yes, ofcourse, here it is :-)

service.log

[Jalle19]

[05/08 08:43:30.814 AD0]: satipc_reply (adapter 0, state 3): receiving from handle 10, sock 13, code 1434
[05/08 08:43:30.815 AD0]: satipc: Received signal status from the server for adapter 0, stength=113 status=0 quality=0
[05/08 08:43:30.815 AD0]: marking device 0 as error, rc = 1434

[retrofan1979]

[05/08 08:43:30.814 AD0]: satipc_reply (adapter 0, state 3): receiving from handle 10, sock 13, code 1434
[05/08 08:43:30.815 AD0]: satipc: Received signal status from the server for adapter 0, stength=113 status=0 quality=0
[05/08 08:43:30.815 AD0]: marking device 0 as error, rc = 1434

Thanks, but what does it mean and more importantly: how can we fix it? When I stop the stream and restart it again it works fine. Maybe it needs an extra teardown?

[Jalle19]

I don't exactly know what it means, I just pointed it out since it looks suspicious. Maybe @lars18th or @catalinii knows?

[9000h]

Fritz!Box is some kind of sat>ip compatible but not certificated, and some workarounds still needed (for QAM64 channels for example

[catalinii]

Let’S try -v satipc

to identify why is the server erroring out

[retrofan1979]

Let’S try -v satipc

to identify why is the server erroring out

Here it is. service.log

[retrofan1979]

and another logfile, the same as the previous one, but also added with DVBViewer playback via HTTP SAT>IP URLS port 8080.

service.log

[retrofan1979]

@catalinii : did you investigate the logs already? What to do next?

[Jalle19]

Seems like the server sends invalid RTSP responses with two empty lines between the headers and the body, leading to the packet being processed as two separate packets:

[08/08 16:53:45.417 AD0]: MSG process << server :
RTSP/1.0 200 OK
Content-Base: rtsp://192.168.178.1:554/stream=1918
Content-Length: 205
Content-Type: application/sdp
CSeq: 10
Session: 1931

[08/08 16:53:45.417 AD0]: satipc_reply (adapter 0, state 3): receiving from handle 7, sock 8, code 200
[08/08 16:53:45.417 AD0]: satipc 0, expect_reply 0, want_tune 0 want commit 1
[08/08 16:53:45.417 AD0]: satipc: request for adapter 0, state 3, freq 498000, pids to add 0, pids to delete 0, expect_reply 0, want_tune 0, sent_transport 1, closed_rtsp 0
[08/08 16:53:45.417 AD0]: adapter 0: Nothing to commit
[08/08 16:53:45.461 AD0]: MSG process << server :
v=0
o=- 1931 1 IN IP4 192.168.178.1
s=SatIPServer:1 0,0,4
t=0 0
m=video 0 RTP/AVP 33
c=In IP4 0.0.0.0
a=control:stream=1918
a=fmtp:33 ver=1.2;src=1;tuner=1,113,0,0,498.00,8,dvbc,256qam,6900,,,,
a=sendonly

[08/08 16:53:45.461 AD0]: satipc_reply (adapter 0, state 3): receiving from handle 7, sock 8, code 1931

Since the logic for determining the status code is fairly naive, it ends up thinking that the 1931 from o=- 1931 1 IN IP4 192.168.178.1 is the status code.

[Jalle19]

~The logging mechanism is also broken, LOGM in satipc_reply works, but not in satipc_tcp_read. Probably due to all the various #undef going on.~ Edit: nevermind, TCP is not used here

[Jalle19]

Seems our old friend https://github.com/catalinii/minisatip/issues/508#issue-388111162 has resurfaced

[Jalle19]

Fixing the return code algorithm to return 0 if a valid return code is not found will fix this

[Jalle19]

A better solution would be to parse the device information like tvheadend does (https://github.com/tvheadend/tvheadend/blob/49ac9387186d32b55a399a04155e835eac22c6c1/src/input/mpegts/satip/satip_frontend.c#L2264) and apply quirks based on device, not return code. Could also be useful to show in the web interface instead of just the IP address.

[retrofan1979]

@Jalle19 thanks for investigating, much appreciated! So, probably it can be fixed :-)

[catalinii]

I think we should force satipc_tcp_read to wait for the payload. The content-length indicates there is a statically sized payload