[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