I’m having a recurring issue that the Plex DVR only partially records a scheduled recording.
For example, last night a recording of the movie Panic Room was scheduled to run from 03:30 to 05:05. Yet, when I checked the recording this morning, the file starts in the middle of the movie and only runs for 1 hour and 22 seconds. Another movie, Crimson Tide, was also only recorded for 26:06 minutes.
How can I find out what’s happening here? Where to I have to look in the log files?
I’m still having been able to address this issue.
For example, I scheduled the recording of the movie “If Beale Street Could Talk”:
With a couple of minutes for pre- and after-run, the recording was supposed to run from 23:57 to 02:04:
Oct 06, 2025 02:13:16.784 [124144060033848] DEBUG - [Grabber/4223f54bd5b83b60fffc5b51573682b10b77ac6f] DVR:NewSchedule: Between 2025-10-06 23:57:00 and 2025-10-07 02:05:00 on channel 6228f7f2364e02fa5ec8e51c-5fc705f4dd53a6002d8f9150: 'If Beale Street Could Talk (2018)'
Oct 06, 2025 02:13:16.785 [124144060033848] DEBUG - [Grabber/4223f54bd5b83b60fffc5b51573682b10b77ac6f/770b9ac82161f15d48c582ade4e4a9c2bf2a4e66] Scheduling 'If Beale Street Could Talk (2018)' for timed grab at 2025-10-06 23:57:00 (in 78224 seconds)
But, according to the logs, the final recording was stopped by Plex over an hour earlier at 1:00 sharp. See the attached log file for the time of the recording.
Is there maybe some kind of scheduled task that interrupts the recording?
Plex log.txt (4.9 MB)
What model tuner are you using? Plex thinks it’s an HDHomeRun, but the logs make it clear that it isn’t:
Oct 07, 2025 01:00:43.274 [124144042224440] DEBUG - [Grabber/770b9ac82161f15d48c582ade4e4a9c2bf2a4e66/HCl#71be] HTTP requesting GET http://openmediavault.local:9191/hdhr/discover.json
Oct 07, 2025 01:00:43.290 [124144042224440] DEBUG - [Grabber/770b9ac82161f15d48c582ade4e4a9c2bf2a4e66/HCl#71bf] HTTP requesting GET http://openmediavault.local:9191/hdhr/lineup_status.json
Oct 07, 2025 01:00:44.314 [124144044333880] DEBUG - [Grabber/770b9ac82161f15d48c582ade4e4a9c2bf2a4e66] Grabber: Freed a tuner on device://tv.plex.grabbers.hdhomerun/12345678 (now 1 available)
HDHomeRun tuners don’t use port 9191 nor do any have an ID of ‘12345678’.
Are you using a proxy such as XteVe or Threadfin (or TVHeadend)? Something else?
I’m actually using Dispatcharr. Similar to how xTeVe or Threadfin, it acts as a virtual HDHomeRun tuner.
I have the exact same issue on some tv channels.
It all got really bad when i added Dispatcharr to the whole thing.
But ever since, i have got the same issue, even when i use xteve as tuner proxy again.
So I think this must be a coincidence?
I have tried several things to troubleshoot:
If I can provide any useful information, just tell me what to provide.
This is really kind of frustrating.
So, a recording last night again didn’t run as scheduled.
The DVR job for the “Arctic” was scheduled to run from 3:30 to 5:00.
However, the final recording only lasted for 13 minutes:
The log shows that the recording stopped at 03:42:
Oct 11, 2025 03:42:20.706 [132781339953976] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 3848 is 0 (success)
Oct 11, 2025 03:42:20.706 [132781145656120] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Grabber: Freed a tuner on device://tv.plex.grabbers.hdhomerun/12345678 (now 1 available)
Oct 11, 2025 03:42:20.706 [132781149059896] DEBUG - Killing job.
Oct 11, 2025 03:42:20.706 [132781149059896] DEBUG - Signalling job ID 3848 with 9
Oct 11, 2025 03:42:20.706 [132781149059896] DEBUG - Job was already killed, not killing again.
Oct 11, 2025 03:42:20.706 [132781149059896] DEBUG - Stopping transcode session 0abdccbc-15eb-4f41-8701-8c390ae25525
Oct 11, 2025 03:42:20.706 [132781094955832] DEBUG - Streaming Resource: Terminated session 0x78c38c712948:0abdccbc-15eb-4f41-8701-8c390ae25525 with reason Recording failed. Please check your tuner or antenna.
Oct 11, 2025 03:42:20.706 [132781094955832] DEBUG - Cleaning directory for session 0abdccbc-15eb-4f41-8701-8c390ae25525 (/transcode/Transcode/Sessions/plex-transcode-0abdccbc-15eb-4f41-8701-8c390ae25525)
Oct 11, 2025 03:42:20.715 [132781149059896] DEBUG - Streaming Resource: Removing session 0x78c38c712948:0abdccbc-15eb-4f41-8701-8c390ae25525
Oct 11, 2025 03:42:20.715 [132781149059896] DEBUG - Whacked session 0abdccbc-15eb-4f41-8701-8c390ae25525, 1 remaining.
Oct 11, 2025 03:42:21.634 [132781145656120] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7/HCl#73ad] HTTP requesting GET http://openmediavault.local:9191/hdhr/discover.json
Oct 11, 2025 03:42:21.657 [132781314845496] DEBUG - [HttpClient/HCl#73ad] HTTP/1.1 (0.0s) 200 response from GET http://openmediavault.local:9191/hdhr/discover.json (reused)
Oct 11, 2025 03:42:21.657 [132781145656120] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7/HCl#73ae] HTTP requesting GET http://openmediavault.local:9191/hdhr/lineup_status.json
Oct 11, 2025 03:42:21.660 [132781314845496] DEBUG - [HttpClient/HCl#73ae] HTTP/1.1 (0.0s) 200 response from GET http://openmediavault.local:9191/hdhr/lineup_status.json (reused)
Oct 11, 2025 03:42:22.187 [132781143546680] WARN - [Req#48eb2/Live/0abdccbc-15eb-4f41-8701-8c390ae25525/bcc2ab90-0204-4097-b31d-eddc5c02d506] buildLiveM3U8: no instance available
Oct 11, 2025 03:42:22.188 [132781139798840] WARN - [Req#48ebb/Live/0abdccbc-15eb-4f41-8701-8c390ae25525/bcc2ab90-0204-4097-b31d-eddc5c02d506] buildLiveM3U8: no instance available
Oct 11, 2025 03:42:22.190 [132781143546680] WARN - [Req#48ec3/Live/0abdccbc-15eb-4f41-8701-8c390ae25525/bcc2ab90-0204-4097-b31d-eddc5c02d506] buildLiveM3U8: no instance available
Oct 11, 2025 03:42:22.193 [132781339953976] DEBUG - Jobs: '/usr/lib/plexmediaserver/Plex Transcoder' exit code for process 3850 is 0 (success)
Oct 11, 2025 03:42:22.193 [132781155388216] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Recorder: No more consumers, stopping.
Oct 11, 2025 03:42:22.193 [132781155388216] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Recorder: Asked to stop recording 'Arctic (2018)' on channel 6228f7f2364e02fa5ec8e51c-5fc705f9c8d56d002e06f849.
Oct 11, 2025 03:42:22.193 [132781155388216] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Recorder: Stopping transcode session.
Oct 11, 2025 03:42:22.193 [132781155388216] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Job was already killed, not killing again.
Oct 11, 2025 03:42:22.193 [132781155388216] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Job was already killed, not killing again.
Oct 11, 2025 03:42:22.193 [132781094955832] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Recording for 'Arctic (2018)' on channel 6228f7f2364e02fa5ec8e51c-5fc705f9c8d56d002e06f849 stopped with status complete.
Oct 11, 2025 03:42:22.193 [132781094955832] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Using recording status.
Oct 11, 2025 03:42:22.194 [132781094955832] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Activity: updated activity e4983074-a8bf-4b5f-a513-78efc307becf - completed 100.0% - Recording
Oct 11, 2025 03:42:22.194 [132781094955832] DEBUG - [Grabber/942ace7faecc2ceded1a83cf10a016c8b76235b7] Activity: updated activity e4983074-a8bf-4b5f-a513-78efc307becf - completed 100.0% - Recording
Does the log provide any more information on why the recording stopped?
Plex Media Server.log (1.2 MB)
Any again, a scheduled recording of “Blues Brothers” only ran for 6 minutes:
Could someone maybe have a look at the log file for this recording? Is there something in there that explains, why the recording stopped early yet again?
Plex Media Server.log (725.5 KB)
I’ve done two other recordings on the same day, that worked just fine.
Can you share your DVR device settings? Go to your Settings -> [Select Server] -> Live TV & DVR and select the cog next to your guide source:
It should look something like this:
These problems are almost always a problem with the stream stability from the tuner; for real tuners this is usually the result of poor signal quality. For IPTV sources it’s usually a result of unstable streams.
Given that you’re using a virtual tuner, there may be some configure you can do on that side to configure a buffer to stabilize the stream. xTeVe and Threadfin, for example, support configuring buffering.
I’ve tested the streams by letting the live tv run for a couple of hours and never had any issues with streams stopping or buffering, though.
The log doesn’t provide any clues? From what I can tell, the recording just stops and Plex things the recording is “complete”. Should there be an error message in the log when a stream is unexpectedly stopped?
Yes i observe the exact same thing.
Last time I had the issues, I deployed seconds Plex Container just for TV.
I have done this again today and test how the DVR recordings behave on the newly deployed instance.
What does it say in media info on a failed recording?
Mine look like:
Media Grab Begins At 1760630400
Media Grab Device device://tv.plex.grabbers.hdhomerun/2023-10-E4NT-TWVN27:24
Media Grab Partial Recording 1
Media Grab Partial Recording Reason Aufnahme wurde abgebrochen
Media Grab Status complete
Is this also a virtual tuner, or a physical HDHomeRun device? I’ve never seen an HDHomeRun device ID in that format (they’re usually 8 character alphanumeric).
Yes,
this is xteve, its connecting to an enigma2 DVB-C receiver and it’s been working for literally ages.
The recordings I scheduled with the new Plex instance have all finished as expected so far.
Strange. Did you make any chance when deploying the second instance?
Hi,
I did not change anything compared to my main Plex container.
Funnily enough the recordings on my main Plex container got better.
I am still trying to understand whats happening, but what I can say for sure is, that with a fresh Plex instance, connected to Dispatcharr, the recordings do not cancel early with ffmpeg as Streaming Profile set in Dispatcharr. They seem to tend to fail with Proxy set as Streaming Profile.
I will try some more recodings playing with different profiles and report back, when I finished.
Thanks @Spacknudel69. Would be great if you can keep us posted. I’ve still not managed to identify any pattern that might explain why a particular recording failed. Neither the Plex nor Dispatcharr log files haven been helpful so far.
Maybe a change in audio codec when a movie or show goes to a commercial break?
I have assumed something like Audio Track or any other changes because of a commercial break. But i have had the most problems recording a specific TV show.
It sometimes failed after 3, sometimes after like 9 and sometimes after like 30 minutes.
There are no commercial breaks during the first 40 minutes of that show, that is runnig for 80 minutes normally.
Also i have recorded the same show from a IPTV source (no changes in codecs), as well as local DVB-C and they both behaved the same way, what made me assume this problem is related to Plex.
As this show is a very good indicator, as I said I will try and find a pattern.
After some days of testing I can now confirm the “old” Plex instance is failing on nearly every single scheduled recording.
The newly deployed instance is recording everything I schedule successfully.
Both containers are deployed with the exact same parameters, and both are using the same Dispatcharr Instance as tuner.
The only thing that is different, is the purged app data folder in the new instance.
As I mentioned, I had that exact problem before. I assume that happens as soon as you change something with your DVR / tuner settings in Plex.
Even deleting DVR completely, and readding it will do you nothing but trouble, as soon as the timer you’re connecting to is not the exact same as before.
That’s why I dediced to move all DVR related stuff to a dedicated instance, so I can purge the the database if I should need it.
To avoid those problems when you need to change settings like URL of tuner or XMLTV you will need to change the parameters in the sqlite database directly. I did that yesterday and this won’t render your DVR useless.
I know this is not “the solution”, but it’s the only way to get out of this issues for me at the moment.
Hope this helps!
Thanks for your hard work trying to narrow down the possible cause for this issue. Is there a way to provide feedback to Plex about your findings?
If I understand you correctly, you’re now running two containers at the same time. One is basically your main Plex database with all you media content. And the second one is exclusively used for the DVR functionality. Do you than feed the recording made with the DVR-container into the regular Plex-instance to access the recordings?
I don’t quite understand what you’re referring to by “timer you’re connecting to”. Do you mean the scheduled recording of a particular program?
Yes, that’s exactly how it is set up.
I just added the same libraries to the DVR container that I have on my main Plex container but put the recordings in a dedicated path for each library. This way the DVR container doesn’t scan files that it shouldn’t care about, and the recordings are imported to the main Plex containers libraries.
The downside of this is that the main container doesn’t know the recordings are DVR recordings. But that actually only matters if you use comskip and set it to mark to skip instead of deleting the commercials. At least it does for me… 
And I meant tuner, not timer. Sorry.
