[mythtv] [mythtv-commits] Ticket #4963: External channel changer is only passed frequency not channum

[Michael T. Dean]

On 03/28/2008 03:47 PM, Andrew M. Bishop wrote:
> Since this was my patch I thought that I should take my chance to
> reply although I am a bit late finding the message here.
>
> "Michael T. Dean" <mtdean at thirdcontact.com> writes:
>   
>> On 03/15/2008 11:00 AM, MythTV wrote:
>>     
>>> #4963: External channel changer is only passed frequency not channum
>>>  The external channel changer program is only passed the "freqid" parameter
>>>  and not the "channum".  This means that it cannot be used to tune anything
>>>  that outputs multiple channels on the same frequency.  For example a cable
>>>  TV box that has only a UHF output and no composite.
>>>       
>> The frequency is a user-configurable value meant to be the /identifier/
>> used by the external channel-change script that's used to change the
>> channel.  It is /not/ required to be a frequency.
>>     
> This means that freqid has different meanings for different things.
>   

It serves only as a frequency identifier.  Or, more generically, a "how 
to tune" identifier (since you seem to need both channel number and 
frequency).

> We already have "channum", "chanid" and "callsign" that are
> identifiers for the channel (for various definitions of the word
> "identifier").  Obviously "chanid" can only be a number and must be
> unique but "channum" already seems free to act as a random identifier
> like you are suggesting that "freqid" should be used as.
>   

freqid  | varchar(10)

Says it can be as random as you like (up to 10 chars).  If you want more 
than 10, IMHO, increasing the size of the column would be a better patch 
than one that changes how external channel change scripts are called.

Oh, and now that you mention channum, there is no requirement whatsoever 
that the user configure the channum to match the frequency identifier 
used by the frequency table.  This is by design to allow users to remap 
channel numbers that the cable company did wrong--i.e. instead of having 
Fox 35 on channel 3, where the stupid cable company put it, I can have 
it on channel 35, where it belongs.  Currently, channum is /only/ used 
to allow the user to type in some number to request a specific channel 
for LiveTV (and--along with callsign--to prevent display of "duplicates" 
in the program guide).

> Don't forget that "freqid" does have a specific meaning as a frequency
>   

Actually, no.  It's a "freq/id/" not a "freq/uency/".

> and existed as such a long time before external channel change scripts
> were added as a feature.
>   

Actually, MythTV currently understands that any value < 10000 
(technically, after adding finetune) is a channel identifier associated 
with the specified frequency table.  Otherwise, the value is treated as 
a frequency.

For external channel change scripts, Myth does /not/ interpret its 
value, so it can be whatever the external script requires.

>> As a matter of fact,
>> if you're using an external channel change script, storing a frequency
>> in this field is a waste as Myth has no need for a frequency.
> It does if you look at the last part of the patch description below.
>   

No.  Your channel change script has a need for frequency.  Again, if you 
specify an external channel change script, Myth never uses the value 
except to create the command-line argument used to call the script.  
However, it simply passes the value through; it does not interpret it in 
any way.

>> So, if you need to pass a frequency and a channel number, you can
>> "encode" them both into the value.  You may even be able to put them
>> into the freqid column as space-separated values that will be parsed by
>> the shell the same as occurs after your patch.  (The existing code looks
>> like that will happen fine.)  If so, fix your DB with a simple:
>> UPDATE channel SET freqid = CONCAT(freqid, ' ', channum);
>>     
> That sounds like a nasty hack to me rather than a real solution.
>   

Then make a freqid -> frequency map in your script and use anything you 
want as a frequency identifier.

>>>  The attached patch passes both the "freqid" and "channum" to the program
>>>  so that it can select whichever is appropriate (the first parameter is
>>>  unchanged so that existing scripts still work).
>>>       
>> This change may still require that users who currently use the freqid
>> properly have to change their channel change scripts (depending on the
>> actual construction of the channel change scripts).  If nothing else,
>> those who have simple argument number checks (i.e. if [ $# -eq 1 ])
>> would have to change their checks.
>>     
> So we can never change the way that the channel change script works
> for fear of breaking some scripts?
>   

That's not my decision, but the more complex the interface is, the more 
likely people will have problems understanding it.  Remember that the 
external channel change script is a user-visible interface with MythTV 
code, so the end user must be able to figure out how to use it.  (Think, 
"Why is my external channel change script receiving a huge number after 
the channel number?  I'm just trying to change to channel 2, so why does 
it say, '55250'?").  Passing a single argument to the script--typically, 
the channel number--is exactly what most people need.  Anything more is 
likely to cause confusion (many users don't even understand that a 
channel number is just an identifier that maps to a frequency defined by 
a frequency table because on every TV/STB/... they've ever owned, 
they've only see the channel number).

>>>  The patch also tunes to
>>>  the specified frequency if the input matches "*television*".
>> If you're using an external channel change script, it, IMHO, should do
>> /all/ of the channel changing.
>>     
> MythTV can make the change for me with this patch.  The external
> channel change script is for /external/ channel changing, not
> /internal/ channel changing of the device that MythTV controls.

But aren't you saying that you have the patch match on 'television' and 
pre-tune a channel?  If you specify a channel change script, it should 
do all the tuning.

Mike