Opened 13 years ago

Closed 13 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 Raymond Wagner)

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 Raymond Wagner 13 years ago.
attaching as a file, as the text says to
mythfrontend-deleteresched.log (26.3 KB) - added by skd5aner <skd5aner@…> 13 years ago.
Frontend Log
mythbackend-deleteresched.log (58.1 KB) - added by skd5aner <skd5aner@…> 13 years ago.
Backend Log (-v network)

Download all attachments as: .zip

Change History (10)

comment:1 Changed 13 years ago by Raymond Wagner

Description: modified (diff)

Changed 13 years ago by Raymond Wagner

Attachment: version_info added

attaching as a file, as the text says to

comment:2 Changed 13 years ago by gigem

Status: newinfoneeded_new

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

Changed 13 years ago by skd5aner <skd5aner@…>

Frontend Log

Changed 13 years ago by skd5aner <skd5aner@…>

Backend Log (-v network)

comment:3 Changed 13 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 13 years ago by Kenni Lund [kenni a kelu dot dk]

Status: infoneeded_newassigned

comment:5 Changed 13 years ago by gigem

Status: assignedinfoneeded

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 13 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 13 years ago by gigem

Milestone: unknown0.24.1
Resolution: Fixed
Status: infoneededclosed

Fixed in SHA: 0cab1df4.

Note: See TracTickets for help on using tickets.