vdrpylib-devel

[vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

Hey, 

I hadn't noticed, until today, that this project was under new 
maintainership.

I was wondering if there are any outstanding patches that have been on the 
list but can't be accessed via the sf interface that might fix a few 
things that break with my setup.

Also, whilst I'm thinking about it, does anyone have a cunning idea how to
share a vdr object amongst multiple python interpreters? I got the
previous version running a few months ago and reading in all the epg data
took up about 30-40MB of memory which multipled by however many clients 
are connected doesn't scale too well!

cheers,

d.

Re: [vdrpylib-devel] pending patches?

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

Dominic Morris wrote:
> Hey, 

Hi, welcome to the list.  Sorry for the late reply.


> I hadn't noticed, until today, that this project was under new 
> maintainership.

Yep, I'm working on another project that I've been using it for and 
decided it would be easier to maintain vdrpylib than to send patches to 
a dead project. ;)


> I was wondering if there are any outstanding patches that have been on the 
> list but can't be accessed via the sf interface that might fix a few 
> things that break with my setup.

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?


> Also, whilst I'm thinking about it, does anyone have a cunning idea how to
> share a vdr object amongst multiple python interpreters? I got the
> previous version running a few months ago and reading in all the epg data
> took up about 30-40MB of memory which multipled by however many clients 
> are connected doesn't scale too well!

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.

-Rob

Re: [vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

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!

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

> 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!)

cheers,

d.

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

Re: [vdrpylib-devel] pending patches?

[Dominic M. <do...@su...>]

On Thu, 6 Jan 2005, Rob Shortt wrote:

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

Sure, here's the entries from epg.data:

C T-9018-4100-4351 BBC THREE;BBC
C T-9018-20480-22272 UKTV History;UKTV
C C-0-109-62007 UKTV Gold
C C-0-111-62009 UKTV G2

[there's some analog TV ones in there as well just to be comprehensive,
they're mapped through as Cable channels], the corresponding channels.conf
entries are:

BBC THREE;BBC:505833330:I0C34D34M16B8T2G32Y0:T:27500:0:0:0:0:4351:9018:4100:0
UKTV History;UKTV:578166670:I0C34D34M16B8T2G32Y0:T:27500:401:402=eng,404=eng:0:0:22272:9018:20480:0
UKTV Gold:109:C0:C:0:100:101:0:A0:62007:0:0:0
UKTV G2:111:C0:C:0:100:101:0:A0:62009:0:0:0

The following bit of code generates the correct id for use with streamdev
from data in channels.conf (sid is the appropriate channel id):

def channel_parse(string,num):
    tokens = string.strip().split(':')
    namtoks = tokens[0].strip().split(';')
    name = namtoks[0]
    freq = int(tokens[1])
    source = tokens[3]
    vpid = tokens[5]
    apids = tokens[6]
    ca = tokens[8]
    id = int(tokens[9])
    nid = int(tokens[10])
    tid = int(tokens[11])
    radio = 0
    if vpid == '0' or vpid == '1':
        radio = 1
        if apids == '0':
            radio = 2
    if source == 'T':
        freq = freq / 1000
    if nid == 0:
        m = map(str,[source, nid, freq, id])
        sid = '-'.join(m)
    else:
        m = map(str,[source, nid, tid, id ])
        sid = '-'.join(m)
    return ( num, name, sid, ca,radio)


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

Python is used to generate the ui and handle the user interaction. Each 
connected MVP causes a new interpreter to be spawned in an individual 
thread. The main thread consists of an event driven C library handling the
network connections. All that's running on the MVP is a dumb client 
displaying a pushed screen and pushed media stream.

The MVP has only got 16MB of memory so I'd like to keep most of that for 
buffering the streams rather than using it up generating the ui etc.

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

That's where my original question comes from, there's no chance of sending 
the raw epg data to the MVP, but keeping a separate copy for each thread 
seems a little ott as well. I'm favouring the querying a database 
approach, I just need to do a bit of investigation into a pyepg based 
solution.

> Maybe Vlad (Sebastien Lucas) can add his 2 cents, I think he's doing 
> something similar for the xbox (XBMC?).

That would be good to hear how someone else is tackling the problem.

cheers,

d.

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