“Cannot record airing in the past”

I have 2 issues with the Plex DVR
1 random one is if I schedule a recording every 3rd or 4th recording once the show has finished I get an error saying “Cannot record airing in the past”

Secondly if I have remove commercial enabled the recording will run for a few seconds and then end. Copy to the library as normal but I will only have a few seconds recorded

I’ve removed the DVR from the server countless times and still no luck. I have 2 servers a qnap and a Nvidia shield and it’s the same on both not sure if a recent update has caused this because they were both working just fine last week

Did you ever figure out the DVR recording issue same thing has been happening to me and have yet to find a real solution.

I just got bit by this. Why a current recording was deemed to be in the past is beyond me.

What version of PMS do you have installed and on what OS?

Which Plex app are you initiating the recording from and what version is it?

PMS 1.17.0.1709 on WD PR4100

Recording scheduled a week ago, all eps new & old, via web ui on PR4100

There were three eps airing in a row today, first two recorded without issue. The third failed as you see.

I have encountered this again. One recording failed for some reason, causing it to be ‘stuck’ and then everything thereafter fails. The only way to fix the issue is to restart plex completeley.
001
This seems like something that should be easily detectable and not be an end all dvr showstopper. There is no logical reason why the recording should still be in progress an hour after it’s ended.

Just started getting this as well. I initially ignored it, but it’s happening to every recording.
I’m using PMS 4.12.2 running on Windows Server 2016.
Anyone had any luck getting it resolved?

I’m seeing this same issue. Has anyone else having this issue figured out how to get past it?

Reported multiple times, seemingly unacknowledged. No way to “fix” short of completely restarting plex. When it goes bad you better notice, because all recordings in progress will be fubar.

Thankfully it doesn’t happen to me very often any more.

Struck again by this error. I recorded 8 episodes in a row until the ninth spit out errors and says “cannot record airing in the past”. If I look at plex logs you just decided the stream ended and errored out. If you have problems recording more than eight hours straight then open a new freaking session and don’t just fail!!! Tuner sharing is cool and all but the utter lack of robustness and error recovery is disgusting.

Jan 20, 2020 13:00:01.798 [0x7fdb650d2700] ERROR - [Transcoder] http://127.0.0.1:32400/livetv/sessions/41184f11-0fd9-42a1-8796-07f42ae3b441/4f8bbb6c-b6c9-4d62-86e7-7b909344b13d/index.m3u8?offset=25197.794350&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx: End of file
Jan 20, 2020 13:00:01.800 [0x7fdb6d2c9700] DEBUG - Jobs: '/mnt/HD/HD_a2/Nas_Prog/plexmediaserver/binaries/Plex Transcoder' exit code for process 25253 is 1 (failure)
Jan 20, 2020 13:00:01.800 [0x7fdb2111f700] DEBUG - Streaming Resource: Terminated session 0x7fdade96d720:4f8bbb6c-b6c9-4d62-86e7-7b909344b13d with reason Recording failed. Please check your tuner or antenna.
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] DEBUG - TranscodeSession: session failed while waiting for duration
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] ERROR - Failed to start session.
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] ERROR - Recorder: Unable to create transcode session or session failed to start.
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] DEBUG - Killing job.
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] DEBUG - Signalling job ID 25253 with 9
Jan 20, 2020 13:00:01.800 [0x7fdaeb735700] ERROR - Recorder: Error 12 (There was a transcoder error) starting the record, shutting things down.
Jan 20, 2020 13:00:01.801 [0x7fdaeb735700] DEBUG - MediaRecorderVirtual: setting stop time to 2020-01-20 13:00:01
Jan 20, 2020 13:00:01.801 [0x7fdaeb735700] DEBUG - Grabber: Operation for 'Star Trek: Deep Space Nine - E9 - The Passenger' on channel 888 completed with status error (There was a transcoder error)

There is nothing wrong with my tuner. You all need to learn what failure recovery is.

Another silent recording failure. I look at my schedule and see that the episode going on right now is not recording. I check the guide and it definitely should be recording.

Plex cannot handle multiple back to back to back recordings on the same channel. Two times today the eighth or ninth hour recording in a row failed. So I get seven/eight episodes, then failure. Restart plex, seven/eight episodes in a row then failure again.

I have logs saved moments after both failures, but does anyone at plex even read these bug reports? The simple matter is this use case is broke, period.

FWIW, I got this error too. It only happened on a recording where I had unchecked “Allow partial airings” and a back-to-back recording was scheduled.

I checked “Allow partial airings” and the problem went away, for me.

1 Like

you best be careful with that setting however. After someone else made a detailed report of what was up with all of their incomplete recordings I went back and noticed I have lots that were partial as well. It’s almost like at that point plex just threw away completeness entirely and I had lots of episodes that were anywhere from one minute to five minutes short or skewed/off entirely, based on creation time stamps. All affected recordings had ‘allow partial recordings’ enabled, from back when that was forced on globally and I hadn’t manually unchecked it on those shows.

This is that thread, unacknowledged by plex.

It might “hide” the error I’m complaining about…and then set up complete disappointment when you eventually notice there’s an incomplete episode in your library that probably could have been re-recorded in the meantime and that now won’t air again with your luck.

if any/all of your shows start or end early, then you could have potential problems with overlap and insufficent tuners.

for example, if you have 4 tuners, and 3 shows recording +1 before/after, this will only leave ONE tuner available to start early/on time (the other 3 are still recording 1 minute after).

and if ‘allow partial’ is disabled, then plex will not be able to start after the +1 minute extra start time.

so the solution is to enable ‘allow partial’ or remove all +1 before/after. (or add more tuners)

I’ve never actually had any problems with partial recordings that weren’t my own fault (server upgrade, reboot, offline for backup, etc.)

But it would appear that setting NO partial recordings fights with overlapped back-to-back recordings. And I predict that plex won’t really try to fix it, so you have to choose your preferred failure, I guess.

I have fifteen available tuners and never get anywhere that close to the limits. This has nothing to do with lack of resources.

In some recent version of plex they now “tuner share” with overlapped recordings. It does not require “two tuners for the same channel” now if you have extra time enabled. There is one feeder opened and multiple consumers of it. I can see plex open a single stream on a single tuner and use it for overlapped recordings, leaving it open for hours. The problem is after some indeterminate amount of time that “feeder” runs out of data and causes a failure. When that happens you miss a recording.

Tuner sharing is great. Lack of any recovery whatsoever when that pipeline encounters errors is bad.

1 Like

Ok. I was going by my experience with 4 tuners.

perhaps it is a hdhr issue if the ‘feeder’ stream terminates or otherwise fails?

I wonder if there is a total time restriction on a HDHR that plex is unaware of and/or failing to take into account.

I would take the time to experiment with a direct hdhr stream (outside of plex) but I don’t want to screw up any of existing show recordings.

It could be anything from using 32bit numbers when should have used 64bit to interference by some periodic plex operation. I used to notice this more often in the middle of the night during “periodic maintenance / guide refresh” When it’s happened in the middle of the day it seemed as well a guide refresh was going on. Could be simple red herrings, hard to tell though with how noisy the logs can get.

As for HDHR being the culprit, while this is possible, I see no errors on the hdhr side and the recording-before-failure successfully contains N+1 minutes, it’s the new recording that fails after briefly starting due to plex’s feeder saying “error no data” at which point plex just gives up. It seems counter intuitive that recording B could get “no data” errors when recording A is still in progress, but that’s what happens.

If I have a day when there’s no recordings set up for minimum eight hours I’ll set up a long running stream to /dev/null to test out if it’s an hdhr limitation. If it is is seems easy enough to only park on one channel for maximum amount of time, before firing up a new feeder.