Opened 13 years ago
Closed 11 years ago
#4795 closed defect (fixed)
Conflict resolution menu does not include Never Record option
Reported by: | Nick Morrott <knowledgejunkie(at)gmail(dot)com> | Owned by: | |
---|---|---|---|
Priority: | trivial | Milestone: | 0.23 |
Component: | MythTV - Scheduling | Version: | head |
Severity: | low | Keywords: | conflict resolution never record |
Cc: | Ticket locked: | no |
Description
When using the recording conflict resolution menu (on the Upcoming Recordings listings for example) the option to 'Never Record' a programme is seemingly not made available (on r14770).
This means that it is not possible to forcibly flag a recording (that just so happens to be conflicting) to never record, which is possible for all other non-conflicting scheduled recordings, duplicate-detection allowing.
Change History (10)
comment:1 Changed 12 years ago by
Milestone: | → 0.22 |
---|---|
Priority: | minor → trivial |
Severity: | medium → low |
comment:2 Changed 12 years ago by
comment:3 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
Closing at submitters request
comment:4 Changed 12 years ago by
Taking a closer look in current trunk, I have a query before this ticket is closed or investigated further:
===== When *exactly* should the Never Record option be displayed on the menu? Should it only be displayed when the selected dupe detection method will work for the current programme? =====
I've been experimenting with a record rule for a show "Medical Detectives" that gets listings via EIT on DVB-S. There are no program subtitles available, only descriptions. I set this rule up (anytime on channel) to purposefully conflict with another recording to test the initial reason for this ticket.
With Subtitle & Description dupe matching:
No dupes are found/marked due to the missing subtitles in the listings and the selected dupe detection (as expected). However, the entries marked as conflicting, and earlier/later unconflicting entries all include a "Never record" option on their menus, even though it does nothing due to the dupe detection method. In the future it would do something if another rule matching the title was created, or the current rule was amended.
With Subtitle then Description dupe matching:
With blank subtitles but good descriptions, the dupe detection works as expected and the scheduler can move the conflicting showings to a later time. However, the entries marked later (and guessing any earlier entries too) do not include a "Never record" option on their schedule menu, whilst the bumped copies of those entries do. Here I think that they should all have the option so that a user can use any of the entries (earlier, later or the entry that will record) to add a 'fake' recorded entry into oldrecorded.
With subtitle dupe matching:
None of the upcoming recordings matching the title have a "Never Record" entry on their menu (as would be expected).
With description dupe matching:
*ALL* entries have Never Record entries, even those flagged as record later (contrast this with sub-then-desc above)
With no dupe matching:
Again, none of the upcoming recordings matching the title have a "Never Record" entry on their menu (as would be expected).
comment:5 Changed 12 years ago by
Resolution: | invalid |
---|---|
Status: | closed → new |
comment:6 Changed 11 years ago by
Component: | mythtv → MythTV - User Interface Library |
---|---|
Owner: | changed from Isaac Richards to stuartm |
Status: | new → accepted |
comment:7 Changed 11 years ago by
Milestone: | 0.22 → 0.23 |
---|
Pushing this to 0.23, it's not a major bug if it's even a bug at all.
comment:8 Changed 11 years ago by
Component: | MythTV - User Interface Library → MythTV - Scheduling |
---|---|
Owner: | stuartm deleted |
Status: | accepted → new |
David, maybe you can clarify when 'Never Record' isn't shown.
comment:9 Changed 11 years ago by
comment:10 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
The subtitle-then-description case wasn't being handled. I added it, but that code is so dense I'm not positive it truly fixes the problem. I'd appreciate it if Nick would recheck this.
The behaviour I was seeing when the ticket was reported was likely due to the conflicting programme's duplicate detection method and possible omission of a subtitle.
Current trunk (tested with r20931) *does* display the Don't Record/Never? Record options for conflicting entries in the upcomings list, so this ticket can be closed.