Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 3 years ago

#9360 closed Bug Report (Fixed)

Delete - "Yes, and allow re-record" doesn't reschedule episodes

Reported by: skd5aner <skd5aner@…> Owned by: gigem
Priority: minor Milestone: 0.24.1
Component: MythTV - Scheduling Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by wagnerrp)

I'm no longer able to reschedule episodes of shows by using the "delete - yes, and allow re-record" option on a recording from the watch recordings screen. I believe, but can not confirm that this has happened sometime after the 0.22 release. I first noticed this behavior sometime during my usage of 0.23, after I finally looked at why episodes weren't eventually re-recording. I was waiting until after 0.24's release to see if the behavior resolved itself, but after testing, it appears to still be present. I can replicate it on any recording rule, new or old, where episodes are recorded, deleted and allowed to re-record, and then later re-aired.

Step to replicate:

1) Create a recording rule, an "any channel" rule for example, for a series that usually re-airs episodes (Discovery Channel/TLC/History typically air the same episodes multiple times a day/week).

2) Allow a non-generic episode to record that has a later airing.

3) Delete the recording through the watch recordings screen by going to Menu, Delete, select "Yes, and allow re-record".

4) Wait for the scheduler to run (or run mythbackend --resched)

5) Check the "Upcoming Episodes" screen for the recording rule and look for any airings of the same episode that was marked for delete and re-record. They will continue to be marked as "Record All - Previously Recorded" and will not be scheduled to record.

The only way to re-record (via the frontend UI) is to go into the recording history and forget the recording.

I have also tested this against the "Delete + rerecord" button in mythweb and it *does not* exhibit the same behavior - it actually works as expected. "Delete + rerecord" in mythweb, will both delete the recording and reschedule the episode to be re-recorded.

I typically would provide logs in the initial report, but I'm not sure which verbose options might be of use without further guidance. Please let me know and I'd be happy to report back with any details necessarily to help with the report.

Thank you in advance!

Attachments (3)

version_info (732 bytes) - added by wagnerrp 3 years ago.
attaching as a file, as the text says to
mythfrontend-deleteresched.log (26.3 KB) - added by skd5aner <skd5aner@…> 3 years ago.
Frontend Log
mythbackend-deleteresched.log (58.1 KB) - added by skd5aner <skd5aner@…> 3 years ago.
Backend Log (-v network)

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by wagnerrp

  • Description modified (diff)

Changed 3 years ago by wagnerrp

attaching as a file, as the text says to

comment:2 Changed 3 years ago by gigem

  • Status changed from new to infoneeded_new

I am unable to reproduce this problem. Can you please provide a log with -v network enabled?

Changed 3 years ago by skd5aner <skd5aner@…>

Frontend Log

Changed 3 years ago by skd5aner <skd5aner@…>

Backend Log (-v network)

comment:3 Changed 3 years ago by skd5aner <skd5aner@…>

Logs attached as requested, -v network for both frontend and backend. Please let me know if there are any additional details I might be able to provide that could help.

I set up a new channel specific rule (with default settings), manually started the one already in progress to record, stopped it after a minute, then delete and allow re-record. Went back in to the upcoming episodes screen, and the next re-airing of the same episode later this afternoon said "Channel Record - Currently Recorded"

Also, I wanted to clarify something in the original report. On the 5'th step of how to reproduce, "Previously Recorded" could actually read "Currently Recorded", as that's what it showed when I tested another scenario to help produce the logs (however in the new case, it was a channel specific recording rule, not an any channel rule).

comment:4 Changed 3 years ago by kenni

  • Status changed from infoneeded_new to assigned

comment:5 follow-up: Changed 3 years ago by gigem

  • Status changed from assigned to infoneeded

You now say the status for the future recording is Currently Recorded. That's very telling. The only way that should be able to happen is if the recording isn't deleted. Are you sure the recording is deleted?

comment:6 in reply to: ↑ 5 Changed 3 years ago by skd5aner <skd5aner@…>

Replying to gigem:

You now say the status for the future recording is Currently Recorded. That's very telling. The only way that should be able to happen is if the recording isn't deleted. Are you sure the recording is deleted?

Yes, I'm sure it's deleted, although I might have misread the last report when I said "currently recorded". After selecting delete, it goes into the delete list which I can see by changing the filter. Going in and checking the upcoming recordings screen on several other tests I've done still report re-airings as "Previously recorded"

Just tested again, I'm not sure why it said "Currently Recorded" on that last test... as I just went, and tested again and after deleting the exact same way, it said "previously recorded" on the next airings of the same episode. Please disregard that prior comment.

I believe what I stated in the original report was most likely correct ("previously recorded")

comment:7 Changed 3 years ago by gigem

  • Milestone changed from unknown to 0.24.1
  • Resolution set to Fixed
  • Status changed from infoneeded to closed

Fixed in SHA: 0cab1df4.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.