Re: [vdrpylib-devel] pending patches?

[Sebastien L. <seb...@gm...>]

On Thu, 06 Jan 2005 12:48:40 -0400, Rob Shortt <ro...@in...> wrote:
> Dominic Morris wrote:
> > On Thu, 6 Jan 2005, Rob Shortt wrote:
> >
> >
> >>Hi, welcome to the list.  Sorry for the late reply.
> >
> > 
> > No worries, I'm still on hols, so I've got time on my hands to hack, if
> > only I could decide on one thing to do at a time!
> 
> LOL, I have the same problem.

Same problem here ;)
 
> >>There is a patch from Vlad here which contains some changes which I may
> >>include.  I haven't gone through it all yet because on my vacation
> >>(which just ended) I decided to goof off instead of hack.  What issues
> >>are you having?
> >
> > 
> > I can't read the EPG in - I'm using DVB-T and the channel ids don't match
> > up with what the code expects! Timers are also unreadable, probably due to
> > the same issue, rather than digging in and re-solving it I thought I'd ask
> > to see if someone else already has.
> 
> Ok, I don't think this lib has ever been developed or tested with DVB-T
> and I was afraid this would be a problem.  Can you followup with a few
> examples of the DVB-T channel ids?  I will also look at the man page for
> them.  Do you know of any other differences between DVB S/C/T as far as
> the VDR config is concerned?  I will update the code for this asap.

My patch should fix this (the channel ID was badly build in some
cases). I had the same isssue (problem reading EPG) with my DVB-S. My
fixed vdrpylib at least works with DVB-S and DVB-C here in France.
Maybe DVB-T is different but I don't think so.

> >>It sounds like you should build a server process which is the single
> >>point of communication to VDR.  In my other project, Freevo
> >>(http://freevo.sf.net), we are working on an EPG library (pyepg) which
> >>can use vdrpylib to fill its database.  You may be interested in that
> >>sort of thing.  I have also been working on a client-server
> >>implimentation of pyepg but that part is specific to Freevo so far.
> >
> > 
> > I always like the idea of leveraging 3rd party code, it seems the
> > client-server implementation might be the most appropriate idea for my
> > project (vdr-mediamvp) whereby the database resides in one process and the
> > rest of the server in another. I suppose the obvious question regarding
> > that is why couldn't the database be just another vdr module to avoid
> > holding two sets of the same data (apart from having to write the code
> > myself of course!)
> 
> I've read up on vdr-mediamvp a few times as I would like to get an MVP
> myself - cool project.  BTW how much python does it use?
> 
> I can see how in this case you wouldn't want to have redundant sets of
> data.  If you think about it though, reading the whole EPG with each MVP
> client is kinda doing the same thing.  How much memory does the MVP
> have, 30-40 megs to keep the EPG around on each client does seem like a lot.
> 
> Perhaps by only reading small parts of the EPG as you need it would work
> better, not that vdrpylib supports that atm.  You could also acheive
> this by writing vdrpylib-aware code on the server side with a custom
> client-server interface for vdr-mediamvp (with or without pyepg) to
> request EPG data in small chunks.  Either way you'll have a redundant
> pool of data but its best to have only two, both on the server, I think.
> 
> Maybe Vlad (Sebastien Lucas) can add his 2 cents, I think he's doing
> something similar for the xbox (XBMC?).

Yes I work with XBMC. 
The script is currently only alpha so not really tested by a lot of
users (only 2 or 3 guys from a french forum).
For the EPG, I only read EPG when needed and only what is needed. I
also have a thread running each 10 minutes wich remove old EPG events
(it was mainly for the fun, it was my first with thread and python).
With that I never had any problem with EPG even if the Xbox has only
64Mo of memory. Once again the has only been tested by 3 guys.

Hope I'll got more time this year (that's my new Year wish :D).