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

Robert Middleswarth mythtv-dev@snowman.net
Wed, 30 Oct 2002 14:51:16 -0500

Robert Kulagowski wrote:

>Hash: SHA1
>Isaac, do you have thoughts on how you're going to proceed?  I've
>been thinking of "nice to have" features.  Stream of thought stuff
>o  Self-organizing encoder farms.  Every 30 seconds, mythtv sends out
>a broadcast packet to the local LAN that has information in it like: 
>hostname, disk space free, number of encoder cards and encoder card
>type (or source, in case something like DirecTV is only available on
>one encoder).  This allows cooperative scheduling.  The other way is
>to simply do what Cisco's IP/TV does:  at startup, the server
>enumerates the encoder cards and the existing content and sends a
>message back to the Content Manager.  The Content Manager then
>changes the status of the server to "Managed" and maintains a table. 
>The server and the content manager have to be manually configured to
>make them aware of each other.
I am not sure about Isaac code yet as I am build a box right now for 
install and development on but based on the fact that everything is 
stored in SQL already I would think that a Decated SQL server and some 
naming logic in his configure code and you would have a basic master 
server already so you would just have to add a program to manage that data.

>o  A machine that doesn't have any encoder cards is still valuable,
>either as a transcode machine, or as a disk space repository /
>archive server.
Would be true if you broke up pices of his software.  One of the Thing 
that could help with recoding to VCD/SVCD/DVD/MPG* recoding.

>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.

>o  A master scheduler is always looking a few minutes into the
>future.  If a program is supposed to be recorded, use the "free
>encoder card" broadcast messages to determine which node should do
>the recording, and the free space message to determine if we need to
>purge content.  If you use a master/slave relationship rather than a
>cooperative one, then this might not be as big an issue, since
>presumably the master will always know the status of each encoder
Correct some form of mangment appt would have to be used and priorty 
would also be useful for machines in rooms you don't use as much or 
recording only machines.

>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

>o  Partial deletes.  I know that you mentioned commercial cutting,
>but I'm interested in "delete up to this point".  Say I have a 2 hour
>recording, and I've already watched 1 hour of it.  I want to free up
>the disk space by deleting the first hour.
Once commercial cutting is added that would be easy to add if someone 
wanted to take the time and felt there was a reason to do it.

>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.

>o  Configurable "history".  Keep track of shows that were recorded,
>and when they were deleted.  That way, if I'm going to watch an
>episode of a show and I don't remember if I've seen the OSD can tell
>me, either at time of recording or in the "To Do" list.  The Tivo has
>a 28 day memory on this sort of stuff, but most syndicated shows take
>longer to cycle through than that.  Allow the user to specify how
>long until purge.  Disk space is fairly cheap.  Note:  this probably
>won't work unless we get the episode descriptions instead of just the
>show name.
That is proble the easiest overall to do and can be setup to use very 
little HD space.  What about something alitlle more useful like a 
database of stuff that  is going to be record and when at what time 
moving that Describtion of the show into the database so you have a full 
list by clicking on a more button on you remote control and state such 
as set_to_record/recording/Unwatched/watched/deleted/or anything else 
which I could think about with a setting in the settings file on when to 
delete from the database.  Also that could be used to setup a system to 
indecate if I watched a show but my wife hasn't

>How's that for a wish list?  Can you get all of that in before 0.7?