Still haven't touched OpenTV and there are several hacks in here for which
a proper solution is required.
(cherry picked from commit 9212120eb4c92aacb0d9cb75624961bf27e2ef5a)
I thought this was causing stale data to enter the pipelines, turns
out this was not the case (it was just a NIT entry for a mux that
didn't exist colliding with one that did).
However still a useful mod.
(cherry picked from commit a7c7b76e8f8f10ece3af3132964c8afd19b26391)
This is necessary so that things like EPG grabbing can make
subscriptions that take precedence over initial scan but not
over standard subscriptions.
Will also be used for the debug mux dump from UI feature.
(cherry picked from commit 35a58bdf85008b819504e86e26f1072f79e79af3)
I'm hoping this will give a small performance boost with heavy levels
of trace. This is because I'm finding that data appears to be missing
when testing EIT, but to test I need to enable debug and I think that
debug may be part of the problem!
(cherry picked from commit d59421f91896fe30cd6ba6507f90ad0766903ae3)
I had forgotten to make the read() buffers mux specific. Without this they
effectively end up using the same buffer for all active sessions and will
trample all over each other!
This will now allow the mappings between services and channels to be created.
Some basic options have been created for the purpose of allowing certain
level of control of how the mapping is done.
The API code has also been updated to use the htsmsg auto conversion of
strings to map/list where required. Basic approach is check for list/map
first and if that fails fallback to string (if that's whats appropriate
for a mixed type field).
This is done on request if the string can be JSON deserialized. This is
useful for the common API where the webui will be sending in serialized
strings and saves having the special case "args" field.
For things like HTSP, which deal directly in htsmsg, the fields should
already have been converted to the right formats etc...
Really this lot could do with a proper tidy up, but probably for another day
and since this code is kinda shared with showtime I want to keep the changes
to a minimum until I've had a chance to discuss with Andreas.
The idea is that this will become a common API framework for both HTTP
and HTSP. And anything else we might think off.
The only real constraint at the moment is both assume a JSON like input
format (for simplicity) since they currently have that in common.
this is conditional based on a test run from the configure script, as this
type of test is certainly not 100% cross platform compatible.
However its very useful to have a true check of lock ownership rather than
the rather arbitary check that "someone" holds the lock.
