This section could be subtitled, "Keeping Up With Those Butt-Heads at Comcast".
HDTV channels can have a whole bunch of sub-channels (called programs), all under the one multiplex frequency. This allows the broadcaster or, in the case of your favorite bunch of clowns at the cable company, the marketing guys, to assign content to whatever sub-channel they like. If they're being nice, they'll keep the lineup the same and everything will work fine. If they're being butt-heads, they'll periodically move things around and stuff will break.
Luckily, the MythTV guys thought of all this. Ha, ha, ha, haaaa! Fooled you. You actually believed that? What a schmuck. Here's what really happens.
The idiots at the broadcaster/cable company change something in the channel lineup (e.g. the ATSC major channel and minor channel numbers change for one of the channels that you normally record in slot 1 of channel 84 -- channel 2_2 moves to 2_1, as it recently did on Comcast). MythTV keeps recording shows on the channel with nary a wimper. However! The recording file that the database points to never actually gets created and there's no actual recording. Nice, huh? If you look in /var/log/mythtv/mythbackend.log for the date/time of the recording, you'll see thousands of entries saying:
Could not find channel 2_2 in CVCT
What this really means is that MythTV went and looked up the channel information in the dtv_multiplex table and tuned to the channel/sub-channel specified. Since it got a lock, it was all set to start recording. Then, just as a precaution, MythTV decided to check that the ATSC major/minor channel numbers, as specified in the Cable Virtual Channel Table [ATSC Syntax] (CVCT) (see www.etherguidesystems.com/Help/SDOs/ATSC/Syntax/TableSections/CVCT.aspx) matched what was set in the channel table. They didn't so it simply dumped the recording in the bit-bucket, with no warning to the user.
The clue as to how to fix this problem is found right in the log at the same place as the first error message. You will see a listing of the channels that are described in the CVCT immediately following. They look like:
VCT Cable: channels(4) tsid(0x807c) seclength(259)
Channel #0 name(WLVI HD) 56-1 mod(SCTE mode 2) cTSID(0x807c)
pnum(2) ETM_loc(0) access_ctrl(0) hidden(0)
path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(1)
descriptors length(27) count(1)
ExtendedChannelNameDescriptor: 'WLVI HD (PRIMARY)'
Channel #1 name(WGBH HD) 2-1 mod(SCTE mode 2) cTSID(0x807c)
pnum(1) ETM_loc(0) access_ctrl(0) hidden(0)
path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(6)
descriptors length(27) count(1)
ExtendedChannelNameDescriptor: 'WGBH HD (PRIMARY)'
Channel #2 name(WGBH UP) 2-101 mod(SCTE mode 2) cTSID(0x807c)
pnum(6) ETM_loc(0) access_ctrl(0) hidden(0)
path_select(0) out_of_band(0) hide_guide(0) service_type(4) source_id(7)
descriptors length(32) count(1)
ExtendedChannelNameDescriptor: 'WGBH UPDATE0 (PRIMARY)'
Channel #3 name(WGBH UP) 2-102 mod(SCTE mode 2) cTSID(0x807c)
pnum(7) ETM_loc(0) access_ctrl(0) hidden(0)
path_select(0) out_of_band(0) hide_guide(0) service_type(4) source_id(8)
descriptors length(32) count(1)
ExtendedChannelNameDescriptor: 'WGBH UPDATE1 (PRIMARY)'
In this case, what was channel 2_2 has been updated to 2_1, as can be seen from "name(WGBH HD) 2-1". The entry for channel 2_2 in the channel table must be updated to match the ATSC major number (2, in this case) and ATSC minor number (1, in this case). You can do this with the following SQL command:
update channel set atsc_major_chan=2, atsc_minor_chan=1 where chanid=1022;
Another fix that appears to work is to set both the ATSC major and ATSC minor numbers to zero, thereby telling MythTV not to check the channel when it tunes to it. This can be done with:
update channel set atsc_major_chan=0, atsc_minor_chan=0 where chanid=1022;
Its your call, whether you want MythTV to record nothing at all or whether you just want it to record the wrong content (or maybe its the right content, just the wrong name). But, to throw another variable into the mix, if you set the ATSC major and ATSC minor numbers to zero, you won't be able to use the on air guide that is sent in the EIT (see Getting EIT To Work). So, probably the best bet is to set ATSC major and ATSC minor numbers to the proper values and keep your eye out for recordings that disappear in the night.
You will, of course, need to figure out what the correct chanid is in order to do this update. This SQL query should help:
select * from channel where freqid=84;
Replace 84 with the frequency ID you are trying to fix and then inspect the resultant listing to find the broken channel. The chanid column is the unique key that you can use for the update. Incidentally, this assumes that whoever or whatever built the channel table put the correct frequency number into each entry. If this isn't the case, you may have to work backwards from first principals. First, begin by selecting the correct dtv_multiplex entry:
select * from dtv_multiplex where sourceid=1 and frequency=585000000;
Replace "1" with the actual sourceid for the input source in question and "585000000" with the center frequency of the channel that is broken. Using the resultant mplexid, select the channel information:
select * from channel where mplexid=184;
Note that other possibilities for "broken" include the wrong slot number being chosen in the channel as well as the wrong frequency being used to tune the channel (this is Scenario 2 in the Comcast playbook, where they change the entire lineup, unannounced, the premise being that everybody is watching via a settop box anyway so it makes no nevermind where we move things and when).
Using /usr/bin/scan, as described in the "Adding HDTV Channels Not Detected By MythTV" section, will give you a listing of all the frequencies that can be tuned on your input connections. The mplexid field of the channel entry should point to the proper frequency in the dtv_multiplex table. If it doesn't change it to match the mplexid from that table that has the correct frequency:
update channel set mplexid=7 where chanid=1022;
Update the serviceid field to choose the correct slot, as given by the path number value (e.g. "pnum(1)") in the /var/log/mythtv/mythbackend.log file:
update channel set serviceid=1 where chanid=1022;
Once you have the channel recording properly again, you may want to change its actual name (e.g. "2_2" changes to "2_1"). You can do this from the channel editor in the MythTV Backend setup program, which is accessed from the System portion of the Gnome Main Menu or you can use this SQL command:
update channel set channum='2_1' where chanid=1022;
One word of caution. Do NOT, I repeat, DO NOT leave any encoder on any system connected to the master backend, whose database you're updating, tuned to the old channel name. If you do, when you change the channel name, everything will hang, including recordings, watching live TV and the master backend itself. The only way out of this fiasco is to go to the machine that actually has the encoder installed in it, run the MythTV Backend setup program, choose Input setup, pick the encoder in question and set its default channel to something else, although, sometimes, you can put the channel number back the way it was, then cycle thru all of the encoders and set them to something else, then re-set the channel number to what you wanted it to be. But, its much easier to not get in this bind in the first place, by setting each encoder to a legit channel before you make the changes.