Rob Shortt wrote: > That's good news. I haven't tested it out yet because my electronics > are covered by a sheet of plastic as I finish the theatre room. It > will be back in working order in a couple of days. I may bring my > Freevo box with the EPG on it into the office to do some work on it in > the meantime.
Current status which will be in cvs soon: the recordserver is working
with the following limitations:
o only one record plugin is supported right now. You can have more,
but only the first one is used.
o because of the limitation above: you can only record one program at
a time. A conflict will result in one recording beeing not
recorded.
o you can't remove favorites (only by editing the xml file and by
doing that, recordings based on that will still be in there)
And the interface to Freevo is not finished.
o you have no visual feedback, the recordings are not shown in the
guide, not in the extra listing in the tv menu. You often see a
recordserver is down, this is because most parts of freevo still
expect a xmlrpc server
o favorites will always be 'any channel', 'any day' and 'any
time'. You need to change that in /var/cache/freevo/recordserver.fxd
and than restart the server.
o Freevo may crash when browsing the guide
> Question: Recordserver is keeping its own list of scheduled
> recordings?
Yes: /var/cache/freevo/recordserver.fxd has a lsit of recordings and a
list of favorites.
> If so, it really doesn't have to, and really shouldn't. That part is
> built into (ok, almost build into) pyepg now. There is a table called
> record_programs that has a single column which is a (unique) program
> id. To get the list of scheduled recordings pyepg would run SQL
> internally: "select * from record_programs". This statement will of
> course be wrapped in a method like get_scheduled_recordings() (maybe
> with options to get by channel or time frame).
OK. Since you know the epg stuff better than I do, can you change
that? You only need to change the load() and save() functions in
server.py. One problem: if something changes the recordings in the
database, the recordserver has no way of knowing that. For favorites
there is a rpc call update to force the recordserver to recalc the
recordings based on a new epg. Please take a look at record.py and
favorite.py in src/record what variables they need, I don't think you
have them all :)
> I know we talked about that on IRC and both decided we can leave that
> for a later date so having recordserver keep a list of recordings for
> the short term is fine. What we shouldn't do it change our interfaces
> to complicate things when we do it the "right way".
OK.
>> So far so good. Now a problem. Rob: that's were you come in :-)
>> How to identify a channel? My TV.xml file (auto generated) has the
>
> Do you generate your own TV.xml? If so then you may choose _any_
> unique string for the id, Pro7 or ProSieben.
I use a xmltv grapper.
>> following settings for one channel: id is prosieben.de, display name
>> is PRO 7 and the dvb name is ProSieben. I want to name it Pro7. (BTW,
>
> By "dvb name" are you referring to what you have in the first field of
> your channels.conf for VDR or mplayer?
Yes. They are different from the id and display name in my xmltv.
>> 7 == sieben in Germany). So we have 4 names for the same channel plus
>> a freqence for analog which is similar to a name.
>
> The named frequency for analogue is the tuner_id. Freevo has
> frequency tables to lookup the real freq in MHz/KHz.
I never unstood that. Please add some doc to it. And we need a huge
cleanup in src/tv. The recordserver needs _nothing_ from that dir. It
will need the tuner_id, but I can't test it.
>> The egp databse uses the xmltv id as key (here prosieben.de). But the
>> recordserver has no way to get the real channel name, he doesn't know
>
> By real channel name do you mean '8' for analoge or 'ProSieben' for dvb?
Yes.
> I can add a method to channels.py or pyepg to return a channel_id
> based on other information but I think that the list of scheduled
> recordings should contain the id instead of (or in addition to) the
> display name. Each program in pyepg contains a channel_id of the
> channel it's on as well. The recordserver doesn't need to know the
> "name" of the channel, just an id to find out which URI it is
> available on (tv0:xxx or dvb0:xxx). Deciding which URI to use is the
> complicated part, and sometimes must be determined at the moment the
> recording starts.
OK. The recordserver uses the id. It doesn't need a display name, it
only needs the channel name when starting the recording.
> When we (you :)) added support in TV_CHANNELS to support the different
> URIs like tv0 and dvb0 we eliminated the need for these mappings. If
> you want this channel available on an analog card and DVB card you
> would have this in TV_CHANNELS:
>
> (channel_id, display_name, URI or tuner_id)
>
> ('prosieben.de', 'PRO 7', ['tv0:8', 'dvb0:ProSieben']),
>
> If your only capture device is dvb0 then this would do the trick:
>
> ('prosieben.de', 'PRO 7', 'ProSieben'),
Right, I remember :)
> We should keep talking about this.
Yes.
Dischi
--
C.O.B.O.L - Completely Obsolete Boring Old Language.
pgpqw0CMOnJ1l.pgp
Description: PGP signature
