[mythtv] Use callsign for scheduling

Tako Schotanus quintesse at palacio-cristal.com
Wed Apr 21 14:51:58 EDT 2004



David Engel wrote:

>On Wed, Apr 21, 2004 at 03:32:00PM +0200, Tako Schotanus wrote:
>  
>
>>>What is a user supposed to do if their grabber sets up two channels to
>>>different stations when they are really the same station?
>>>      
>>>
>>I imagine the same as what happens when a user doesn't manually change
>>the callsign for two different channels to be the same because they are
>>actually both the same station. 
>>    
>>
>
>Currently, a user can change the callsign easily by using the channel
>editor.  If they're afraid of using mysql directly, how they do this
>with hidden stationids?
>  
>
Couldn't the channel editor be changed to offer the same functionality 
but take into account the station table as well?

>  
>
>>And in the case where the callsigns are
>>filled in by the grabber the system should automatically map channels to
>>the same station if their callsign is exactly the same.
>>    
>>
>
>Ah, so callsigns *can* be used to recognize stations are the same.
>What if the grabber fills in callsigns but doesn't give them the same
>ones?
>  
>
I was just comparing to the current situation (or is it not implemented 
yet?) where the callsign is (will be?) used to determine if a channel 
actually refers to the same station by making sure the callsign is the 
same. Just pointing out that basically the situation is the same (which 
I think is basically sound) but the implementation differs (IMO the 
"station table" propasal would be slightly better in certain 
circumstances than the"duplicate callsigns").

In the end I'm not going to lay awake at night if a seperate station 
table doesn't get implemented... until maybe the time that it hurts me 
because I have to redo my channel table, that is ;-)

>  
>
>>>I'm not picking on you.  Rather, I'm trying to point out that there is
>>>a lot more to consider, especially with xmltv grabbers that don't
>>>provide everything we would like.
>>>      
>>>
>>Of course the code will not write itself and if this station table idea
>>works out somebody would have to do it, but at this moment I don't see
>>    
>>
>
>Exactly.  Since I'm not terribly motivated to work on this right now,
>I want to make sure that whomever does thinks about these things.
>
>  
>
>>I was wondering though, why the need for backwards compatibility?
>>Doesn't this only complicates the situation unnecessarily? Is there any
>>reason why a new database (with a station table) should be able to
>>function with older versions of MythTV? Otherwise I would add this
>>remark related to the items I marked with (*) : this could be handled by
>>the database updater.
>>    
>>
>
>Those are very good questions.  I don't believe I've ever seen any
>stated guidelines for backwards compatibility.  I'm pretty sure that a
>lot of previous database-related upgrades have not been compatible in
>both directions.
>  
>
I'm sure about that as well, that's why it surprised me that the 
"station table" proposal made by Brian explicitly referred to backward 
compatibility.

>The only reason I supported it this time around is because someone (I
>think Bruce) explicitly asked about it.  Now that the wrinkles
>(mysql4, unexpected NULL fields) have been ironed out, I would prefer
>tos remove the compatibility code.
>  
>
Agreed

>David
>  
>
>  
>
-Tako
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20040421/5f1254e7/attachment.html


More information about the mythtv-dev mailing list