Thanks so much for sharing that discussion link. It worked great! 
This is a load of cr@p! Why this was released is beyond my understanding as I thought Plex knew what they were doing, I used to be proud to say that I bought a lifetime pass back in beta but now it looks like the quality control has hit the fan. Pull this off of our systems until you can make it stable! Unless you want to continue to pisss off your users.
I’ve noticed that when a large library scans that 1) the calendar portion under ‘Recording Schedule’ fails to load, and 2) if I click on one of the scheduled recordings under ‘Recording Priority’ and make changes, it fails when I click ‘Save’. Is it possible this is related to recordings in progress not being saved? My scans are set to automatic and hourly.
any fix for this so far? Im running CentOS minimal and even the reboot wont work, I have lost a ton of “recorded” TV programs last night.
@mrangelo said:
any fix for this so far?
Engineering is working on it. I’ve been aiding in reproducing and we’ve made progress, but a fix is not yet ready.
I also have been a long-time plex pass member. This bug has been around for many months. I recently joined Emby Premiere and immediately have working recording of TV and streaming of live TV to Roku and other devices. I still think Plex is the better overall system, but missing live TV and recording are tough to overlook.
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
Fantastic 
Thanks for the update.
Please make the error message (if signal related) more clear in the future. The generic errors make it difficult to understand out what the heck is going on and how to fix it as an end user.
And, if Plex is able to determine when the signal is intermittent, consider generating a warning so folks know to double-check the quality of the recorded content. Otherwise, the show gets captured (poorly & pixelated) and added to the library. I’ll never know about it until I want to watch it, at which point it’s too late to fix and very annoying.
Cheers on the good work!
@kinoCharlino said:
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
I’m sorry, I have a tough time with this response. This does not explain how some of us [without changing anything to do with our signals] did total reinstalls of Plex and THAT fixed our problems.
Best case, you are right. Hope so, because you are giving a lot of people good reason to be very upset if you’re wrong.
I just got my hands on a patched build and will be testing it this afternoon and evening. I was able to reproduce the issue quite consistently before.
@irishcaptainjack said:
Please make the error message (if signal related) more clear in the future. The generic errors make it difficult to understand out what the heck is going on and how to fix it as an end user.
We have an internal issue ticker filed for this already. I agree, a bit more information at the point of error would be helpful and not too scary for the average user.
@irishcaptainjack said:
And, if Plex is able to determine when the signal is intermittent, consider generating a warning so folks know to double-check the quality of the recorded content. Otherwise, the show gets captured (poorly & pixelated) and added to the library. I’ll never know about it until I want to watch it, at which point it’s too late to fix and very annoying.
From what I understand, we’re just handling signal quality issues better with this patch, not calling them out to the user, but I will pass your suggestion on to engineering. The challenge is we can’t really tell when the signal is intermittent other than via transcoder errors, which honestly look just like any other transcoder error.
@roycooper said:
I’m sorry, I have a tough time with this response. This does not explain how some of us [without changing anything to do with our signals] did total reinstalls of Plex and THAT fixed our problems.
I brought this up with engineering and they said this problem should not have been resolved by reinstalling, if you were experiencing the same issue caused by the same root cause. Reinstalling can fix a corrupted install, and deleting your AppSupport directory in the process might have helped, though engineering doesn’t believe it would have resolved the particular root cause that is affecting most users. It’s possible the root cause of the issue you experienced was different. There are almost certainly multiple root causes that lead to the “100%-stuck” symptom. The patch we’re testing now is expected to resolve the one most commonly reported in the forums (by a large margin).
I’m extremely disappointed in Plex and the team of devs. You guys had a working build back in 1.7x - now you constantly break it with updates. This is rookie stuff. I was trying to cut the cord and my Plex app used to be reliable for DVR but over the last few months it’s been totally unreliable. You guys are better than this. Please deliver to this community something that works as advertised.
@kinoCharlino said:
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
Am I correct in assuming that you’re not necessarily talking about signal strength here, but rather what’s in the mux from the provider?
@skeletorjus said:
@kinoCharlino said:
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
Am I correct in assuming that you’re not necessarily talking about signal strength here, but rather what’s in the mux from the provider?
I was about to ask the same. During all my failed recordings I never showed the signal strength, as measured by the HDHomerun units, to be anything less than stellar.
Anyway I do hope the Plex team and those helping test really have a handle on this as the true root cause. I would love to get back to the latest version as many do. I only question, since I know 1.6.1 is rock solid, was some of this testing being done performed to get any side by side comparisons to what I would call the “last known working version”?
@MarkAllen45 said:
@skeletorjus said:
@kinoCharlino said:
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
Am I correct in assuming that you’re not necessarily talking about signal strength here, but rather what’s in the mux from the provider?I was about to ask the same. During all my failed recordings I never showed the signal strength, as measured by the HDHomerun units, to be anything less than stellar.
Anyway I do hope the Plex team and those helping test really have a handle on this as the true root cause. I would love to get back to the latest version as many do. I only question, since I know 1.6.1 is rock solid, was some of this testing being done performed to get any side by side comparisons to what I would call the “last known working version”?
To be fair, I just asked because I felt it needed clarification. The root cause of the error isn’t signal strength (or loss of it), but rather the transcoder crashing when there’s items/streams in the mux that it isn’t prepared to handle.
The reason this isn’t happening in 1.6.1 is that this is the final version released before Plex started involving the transcoder and do segmentations of the recordings.
I’ve gone thru about half of the comments on this thread and have seen a few individuals mention system behavior that sounds similar to mine. I wanted to add my experience in hopes that it would help pin point the issue and/or provide more detail on the issue.
Background:
I am currently running Plex 1.9.5 on Windows Home Server 2011, 8 GB of RAM and an Intel Core i3 processor. Transcodes are stored on SSD, .grab files are on spinning drives pooled together using Stablebit DrivePool. My tuner is a HDHomeRun Extend running the latest firmware.
I do use the Plex As A Service app for starting Plex as a service on the box but I also log into the box because I found that Plex is unable to move files from the .grab directories to the permanent library locations unless I am logged in (this may be due to the libraries being setup using UNC paths).
Plex libraries are all setup using UNC paths (ex. \\SomeServer\SomeDirectory\TVShows)
I have been running Plex DVR for about two months (recording approximately 20 shows a week) and have always updated to the latest Plex Pass betas when they are released without issue. The first time I experienced the 100% issue was on Tuesday (11/7) of this week. At that point I was running version 1.9.6.4401. Yesterday I installed 1.9.7 and experienced the same issue. I also tried back-leveling to version 1.9.5 yesterday (where I currently am) but I am still getting the “100%” issue on all recordings that I start.
Signal strength has not been an issue on the channels that I record on. For the example provided below the signal strength of the channel was 100%.
Observations:
- Recordings start normally within Plex
- As the recording continues in Plex the .grab file does not grow in size proportional to length of time that Plex has been recording (as an example typically at the end of a 1 hour 720p recording the file size is 2.5 GB but what I see is the .grab file is only around 300 MB at the end of the hour and continues to grow)
- At recording end time Plex continues to create .ts segments in the ${user.home}\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\plex-transcode-xxxxxxxxxxxxxxxxxxxxxxxxxx directory
- At the same time the .grab folder continues to grow in size but is way behind the size of the .ts segements in the plex-transcode-xxxxxxxxxxxxxxxxxxxxxxxxxx directory. As an example I recorded the “The Late Show with Stephen Colbert” last night and at the time when the recording should have been ending the .ts directory had +4 GB of files but the .grab file was only 500 MB.
- Instead of killing the PlexTranscoder processes like I have been I let it run to completion. The end results is that Plex downloaded +25 GB of .ts files to the ${user.home}\AppData\Local\Plex Media Server\Cache\Transcode\Sessions\plex-transcode-xxxxxxxxxxxxxxxxxxxxxxxxxx directory. The .grab file was successfully created and moved to the permanent location. Additionally the plex-transcode-xxxxxxxxxxxxxxxxxxxxxxxxxx directory still exists on the server and has not been removed because the PlexTranscoder process is still running.
- The side-effect of the transcodes never ending above is that none of the tuners are freed up on the HDHomeRun until the .grab file is completed and moved. This results in all of the subsequent recordings failing.
I grabbed the .ts files (4 GB+), .grab file (500 MB) and logs from the server for this time period described above and can provide if needed. I don’t know how long I will be able to stay on this version of the server if all recordings are going to fail. It sounds like my only recourse is to go all the way back to 1.6.1.
@kinoCharlino said:
Good news is we’ve nailed down the root cause and are working on a patch. Definitely signal related, definitely fixable
I’m curious what you mean by signal related. I use an HDHomeRun PRIME which takes a cable card. I do not record OTA, so I should be unaffected by signal strength. I also have not had any outages to cable/internet when these problems occur.
Maybe you actually mean mean something like corrupted frames or a demuxer problem or something else that’s actually not related to signal, but could be a symptom of low signal?
Saying it is signal related is obviously a gross oversimplification of the issue. You guys love the details, so hopefully this post will provide more of that. The key root cause we’re testing a patch for has to do with bit-flips that trigger an issue with timestamps.
@skeletorjus said:
Am I correct in assuming that you’re not necessarily talking about signal strength here, but rather what’s in the mux from the provider?
Yes, it is possible and part of the investigation. It’s also possible the signal Plex DVR is getting is worse than it appears. You can have quite a lot of loss without it being visually noticeable due to error correction, but it only takes one well-placed bit-flip to trigger the timestamp issue we’ve isolated. The root cause we’re working through has to do with corrupted timestamps. For regular A/V bitstream data (which is most of it), a bitflip will just result in, at worst, an undecodeable packet that gets discarded. And for most of the packet header, it’ll result in an undemuxable packet that gets discarded. If there’s an uncorrected bitflip in the timestamp, there’s currently no mechanism to detect that, and timestamp handling is probably the single most fragile thing in the whole stack. That’s where we are focused on with this patch.
To be fair, I just asked because I felt it needed clarification. The root cause of the error isn’t signal strength (or loss of it), but rather the transcoder crashing when there’s items/streams in the mux that it isn’t prepared to handle.
We haven’t seen any evidence of transcoder crashes so far. They’re very evident in the logs. A crash will give a log along the lines of exit code for process [pid] is -11.
The latest patch we are testing seems to have improved things. So far I’ve scheduling recording for 15 programs and 1 got stuck, but only temporarily. It cleared up and was successful once the show after it was done recording and all tuners were freed up. All the rest were fine. We’re looking into why that happened, but it’s looking promising otherwise.
Initially I was able to reproduce this with my local FOX affiliate. Their tower is further away from my location than others and (according to the FCC’s tool) my receive power was -83 dBm. I moved my antenna to a better location and I no longer saw this issue with FOX. That’s when it started up with QUBO, which is a good channel to test against because they air 30 minute kid shows back-to-back, 24/7. QUBO’s tower is closer to my location and I show receive power of -23 dBm.
@mjarends, awesome write up! I’ve forwarded that to the engineers working on this issue.
@kinoCharlino said:
@skeletorjus said:
To be fair, I just asked because I felt it needed clarification. The root cause of the error isn’t signal strength (or loss of it), but rather the transcoder crashing when there’s items/streams in the mux that it isn’t prepared to handle.We haven’t seen any evidence of transcoder crashes so far. They’re very evident in the logs. A crash will give a log along the lines of
exit code for process [pid] is -11.
Maybe crash is bad wording on my part and saying it’s unable to handle it is more accurate.
I’m sure that bad signal can trigger the problem, but it’s absolutely not the only way to encounter this.
The issue ultimately lies in how Plex handles these inconstencies, whether they originate from signal loss or other causes.
@skeletorjus said:
I’m sure that bad signal can trigger the problem, but it’s absolutely not the only way to encounter this.
The issue ultimately lies in how Plex handles these inconstencies, whether they originate from signal loss or other causes.
Yeah, I agree and I believe the engineers working on this issue would also agree. Poor signal was just one way for us to trigger it in testing, so we could reproduce it over and over. Gong strong here on the patch testing.
What software can I use with my HDHomerun tuner to determine what my signal strength is and how do I interpret the numbers? Is -85db better or worse than -20db? Just curious so I can get a read on my situation prior to installing this next Plex patch.
