Can't reset/retire frontend/backend hostname-> upgrade faults

[harrycoin@…]

Same problem, two scenarios:

1) A frontend or backend is upgraded, same hostname different guts.

2) A frontend or backend is retired, tuner/connection & etc data lingers.

Either case generates rafts of problems, from misleading as listing recorders as 'offline' that will never again be 'online', to serious such as totally wrong non-default video playback or tuner connection setups. Worse wrong directory setups when a new system shows up with a previously used hostname -- particularly when the older directory setups are pre-storage group.

mythtv-setup needs a way to display all known hostnames with the ability to delete them from the database (if backends to include all tuners and input connections and dtv scans/channels with no references) and also a way to /reset to defaults/.

[robertm]

If you are using the same hostname, then you are implicitly telling MythTV that this is the same hardware. This is not "rafts" of problems-- if you have changed the recorders, then yes, it's your responsibility to remove them, for which there is a UI (mythtv-setup). If you have changed video hardware then yes, you need to change the video playback profile, something for which there is also a UI. If you have changed the storage group paths, you can fix that in the UI too. If you don't want to be stuck with the baggage of the hostname, then don't pick the same hostname.

In essence, if you tell MythTV that the host is the same, and it's not, then we provide UIs to change it to be appropriate for the new hardware.

In essence, this is just an excerpt from the last ticket, and still a feature request. If you feel that myth "needs" this functionality, then you are going to need to provide a patch for it, unless one of the developers decides to take it on as their own task. I can see how the ability to remove settings for a retired frontend or backend might be useful, but it's by no means mandatory and not a bug. If you would like to attach a patch to this ticket it can be reopened.

[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?

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.

Kindly reconsider. How much work would it call for to present a list of systems in the database with the ability to delete upon request? If this sort of thing isn't properly a 'developer task' or useability bug fix, what is?

[sphery]

Host name is solely a logical identifier we're using to group together configuration information. It can be any value you like (up to 64 bytes--where some non-ASCII characters takes multiple bytes). In truth, it's not actually a host name in MythTV's eyes. It's just a host identifier, for which, by default, we use the host name, since we can be reasonably sure that will exist.

If you use the same system/network host name on the computer, but want to use a different MythTV "host identifier", create a LocalHostName? override in your mysql.txt/config.xml file that specifies some other name. Because of the confusion that constantly occurs over the meaning of "host name"/LocalHostName?, I will be changing the name of LocalHostName? override and some of the log messages to better describe the function of the host identifier.

Note, also, we can answer questions like these in your thread on the mythtv-users list. :)