[mythtv-users] Database & Storeage Directory Housekeeper Setup Page

[Raymond Wagner]

On 1/31/2012 19:06, MythTV wrote:
> Comment (by harrycoin@…):
>
>   The choice of hostname usually refers to a place, a function, it is not a
>   shorthand for what's in the box.  Otherwise hostnames would be
>   'dellXXXbox2' per your suggestion and not 'bobs laptop' as in so many
>   cases.  For example, kindly explain where the GUI presently makes it
>   possible to remove the tuners and connections from a backend which simply
>   died?  How is not offering that ability not a bug?

If you are using the same hostname as a previous machine, tuners and 
connections can be removed just as easily as they could be from the 
original machine. The only problem is default settings, which may be 
hidden deep in some menu and not easily accessible. If the tuners are 
mapped to a hostname that no longer exists, then those inputs and 
storage groups will simply not be accessible, and your master backend 
will know they're not accessible and know not to try to use them for 
recordings or live tv. At worst, you'll see them listed as "(not 
connected)" in the backend status page that gets proxied through 
Mythweb. If you wish to remove them for cleanliness sake, you can apply 
an override to "LocalHostName" in the mysql.txt, to force MythTV to use 
a different identification value.

All of this is in progress of being rewritten as we migrate to a 
web-based configuration built into mythbackend. Mythtv-setup should be 
considered a dead-end application, so there will not be any significant 
development, nor fixes for behaviors (perhaps unfriendly, but not bugs) 
MythTV has always had.

>   In my world laptops go away and come back with different hardware using
>   the same hostname (totally outside my control), and backends break with no
>   hope of recovery using the same guts without asking me first to use a gui
>   to prepare for the event.

I actually had a discussion with one of the other developers about this 
a couple days ago. Settings are keyed off an identifier string, and that 
string defaults to the system's hostname. There is nothing wrong with 
this configuration, but there is confusion resulting from users viewing 
it as the hostname (and database fields to back that up), rather than 
just some arbitrary profile name. As mentioned above, you can force a 
different profile name from within mysql.txt.

Now to make this a bit more explicit, we could decouple the profile from 
the hostname, instead using some arbitrarily generated string stored in 
the config.xml. For convenience, this could just be the UDN 
automatically generated and stored for the UPNP code. Add a protocol 
method to the master backend to query the temporary address of each 
connected UDN, and add a table to store the last host that UDN connected 
from, to soft-configure new users on that host.

It would be relatively simple in concept, but the pervasive use of 
hostname as the profile key means changes would have to be used 
throughout the codebase, and strange glitches would continue to appear 
for months after the change.

>   If this sort of thing isn't properly a 'developer task' or useability
>   bug fix, what is?

As stated, it simply isn't a 'developer task' until a one of the 
developers takes ownership of the idea, with the intent to get it 
written and committed in a timely manner. Since one has not stated they 
will do so, and since you have not submitted patches of your own, it is 
a feature request, which we do not accept on the bug tracking system.