[mythtv-users] Is this DB schema as ambiguous as it looks?

[f-myth-users@media.mit.edu]

I'm looking at a corner-case in the DB schema and am wondering if I'm
misreading the situation.  [Should I be sending this to -dev instead?]
I'm looking at 18, but I'm assuming this persists in 19, especially
since filenames in 19 now don't include the endtime (presumably 'cause
it might have gotten changed during the recording?).

Tables like recordedmarkup seem to identify recordings by a tuple of
(chanid, starttime), but that seems ambiguous---if you've got more
than one tuner, it's perfectly possible to start a recording at time
T on channel C as a normal recording, -and- to manually schedule a
recording that -also- starts at time T on channel C that goes for a
different length of time.  [See PS for why.]

So now we've got two completely different files but only one way to
refer to them in any table (like recordedmarkup) which doesn't also
use the end time to disambiguate.  Is this likely to fatally confuse
seeking or commflagging?  Might other things break?

(I've noticed this because my nearline/offline automation is currently
storing files with names of chanid_starttime_endtime and, when I go to
19 and it gets rid of the endtime in the filename, I'm going to be
change my side of the code to reinsert it in my offline files to
remove the ambiguity, and make the length of the recording more obvious
from just inspecting its name.)

Any comments?  Have I missed something?

(Yes, if this is likely to fatally confuse things, I can ensure that
any overlapping recordings I make start at a different minute, but if
-that's- the case, then either the DB ambiguity should be fixed, or
the UI should prevent me from confusing the situation in the first
place by doing this.)

P.S. I've actually done this while debugging things; for example, some
stations (one of my PBS affiliates in particular) have erratic
start-times on episodes, and if they're showing a marathon of them, I
might try to capture each episode individually -and- schedule a manual
recording that captures the entire set as a block.  (This is prompted,
in part, by trying to find tools that can do simple MPEG2 cutting
without losing closed captioning data; dvbcut might do this if I can
get it to compile; until then, having both forms of episodes for a few
days/weeks works.  This has also proven handy because of IVTV problems
wherein a sync glitch from the studio causes one but not every tuner
to then record bad video for the entire rest of the recording; I have
a case with two recordings of the same feed at the same time where
one's damaged and one's not & sent a report to ivtv-devel about this
a few days ago; being able to "cover" like this until this bug is
fixed is handy.)