[mythtv-users] question involving multiple frontends

Michael T. Dean mtdean at thirdcontact.com
Mon Feb 9 21:41:24 UTC 2009

On 02/09/2009 03:54 PM, Adam Stylinski wrote:
> Adam Stylinski wrote:
>> While I'm glad that there is a way to do this manually and was looking
>> for a method similar to this, my main concern is having duplicate
>> recordings.  In a house with multiple backends, it is hard to know when
>> the user is watching what, and there will be overlap if it attention
>> isn't paid (again, causing duplicate recordings

Which aren't a problem because Myth can handle it and LiveTV is 
autoexpired with prejudice.

>>  and wasting a tuner).

Which means if you have people watching LiveTV and you're concerned 
about running out of capture cards/tuners, you need more.

Simple formula:  1 capture card per simultaneous LiveTV user + 1 capture 
card per desired scheduled recording or 1 capture card per channel 
(multiplex, if using multirec), whichever is smaller.

And, I'll guarantee that the $50 per each additional capture card you 
buy is /significantly/ cheaper than the cost of the code required to do 
it your way.  (And, since Waste-Your-LifeTV, er, LiveTV, is not 
something that interests many MythTV users (especially developers), 
finding someone to contribute all the required hours of their time to 
write and test (and--I would hope--maintain) the code will likely be a 

>> What might be great, although likely impossible, is for the frontend to
>> look for livetv sessions already in progress and stream from them.  Then
>> if the user switches channels on one frontend, their frontend simply
>> goes to another tuner if there is another user watching the channel that
>> is being changed (sorry if my English wasn't clear there).  So
>> essentially a situation would occur like so, viewer A is watching WCPO,
>> viewer B is watching WCPO also.  User A wants to switch to WKRC.  User
>> A's frontend accesses another tuner on the backend as to not interrupt
>> the livetv session of the other user, and user B watches seamlessly,
>> never stopping the recording livetv program in progress.  I can see this
>> being useful for other reasons, i.e. not wasting a tuner for potential
>> scheduling. 
> Also, I may not have been clear on this, but I mean automagically find
> existing livetv sessions on the same channel when the user goes to
> "watch tv".  What you said isn't the same, although it is useful, again,
> if you're aware of what user B is watching.

So, you start LiveTV on frontend A.  Someone else start LiveTV on 
frontend B.  Then 2 scheduled recording begin, and now all 3 of your 
capture cards are busy recording different things.  Then, the person 
watching LiveTV on frontend B decides that the show is boring and 
changes channels to a channel that's not being recorded for either of 
the 2 scheduled recordings.  What should Myth do?  We could pop up a 
dialog saying, "Sorry, but due to your bad timing at starting 
LiveTV/changing the channel, you're stuck watching something that 
another user is watching or that I'm currently recording."

Now, let's make it more complex.  Let's say the person watching LiveTV 
on frontend B actually loves the show, but you decide it's drivel, so 
you try to change the channel, but all capture cards are in use.  What 
does Myth do here?  Well, since you started LiveTV first, let's say Myth 
decides you have priority/control.  Now, the person who was watching a 
very enjoyable show gets hopped to a different channel.

OK, so let's say Myth decides that just because you started LiveTV, that 
doesn't mean you should have priority.  Instead, it figures, since both 
you and frontend-B-user were watching the same show when all other 
capture cards became busy, whoever decides to change the channel isn't 
allowed to do so (i.e. you both have to watch the same show).  So, you 
get a pop up dialog saying, "Sorry, all capture cards are busy, so 
you're stuck watching this drivel."  Now, the user watching LiveTV on 
frontend B thinks, "You know, this show really isn't that well-written, 
let me see what else is on..."  Now that user tries to change the 
channel (perhaps even to the same channel you had tried to change to) 
and gets a pop up saying all capture cards are busy.  So, the user 
watching LiveTV on frontend B yells upstairs to you, "Hey, you really 
interested in that show?  It's garbage."  You answer, "No joke, let's 
switch."  Then--coordinating by yelling to each other--you both exit 
LiveTV (making a capture card available), then one of you enters LiveTV 
and the other rejoins the LiveTV session.  But what you didn't realize 
is that frontend-B-user snuck into LiveTV /before/ you restarted it and 
started watching the /only/ show you've ever seen that was worse than 
the one you were just watching.  Pretty soon, you have to walk 
downstairs, steal the remote, exit LiveTV, and go back up to your 
frontend of choice to watch your LiveTV program of choice.  (Then 
frontend B user retaliates with remotely launched Nerf missiles, until 
soon enough, the UN (that is "UNhappy family members") send in 
peace-keeping forces who decide that everyone has to watch a completely 
different show.)

All this violence could have been avoided if only you had enough capture 

Basically, the problem is that with this approach, we can't guarantee 
the user a capture card, so a LiveTV user may get stuck.  The /only/ way 
to guarantee that people can watch what they want is to either a) 
schedule the use of the capture cards--i.e. don't use LiveTV or b) have 
enough capture cards for LiveTV /plus/ all scheduled recordings.

But, if you'd like to, feel free to add the idea to 
http://www.mythtv.org/wiki/Feature_Wishlist .


More information about the mythtv-users mailing list