Mailing List Archive: MythTV: Dev

[PATCH] Control duplicates by channel ID

1 2

View All

Index | Next | Previous | View Threaded

david at shay

Aug 8, 2007, 12:45 PM

Post #26 of 35 (1242 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/7/07, David Shay <david [at] shay> wrote:
> On 8/7/07, David Shay <david [at] shay> wrote:
> > On 8/7/07, David Engel <david [at] istwok> wrote:
> > > On Tue, Aug 07, 2007 at 01:56:18PM -0500, David Shay wrote:
> > > > > Yes, the AddHistory should also be qualified by
> > > > >
> > > > > nextRecording->recstartts <= schedTime
> > > >
> > > > After some more thought, I wondered if maybe the check should be a
> > > > call to IsSameTimeslot instead? I'll try some things out tonight.
> > >
> > > I don't follow. In PruneRedundants(), any call to AddHistory() must
> > > be qualified by the current time in order to match how it would have
> > > been called in RunScheduler(). IOW, anything in that might happen in
> > > the future is still conjecture at that point. Only after the
> > > scheduler would have acted on something, does it become a mater or
> > > record.
> > >
> >
> > Sorry, I wasn't clear. I meant not JUST the check for <= schedtime
> > but ALSO a check to IsSameTimeslot so that we were only adding the
> > "precise" "potentially unnecessarily duplicate" entries to
> > oldrecorded.
> >
> Well, never mind about that. That check isn't needed. But, this
> doesn't completely solve the problem. Here was a sample case:
>
> 1 record rule, any channel, new duplicate rule set to off (normal,
> existing behavior)
> show matches 3 showings, 2 on one callsign, 1 on a different callsign.
> Scheduler detects 1 of the showing on the same callsign as will
> record, the other as other showing. The one on the different callsign
> is EarlierShowing. So far, so good.
> Recording starts. Only 2 entries get added to oldrecorded, the one
> for the chanid with the callsign it is really being recorded on
> (status -2), and the one with the chanid and the different callsign
> (status 4). It should have added the other chanid, but didn't. It
> must not have made it through to PruneRedundants at that point, I
> guess. (I'll need to add more debug stuff to check why not).

OK, determined the problem to be that the scheduler runs in advance of
the program starting, so the check on recstartts <= schedtime is
false, so the record doesn't get added. The scheduler doesn't re-run
again until after the program has ended rerecording, which after the
statuses have already been screwed up by the call as below. Not sure
what the right check here is, but it's not against schedtime I don't
think.

>
> Recording ends. The additional entry gets added to oldrecorded, but
> with a status of -3 for recorded, when it should have been 13 for
> othershowing. The one that was really recorded also gets set to -3.
> I've traced this back, I think, to the fact that when a recording ends
> it updates it's status via a call to UpdateRecStatus using a pointer
> to *pginfo structure, which then uses IsSameProgramTimeSlot.
>
> Initially, I had further qualified the call here to do the check if
> dupchanid was set, then to also check on matching channel ID's. In
> this case, the new dupchanid was not in effect, so it just went about
> it's merry way iterating through, found 2 matches for the same
> callsign via IsSameProgramTimeSlot and updated them both with the
> recorded status, incorrectly.
>
> I'm not 100% certain of this, but if the goal is to always add
> oldrecorded entries for the past/current stuff, maybe UpdateRecStatus
> should just ALWAYS check on a chanid match, just like the join in
> FromProgram will now always join on chanid.
>
> Still have to solve the problem of why the initial same callsign/not
> recording channel ID didn't get to oldrecorded first, but if it HAD,
> then the above logic would work.
>
> Thoughts?
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 8, 2007, 7:06 PM

Post #27 of 35 (1227 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On Wed, Aug 08, 2007 at 02:45:03PM -0500, David Shay wrote:
> OK, determined the problem to be that the scheduler runs in advance of
> the program starting, so the check on recstartts <= schedtime is
> false, so the record doesn't get added. The scheduler doesn't re-run
> again until after the program has ended rerecording, which after the
> statuses have already been screwed up by the call as below. Not sure
> what the right check here is, but it's not against schedtime I don't
> think.

Besides the problems you've already noted, I thought of some others
which effectlively make doing AddHistorys in PruneRedundants a
non-starter. This remaining option at the moment is to change
PruneRedundants to coalesce on chanid instead of callsign and then
deal with all the places into which that ripples.

To be honest, I really don't like how pervasive this change is
becoming. I'd much rather find a less intrusive alternative. Heck,
even an out right hack for such a special case feature might be
better. Of course, I'm biased since I don't foresee myself using
this. One hair-brained idea I've considered is munging titles and
programids on the fly to trick the scheduler into thinking the same
program on different chanids is really different. Another one is
automatically create special manual recording rules as needed. You
never know, something way outside the box might just do the trick too.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at shay

Aug 8, 2007, 9:52 PM

Post #28 of 35 (1225 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/8/07, David Engel <david [at] istwok> wrote:
> On Wed, Aug 08, 2007 at 02:45:03PM -0500, David Shay wrote:
> > OK, determined the problem to be that the scheduler runs in advance of
> > the program starting, so the check on recstartts <= schedtime is
> > false, so the record doesn't get added. The scheduler doesn't re-run
> > again until after the program has ended rerecording, which after the
> > statuses have already been screwed up by the call as below. Not sure
> > what the right check here is, but it's not against schedtime I don't
> > think.
>
> Besides the problems you've already noted, I thought of some others
> which effectlively make doing AddHistorys in PruneRedundants a
> non-starter. This remaining option at the moment is to change
> PruneRedundants to coalesce on chanid instead of callsign and then
> deal with all the places into which that ripples.
>
> To be honest, I really don't like how pervasive this change is
> becoming. I'd much rather find a less intrusive alternative. Heck,
> even an out right hack for such a special case feature might be
> better. Of course, I'm biased since I don't foresee myself using
> this. One hair-brained idea I've considered is munging titles and
> programids on the fly to trick the scheduler into thinking the same
> program on different chanids is really different. Another one is
> automatically create special manual recording rules as needed. You
> never know, something way outside the box might just do the trick too.
>
> David
>

I'm not ready to give up yet (because I REALLY want to use this...I
was recording HD and SDTV for a while and had to keep adding override
entries to make it work, since I still wanted to take advantage of
duplicate detection). From my perspective, if we can figure out how
to get all relevant entries into oldrecorded, I think the rest will
work.

How about inserting a new function when the recording starts that
inserts the appropriate additional rows. It could find other showings
on at the same time, check their current status in oldrecorded, and
*only* if it didn't exist, create it with a status of rsOtherShowing,
otherwise leave it alone. Could be a race condition (although I think
that logic already might stop it) with multiple shows starting at the
same time, but I think that could be handled.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 9, 2007, 11:54 AM

Post #29 of 35 (1239 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On Wed, Aug 08, 2007 at 11:52:29PM -0500, David Shay wrote:
> I'm not ready to give up yet (because I REALLY want to use this...I
> was recording HD and SDTV for a while and had to keep adding override

I'm not asking you to give. I was mainly throwing something out there
in hopes of sparking a new idea.

> entries to make it work, since I still wanted to take advantage of
> duplicate detection). From my perspective, if we can figure out how
> to get all relevant entries into oldrecorded, I think the rest will
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (* see below)

> How about inserting a new function when the recording starts that
> inserts the appropriate additional rows. It could find other showings
> on at the same time, check their current status in oldrecorded, and
> [...]

This all hinges on changing oldrecorded to index on chanid instead of
callsign. If that change is made, I think the rest of the scheduler
needs to also change to fundamentally group things by chanid.
Anything less will be madness, IMO.

(*) This might have sparked one of those ideas. Instead of changing
oldrecorded to match our special case data, let's change our special
case data to use the existing oldrecorded but still achieve the
desired result. My local NBC affiliate is KXAS and shows up as
chanids 1005, 3101 and 3131 for me. What if for these special rules,
and only these special rules, the scheduler saw callsigns like
"KXAS/1005", "KXAS/3101" and "KXAS/3131" for the respective chanids
instead of them all being the same "KXAS"? Voila, the indexing
problem on oldrecorded goes away.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at shay

Aug 10, 2007, 12:00 PM

Post #30 of 35 (1237 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/9/07, David Engel <david [at] istwok> wrote:
> On Wed, Aug 08, 2007 at 11:52:29PM -0500, David Shay wrote:
> > I'm not ready to give up yet (because I REALLY want to use this...I
> > was recording HD and SDTV for a while and had to keep adding override
>
> I'm not asking you to give. I was mainly throwing something out there
> in hopes of sparking a new idea.
>
> > entries to make it work, since I still wanted to take advantage of
> > duplicate detection). From my perspective, if we can figure out how
> > to get all relevant entries into oldrecorded, I think the rest will
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (* see below)
>
> > How about inserting a new function when the recording starts that
> > inserts the appropriate additional rows. It could find other showings
> > on at the same time, check their current status in oldrecorded, and
> > [...]
>
> This all hinges on changing oldrecorded to index on chanid instead of
> callsign. If that change is made, I think the rest of the scheduler
> needs to also change to fundamentally group things by chanid.
> Anything less will be madness, IMO.

I'm not sure. I had hoped initially that changing the key wouldn't be
that large of a problem since most of the calls were qualified by
chanid already. I still am going to do more exploring on how you
could get those oldrecorded entries in there somehow. Maybe that's
still just putting one more finger in the dike -- I don't know.

>
> (*) This might have sparked one of those ideas. Instead of changing
> oldrecorded to match our special case data, let's change our special
> case data to use the existing oldrecorded but still achieve the
> desired result. My local NBC affiliate is KXAS and shows up as
> chanids 1005, 3101 and 3131 for me. What if for these special rules,
> and only these special rules, the scheduler saw callsigns like
> "KXAS/1005", "KXAS/3101" and "KXAS/3131" for the respective chanids
> instead of them all being the same "KXAS"? Voila, the indexing
> problem on oldrecorded goes away.
>

This is definitely an interesting "out of the box" thought. I haven't
played it all the way out yet. My first glance was at the
oldrecorded/oldstatus join in FromProgram, which is what was biting us
in the current situation. If we change the callsign in oldrecorded to
be the concantenated value, the join from program would fail (since in
program it would not be manipulated, I would assume you would
manipulate it in "record", though). Since the join would fail, it
would not pick up the oldrecorded status. I suppose it might be
possible to craft the join in such a way, though that you joined on
either the straight callsign match *or* the concatentated
callsign/chanid match. That might make it work for there. I'll think
on this some more.

Also, I suppose we would have to increase the length of station in
recorded/oldrecorded on the offchance that somebody has really long
callsign values, or trim them to a length of 15 before concatenating .
Trimming would make doing the join in SQL like above harder, but that
might be the only place where the SQL simulation of this would be
necessary. Again, I've only contemplated it for a little bit. This
will add even more conditional logic on dupchanid to now manipulate
callsigns as well as manipulating duplicate logic, but that might be
fine.

Haven't gotten back to code anything the last few days, nor will I
until next week at the rate work is going, but I'll keep mulling it
over.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

bjm at lvcm

Aug 10, 2007, 4:05 PM

Post #31 of 35 (1235 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

David Shay wrote:
...
> Determined what at least one of the problems here is. The primary key
> to oldrecorded does not include chanid. This makes the "REPLACE"
> statement in AddHistory not add a new record when it now should. I'm
> not sure if there would be any other impacts of just adding chanid
> into the key for oldrecorded.

I haven't really been following this while you guys hash
this out but here's a random thought that may point in a
different direction...

"REPLACE" isn't engraved in granite. It's a shortcut for
DELETE FROM then INSERT INTO only much less flexible. You
could use starttime/title/chanid as the key because chanid
is a subset of station and not the other way around. For
normal rules:

DELETE FROM oldrec WHERE starttime/title/station;
INSERT INTO oldrec (starttime,title,chanid,station,...);

For dupchanid:

DELETE FROM oldrec WHERE starttime/title/chanid;
INSERT INTO oldrec (starttime,title,chanid,station,...);

The first bug would be that if a normal rule and a dupchanid
rule are recording the same show on a different chanid, the
first "DELETE" above would remove all entries for any chanid
of that station. Maybe starttime/title/station/recordid; or
something. I think a normal and dupchanid fighting for the
same showing may raise other issues too.

-- bjm
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 11, 2007, 9:36 AM

Post #32 of 35 (1223 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On Fri, Aug 10, 2007 at 02:00:25PM -0500, David Shay wrote:
> This is definitely an interesting "out of the box" thought. I haven't
> played it all the way out yet. My first glance was at the
> oldrecorded/oldstatus join in FromProgram, which is what was biting us
> in the current situation. If we change the callsign in oldrecorded to

Ah, yes. Oh, well. As you noted, the problem with the FromProgram
join could possibly be overcome. I wouldn't throw this option
completely out yet, but this does make this hack less elegant.

> Haven't gotten back to code anything the last few days, nor will I
> until next week at the rate work is going, but I'll keep mulling it
> over.

OK. It's looking again like changing PruneRedundants to group by
chanid instead of callsign and dealing with the fallout from that is
the best current option.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at istwok

Aug 11, 2007, 9:43 AM

Post #33 of 35 (1213 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On Fri, Aug 10, 2007 at 04:05:38PM -0700, Bruce Markey wrote:
> The first bug would be that if a normal rule and a dupchanid
> rule are recording the same show on a different chanid, the
> first "DELETE" above would remove all entries for any chanid
> of that station. Maybe starttime/title/station/recordid; or
> something. I think a normal and dupchanid fighting for the
> same showing may raise other issues too.

Something like this has occurred to me as well. My fear is it could
lead to some pretty subtle bugs in the case you cited. I'll have to
ponder it some more.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

david at shay

Sep 6, 2007, 7:04 PM

Post #34 of 35 (1095 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On 8/11/07, David Engel <david [at] istwok> wrote:
>
> On Fri, Aug 10, 2007 at 02:00:25PM -0500, David Shay wrote:
> > This is definitely an interesting "out of the box" thought. I haven't
> > played it all the way out yet. My first glance was at the
> > oldrecorded/oldstatus join in FromProgram, which is what was biting us
> > in the current situation. If we change the callsign in oldrecorded to
>
> Ah, yes. Oh, well. As you noted, the problem with the FromProgram
> join could possibly be overcome. I wouldn't throw this option
> completely out yet, but this does make this hack less elegant.
>
> > Haven't gotten back to code anything the last few days, nor will I
> > until next week at the rate work is going, but I'll keep mulling it
> > over.
>
> OK. It's looking again like changing PruneRedundants to group by
> chanid instead of callsign and dealing with the fallout from that is
> the best current option.

Alright. Want to start looking at this again. Needed to get out of the
troll war that I accidentally got involved in on -users. *Slaps head and
vows not to do that again.

Anyway, I looked some more at concatenating callsign/chanid for these
special cases and I think it would lead to a lot of exception logic,
seemingly in more places than just FromRecorded.

If I rule that out temporarily for now, option 2 would still be to try to
figure out how to get all of the oldrecorded entries in. I still think
that's possible, but if I temporarily rule this out, and call option 3 your
"changing PruneRedundants to group by chanid instead of callsign", can you
describe what you believe the fallout would be?

david at istwok

Sep 8, 2007, 9:47 PM

Post #35 of 35 (1106 views)
Permalink

Re: [PATCH] Control duplicates by channel ID [In reply to]

On Thu, Sep 06, 2007 at 09:04:56PM -0500, David Shay wrote:
> If I rule that out temporarily for now, option 2 would still be to try to
> figure out how to get all of the oldrecorded entries in. I still think
> that's possible, but if I temporarily rule this out, and call option 3 your
> "changing PruneRedundants to group by chanid instead of callsign", can you
> describe what you believe the fallout would be?

Off the top of my head, here are the things I believe would need to be
addressed.

In AddNewRecords(), there is code which ignores candidate recordings
if that program is already being recorded. That code would need to be
changed to do the right thing for chanid and non-chanid rules.

Also in AddNewRecords(), the oldrecstatus JOIN would need to be
changed to match on chanid instead of callsign.

The code which sets oldrecorded.reactivate would need to be changed to
do the right thing for chanid and non-chanid rules -- set only the
entry for the specific chanid for a chanid rule or set all chanids for
a non-chanid rule.

In the Previously Recorded screen, there might need to be two
variations of the "Remove this episode" action -- one to remove only
that chanid and another to remove all chanids.

David
--
David Engel
david [at] istwok
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads