[mythtv-users] Multiple frontends watching thesame backend program.

PAUL WILLIAMSON pwilliamson at mandtbank.com
Wed Jan 19 09:29:04 EST 2005


>>>> denier at umr.edu 1/19/2005 6:20:31 AM >>>

<snip>

>1) All myth backends do is compress a data stream and send it 
> out.  They have no need to store any data, at least with respect 
> to Live TV.

Um, no.  This represents a huge change from the way things 
are done now.  The mythbackend for the tuner you are using 
creates a ringbuffer for paulse/rew/ff functionality.  That's 
why there is a 5 second delay - the file needs to be created.
LiveTV buffers are not stored on the individual frontends.

>2) The first myth frontend to request viewing a channel sets the 
>Live TV parameters (compression) that subsequent must use.  
>This is necessary unless one wants the backend to be potentially 
>compressing to multiple formats.

Channel Changing is not done by the first frontend, but any 
frontend.  There is no special compression done other than 
the standard mpeg-2.  If using a pvr-250, not much else to set.
You can compress to any format after recording is complete 
with nuvexport.


>3) It then begins sending out packets of video to each frontend 
>that is online.  Ideally one would think some form of multicasting 
>would be desired.  I have never seriously looked at multicast packets

>on linux so I've no idea if thats feasible.

You're talking about something like rendevous, and I don't think 
this would be trivial to implement.  It works more (I think) the other

way 'round - the frontends connect to the backend to get their 
programming.

>4) Each frontend collects the video packets and starts its own 
>history of the packets on  its hard drive.  This allows each frontend

>to have a different delay and skip around live TV.

Way different from the way things are done today, since the 
pvr-250 on the backend is how things are written to disk.

>Again, its just my 2 cents.  If I get a massive amount of ambition 
>and free time someday I may take an actual look at the mythtv 
>code, but something tells me it would be a lot of work to get to 
>the point of actually being helpful that way.

I'm just a regular user (who still is having problems with the non-core

functionality), but after taking a look through the code, this is
nothing 
like Myth works today

>What allowed frontends could do (eventually).
>-------------------------------------------
>1) Each backend would have a list of stations or a wildcard pattern 
>on stations allowed to preempt control of the tuner.

For what purpose?  LiveTV or recording?  I think this is already there

with profiles and priorities.

>2) Allowed frontends that are the second or later to join watching 
>the channel to be able to change the channel.  (This should be one 
>of the easier changes since you can do this with something like ssh 
>backend /usr/bin/channel_change 333.)

What difference does it make what order the frontends connect 
to the backend?  Multiple tuners is a far easier solution.

>3) Allowed frontends to eventually allow changing the live TV 
>settings to be encoded.  The original frontend that selected the 
>format is forced to either change as well, or use a different tuner.

Again, the used card is primarily how the encoding is decided. 




More information about the mythtv-users mailing list