Hi,
Hi Dischi,
I want to give a small update on the recordserver in cvs, a small request to Rob and a small thing to think about.
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.
Let's beginn with the good news. The recordserver on my machine can
now: add/delete/list recordings and add/list/update favorites. A
favorite is added to the recordings based on the pyepg database. When
you delete a recording based on a favorite, it won't get reinserted
again by an update (Oops, that reminds me: you can't add it ever
again, need to fix that). The communication is based on mbus and very
fast.
Question: Recordserver is keeping its own list of scheduled recordings?
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).
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".
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.
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?
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.
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?
if there is xmltv or not. So I suggest we use the display name I want to see as db key (here Pro7, but it can also contain spaces). Than we use the following variables:
As you said, recordserver doesn't know about xmltv, nor should it. No part of Freevo should know anything about xmltv (besides what is needed to run tv_grab), just pyepg. Even pyepg's external interface should have nothing to do with xmltv, the only xmltv logic should be parsing the TV.xml to fill the pyepg database. One of the requirements of the DB is that it be generic enough to support TV data from multiple sources.
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.
XMLTV_NAMES = { 'prosieben.de': 'Pro7' }
The pyepg should do the following: use the xmltv key to parse the file. Than get the display name. If there is a key in XMLTV_NAMES matching the id, take it. If not, use the display name from TV.xml. Now, the db doesn't have to know about prosieben.de at all. When you record, you record on your display name (Pro7). Now the recordserver needs to know how to record Pro7. For that we could have
I don't think we need this kind of pyepg <-> freevo interaction and its not good from an architecture point of view.
All prosieben.de is is a unique identifier for that channel. This id can be anything you like, you could use Pro7 or ProSieben. The other columns don't have to be unique. If you use a 3rd party xmltv file and don't want to rewrite the id we could have an option in tv_grab and pyepg for filling the DB with data to use another attribute for the channel id.
DVB_MAPPING = { 'Pro7': 'ProSieben' }
The dvb plugin will try to find the name in DVB_MAPPING. If found, use it. If not, try our display name. And we need the same for analog tv
FREQ_MAPPING = {'Pro7': 8 }
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'),3 variables sound like too much to config for the user. But it is the
easiest way. And having fallbacks makes it much easier. And Freevo can
guess something from the xmltv file like it is doing now. And we could
add the country support. I will write a file for Germany having the
following informations:
XMLTV_GRAPPER XMLTV_NAME DVB_MAPPING
I think DVB_MAPPING and FREQ_MAPPING are too much config for the user and are redundant to other existing solutions.
So the user only needs to set country=germany and dvb is working out
of the box. Rob: can you change pyegp to use the display name as key?
It will be much faster if you do it since you wrote it (and know
SQL).
I agree that setting the country and have everything just work would be great, and we should work towards that.
I don't want to change pyepg to use the display name (call_sign) in the DB as the key, the whole purpose of the id field it to be a unique key for that channel (in pyepg or any app using it). Actually there is no actual display_name in the DB but call_sign.
Freevo creates the display name (in ChannelItem) based on the tuner_id and call_sign from pyepg as a bad default. We either need to define some rules or user preferences for Freevo to decide the display name or do the same for pyepg and add a column in the channels table for it. At first I wasn't worying about the display name in pyepg because that is a user interface issue and maybe it should be left up to Freevo... I can see how we would want it in pyepg though.
We should keep talking about this.
-Rob
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
