[mythtv-users] Enabling multirec borks usability a bit.
linux at thehobsons.co.uk
Wed Apr 21 19:27:33 UTC 2010
Douglas Peale wrote:
>I want to make sure that this does not get over simplified.
>I have 5 tuners in my system, 3 tuners on cable, one tuner on a
>northwest facing antenna, and one on a south facing antenna.
>This means I get as many as 4 variants of a single station.
>On cable there are some stations that are available as analog,
>digital SD, and digital HD. That same station may also be available
>as OTA HD.
>Worse, at least one station is from a neighboring town, and the
>cable version of it gets blocked whenever the local affiliate feels
>Usually the OTA HD quality is better than the cable HD quality, but
>that situation changes on certain stations that have mulipath issues
>and OTA station can also be affected by the weather. I have adjusted
>tuner and channel priorities so that recordings will be done on the
>quality source for the programming.
>While I can assign any channel number to any station, I have
>assigned the digital SD and analog stations the same numbers so that
>the numbers that show up in the guides. This means, for example,
>that I have an analog channel 2, a digital SD channel 2, a cable HD
>channel 2.1, and
>an OTA HD channel 2.1, all with the same programming.
>When using live TV and selecting channel 13, which variant of
>channel 2 should live TV choose? I need to be able to access all
>variants to be
>able to test the setup and to see if the cable company has played
>musical channels again, but if I'm channel surfing, I'd like to just
>the best quality variants of the channels.
My thoughts on how it should work, is that from the users
perspective, you would "just have a list of channels" - whatever you
want to watch (either by pressing next/prev chan, or by typing a
number) would be shown subject to *an* input being available that
carries the channel.
If I were doing it, I'd code it so that it would show you the highest
priority input available for the channel. If a recording starts that
causes a conflict, then it would switch your live TV to the next
lowest priority - or put up a notice if there wasn't another option.
I guess people would probably want config options - such as
prioritising live TV at the expense of recordings, or using the
lowest priority first so as to minimise clashes with recordings.
So the logic would be :
Use selects a channel, system gets a list of inputs currently
available that can show it, selects the best according to channel
priorities and user settings, displays it - and if no input is
available, then just show a blank screen and a "channel not
When a recording starts, decide which input is required for the
recording - taking into account input priorities and user settings,
if result says recording should be on input currently used for live
TV, kick off the live TV, start the recording, and repeat the above
logic to select a different input to show or notify the user. If the
results say that the recording cannot be performed now, then trigger
a reschedule in case it can be done later.
Doesn't need any knowledge of input types - only the logic already
built in that decides what inputs are available for a given channel
and what their relative priorities are.
A side effect would be that those of us with DVB-T could install one
physical tuner per multiplex, scan only one multiplex per tuner, and
effectively dedicate each tuner to one mux - with multirec taking
care of the rest. That would completly eliminate the possibility of
two tuners getting on the same mux and causing blocking by not being
available to tune to another mux.
> > So buy a PVR for LiveTV and use MythTV for recording?
>No. Just buy a tuner or reciever or let your TV sort things out.
>If LiveTV is really that important than clearly it deserves dedicated
>hardware. Either way, you're going to end up with problems even if
>MythTV's LiveTV function were perfectly golden. You still have the
>problem of having that tuner and the system wanting to use that tuner
>while someone is trying to tie it up interactively.
On the other hand, take the example above - multiple input types
requiring multiple duplicate hardware, some of which (eg cable DTAs)
requiring ongoing rental. I think most people could live with a
certain amount of contention IFF the system handles it gracefully.
Putting any extra hardware into the Myth system would make the whole
equal to more than the sum of the parts.
Michael T. Dean wrote:
>Live TV isn't excluded. It's just that it will only be improved by
>people who care to donate their time/effort to improving Live TV
>(and you can't count me among those people--I have plenty of other
>stuff on my TODO list for MythTV).
I don't think anyone would argue with that standpoint - but there are
those who keep repeating that LiveTV shouldn't be used. There's a big
As a user who doesn't code, I won't ask for someone to implement
something they don't want to work on for their own reasons - I have
no right to do that. I think it's reasonable to make suggestions on
how it might work from a users point of view so that anyone that does
decide to do the work has some input on what others might find
useful, but that's a different matter.
But I don't think it's all that reasonable for people to try and
discourage input on something they personally don't want to use.
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the mythtv-users