I finally had reason to try the Perl script (from the wiki) which queries an HDHomerun Prime and obtains QAM channel mapping frequency and service ID's. My provider, Comcast, surprised me by making a change this past week midweek. Usually it's Sat night/Sun morning. In the past when this has happened, I've always edited the database channel tables manually (using webwin), after making a list from the STB diagnostic screen for frequencies and then guessing at the service/program ID's (which usually end up unchanged), then restarting the backend. This time, Comcast had done a major re-order of the frequencies and ID mappings. I modified the Perl script to only report the changes, and the new dtv_multiplex lookups (which are defined for a US-cable frequencies from scte65scan years ago), and then manually entered the changes. Didn't trust the script to be writing to the DB--but I guess this is something that will be more difficult down the road when the developers get around to embedding the DB within the core app, and thereby protecting the users from themselves. I understand and applaud this, but I hope there will be a way to update such changeable info remotely, without having to do a full channel scan through the GUI and tear everything up. I started doing this years ago before any user interface was mature, out of necessity. I hope some kind of tie-in with a CC Prime/HDHR QAM setup can be "built-in" when the times comes. Yes, I know, patches welcome. :) But I digress.<br>
<br>My reason for writing this has to do with the consequence of Comcast's more extensive remapping. For each of my HDHR QAM tuners, I have 2 virtual tuners defined. I ran into something I never saw before, because they switched the multiplex of several of the main HD network channels. In the old mapping, CBS and Fox were on the same transport, but now it's NBC and Fox together (at least I think I have this right). The consequence is that the myth scheduler thought it could use one physical tuner to record a simultaneous CBS/Fox shows, but obviously could not. So in its confusion it ended up recording the same tuned stream for both (I presume the last one tuned), causing one to be missed. Last Thursday I foobar-ed "Touch" and "Person of Interest" this way. I had fixed the DB assignments right before they started recording, but didn't realize what was happening until too late. Also, after having changed the assignments, I did not restart the backend because another recording was still going ("30 Rock" which ended up being trashed for a clerical error, but I didn't know that at the time). I had assumed that maybe the scheduler didn't "see" the channel mappings without a backend restart. Of course, I never thought to do one, until this past Monday night, where I also lost a new "House" episode, sacrificed to the NCAA men's championship game, which did record successfully. I tried restarting the backend right after the recordings started, and then re-activated the "House" recording, but the scheduler didn't recognize the change.<br>
<br>I'm not sure this is a bug, per se, because this is a very special corner case. But I wanted to put it out there and ask if anyone else has seen it, and if there are any steps I could take after a mapping change deal with this situation. I think the Perl script is a great thing, and I know the author suggests that running it a 3am and letting it do an update potentially keep you from losing recordings. I'm thinking that if a user has virtual tuners defined, it may have other issues. Thoughts? As I have to finish my taxes (for myself and my mother) this week, intersecting with myth not-recording time, I'm not sure how much time I'll have to experiment with this in the coming week to get a handle on what's going on.<br>