Dirk Meyer wrote: > Rob Shortt wrote: >>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 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. >>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. When a channel gets added to the guide it will, at the very least, have a name. If the guide data source can only provide one thing saying what the channel is, it will be used as the name. Even though the database schema doesn't enforce it, right now the channels col is unique on the name. As for XMLTV, the XMLTV parser can (and does) worry about parsing the display-name field and deciding what may be a tuner id. > 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. > 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. 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. 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. > And if freevo-tvdev says > something about a possible channel S50, try to find that "name" in the > db. Yes, this is basicly how tvserver / tvdev interaction works now. When EPG client loads it makes a dict of all channels keyed by tuner_id. When tvserver gets a list of channels from tvdev it will first check the config (epg mapping) for user override. If there is nothing specified by the user it tries to get the channel based on tuner_id key. If that part fails then it tried to get it by name. In your case you will only have the name field in the guide - many of your channels will be found this way. If this part fails, there's a simple guess using the normalize funtion, and if all cases fail it creates an empty epg mapping for this channel so the user knows to override. Effectively this does what you're suggesting, only that that name is left from the tuner_id list. >>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. > 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? 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. We talked briefly about having an EPG server use mbus for message / command passing and a new socket based protocol (that we can secure) for the EPG data. This would also allow non-python clients. That would be wonderful but what we have right now works pretty good, and we don't want to puch Freevo 2 out any further. I am willing to put some work into securing the inet socket based EPG now though. >>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. 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 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. 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. 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. >>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. OK, that was explained a bit more above as well. >>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). 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. >>-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? OK, this might work as-is, but not tested well. Also, there is not much checking in the code right now. So, maybe this isn't such a problem, just not finished. >>-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. The only good reason to use exclude_channels is to reduce the size of the database. Will it make much difference? Maybe. I do have lots of channels in my guide data that I don't care about. This field could help on both ends, updating the guide data, and choosing what channels to display and use. Also, if we add channel and EPG updating filters for DVB in kaa.record there will be many channels reported by the stream that users don't want to see, there is lots of junk out there. The tvdev process may detect channels you don't really want either. These channels can be eliminated in this manner. Eventually a user may select a channel in any UI and choose "I don't want to see this channel any more.", it would update config object, and call save(). >>-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. The channel_aliases would be the manual intervention step. If the guide already added extra items to the list then the work is done. Actually, this is almost the same as epg mapping in the config right now, maybe we can just extend that. >>-fix freevo-epg update for multiple sources, which should run in serial. > > > OK Trivial fix, maybe I'll get to it on the weekend. re: tv based guide >>I didn't touch this yet so I need to make it use epg2 as well. I think >>I can do this today still. I checked in some code, it doesn't crash but is obviously broken. I will continue. > 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. Agreed. Now I'm tired of writing large email... :) -Rob -- ------------------------------------------------------- Rob Shortt | http://tvcentric.com | Freevo [EMAIL PROTECTED] | http://freevo.sf.net | Free your TV
signature.asc
Description: OpenPGP digital signature
