I have decided that this is no longer necessary, however:
a) I like some of the changes introduced, so want to keep them
b) want to keep the option available should I re-evaulate the performance
Really this should not be directly in here, as subscription code shouldn't
need any knowledge of the underlying systems. However its a backdoor into
the full mux.
I have split the input threading in two. There is now a smaller/faster thread
responisble for reading data from the source device (file/socket/DVB/etc...)
and a potentially slower (though not too slow!) thread for processing.
This ensures that any minor delay in processing (potentially due to unexpected
effects during start/stop, or anything else!) do not unduly impact reading from
the source which could otherwise lead to loss of data.
If a scrambled has been seen on a "scrambled" channel all further packets
(within the subscription) MUST be processed through the descrambler else we
can end up with out of sequence packets causing CC errors. Relates to #1986
Could have ensure this was set correctly on input, but given that it was being
set if no config was passed and almost certainly it must by definition be the
same as the source mux, might as well simplify things.
This will not attempt to remove duplicate networks or configure the tuners.
I have decided this is just too much work to get right, versus very little
human input to correct.
This is to allow simple detection of a need to migrate, so that it can be done
in one centralised location. Rather than having to have lots of in place dual
config handling.
Some simple stuff will probably continue to be done in place, to avoid
constantly adding migration routines for trivial stuff. But anyting non-trivial
will at least be more easily handled without the need for external scripts.
