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