[mythtv-users] partial lock with hdhr3-cc

[Joseph Fry]

>
>    > However, I wonder if mythtv-setup isn't also at fault, because
>    > it lets one configure an hdhr3-cc tuner by ip address alone--without
>    > warning that an undiscovered hdhr will not be configured properly?
>    > I have added a note to the wiki page about this.
>    >
>    >
>    >
> http://www.mythtv.org/wiki/Silicondust_HDHomeRun_Prime#Initial_Checkout_and_Activation
>    >
>    > I spent a good deal of time chasing down red-herring errors from the
>    > backend logs.
>    >
>
>    I don't know that I would blame mythtv-setup because something
> completely
>    unrelated caused an issue.  Do you blame Firefox for not warning you
> when
>    your router is misconfigured?
>
> I don't see the analogy.
>
> Mythtv-setup can't correctly configure mythtv to use an hdhr unless
> the device is discovered. The way m-s works at the moment seems to
> imply that it can.
>

Nonsense... I can configure mythtv without the HDHR online at the time, if
I specify the ip address (for example if I am pre-configuring a new backend
for my parents to be shipped to them and want it plug-and-play).  You can
opt to discover them, or manually enter the IP... but if you manually enter
the IP, its going to assume that you know that the device is online and
accessible or at least that it will be when it's time to use it.


>
>    Honestly, your note in the wiki is completely pointless.
>
> You're entitled to your opinion. Note that just before this, the wiki
> shows how to build hdhomerun_config from source, which *is* pointless
> and out-of-date.
>

umm... in open source projects, the standard supported install method is
compile from source.  And there is nothing outdated about it... just
because your distro happens to package a version of it, doesn't mean that
all do, or that all of them package the latest version.  While few of us
actually do it, it's not because it's outdated or pointless... it's because
its just easier to use the package maintainer's compiled version.

   Just a few steps before it, they do a discover... which would imply
>    that nothing is blocking, or it would not have returned the IP
>    address in the first place.
>
> I added the output along with the note.
>
>    I guess the moral of your story is, if you run a firewall, you need to
>    update it if your network configuration changes.  Which, when you think
>    about it, is really pretty obvious.  I completely appreciate your
>    frustration though, I doubt there is anyone on this list that hasn't
> wasted
>    days of their lives on boneheaded oversights like this.
>
> Ok, true enough. But if your logs are also full of misleading error
> messages, it can take a long time to figure out which boneheaded error
> you have made. I added the note and sent my follow-up to help others
> (incl. my future self) to solve this problem and not waste their time,
> too. The damned thing is that I had solved this problem a year ago (in
> under an hour) and this time round it took me a week to re-learn the
> lesson.


This I can agree with... it would be nice if the error messages simply
stated that the HDHR was inaccessible.  Or better yet... "pinging HDHR at
192.168.0.111.... failed"... if it did a quick ping check before starting
recording and logged success/fail, it would make super easy.

And please don't take my "bonehead" comment as something personal.... we
all have done similar before; quite often in my case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140728/7ce89d01/attachment.html>