Hi,
I posted in the discussion "RFE: Make VDR more friendly when using
combinations of DVB-S, DVB-T and DVB-C" yesterday and mentioned that my
little project Channelpedia could be helpful in this regard. But because
my approach is more targeting the necessary semantic meta data that
would be necessary for those advanced features, I would like to explain
my ideas in a different thread.
When I started to work on Channelpedia my goal was to offer a website
where different VDR channel lists of different DVB providers could be
easily stored, sorted and regularly updated in an easy way. The main
audience were new VDR users who often are overwhelmed by the amount of
channels offered by their DVB source (in particular satellite sources).
Technically, Channelpedia is a PHP web application that uses a sqlite
database and offers to upload channel data and retreive channel data in
different ways (static generated HTML pages + a small RESTful JSON
interface). Channelpedia is not a VDR addon and not a VDR plugin. The
coding is completely independet from VDR and it can't be plugged into
VDR in any way.
Now that there are a couple of different DVB providers in the
Channelpedia database, I thought it would make sense to additionally
collect semantic meta data for channels in a provider independent way.
This semantic data can be gathered and stored in Channelpedia, but in
the end it should be easily exportable from Channelpedia. For example in
a single textfile, so that this textfile could be used by VDR plugins
(or even VDR core) for lookups.
The basic idea is that this textfile has a certain structure (could
also be XML or JSON) and that anybody could create this data file by
typing it all down manually. But Channelpedia on the other hand could
create this file in an automated way so that it is rarely necessary to
maintain that file manually. At this time, Channelpedia collects some of
this meta data only for channels relevant for German language countries
(due to the amount of work involved I have limited it to German channels
for now).
I will now give an example of the kind of metadata I would like to
collect per channel:
All this metadata below is not specific to one single DVB provider.
Instead it should be usable for any provider (C,T,S,I,...) that offers
the respective channel.
* Country/countries where the organization is based that offers
the channel (problems might arise with cooperations: 3sat is a joint
effort of Germany, Austria, Switzerland)
* Primary region of the audience: Where does the indended audience
live?
Which language do they speak?
* Website URI of the channel (Wikipedia page of this channel +
the website of the organization)
* Type of channel (Kids entertainment, Music, Crime, Sport, ....)
* Channel logo resources for this channel that can be found on the web
* List of existing EPG web services (that offer an XML based
epg for this channel)
* Existing channel variants with the completely the same
or nearly the same epg:
- Time-shift-versions (+1, +2, +24): List of other channels that
have the same epg but a timeshift offset
- Regional variants (BBC 1 London, BBC 1 Oxford, ... /
WDR Aachen, WDR Köln, WDR ....): List of other channels that
share 95% of the EPG but have "regional windows"
- Quality/Bandwidth variants (SD, HD, different bitrates,
DVB-T offers less quality in Germany compared to SD via DVB-C/S):
List of channel alternatives that offer a higher or lower picture
quality)
- Reference to root channel (the "root" channel is
the predecessor of all other variants)
* CA-status: This channel regularly changes from FTA to
scrambled or is permanently scrambled.
* Which pay-TV packages / platforms have got this channel in their
portfolio
To store all this metadata for a channel, the channel needs a unique ID
that is different from the technical unique ID that VDR uses internally
(Source-NID-TID-SID, for a more detailed explanation of this ID please
read VDR man page). The technical IDs of VDR are only used to identify a
channel within the channels.conf of one VDR user and his active DVB
providers. But we need IDs that are able to identify channels across
different providers. Therefore we have to make them up ourselves, based
on their channel name. I want to call them Channelpedia IDs for now -
short: CPID, to make it easier to talk about them.
But the NID-TID and SID still remain very important. If we put all the
NID-TID-SID data into the metadata too, we can use them to automatically
assign a channel in a channels.conf to a CPID.
Regarding German channels, the DVB-C sometimes reuse the same
NID-TID-SID of the channel on satellite. This means that we can hope
that we don't have to store as many variants of NID-TID-SID in the
metadata as there are providers out there.
I guess this metadata collection can never be complete or completely
accurate, but even if it doesn't contain all those channels out there it
could still be very helpful for VDR plugins. Example:
I create a searchtimer using epgsearch and epgsearch is able to look up
all channel siblings in my local channels.conf that share the same EPG
with the channel that I have currently selected. Now, epgsearch could
give me choices: "Do you want to record the HD version of this channel?
Is SD quality good enought? etc."
Further infos:
<http://channelpedia.yavdr.com/>
Demos:
<http://channelpedia.yavdr.com/gen/de_uniqueIDs2.html>
<http://channelpedia.yavdr.com/gen/de_uniqueIDs.html> (JSON files
available for auto-assignment)
German language thread:
<http://www.vdr-portal.de/board1-news/board2-vdr-news/111607-announce-entwurf-channelpedia-generiert-automatisch-unique-kanal-ids/>
Regards,
Henning
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
