Rob Shortt wrote: > Hi, Hi
I had no time to look at the code yet, but I still have some comments about it (maybe reading the code would help) > In an effort to simplify thing's a bit I've removed the old channel_id > from the EPG. Instead, a channel will be uniquely identified by its > name only. What is the name if not the channel id? > The database also has fields for long_name (not used by any > Freevo UI yet) that is more verbose, and a field for tuner_id. The > tuner_id is a list that holds possible ids for tuning a channel. A > tuner_id is something the tuner/recorder uses to identify and tune a > channel. For analog tv this is used to map a frequency, for DVB is can > be a service id, or sometimes a name. Because the tuner_id is not > always right for you depending on where you get your guide data > (different XMLTV sources, etc), and sometimes not present at all, this > field is only used to help programs/users match channels in the EPG to > channels their devices provide acess to. How do you know the difference between tuner id and name? I have a channel called N3, looks similar to the tuner id C50. And xmltv only has display names and tuner ids are part of it. So maybe a channel has no real name in the db and only a list of possible names. When updating from different sources, try to find at least one match to merge the sources. And if freevo-tvdev says something about a possible channel S50, try to find that "name" in the db. > The epg2 server.py can be run on the command line to start a server > instance which will listen on a local unix socket and optionally on an > inet socket (but be careful with your network). As I wrote before, I don't like the idea of making a pickle ipc interface public. IMHO the best way would be to use kaa.ipc for internal communication when we move stuff out of a lib and mbus for global communication between programs. So we have two choices here: 1. Use kaa.epg has interface and do not care that it is a different process. This is done by kaa.vfs and kaa.vfs will start a server if needed and stop it when you are done. Communication is kaa.ipc, but you don't see it. 2. Define that we have an epg server. Communication is mbus and you have to start the server on your own. > I added src/ipc/epg.py. As discussed, this may move to a new location > but for now is at least in a common place. This module will use it's > own config file (/etc/freevo/epg.conf) so we don't have to repeat EPG > config items in every other config file. What config is needed? I thing we will have one epg master in the network and this is the tvserver. The tvserver epg needs some config like sources and how to access them. All other parts like freevo-ui or webserver only _use_ the db with the help of kaa.epg. And it is possible to have more than one db (if you have more than one pc). The other apps will sync the db with _one_ source (and you can't change that) and that is the tvserver. > I may rename that function to guide() because kaa.epg2.__init__ > maintains a copy that gets returned. By using > guide().get_channels() (etc) we can avoid problems with the server > going away. I also also thought about that. Whay happens if the server is gone. Well, first of all, it is a bug because the server can't die. But if something 'kill's the server we need some way to restart it. But right now I thing: use the server and if it is gone, crash to make sure we see and fix the bug. > Of course, changes here reflect the kaa.epg2 changes. These changes let > us match channels reported by freevo-tvdev to those in the EPG easier, > and the only ones written to the epg.mapping in the config file are > those it can't find. The user can also add ones to the mapping to > override potentially bad guesses. OK. > There's a new script, freevo-epg, that can be used as a client to update > the EPG information based on config options, and search the guide. Maybe the update should be part of the tvserver, like calling 'tvserver --update-epg'. And the epg search could either be part of the tvserver interactive mode (-i) or an extra parameter (or both). > -Merge programs better and detect shifts in the schedule. Right now > there may be problems when adding a program that just moved by a few > minutes. Why? You remove the old and add the new. Where is a problem? > -there's an exclude_channels variable you can pass but it's not used > yet. Make this work, ignoring (don't add to DB) matching channels. Why? You can add all channels to the db, but Freevo should only show the channels we have a tvdev for. So when channel 1 to 10 are in the db but the tvdev only reports 1 - 5, you won't see the other channels in freevo. > -Maybe add a channel_aliases variable in case we have a channel from two > devices or EPG sources that name the smae channel slightly different. IMHO that should be part of the 'names' a channel has (see above). So I channel may have the names 'ProSieben', 'Pro7', 'Pro Sieben' and S50. > -test favorites, this may need more work > -add an mbus call to return a list of channels that have been reported > by freevo-dev. The UIs can use this information to only display > channels that you can use. Yes > -add channel_aliases? I don't see a reason why > -fix freevo-epg update for multiple sources, which should run in serial. OK > I didn't touch this yet so I need to make it use epg2 as well. I think > I can do this today still. That would be great. Well, when moving to kaa.canvas, most of the code needs to be rewritten anyway, but making it work before that would be great. Dischi -- Never let a computer know you're in a hurry.
pgp52qeBDschD.pgp
Description: PGP signature
