Re: [Openpvr-devel] Re: ongoing development, ideas, etc

[Robert K. <rku...@ro...>]

> >  Earlier, I was think that this would be a huge waste, but then I noticed
a few things:  1)  a two week pull of guide data using XMLTV was only a 4
meg file.

> ~800MB if you gzip it.  My scheduler uses gnome-xml, which can read
> gzippd xml files.

Hrmm.  Really?  Almost 1 GB?  I just did a 14 week download of my headend and
it was 8 megs.  (My earlier 4 megs estimation was because I forgot that the
default for _grab_na is 7 days.)  Are you downloading something like a
DirecTV headend?

What are other people getting?

> > 2)  1440 slots per day per tuner * 14 days of guide data is still not
> > a huge amount (anymore, since we're talking PCs and even 64MB will give
> us
> > some elbow room)
> I'd watch that assumption.  My scheduler will grow to 90-90MB of
> memory usage once the whole XMLTV file is slurped in.

Do we want to start discussing the algorithm for scheduling?  While I may not
be able to crank on the C code like Brian has I'd still like to feel like I
can contribute.

I guess there are two possible cases to consider:
1)  The single tuner model
2)  The multiple tuner model, where the tuners may not necessarily be in the
same PC

To me, I think it's pretty important to consider the multiple tuner model.

Also, to see what others have done in this area, I've been poking around. 
The cheema.com site seems gone, and neither google nor the wayback machine
have anything for the site.  Too bad.

I've been taking a look at the LinuxTV project over at http://www.linuxtv.org
and http://www.cadsoft.de/people/kls/vdr/index.htm to see what they've come
up with.  Their project is tightly tied to MPEG2 hardware encoder cards, and
appears to be a mostly European project.

One interesting thing that they did is the "SDRVP" protocol.  It uses
ascii-text like commands, so that control of the VDR is possible through
telnet.  It might be an interesting idea to crib, and could be used between a
group of PVRs as a means of scheduling, etc.

The way they handle the multiple tuner model is to have a primary and then
slaves.  The primary is used as the main tuner, and it's what's displayed
onscreen.  If there's a program recording coming up, it gets put to one of
the secondary tuner cards.  If there are no secondaries available, then the
primary is used.  Collisions are handled through on-screen prompts, and a
timeout.  If the timeout expires (user isn't watching TV), then a priority
scheme is used to decide what gets recorded.  The priority scheme is also
used to decide what gets deleted when disk space is running out.

If the primary is recording something, and a channel change command gets
sent, and there is a free tuner available, the recording job gets handed off
to a secondary card and the primary then changes channels.  They state that
this isn't a clean transfer in the sense that there's going to be a gap, so
the docs recommend changing channels during a commercial break.

They do have all the "trick play" functionality working, along with
multi-speed FF and REW.

What they don't seem to have is a good scheduling mechanism.  The EPG is
derived from in-band EPG data - no XMLTV or other scrapers are used.  They do
have a flexible means of setting recordings, but it's still time-slot rather
than Show name based.  Their program picker lets you choose a repeating
program that may not run M-F, like The Daily Show, for example, so you can
say that the show is on M-Th only.

They also have a pretty good OSD.  I can't tell whether the DVB cards that
they use provide analog video out, or if they're using a TV-out video card.

Recording is done in 2GB chunks.  They have an editing mechanism that allows
cutting commercials out of recording through mark-in and mark-out points.

There's also a web-based controller.  See
http://www.linvdr.org/download/vdradmin/shots/ for screen shots.

Other stuff:

I'm curious as to how something like the Replay 4000 is able to determine
where the commercials are.  The Replay doesn't have a lot of CPU horsepower,
so I'm assuming that it's monitoring what the video encoder is doing, and
when it starts recording a whole lot of black (or fade to black) it records
an entry into an index file that says "possible commercial start at block X".

The .ndx file is also used for executing forward and backwards skips.  I
believe that the .ndx file is keeping track of the GOPs so that it knows
where the I frames are.


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/