Rob Shortt wrote:This part I do _not_ like (sorry). I wish to run Freevo with TV_CHANNELS=None and use info from the DB. Before the last changes to tv/channels.py it used TV_CHANNELS to compliment data from the DB. Now it is all or nothing.
Sorry, but the old way didn't work for me. There are no dvb informations in the db and the old code added every channel twice (one From the db, one from TV_CHANNELS). I guess what we should do is:
Ok, having no dvb information in the DB is a problem. I am thinking about how to fix that. Maybe we can change tuner_id to access_id and fill it with service id or service name from your channels.conf, if there is a way to correlate the XMLTV data with it... just a thought. There has to be a way to connect the EPG data with your dvb channels from channels.conf, otherwise you will always need to have something in TV_CHANNELS.
if not TV_CHANNELS: TV_CHANNELS = create_from_epg
The problem with that is you can't have just a few channels in TV_CHANNELS. I have a few extras, for example I want a Freevo configured channel for my web cam and perhaps a security camera. I also with to add URLs to my channels for web streams.
If the TV_CHANNELS entries contain the same channel_id as in the DB then the information in TV_CHANNELS should replace / have priority over the DB and we can add all that to ChannelList. The only way you would have duplicates would be if the id's are different (in which case they are technicly different), or if there's a bug.
Problem: If tuner id and the dvb name are both strings, how to tell them apart?
Well, we already have TV_DEFAULT_SETTINGS, mine is set to 'ivtv0'. TV_DEFAULT_SETTINGS defaults to the first one of ['dvb0', 'tv0', 'ivtv0'] found in TV_SETTINGS.keys(). That will take care of 99% of our users. TV_CHANNELS then only needs to look like:
TV_CHANNELS = [ ( 'ard.de', 'ARD', 'dvb0:Das Erste RB', 'dvb1:Das Erste' ), ( 'ndr.de', 'NDR', 'tv0:19' ), ( 'blah.de', 'BLAH', 'Ich Blah', 'tv1:20' ), ( 'kika.de', 'Kika', 'Doku KiKa' ) ]
That example is mixed up only for demonstration. If a user has no TV_CHANNELS all channels can be assumed to be available on TV_DEFAULT_SETTINGS, same thing for those channels that are in the DB and not found in TV_CHANNELS.
OK, so we keep the scanning code like it is now (does it start with dvb, tv or ivtv) and if not, use TV_DEFAULT_SETTINGS. We could make this variable auto detected. If a dvb card is found, set it to dvb:, if ivtv is found (can you detect this?), use this and if both fail,
Yes, detecting ivtv is no problem, we do it now. TV_DEFAULT_SETTINGS is already autodetected based on what we've detected for cards, with the priority of dvb, ivtv, tv.
What to do if a user has multiple cards? Best case scenario is that these cards have the same capabilities and only server to reduce conflicts in recording and watching tv. Then we should allow TV_DEFAULT_SETTINGS to be a list, ['tv0', 'tv1']. Ok, that would cover 99.5% of the users.
So TV_DEFAULT_SETTINGS is only 'tv'. The code in config.py can handle this by match tv: to all tv[0-9] cards.
Ahh, yes! That makes perfect sense.
If the user has multiple cards and they have different capabilities then they _must_ have their channels in TV_CHANNELS, well at least all channels for one card (the one not the default). If the channel is available on different cards but as different tuner ids or different dvb name then they MUST supply tvX: or dvbX:.
How do you plan to use dvb without a TV_CHANNELS? You have no id in the xmltv file and even for analog tv, the tuner id is not in all xmltv files (at least not in Germany). And even if: my dvb card has a
Se above about how we may be able to corelate the DB with dvb naming and channels.conf. We should be able to use dvb withough TV_CHANNELS.
/dev/dvb/adapter0 and also a /dev/video0. Freevo should not think that this /dev/video0 is a tv: device, that doesn't work. So my proposal:
We can (and might already) detect that this /dev/video0 is for the dvb card, no problems there. Some people may also like to make use of the dvb card's videodev interface for TvTime. So dvb0 may have control of /dev/dvb/adapter0 and /dev/video0 while tv0 has control of /dev/video1.
write a small helper to help users to generate a TV_CHANNELS. I still don't understand how we could use dvb without it and why some people don't want to sort the channels in order how often see use them.
I feel that managing a complete TV_CHANNELS is a real pain. A few entries are no problem but some people have _hundreds_ of channels. Sorting the list and time-dependant data is another story.
Since reading channels from memory is faster than querying the DB then
we simply load the DB on bootup and merge it with TV_CHANNELS, or vice
verca.
Please do not merge it. I want to create my TV_CHANNELS without the db
adding stuff to it.
It would be the other way around, local configuration should always have priority over the DB. We could even totally ignore individual channels from the DB if the same id is in TV_CHANNELS.
In tv/channels.py there is the hook to pyepg so we can again have it check TV_CHANNELS when it creates or refreshes the ChannelList.
tv/channels.py is a bad place for it. The recordserver doesn't use this file, it uses the epg directly.
Maybe it should. ChannelList was intended to be Freevo's interface to the EPG because we have local configuration to worry about. Also you want to make sure that when freevo main talks about channel xyz then recordserver thinks it has the same properties.
This could go further with what we were talking about earlier with autodetection, 'channels' could be one of the things to detect:
import config # home for variables that get filled in when # things are autodetected
import system # autodetect code under src/system/
system.detect('channels', 'devices', 'cache', 'xine')
That way only Freevo processes that need to detect things like devices and channels will have that work done. We could even update one of these at a recurring time: system.detect('channels').
Sounds good.
Ok, I guess that can go on our list for when we get this other stuff sorted out.
-Rob
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
