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

Robert Middleswarth mythtv-dev@snowman.net
Thu, 31 Oct 2002 01:29:02 -0500


I will try an clairfy as much as I can.  Wrote most of this well at work 
so my thought were alittle disjointed sometimes.

Craig McLaughlin wrote:

>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... 
>
You are right that 1 Well Comprised Video Signal could be sent from a 
Video Sever to a Video client without to much trouble. but we aren't 
talking about that.  We are talking about multipule pc talking back and 
forth.  So 1 PC could be asked to Xfer Saved data and Xfer Live Data and 
Receive Live Data using a Codec that was designed for speed not size. 
 Althought we are talking about 100 based network cards they do start to 
slow down in the 3-4 Meg range.  Granted if you are talking about 1 
Machine for Encodeing and 1 Machine that only displayed then yes there 
would be no problem but that isn't what Mythtv is doing at this time and 
if I read right not what  Robert Kulagowski was talking about.

>>>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
>finished...
>
Please note I use the term AI in very generic way.  I think you are 
right I mis-read what he was asking . :-[   I think you are right about 
that being rather easy to do althought it opens a few questions about 
recording on the same channel.  Example how would you handle 8:00 PM 
Seventh Heaven 9:00 PM Everywood both show are one hour long on the same 
channel.

>>>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.
>
>
>Cheers,
>--Craig
>  
>
I think I got the last two sections mixed up.  That should teach me for 
responding well I was at work.  Don't get me wrong I think some of his 
idea are great and never hurts to talk about it I was just putting in my 
$.02.  If there is good esponde guide info then there should be a no 
problem as the system will see same episode descriptions and wont record 
but when there isn't a usable description and all that is list is the 
shows name 5  times a day.  Figuire out which one to record and which 
one not to may not be so easy.  The code to try and sort that out would 
require some form of comprise to make the code generic enfo to be used 
in the project.  Tring to make a system that would pick 1 of those 5 
would require more work that to just simple enter the data into a VCR. 
 Try and make something that would learn that 22:00 is best but if you 
can't due 22:00 then do 14:00 instead would require either alot of user 
spefic code and/or make some assemptions like only record 1st/last/x 
time of a certain show today which would add complexty to the interface.

Sorry I wasn't as clear as I had ment tobe.  It is getting late now and 
I need to get some sleep.  I hope this replay is more clear on what I 
was tring to say.

Robert