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.
THe problem is that mux subs have been done such that unsubscribe
(which in turn calls subs_reschedule()) can itelf be called in line
from subs_reschedule().
Really this is a bit of a mess but this simple hack fixes things.
I've made the table extraid 64 bits, as some entries require 32+X bits
so a 32-bit field wasn't enough.
Added callback for registering destruction (for dealloc'ing memory
alloc'd for opaque).
Added method of registering desciptor tag handlers, saves duplicating
BAT processing used for OpenTV, which uses 1 custom descriptor.
Improved the table completion detection and reduced level of debug
that could swamp tvhlog queue.
If processing because so high that the log queue becomes swamped we can
end up with a sort of avalanche scenario where everything gradually slows
down and the size of the buffer continues to grow. The main culprits of
this have been eliminated at source, however this is still a useful
safe guard.
The processing performed in the hexdump routine, commonly used in
SI table trace output. Was having a significant impact on performance
as it was not pre-processing the config to see if trace was even
enabled before continuing to build up the (large and frequent) hex
strings.
It's a bit ugly to link subs and mpegts directly, but its not the end
of the world (and probably unavoidable without lots of duplication).
I'm still not convinced its robust to mux deletions if subs exist on
that mux. Probably needs mmi to be ref counted.
There is also a special kind of sub that expects to receive no stream
data, i.e. all data will come from the SI tables only. This special
sub is automatically unsubscribed (but that might need changing).
Note: I think my thinking for needing this logging thread is possibly
no longer valid. So this might be removed at some point (or at least
made optional).
