preferred-title grabber not called frequently enough to possibly avoid incorrect title choice

[lincoln]

preferred-title grabber not called frequently enough to possibly avoid incorrect title choice.

the events that cause it are:

• grabberP is our 'preferred' title source
• day 1: shepherd runs grabberP as a preferred source. grabberP populates days 1-7 with preferred titles.
• day 2: shepherd runs grabberA, a 'cheaper' cost grabber. grabberA populates days 2-8. preferred titles for programmes on days 2-7 come from previously-populated grabberP. but if a programme on day 8 was wasn't on in days 1-7 (lets call it programmeC), we will install a preferred title as per what we've seen from grabberA (programmeCa). an existing recording schedule in mythtv for recording programmeCp may fail to match programmeCa's title.

even if we enhanced the reconciler to rewrite the "preferred programme table" if in some future instance grabberP runs and it realizes it had put title programmeCa in rather than programmeCp, it may be too late for some recordings that may have been missed.

[peter]

I don't think this problem can be fixed, at least not without a more intimate connection between Myth and Shepherd.

Consider two cases following the scenerio above: 1) programCp was previously scheduled to be recorded, and 2) programCp was not previously scheduled to be recorded, but after the grab which didn't use grabberP and therefore named the program programCa, the user scheduled programCa to record. So in scenerio 1, when we do run grabberP again, we should rename the program to programCp, so it will be recorded, while in scenerio 2, we must not revert to calling it programCp, or Myth will not record it.

I think it is worse to do the wrong thing for scenerio 2 than for scenerio 1, since in the case of scenerio 1, a Myth user can detect the problem when they see, eg, "House, MD" in their new program listing when "House" is scheduled to be recorded, and schedule it to be recorded. Whereas in scenerio 2, myth will have seen both the old and new program names before (the old name from before the user switched to Shepherd), so when Shepherd switches the name back to the old preferred name, the user will not have any way to notice it.

Therefore, on the whole I think it is better for Shepherd to keep program names unchanged once it has emitted them. Ie, I agree with the second part of your suggested fix, but not the first.

[lincoln]

Proposed solution

Add retrospective preferred titles into reconciler.

This would be implemented something like:

• the reconciler remembers last 14 days of programme titles.
• these are stored as: 'day of week' + 'start' + 'duration' + 'title'.

When it comes to looking up a preferred title, we try do a canonicalizeTitles_match() (fuzzy) against programmes previously seen starting/ending within n seconds on the same day.

If we get a match then store the previously-seen title as our preferred title and use that. Since we're only doing the canonicalizeTitles_match() against programmes in the same timeslot we shouldn't get false positives.

If we don't get a match then we proceed as we currently do.

thoughts?

[lincoln]

as per [294]

[max]

revert spam