This will start capture and write to file chan31.1_grab.ts
The time will increment. You can stop the capture with control and c - if the problem is seen in first 5 minutes then capture 5 minutes
Then do a short recording under 1.14. and 1.16 from the channel and lets have logs and .ts files for these as well. Beta 1.16.0.1220-147963d87 available here https://plex.tv/downloads
Just thinking about this - the curl request is via the Plex Media Server Plex Tuner Service - so if there is a bug in the tuner service, it would best to do the curl capture once under 1.14.1 and once under 1.16.0
The CURL.exe capture produces a GOOD .ts file in both 1.16.0.1200 and 1.14.1.5488 A PLEX DVR capture produces a BROKEN .ts file in 1.16.0.1200, and a GOOD .ts file in 1.14.1.5488
Thanks Warham30. Glad I didn’t do the update then. I did notice that the summary of what was fixed didn’t mention anything about this issue but it was a newer version then any of the above mentioned versions so was kinda hoping.
I had some time today to try the 1.16.1.1246 release today and have the same issue with the sound and picture. If I go back to the 1 .14 version it works fine. Has anyone else in this thread had any luck with this issue? This topic seems to have gone quiet. In regards to the recent email I got from plex. Why are you forcing this update on us when you haven’t even fixed the issues in the new versions with regards to audio and video problems? I tried the newest version today and I instantly have problems with pixelation and audio glitches. I revert back to 1.14 and everything works perfect. I really don’t understand why you guys are taking so long to fix this issue and then have the nerve to force paying customers to “upgrade” to a version that is not going to work as intended. I have been following this thread on the forum hoping there would be a solution to this but it has yet to be resolved.
We’re all still having the issue. With the help of @sa2000 I’ve submitted detailed logs and sample streams from various versions which clearly show the issue (and show it not happening in 1.14.x).
I agree with you - it’s a bit on the nose to be forced to chose between:
Watchable DVR streams, but no EPG guide data (version 1.14.x)
EPG guide data, but unwatchable DVR streams (version 1.16.x)
I’ve gone quiet on this, holding out for the cause to be identified and sat with 1.14 but our tv shows are off season now so isn’t as important. I will probably run on the new version 1.16.1.1246 for a bit to see if it is tolerable. Right away I can see 12.1 WISN out of Milwaukee still glitches every 5-30 seconds.
@sa2000 - would giving devs access to my PMS computer with remote access help?
If they want to schedule some days of usage where we shouldn’t use it -we can get by I can hook up a few rabbit ears on the main TVs. It is a windows 10 box I can create a non-microsoft local admin account for remote desktop access to run PMS under.
@sa2000 I put most of my media on a second server now to break things up. Only the OTA recordings are on this box now. They could actually just install plex fresh and not need to have it associated with my account, I can make a backup of my plex database before they do that to plop back down when all is done. I have a couple if not more tv stations that are pretty consistent with this issue.
I have 12meg upload and 200meg download with an existing port forward for each server for plex so they can watch the tv stream on their computer.
I’ve been living with the old version 1.14.1.5488, as it is far less buggy because of the DVR recording issue. And while I appreciate @sa2000 for helping everyone, it’s ridiculous for Plex to force us to upgrade (or else we’ll lose guide data). We basically have 4 days until something doesn’t work – either guide data disappears or DVR recordings become unwatchable.
Life has been too busy to worry about this and I really thought it would have been fixed by now. If more debug data is needed, please provide instructions on how to collect and send it (life actually slowed down enough to do this). In the meantime, the old server version should be allowed to continue working with correct guide data.
I emailed support@hauppauge.com and asked if they were aware of the issue and could do anything to help Plex figure it out. I linked to this thread url. Maybe if everyone having this issue similarly reports it the # of users will give them an idea of the customer base in need of help. They have the plex name on their packaging so there should be some relationship there. I decided to be running the up to date version now instead of 1.14 but ABC really sucks and Fox sucks a little bit in Milwaukee with the audio pops and artifacts.
I checked and am still running the latest driver version for the QuadHD from later last year on win10.
The CURL.exe capture produces a GOOD .ts file in both 1.16.0.1200 and 1.14.1.5488
A PLEX DVR capture produces a BROKEN .ts file in 1.16.0.1200, and a GOOD .ts file in 1.14.1.5488