Tvheadend

You should provide more logs from tvheadend. It's difficult to determine what's going on from your description. It looks like that the SAT>IP server was not detected for a reason after power-up, so it looks like a wrong network config or so...

Jaroslav Kysela wrote:
> You should provide more logs from tvheadend. It's difficult to determine what's going on from your description. It looks like that the SAT>IP server was not detected for a reason after power-up, so it looks like a wrong network config or so...

Understand interest in network.
All of SAT>IP tuners, hts pi3 stretch arm64 tvheadend & NAS atom 16.04 amd64 smb are colocated on same Gig Switch.
pi3 osmc armhf client on site but not colocated i.e. switches but not routers.
All devices fixed static IP adrs - no DHCP dependencies.

Attempting to repeat (with logging) but NOT successful to get same symptoms.
(Multiple interruption to site power does not make friends...)

However I do notice issue with power up sequence relating to NAS used for recordings.
IF the NAS is not up before pi3 tvh then it is not found correctly though NAS becomes live OK on LAN.
Example to demonstrate:
having previously made recordings on the NAS, they correctly show in the finished recordings.
However if pi3 comes up before NAS then finished recording empty.
If NAS then DOES come up afterwards then finished recordings remain empty.
If do pi3# service tvheadend restart - then finished recordings reappear.
Conclude that network attached devices not handled in tvheadend in a network up/down/up tolerant fashion.
This is high desirable as do LANs become temporarily unavailable for a number of reasons.

Could this also be true for tvheadend handling of SAT>IP tuners?
(Which was the log provided in the initial post)

TVH expects to have the data accessible when it's started like other programs. TVH does not know, if it's network storage or so. You should start TVH after the network device is mounted.

For SAT>IP - tvh sends the upnp requests multiple times after start and the code also watches for the new servers (upnp discovery broadcasts). If something fails here, you may check '--trace upnp,satip' logs. https://tvheadend.org/projects/tvheadend/wiki/Traces

Jaroslav Kysela wrote:

TVH expects to have the data accessible when it's started ...
For SAT>IP - tvh sends the upnp requests multiple times after start ...

------I will look at this . . .

I have managed to repeat the original symptoms "No free adapter available"
showing on the Kodi client - without power cut/recovery.
Config has 2 SATIP tuners.
After watching recorded .ts on Kodi returned to TV using red button.
Image was frozen still with circle timing on centre dispaly.
I backed out and selected the channel I wanted.
Immediately I had "No free adapter available displayed.
I went to web portal.
Tuner 1 was tuned to mux as epggrab - Data showing/changing as usual.
Tuner 2 showing tuned to the TV Channel requested - But showing state "Idle".
Reboot of Kodi made no difference.
After a while the epggrab finished normally.
I stopped tuner play out on "idle" tuner using Kodi remote.
The subscripted stopped immediately
I played it again and it started immediately - but still no stream
I stopped it again but restarted another channel which worked OK.
I then started tuner 2 recording another channel which recorded OK.
So both tuners working OK concurrently.

I have logs. I will try to repeat to establish consistency, if any.

Having now tested this issue a lot more I have not found evidence
that it is connected with power interruption of power up of NAS for recording.

I believe this issue should be renamed
-----> Multiple repeated "No input source available"

cy clic wrote:

I believe this issue should be renamed
-----> Multiple repeated "No input source available"

Observations from tests.
pi2 running armhf 4.2.5-14
pi3 running arm64 4.3-997
Single test set up sharing SAT>IP 8 tuners
Same net/switch arrangements
Same Kodi Clients
Similar Freesat Bouquet setup
Initially
pi2: 5 tuners, pi3: 2 tuners, then
pi2: 4 tuners, pi3: 4 tuners, then
pi2: 8 tuners followed by
pi3: 8 tuners then finally
pi2: 1 dedicated tuner + 6 shared tuners and
pi3: 1 dedicated tuner + 6 shared tuners
i.e. each 7 tuners available if not used by other pi.
Multiple Kodi programme multi tuner playback worked OK.
Multiple Kodi programme from a single mux/tuner worked OK.
Combined dvr+Kodi playback from a single mux/tuner worked OK.

Conclusions
pi2 does not exhibit the issue and can handle up to all 7/8 tuners
with only small drop-out at 6 or 6+ recordings.
pi3 does exhibit the issue sometimes and also can handle up to all 7/8 tuners
with no drop out during the test period (though not thorough enough for certainty).
pi failed with any of 2, 4, 8 or 1+6 shared tuners allocated set ups.
Having allocated idle unused tuners does not stop the issue.

subscription: xxxx: No input source available for subscription
repeats ever second or two until state change.
Start or stop is sometimes related dvr start or stop,
sometimes related to manual selection of another channel.
more often/easily to trigger the issue using channel change on Kodi client either zapping or numbers pad.
Not predictable and sometimes not seen through much good zapping and manual channel changes.
Several times seen when changing channels after a period of static watched channel.

epggrab: never seen to fail when doing retune.
epggrab: always made use of all tuners (including shared) as one might expect.
Bumping of an epggrab weight 4 always worked as one might expect.
subscription: sometimes did use all tuners.
Sometimes it did not. When it did not is when the issue was seen.
I therefore muse that the issue is related to failure of the algorithm to find an unused tuner?
Not only (in this state) does it mistakenly think there is no free tuner but it seems to enter a an eternal loop filling the log with a repeating identical message unless something happens to attempt another subscription.

I note
On pi2 tuners in use to watch TV had weight 150 (4.2.5-14)
On pi3 tuners in use to watch TV had weight 100 (4.3-997)
Scanning 11425H on pi3 had weight of 100 and was seen to bump viewed channel, which also triggered a change to the fault state.
The 11425H activity was assumed to come from a mux subscription which I then disabled for rest of testing.
Is the change of weight 150->100 weight deliberate? Or did it arrive through churn?.
My intuition is that a viewed programme should not be bumped by scan of 11425H Freesat info.

The message
mpegts: too much queued table input data (over 2MB), discarding new
was seen to quite closely precede the issue more than once.
However I have no evidence the issues are related nor have I come across any way to repeatedly generate the ...2M... message.

The issue is not limited to the releases used in the test.
It has been seen in the issues that preceded each.

Hope this helps

I lost the track here. If you have a specific question for developers, show the logs and describe one problem. Those writings with such large explanations without anything which we can analyze, it's just wasting of my time to read this. From the glance, it looks like some bad configuration assumptions (shared tuners sounds horrible - who is the arbiter?).

2018-01-27 12:09:53.503 satip: SAT>IP DVB-S Tuner #4 (TunerIPAdrs) - RTSP SETUP error -5 (Input/output error) [6-503]

So the tuner was not available when the stream was requested, 503 from the server means "Service not available" . The 'retry' is configured in the streaming profiles - 'Restart on error' option, otherwise the tuner is marked as invalid and tvh will never try to use it again for the marked service (until resubscribed).