Channel changes need to honor channel visible field in channel data.

[eric.bosch@…]

I have a 2-device input group, IEEE1394 and s-video sharing a common STB. Some channels will fail to tune in on IEEE1394 due to encryption, or being blocked by Comcast, and this currently cascades into segfault. If I enter mythtv-setup, edit channels, and make the 1394 device copy of the channel NOT visible, and I make the channel on the s-video input visible, it does not have the desired effect. It will still try to tune the offending channel on IEEE1394 input device instead of the only one with a "visible" attribute unset in the channel table. A Channel change should look to see if the channel requested IS present, IS visible, and switch to the appropriate device when necessary.

I use schedules direct, and they do not support having multiple copies of the same lineup, which I had hoped to use one copy to reflect the HD channels that DO work over IEEE1394, and the other than contains all other channels, and use that for driving the guide info.

If there is some other trick to this, let me know

I did get it to work as desired by actually deleting the channel for the broken IEEE1394 channel from the device, however the next running of mythfilldatabase restored the channel info, thus breaking it again.

[anonymous]

You need to run mythfilldatabase with the --remove-new-channels option so the channels don't get added back in. Visible means visible, not "delete" or "never tune to this channel". This is functioning correctly.

[anonymous]

By the way, there is an example of how to accomplish exactly what you're trying to do in the documentation: http://www.mythtv.org/docs/mythtv-HOWTO-24.html#ss24.4

[stuartm]

Visible should be equivalent to delete in these circumstances.

[eric.bosch@…]

I don't really like the idea of losing automatic additions of channels, as channel lineups do change occaisonally. Would it be possible to add a field "do_not_use" in order to make these channels more manageable? What is the actual purpose of the "Visible" field?

Stuart, are you saying that channels marked NOT visible should NOT be tunable?

[eric.bosch@…]

After performing some testing, it appears that this feature works correctly from a backend/recording perspective, but seems incomplete on the LiveTV side. An additional problem, if something is recording on IEEE1394, and I attempt to start a LiveTV session, it immediately fails, apparently trying to signal a startup on the second half of a busy input group, i.e., it sees a tuner (S-Video) is available, thus trying use it without checking if that input group is busy.

[danielk]

We need a backtrace for the segfault. Thanks.

As for the visible flag, we've always allowed changing to invisible channels in LiveTV. It is safe to do with other tuners and allows you to watch the home shopping network or some other invisible channel without too much fuss. Any change to this behavior should be discussed on the mailing list first.

[eric.bosch@…]

Ok, I've done some additional testing after reloading my channel base, and the segfaults appear to be cured at this point. The only pain that I still see is that in many cases, the recording does not observe the "Preferred Tuner" setting, and often will attempt to record on a tuner that does not function properly, ie hd on encrypted channels. What I would like to see down the road is an automatic retry upon tuning failure for one tuner to retry on the other member of a tuner group, ie, if Firewire recording fails, fall back to svideo recording on other member of tuner group.

[robertm]

Segfaults reported as solved by reporter, other behavior in this ticket appears to be as designed/intended.