This is needed since this routine is used to also load config on creation.
So if a NOSAVE option is included there it will not load it. If it really
is NOSAVE it shouldn't be in the config files anyway (due to NOSAVE check
on actual save).
This causes initial scans to time out where the SDT is waiting on
mux information from. Given that we'll rescan these muxes anyway
there is little point.
The only downside is the single point of info muxes (like 11778V
in the UK) may not get the opportunity to provide all the info they
could, since we might miss service info until later.
This does require a certain level of extra input from prop_t users where
the type is enumerated. A new routine rend() must be implemented to provide
the rendered value (for lists that are not enum, this is done transparently).
The problem was that I played fast and loose with the diseqc spec. I set the
line volts much later than you're supposed to, for various reasons.
I've now sorted that, though because of the complexity if a rotor exists I
run a full re-program of the switch (only if a rotor is present). And I double
set the line volts, both in the switch (to ensure it happens early) and then
in the LNB tuning (in case no switch exists).
If a service was marked as bad (no input) it was not unlinking the
subscription from the service before re-applying, this resulted in
a double entry into the service subs list and ultimatey a livelock
or possibly worse.
This was due to failure to properly reported which adapters have
been enabled. There are other problems with the capmt setup code
that really need addressing, but I don't have the time right now!
It's possible a mux is not tunable, yet that doesn't imply the presence
of a free tuner means its invalid. It could just be that its an S2 mux
with only an S tuner available (just one example).
Rather than adding an explicit flag (to stop mux calls) on retune I
have moved the frontend close operation to be done in the background
monitor timer. This isn't foolproof but will cover most things
and I can probably add a delay to cause that to not execute immediately
should the timer be about to expire.
Now have the concept of both input and output bandwidth usage of a sub.
The reason for this is that while data may be flowing into the subscription,
i.e. a signal is being received. Things like timeshift, or even potentially
flow control, may mean the actual outgoing rate is quite different.
Input rate is added by the subscription code as data enters the sub, however
the output rate must be added by the subscription handler as close to the
client as possible.
This is particularly important for null susbcriptions that receive no
stream data and therefore handle the SMT_STOP inline (actually was
direct before). This causes list corruption, therefore these subs
are now stored to a secondary list that are cleaned up within the
standard rescheduler.
