changing freq sometimes not working correctly when tuner source is external sat>ip server

[jyrts]

1. Have SAT>IP server Xoro 8100 (running on IP 192.168.2.24)

2. basically I am using minisatip as a satip proxy for the Xoro 8100. Main purpuse is oscam decoding (running on IP 192.168.2.50)
   /usr/bin/minisatip -f -o 192.168.2.50:9000 --disable-dvb --disable-ssdp -s 192.168.2.24

3. I have 4 channels on my enigma2 client (running on IP 192.168.2.50)
   #NAME TEST
   #SERVICE 1:0:19:2b7a:0:0:0:0:0:0:http%3a//192.168.2.50%3a8080/?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,6300,6310,6320,6330:ZDF neo HD
   #DESCRIPTION ZDF neo HD
   #SERVICE 1:0:19:2b66:0:0:0:0:0:0:http%3a//192.168.2.50%3a8080/?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,6100,6110,6120,6130:ZDF HD
   #DESCRIPTION ZDF HD
   #SERVICE 1:0:19:2856:0:0:0:0:0:0:http%3a//192.168.2.50%3a8080/?src=1&freq=11583&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5201,5202,5210,5204:BR HD
   #DESCRIPTION BR HD
   #SERVICE 1:0:19:285b:0:0:0:0:0:0:http%3a//192.168.2.50%3a8080/?src=1&freq=11583&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5260,5261,5262:phoenix HD
   #DESCRIPTION phoenix HD

NOTES:
first, second channel are on transponder freq 11362 and third, fourth channel are on frec 11583.
minisatip is running in the enigma2 client, latest version (minisatip server, oscam server and the client is "all-in-one" IP 192.168.2.50)

PROBLEM DESCRIPTION:

1. I put first channel ZDF neo HD - all works
2. I put second channel ZDF HD - all works
3. I put third channel BR HD - no picture
4. I put fourth channel phoenix HD - all works
5. I put back third channel BR HD - all works
6. I put second channel ZDF HD - no picture
7. I put first channel ZDF neo HD - all works
8. I put second channel ZDF HD - all works
9. I put third channel BR HD - no picture

MORE INFO
Seems like when there is a transporder freq change, then at the first attempt I get no picture
Only one client is using only one channel. So I am not using multiple clients or multiple channels at the same time here...
When the channels are on the same transponder, i can change up down as I want - No frees.
when I use directly Xoro 8100 (in channel list I replace 192.168.2.50:8080 -> 192.168.2.24) all works perfectly. No freeze on transponder change

[Jalle19]

Can you post logs from your minisatip instance when doing the channel change sequence you described? Use -l general when logging.

[jyrts]

I am attaching log where I open ZDF HD (works) and then change channel to new transponder BR HD (not working)

minisatip.log

[jyrts]

I add new log where I change channels ZDF HD (OK) -> BR HD (NOK) -> phoenix HD (OK) -> BR HD (OK)
the second time when I tune to BR HD again, all works...

minisatip.log

[jyrts]

In the last log I do the long test:
I put first channel ZDF neo HD - all works
I put second channel ZDF HD - all works
I put third channel BR HD - no picture
I put fourth channel phoenix HD - all works
I put back third channel BR HD - all works
I put second channel ZDF HD - no picture
I put first channel ZDF neo HD - all works
I put second channel ZDF HD - all works
I put third channel BR HD - no picture

minisatip.log

When I do the 100% same test (same channels, same change order) directly connected to the Xoro 8100 and without minisatip in between - all works

[jyrts]

on freq change old adapter is not freed fast enough, no adapters are available?

get_adapter returns NULL for adapter_id -1

[Jalle19]

@lars18th have you experienced this before (adapter not freed quickly enough)?

[jyrts]

The problem has existed for ages, for years. I'm not talking about the exact error (get_adapter returns NULL for adapter_id -1) because I never looked the log files, but the problem description is the same for years.
I was just lazy - tuned to a channel multiple times, ignoring the software bug.

Maybe nobody else complains because they are not using virtual sat>ip tuners as signal source or it is a specific minisatip <-> Xoro 8100 communication problem.

One little theory Is that when the end-client is using TCP instead of UDP then the problem seems to increase. Every first transponder change fails, but the second is success. Some kind of time-out problem between opening&relasing the adapters...

[Jalle19]

I haven't experienced this myself, so could be that it's specific to the Xoro 8100.

[lars18th]

@lars18th have you experienced this before (adapter not freed quickly enough)?

Hi to all!

From my experience:

• The Xoro implementation is very buggy. I've one Xoro STB and it's (by far) the most complicated to drive using the SAT>IP protocol.
• I'm using minisatip driving several external SAT>IP servers (some are minisatip and some others no). Therefore I use it with a similar environment than @jyrts .
• One problem using multiple external SAT>IP servers is the selection of the correct tuner. For this reason I've created the patch Add adapter restrictions #1117 (that at time it's stalled until I'll have time to update it).
• But more troubles exist: the closing of the external tuner (satipc) is not at time sufficient robust. We need to refactor it.
• The current implementation also can't handle the glitches created by some pid changes with external tuners. For example, with some Xoro devices when you send in less than one 1 second more than one request that it implies a change in the pid list, then the stream will be affected and some TS packets will be lost.
• And more over: for example when the RTSP TCP is closed by the server and the session continues (typical behaviour of the Xoro implementation). Years ago I've created a patch, but it was not accepted.
• And more and more edge-cases not resolved.

I'm sorry but at time I don't have sufficient time to provide a solution.
However, I'll promise to target it in the future. 😉
Regards.

[jyrts]

I have a big dream. I bought total of eight Xoro 8100 satip servers... For 8 different satellite positsions 8 tuner per satellite... Basically 64 tuners in total. Big-big system. :)

But then there was the first problem - most Enigma satip clients (i.e VU+ Zero) have only 2 virtual satip client tuners. So I can ony connect directly to 2 satip server and you can only watch 2 different satellite positions (i.e 13E and 19E)

I found minisatip to act as a proxy: take care of the decoding with oscam and act as a virtual diseqc to get all the 8 different satellite positsions covered (each satellite positsion has his own quattro LNB and own satip server)

Soo far minisatip almost does the job - decoding and virtual disqc work, but channel change is buggy - I have to tune to some channels twice.
When in the channel list channels are on same transponder then no problem... Also when channels are in order where they are each on different satellite positiison then also no problem. But when in channeli list channels are on same satellite but diffrenet frequency... I have to tune twice to get a picture. Soo really this only software bug stops me having my big dream :D

there also seems to be a problem with max tunders minisatip can handle... When I configure 64 tuners, minisatip nevers shows 64 tuners, a lot go missing. Dont know why, but this is not a case for this topic.

[lars18th]

Hi @jyrts ,

God luck with the Xoro 8100 servers if you want to drive 64 tuners. In any case you will need to use Unicable II LNBs (programable for two sat positions). Where have you bought them?

Regarding the limitations of tuners for minisatip, I feel the current limit is 64 but perhaps it's 32. I'll check it in the future.
And in reference to the tuner change, I've similar problems. The main reason is that the satipc module in minisatip is not handling correctly the errors of the remote SAT>IP server. For example, if the request fails it doesn't try to use another device. My first option to overcome (not fully solve) it is to use a Round-Robin selection of the tuners (instead of the current fixed selection based on the order). This will be implemented in the future version of the patch #1117 . However you need to have patience.

Regards.

[Jalle19]

there also seems to be a problem with max tunders minisatip can handle... When I configure 64 tuners, minisatip nevers shows 64 tuners, a lot go missing. Dont know why, but this is not a case for this topic.

This you can open a new issue for, sounds like a bug

[jyrts]

I am using DUR-line +Ultra Quattro LNB's on my Toroidal T90 antenna to feed all my SAT>IP servers.
I can tell the Xoro 8100 SAT>IP server is not bad choice at all - when comparing price vs tuner count (up to 8) it is one of the best buy's at all. They are small, dont get hot, they dont freeze
The only biggest-biggest downside is that you can not run minisatip directly on it - it is not open source :(

Anyway. If you need anybody to test new fixes/relases - I'm all yours! :)

[jyrts]

Made some more testing and it seems this problem is not that Xoro 8100 specific.

By modifying the channel list in the Engima2 client box (stream url from http:// to rtsp:// ) then there is no freq change problem anymore.

The downside is that the video picture in the Enigma2 box then opens a lot slower. But at least no picture freeze when going from channel ZDF HD to BR HD. I hope this info helps

In HTTP mode channel change is under 1 second, but freq change problems occur... In RTSP mode channel change is ~5-10 second but no freq change problem. The slowness is probably caused by the Enigma2 box client itself, soo minisatip has time to free old used adapter...

[Jalle19]

Have you tried using https://github.com/oe-alliance/satip-client instead?

[lars18th]

Hi @jyrts ,

By modifying the channel list in the Engima2 client box (stream url from http:// to rtsp:// ) then there is no freq change problem anymore.

Are you using the HTTP client mode to play? Then your problem is a known bug. I've reported time ago. When more than one client requests a channel over the HTTP protocol in some cases the client doesn't obtains a free tuner. That's in my TODO list.

Another different question is your "delay" when using the RTSP transport. In this case I suspect that your client is using a large buffer. If this is true, then try to reduce the size.

I hope it helps.

[jyrts]

Yes, I am using HTTP client mode to play.

The channelist list on the Enigma2 client looks like:
http://192.168.2.50:8080/?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,6300,6310,6320,6330
http://192.168.2.50:8080/?src=1&freq=11362&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,6100,6110,6120,6130
http://192.168.2.50:8080/?src=1&freq=11583&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5201,5202,5210,5204
http://192.168.2.50:8080/?src=1&freq=11583&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5260,5261,5262

The problem occours when there are two conditions at the same time: 1. the minisatip adapter source is not a local hardware tuner but a remote sat-ip server (xoro 8100) 2. when i change channel and the transponder frequency is not the same as it was on the old channel

Seems I found another temporary solution to this on the Enigma2 client side:
Menu -> Setup -> Usage & GUI -> Customize System Settings -> HTTP stream start delay 0->500ms.

When the delay is 0/10/50/100ms then no good but starting at 500ms and bigger delay - channel change with transponder change works all good. The whole problem has magically disappeared. Seems with 500ms channel change delay minisatip has enough time to free the old remote sati>ip tuner to change freq and use the same tuner again

[catalinii]

I looked at the first log and it looks like this:
[06/11 17:00:32.420]: Got adapter -1 on sid 1 socket 11
[06/11 17:00:32.421]: Reply (handle 10) [192.168.2.50:36014] content_len:0, sock 11
[06/11 17:00:32.429]: select_and_execute[11]: Connection reset by peer on socket 10 (sid:1) from 192.168.2.50:36014 - type http (3) errno 131
[06/11 17:00:32.429]: Requested sid close 1 timeout 30000 type 1, sock 11, handle 10, timeout 0
[06/11 17:00:32.430]: closing stream 1
[06/11 17:00:32.430]: sockets_del: sock 12 -> handle -2, sid 1, overflow bytes 0, total buffered bytes 0
[06/11 17:00:32.430]: sockets_del: sock 12 Last open socket is at index 12 current_handle -2
[06/11 17:00:32.431]: closed stream 1
[06/11 17:00:32.431]: sockets_del: sock 11 -> handle 10, sid 1, overflow bytes 0, total buffered bytes 0
[06/11 17:00:32.431]: sockets_del: sock 11 Last open socket is at index 11 current_handle 10
[06/11 17:00:32.431]: Delete socket 11 done: sid -1
[06/11 17:00:32.615]: writev returned -1 handle 5, iiov 1 errno 131 error Connection reset by peer
[06/11 17:00:32.616]: select_and_execute[5]: Close on socket 5 (sid:0) from 192.168.2.50:36011 - type http (3) errno 0
[06/11 17:00:32.617]: Requested sid close 0 timeout 30000 type 1, sock 5, handle 5, timeout 0
[06/11 17:00:32.617]: closing stream 0

This shows that the stream 0 (which uses the adapter 0) is closed AFTER the new stream is requested.

As a result minisatip cannot assign the adapter to the new request.

One option is to use a new client (like the satip client in enigma)

[lars18th]

Hi @jyrts and @catalinii ,

I've done some review of the logs shared by @jyrts (as I've been having some problems with channel switching using HTTP clients for a long time now), but I need to say that @catalinii have the reason:

This shows that the stream 0 (which uses the adapter 0) is closed AFTER the new stream is requested.

I copy another time some part of the LOG:

[06/11 17:02:32.880]: Read RTSP (sock 11, handle 10) [192.168.2.50:36022] sid -1, len: 239
[06/11 17:02:32.881]: detect_dvb_parameters (S)-> src=1&freq=11583&pol=h&ro=0.35&msys=dvbs2&mtype=8psk&plts=on&sr=22000&fec=23&pids=0,17,18,5201,5202,5210,5204
[06/11 17:02:32.881]: detect_dvb_parameters (E) -> src=1, fe=0, freq=11583000, fec=2, sr=22000000, pol=2, ro=0, msys=6, mtype=9, plts=0, bw=8000000, inv=2, pids=0,17,18,5201,5202,5210,5204 - apids=NULL - dpids=NULL x_pmt=NULL
[06/11 17:02:32.881]: Setup stream sid -1 parameters, sock_id 11, handle 10
[06/11 17:02:32.881]: stream.c:188 get_sid returns NULL for s_id = -1
[06/11 17:02:32.881]: set_sock_lock: sock_id 11 locks also mutex 0x49cd20
[06/11 17:02:32.882]: sockets_add: handle -2 (type 0) returning socket sock 12 [:0] read: 0x3ca48
[06/11 17:02:32.883]: set_sock_lock: sock_id 12 locks also mutex 0x49cd20
[06/11 17:02:32.883]: Setup stream done: sid 1 for sock 11 handle 10
[06/11 17:02:32.883]: copy_dvb_param start -> src=0, fe=0, freq=0, fec=9, sr=0, pol=0, ro=3, msys=0, mtype=6, plts=2, bw=8000000, inv=2, pids=NULL, apids=NULL, dpids=NULL x_pmt=NULL
[06/11 17:02:32.884]: copy_dvb_parameters -> src=1, fe=0, freq=11583000, fec=2 sr=22000000, pol=2, ro=0, msys=6, mtype=9, plts=0, bw=8000000, inv=2, pids=0,17,18,5201,5202,5210,5204, apids=NULL, dpids=NULL x_pmt=NULL
[06/11 17:02:32.884]: Play for stream sid 1, type 1, rsock 10, adapter -1, sock_id 11, rsock_id 11, handle 10
[06/11 17:02:32.884]: stream.c:262: get_adapter returns NULL for adapter_id -1
[06/11 17:02:32.884]: adapter.c:1222: get_adapter returns NULL for adapter_id -1
[06/11 17:02:32.885]: stream.c:271: get_adapter returns NULL for adapter_id -1
[06/11 17:02:32.885]: get _free adapter 0 - a[0] => e:1 m:0 sid_cnt:1 src:1 f:11362000 pol=2 sys: dvbs2 dvbs
[06/11 17:02:32.885]: Dumping adapters:
[06/11 17:02:32.885]: 0|f: 11362000 sid_cnt:1 master_sid:0 master_source:-1 del_sys: dvbs2,dvbs,undefined 
[06/11 17:02:32.885]: Dumping streams:
[06/11 17:02:32.886]: 0|  a:0 rsock:5 type:1 play:1 remote:192.168.2.50:36019
[06/11 17:02:32.886]: 1|  a:-1 rsock:10 type:1 play:0 remote:192.168.2.50:36022
[06/11 17:02:32.886]: delsys_match: adapter is NULL, delsys 6
Message repeated 62 times
[06/11 17:02:32.892]: no adapter found for src:1 f:11583000 pol:2 msys:6
[06/11 17:02:32.892]: Dumping adapters:
[06/11 17:02:32.892]: 0|f: 11362000 sid_cnt:1 master_sid:0 master_source:-1 del_sys: dvbs2,dvbs,undefined 
[06/11 17:02:32.893]: Dumping streams:
[06/11 17:02:32.893]: 0|  a:0 rsock:5 type:1 play:1 remote:192.168.2.50:36019
[06/11 17:02:32.893]: 1|  a:-1 rsock:10 type:1 play:0 remote:192.168.2.50:36022
[06/11 17:02:32.894]: Got adapter -1 on sid 1 socket 11
[06/11 17:02:32.894]: Reply (handle 10) [192.168.2.50:36022] content_len:0, sock 11
[06/11 17:02:32.902]: select_and_execute[11]: Connection reset by peer on socket 10 (sid:1) from 192.168.2.50:36022 - type http (3) errno 131
[06/11 17:02:32.903]: Requested sid close 1 timeout 30000 type 1, sock 11, handle 10, timeout 0
[06/11 17:02:32.903]: closing stream 1
[06/11 17:02:32.903]: sockets_del: sock 12 -> handle -2, sid 1, overflow bytes 0, total buffered bytes 0
[06/11 17:02:32.903]: sockets_del: sock 12 Last open socket is at index 12 current_handle -2
[06/11 17:02:32.904]: closed stream 1
[06/11 17:02:32.904]: sockets_del: sock 11 -> handle 10, sid 1, overflow bytes 0, total buffered bytes 0
[06/11 17:02:32.904]: sockets_del: sock 11 Last open socket is at index 11 current_handle 10
[06/11 17:02:32.905]: Delete socket 11 done: sid -1
[06/11 17:02:33.085]: writev returned -1 handle 5, iiov 1 errno 131 error Connection reset by peer
[06/11 17:02:33.086]: select_and_execute[5]: Close on socket 5 (sid:0) from 192.168.2.50:36019 - type http (3) errno 0
[06/11 17:02:33.086]: Requested sid close 0 timeout 30000 type 1, sock 5, handle 5, timeout 0
[06/11 17:02:33.087]: closing stream 0
[06/11 17:02:33.087]: sockets_del: sock 6 -> handle -2, sid 0, overflow bytes 0, total buffered bytes 0
[06/11 17:02:33.087]: sockets_del: sock 6 Last open socket is at index 10 current_handle -2
[06/11 17:02:33.087]: adapter.c:834 get_sid returns NULL for s_id = 0

What you can see here is that minisatip is streaming (over HTTP) the channel ZFD HD in the frequency 11362000 (stream 0). And then a NEW HTTP request calls for the channel BR HD in the frequency 11583000 (stream 1). But the problem is that the stream 0 (the current streaming) is NOT closed before the new request. Therefore, as @catalinii indicates it's impossible that the tuner will be free for the second call. In this case the problem is the CLIENT that makes new requests before closing the previous one.

However, perhaps some workaround can be implemented... if @catalinii will agree with that. From my point of view the HTTP client functionality is a must-have of minisatip. And we can provide some smart streaming to it. For example, we can control if the same client (based on IP or user-agent or a cookie) makes multiple requests. In this case we can cancel previous streamings and serve a new request.

What you think about that, @catalinii ? Too much effort for nothing?

[Jalle19]

I'm categorically against hacks for broken clients

[catalinii]

Yeah I agree with @Jalle19 here. If we do it that way we will get to the point that a fix for a broken client will break another broken client fix.

We can maybe dig into enigma cliebt implementation to see why is done, but one reason could be that the existing channel (ZDF) is stopped only when the new channel can be played.

Of course the other solution is to have 2 or more adapters with unicable

[jyrts]

Help me out here... Why are you talking about broken client and why the 500ms delay between channel changes on the client side fixes the whole problem here?

I can make a new test, by adding more adapters to minisatip.
Instead:
/usr/bin/minisatip -f -o 192.168.2.50:9000 --disable-dvb --disable-ssdp -s 192.168.2.24
I run:
/usr/bin/minisatip -f -o 192.168.2.50:9000 --disable-dvb --disable-ssdp -s 192.168.2.24 -s 192.168.2.24

and try what happens. The Xoro 8100 has 8 tuners I can use with no problem (when using directly without minisatip)

[lars18th]

Hi @catalinii ,

The idea is not to provide workarounds for broken clients. If a client requests a new channel before closing the previous, the only reason (that it has sense) is because the client it's assuming that more than one tuner exist and then it wants to provide a fast channel change. This is a common behaviour of clients using IPTV servers. And this works because all the channels are available at the same time. However, when using real tuners this is false. And therefore it's mandatory to close (aka free) any channel before requesting another one.

From my experience, good HTTP clients provide a method to configure if you want to use concurrent channel requests (good for IPTV) or not (for TUNERS). And then I suggest to @jyrts to try to configure in this way if the client support it.

However, my idea is to provide a convenient behaviour to auto-close channels. The reason it's because using the HTTP interface the user doesn't have any information about the number of tuners. And then it can't open multiple channels smartly, bucause it doesn't knows if tuners are shared and the number of them. So, my suggestion it's about a SMART method. However, perhaps it's preferable to not add the complexity of it.

Regards.

[lars18th]

Hi @jyrts ,

Help me out here... Why are you talking about broken client and why the 500ms delay between channel changes on the client side fixes the whole problem here?

and try what happens. The Xoro 8100 has 8 tuners I can use with no problem (when using directly without minisatip)

As I've commented the problem is because your client is requesting more than one channel at the same time. If you configure minisatip with multiple tuners, then one tuner could be unused when the client requests the next channel. And then your problem will be solved. However, it's preferable to configure your client to not do "fast channel tunning". This will definitively solve the issue.

Regards.

[jyrts]

This bug may be a bit related to: "BUG: Not free adapters when fast changes #813"

I have been using temporary fix for a long time now.
In Engima2 settings I have "HTTP stream start delay" set to 500ms and it does the trick. All channel changes work

[jyrts]

I think we can close this issue.
There are two temporary fixes a) on the client side add channel change delay 500ms b) add more tuners to minisatip server.

Both fixes work.