Opened 17 years ago

Closed 13 years ago

#5 closed defect (fixed)

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

Reported by: lincoln Owned by: lincoln
Priority: major Milestone: 1.0
Component: Reconciler Version: 0.3
Keywords: Cc:

Description (last modified by 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.

Change History (7)

comment:1 Changed 17 years ago by peter

Component: ShepherdReconciler

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.

comment:2 Changed 17 years ago by lincoln

Description: modified (diff)

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.


comment:3 Changed 17 years ago by Max

Milestone: 1.0

comment:4 Changed 17 years ago by lincoln

Owner: set to lincoln
Status: newassigned

comment:5 Changed 17 years ago by lincoln

Resolution: fixed
Status: assignedclosed

as per [294]

comment:6 Changed 13 years ago by anonymous

Component: ReconcilerConfiguration
Keywords: ipqqmrvags added
Milestone: 1.0
Priority: majorminor
Resolution: fixed
Status: closedreopened
Type: defecttask
Version: 0.31.x

comment:7 Changed 13 years ago by Max

Component: ConfigurationReconciler
Keywords: ipqqmrvags removed
Milestone: 1.0
Priority: minormajor
Resolution: fixed
Status: reopenedclosed
Type: taskdefect
Version: 1.x0.3

revert spam

Note: See TracTickets for help on using tickets.