Plex 1.10 Still No Joy...Same Bugs Persist

I really wanted the new 1.10 release to resolve the issues I (we) have been tracking. I REALLY would love to try out the commercial stripping functionality, but unfortunately the same bugs as before persist:

  1. stuck / hung tuners
  2. hung tuners in the interface that do not represent actual status of the tuner hardware
  3. incomplete recordings
  4. broken / malformed / zero length file recordings.
  5. A new one, recordings would start, interface and tuners both show recording status and at some point the hardware gets dropped before completing the show while the interface still shows an active recording.

These symptoms were tested and verified today with 6 recordings over a span of about 4 hours.

Results:
0 successful recordings
3 failed (triangle status) recordings
3 incomplete / partial recordings generating files between 3mb and 26mb

Reverting to 1.6.1
For those who want to suggest that there is something wrong with my hardware, processor etc…I have successfully recorded 1,300 recordings using 1.6.1.

Love Plex, looking forward to getting these bugs squashed

I’m testing 1.10 at the moment and all recordings are going okay.

If I could make a suggestion the one time I have seen a problem with recording via the DVR has occurred when the input signal was corrupted in some way. This occurred during bad weather and seemed to corrupt the recording.

DTV signals can be flakey. They may be causing the PMS some trouble when the data flow gets interrupted. With DTV it can be hard to determine if your signal is bad as the error correction covers a fair amount, but it might just take a little nudge to send the tuner over the edge. My suggestion is to look at signal strength and signal quality.

From all the errors you have noted above they all seem like they could be caused by a bad signal to the tuner.

@dagrilla said:
I really wanted the new 1.10 release to resolve the issues I (we) have been tracking. I REALLY would love to try out the commercial stripping functionality, but unfortunately the same bugs as before persist:

  1. stuck / hung tuners
  2. hung tuners in the interface that do not represent actual status of the tuner hardware
  3. incomplete recordings
  4. broken / malformed / zero length file recordings.
  5. A new one, recordings would start, interface and tuners both show recording status and at some point the hardware gets dropped before completing the show while the interface still shows an active recording.

These symptoms were tested and verified today with 6 recordings over a span of about 4 hours.

Results:
0 successful recordings
3 failed (triangle status) recordings
3 incomplete / partial recordings generating files between 3mb and 26mb

Reverting to 1.6.1
For those who want to suggest that there is something wrong with my hardware, processor etc…I have successfully recorded 1,300 recordings using 1.6.1.

Love Plex, looking forward to getting these bugs squashed

Try shutting down Plex. Clear out your log file. Restart plex and schedule a recording or two. Immediately after failure grab logs and upload the zip file so we can try to help you.

@dagrilla said:
I really wanted the new 1.10 release to resolve the issues I (we) have been tracking.
Reverting to 1.6.1
Love Plex, looking forward to getting these bugs squashed

What OS are you using? I’ve had nothing but progressively worse DVR results with every update for many months.

1.10.1 Ditto.
3 Recording attempts, 3 failures.

Recording 1:
HDHR light did go on
Web interface did indicate a recording was taking place
after 7 minutes HDHR light was off. Plex web interface said recording was complete
A 2mb file with a few seconds of video was produced

Recording 2:
HDHR Light did go on
after 12 minutes HDHR light was off
plex web interface showed a failed recording
no file was produced

Recording 3:
HDHR light did NOT go on
plex web interface showed a failed recording with message “Recording not started because airing in progress”

Backed up all files, logs and directories in the event Plex wants to track these bugs down.

Reverted to 1.6.1

heres also a log from a started playback try … in the end the same behavior, cant tune channel, error occured, whatever …
same happens from time to time … only solution, reboot server wich is a pain when a shield is not with direct access :wink:


Dec 10, 2017 02:26:05.027 [3508] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:05.027 [31484] DEBUG - Request: [192.168.1.101:62900 (Subnet)] POST /livetv/dvrs/6/channels/452/tune (12 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:05.028 [31484] DEBUG - DVR:Subscription: Starting a new rolling subscription for session tuig8dtd9ae1zjxdbbe9z2j3 channel 452.
Dec 10, 2017 02:26:25.021 [3508] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.022 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.023 [31483] DEBUG - Request: [192.168.1.101:62915 (Subnet)] GET /library/sections (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.023 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.024 [31500] DEBUG - Request: [192.168.1.101:62916 (Subnet)] GET /media/providers (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.027 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.028 [31501] DEBUG - Request: [192.168.1.101:62910 (Subnet)] GET /music/iTunes (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.030 [31502] DEBUG - Request: [192.168.1.101:62917 (Subnet)] GET /hubs?excludeFields=summary&count=12&includeEmpty=1&includeFeaturedTags=1&excludePlaylists=1 (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.030 [3509] DEBUG - Completed: [192.168.1.101:62915] 200 GET /library/sections (16 live) GZIP 7ms 862 bytes (pipelined: 1)
Dec 10, 2017 02:26:25.031 [31502] DEBUG - HubCache: Retrieving ‘1/home.continue/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.031 [3509] DEBUG - Completed: [192.168.1.101:62910] 404 GET /music/iTunes (16 live) GZIP 9ms 379 bytes (pipelined: 1)
Dec 10, 2017 02:26:25.032 [31502] DEBUG - HubCache: Retrieving ‘1/home.ondeck/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.032 [31502] DEBUG - HubCache: Retrieving ‘1/home.movies.recent/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.033 [31502] DEBUG - HubCache: Retrieving ‘1/home.television.recent/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.034 [31502] DEBUG - HubCache: Retrieving ‘1/home.videos.recent/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.035 [31502] DEBUG - HubCache: Retrieving ‘1/home.photos.recent/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.035 [31502] DEBUG - HubCache: Retrieving ‘1/home.music.recent/hubs/12/de’ from the cache.
Dec 10, 2017 02:26:25.036 [3509] DEBUG - Completed: [192.168.1.101:62916] 200 GET /media/providers (16 live) GZIP 12ms 1119 bytes (pipelined: 1)
Dec 10, 2017 02:26:25.038 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.039 [31502] DEBUG - Selecting best audio stream for part ID 10707 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.039 [31502] DEBUG - Audio Stream: 23968, Subtitle Stream: -1
Dec 10, 2017 02:26:25.040 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.040 [31502] DEBUG - Selecting best audio stream for part ID 10686 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.041 [31502] DEBUG - Audio Stream: 23919, Subtitle Stream: -1
Dec 10, 2017 02:26:25.042 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.042 [31502] DEBUG - Selecting best audio stream for part ID 10687 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.042 [31502] DEBUG - Audio Stream: 23922, Subtitle Stream: -1
Dec 10, 2017 02:26:25.044 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.044 [31502] DEBUG - Selecting best audio stream for part ID 10688 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.044 [31502] DEBUG - Audio Stream: 23925, Subtitle Stream: -1
Dec 10, 2017 02:26:25.045 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.045 [31502] DEBUG - Selecting best audio stream for part ID 10706 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.045 [31502] DEBUG - Audio Stream: 23965, Subtitle Stream: -1
Dec 10, 2017 02:26:25.047 [31502] DEBUG - We’re going to try to auto-select an audio stream for account 1.
Dec 10, 2017 02:26:25.047 [31502] DEBUG - Selecting best audio stream for part ID 10708 (autoselect: 1 language: de)
Dec 10, 2017 02:26:25.047 [31502] DEBUG - Audio Stream: 23971, Subtitle Stream: -1
Dec 10, 2017 02:26:25.083 [3509] DEBUG - Completed: [192.168.1.101:62917] 200 GET /hubs?excludeFields=summary&count=12&includeEmpty=1&includeFeaturedTags=1&excludePlaylists=1 (16 live) GZIP 55ms 8423 bytes (pipelined: 1)
Dec 10, 2017 02:26:25.169 [3508] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.169 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.170 [31483] DEBUG - Request: [192.168.1.101:62917 (Subnet)] GET /hubs/home/recentlyAdded?type=1 (16 live) Page 12-38 GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.170 [31501] DEBUG - Request: [192.168.1.101:62916 (Subnet)] GET /hubs/home/recentlyAdded?type=2 (16 live) Page 12-38 GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.173 [31483] DEBUG - Setting container serialization range to [12, 38] (total=-1)
Dec 10, 2017 02:26:25.208 [31483] DEBUG - It took 60.000000 ms to retrieve 27 items.
Dec 10, 2017 02:26:25.211 [31483] DEBUG - Setting container serialization range to [12, 38] (total=51)
Dec 10, 2017 02:26:25.245 [3509] DEBUG - Completed: [192.168.1.101:62917] 200 GET /hubs/home/recentlyAdded?type=1 (16 live) GZIP Page 12-38 75ms 16878 bytes (pipelined: 2)
Dec 10, 2017 02:26:25.314 [31501] DEBUG - It took 90.000000 ms to retrieve 75 items.
Dec 10, 2017 02:26:25.407 [31501] DEBUG - Requesting more shows since stacking only returned 13 items.
Dec 10, 2017 02:26:25.914 [31501] DEBUG - It took 460.000000 ms to retrieve 500 items.
Dec 10, 2017 02:26:25.947 [3508] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.947 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.947 [31499] DEBUG - Request: [192.168.1.101:62917 (Subnet)] GET /:/prefs (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.953 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.954 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:25.954 [31502] DEBUG - Request: [192.168.1.101:62910 (Subnet)] GET /accounts/1 (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.956 [31483] DEBUG - Request: [192.168.1.101:62915 (Subnet)] GET /myplex/account (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.957 [31500] DEBUG - Request: [192.168.1.101:62918 (Subnet)] GET /system/:/prefs (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:25.957 [31500] DEBUG - [com.plexapp.system] Sending command over HTTP (GET): /system/:/prefs
Dec 10, 2017 02:26:25.957 [31500] DEBUG - HTTP requesting GET http://127.0.0.1:47015/system/:/prefs
Dec 10, 2017 02:26:25.957 [3509] DEBUG - Completed: [192.168.1.101:62910] 200 GET /accounts/1 (16 live) GZIP 9ms 513 bytes (pipelined: 2)
Dec 10, 2017 02:26:25.958 [3509] DEBUG - Completed: [192.168.1.101:62915] 200 GET /myplex/account (16 live) GZIP 4ms 755 bytes (pipelined: 2)
Dec 10, 2017 02:26:25.970 [31500] DEBUG - HTTP 304 response from GET http://127.0.0.1:47015/system/:/prefs
Dec 10, 2017 02:26:25.969 [3508] DEBUG - Completed: [192.168.1.101:62917] 200 GET /:/prefs (16 live) GZIP 21ms 7764 bytes (pipelined: 3)
Dec 10, 2017 02:26:25.970 [31500] DEBUG - [com.plexapp.system] HTTP reply status 304, with 0 bytes of content.
Dec 10, 2017 02:26:25.971 [3508] DEBUG - Completed: [192.168.1.101:62918] 304 GET /system/:/prefs (16 live) GZIP 16ms 324 bytes (pipelined: 1)
Dec 10, 2017 02:26:26.028 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:26.053 [31502] DEBUG - Request: [192.168.1.101:62915 (Subnet)] GET /web/common/img/backgrounds/preset-dark.64cc1c942221cd2c153244bd8ecfb67a.png (16 live) GZIP Signed-in
Dec 10, 2017 02:26:26.053 [31504] DEBUG - Request: [192.168.1.101:62918 (Subnet)] PUT /myplex/refreshReachability (16 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:26.053 [31502] DEBUG - Final path: /data/user/0/com.plexapp.mediaserver.smb/Resources/Plug-ins-648bc61d4/WebClient.bundle/Contents/Resources/common/img/backgrounds/preset-dark.64cc1c942221cd2c153244bd8ecfb67a.png
Dec 10, 2017 02:26:26.053 [31502] DEBUG - Content-Length of /data/user/0/com.plexapp.mediaserver.smb/Resources/Plug-ins-648bc61d4/WebClient.bundle/Contents/Resources/common/img/backgrounds/preset-dark.64cc1c942221cd2c153244bd8ecfb67a.png is 31365.
Dec 10, 2017 02:26:26.053 [31504] DEBUG - MyPlex: Requesting reachability check.
Dec 10, 2017 02:26:26.054 [3508] DEBUG - Completed: [192.168.1.101:62915] 200 GET /web/common/img/backgrounds/preset-dark.64cc1c942221cd2c153244bd8ecfb67a.png (16 live) GZIP 1ms 31365 bytes (pipelined: 3)
Dec 10, 2017 02:26:26.058 [31504] DEBUG - HTTP requesting PUT https://plex.tv/api/servers/c69769951585c6f44117f8afe6828145dda8d04d/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=7ceb1d5a-22d5-484c-9acb-3f0a06097eec
Dec 10, 2017 02:26:26.292 [31504] DEBUG - HTTP 200 response from PUT https://plex.tv/api/servers/c69769951585c6f44117f8afe6828145dda8d04d/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=7ceb1d5a-22d5-484c-9acb-3f0a06097eec
Dec 10, 2017 02:26:26.293 [3509] DEBUG - Completed: [192.168.1.101:62918] 200 PUT /myplex/refreshReachability (16 live) GZIP 240ms 268 bytes (pipelined: 2)
Dec 10, 2017 02:26:26.325 [31501] DEBUG - Setting container serialization range to [12, 38] (total=-1)
Dec 10, 2017 02:26:26.333 [31501] DEBUG - There were 1 top-level paths for Buffy.
Dec 10, 2017 02:26:26.341 [31501] DEBUG - There were 1 top-level paths for Sons of Anarchy.
Dec 10, 2017 02:26:26.347 [31499] DEBUG - Request: [54.171.118.141:25919 (WAN)] GET /identity (17 live) Signed-in Token (myusername)
Dec 10, 2017 02:26:26.348 [31501] DEBUG - There were 1 top-level paths for Black Sails.
Dec 10, 2017 02:26:26.348 [3508] DEBUG - Completed: [54.171.118.141:25919] 200 GET /identity (17 live) 0ms 357 bytes
Dec 10, 2017 02:26:26.356 [31501] DEBUG - There were 1 top-level paths for Humans.
Dec 10, 2017 02:26:26.372 [31501] DEBUG - There were 1 top-level paths for Profiling Paris.
Dec 10, 2017 02:26:26.381 [3508] DEBUG - Completed: [192.168.1.101:62916] 200 GET /hubs/home/recentlyAdded?type=2 (17 live) GZIP Page 12-38 1211ms 9936 bytes (pipelined: 2)
Dec 10, 2017 02:26:26.427 [31507] DEBUG - EventSource: Got event [data] ‘’
Dec 10, 2017 02:26:26.427 [31507] DEBUG - PubSub: Got notified of reachability: 1 for 91.66.204.154:32410
Dec 10, 2017 02:26:26.434 [3509] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:26.435 [31483] DEBUG - Request: [192.168.1.101:62916 (Subnet)] GET /myplex/account (17 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:26.436 [3509] DEBUG - Completed: [192.168.1.101:62916] 200 GET /myplex/account (17 live) GZIP 1ms 755 bytes (pipelined: 3)
Dec 10, 2017 02:26:27.934 [3508] DEBUG - Auth: authenticated user 1 as myusername
Dec 10, 2017 02:26:27.934 [31500] DEBUG - Request: [192.168.1.101:62916 (Subnet)] GET /diagnostics/logs (17 live) GZIP Signed-in Token (myusername)
Dec 10, 2017 02:26:27.935 [31500] DEBUG - Diagnostics: Building logfile zip

1.11 Ditto.

2 Recording attempts, 2 failures.
So similar to all of the previous buggy versions I stopped testing after two recordings.

Recording 1:
HDHR light did go on
Web interface did indicate a recording was taking place
after 12 minutes HDHR light was off. Plex web interface said recording was complete
A 52mb file with a few 2 minutes and 19 seconds of video was produced

Recording 2:
HDHR Light did go on
after full 30 minutes HDHR light was off
plex web interface showed a successful recording
However, the file produced was only 89mb file with just 3 minutes and 37seconds of video

Reverted to 1.6.1

Can I just ask a question, not meaning it to be taken in a wrong or condescending way…

Why do you think its bugs in the Plex code? I’m not having any problems with Plex DVR as are other people I know who use it. It works quite well for us.

I’m just curious, not meaning to be antagonistic.

Actually i think this is a very valid point. I was having several issues with my system until i reloaded it. I had a old Windows Home server install that just had something that was borked for Plex DVR on anything 1.7.x +. After the OS reload it worked fine. It would be interesting to hear the whole picture of what the platform is that we are talking about here. I know a reload may not be needed for all, But plex can’t account for all software variations we may have on our systems.

By the way my environment has been flawless since the reload.

I never had an issue with watching live TV or recording until I went to watch a show that was to be recorded on the 11th, now unable to watch Live TV and the tuner fails to tune a channel. all channels are watchable on OTA with roku but not plex.

What tuner are you using and what firmware for the tuner?

The reason I asked is because the one time I had significant issues with dropped recordings (recordings lasting about 6 or 7 min or so) was when I bought a second SiliconDust HDHomeRun Prime. It took me a while to realize that it was running older firmware. Once I upgraded the firmware it worked reliably with Plex DVR.

Edit:

For what it’s worth I am running the latest version of Plex Media Server and it seems to be running fine. Older versions worked fine as well. IIRC, I had an issue with 1.7.x or 1.8.x a while back whereby recordings didn’t seem to even start but downgrading solved that issue. The issue didn’t reoccur in subsequent upgraded versions.

Replying to Stephen3001 Maverick Mrgagreer and Octavean:

  1. the reason I know it is a bug is because I have tested every single point release between 1.6.1 and 1.11. ALL versions except 1.6.1 exhibit the same bugs
  2. Until I stumbled on a post from another person experiencing the same issues with the tip that 1.6.1 was the last stable release, I actually did exhaustive testing including fresh installs and testing of every version from 1.6.1 up into the 1.9s somewhere before I grew weary of starting over for another point release that would exhibit the same bugs as all the releases prior
  3. Other users, a LOT of them have the exact same set of issues. ALL of them. I post here so all of the other people who have the same issue know they aren’t alone. Know they can use 1.6.1 until the issue is resolved and so they can know they don’t need to waste time installing the latest point release.
  4. I have confirmation from PLEX dev themselves that they have identified the issue(s) and are working on them. I post to let them know that I have tested each point release and that the bugs persist
  5. I know it isn’t my hardware because as noted above, many many others have the exact list of bugs using a variety of different hardware AND the same hardware has recorded at this point about 3,000 shows without any issue using 1.6.1.
  6. Firmware etc is up to date. I have a browser window open with tabs for this forum, plex download, firmware update etc. I check several times a day on all fronts. Looking forward to closing this window once this is all resolved.

In short I’ve probably spent 100+ hours testing and isolating the issue. If I can save anyone else the majority of those hours by simply reading my posts then I’ll have performed a valuable service. I really appreciate the person who posted 1.6.1 as a stable release and another who posted how to access older releases. their posts saved me a ton of time and so I’m trying to do the same for others.

I’m sure Plex will nail this down. In the meantime, I’ll test each point release and let them know if the issues persist.

I have been using 1.6 version for a while due to it working better with mkv being direct play capable on my clients and it hasn’t had any stuck recordings. I just tested a fresh build on a new setup in Ubuntu and I seem to be getting some stuck recordings, I haven’t fully tested it though and it could be my setup/bad reception even as I just started, but I do appreciate seeing the thread with tests and myself use 1.6 for my primary still.

@dagrilla said:
Replying to Stephen3001 Maverick Mrgagreer and Octavean:

  1. the reason I know it is a bug is because I have tested every single point release between 1.6.1 and 1.11. ALL versions except 1.6.1 exhibit the same bugs
  2. Until I stumbled on a post from another person experiencing the same issues with the tip that 1.6.1 was the last stable release, I actually did exhaustive testing including fresh installs and testing of every version from 1.6.1 up into the 1.9s somewhere before I grew weary of starting over for another point release that would exhibit the same bugs as all the releases prior
  3. Other users, a LOT of them have the exact same set of issues. ALL of them. I post here so all of the other people who have the same issue know they aren’t alone. Know they can use 1.6.1 until the issue is resolved and so they can know they don’t need to waste time installing the latest point release.
  4. I have confirmation from PLEX dev themselves that they have identified the issue(s) and are working on them. I post to let them know that I have tested each point release and that the bugs persist
  5. I know it isn’t my hardware because as noted above, many many others have the exact list of bugs using a variety of different hardware AND the same hardware has recorded at this point about 3,000 shows without any issue using 1.6.1.
  6. Firmware etc is up to date. I have a browser window open with tabs for this forum, plex download, firmware update etc. I check several times a day on all fronts. Looking forward to closing this window once this is all resolved.

In short I’ve probably spent 100+ hours testing and isolating the issue. If I can save anyone else the majority of those hours by simply reading my posts then I’ll have performed a valuable service. I really appreciate the person who posted 1.6.1 as a stable release and another who posted how to access older releases. their posts saved me a ton of time and so I’m trying to do the same for others.

I’m sure Plex will nail this down. In the meantime, I’ll test each point release and let them know if the issues persist.

I was asking out of curiosity.

I wasn’t trying to suggest that Plex is perfect because clearly there are issues. However while there very well may be a prominent bug in Plex that you and many others are wrestling with, still many others are not. While it’s neither here nor there, I run Plex Media Server on three different systems and have encountered no bug that would limit my upgrade progress beyond 1.6.1.

The two aren’t necessarily mutually exclusive. Some are effected by said bug and some are not but we have all presumably tested the same versions of PMs beyond version 1.6.1. The logical question then is why are some effected and others aren’t? Is it regional, platform (Linux, Windows, Mac), hardware platform etc,…?

Either way, it’s good that Plex engineers are working on the issue. Hopefully you’ll get some relief soon. Whenever that day comes hopefully you won’t see reoccurrences with newer versions beyond that point,…

For those of us that don’t have this issue we can consider ourselves lucky.

Thank you @dagrilla for your response.

As a broadcast systems engineer I am just as interested in the process of fault/bug finding as much as the bug/fault itself.

From my point of view, as I said, I have no problems with the current Plex version and the operations of the DVR/Live TV. i’m On holidays now and using the Live TV function to stream local programming to my phone that i’m Not getting while i’m At the remote location. It works perfectly every time.

The amount of variables in play in any Plex system is high. The software, the hardware, internet connections, the clients, the hardware of the clients. All are in play when fault finding. I just recommend not obsessing on a particular part of a system you suspect being bad. I’ve seen to many instances of this lead to misdiagnosis of faults and time wasted.

I wish you well on your mission.

1.11.1 Ditto.

All the same bugs persist.

  • failed recordings
  • stuck tuners
  • incomplete recordings
  • etc

7 Recording attempts, 7 failures.

Again similar to all of the previous buggy versions. I decided to let it run for longer this time because none of my scheduled recordings were critical.

7 recordings failed
3 of the failed recordings produced files
0 of the files were more than 10% of the length of the actual program.

If you are keeping track, that is at least 16 point releases since that last version of Plex DVR that actually works…1.6.1.

Reverted to 1.6.1

still working okay here

1.11.2

Wait a minute…this might be working.

I am hesitant to declare absolute success, but in about 24 hours of testing, 1.11.2 has successfully recorded more shows than all of the versions between 1.6.1 and 1.11.2 combined.

Over this span I have had 9 recordings, 8 successful.

I will continue to post updates, but so far 1.11.2 seems to have resolved the issues I’ve been documenting and reporting.

Fingers crossed!

1.11.2

Your mileage may vary. If it does, remember 1.6.1 is table and it works…but I think I am ready to declare 1.11.2 as a working version of Plex DVR.

None of the issues in the previous releases dating back to 1.6.1 are manifesting.

In two days of testing I have had 21 shows record, 20 of them were successful.

In addition to enjoying a working DVR, it is great to have all the features introduced since 1.6.1…excellent!