[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