[mythtv] Thoughts on encoder farms / distributed capturing and viewing

Craig McLaughlin mythtv-dev@snowman.net
30 Oct 2002 12:24:51 -0800

On Wed, 2002-10-30 at 11:51, Robert Middleswarth wrote:
> Robert Kulagowski wrote:
> >o  Totally decoupling the encoder and the viewer.  Therefore, a local
> >node that has an encoder _might not_ be using it to watch live TV;
> >its "live" channel may actually be coming from a different encoder on
> >a different node.  The ringbuffer file is getting filled using IP.
> >  
> >
> Proble no possible as that would require alot of bandwidth on you local 
> network I not sure most nic card could handle that much data you would 
> have to create some form of mess network were you have 2 or 3 Nic in 
> each machine to send thought all that data.  Also there would be alot of 
> latance as the sending machine would have to begain recording start 
> direct connection to the sending and buffer data on both ends to deal 
> with packet delay/loss which would make it very unresponsive.

??? Check out videolan which does *just* this (decoupling the "server" /
source from the client / viewer).  The idea isn't that far-fetched...
particularly if the source is mpeg4 & the client side does the decoding
of the stream -- heck, by spec an SVCD is something like 2.6Mbps video +
224Kbps audio... 

> >o  A "stripe" based conflict resolution scheme.  I'm not sure that
> >I'll be able to explain this, but I'll try.  One of the things that I
> >don't like about my Tivo is the following:  "Everybody Loves Raymond"
> >runs on CBS from 1900 to 1930 in Chicago.  Sometimes, due to clock
> >issues, or the network being a little late, we miss the last bit of
> >"zinger" before the final credit roll.  So I tell Tivo to go 2
> >minutes long, and so now it records from 1900 to 1932.  The problem
> >is that if there's a show on a different channel starting at 1930, it
> >won't get recorded at all, because the Tivo isn't allocating smaller
> >blocks.  So even if I'm willing to miss the initial credits on a
> >show, I'm out of luck.  My thinking is that if you split a show into
> >1 minute blocks and overlap based on priority, the 32 minute show
> >will overlap the first two minutes of the show on the other channel. 
> >Every minute, the encoder is checking to master schedule to see what
> >channel it should be recording, so it will naturally "fall off" the
> >end of the 32 minute show and onto the 28 minute one.  This scheme
> >also handles "early start", since a higher priority show will overlap
> >the end of a lower priority show.  Of course, if there are multiple
> >encoder cards that are free then there's no conflict.
> >  
> >
> That would be real tough to setup you are talking crazy level of AI. 
>  Althought the conflict manger could be used to decide on thing like 
> that by a human who could make those kind of decisions

Not really any "crazy" AI -- actually, the existing conflict resolution
code is probably sufficient... Hm.  Think I'll look at this.  Basically,
for each minute, you'd need to see: Are we recording?  Is there a
conflict?  If so, does the current recording or the "other" recording
have priority?  If current, just keep going.  If "other," close this
one, start that one.

A couple of edge cases would need to be done, too -- like moving from
the higher-priority "current" to the "new" when the higher-priority one
is done (i.e.: at 1902)... Hm.  Yeah, time to get that extra system

> >o  A "hint" system for shows that are on multiple times per day.  On
> >my Tivo, if I tell it to record "The Daily Show", it's going to
> >record it 4 times a day because lately, TMS hasn't been putting in
> >show descriptions, so the Tivo doesn't know that the showing at 1400
> >and 1900 is a rebroadcast of the previous days' 2200 broadcast.  When
> >I do a manual record by time, I have to go in and delete the Friday
> >"Comedy Central Presents" which is on at the same time because I
> >can't program the Tivo to record M-Th.
> >  
> >
> Again to much AI there if got created it would never work the way YOU 
> wanted it would work the way it would be designed.  Althought I think 
> the ID of a Manual record menu which works like a VCR would be nice for 
> time when program data doesn't download or time when the data is 
> outright wrong.

No offense intended, but... what's this fascination with AI?  And if
he's proposing requirements, why wouldn't they at least be discussed as
part of the design?

That said, I don't see a 100% solution to this (yet), but certainly if
one is using a consistent source for descriptions, and they are fairly
robust (i.e.: the description is available for all showings of the same
"episode", then one could track that and see if we have currently
recorded that "description" in addition to a particular time.