Multiple recordings of the same show

[Handy.Man]

This afternoon while watching a recording, it started stuttering !

I looked at the Device status and there was 10+ recording of the same show. Way too many for the server.

I tried to cancel the recording with the client, but the status didn't show any change

I tried to cancel the recordings on the server, but NextPVR was unresponsive.

I stop the service, restarted the service and again I had 15 or so recording of the same show.
I kill all compskip processes and was able to cancel the recordings with the client. Some showed "...alternated airings...:
Maybe I should untick the "Look for alternate airings on unresolved conflict" ?

The only thing that changed on the server in the last days was the installation of Windows Update yesterday followed by a reboot.
KB2999226 Update for Universal C Runtime in Windows
KB3080079 Update to add RDS support for TLS 1.1 and TLS 1.2

[johnsonx42]

yes, a bug has been discovered with the "alternate airing on conflict" code. the recordings it creates are not detected properly by the regular scheduling code, at least in some cases, so the scheduler keeps trying to schedule them, keeps making a conflict, which then fires the "alternate airing on conflict" code again which schedules another replacement recording, and so on. you'll get as many dupes as the number of times the epg updates between the time the episode appears in your data and the time that it actually airs.

I thought it had something to do with dots in the unique_id's of the shows in the guide data, which you have as well, and some inconsistency with code that's supposed to disregard the dots, but the 2nd user who reported this issue says he's on schedules direct which doesn't have the dots. I haven't had time to do any further testing myself, but I have raised the issue as a bug to be tested and resolved for 3.6.x. (i hassle sub with my little to-do list, he just loves it)

It may be best for now to turn off that feature and resolve conflicts by hand until there is a fix. There is a new feature where if you select "Find All" on an episode listed in the conflicts screen, it will show you only additional showings of just that specific episode; if you schedule one of those with a quick record and then let the epg update, the conflict will go away.

[Handy.Man]

Thanks for the reply, I found http://forums.nextpvr.com/showthread.php...Recordings which describe the problem.

So I will untick the option and restart the server.

[Handy.Man]

Well it happened again with the same show :eek:
It is a manual recording of the second airing of last evening live show.

The first airing on Fridays at 21h00 is allways in conflict with 3 show that start at 22h00. So I cancel my show, another show at 22h00, then I scheduled a normal recording at 21h00 for my show.
I have been doing this for month without issue until i upgraded to 3.5.7. It seems the recurring at 21h00 triggered the alternate airing logic (maybe the harm was done 2 weeks ago before the restart)


Last friday afternoon, I unticked the "Look for alternate..." and restarted the Recording service, maybe I should have stop it and start it ?

In the recording settings I have:
Match Exact Title
Avoid duplicate recording is ticked
Look for alternate airings is not ticked

So in order to "clean up" a bit, I stop/start Recording service, I deleted the recurring recording, and reprogrammed it.
Here are the log, db3 and xml files

[FirstTeamOPS]

yes, a bug has been discovered with the "alternate airing on conflict" code. the recordings it creates are not detected properly by the regular scheduling code, at least in some cases, so the scheduler keeps trying to schedule them, keeps making a conflict, which then fires the "alternate airing on conflict" code again which schedules another replacement recording, and so on. you'll get as many dupes as the number of times the epg updates between the time the episode appears in your data and the time that it actually airs.

I thought it had something to do with dots in the unique_id's of the shows in the guide data, which you have as well, and some inconsistency with code that's supposed to disregard the dots, but the 2nd user who reported this issue says he's on schedules direct which doesn't have the dots. I haven't had time to do any further testing myself, but I have raised the issue as a bug to be tested and resolved for 3.6.x. (i hassle sub with my little to-do list, he just loves it)

It may be best for now to turn off that feature and resolve conflicts by hand until there is a fix. There is a new feature where if you select "Find All" on an episode listed in the conflicts screen, it will show you only additional showings of just that specific episode; if you schedule one of those with a quick record and then let the epg update, the conflict will go away.

Reading into this... could this bug happen with new recordings too? I have a issue where new episodes are not being recorded. These include: "Big Bang Theory" which I marked manually to record, "Scorpion" Monday (tonight) night, "NCIS" Tuesday night are examples. I tried multiple 'update EPG' and 'empty EPG' tonight in an attempt to refresh the data.
These are all set to record new episodes on the specified channel. I see what the logs say but figured let you guys look into it. Also attached a NEWA screenshot showing Scorpion is new. I am on Schedules Direct.
I added a new tuner so there was a massive amount of screwing around going on last week to get it setup correctly so there's probably a chance something is corrupted in the db too.

[mvallevand]

When you delete a future pending recording they won't be re-recorded as a recurring recording. That is what you did with Scorpion, NCIS and TBBT

Martin

[FirstTeamOPS]

Got it, thanks. Probably happened trying to set them up under the new channel names.