DVR fails after update

Plex Media Server
,
1

Server Version#:1.41.6.9685
Player Version#:1.108.1.307-dd5b87aa
Plex Media Server Logs_2025-05-04_11-35-16.zip (4.1 MB)

I’ve been running on Server version 1.29.0.620 for a long time because every time I update it breaks my DVR. Since I paid for a lifetime plex pass specifically for the DVR function, I don’t think it’s unreasonable to ask for some real help.

Recently the mobile apps stopped working because of the server version I was using, so I attempted an update again. After updating I set up some simple 30 minute shows to record and once again 5 of 8 recordings failed. This is ridiculous. I can’t use the one feature that I specifically paid to use unless I use an outdated server version. I’m at my wit’s end here.

2

After a few days I’m noticing a pattern. If a single show is set to record it usually works without a problem. If two shows are set to record back to back the second recording almost always fails. Here’s the latest log.
Plex Media Server Logs_2025-05-06_11-18-49.zip (5.3 MB)

3

I’m on Linux, not Win, but this was a problem I had a few years ago (back to back recordings cause the second recording to fail.) The resolution was to delete codecs, after which Plex will redownload codecs as needed.

Under Linux the process was to stop the Plex server process, go to the “codecs” directory, delete everything except the “.device_id” file, and then start the Plex server process. Here is a link to someone describing that process on Win.

4

Thank you, I will try this and report on results.

5

Well, it appears that wasn’t my problem. Second recording of a back to back only recorded three minutes. First recording worked fine.
Again, here’s the latest log.
Plex Media Server Logs_2025-05-07_11-33-33.zip (4.9 MB)

6

Am I right that both of these back-to-back recordings on the same channel, and if so do you have “Minutes before Start” and/or “Minutes after End” set on the recordings? I think what I am seeing in the logs is that there is some overlap of the two recordings between 5/7 11:29AM until 11:32 am on the same channel. The second recording starts successfully, but then fails at 11:32am very close to when the first recording successfully completes.

If this is the case then would you try recording consecutive shows without any minutes before start and/or minutes after end just to see if it works? You could also try back-to-back recordings, but where the two recordings are on different channels. Certainly Plex should be able to handle this, so if either works then this strongly suggests a bug in the implementation of extra time.

7

I can certainly try that, but as I’ve previously stated it worked fine on server version 1.29.0.620. Any version I have tried after that one has had problems. It’s very frustrating.

8

So far none of the suggestions I’ve received, while appreciated, have corrected the problem. What I’m afraid of but don’t want to do is to completely wipe out my installation and start from scratch. I’m really hoping that someone can pinpoint the problem so I can fix it.
Here’s the latest log:
Plex Media Server Logs_2025-05-09_11-03-28.zip (5.2 MB)

9

this feels like it’s getting worse. Now even isolated recordings are a few minutes shorter than they should be. This is driving me crazy. I’ve had this issue for a long time and posted here several times. It’s very frustrating.

10

Latest log:
Plex Media Server Logs_2025-05-10_10-55-42.zip (5.1 MB)

11

I know my previous suggestions haven’t helped, and that this worked for you on previous versions of Plex Server, but since no one else has responded I took a look at your latest logs. I noted again that the failed recording happens after a cleanup that happens after a recording has completed. The cleanup:

May 09, 2025 19:01:07.784 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\2fbecbee52624056254253b666e7fe49133a2d49-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:07.990 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\5832b09c8975fa73d9d6d89bfc033e256ec1281f-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:08.196 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\5aa8d3033e4ae534bf9505c88f3b7608f56d67f7-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:08.400 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\5cbfe766735399cba26ed395023951458495c7ba-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:08.608 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c.
May 09, 2025 19:01:08.815 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\8826fe444193ecdc0a420dea190ec489abd99aef-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:09.020 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\cad263ebe3750e74ba0959eb8b4ac8abad28051d-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:09.242 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\.grab\e9f250a0600753ea3b943114241188a03deab9ab-88d24317a31be0ffff5f4096e0d9ab12274a1f3c".
May 09, 2025 19:01:09.447 [6220] DEBUG - Grabber: Cleaned up 10 decrepit directories in 0.0 sec.

Then immediately the failure in your transcoder:

May 09, 2025 19:01:09.448 [6220] DEBUG - Activity: registered new activity c27a24ca-b6c1-4fd8-af2c-fc35ade28dfb - "Processing subscriptions"
May 09, 2025 19:01:09.448 [6220] DEBUG - Subscription: Scheduling subscriptions.
May 09, 2025 19:01:09.449 [9504] ERROR - [Req#fee87/Transcode/94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c] av_interleaved_write_frame(): Invalid argument
May 09, 2025 19:01:09.450 [9504] ERROR - [Req#fee88/Transcode/bc8b3d77-3fee-4e23-920e-d3a97bf483d7/5ec29bef-981d-4844-8cd1-cf866e8c01cc] S:\TV Shows\Wheel of Fortune (1975)\Season 42\Wheel of Fortune (1975) - S42E175 - The Beach.ts: Invalid argument
May 09, 2025 19:01:09.450 [2244] ERROR - [Req#fee8a/Transcode/94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c] Error writing trailer of S:\TV Shows\.grab\ba2bddca03ebba6392d15e805629977d06d0889c-88d24317a31be0ffff5f4096e0d9ab12274a1f3c\Penn & Teller Fool Us (2011) - S10E01 - Who's Your Daddy.ts: Invalid argument
May 09, 2025 19:01:09.451 [9504] ERROR - [Req#fee8d/Transcode/94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c] Error closing file S:\TV Shows\.grab\ba2bddca03ebba6392d15e805629977d06d0889c-88d24317a31be0ffff5f4096e0d9ab12274a1f3c\Penn & Teller Fool Us (2011) - S10E01 - Who's Your Daddy.ts: Invalid argument
May 09, 2025 19:01:09.455 [14660] DEBUG - Jobs: 'C:\Program Files\Plex\Plex Media Server\Plex Transcoder.exe' exit code for process 9940 is 1 (failure)

Note the transcode identifier in the failure, “94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c”:

May 09, 2025 19:01:09.449 [9504] ERROR - [Req#fee87/Transcode/94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c] av_interleaved_write_frame(): Invalid argument

And then look back at the directories cleaned up and note that the identifier for the transcoder is one of the directories that was cleaned up:

May 09, 2025 19:01:08.608 [6220] DEBUG - Grabber: Deleting "S:\TV Shows\94b74015-42e1-4680-95f2-d453824e4dd8/864ff50c-bc57-4a14-9cf5-68f2e9d3e53c.

In Plex Server Settings → Transcoder, make sure the “Show Advanced” button has been clicked, and then do you have anything in the “Transcoder temporary directory” field?

If you do have it set, what is it set to? Is it set to a local drive, or a network drive? Is it set to “S:\TV Shows”? Two thoughts on the transcoder temp directory with Plex - it should not be a network drive per this Plex document, and it should also not be in “within any of the libraries media path locations” like “S:\TV Shows”. It may be getting caught in post recording cleanups - possibly new cleanups introduced in newer Plex Server releases.

I hope this helps. Plex is closed source and Plex Server logging changes over time, so people that are just users like I am can’t see the code to see what is going on under the hood.

12

The transcoder temp directory is a local drive, not any of the libraries. It’s a directory only used for that purpose.

I understand that other users are limited in what they can help with, that’s why I’m frustrated that given the number of times I’ve posted about this problem I’ve never had an actual Plex employee look at. Especially since it’s having to do with a feature that is only available to paying users.

13

This is a tough one, and I do now see that your transcode directory is at C:\ptemp\Transcode.

I feel like I’m shooting in the dark because the primary symptom in your logs is that there are a LOT of transcoder errors, but nothing OS level specific. For example, the “av_interleaved_write_frame(): Invalid argument” error seems to be the first actual error Plex Server returns when your recordings fail, but this is an error from the FFMPEG process that Plex is passing back and we can’t see the actual arguments being passed or the state of your filesystem at the time.

Are you running Malwarebytes Premium on your Plex Server? I haven’t seen it for a while, but at one time it was causing a lot of people problems because it can interfere with the Plex transcoder. IIRC the fix was to put exclusions into Malwarebytes for the Plex processes.

Very frequent library scans can also cause transcoder problems, and I do see a lot of repeated scans in your logs. Under Settings → Library, again make sure “Show Advanced” is clicked, do you have “Scan my library periodically” checked, and if so how often do you have the library scan interval set? Try turning off “Scan my library periodically” or set it to something fairly low, like every 12 hours to see if it helps.

14

I also had a look at the most recent logs. What stuck out to me was a failure in Plex’s post-processing. In one specific example, during credits detection:

May 09, 2025 06:32:19.806 [8256] ERROR - [Grabber/6ae8833c788ba29b2ed67c0e7b8144250b9845b2/CreditsDetectionManager] PeekNamedPipe failed: 0x6d
May 09, 2025 06:32:19.806 [8256] ERROR - [Grabber/6ae8833c788ba29b2ed67c0e7b8144250b9845b2/CreditsDetectionManager] BufferingLineReader: failed to read line (error: -1)
May 09, 2025 06:32:19.809 [8016] DEBUG - Jobs: 'C:\Program Files\Plex\Plex Media Server\Plex Media Scanner.exe' exit code for process 1148 is 0 (success)
May 09, 2025 06:32:19.809 [8256] DEBUG - [Grabber/6ae8833c788ba29b2ed67c0e7b8144250b9845b2/CreditsDetectionManager] Activity: updated activity 6815b70d-e64f-4505-8998-333dc922a3bb - completed 75.0% - Detecting Credits
May 09, 2025 06:32:19.809 [8256] DEBUG - [Grabber/6ae8833c788ba29b2ed67c0e7b8144250b9845b2/CreditsDetectionManager] Completed credits detection for item 57244 (success: 0, failures: 1)
May 09, 2025 06:32:19.809 [8256] DEBUG - [Grabber/6ae8833c788ba29b2ed67c0e7b8144250b9845b2/CreditsDetectionManager] Activity: Ended activity 6815b70d-e64f-4505-8998-333dc922a3bb.

I’d be curious to see if disabling all post-processing (ad detection, intro detection, credits detection, voice activity detection) for the destination library changed the behavior. Then they could be added back to see which one triggers the behavior.

Another option would be to leave them enabled, but configure them so that they only run as scheduled tasks (and not when media is added). That would be system-wide though so might not be desirable.

15

No Malwarebytes, not really running any other software at all. I’ll try the suggestions you have and see if it makes a difference.

16

Nothing seems to have changed, still having the same problems. Standalone half hour programs record OK, a second half hour program in a row or a 1 hour program fail at some point.
Here’s another log:
Plex Media Server Logs_2025-05-13_11-06-14.zip (5.4 MB)

17

At this point I’m looking for anything odd, and I noticed that Plex is trying to clean up the same decrepit .grab directories over and over again, and that the number of decrepit .grab directories is growing over time. This is for you the directories under S:\TV Shows\.grab.

What is the S: drive? Is it a local internal drive, USB drive, network drive? If you shut down your Plex Server instance and go to S:\TV Shows\.grab, then are there any subdirectories? (Typically this .grab directory will be empty if the Plex Server isn’t doing anything or is shut down.) What are the permissions for the S: drive, and specifically the .grab directory? This is where it gets tricky for me because I’m not on Windows…

I can’t specifically say that this is related to your recording issue, but the .grab directory is where Plex puts files for recordings in progress. When the recording is done it moves from .grab to the final recording destination. With @pshanew also seeing issues with postprocessing, I’m suspicious of something with the S: drive. Right now I can’t explain why it would have worked with older versions of the Plex Server and not the new version.

18

the S:\ drive is a network drive on a NAS device. The Plex server has full rights to that drive. When I shut down the Plex server instance and look at the .grab folder there are several subdirectories there. I’m going to empty it and test to see if that makes a difference.

19

Initial testing after emptying the .grab folder seems promising, I’ll keep an eye on it for the next couple of days and see what happens.

1 Like
20

So, after clearing out that .grab folder I’ve seen improvements, but still some recordings are coming up short or just failing, but most are doing OK. So better, but still not great.
Here’s the latest log:
Plex Media Server Logs_2025-05-15_10-51-40.zip (5.3 MB)