Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#7818 closed enhancement (wontfix)

allow preffered input group for scheduling

Reported by: Mark Spieth Owned by: gigem
Priority: minor Milestone: unknown
Component: MythTV - Scheduling Version: unknown
Severity: medium Keywords:
Cc: Ticket locked: no

Description

With multiple inputs per physical input, it is probably more sensible to have input group preferences for programs instead of specific cardinputs.

patch attached to implement this.

Attachments (2)

mythtv_inputgrouppref.patch (3.9 KB) - added by Mark Spieth 10 years ago.
mythtv_inputgrouppref.2.patch (4.9 KB) - added by Mark Spieth 10 years ago.
updated patch

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by Mark Spieth

Attachment: mythtv_inputgrouppref.patch added

comment:1 Changed 10 years ago by gigem

Status: newinfoneeded_new

bjm added the preferred input support based on an idea from me. I envisioned something more flexible, but couldn't come up with a simple enough implementation to justify it. We settled on the single, preferred input approach because it was simple and an expert user could use it to coerce the scheduler into doing the desired thing when needed.

My gut reaction is to reject this new patch for the same reasons we didn't do more in the first place -- it isn't flexible enough to justify the extra complexity. I'd much rather see effort put into making the existing power priority support be made more accessible.

Still, I might consider this change, and that's an awfully big might, if the following issues can be addressed.

  1. Use negative numbers to identify inputgroups instead of +1000. I thinks that would be a little more elegant.
  1. The join condition on the inputgroup table in the scheduler BUQ (big ugly query) is bogus.
  1. This is the biggie. Inputs can belong to multiple inputgroups. Even if the join condition mentioned above is fixed, this wouldn't be handled correctly.

comment:2 Changed 10 years ago by robertm

Resolution: wontfix
Status: infoneeded_newclosed

No response (but please feel free to reopen if you meet the criterion listed above).

Changed 10 years ago by Mark Spieth

updated patch

comment:3 Changed 10 years ago by Mark Spieth

issues 1 and 2 addressed. issue 3 is not.

solution works within those constraints.

leaving closed due to non compliance of issue 3.

may be useful to someone.

Note: See TracTickets for help on using tickets.