This line is filler that is ignored by Doxygen. More...
This line is filler that is ignored by Doxygen.
The schema contains the following tables:
|oldrecorded||k(endtime) k(title) k(seriesid) k(programid) pk(station,starttime,title)|
|program||k(endtime) k(title) k(title_pronounce) k(seriesid) k(programid) k(chanid,starttime,endtime)|
|record||pk(recordid) k(chanid,starttime) k(title) k(seriesid) k(programid)|
|recorded||k(endtime) k(seriesid) k(programid)|
|displayprofilegroups||pk(name, host), uk(profileid)|
Where pk means PRIMARY KEY, uk means "UNIQUE KEY", and k means "KEY". BUSQ refers to the Big Ugly SQL Query in scheduler.cpp
This table describes the attributes of a capture card used by MythTV.
The primary key 'cardid' is automatically generated by the database.
The 'videodevice' field normally points to a device used to capture the video, but for DVB where multiple devices are used it is simply a number indicating which set of devices to use. The 'audiodevice' is only used by framegrabber cards, encoding cards like the Hauppauge PVR line encode the audio as part of the video stream, while DTV cards like the various ATSC and DVB cards receive the audio as part of the video stream. The same applies to the 'vbidevice', PVR and DTV cards have captions encoded in the digital stream, while framegrabber cards use this device to provide caption and other data to MythTV.
The 'audioratelimit' field is used to set the audio capture rate when using the 'audiodevice' field. This is mostly useful for V4L cards that have troublesome on-board audio, such as some cards supported by the bttv driver.
The 'cardtype' is an important field for all cards as it guides the interpretation of the rest of the fields, it has several possible values: "V4L", "MJPEG", "DVB", "MPEG", "FIREWIRE", and "GO7007". "V4L" indicates a V4L compatible device, this could be a true V4L device or something like a Firewire camera with the "firewire->v4l" driver. "MJPEG" describes a Matrox G200 or DC10 card which captures individual frames as JPEG images. "DVB" can describe any card supported by the Linux DVB drivers, including the pcHDTV and other ATSC cards. The "MPEG" type describes a device using the ivtv drivers such as the Hauppauge PVR[150,250,350,500]s +Freestyle cards, the Yuan MPEG series, the Avermedia M179, and the Adaptec VideOh! AVC-2410. The "FIREWIRE" card type does not describe Firewire cameras or capture cards but instead describes the Firewire port required by law in the USA on cable boxes for subscribers who receive HDTV channels and request the Firewire port feature. This port lets you communicate with your cable box without needing to build an IR transmitter; in some cases, it also allows you to digitally capture video. The "GO7007" card type describes a USB MPEG-4 encoder such as the Plextor ConvertX.
The 'hostname' field is another important field for all cards as it specifies which backend the capture card is connected to.
The 'signal_timeout' and 'channel_timeout' indicate in milliseconds how long it should take to get a signal and channel lock respectively.
The 'dvb_swfilter', 'dvb_sat_type', 'dvb_wait_for_seqstart', 'skipbtaudio', 'dvb_on_demand', and 'dvb_diseqc_type' columns are all "DVB" specific configuration parameters.
Both 'dvb_recordts' and 'dvb_hw_decoder' are unused, and will be dropped in future versions of MythTV.
The 'firewire_port', 'firewire_node', 'firewire_speed', 'firewire_model', 'firewire_connection' are all "FIREWIRE" specific configuration parameters. The first three define the connection, and function much like 'videodevice' does for other capture "cards". The 'firewire_model' describes the cable box model, for example "DCT-6000" describes a box that communicates using the same protocol as the Motorola DCT-6000. The 'firewire_connection' field describes the overall communication protocol, i.e. are we using "Broadcast" or "Point-to-Point" communication.
This table contains the information needed to tune to a particular frequency on a particular input.
The primary key, 'mplexid', is automatically generated by the database. The most important field is the 'frequency' field which contains the transmission frequency in Hertz. The 'sourceid' which tells us which card and on what input of that card this multiplex applies to according to the Video Source Table (videosource). Along with a channel number 'sourceid' also uniquely identifies a channel in the Channel Table (channel). The 'modulation' field tells us whether the modulation mode is "qpsk", "qam_16", "qam_32", "qam_64", "qam_128", "qam_256", "8vsb", "16vsb", or "auto". Finally, the 'sistandard' field is the last field which applies to both DVB and ATSC, it contains on of four strings, "dvb", "atsc", "mpeg" or "opencable".
When describing an ATSC Multiplex, the Channel Table (channel) contains the major and minor channels used to tune to a particular stream.
Other fields are used by different DVBx implementations to tune to a a particular type of service and MythTV just passes them along to the drivers to take care of.
This table contains free form data pertaining to DVB services, it is like a settings table for DVB.
This table tells us about a particular input on a video capture card.
The primary key, 'sourceid', is automatically generated by the database. The 'name' field gives the input name as passed to the video capture card driver. The 'xmltvgrabber' field tells us where we get our listings from. The 'userid' and 'password' fields are optionally used to log in to a listings service, with the 'lineupid' being used to select a particular lineup available from the listings service. Finally, the 'freqtable' tells us which channel number to frequency mapping to use with analog channels, us, us-cable, pal, etc.
The primary key, 'chanid' is generated by combining the source id with a unique number from 0 to 99.
The 'channum' field contains the channel number to be input to jump to a channel.
The 'sourceid' field contains the Video Source Table (videosource) key, which specifies which listings service to use and which input on which video capture card to find this channel.
The 'callsign' field contains the government mandated license number of the channel's broadcaster if this is an over-the-air channel.
The 'name' field provides the alphanumeric name of this channel for use in the MythTV user interface.
The 'icon' field provides the path to an optional channel icon for this channel.
The 'freqid' field provides the channel number to tune to, as differentiated from the 'channum' used in the MythTV user interface. When the 'mplexid' is set it is used instead. And the 'finetune' field is used to adjust the frequency provided by the combination of 'freqid' and 'tvformat', this can be used when there is carrier drift in a cable system.
The 'xmltvid' field is used to identify this channel to the listings provider.
The 'tmoffset' field is used to apply an offset (in minutes) from the listings provided by the provider to a new time in the MythTV program guide database. This is very handy when the listings provider has listings which are offset by a few hours on individual channels with the rest of them being correct.
The 'recpriority' field is used tell the scheduler from which of two otherwise equivalent programs on two different channels should be preferred, a higher number means this channel is more preferred.
The 'tvformat' is one of "ntsc", "ntsc-jp", "pal", "atsc", etc and is used for various purposes, such as translating a channel number to a frequency, setting the recording frame size, etc.
'commfree' tells us whether this is a commercial free channel, such as those on the BBC and CBC networks. On commercial free channels we do not need to run the commercial detector.
'commmethod' tells us which commercial flagger to use on the channel, the default is to use the global setting
'visible' tells us whether we should show this channel in the channel guide.
'outputfilters' contains a list of filters that should be applied when playing recordings from this channel.
The 'contrast' 'brightness', 'colour', and 'hue' fields are used by frame grabbing recorders to adjust the picture before encoding each frame. And, 'videofilters' contains a list of filters that should be applied when recording from channel using a frame grabbing recorder.
For digital television, the 'mplexid' field contains the Digital Television Multiplex Table (dtv_multiplex) key for determining additional digital tuning parameters. The 'serviceid' field contains the MPEG program number when describing a DVB service. The 'useonairguide' field is used by DVB to determine whether to use the on-air-guide data from this channel to update the listings.
'category_type' holds one of these exact four strings: "movie", "series", "sports" or "tvshow".
'airdate' is a string representing the year of release for movies and may have no meaning for other types of shows.
'stars' is a floating point number from 0.0 to 1.0. On a four star scale, 1.0 would be four stars, 0.75 would be three stars and so on.
'originalairdate' if provided is the date when a show was, or will be, first televised.
'previouslyshown' is a field created by MythTV to try to determine if a showing is more than 14 days after its original air date or if the show was marked as a repeat and did not have a date for the first airing. If this is "0" it usually means that this is a brand new show or a rebroadcast within the first two weeks.
'programid' is the Tribune Media Service database record identifier for each program description. In general, these start with a two letter prefix, MV, EP, SP or SH that equate to the 'category_type'. For most, the last four digits are "0000" except EP where the last four digits are the episode number in the series. Note that these are generated by TMS and not the show's producers but they are usually in the same order as the original air dates for the episodes. Detailed information can be found in the Data Direct documentation at http://labs.zap2it.com/ .
oldrecorded imposes the restriction of one entry per title, starttime and callsign. The scheduler relies on this when restoring any previous status for programs that aren't currently recording and for catching reactivation requests.
The duplicate field is used to indicate if this record should be used to check for duplicates in the BUSQ
If a matching entry exists in the oldfind table, the program is considered a duplicate regardless of the duplicate setting in recorded and oldrecorded. oldfind is an imperfect optimization to avoid greatly increasing the time needed for the big scheduler query.
But the real reason for oldfind is that a search rule may not be able to match by title. For instance, a FindWeekly "Bill Murray (People Search)" needs to know that "Meatballs" is a duplicate for this week if "Stripes" has already been recorded. Oldfind tracks if the rule (recordid) has recorded in the current time interval (findid). When a recording has a findid, ForgetHistory() and DeleteHistory() update oldfind while updating oldrecorded.
The duplicate field is used to indicate if this record should be used to check for duplicates in the BUSQ