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

[Brian J. M. <1a3...@in...>]

> Is this the version of the scheduler that's on CVS as the .c file?

Yes.

> That's what I was thinking, until I sat down with a pen and paper and Vis=
io
> and started to map out the logic of scheduling.  I think I might be
> overcomplicating it a bit.  My idea was to use 1 minute slots for each tu=
ner.
>  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 m=
eg
> file.

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

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

> What I don't like about the Tivo is it's insistance that if I put in a
> 1-minute "slop" buffer at the end of a program, it's not going to record =
the
> program that comes after it.

I have not used a "slop buffer".  I have my machines synced to NTP on
the Internet and have been quite surprised at how well timed
scheduling is on TV.  I don't think I have ever lost a program ending
due to not having the slop buffer yet.

> Yes, I was thinking of that as an option.  I'm going to have to see if the
> data is plaintext or if it's encoded in some way.

Oh I would be much surprised if it's plain-text.  It's a
feature/service that Gemstar licenses to make money on.  I have only
seen it on a couple of brands of TV/VCR like RCA.  If it were
plain-text (free for all) I am sure every TV being made today would
have it.

> If you follow the Tivo and Replay model, then essentially they're always
> recording on the off chance that 1)  You want to pause live TV, or 2) You
> want to save the buffer

Yeah, I know.  I am not doing this yet.  I only record programming on
demand.

> I think that at a minimum we should make sure that there's good sync over=
 a
> 2hour time period.  That way you can watch movies.

I have no reason to believe that mp1e will drift over 2, 3 or even more
hours.  There is no evidence of even a hint of drift with 1 hour
programs.

> I was also thinking about a "hints" file.  For example, the Daily show is=
 on
> 4 times a day, but only the one that comes on at 2300EST is the "premiere"
> one.  The ones that follow in the 24 hour period after that are re-shows.=
=20

This is excellent!  Repeating of programs is great for scheduling.  It
increases the odds that you will get everything you want.  It is the
other reason to only specify programs, not "when" to the scheduler.
It will record all of the programs you want at their first opportunity
(i.e. greedy), but if there is a conflict will record a repeat of a
program when it is next on.

> I've looked at the XMLTV data for TDS, and there doesn't appear to be any
> coding of which episodes are repeats.  Same thing for "Talk Soup", etc.

That is what the "seen_programs" database is for.  It keeps track of
what you have seen (more likely what you have recorded -- what you
have seen will depend on the gui keeping track of what you are
watching) so that you don't record programs more than once.

Right now you have to update seen_programs manually.  I will add code
to the scheduler to update it when it schedules something soon.  Later
when the gui for watching is functional, it will update seen_programs
when something is watched.

> The Tivo has the same problem with its guide data.  The way I capture it =
now
> is to put in a manual recording for TDS that runs M-F, channel 42, 2200-2=
230.
>  Works great, except TDS doesn't run on Friday, so I need to go in manual=
ly
> and delete that recording so that I don't get "Comedy Blend".

That is exactly the headache I want to avoid.  When I first started
this project I was just looking for Digital VCR capability (timeslot
based recording) but the idea of recording programs instead of
timeslots is far superiour.  Of course, timeslot recording should
still be available, but program recording should be the norm.

> I think that the user should choose, and it doesn't have to be anything t=
o do
> with the categories that come in over the wire with XMLTV.

Right.

> Are you doing NFS, moving the file over, or something else?

NFS.

> The Replay 4000's uses straight-up HTTP, sending the file across in chunk=
s.=20
> What do you think of this as a streaming method?

Sounds good enough.  HTTP is just a TCP stream after the handshake and
file request.

Wow, replay 4000 is just HTTP huh?  Any idea what format the file is
that it streams to you?  Standard MPEG2?  Sounds like that would be
sweet for building a network of players out of Linux boxes.

> Concur.  That's why I said far future.

Future or now, it doesn't change the privacy problems.

> I didn't say all my ideas were good!

It was not a bad idea.  I am sure there are some people who would give
up that privacy aspect to get that kind of information.

> That's why I put it in the "Don't think it's important" column.

:-)

> I was looking at IR as well.  Of course, in my visio schematic I have a
> decision tree: "Do we need to blast IR?" to take care of external tuners.

Yeah, I have thought very briefly about that.  I have noise problems
on my captures that I think would go away with an external tuner.

> I
> was looking at the various LIRC projects, and then StreamZap caught my eye
> http://www.streamzap.com  - the nice thing about the streamzap is that for
> $40, you get a USB IR receiver, and a remote that sure looks an awful like
> the Tivo peanut.  No idea is the USB receiver is supported yet, and I did=
n't
> see streamzap listed on the LIRC page for remotes they know about.

Check out irman: http://www.evation.com/irman/.  US$35 and it works
with any normal remote.  I don't care to buy yet another remote.  I
want my "universal" to work my PVR as well.

> Switched to rocketmail.

Thanx!

b.

--=20
Brian J. Murrell