[mythtv] Use callsign for scheduling

[Brian May]

>>>>> "David" == David Engel <gigem at comcast.net> writes:

    David> How are mythweb, mythfilldatabase, the scheduler or
    David> anything else which uses the channel table affected?

    David> Is the program table changed?  Assuming you now have unique
    David> stationids, wouldn't it make sense tie programs to stations
    David> instead of channels?

Yes, this was the general idea. I should have included that in my
plan.  Possibly this would be step two, after the step I already
proposed (unless you want to make all the changes in one big hit,
which might also be a good strategy).

    David> What is a user supposed to do if their grabber sets up two
    David> channels to different stations when they are really the
    David> same station?  What happens to their existing record
    David> entries?

If the grabber sets them up as two separate stations, then it is buggy
and needs to get fixed. In this case, mythtv must treat them as two
separate stations.

    David> What is a user supposed to do if their channels get changed
    David> and their grabber creates new stationids because it doesn't
    David> or can't tell the difference between inserts, deletes and
    David> moves?  What happens to their existing record entries?

I am not sure what you are getting at here, I think Tako has answered
this anyway. Again, it would sound like a buggy grabber that needs to
be fixed.

    David> I'm not picking on you.  Rather, I'm trying to point out
    David> that there is a lot more to consider, especially with xmltv
    David> grabbers that don't provide everything we would like.

No problem.

>>>>> "Tako" == Tako Schotanus <quintesse at palacio-cristal.com> writes:

    Tako> I was wondering though, why the need for backwards
    Tako> compatibility?  Doesn't this only complicates the situation
    Tako> unnecessarily? Is there any reason why a new database (with
    Tako> a station table) should be able to function with older
    Tako> versions of MythTV? Otherwise I would add this remark
    Tako> related to the items I marked with (*) : this could be
    Tako> handled by the database updater.

David said:

>>>>> "David" == David Engel <gigem at comcast.net> writes:

    David> OK, then quit complaining and make a concrete proposal (or
    David> better yet, a patch) to do this.  Please make sure it
    David> handles upgrading and backwards and forwards compatibility.

So I assumed backwards compatibility was a priority. Perhaps I
misunderstood him?

It would make things simpler not to have to worry about this.

>>>>> "David" == David Engel <gigem at comcast.net> writes:

    David> Those are very good questions.  I don't believe I've ever
    David> seen any stated guidelines for backwards compatibility.
    David> I'm pretty sure that a lot of previous database-related
    David> upgrades have not been compatible in both directions.

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

I think mythtv is still a "unstable" project, which means backwards
compatibility isn't yet a high priority.

People probably should backup there databases before upgrading anyway,
just in case the new version doesn't work and a downgrade to
temporarily required.
-- 
Brian May <bam at snoopy.apana.org.au>