[mythtv] RFC: Frequencies, Content and Descriptions

[Johannes Niess]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Thank you very much for creating this superb application. As I messed up my 
mythtv installation (0.13) with regards to xmltv I had to modify the channels 
table by hand. To me it looks like the channels table is a bit odd. Could you 
please clarify where each field is used? I'll summarize the discussion and 
make it a part of the FAQ.

chanid: internal identifier for e. g. the program table. First digit is the 
source id. 

channum: (numerical ?) sort order of channels in program guide

freqid: key to frequency lookup table (to get MHz to tune to)

callsign: displayed name in short form (e. g. program guide)

name: ?
I have callsign = name everywhere, so it looks redundant

xmltvid: "channel id" from xmltv


IMHO the current implementation has several design flaws. It does not seperate 
cleanly between the three entities involved:

1) "Frequency": settings like card and frequency to a slot where you can 
recieve content. Other people may call this a channel.

2) Content: The sequence of images and sounds we like to watch and record. 
Station is another name for this sequence of programs (shows, films, news 
items).

3) Description: Data from xmltv describing items of content.

In its current implementation frequency, content and description have a 1:1:1 
relationship. This has several drawbacks:

- - You can not have multiple xmltv sources, which often use different xmltvid's 
for the same content.

You can fake it with creating new records in the channel table, but it results 
in a new line in the program guide interface. To do that you'd need to set 
the same freqid.

Given the unreliable sources for xmltv data it would be good to use several 
sources for the same content. It requires some sort of priorites or 
algorithms (e. g. length based) to ease conflicts between several description 
parts and to display a resulting set. 

- - The scheduler can not cope with the same content availabe on different kinds 
of backends (e. g. analog and digital). It deals with frequencies only.

There is significant content overlap between analog and digital TV. Recording 
from analog backend only if the digital backend is occupied with another job 
would be nice.

With the advent of terrestrial DVB in Europe this overlap will become 
important and will result in much changing of frequencies.

As a long term goal seperate tables for the frequency, content and description 
seem to be a good thing. This way you can model their correct relationship. 
Its frequency N:1 content 1:N description.

As a short term goal we could use mysql's error tolerant text search to match 
frequencies and descriptions from xawtv to xmltv. Besides the implemented 
case independant match we could remove spaces, dashes, dots etc. A second 
approach could be to take first letters from long channel names to match 
xmltvids.

Mythtv is not my application, but I love it and want to improve it. I've done 
a fair amout of programming, but most of it in perl. Given my ignorance of qt 
it took me some time to even find the sql strings used in the source code. 
Some of my assumptions above may be wrong. So please don't wait for my 
patches implementing the ideas.

Johannes Niess
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/+r2HZ86b9aw2E+0RAnPJAJ4lBtJHL5hQQRfmBD7uq9wreGPP1QCfYyaN
Iu1te39yiGrNsiexAS6pitY=
=owQV
-----END PGP SIGNATURE-----