mtdean at thirdcontact
Oct 18, 2013, 12:12 PM
Post #42 of 43
On 10/18/2013 02:52 PM, jedi wrote:
> On Fri, Oct 18, 2013 at 11:18:56AM -0400, Michael T. Dean wrote:
>> On 10/13/2013 02:41 PM, Jay Ashworth wrote:
>>> From: "David Engel"
>>>> The hostility in the past has been because the suggestions were to
>>>> save cardid/inputid. Those values can change when tuners are added,
>>>> removed or renumbered making them less useful. The input displaay
>>>> names can be more descriptive, so using them can solve the tuner
>>>> change problem. Of course, it's still up to the user to add
>>>> sufficiently descriptive names.
>>> And that's patently ridiculous: how often are tuners *actually* changed
>>> on production machines? Every 3 or 4 years?
>> Every boot on some machines (like mine)--depending on which tuner
>> gets which number from the kernel. I have no need for any udev or
>> other rules to lock a physical card to a specific kernel number
>> because every single one of my cards is "identical" (meaning they're
>> all DVB-API cards that are attached to the same Video
>> Source)--despite being 5 distinct physical cards from 2
>> manufacturers with 3 models of card.
>> In other words, the problem isn't the user
>> changing/swapping/removing tuner hardware, but that the only
>> identifier we have in MythTV is /not/ necessarily associated with
>> any static value that's useful over time. I.e. MythTV's numbers
> Anyone that cares can make it so. It's not some impossible insurmountable
> problem. It is certainly far easier than digging into someone else's C++ code
> and trying to retrofit this sort of thing because of defeatest paralysis on the
> part of those that could make simple work of it.
Right, but when it's stored indefinitely (as long as the recording is
kept) as information about the recording, it implies to the casual user
(meaning, doesn't understand the intricacies of the kernel's device
layer) that it means something as long as it's stored. If, instead,
it's only in the logs, it implies that it has meaning only for a short
time (which is /exactly/ correct).
Again, though, I won't complain if someone stores it--as long as they
store and expose a real, user-specified name and not a(n internal)
database ID. That way, the user has to specify a name to get one, just
like they have to configure the underlying system to make that name
>> don't necessarily equate to the same physical hardware on every run
>> of MythTV.
>> Plus--and far more importantly--users shouldn't have to do direct
>> database queries to figure out what inputid matches up with what
>> physical input, so if /any/ code exposes (internal) database ID
>> numbers, that code is wrong (and, yes, I know there is code in
> The main status pages for the backends have always done this.
Yes, that's what I said, "And, FWIW, we also need user-specified card
names (to replace the "Encoder 4" or whatever on backend status page and
Upcoming Recordings list)." And, yes, it's *still* wrong. But we won't
add new code that's similarly wrong--instead, we aim to fix the wrong code.
mythtv-users mailing list
mythtv-users [at] mythtv