Since 1.7, I and many others have found DVR recording to be unreliable, occasionally (or frequently) reaching “100% complete” on a recording but then getting stuck, displaying a red “recording” circle in the Recording Schedule rather than a white “play” triangle, and never adding the recording to the library. Instead, a corrupt file remains in the .grab folder.
Given that the DVR feature is no longer in beta, and given the severity and widespread nature of this bug, I assume it’s a high priority to fix it. Can we get some sense of where that bug-fixing process is at (have Plex engineers reproduced it?), and whether this is likely to be fixed in the near future?
I, along with many others, have been posting about this bug with logs and screen snapshots in other threads. To my knowledge the bug has not even been acknowledged. It was disheartening to see that with the introduction of this widespread bug the DVR feature is supposedly production ready (no longer in beta). My solution was to go out and buy a Tivo Romeo OTA this weekend. I’m happy to report that the Tivo resolves most of the hastily released Plex DVR issue’s as it’s purpose built hardware. I don’t think a near bullet proof software DVR solution will ever be released on the Plex platform unfortunately. Seems like there are just too many variables in the mix and feels much more like an alpha feature at this point in time.
If you were following those threads, you’d notice I’ve been involved in several of them, have asked people for logs, and am working through it. Until there are some logs which show the root cause, it’s a little difficult to diagnose. Rest assured the issue is known, and is being looked into.
Dave, thanks! Yes, I’ve seen you’ve gotten lots of logs (including my own), but it hasn’t been clear whether they provided the details you need. Apparently not. If there’s a way for me to help—run a custom build with extra logging or something—I’m happy to do so. Best of luck!
@DaveBinM I’m on an nvidia sheild and experiencing this behavior as well. The recordings seem to move over if left for sufficient time, but take several hours to transcode. Also, my transcode temp directory has filled with >500GB of sessions, which are likely from liveTV since my media almost 100% direct streams.
Let me know if you would like log files, and which one. Happy to send them over if helpful.
@DaveBinM said:
If you were following those threads, you’d notice I’ve been involved in several of them, have asked people for logs, and am working through it. Until there are some logs which show the root cause, it’s a little difficult to diagnose. Rest assured the issue is known, and is being looked into.
@DaveBinM If there are testing steps we can help with let us know. Most of us can reproduce within 24hrs on a 1.7.x release. Sometimes longer on a newer one. Can’t believe they went out of beta with this one hanging out there. It seems to be the number one reported issue by far or must be very close to it.
Logs have been submitted left and right, but if you have other testing requests which might help isolate the issue…let us know. We’d all like to help where we can so we can get the Devs what they need to finally fix this.
@lorddoskias The problem is sometimes the logs don’t show when the issue started, just that the issue is ongoing. This item is still on my investigation list. If I can track down the problem I’ll let you know.
If you can post logs as soon as you notice a recording not complete successfully (the closer to the intended end time, the better), they’d be helpful. I’ve looked through most of the logs provided now, and unfortunately they’ve not got me any closer yet.
@DaveBinM Well thanks for your efforts. The last link that the OP provided (relinked below) seems to be the most active, I know the guys on there continuously test the new releases and try to provide logs. So that would be a good place to keep eyes peeled, but you probably already know that.
Too bad the logs are so limited. I may roll up to a bugged release in the next week or two just to generate a TON of logs for you if that would help. Some releases had very frequent reoccurrence, so it shouldn’t take much other then elbow grease.
Do you know how long it takes for the issue start to roll off the log? That would be useful to know. For instance, if it started 5 hours ago and I pull the log would it still show the start of the issue? If you don’t know no big deal, it would just be nice info.
@lorddoskias Thanks for the offer, but I think I’m on the right track now. As for how long until logs churn over, it depends on what you’re doing. Sometimes they last only an hour in the five logs, and sometimes it can be five hours.
I came across an interesting “new” feature of this DVR issue last night… Running PMS 1.8, I set number of back-to-back recording to take place overnight. I’ve fond this to be a great way to trigger this bug. As I predicted, I woke up this morning to a “recording schedule” full of shows @ 100%, in record limbo, and not in my library. I then went to PMS dropdown icon on my Mac server and noticed it listed a number of “active transcoding session” thought none should have been running at that time. I then canceled the sessions it listed via the PMS and instantly in the web viewer there was a flurry of activity alerts about the recordings in limbo. I then went to my library and there were the shows that were stuck. The only catch is that only and small handful of them were the full show. The majority were just 1 second long blips. However, they loaded all the metadata.
@lenhood said:
The problem is the transcoder, it just won’t stop at the end of a recording and the shows never gets moved to the
tv shows location…
Yes, I turned off the transcoder and in PMS 1.8 and the bug seems to have stopped. Now the issue is I have ton of interlaced video from my DVR that, instead of direct streaming to my player, now needs to be transcoded to remove those line.
I have the transcoder turned off always under plex DVR settings and have still had the issue. The 1.8 releases simply take longer usually (I’ve lasted 8 days) for reoccurrence.
Is there a different place to turn it off? If not, you may just be taking a while to have a reoccurrence.
@lorddoskias said:
I have the transcoder turned off always under plex DVR settings and have still had the issue. The 1.8 releases simply take longer usually (I’ve lasted 8 days) for reoccurrence.
Is there a different place to turn it off? If not, you may just be taking a while to have a reoccurrence.
Not as far as I know. Only place I’m aware of is in the DVR setting.
I started out with 1.7 and had the glitch, I downgraded to 1.6 for a day, and then went up to 1.8. After that, as long as transcoding is off in DVR setting, no issue. It’s been 2 days and I’ve been doing as much back-to-back recording as I can and seems to be going strong.
Hopefully, it will keep going strong for you guys.
I thought the 1.8’s had fixed it, but like I said it started doing it again on the 8th day. No transcoding. Others have reported similar results. It is drastically less frequent in the 1.8s though. A guy on a different thread decided to roll it anyway because he doesn’t mind rebooting every week or two. My setup is not physically close so I can’t handle that.
1.8.1.4319 doesn’t fix this either. It looks like 1.6.1 is last stable release that records properly and ends recordings and release tuners as expected . Strange that DVR has been released out of Beta and it got worse then when in beta.
@skraemertx said:
Strange that DVR has been released out of Beta and it got worse then when in beta.
I agree. After months of dealing with this and other issues, posting logs, and testing/helping with various things…I am now actively testing Emby to potentially replace PMS. Just bought a month to give it a good go, and we’ll see where it goes. I may end up just writing off the cost of my PLEX lifetime pass. For me stability is number one. New features are secondary (though certainly most welcome) but should be tested in private BETA (by those brave volunteers who so choose), and not declared stable while housing glaring, widespread, and longstanding bugs. I think the devs are working very hard, it just seems like too much too fast maybe. Who knows maybe Emby will have me begging for PLEX, but it’s worth a shot to end the pain.
PS. The DVR 100+% bug is annoying, but it’s a different bug affecting both local and remote users on all versions I’ve tested between 1.5.7 and 1.8.x that finally has driven me to this. You reach a point where you get tired of messing with something that is supposed to sit and provide entertainment.
@lorddoskias ,
I agree that 100% issue is a pain , I haven’t had issues until the 1.7.x version came out all previous versions worked fine for me with DVR. 1.6.1 was the last version that was stable and consistent for me, i haven’t had many issues with with plex not being stable except this latest change with chunking for LIve TV. and the switch to mkv wasn’t a thrill but they switched it back because of the subtitle issues. in any case let us know how the Emby Test works out and what functionality is lacking in it vs plex I would be curious to know if its worth switching.
@skraemertx said:
I agree that 100% issue is a pain , I haven’t had issues until the 1.7.x version came out all previous versions worked fine for me with DVR. 1.6.1 was the last version that was stable and consistent for me
Ditto. 1.6.1 was the last release without this bug.
In any case let us know how the Emby Test works out and what functionality is lacking in it vs plex I would be curious to know if its worth switching.
Until there are some logs which show the root cause, it’s a little difficult to diagnose. Rest assured the issue is known, and is being looked into. 
Until there are some logs which show the root cause, it’s a little difficult to diagnose. Rest assured the issue is known, and is being looked into. 
