[mythtv-users] ivtv 0.4.1 and later - input numbering for Tuner

[Michael T. Dean]

On 05/27/2006 01:59 PM, Nick wrote:
> On 27/05/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>   
>> On 05/27/2006 01:24 PM, Nick wrote:
>>     
>>> On 27/05/06, MIlos Prudek <prudek at bvx.cz> wrote:
>>>> I got Hauppauge PVR-150 and have a nicely working myth. Until I upgraded
>>>> from ivtv-0.4.0 to ivtv-0.4.5. Now I only see static.
>>> In the mythconverg database. the table 'capturecard'
>>>       
>> ... a bunch of stuff about editing the database ...
>>     
>>> You can check these two tables to make sure they agree to your ivtv
>>> and channel configurations. It may be
>>>       
>> ^H^H^H^H^H^Hdefinitely IS
>>     
> I still find it much quicker to log in via phpMyAdmin and check/change
> simple things like this, especially if it's just one card causing the
> problem, hence the 'may' ;-)

I'm just factoring in all the follow-up posts after a user changes a 
value to something illegal and breaks his/her Myth box even worse.  
Since there's absolutely no value checking when editing the database 
directly, users should not generally do so.  The mythtv-setup program 
(and the mythfrontend settings section) check values for you, so you 
can't put in bad ones.

As a matter of fact, the problem this user is experiencing is virtually 
equivalent to one caused by editing the database directly.  The data in 
the database (carried over from the previous configuration) is invalid 
(this time, though, because IvyTV changed).  Since it's already in the 
database, mythtv-setup assumes there must be some reason the user is 
specifying that information and allows it to stay--even though 
mythtv-setup wouldn't allow the user to specify that information if the 
user defined the card from scratch since the information is illegal.

So, if there's any way to accomplish something through mythtv-setup, 
mythfrontend, or MythWeb, that approach is the approved solution.  If 
not, careful and explicit descriptions of how to edit information in the 
database (like yours was) are OK, but should really be an indicator that 
someone needs to make a patch to allow fixing the issue through the GUI's.

Mike