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

[skd5aner <skd5aner@…>]

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!

[Raymond Wagner]

attaching as a file, as the text says to

[gigem]

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

[skd5aner <skd5aner@…>]

Frontend Log

[skd5aner <skd5aner@…>]

Backend Log (-v network)

[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).

[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?

[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")

[gigem]

Fixed in SHA: 0cab1df4.