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....
>> 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
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.
>> 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.
> 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).
> 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.
>>>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.
>> 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.
> 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.
> 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.
Supporting non python clients is always a good idea.
> 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.
The todo list is long ... very long. Without much thinking I can name
three major parts that needs to be done: kaa.canvas, kaa.vfs,
kaa.record scanning. With the current sped of development, freevo 2.0
is not around the corner.
>>>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 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.
> 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.
>> 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?
> 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().
OK
> Now I'm tired of writing large email... :)
:)
Dischi
--
Pascal:
A programming language named after a man who would turn over
in his grave if he knew about it.
-- Datamation, January 15, 1984
pgpY2WfItcqws.pgp
Description: PGP signature
