So I finally got around to updating the system to use the new service. I always dislike mucking around with the channels in mythtv because the configuration system doesn’t quite have their story straight with the programming data folks. That is, it never works out of the box. In other words, MySQL experience required.
To complicate matters, not only did I cancel my premium cable service, but my cable provider changed the entire programming lineup. This will be a challenge.
To start, I updated my Fedora Core 6, atrpms installation flawlessly to mythtv 20.2, ran the setup, and configured schedules direct. I exited and ran mythfilldatabase with the expectation of it magically sorting everything out and… wait for it… it didn’t. Everything was hosed.
Reading a bunch of posts seemed to indicate the best thing to do was to start over. So I did. I deleted all the programming data providers, created new ones and assigned them to my standard definition and HDTV tuners respectively. I scanned for SD channels and imported my HDTV channels from when I first configured them. I re-ran mythfilldatabase and, well, I had programming data for all the SD channels, the SD channel callsigns were changed to ‘Adding Channel X’ and the HDTV channels had no data and their names wrong…
Running ‘mythfilldatabase –do-channel-updates’ fixed the SD channels. The HDTV channels were harder.
Mythfilldatabase does some kind of crazy schedulesdirect -> channel table matching to figure out where to put programming data. I can’t remember what fields are important, but updating the channum, freqid, and callsign columns in the channel table did the trick. Basically, channum and freqid were set to the imaginary HD channel number, and callsign to the call sign. Re-running mythfilldatabase populated my channels with the correct programming data.
So mythtv still has some way to go, especially with HDTV configuration (is there a tech organization that doesn’t) but at least with a bit of database skillz, I was able to make the transition within two evenings.