Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

HD Homerun virtual tuners and cableco QAM channel remapping

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


lists.md301 at gmail

Apr 3, 2012, 6:36 AM

Post #1 of 7 (806 views)
Permalink
HD Homerun virtual tuners and cableco QAM channel remapping

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.

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.

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.


mtdean at thirdcontact

Apr 3, 2012, 7:41 AM

Post #2 of 7 (760 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On 04/03/2012 09:36 AM, lists.md301 wrote:
> 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.

The short answer is had you used a supported approach for updating your
channel (and related) information and restarted the master backend, all
would have worked. This is exactly why we don't support direct DB
editing of the data.

Our intention for the future is to make the supported approach even
easier and more reliable (and, perhaps, even semi-automatic, eventually)
so there's absolutely no reason for users to feel they need to do it
manually.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


lists.md301 at gmail

Apr 3, 2012, 8:24 AM

Post #3 of 7 (764 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On Tue, Apr 3, 2012 at 10:41 AM, Michael T. Dean <mtdean [at] thirdcontact>wrote:

> On 04/03/2012 09:36 AM, lists.md301 wrote:
>
>> 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.
>>
>
> The short answer is had you used a supported approach for updating your
> channel (and related) information and restarted the master backend, all
> would have worked. This is exactly why we don't support direct DB editing
> of the data.
>
> Our intention for the future is to make the supported approach even easier
> and more reliable (and, perhaps, even semi-automatic, eventually) so
> there's absolutely no reason for users to feel they need to do it manually.
> <http://www.mythtv.org/mailman/listinfo/mythtv-users>


Thanks for the reply, Mike. I understand the risks of using an unsupported
method. I brought this to the list because I suspect I'm not the only one
doing it. I don't expect the developers to support me (or anyone) in doing
things against design. However, I suspect that for at least some of us who
are doing unsupported things, it's because we are long-time users (for me,
since 0.13) who resorted to doing these things because on older versions,
it was the only way to do them when certain functionality was new, or do
them reliably. (I remember mucking with a channels.conf file and the DVB
scan utilities when I first got an AverMedia A150 digital QAM card.)

I would ask the follow up question about where exactly I can find
documentation on the supported approaches. I did a brief search of the
wiki, and did not find anything very detailed:

http://www.mythtv.org/wiki/Hdhomerun#North_America_Digital_Cable
http://www.mythtv.org/wiki/Frontend_Channel_Editor
http://www.mythtv.org/wiki/Adding_QAM_Channels_For_HDTV_Tuner_Cards
http://www.mythtv.org/docs/mythtv-HOWTO-9.html#ss9.1

It seems that a mythtv-setup channel scan (as described in the hdhomerun
page), in combination with the frontend channel editor, appears to be the
supported method. But as I understand things (and I admit my knowledge is
lacking here), both appear to have complications/down sides, reconciling
any PSIP identification with cable company virtual channel assignments
(from SchedulesDirect), the details of which are not mentioned in mentioned
in the docs I found. Maybe the minimal updates to existing channels makes
it less intrusive than I'm thinking. I've been reluctant to attempt that
in the past, for fear of trashing things and having start from
scratch--it's that unclear to me. (Of course that was also back before
database backup/restores were so easy as they are now.) That's why the
Prime Perl script is so appealing. Anyway, if there's another doc source I
didn't find, could please direct me to it? (If I end up figuring this out,
I'd be happy to update the wiki with a concise, detailed summary of how to
deal with this situation.)

Please don't take my questions as criticism of any developers about the way
it is. I'm just trying to give real-world feedback from an end-user.
Thanks for setting me straight. It sounds like you're headed in the
direction I'd like to see on this for when channel mappings need to be
updated.


lists.md301 at gmail

May 7, 2012, 10:11 AM

Post #4 of 7 (649 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On Tue, Apr 3, 2012 at 11:24 AM, lists.md301 <lists.md301 [at] gmail> wrote:

>
> On Tue, Apr 3, 2012 at 10:41 AM, Michael T. Dean <mtdean [at] thirdcontact>wrote:
>
>> On 04/03/2012 09:36 AM, lists.md301 wrote:
>>
>>> 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.
>>>
>>
>> The short answer is had you used a supported approach for updating your
>> channel (and related) information and restarted the master backend, all
>> would have worked. This is exactly why we don't support direct DB editing
>> of the data.
>>
>> Our intention for the future is to make the supported approach even
>> easier and more reliable (and, perhaps, even semi-automatic, eventually) so
>> there's absolutely no reason for users to feel they need to do it manually.
>> <http://www.mythtv.org/mailman/listinfo/mythtv-users>
>
>
> Thanks for the reply, Mike. I understand the risks of using an unsupported
> method. I brought this to the list because I suspect I'm not the only one
> doing it. I don't expect the developers to support me (or anyone) in doing
> things against design. However, I suspect that for at least some of us who
> are doing unsupported things, it's because we are long-time users (for me,
> since 0.13) who resorted to doing these things because on older versions,
> it was the only way to do them when certain functionality was new, or do
> them reliably. (I remember mucking with a channels.conf file and the DVB
> scan utilities when I first got an AverMedia A150 digital QAM card.) [snip]
>

Following up on my previous, because it might of interest to some. It
turns out (as is often the case with these things), that something got
messed up with my mythtv-setup input groups for the virtual tuners, and
that is probably the root cause of my issue. I discovered this (by
accident) by further doing that illicit thing of looking (but not touching)
the database. I noticed a single input group, but it only included 2 of
the 3 tuners for one physical HDHR clear QAM tuner, and nothing at all for
the other physical tuner. After a bit more investigation, I basically
re-assigned the each tuner's input connections, and saw the input groups
for each were automatically created. I was unaware of this, and have since
looked through the documentation and did not find any mention of this as it
relates to virtual tuners. In hindsight it makes perfect sense, but I
didn't know (1) it was how mythtv managed this, and (2) it got handled
automatically. I was aware of manually creating input groups to manage a
single recorder source. My virtual tuners have behaved properly once I
corrected the input group assignments

Bottom line is, I'm not sure how this got messed up in the first place for
my HDHR QAM virtual tuners (I'm sure it was operator error, and not any
software bug), when I deleted all and re-created my tuners to add the new
HDHR Prime ones in my initial 0.24 setup. Perhaps it would be a good idea
to make mention of input groups with virtual tuners in the documentation,
but I'm unsure myself where the best place for this would be (or I would do
it myself). Or if it is already, and I've missed it, feel free to ignore
this suggestion.


gary.buhrmaster at gmail

May 7, 2012, 10:34 AM

Post #5 of 7 (645 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On Mon, May 7, 2012 at 5:11 PM, lists.md301 <lists.md301 [at] gmail> wrote:
> ...  Perhaps it would be a good idea
> to make mention of input groups with
> virtual tuners in the documentation,
> but I'm unsure myself where the best
> place for this would be (or I would do
> it myself).  Or if it is already, and I've
> missed it, feel free to ignore
> this suggestion.

The business logic of the MythTV database
is not exclusively in the database, and as
such, I do not know there is any better
recommendation other than "there be dragons
there" along with the ever present "No user
serviceable parts inside, do not open". Any
such documentation as to how not to break
the database for particular point fixes would
imply that editing the database is a possible
option (and then you get more breakage as
others try to edit the database)(*).

It reminds me of the old joke:
Patient: "Doctor, it hurts when I do this."
Doctor: "Stop doing that."

Mike has been consistent on this point.

Gary

(*) Your database, your decisions. However
you really need to understand that when you
do it, you are on your own.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


lists.md301 at gmail

May 7, 2012, 11:11 AM

Post #6 of 7 (646 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On Mon, May 7, 2012 at 1:34 PM, Gary Buhrmaster
<gary.buhrmaster [at] gmail>wrote:

> On Mon, May 7, 2012 at 5:11 PM, lists.md301 <lists.md301 [at] gmail> wrote:
> > ... Perhaps it would be a good idea
> > to make mention of input groups with
> > virtual tuners in the documentation,
> > but I'm unsure myself where the best
> > place for this would be (or I would do
> > it myself). Or if it is already, and I've
> > missed it, feel free to ignore
> > this suggestion.
>
> The business logic of the MythTV database
> is not exclusively in the database, and as
> such, I do not know there is any better
> recommendation other than "there be dragons
> there" along with the ever present "No user
> serviceable parts inside, do not open". Any
> such documentation as to how not to break
> the database for particular point fixes would
> imply that editing the database is a possible
> option (and then you get more breakage as
> others try to edit the database)(*).
>

I think you missed my point, but I can see why you might have, considering
I was talking about poking around the database again. I only uncovered my
real problem because I noticed a table in the database, specifically the
one for input groups.

I just remotely logged into my master backend and ran mythtv-setup so I can
be precise. For example, on the second screen of the input connections for
my first HDHR QAM tuner, I have input group 1 defined as
"HDHOMERUN_10328892-0". It never occurred to me that defining virtual
tuners would cause an input group to be defined in mythtv-setup (only
obvious in hindsight). So reviewing my setup configuration, I would not
have noticed that there was no input group defined, which I believe was the
source of my problem. How it got deleted I cannot say, but certainly was
my doing in some way.

I'm merely suggesting that whatever appropriate place in the
setup/documentation that covers virtual tuners, it could be mentioned that
an input group will be automatically created to handle it's functionality,
and perhaps also a warning that it should not be monkeyed with. But the
catch is, there isn't really any setup explanation of virtual tuners at all
that I could find, which is why I'm not simply adding something to the
documentation myself. None of the links on the 'mythtv-setup' wiki page at
present include that level of detail. I hope this doesn't sound like a
"feature request without a patch." I'm just bringing attention to
something that caused me problems, hoping others may learn from it. (First
2 things I always do when I have an issue is search the wiki and the
gossamer mailing list archive.) It seems to me a user could break things,
without ever hacking the database, if they somehow wrongly messed with the
input group settings in mythtv-setup.


gary.buhrmaster at gmail

May 7, 2012, 11:39 AM

Post #7 of 7 (659 views)
Permalink
Re: HD Homerun virtual tuners and cableco QAM channel remapping [In reply to]

On Mon, May 7, 2012 at 6:11 PM, lists.md301 <lists.md301 [at] gmail> wrote:
.....
> I'm merely suggesting that whatever appropriate place in the
> setup/documentation that covers virtual tuners, it could be mentioned that
> an input group will be automatically created to handle it's functionality,
> and perhaps also a warning that it should not be monkeyed with.

I would hope that the setup rewrite (still targeted for 0.26?)
will manage to reduce some of the ability for one to achieve
configurations that work less than well (exceptions noted).

Gary
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.