search

catalinii / minisatip

minisatip is an SATIP server for linux using local DVB-S2, DVB-C, DVB-T or ATSC cards
https://minisatip.org
327 stars 82 forks source link

Multiple Unicable systems / virtual diseqc (-A) and unicable (-u) ? #1174

Open mark-royds opened 2 months ago

mark-royds commented 2 months ago

I am having difficulty finding the correct configuration to support an environment with 2 separate unicable LNBs.

I'm using a Digibit R1 (idl4k) device that has 4 physical inputs (numbered 0 - 3), 4 frontend tuners (0 - 3), and an internal switch that allows any input to be routed to any tuner.

With only had a single LNB connected, everything works well. Physical input 0 connected to a Unicable LNB pointing at constellation A. I used "--unicable 0:0-1210,1:1-1420,2:2-1680,3:3-2040" to start minisatip and as expected, a tuning request for any FE is routed to the LNB on port 0.

I now want to add a second constellation: Physical input 3 connected to a Unicable LNB pointing at constellation B. The Unicable user bands/frequencies for the 2nd LNB are the same as those used on input 0.

What is the correct configuration to support the the above topology?

"-A 0:0:0,1:3:0" doesn't seem to work as expected - tune requests for constellation B (src=2) are still routed to input 0.

The closest I've been able to get is by adding "-S 3:3". This forces frontend 3 to use input 3. However, this means FE3 always uses input 3 and prevents access to input 0 - requests for fe=4&src=1 are still routed to input 3.

The results of all my testing are as follows:

config request result -A 0:0:0,1:3:0 fe=1&src=1 OK - FE0 connected to input 0 -A 0:0:0,1:3:0 fe=4&src=1 OK - FE3 connected to input 0 -A 0:0:0,1:3:0 fe=1&src=2 FAIL - FE0 connected to input 0 -A 0:0:0,1:3:0 fe=4&src=2 FAIL - FE3 connected to input 0 -S 3:3 fe=1&src=1 OK - FE0 connected to input 0 -S 3:3 fe=4&src=1 FAIL - FE3 connected to input 3 -S 3:3 fe=1&src=2 FAIL - FE0 connected to input 0 -S 3:3 fe=4&src=2 OK - FE3 connected to input 3

Testing was carried out with version 1.2.1 and 1.3.23 with identical results.

This seems to be an issue specific to Unicable and Jess. If eliminate the unicable configuration and fall back to legacy tuning, the above tests all pass. Of course, legacy tuning is only 25% useful with a single cable drop from each LNB as in this case.

Jalle19 commented 2 months ago

I've resorted to using -S myself, even though it's not optimal. I think what you're describing isn't possible with the current code, even though the hardware should support it.

You could try ancient builds of perexg/satip-axe to see if you find a version where everything works, then we could work from there to get the changes incorporated into master again.

mark-royds commented 2 months ago

I don't think even the perexg builds do quite what I'm asking for.

The dist/minisatip.md file included in the perexg build mentions an "-X / -9" option that deals with multiple Unicable groups but that appears to effectively partition the device into two or more groups.

Multiple unicable groups

You may connect multiple unicable LNBs through multiple coaxial wires to the box. In this case, it is necessary to tell which tuners will use which physical input. In this case '-9 T1,T2,T3,T4 / '-X T1,T2,T3,T4' option should be used wheren you can define the parent inputs for all four tuners like: '-9 0,0,2,2' or '-X 0,0,2,2' where two unicable groups are connected to minisatip input 0 and 2.

box input 0 ---+--- wire 1 (unicable group 1) box input 1 ---/

box input 2 ---+--- wire 2 (unicable group 2) box input 3 ---/

My reading of the above is that tuners 0 and 1 will be constrained to input 0, and tuners 2 and 3 will be constrained to input 2.

In any case, the perexg patches that enable the above functionality were introduced in build 11 which so far as I can tell (I'm not a git expert) had the patch files stored in an external filesharing service that is no longer operational. The first commit in the perexg git looks like build 15, by which time the minisatip changes to support Unicable grouping have been removed. Perhaps someone with better git skills than me can dig out the relevent patches.

Thinking about this a bit more, a new implementation should take into account situations where the two separate Unicable systems need to use different user bands. I shall ponder for a bit and see if I can come up with a sensible design / configuration syntax. It feels like it could get very complicated.

mark-royds commented 2 months ago

In any case, the perexg patches that enable the above functionality were introduced in build 11 which so far as I can tell (I'm not a git expert) had the patch files stored in an external filesharing service that is no longer operational. The first commit in the perexg git looks like build 15, by which time the minisatip changes to support Unicable grouping have been removed. Perhaps someone with better git skills than me can dig out the relevent patches.

Actually, scratch what I said there. A bit more learning of git and I came up with this: https://github.com/perexg/satip-axe/tree/572269b Build 11, which includes the "-X" patch

lars18th commented 2 months ago

Hi @mark-royds ,

I hope you could fix your problem, as I've the idea of moving my current infrastructure to unicable with mutiple sat positions. And I feel your problem needs to be fixed.

But in any case, I suggest a more complex alternative: put DiseqC 1.0 switchess before the unicable cables. Then instead of two tuners fixed for each sat position, you'll have the option of using each tuner with the two satelital positions. That's my idea:

                  /-- LNB Unicable A
Tuner A --> DiseqC 
                  \-- LNB Unicable B

                  /-- LNB Unicable A
Tuner B --> DiseqC 
                  \-- LNB Unicable B

                  /-- LNB Unicable A
Tuner C --> DiseqC 
                  \-- LNB Unicable B

                  /-- LNB Unicable A
Tuner D --> DiseqC 
                  \-- LNB Unicable B

This requires two wires for each LNB, and four new small switches. Easy to add. But then minisatip requires to process first the command to change the DiseqC swith and after send the Unicable command. What you think about this?

lars18th commented 2 months ago

Hi @mark-royds ,

The results of all my testing are as follows: [...]

After reading with more detail your description, I recommend to first do the test with only 2 tuners: 0 and 1, each connected to one wire.

After that check this please: --unicable 0:0-1210,1:1-1420,2:2-1680,3:3-2040 -A 0:0:0,1:1:1. And then request only using the src parameter without any fe entry. The command -A is not compatible with fe. With this config the Tuner A (fe=0) will use the slot 0 with freq 1210, and the Tuner B (fe=1) will use the slot 1 with freq 1420. But when minisatip receives the src=1 it will use only the Tuner A connected with the wire A. And using the src=2 it will use only the Tuner B connected to the wire B. Therefore the two sat positions will be reached independently and you can fully tune to them.

So if this test will complete, then we can try to add the other two tuners. But for this, before configure internally the AXE device, I'll recommend to use a single wire spplit to connect two tuners to the same wire. It will be more easy to isolate the problems.

Please inform us with your new results. Regards.

mark-royds commented 2 months ago

Hi @lars18th Thanks for the suggestion.

I've just tried the solution you proposed. Unfortunately, ommitting the fe= from the request doesn't solve the problem. You can see below that the results are quite odd with the src=2 parameter resulting in FE3 being selected where I would hope to see FE0 selected and routed to input 3.

Results config request result -A 0:0:0,1:3:0 src=1 OK - FE0 connected to input 0 -A 0:0:0,1:3:0 src=2 FAIL - FE3 connected to input 0

Some logs of minisatip startup:

[29/08 15:26:31.099]: Set default timeout to 0
[29/08 15:26:31.103]: Setting unicable adapter 0 slot 0 freq 1210 pin -1
[29/08 15:26:31.104]: Setting unicable adapter 1 slot 1 freq 1420 pin -1
[29/08 15:26:31.106]: Setting unicable adapter 2 slot 2 freq 1680 pin -1
[29/08 15:26:31.108]: Setting unicable adapter 3 slot 3 freq 2040 pin -1
[29/08 15:26:31.108]: Setting source 0 (src=1) to adapter 0 position 0
[29/08 15:26:31.108]: Setting source 1 (src=2) to adapter 3 position 0
[29/08 15:26:31.109]: minisatip.c:1096 allocation_wrapper malloc allocated 50 bytes at 0x48c480
[29/08 15:26:31.109]: minisatip.c:1100 allocation_wrapper malloc allocated 50 bytes at 0x48c400
[29/08 15:26:31.110]: minisatip.c:1103 allocation_wrapper malloc allocated 64 bytes at 0x48c438
[29/08 15:26:31.110]: minisatip.c:1109 allocation_wrapper malloc allocated 32 bytes at 0x48c4b8
[29/08 15:26:31.110]: minisatip.c:1114 allocation_wrapper malloc allocated 32 bytes at 0x48c4e0
[29/08 15:26:31.110]: minisatip.c:1116 allocation_wrapper malloc allocated 32 bytes at 0x48c508
[29/08 15:26:31.111]: minisatip version 1.2.12, compiled in Aug  6 2023 11:00:41, with s2api version: 0501
[29/08 15:26:31.111]: Built with dvbcsa
[29/08 15:26:31.111]: Built without CI
[29/08 15:26:31.111]: Built with dvbapi
[29/08 15:26:31.111]: Built with tables processing
[29/08 15:26:31.111]: Built with pmt processing
[29/08 15:26:31.111]: Built with satip client
[29/08 15:26:31.112]: Built with linux dvb client
[29/08 15:26:31.112]: Built with backtrace
[29/08 15:26:31.112]: Built without netceiver
[29/08 15:26:31.112]: Built without ddci
[29/08 15:26:31.112]: Built without t2mi
[29/08 15:26:31.112]: Built for satip-axe
[29/08 15:26:31.112]:  LOG  of the module enabled: general
[29/08 15:26:31.112]: DEBUG of the module enabled: general
[29/08 15:26:31.112]:  LOG  of the module enabled: http
[29/08 15:26:31.112]: DEBUG of the module enabled: http
[29/08 15:26:31.112]:  LOG  of the module enabled: socketworks
[29/08 15:26:31.113]: DEBUG of the module enabled: socketworks
[29/08 15:26:31.113]:  LOG  of the module enabled: stream
[29/08 15:26:31.113]: DEBUG of the module enabled: stream
[29/08 15:26:31.113]:  LOG  of the module enabled: adapter
[29/08 15:26:31.113]: DEBUG of the module enabled: adapter
[29/08 15:26:31.113]:  LOG  of the module enabled: satipc
[29/08 15:26:31.113]: DEBUG of the module enabled: satipc
[29/08 15:26:31.113]:  LOG  of the module enabled: pmt
[29/08 15:26:31.114]: DEBUG of the module enabled: pmt
[29/08 15:26:31.114]:  LOG  of the module enabled: tables
[29/08 15:26:31.114]: DEBUG of the module enabled: tables
[29/08 15:26:31.114]:  LOG  of the module enabled: dvbapi
[29/08 15:26:31.114]: DEBUG of the module enabled: dvbapi
[29/08 15:26:31.114]:  LOG  of the module enabled: lock
[29/08 15:26:31.114]: DEBUG of the module enabled: lock
[29/08 15:26:31.114]:  LOG  of the module enabled: netceiver
[29/08 15:26:31.114]: DEBUG of the module enabled: netceiver
[29/08 15:26:31.114]:  LOG  of the module enabled: ca
[29/08 15:26:31.114]: DEBUG of the module enabled: ca
[29/08 15:26:31.115]:  LOG  of the module enabled: axe
[29/08 15:26:31.115]: DEBUG of the module enabled: axe
[29/08 15:26:31.115]:  LOG  of the module enabled: socket
[29/08 15:26:31.115]: DEBUG of the module enabled: socket
[29/08 15:26:31.115]:  LOG  of the module enabled: utils
[29/08 15:26:31.115]: DEBUG of the module enabled: utils
[29/08 15:26:31.115]:  LOG  of the module enabled: dmx
[29/08 15:26:31.115]: DEBUG of the module enabled: dmx
[29/08 15:26:31.115]:  LOG  of the module enabled: dvb
[29/08 15:26:31.116]: DEBUG of the module enabled: dvb
[29/08 15:26:31.117]: New TCP listening socket 3 at 0:0:0:0:554, family 2
[29/08 15:26:31.117]: New TCP listening socket 4 at 0:0:0:0:8080, family 2
[29/08 15:26:31.117]: New UDP socket 5 bound to 0.0.0.0:1900
[29/08 15:26:31.118]: setting multicast for 239.255.255.250
[29/08 15:26:31.118]: New UDP socket 6 bound to 239.255.255.250:1900 (mcast:239.255.255.250)
[29/08 15:26:31.119]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48c530
[29/08 15:26:31.119]: sockets_add: handle 5 (type 0) returning socket sock 0 [:0] read: 0x409738
[29/08 15:26:31.119]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48c648
[29/08 15:26:31.119]: sockets_add: handle 6 (type 0) returning socket sock 1 [:0] read: 0x409738
[29/08 15:26:31.119]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48c760
[29/08 15:26:31.119]: sockets_add: handle 3 (type 2) returning socket sock 2 [:0] read: 0x40bbec
[29/08 15:26:31.119]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48c878
[29/08 15:26:31.120]: sockets_add: handle 4 (type 2) returning socket sock 3 [:0] read: 0x40bbec
[29/08 15:26:31.120]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48c990
[29/08 15:26:31.121]: sockets_add: handle -2 (type 0) returning socket sock 4 [:0] read: 0x409738
[29/08 15:26:31.121]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48caa8
[29/08 15:26:31.121]: sockets_add: handle -2 (type 0) returning socket sock 5 [:0] read: 0x409738
[29/08 15:26:31.121]: set_socket_thread: thread 296e4210 for sockets 5
[29/08 15:26:31.122]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48cbc0
[29/08 15:26:31.122]: sockets_add: handle -2 (type 0) returning socket sock 6 [:0] read: 0x409738
[29/08 15:26:31.122]: starting init_all_hw 0
[29/08 15:26:31.337]: testing device /dev/axe/frontend-0 -> fd: 8
[29/08 15:26:31.339]: testing device /dev/axe/frontend-1 -> fd: 8
[29/08 15:26:31.341]: testing device /dev/axe/frontend-2 -> fd: 8
[29/08 15:26:31.343]: testing device /dev/axe/frontend-3 -> fd: 8
[29/08 15:26:31.343]: trying to open [0] adapter 0 and frontend 0
[29/08 15:26:31.349]: opened DVB adapter 0 fe:8 dvr:9
[29/08 15:26:31.349]: deleting pids on adapter 0, sid -1, pids=NULL
[29/08 15:26:31.350]: Delivery System DVB-S/DVB-S2 (AXE)
[29/08 15:26:31.350]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48ccd8
[29/08 15:26:31.350]: sockets_add: handle 9 (type 5) returning socket sock 7 [:0] read: 0x4096b0
[29/08 15:26:31.351]: set_socket_thread: thread 296e4210 for sockets 7
[29/08 15:26:31.351]: done opening adapter 0 delivery systems: dvbs dvbs2 undefined undefined
[29/08 15:26:31.351]: FE 1 mapped to Adapter 0, sys dvbs2
[29/08 15:26:31.351]: trying to open [1] adapter 1 and frontend 0
[29/08 15:26:31.355]: opened DVB adapter 1 fe:10 dvr:11
[29/08 15:26:31.356]: deleting pids on adapter 1, sid -1, pids=NULL
[29/08 15:26:31.356]: Delivery System DVB-S/DVB-S2 (AXE)
[29/08 15:26:31.356]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48cdf0
[29/08 15:26:31.357]: sockets_add: handle 11 (type 5) returning socket sock 8 [:0] read: 0x4096b0
[29/08 15:26:31.357]: set_socket_thread: thread 296e4210 for sockets 8
[29/08 15:26:31.357]: done opening adapter 1 delivery systems: dvbs dvbs2 undefined undefined
[29/08 15:26:31.358]: FE 1 mapped to Adapter 0, sys dvbs2
[29/08 15:26:31.358]: FE 2 mapped to Adapter 1, sys dvbs2
[29/08 15:26:31.358]: trying to open [2] adapter 2 and frontend 0
[29/08 15:26:31.362]: opened DVB adapter 2 fe:12 dvr:13
[29/08 15:26:31.363]: deleting pids on adapter 2, sid -1, pids=NULL
[29/08 15:26:31.363]: Delivery System DVB-S/DVB-S2 (AXE)
[29/08 15:26:31.363]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48cf08
[29/08 15:26:31.363]: sockets_add: handle 13 (type 5) returning socket sock 9 [:0] read: 0x4096b0
[29/08 15:26:31.364]: set_socket_thread: thread 296e4210 for sockets 9
[29/08 15:26:31.364]: done opening adapter 2 delivery systems: dvbs dvbs2 undefined undefined
[29/08 15:26:31.364]: FE 1 mapped to Adapter 0, sys dvbs2
[29/08 15:26:31.364]: FE 2 mapped to Adapter 1, sys dvbs2
[29/08 15:26:31.364]: FE 3 mapped to Adapter 2, sys dvbs2
[29/08 15:26:31.364]: trying to open [3] adapter 3 and frontend 0
[29/08 15:26:31.369]: opened DVB adapter 3 fe:14 dvr:15
[29/08 15:26:31.369]: deleting pids on adapter 3, sid -1, pids=NULL
[29/08 15:26:31.369]: Delivery System DVB-S/DVB-S2 (AXE)
[29/08 15:26:31.369]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48d020
[29/08 15:26:31.369]: sockets_add: handle 15 (type 5) returning socket sock 10 [:0] read: 0x4096b0
[29/08 15:26:31.370]: set_socket_thread: thread 296e4210 for sockets 10
[29/08 15:26:31.370]: done opening adapter 3 delivery systems: dvbs dvbs2 undefined undefined
[29/08 15:26:31.371]: FE 1 mapped to Adapter 0, sys dvbs2
[29/08 15:26:31.371]: FE 2 mapped to Adapter 1, sys dvbs2
[29/08 15:26:31.371]: FE 3 mapped to Adapter 2, sys dvbs2
[29/08 15:26:31.371]: FE 4 mapped to Adapter 3, sys dvbs2
[29/08 15:26:31.371]: done init_hw 1
[29/08 15:26:31.371]: Initializing with 4 devices

The first part of the logs for a tune request with src=2:

[29/08 15:26:36.243]: MSG client >> process :
GET /?src=2&pol=H&freq=12304&msys=DVBS2&mtype=qpsk&sr=27500&pids=0,1,16,17 HTTP/1.1
Host: 10.150.213.101:8080
User-Agent: curl/7.74.0
Accept: */*

[29/08 15:26:36.244]: detect_dvb_parameters (S)-> src=2&pol=H&freq=12304&msys=DVBS2&mtype=qpsk&sr=27500&pids=0,1,16,17
[29/08 15:26:36.244]: detect_dvb_parameters (E) -> src=2, fe=0, freq=12304000, fec=9, sr=27500000, pol=2, ro=3, msys=6, mtype=0, plts=2, bw=8000000, inv=2, pids=0,1,16,17 - apids=NULL - dpids=NULL x_pmt=NULL
[29/08 15:26:36.244]: Setup stream sid -1 parameters, sock_id 11, handle 16
[29/08 15:26:36.244]: stream.c:189 get_sid returns NULL for s_id = -1
[29/08 15:26:36.245]: utils.c:1397 allocation_wrapper malloc allocated 2980 bytes at 0x48d250
[29/08 15:26:36.245]: set_sock_lock: sock_id 11 locks also mutex 0x48d254
[29/08 15:26:36.245]: utils.c:1397 allocation_wrapper malloc allocated 276 bytes at 0x48ddf8
[29/08 15:26:36.245]: sockets_add: handle -2 (type 0) returning socket sock 12 [:0] read: 0x409738
[29/08 15:26:36.245]: set_sock_lock: sock_id 12 locks also mutex 0x48d254
[29/08 15:26:36.245]: Setup stream done: sid 0 for sock 11 handle 16
[29/08 15:26:36.246]: 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
[29/08 15:26:36.246]: copy_dvb_parameters -> src=2, fe=0, freq=12304000, fec=9 sr=27500000, pol=2, ro=3, msys=6, mtype=0, plts=2, bw=8000000, inv=2, pids=0,1,16,17, apids=NULL, dpids=NULL x_pmt=NULL
[29/08 15:26:36.246]: Updating sid 0 time to 5124, current time 5127
[29/08 15:26:36.246]: Play for stream sid 0, type 1, rsock 16, adapter -1, sock_id 11, rsock_id 11, handle 16
[29/08 15:26:36.247]: stream.c:263: get_adapter returns NULL for adapter_id -1
[29/08 15:26:36.247]: adapter.c:1196: get_adapter returns NULL for adapter_id -1
[29/08 15:26:36.247]: stream.c:272: get_adapter returns NULL for adapter_id -1
[29/08 15:26:36.247]: get free adapter 0 - a[0] => e:1 m:-1 sid_cnt:0 src:0 f:0 pol=0 sys: dvbs dvbs2
[29/08 15:26:36.247]: Dumping adapters:
[29/08 15:26:36.247]: 0|f: 0 sid_cnt:0 master_sid:-1 master_source:-1 del_sys: dvbs,dvbs2,undefined  Sources Table: 0->1,
[29/08 15:26:36.247]: 1|f: 0 sid_cnt:0 master_sid:-1 master_source:-1 del_sys: dvbs,dvbs2,undefined  Sources Table:
[29/08 15:26:36.247]: 2|f: 0 sid_cnt:0 master_sid:-1 master_source:-1 del_sys: dvbs,dvbs2,undefined  Sources Table:
[29/08 15:26:36.248]: 3|f: 0 sid_cnt:0 master_sid:-1 master_source:-1 del_sys: dvbs,dvbs2,undefined  Sources Table: 1->1,
[29/08 15:26:36.248]: Dumping streams:
[29/08 15:26:36.248]: 0|  a:-1 rsock:16 type:1 play:0 remote:10.150.213.8:36098
[29/08 15:26:36.248]: new parameters: f:12304000, plp/isi:-1, diseqc:2, pol:2, sr:27500000, mtype:0
[29/08 15:26:36.248]: old parameters: f:0, plp/isi:-1, diseqc:0, pol:0, sr:0, mtype:6
[29/08 15:26:36.248]: Got adapter 3 on sid 0 socket 11
[29/08 15:26:36.249]: set adapter 3 for sid 0 m:0 s:1
[29/08 15:26:36.249]: setting DVB parameters for adapter 3 - master_sid 0 sid 0 old f:0
[29/08 15:26:36.249]: new parameters: f:12304000, plp/isi:-1, diseqc:2, pol:2, sr:27500000, mtype:0
[29/08 15:26:36.249]: old parameters: f:0, plp/isi:-1, diseqc:0, pol:0, sr:0, mtype:6
[29/08 15:26:36.249]: deleting pids on adapter 3, sid -1, pids=NULL
[29/08 15:26:36.250]: 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
[29/08 15:26:36.250]: copy_dvb_parameters -> src=2, fe=0, freq=12304000, fec=9 sr=27500000, pol=2, ro=3, msys=6, mtype=0, plts=2, bw=8000000, inv=2, pids=0,1,16,17, apids=NULL, dpids=NULL x_pmt=NULL
[29/08 15:26:36.250]: Mapping adapter 3 src 2 to src 1
[29/08 15:26:36.250]: deleting pids on adapter 3, sid 0, pids=NULL
[29/08 15:26:36.250]: adding pids to adapter 3, sid 0, pids=0,1,16,17
[29/08 15:26:36.250]: Dumping pids table for adapter 3, number of unknown pids: 0
[29/08 15:26:36.250]: pid 0, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.250]: pid 1, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.251]: pid 16, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.251]: pid 17, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.252]: adapter 0: using source 0, fe 8 fe2 8
[29/08 15:26:36.253]: send_unicable fd 8, freq 1704, ufreq 2040, pos = 0, pol = 1, hiband = 1, slot 3, pin -1, diseqc => e0 10 5a 6e 4a
[29/08 15:26:36.433]: axe_fe: used[0] = 0x8, pol=1, hiband=1, diseqc=0
[29/08 15:26:36.433]: axe_fe: used[1] = 0x0, pol=-1, hiband=-1, diseqc=-1
[29/08 15:26:36.433]: axe_fe: used[2] = 0x0, pol=-1, hiband=-1, diseqc=-1
[29/08 15:26:36.433]: axe_fe: used[3] = 0x0, pol=-1, hiband=-1, diseqc=-1
[29/08 15:26:36.433]: axe_fe: reset for fd 14 adapter 0 input 0 diseqc 0
[29/08 15:26:36.434]: tuning to 12304000(2040000) pol: h (2) sr:27500000 fec:  delsys:dvbs2 mod:qpsk rolloff:auto pilot:auto, ts clear=5134, ts pol=5134 sequence_index = -1
[29/08 15:26:36.434]: axe: isi -1 pls -1 mode -1
[29/08 15:26:36.442]: utils.c:1397 allocation_wrapper malloc allocated 4144 bytes at 0x48df10
[29/08 15:26:36.443]: new filter 0 added for adapter 3, pid 0, flags 20, mask_len 0, master_filter 0
[29/08 15:26:36.443]: utils.c:1397 allocation_wrapper malloc allocated 4144 bytes at 0x48ef48
[29/08 15:26:36.443]: new filter 1 added for adapter 3, pid 17, flags 20, mask_len 0, master_filter 1
[29/08 15:26:36.443]: found filter 0 for pid 0, master 0 (2)
[29/08 15:26:36.444]: get_master_pmt_for_pid: no pmt found for pid 0 adapter 3
[29/08 15:26:36.444]: PMT -1 not found when adding pid 0 on adapter 3
[29/08 15:26:36.444]: get_master_pmt_for_pid: no pmt found for pid 1 adapter 3
[29/08 15:26:36.444]: PMT -1 not found when adding pid 1 on adapter 3
[29/08 15:26:36.444]: get_master_pmt_for_pid: no pmt found for pid 16 adapter 3
[29/08 15:26:36.444]: PMT -1 not found when adding pid 16 on adapter 3
[29/08 15:26:36.445]: found filter 1 for pid 17, master 1 (2)
[29/08 15:26:36.445]: get_master_pmt_for_pid: no pmt found for pid 17 adapter 3
[29/08 15:26:36.445]: PMT -1 not found when adding pid 17 on adapter 3
[29/08 15:26:36.445]: Dumping pids table for adapter 3, number of unknown pids: 0
[29/08 15:26:36.445]: pid 0, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter 0, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.445]: pid 1, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.445]: pid 16, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.445]: pid 17, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter 1, sock -1, sids: 0 -1 -1 -1 -1 -1 -1 -1
[29/08 15:26:36.447]: setting filter on PID 0 for ADAPTER 3
[29/08 15:26:36.448]: setting filter on PID 1 for ADAPTER 3
[29/08 15:26:36.450]: setting filter on PID 16 for ADAPTER 3
[29/08 15:26:36.452]: setting filter on PID 17 for ADAPTER 3

In the logs you can see send_unicable fd 8, freq 1704, ufreq 2040, pos = 0, pol = 1, hiband = 1, slot 3, pin -1, diseqc => e0 10 5a 6e 4a

So minisatip is using the 4th slot defined in the --unicable parameter.

mark-royds commented 2 months ago

But in any case, I suggest a more complex alternative: put DiseqC 1.0 switchess before the unicable cables. Then instead of two tuners fixed for each sat position, you'll have the option of using each tuner with the two satelital positions. That's my idea:

This would require the purchase of (4) switches and (2) 4-way splitters (I only have one cable available from each LNB).

What you think about this?

Unicable/Jess is also using DiSEqC to command the LNB. Is that an issue? Hopefully an array of external splitters and switches is unnecessary and we can leverage the ones that are built in to the receiver hardware already.

lars18th commented 2 months ago

This would require the purchase of (4) switches and (2) 4-way splitters (I only have one cable available from each LNB).

Hopefully an array of external splitters and switches is unnecessary and we can leverage the ones that are built in to the receiver hardware already.

Yes, in your case, I feel is the best option.

lars18th commented 2 months ago

Hi @lars18th Thanks for the suggestion.

I've just tried the solution you proposed. Unfortunately, ommitting the fe= from the request doesn't solve the problem. You can see below that the results are quite odd with the src=2 parameter resulting in FE3 being selected where I would hope to see FE0 selected and routed to input 3.

Results config request result -A 0:0:0,1:3:0 src=1 OK - FE0 connected to input 0 -A 0:0:0,1:3:0 src=2 FAIL - FE3 connected to input 0

Hi @mark-royds ,

The parameter -A 0:0:0,1:3:0 is not working as you imagine. If you don't want to try the test of only two tuners (one wire to Input A and the other in Input B), then try this -A 0:0:0,0:1:0,1:2:0,1:3:0 and not use fe= at all.

mark-royds commented 2 months ago

My understanding is that -A 0:0:0.1:3:0 instructs minisatip that: src=1 is on adapter 0, DiSEqC position 0 src=2 is on adapter 3, DiSEqC position 0

I think that's the crux of the problem really. The adapter (read: FE) should really not matter. The critical variable is the physical input.

My R1 is in a remote location so I can't switch the cables over just now . I currently have it wired with LNB-A in input 0 and LNB-B in input 3.

Using -A 0:0:0,0:1:0,1:2:0,1:3:0 as you suggest results in FE2 being selected and routed to input 0. No cigar!

mark-royds commented 2 months ago

Perhaps what we need is

-I --input-map SRC:INPUT:UB-FREQ,[SRC:INPUT:UB-FREQ]
  * SRC: satellite position being requested by clients
  * INPUT: physical input (0-3)
  * UB: Unicable userband
  * FREQ: Unicable frequency
  * eg:
    * --input-map 0:0:0-1210,0:0:1-1420,0:0:2-1680,0:0:3-2040,1:3:0-1210,1:3:1-1420,1:3:2-1680,1:3:3-2040

Something like that anyway... perhaps include some way to specify Legacy/Unicable/Jess at the same time. I suppose DiSEqC would need to go in there too. A bit unwieldy perhaps

Jalle19 commented 2 months ago

I'll think this over some tomorrow

lars18th commented 1 month ago

Hi to all,

After more thinking on this issue I've these comments:

What do you think?

mark-royds commented 1 month ago

Is the fe= limitation of -A definitely relevant to the issue? When I tested using curl I ommitted the fe= parameter completely and only included src= in the request. In those test cases, -A caused minisatip to select a specific FE, based on the source:adapter:diseqc mapping, but the physical input was always routed to input 0 (LNB1).

I'm snowed under with my day job for the next couple of days but if I get a moment I'd like to document the behaviour in legacy LNB mode. I'm recall that I've been able to have minisatip route any FE to any physical input by passing fe= in the request but I'd need to test.

The elephant in the room is the possibility of each Unicable/Jess system using different user bands. Technically it should be possible to use a simple RF combiner to join multiple systems to the same physical input and have the appropriate LNB triggered based on the UB requested by the FE. However minisatip doesn't have any command line option that I can see where you can link SRC,UB & physical input together.

Perhaps we should draw up a complex theoretical test system and identify any gaps in minisatip functionality, I don't write good code, but I can do good analysis so would be happy to put my hat in the ring for that.

lars18th commented 1 month ago

Hi @mark-royds ,

The question of driving "complex" unicable configurations is now out the scope. This include "multiple unicable LNBs in the same wire with not overlaped user bands for different satellite positions". But also other configurations, for example "different unicable LNBs each one in one different wire connected to a switch in front of the tuner". This is more or less what you have, but in this case the switch is internal and not managed by diseqc commands. This will need to be targeted in the future if someone wants to implement it.

But I feel that your current problem could be fixed without implementing something new, because your unicable LNBs are equal and using the same user bands.

lars18th commented 1 month ago

Hi @mark-royds ,

I feel you need to try the @Jalle19 version of AXE: https://github.com/Jalle19/satip-axe

Please read: https://github.com/Jalle19/satip-axe/blob/master/dist/minisatip.md#multiple-unicable-groups

mark-royds commented 1 month ago

Hi @mark-royds ,

I feel you need to try the @Jalle19 version of AXE: https://github.com/Jalle19/satip-axe

Please read: https://github.com/Jalle19/satip-axe/blob/master/dist/minisatip.md#multiple-unicable-groups

I have seen that version but there are a couple of issues...

mark-royds commented 1 month ago

The question of driving "complex" unicable configurations is now out the scope. This include "multiple unicable LNBs in the same wire with not overlaped user bands for different satellite positions". But also other configurations, for example "different unicable LNBs each one in one different wire connected to a switch in front of the tuner". This is more or less what you have, but in this case the switch is internal and not managed by diseqc commands. This will need to be targeted in the future if someone wants to implement it.

Personally I think if there is an effort to implement something that will fix my issue, it's worth designing a solution that widens the scope a little so that some other edge cases can be picked off too. My rationale is that the problem I have seems to stem from an limitation in the implementation of Unicable/Jess. Rather than create a very targeted patch for one (my) use case, perhaps better to address the underlying limitation for the benefit of a wider group.

As I say, I'm happy to investigate and specify a more complete solution but my middle name is segfault so I would need the help of someone with much more coding skill when it comes to the implementation.

not managed by diseqc commands

This is useful information. Is it i2c or something?

lars18th commented 1 month ago

Hi @mark-royds ,

Unfortunately, I can't help directly because I don't use AXE. And for this reason I suggest to target your problem without much changes. Your device has an internal switch that is controlled with the I2C bus. Therefore is not standard. More or less your configuration is a "cascade" of a switch+unicable. And it works because the internal switch is independent and it could be controlled without diseqc commands. But in any case, the "grouping" support is necessary.

Please @Jalle19 could you review your PR #979 ? I feel the issue from @mark-royds is related.

Jalle19 commented 1 month ago

It's related, yes. I haven't had time to debug this any further.

lars18th commented 1 month ago

Hi @catalinii and @Jalle19 ,

Based on the configuration commented by @mark-royds , I want to discuss about this use case:

At time we don't have support for this configuration. Any idea to support it?