Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Hauppauge PVR Questions

 

 

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded


jedi at mishnet

Oct 11, 2013, 6:47 PM

Post #26 of 43 (1128 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Fri, Oct 11, 2013 at 05:15:09PM -0500, David Engel wrote:
> On Fri, Oct 11, 2013 at 01:03:23PM -0400, Jay Ashworth wrote:
> > On a related topic, does the backend store which tuner a recording was
> > made on? If so, is it terribly hard to expose that in a theme?
>
> This question comes up semi-frequently. Currently, the tuner for a
> recording is only reported in the logs. Because card and input
> numbers can change wildly over time, neither is a good choice for long
> time storage. Something that might be doable instead is to store the
> input name, but that would require users to fill that information in a
> priori.

"We don't think we can be perfect, so we won't try at all".

[deletia]

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


stephen_agent at jsw

Oct 11, 2013, 6:57 PM

Post #27 of 43 (1129 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Fri, 11 Oct 2013 13:03:23 -0400 (EDT), you wrote:

>
>On a related topic, does the backend store which tuner a recording was
>made on? If so, is it terribly hard to expose that in a theme?

That information is only in the logs. I use this script:

http://www.mythtv.org/wiki/Which_recorder.pl

installed into my backend status page on mythweb to display it. I had
to modify it to make it work with the current log file format. I
commented out the big if at line 45 and replaced it with this:

if (/^([A-Z][a-z][a-z] [ 0-9]\d \d\d:\d\d:\d\d) .* Tuning
recording: (.*): channel (\d+) on cardid (\d+), sourceid (\d+)/)

See here for how to make it work with mythweb:

http://www.mythtv.org/wiki/Miscellaneous_Status_Information

Of course, that only makes available the information in the current
log file, so if you need to use it a long time after the recording was
made it will be gone.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gnassas at mac

Oct 12, 2013, 5:06 PM

Post #28 of 43 (1119 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

> On Oct 11, 2013, at 6:15 PM, David Engel <david [at] istwok> wrote:
>
> Something that might be doable instead is to store the
> input name, but that would require users to fill that information in a
> priori.

Oooooo, would you be willing to commit a patch implementing such a feature? I mean, if you're thinking of doing it yourself I'll hang back and wait but in the past there has been open hostility to saving tuner info so I'd like to grab the opportunity if it's actually there.

It might take me a week or two to find the time and code it up.

- George

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


david at istwok

Oct 13, 2013, 11:31 AM

Post #29 of 43 (1112 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Sat, Oct 12, 2013 at 08:06:56PM -0400, George Nassas wrote:
> > On Oct 11, 2013, at 6:15 PM, David Engel <david [at] istwok> wrote:
> > Something that might be doable instead is to store the
> > input name, but that would require users to fill that information in a
> > priori.
>
> Oooooo, would you be willing to commit a patch implementing such a feature? I mean, if you're thinking of doing it yourself I'll hang back and wait but in the past there has been open hostility to saving tuner info so I'd like to grab the opportunity if it's actually there.
>
> It might take me a week or two to find the time and code it up.

Yes, we'd accept a patch adding the input display name to the recorded
table. Please also make that information available in the details
screen and to the theme.

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.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 13, 2013, 11:41 AM

Post #30 of 43 (1111 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

----- Original Message -----
> From: "David Engel" <david [at] istwok>

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

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


stephen_agent at jsw

Oct 13, 2013, 2:54 PM

Post #31 of 43 (1101 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Sun, 13 Oct 2013 14:41:44 -0400 (EDT), you wrote:

>----- Original Message -----
>> From: "David Engel" <david [at] istwok>
>
>> 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?
>
>Cheers,
>-- jra

That depends on your situation - mine have never been stable so far
for more than two years, due to changing technology and hardware
failures. My mother's box has been more stable - it is probably three
years now since I added her third DVB-T tuner.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gary.buhrmaster at gmail

Oct 13, 2013, 3:07 PM

Post #32 of 43 (1102 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Sun, Oct 13, 2013 at 6:41 PM, Jay Ashworth <jra [at] baylink> wrote:
> ...how often are tuners *actually* changed
> on production machines? Every 3 or 4 years?

AFAIK no one has any numbers to do the statistics,
and any one persons numbers are irrelevant. My
WAG is that the number is likely bi-modal (just like
packet sizes :-), with a large bump at the small
interval, and another (wider one) at the large interval.
But I could easily be wrong (as could you);
"Lies, damned lies, and statistics".

Gary
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gnassas at mac

Oct 13, 2013, 4:43 PM

Post #33 of 43 (1099 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

> On Oct 13, 2013, at 2:41 PM, Jay Ashworth <jra [at] baylink> wrote:
>
> And that's patently ridiculous: how often are tuners *actually* changed
> on production machines? Every 3 or 4 years?

It used to be that any time you wanted to change tuner priorities or bump the number of virtual tuners etc the standard advice was to wipe 'em all out and redefine from scratch. It wasn't common to do this but it wasn't uncommon either.

Maybe a year ago a change went in where tuner preference is through an integer you control rather than DB row create order. It was a pretty sweet little update and nowadays full wipes are no longer fashionable.

- George

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


t004 at kbocek

Oct 13, 2013, 5:31 PM

Post #34 of 43 (1097 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On 10/13/2013 11:41 AM, Jay Ashworth wrote:
>
> And that's patently ridiculous: how often are tuners *actually* changed
> on production machines? Every 3 or 4 years?
>
> Cheers,
> -- jra

I think that's a totally unfair characterization. In the past 3 or 4
years I think I've made 6 or 8 changes to my tuners from going between
an analog tuner to an HD Homerun classic to an HD-PVR to an HD Homerun
Prime. My latest change was to abandon my HDHR Classics entirely and go
to a HDHR Prime only setup. On the horizon I plan on playing with an OTA
antenna with my now unused HDHR classics. I'm glad I know how to perform
the forbidden direct manipulations of the MythTV database. It's easier
that way.

The point is my tuners are changed frequently. And don't get me started
on how often I need to change the channel setups. Bah and humbug!

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jra at baylink

Oct 14, 2013, 8:44 AM

Post #35 of 43 (1087 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

----- Original Message -----
> From: "Stephen Worthington" <stephen_agent [at] jsw>

> >And that's patently ridiculous: how often are tuners *actually*
> >changed on production machines? Every 3 or 4 years?
>
> That depends on your situation - mine have never been stable so far
> for more than two years, due to changing technology and hardware
> failures. My mother's box has been more stable - it is probably three
> years now since I added her third DVB-T tuner.

Even so: the purpose for this particular feature (the only use case,
so far as I can see) is "this recording looks crappy; which tuner is
suddenly having a problem". That's a "what tuner was being used last week"
question, by and large; it's clear that if you change tuners, the old
data won't mean anything, but since I can't see that anyone would *care*...

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra [at] baylink
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


gary.buhrmaster at gmail

Oct 14, 2013, 4:46 PM

Post #36 of 43 (1084 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Sun, Oct 13, 2013 at 6:31 PM, David Engel <david [at] istwok> wrote:
...
> Yes, we'd accept a patch adding the input display name to the recorded
> table. Please also make that information available in the details
> screen and to the theme.

How about the people interested "crowdsource" the patch?
Here is my contribution to update the schema. Untested,
but looks right. Someone else can contribute to the theme,
and someone else can contribute to the details screen, and
lastly someone else can add the code to fill in the value
(yes, I chose the "easy" one to do).

Note that I have not "vetted" the chosen column name, so
the devs might have a better name in mind.



diff --git a/mythtv/libs/libmythtv/dbcheck.cpp
b/mythtv/libs/libmythtv/dbcheck.cpp
index db8d59b..198c5c2 100644
--- a/mythtv/libs/libmythtv/dbcheck.cpp
+++ b/mythtv/libs/libmythtv/dbcheck.cpp
@@ -2521,7 +2521,19 @@ NULL
if (!performActualUpdate(&updates[0], "1318", dbver))
return false;
}
-
+
+ if (dbver == "1318")
+ {
+ // Add support for storing cardinput displayname to recorded
+ const char *updates[] = {
+ "ALTER TABLE recorded ADD COLUMN cardinputdisplayname
varchar(64) NOT NULL DEFAULT '';",
+ NULL
+ };
+
+ if (!performActualUpdate(&updates[0], "1319", dbver))
+ return false;
+ }
+

return true;
}
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 18, 2013, 7:52 AM

Post #37 of 43 (1059 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On 10/11/2013 09:57 PM, Stephen Worthington wrote:
> On Fri, 11 Oct 2013 13:03:23 -0400 (EDT), you wrote:
>
>> On a related topic, does the backend store which tuner a recording was
>> made on? If so, is it terribly hard to expose that in a theme?
> That information is only in the logs. I use this script:
>
> http://www.mythtv.org/wiki/Which_recorder.pl
>
> installed into my backend status page on mythweb to display it. I had
> to modify it to make it work with the current log file format. I
> commented out the big if at line 45 and replaced it with this:
>
> if (/^([A-Z][a-z][a-z] [ 0-9]\d \d\d:\d\d:\d\d) .* Tuning
> recording: (.*): channel (\d+) on cardid (\d+), sourceid (\d+)/)
>
> See here for how to make it work with mythweb:
>
> http://www.mythtv.org/wiki/Miscellaneous_Status_Information
>
> Of course, that only makes available the information in the current
> log file, so if you need to use it a long time after the recording was
> made it will be gone.

Feel free to update the wiki page with the new logging regex.

Thanks,
Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 18, 2013, 8:18 AM

Post #38 of 43 (1057 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

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 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 MythTV that does
so, and, yes, that code is wrong, too, and needs fixing).

And, FWIW, we also need user-specified card names (to replace the
"Encoder 4" or whatever on backend status page and Upcoming Recordings
list).

So, storing the user-specified card input display name would be OK--but
only if we are sure to make it completely clear that the name can *only*
match up to the exact same physical hardware if a) the user has only one
capture device or b) the user does external (non-MythTV) configuration
of the underlying system to make sure that the physical device matches
up to the same kernel device on every reboot. (Which is why we've taken
the "use the logs" approach in the past--because the value stored to say
which card my system used in 2006 to record that episode of New Yankee
Workshop is meaningless information, today, even though I still haven't
watched the recording and, therefore, still have the recording and its
metadata. Having the value in the logs, only, helps to enforce the idea
that the information is ephemeral, as is the configuration of the system
at any given time. That said, I won't complain if someone stores the
card input display name the user has configured, but *only* of someone
else explains to them the intricacies of udev and kernel numbers and
that they can't assume that today's configuration is the same as the one
that existed a year earlier. I will complain loudly if someone exposes
the (database-internal) card input ID to the user. :)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


bkamen at benjammin

Oct 18, 2013, 8:32 AM

Post #39 of 43 (1052 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On 2013-10-18 10:18 AM, 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.

As a sidenote: I did run a setup for a while using one tuner for Cable (before Clear-QAM went away) and one on a OTA connection.

Now I have an HDHR-prime with a CC installed, so any tuner cards will now all be OTA.

At some point, I was contemplating multiple OTA antennae because my stations are in different directions..
but that's a project for another day.

-Ben

--
Ben Kamen - O.D.T., S.P.
----------------------------------------------------------------------
eMail: ben [at] benjammin http://www.benjammin.net
Fortune says:
There's nothing disgusting about it [the Companion]. It's just another
life form, that's all. You get used to those things.
-- McCoy, "Metamorphosis", stardate 3219.8
- -
NOTICE: All legal disclaimers sent to benjammin.net/benkamen.net
or any of it's affiliated domains are rendered null and void on
receipt of communications and will be handled/considered as such.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


darylangela at gmail

Oct 18, 2013, 10:33 AM

Post #40 of 43 (1052 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On Fri, Oct 18, 2013 at 11:32 AM, Ben Kamen <bkamen [at] benjammin> wrote:
> On 2013-10-18 10:18 AM, 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.
>
>
> As a sidenote: I did run a setup for a while using one tuner for Cable
> (before Clear-QAM went away) and one on a OTA connection.
>
> Now I have an HDHR-prime with a CC installed, so any tuner cards will now
> all be OTA.
>
> At some point, I was contemplating multiple OTA antennae because my stations
> are in different directions..
> but that's a project for another day.
>
> -Ben
>
> --
> Ben Kamen - O.D.T., S.P.
> ----------------------------------------------------------------------
> eMail: ben [at] benjammin http://www.benjammin.net
> Fortune says:
> There's nothing disgusting about it [the Companion]. It's just another
> life form, that's all. You get used to those things.
> -- McCoy, "Metamorphosis", stardate 3219.8
> - -
> NOTICE: All legal disclaimers sent to benjammin.net/benkamen.net
> or any of it's affiliated domains are rendered null and void on
> receipt of communications and will be handled/considered as such.
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

At some point, I was contemplating multiple OTA antennae because my stations
> are in different directions..
> but that's a project for another day.

I have a home made multi-directional HD antenna mounted 5' above my
roof-top, works great for all my available channels. It is essentially
two pairs of antennae facing eight directions, north, north-east,
east, south-east, south, south-west, west, and north-west the right of
each connected to the ground of the coax and the left to the carrier.
Originally an indoor unit I would get pixelation when traffic went by
my house, now with elevation it is rock solid.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


jedi at mishnet

Oct 18, 2013, 11:52 AM

Post #41 of 43 (1051 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

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.

> 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.

[deletia]
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 18, 2013, 12:12 PM

Post #42 of 43 (1051 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

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
meaningful.

>> 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.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

Oct 18, 2013, 12:21 PM

Post #43 of 43 (1046 views)
Permalink
Re: Hauppauge PVR questions [In reply to]

On 10/18/2013 02:52 PM, jedi wrote:
> 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.

Oh, and FWIW, this makes it sound like a developer on the project can
just throw something together and push it to git in a few minutes. It's
important to note that any changes to MythTV--regardless of how well the
person doing the changes knows the existing code--take quite a bit of
time. Even running a simple "smoke test" takes many, many minutes, just
to get the apparatus in place for testing (and that's not even taking
into account all the effort of planning and developing the code, and all
the supporting code--let alone a proper test that all boundary
conditions are handled correctly).

Any "defeatest paralysis" you may think exists in the project is
actually just a lack of time available to do the work. No one has ever
said we can't store something to help users, but we are saying we will
only allow it to be done properly in a way that doesn't tend to make
untrue assurances to users--even those users who don't know as much
about the kernel/device handling as you do. (And I mean that
sincerely--your knowledge of GNU/Linux is much greater than many other
users' knowledge, so it's important to think of it from a, "What if I
didn't know what I know?" perspective.)

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

First page Previous page 1 2 Next page Last page  View All MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.