this was because it reverted to using the display string and doing
a reverse mapping. Which is clearly the wrong way to do things when you
can have multiple display fields for the same key value.
The reason for this is there isn't a command for "changing" channel, this may
be changed in the future. So to simulate it the subscription weight is change
to a minimum level and then a new one can be created, thus reducing the need
to stop the tuner (especially for in mux zaps).
This allows user configuration which in the event of no setting will fallback
to information automatically determined from the services.
I have also updated the name stuff and simplified it a bit (with one minor
change to idnode to support).
Many of these are somewhat redundant now, as I've suppressed many of the
warnings as they're false positives. However the changes, such as added
a detach flag to tvhthread_create(), have been kept anyway.
This is because the field can now be NULL and there were places where this
was not properly checked. So now a function call channel_get_name() should
be used instead and is garaunteed to return non-NULL.
In addition to this there is a nice added benefit. You can NOT set the name,
and it will automatically pull the name from the first available service. This
will not be persistent (part of config) unless you change that name and save
from the UI. This means if the service name changes, so will the channel name.
However on that last point there will not be, currently, any message sent to
the clients (HTSP) to inform them of such a change. So there might be some lag
in getting the update.
I'd added this so that ALL mux subs tried to use fullmux reception. This was
clearly not what was intended as the only time this is needed (at present)
is when subscribing for muxdump from the webui.
I think it was quite possible for two services on the same multiplex not
to share the same tuner. Also I wasn't convinced about how it kicked running
services.
This is not supported by ulibc, however since prctl is part of standard
Linux kernel since 2.6.9, I've added a thin wrapper around thread startup
to call that method from within the thread.
This should overcome the current issues with EPG grabbers stealing data
but also, IMO, is a better approach.
However it did require some reworking of lock semantics.
This can be done in 3 ways:
none: don't hide anything
all: hide all disabled elements (you can't re-enable in this state)
default: hide those elements whose parents are disabled
