[mythtv-users] 0.21 and 0.22 servers on the same network?
Michael T. Dean
mtdean at thirdcontact.com
Wed Apr 7 23:23:25 UTC 2010
On 04/07/2010 06:45 PM, Mark Knecht wrote:
> On Wed, Apr 7, 2010 at 3:17 PM, Michael T. Dean wrote:
>
>> On 04/07/2010 04:40 PM, Mark Knecht wrote:
>>
>>> On Wed, Apr 7, 2010 at 12:07 PM, Doug Lytle wrote:
>>>
>>>> Mark Knecht wrote:
>>>>
>>>>> Unfortunately this MythTV wiki page on the subject doesn't seem to
>>>>> tell me how to turn it off. I took a quick look using a frontend down
>>>>>
>>>> mythbackend --help
>>>>
>>>> --noupnp Do not enable the UPNP server
>>>>
>>> I wonder if any Gentoo users know whether this can go in
>>> /etc/conf.d/mythbackend? Or do I have to hand edit the init scripts?
>>>
>>> It worked (I think) editing the init script and adding --noupnp as
>>> Media Player no longer sees it. However editing init scripts is
>>> probably not the Gentoo way to do this.
>>>
>> There's really no need to turn off UPnP. I run a production system and a
>> development system (2 completely separate systems) on the same network and
>> they both have UPnP enabled. The only thing UPnP does is automatically find
>> the backend so you can select it rather than type in the information about
>> it the first time you run your MythTV program.
>>
> If it really provides so little value then why is it enabled by default?
>
> You're beyond a super user Mike, When it comes to this program I'm a
> complete dummy. I've heard a _lot_ of warnings here about 0.22 messing
> up 0.21 databases or the other way around. What value does this
> feature provide me if I know the IP addresses and am happy typing them
> in? One mistake and something is wrecked? No one is going to log into
> my network and fix this for me.
>
> To me it's not worth the risk. For you it's a non-issue because I
> guess you're a developer or something. Respectfully, we're coming from
> different points of view. To you this is easy. To me this is home brew
> software that has failed in my home for weeks at a time.
>
Well, even though it doesn't do much, it doesn't hurt much. The only
time it comes into play is when you start up a MythTV application in an
environment that's never been configured for MythTV (one with no
mysql.txt or config.xml). And, since MythTV applications /always/
prompt the user, asking /which/ backend to use, the only way to
accidentally upgrade the wrong database is to explicitly choose the
wrong database.
Unless, of course, you start your MythTV applications in a
non-interactive environment--i.e. through an init script. In a
non-interactive environment, MythTV applications can't prompt the user
for what to do (through the console or GUI), so they do "what's normally
right"--upgrade the database and let you continue on your way. But, the
only application you could really do that with is mythbackend***, and if
you start up mythbackend on an unconfigured system through an init
script before running mythtv-setup, you probably should get the quick
introduction to database backup/restore that you're going to need. And,
IIRC, it will only automatically connect to a backend if there's only a
single backend running on the network (further proof that only
mythbackend can be a problem).
I /think/ it's also possible that you may have an issue on an
already-configured system when the database server specified by
mysql.txt/config.xml is not running and the application tries to fall
back to UPnP to find the backend and its database (since it assumes you
moved it). That leads to http://svn.mythtv.org/trac/ticket/7799 . But,
again, in an interactive environment, it will always prompt before doing
anything.
Since the idea is to make configuration easy for new users--who aren't
likely to run multiple disconnected MythTV systems of varying versions
on the same network--UPnP backend auto-detection is enabled by default.
Again, though, it's not a problem even if you /are/ running multiple
disconnected MythTV systems of varying versions on the same network. I
do it every time I boot my MythTV dev box.
Personally, I'd like to remove the ability for any MythTV application to
upgrade the database and require a user to explicitly request an upgrade
through mythtv-setup. Others, however, like the current approach. It
/is/ much better now, than it has ever been in the past. We no longer
allow a frontend to ever upgrade the database (without an explicit
command-line argument forcing the upgrade), and the program upgrading
the database will make a backup before doing the upgrade. I'm trying to
convince others to let me change mythbackend so /only/ the master
backend is allowed to upgrade the database. ...
All that said, if you're not sure how things work, or you want to be
extra careful, the separate network approach is likely the best. A lot
of users accidentally upgraded their databases /before/ we had the UPnP
autodetection, so it's not the UPnP that's the problem--it's making a
mistake that causes the problems. UPnP doesn't even make those mistakes
more likely.
Mike
***And maybe mythjobqueue--though I'm not sure if mythjobqueue is
allowed to upgrade the database, but it doesn't matter because I'm the
only person who uses mythjobqueue. It seems many users would prefer to
run mythbackend without capture cards and waste 10x the RAM (256MB
instead of 27MB -
http://www.gossamer-threads.com/lists/mythtv/users/347829#347829 ) while
at the same time running mythfrontend in X without a Window Manager so
they can save 300KB of RAM (
http://www.gossamer-threads.com/lists/mythtv/users/230354#230354 )
and--by running a capture card-less backend--run an unsupported
configuration than run mythjobqueue--at least that's the impression I've
gotten from threads on this list ;)
More information about the mythtv-users
mailing list