[mythtv-users] Enabling multirec borks usability a bit.

Jeff Wormsley daworm at comcast.net
Tue Apr 20 21:03:44 UTC 2010


On 4/20/2010 3:20 PM, Douglas Peale wrote:
> While I can assign any channel number to any station, I have assigned 
> the digital SD and analog stations the same numbers so that they match
> 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.
>    
I have done this where my QAM256 channels overlap my HDPVR channels as 
well.
> 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 surf
> the best quality variants of the channels.
>    
First, I'm assuming you mean if you punch the numbers 13, not Chan+ or 
Chan-?  I'm of two minds about this.  My first thought is the opposite 
of yours.  I'd make LiveTV favor the LOWEST priority (ie, if you set it 
up right, the worst quality).  My thinking is that if I want to save it, 
I want it to be the best, but if I want to watch and be done, I don't 
care as much about the quality.  I can certainly see your point of view, 
in that if you are going to watch it, you want to watch the best version 
no matter what.  However, if you use Chan+ and Chan-, there is no reason 
you can't see all of them (if you are on 12, and you have three 13's, 
then Chan+ goes to the first 13, Chan+ again to the next, and so on).

As for the questions about what happens when a recording needs to start 
while LiveTV is running, here are the scenarios I can think of with one 
upcoming recording and one current LiveTV user, and what the system 
should probably do by default.  I'm sure the dev's are fully aware of 
all of these and more, but I had to think them through for myself, and 
maybe some other people can benefit by having them spelled out (and if I 
missed  a message in this thread that better covered this, I'm sorry to 
repeat it).

0. The recording can be made on another tuner, which has higher priority 
than the LiveTV tuner.

This is a no brainer, the system just records the show.

1. The LiveTV tuner is the only one that can get the channel that the 
recording is scheduled for, and this recording is not repeated in the 
current listings.

Dialog to user, "Let it record or continue LiveTV?"

2. The LiveTV tuner is the only one that can get the channel that the 
recording is scheduled for, and this recording is repeated*** in the 
current listings.

Dialog to user, "Let it record, schedule recording for later*, or 
continue LiveTV?"

3. The LiveTV tuner is the best tuner that can get the channel that the 
recording is scheduled for, and this recording not is repeated in the 
current listings, and the LiveTV show is not available on another tuner.

Dialog to user, "Let it record, or continue LiveTV?"

4. The LiveTV tuner is the best tuner that can get the channel that the 
recording is scheduled for, and this recording is repeated in the 
current listings, and the LiveTV show is not available on another tuner.

Dialog to user, "Let it record, schedule recording for later*, record on 
other tuner, or continue LiveTV?"

5. The LiveTV tuner is the best tuner that can get the channel that the 
recording is scheduled for, and this recording not is repeated in the 
current listings, and the LiveTV show is available on another tuner.

Dialog to user, "Switch LiveTV to other tuner**, record on other tuner, 
or continue LiveTV on this tuner?"

6. The LiveTV tuner is the best tuner that can get the channel that the 
recording is scheduled for, and this recording is repeated in the 
current listings, and the LiveTV show is available on another tuner.

Dialog to user, "Switch LiveTV to other tuner**, schedule recording for 
later*, record on other tuner, or continue LiveTV on this tuner?"

* (This is what will happen anyway, but if the user knows it is repeated 
they may be willing to keep watching the LiveTV, whereas if they don't 
know it is repeated, they may want to record it now.)

** Implies recording gets to use the tuner formerly used by LiveTV.

*** Implies that at this point, the tuner with the conflict is known to 
be available at that future time.  Obviously, with schedule updates, 
that could change.  Perhaps one of the "dire consequences" is that it is 
removed from the listings later, or something higher priority bumps it 
later.  I don't worry about these, as schedule changes make this happen 
all the time anyway, with or without LiveTV multirec changes.

This gets harder, but I think still manageable, with more than one 
recording scheduled to start.

Where it gets very hard is when there are multiple people watching 
LiveTV and multiple recordings about to start.  If you offer some 
choices to, for example, two LiveTV users, and one makes a choice, what 
happens to the other LiveTV user?  Do their choices suddenly change?  
What happens if they both choose at the same time?  Or, let's say you 
created some kind of LiveTV frontend priority, similar to the tuner 
priority, and the LiveTV watcher with the highest priority has to make 
the choice, what happens to the other person watching LiveTV?  I assume 
they'll get a dialog telling them they are being booted and either 
jumped to the next available channel or booted back to the previous menu.

Perhaps the OSD can be of some help, giving warning with an icon in the 
screen corner when something disruptive is about to happen well before 
the dialog appears.  Or closed captioning, similar to weather alerts, 
could scroll a warning across the screen.  Or, if LiveTV is about to 
start a program and another is scheduled to take the tuner in the same 
timeslot, or maybe even the next one, a dialog can appear then, so that 
the user has time to decide whether to continue watching the LiveTV 
show, or go schedule it to be recorded possibly later.

I think it is all doable, and in the end would be desirable.  I don't 
for a moment think it would be easy.  Before anyone goes too far with 
it, all of the combinations of issues like above need to be listed, and 
the appropriate action by the appropriate actor needs to be defined.  
Once that's done, figuring out how much work it would take to implement 
it shouldn't be that hard.  Perhaps a thread or wiki page where people 
could list possible scenarios and others could give possible solutions 
would be useful.  Once the full scope of the job is known to everyone, 
not just the devs who understand it at a deep level, I'm sure a better 
consensus can be arrived at on what can and should be done.

Jeff.
--
I haven't smoked for 3 years, 8 months and 3 days, saving $6,042.21 and 
not smoking 40,281.46 cigarettes.


More information about the mythtv-users mailing list