Bug #1532
closed
disabling a multiplex does not disable channels from that multiplex
Added by Reinhard Mantey over 12 years ago.
Updated about 12 years ago.
Estimated time:
(Total: 0:00 h)
Found in version:
3.3.152 - g249b4c1
Description
after disabling a multiplex entry and saving changes I'd expected the services from that frequency to disappear from service page, or at least to become disabled too.
But toggling enable checkbox of a multiplex entry seems to have no impact on related services.
- Status changed from New to Accepted
Agreed,
I did just fix something similar to this related to OTA EPG ingest. However I didn't fix the more general case. But I agree that such services should be ignored (if service, multiplex or adapter) is disabled when deciding what can be used to subscribe a channel.
However the info will not be removed from the UI for good reason. Though marking channels as unusable in some way (especially so clients such as XBMC can use this info to filter channel list) would be a good idea.
Adam
- Target version set to 3.4
However the info will not be removed from the UI for good reason.
Agreed.
May be you could introduce a new flag for disabling a dependant service (don't know, what's possible with extJS).
If a user disables some serivces of a multiplex, then after toggling the enable state of a multiplex/adapter twice, things will stay as before - so no service state gets lost by disabling a multiplex/adapter.
Reinhard
Sure, this won't actually change any of the internal state. It's just that the (display/active) state of a service will be calculated as:
svc->enabled && svc->mux->enabled && svc->mux->adapter->enabled
or something along those lines.
Adam
- Target version deleted (
3.4)
I think it best that we push this until the DVB re-write, although its not right the fact that services/channels are not disabled is not fatal.
Adam
DVB rewrite sounds interesting.
A there some plans on that item available publicly?
I think, the UI needs some improvement too, like several filters or the like on muxes and services page, as the first setup is quite cumbersum.
Reinhard
Andreas is still working on it and it won't be available until after 3.4. The UI will most likely be very different to take into account the very different nature of how TVH will manage the information. One of the main purposes is to simplify network management, especially for large satellite setups.
Adam
- Status changed from Accepted to Fixed
- Target version set to 3.4
I think a more complete solution may be possible later on, but for now I think the workaround fixes the most pressing issues.
Adam
Also available in: Atom
PDF
Updated by 
Updated by