Dirk Meyer wrote: > Rob Shortt wrote: > >>>What is the name if not the channel id? >> >>The name is the actual channel name like "ZDF" or "PRO 7". The idea >>here is to keep things as simple as possible. I don't think it is worth >>using the XMLTV ID internally, it is only something needed by the XMLTV >>data structure to match programs to channels. We have our own internal >>ID in the database to do that job. Besides, different XMLTV sources, >>and also non-XMLTV sources will use different IDs. We know about a >>channel based on its name. > > > But maybe I don't know the real name. You guess the name for xmltv by > using the display-name I try to find out the name and the tuner > id. But we will see....
Right, it is posible data source doesn't have the name quite right, or how you like it. WIP I guess. >>>So maybe a channel has no real name in the db and only a list of >> >>I think we need a difinative name in the db, this way it has already >>decided what will be used as the name in any potential UI, making >>display less complicated. > > > Is it complicated for the ui to just take a look at the current > display names in the db for each channel to detect what the real name This is kind of what happens when the channel is added to the guide. > is? I mean, based on my sources what you think is the display name may > be wrong. Maybe the user wants to set his own name. So maybe a unique > id (integer) is the primary key and the name can change. Possibly. Maybe the user setting should be kept in config so it won't be lost with db changes, or if db must be removed. >>>possible names. When updating from different sources, try to find at >>>least one match to merge the sources. >> >>Right now merging sources works by name only. If you have two sources >>with different channel names they are most likely different >>channels. > > > OK, maybe add a way to set some extra mapping logic by the user. Yes, that's what I meant by using channel_aliases or epg.mapping. Maybe there could be a config object to represent some aspects of user defined channel information. >>However, I do have channels from different sources that have different >>names. Right now these are also seen and listed as different channels. >>This is one thing that a user defined channel_aliases would take care >>of. > > > What is the difference between your tuner ids from the xml file and > aliases from the user? They are there for the same reason. So a > channel should have a unique id, a name that can be changed by the > user and a list of access ids (all display-names from xmltv, alias, > etc). I guess they are pretty much the same but I prefer to use the name (as guessed by the source_XXXX.py / parser) as the unique key for db channels. >>There is no way of telling this without user input. We could get >>all complicated and compare all of the program entries for different >>channels and decide that if there's a 95% match then the channels are >>the same, etc. Maybe in the future, but for now I think this is the >>best way. > > > Trying to guess based on current data sounds like the way to go. But > for now the manual stuff is ok. agreed >>>>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. >> >>I know. This is disabled by default for this reason. I (and many >>others) run Freevo on an internal network with a firewall. I'm not >>worried about someone on my network trying to do nasty things. > > > Well, it may be ok for you, but I don't want a public 2.0 release out > there with a huge security risk. You know what you are doing by > choosing this kind of communication, others don't. OK, I can respect that. I still need a networked EPG that performs well. I also forgot to mention the need to support diskless clients - no disk to store local db. >>>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 would prefer something more like 2, but I don't think mbus is suitable >>for EPG data is it? > > > Yes and no. Right now mbus has the limitation that the message has to > fit into one UDP packet. That may not work when you try to get the epg > for the whole day on all channels. Sometime I can do some more tests with the EPG and mbus. With epg1 architecture it seemed to take too many resources disassembling objects into mbus messages, then reassembling on the client. Maybe this will be better in epg2 since it may be hooked into the GuideClient _load() easily. DB rows are a lot like mbus messages. >>I really like the behaviour of kaa.ipc right now, the only problem >>we have right now is security. I don't think we should put too much >>effort into another EPG rewrite before Freevo 2.0. > > > Before 2.0 pre1 no, but like I wrote above, we need a clean secure > solution for the final 2.0. But that won't be a rewrite, only a change > of the communication layer. Ok, we will keep at it. >>>>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. >> >>All clients will need to pass the correct into to kaa.epg2.connect(), >>this includes the db file, optionally a network address, a log file, and >>log level. > > > Logfile and loglevel should be clear by just using freevo on top of > kaa. And db or network, yes, that is the only option. > > >>It is also possible to update the guide data using a client-only >>client so the source info is needed as well. Anything in Freevo >>using the guide needs this info so that is why the epg.py in Freevo >>is the entry point for _all_ Freevo apps. That module using an epg >>config file works well. Only one place to change epg config on each >>host, not multiple files on each host. > > > ??? I mean that we should use src/ipc/epg.py methods to do all EPG operations in Freevo. That is our glue to kaa.epg2. UI needs EPG, webserver, helpers too. We don't have to have an epg group in each config file because it's in a central file. It doesn't matter that there are config items for things one client may not use. If the freevo.conf file was shared by all Freevo processes I would suggest an epg group in there but right now we have no common config file. >>I have added a ping() to the guide client, and now when >>connect()/guide() is called it checks for an already instantiated client >>and calls ping() making sure it's there. If not, just start a new one, >>log errors. I know not all users check logs but I think it is important >>for things to keep running. > > > Maybe stuff like that should be part of kaa.ipc in general. But IIRC > there is a callback somewhere for lost connections. This callback exists on the server side, I'm not sure about the client side. There is a ping() in kaa.ipc, and that is what I hooked up to GuideClient. On the disconnected exception it (kaa.ipc) returns False. >>IDEA: We can create a Freevo messaging service that can send messages >>and alerts to UIs like the TV and webserver. Something could look for >>errors and notify you. > > > Like mbus messages? Sure there could be a display or message event on > mbus. Yes. I guess what I meant was a process that watches for error then sends a message / event over mbus. We could even do this from the logging module. >>>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). >> >>Maybe. It is also possible to run freevo-epg on hosts besides the >>tvserver host. Right now they are in the same package, but the >>freevo-epg script could be packaged seperately, and installing tvserver >>would just depend on it. > > > Why do you want to run tvserver and epgserver on different hosts? I don't. I meant that other hosts can be epg client. On my thin box I can use freevo-epg to search the guide and also update guide data but the EPG server is on the machine with tvserver. I'll continue with this work over the weekend, maybe tweak some EPG and tvserver internals based on this discussion. -Rob -- ------------------------------------------------------- Rob Shortt | http://tvcentric.com | Freevo [EMAIL PROTECTED] | http://freevo.sf.net | Free your TV
signature.asc
Description: OpenPGP digital signature
