Tvheadend

As a follow up, the tvheadend log when trying to play a hidden service via VLC is as follows

2020-05-29 16:27:29.454 http: 192.168.0.230: using ticket 1e2553e63cfb3dc015d530eb5a69b60f35fc3eff for /stream/service/7b6c4011f918257e2a20b8630aedec31
2020-05-29 16:27:31.454 subscription: 0002: No input source available for subscription "HTTP" to service "DVB-T Network/514MHz/BBC ONE W Mid" in mux "514MHz in DVB-T Network"
2020-05-29 16:27:31.454 webui: Couldn't start streaming /stream/service/7b6c4011f918257e2a20b8630aedec31?ticket=1e2553e63cfb3dc015d530eb5a69b60f35fc3eff, No service enabled
2020-05-29 16:27:31.454 subscription: 0002: "HTTP" unsubscribing, hostname="192.168.0.230", client="VLC/3.0.10 LibVLC/3.0.10"
2020-05-29 16:27:31.494 http: 192.168.0.230: using ticket 1e2553e63cfb3dc015d530eb5a69b60f35fc3eff for /stream/service/7b6c4011f918257e2a20b8630aedec31
2020-05-29 16:27:33.494 subscription: 0003: No input source available for subscription "HTTP" to service "DVB-T Network/514MHz/BBC ONE W Mid" in mux "514MHz in DVB-T Network"
2020-05-29 16:27:33.494 webui: Couldn't start streaming /stream/service/7b6c4011f918257e2a20b8630aedec31?ticket=1e2553e63cfb3dc015d530eb5a69b60f35fc3eff, No service enabled
2020-05-29 16:27:33.494 subscription: 0003: "HTTP" unsubscribing, hostname="192.168.0.230", client="VLC/3.0.10 LibVLC/3.0.10"

I also have seen that. The problem is that those services does not take stream parameters during scan (PCR,H24/MPEG/audio...), only PMT is seen.

For me this problem also happen for DVB-T phisycal adapters. It is not exclusive of satip.

That seems to be correct. As a follow on to this I have found that if I delete the services that are hidden and rescan, then keep repeating this, eventually the services do come through but it can take 10 or 15 attempts minimum

The satip server I am using for testing this part is the stable release

Is it possible this could be down to low signal?

I can now confirm this is not due to low signal. Previously some of the channels had signal strength of -81dbm, they are all no lower then -39dmb and the issue still persists

Sorry to keep posting but i am just ruling things out now

Both the satip receiver (85) and the raspberry pi (81) that was running the stable release are running version 4.3-1885~ge1031ce5d
To rule out any issues of multiple receivers, i have only enabled this one satip source (81) on the main receiver (85) install

The main tuner (81) tunes 102 services mapped and visible, with another 43 hidden that should not be
The satip client (85) tunes and again only receives between 5 and 36 services as visible, with the remaining hidden

All 3 instances (including the other receiver (80)) show the same 145 services total but with varying numbers mapped so it seems to affect everything as Pablo R. saw and not just satip although the satip receiver seems to consistently map a much lower amount than the main devices

The lowest signal strength i saw was -45dbm during tuning which from what i can find out is perfectly acceptable. I have however noticed that some of the services do have PMT and PCR mapped but obviously with no mpeg streams still

Ok, last follow up to this for a while

I removed tvheadend from both transmitter device (80 and 81) and instead ran minisatip on them

Connected them both to the satip receiver running tvheadend (85) and i now have 99 services scanned and working flawlessly from both devices. This is consistent no matter how many times i delete and re-scan all services so for now, i'm going to stick with this

I have a similar problem with Mux scanning. I still don't know what's causing it (good services "hidden" under parent disabled), but I found that setting the option "Maximum PIDs" to a lower value in the SAT>IP adapter before the scan usually solves my problem.

You are most likely subscribing to more PIDs than your driver/server supports.