Re: [Openpvr-devel] On-going development; ideas, etc.

[Brian J. M. <f21...@in...>]

On Thu, Mar 14, 2002 at 09:46:47PM -0600, Dave Caplinger wrote:
>=20
> Yep, I picked it up for $30 (and it has stereo audio and came with the=20
> remote, as well as an FM tuner I don't care about.)

Good deal!

> I've been trying to keep up with NVrec; it's nice that it puts the same=
=20
> front-end (cmd-line) interface on the various encoders since it makes it=
=20
> easier to compare, but I haven't played with the recent ones lately.

I did the same thing.  In CVS there is a utility called "record" which
accepts an easy to use, unified list of cmdline switches and
translates them into the various native cmdline switches for a handful
of encoders -- mainly the ones I have been interested in.

That way I can easily switch from one encoder to another without
having to try to remember how the switches work.

> It figures... I just tried to go to his web site and now I can't reach=20
> it (www.cheema.com/vcr).  I added it to the OpenPVR wikki a few weeks=20
> ago; sorry if it's gone forever now. :-(  It was a nice web front end to=
=20
> view a TV schedule, and click on a program to schedule a recording of=20
> it.  Exactly the kind of thing that my wife would have no problem=20
> understanding and using to select shows to record.  Also you could see=20
> what was previously recorded and click on it to stream it to your=20
> computer for viewing. (It was designed for a client-server approach to=20
> PVR, and he was/is doing his viewing on a PC, not a TV, but the schedule=
=20
> browsing was nice and clean (just text and tables, no distracting=20
> graphics etc).

Sounds nice.

> Yes, I'm eager to try this out.

Let me know what you think.  I do have to find some time to get things
a little more polished.  Like not keeping the xml files in /tmp, and
cleaning out some debug, etc. but I use it daily to set up my own
recording.  It just spits out the 2 weeks worth of recording as "at"
commands and I cherry pick them daily and enter them manually -- until
I am happy that it is working correctly.

> Well I tried framebuffer first but I had all kinds of problems with the=
=20
> i810 framebuffer driver.  Granted that was several months ago so maybe=20
> things are different now.  If I can get it working, you're right that=20
> DirectFB sure looks nice :-)

The only thing about DirectFB that I am a bit worried about is
overhead.  On a card well supported by mplayer, like the G400 or
Radeon, the CPU used for video display is negligent.  I fear that
DirectFB will add some to that.  I still have to go back and play with
DirectFB some more.  Currently I am using mga_vid with mplayer.

> Well yes, but in the "X-Files marathon" case there are a TON of X-Files=
=20
> episodes that I have in fact seen, but there is no way I'm going to=20
> manually enter 8 seasons worth of data into my PVR just so it won't=20
> won't record them again.

~grin~  http://epguides.com/  It takes some hacking to get it into the
seen_programs xml format, but a vim macro or two takes care of it.  A
perl program to convert all of the episodes of a given program into
the xml file should be trivial.

> (There's lots of stuff that I've seen in my=20
> lifetime that my PVR will have no clue that I've seen since it never=20
> recorded it.)

See above.  Now if you have only seen "some" episodes and you want to
try to see the ones from previous seasons that you have not seen yet,
it gets ugly, but in most cases, for the stuff I watch, if the episode
is a year or two old, I don't much care to see it.  In other cases, I
have been watching the show religiously enough that I can assume I
have seen all previous episodes.

> Agreed; I just didn't expect this feature as part of the "base=20
> functionality" I am trying to get to.

Neither had I.  Until I started thinking about it, and then found
XMLTV, and then I said what the heck and coded it up.  Now it's the
best thing I did in this whole adventure.  I love it.

The only one part about it that does not work well yet is that not all
programs (coming from XMLTV which means zap2it in North America) have
"sub-titles" (episode names) and they are repeated so you wind up
getting the same episode more than once.  The scheduler just inserts
the "seconds since Jan. 1 1970" Unix time in there.  I have been
thinking of allowing the user to define a mask to name episodes with
if there is no name given.

I think being able to use some of the specifiers available in the
"date" command could figure this out.  So if you know that all of the
"untitled" episodes of "Foo" in a given week (Sun-Sat) are the same,
you could give a mask of "%U-%Y".  Once it had been recorded once that
week, it would not be recorded again until next week.

Where this breaks is if the programs are repeats from (say) Wed-Tue of
the following week.  Or if there are two different episodes a week,
repated Sun-Wed and Thu-Sat.  I need to give this some more thought.

> I'd be thrilled to have it of=20
> course. :-)

'Tis nice.  :-)

b.

--=20
Brian J. Murrell