Re: [vdrpylib-devel] pending patches?

[Rob S. <ro...@in...>]

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.


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


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


-Rob