I wonder how difficult it is to downgrade on a linux (Ubuntu) host to 1.13.x; anybody know?
1 Like
I downgraded my CentOS7 test VM also, the hard part with plex is finding the old versions. Took me half a day of searching to finally find a repository with the older rpms. In the case of ubuntu you can use “dpkg” to downgrade your version if you can find the older package. Good Luck!
I’m going to give Plex version 1.13.9.5439 a try.
For what its worth, I download each point upgrade and save to a file for just such an occasion. The only reason I hadn’t downgraded earlier is that I had a hardware failure on one of my NAS units and have been dealing with that for a while. It was an experimental XPEnology box initially (Core i5 2500K, ASUS P8P67 Pro, 8GB RAM, 12 bay with dual SSD cache) but it turned out to be a great performer and I started to rely on it. So between troubleshooting it and setting up the QNAP TS-451+ to pickup the slack I haven’t had time.
OK, I just rolled back from PMS version 1.14.0.5470 to version 1.13.9.5439.
Before doing so I verified which channels were not currently functionally tuning properly. In this case it was the History Channel, MSNBC and AMC which are channels 662, 652 and 667 respectively.
After uninstalling PMS version 1.14.0.5470 and installing version 1.13.9.5439 all previously failing channels are now functional again.
So there is no question in my mind that there is a significant tuning bug in PMS version 1.14.x.xxxx.
Hopefully my PMS can now reliably record scheduled recordings without error. Hopefully,…
MSNBC is one of the channels that inconsistently records for me as well. I’m using a HDHomeRun Prime. The Food Network is also a challenge from time to time as well.
Plex, what do you need to effectively troubleshoot these errors?
1 Like
I should mention that I only pointedly tested a few channels for none functional ones. My Plex DVR receives something on the order of ~400 channels so it would be difficult and time consuming to test them all. Since my recording schedule was hit with so many errors during this time in question it just made sense to cover the channels that had a history of failure.
I have little doubt that there were other channels that had issues under PMS version 1.14.0.5470 but I wasn’t aware of them specifically.
After rolling back to version 1.13.9.5439 and receiving a great deal of relief from this issue I still cannot be 100% certain of the status of all ~400 channels. However, the most frequent channels I use and the channels noted to have a history of problems are no longer an issue.
It is however reasonable to assume the tuning bug can be avoided by avoiding PMS version 1.14.x.xxxx.
Luck me, I also managed to get my XPEnology Core i5 2500K PMS functional again. Although I’ll have to re-scan the library which will take some time.
Did you roll back via snapshot or by actually downgrading? While I’m running Plex Server on an Ubuntu VM I don’t have a snapshot to roll back to.
I run Plex Media Server on a Synology DS1815+ NAS with an Intel Atom C2000 series SoC (8 bays) and a DYI XPEnology Core i5 2500K platform. Synology DSM is Linux based.
I also run a QNAP TS-451+ which is a kind of backup for the XPEnology NAS.
I basically just uninstalled PMS version 1.14.0.5470 and Installed version 1.13.9.5439.
Generally doing so isn’t an issue. All scheduled recordings are still scheduled. The tuner doesn’t have to be reinstalled. There is no need to re-scan the media locations. It just works right away.
I had an unrelated problem with the XPEnology system where I had to remount some remote shares. Once I did that I realized I didn’t do it exactly the same way so the path was different and thus things weren’t going to work right. This necessitated a re-scan. I standardized my methods this time so if it happens again the path will be exactly the same (should I have to manually remount again).
I checked all my cable lines for unnecessary splitters. Removed one. Haven’t had the problem since.
Ok, so here’s what I found.
On linux (in my case Ubuntu) you don’t “uninstall” the old version; you install the old version ontop of the new version. When you do, this overwrites the existing (newer) version with the older version but keeps all of your library / settings / etc.
It took some piecing together but I want able to download the old version from Plex (it’s available but there’s no URL for it; it was a combination of using this list of plex releases here combined with this post here on downloading old versions:
(Mirror of comments incase deleted)
Basic process is to go to Plex.TV/downloads and right click on the link to download the current version and copy the link address. Paste it into a text editor. For example the current version download for Windows is:
https://downloads.plex.tv/plex-media-server/1.9.3.4290-9798172d4/Plex-Media-Server-1.9.3.4290-9798172d4.exe
If you are using a different OS the method is the same you would just have a different URL. For OSX the URL would be something like:
https://downloads.plex.tv/plex-media-server/1.9.3.4290-9798172d4/PlexMediaServer-1.9.3.4290-9798172d4-OSX.zip
You then need to know the prior version number, the full version information not just 1.6.1. For 1.6.1 the version info was: 1.6.1.3722-4955e31cf
We then replace the current version info (1.9.3.4290-9798172d4) with the prior version (1.6.1.3722-4955e31cf) we want to download so the new link for version 1.6.1 becomes:
https://downloads.plex.tv/plex-media-server/1.6.1.3722-4955e31cf/Plex-Media-Server-1.6.1.3722-4955e31cf.exe
Paste the new link into your web browser and the download should start.
I then used wget to download the file to a directory on my server. Once there, I ran it using “sudo dpkg -i packagename.deb” and it was done.
Just remember if you’re using a plex update script to disable it.
At this point I’m on 1.13.9.5456 and am waiting to see what happens with the recording. Will report back.
And now I get “There was a transcoder error”. Rebooting the server and trying again.
Rebooted and now it’s “There was a transcoder error”.
Grrrrr.
Well downgrading definitely corrected the issue for me.
One thing that I have noticed now that all the channels are working again with version 1.13.9.5439 is that the channels that often would not tune properly under version 1.14.0.5470 seem to take longer to tune in.
That is to say, perhaps version 1.14.0.5470 assumes a channel wont tune if it doesn’t tune in within a specific threshold time. A threshold time that is lower then that of earlier versions of PMS like 1.13.9.5439.
Its just a guess.
I wonder if I need to go a version lower; I’m running 5456 and you’re on 5439
Interestingly enough, other things I had scheduled for today on different channels recorded just fine.
Show just tried to record, and failed.
With logs…
Plex Media Server Logs_2018-12-07_15-09-01.zip (4.8 MB)
2 minutes later, Plex deletes the entry in the Recordings Calendar so you aren’t even aware that there was a problem…
QuadPC-Plex, from the log you provided it looks like the same error I was seeing, “Error 16.” You could try and downgrade your installation to 1.13.x and see if you can tune channel 655.
Dec 07, 2018 14:52:41.754 [32880] INFO - Plex Media Server v1.14.0.5470-9d51fdfaa - Microsoft PC x64 - build: windows-i386 english - GMT -08:00
Dec 07, 2018 14:52:41.754 [32880] INFO - Windows version: 10.0 (Build 17134), language en-US
Dec 07, 2018 14:52:41.754 [32880] INFO - 8 2592 MHz processor(s): Architecture=0, Level=6, Revision=24067 Processor Identifier=Intel64 Family 6 Model 94 Stepping 3, GenuineIntel
Dec 07, 2018 14:52:48.353 [31424] DEBUG - Job was already killed, not killing again.
Dec 07, 2018 14:52:48.354 [31424] ERROR - DVR:Recorder: Error 16 (Recording failed. Please check your tuner or antenna.) starting the record, shutting things down.
Dec 07, 2018 14:52:48.354 [31424] DEBUG - MediaRecorderVirtual: setting stop time to 2018-12-07 14:52:48
Dec 07, 2018 14:52:48.354 [31424] DEBUG - DVR:Recorder: Asked to stop recording 'The Five - E246 - Episode 246' on channel 655.
Dec 07, 2018 14:52:48.354 [31424] DEBUG - DVR:Grabber: Freed a tuner (now 3 available)
Dec 07, 2018 14:52:48.354 [31424] ERROR - DVR:Recorder: Error 16 (Recording failed. Please check your tuner or antenna.) starting the record, shutting things down.
Dec 07, 2018 14:52:48.354 [31424] DEBUG - MediaRecorderVirtual: setting stop time to 2018-12-07 14:52:48
Dec 07, 2018 14:52:48.354 [31424] DEBUG - DVR:Recorder: No more consumers, stopping.
Dec 07, 2018 14:52:48.354 [31424] DEBUG - DVR:Grabber: Operation for 'The Five - E246 - Episode 246' on channel 655 completed with status error (Recording failed. Please check your tuner or antenna.)
Dec 07, 2018 14:52:48.355 [31424] DEBUG - Activity: Ended activity 5f22b0d3-ae18-4dd6-bd2d-bc3238b065cf.
Dec 07, 2018 14:52:48.355 [31424] ERROR - DVR:Grabber: Starting media grab failed.
Dec 07, 2018 14:52:48.435 [24276] DEBUG - DVR:Subscription: No match in the library for 'The Five - E246 - Episode 246', grabbing.
Dec 07, 2018 14:52:51.007 [0008] DEBUG - DVR:Schedule: Attempting to schedule the item 'The Five - E246 - Episode 246'.
Dec 07, 2018 14:52:51.007 [0008] DEBUG - DVR:Schedule: Trying airing at 2018-12-07 14:00:00 on channel 655.
Dec 07, 2018 14:52:51.007 [0008] DEBUG - DVR:Schedule: Device 0 tuner 0 scheduled recording between 2018-12-07 14:00:00 and 2018-12-07 15:00:00 on channel 655.
Dec 07, 2018 14:52:51.007 [0008] DEBUG - DVR:Grabber: Starting grab immediately for 'The Five - E246 - Episode 246' on channel 655 and we're 3171 seconds in already.
Dec 07, 2018 14:52:51.011 [18304] DEBUG - DVR:Grabber: Starting operation for 'The Five - E246 - Episode 246' on channel 655.
Dec 07, 2018 14:52:51.011 [0008] DEBUG - DVR:Schedule: Trying airing at 2018-12-18 14:00:00 on channel 655.
Dec 07, 2018 14:52:51.011 [0008] DEBUG - DVR:Schedule: Device 0 tuner 0 scheduled recording between 2018-12-18 14:00:00 and 2018-12-18 15:00:00 on channel 655.
Its been two weeks since we’ve heard from Plex staff. Could we get a brief update? Thank you.
I am sorry but since having moved to satellite at home, I can’t even use DVR/LiveTV to test anything.
It stands to reason that if it cant tune the channel in a specific time, it will complain. They might have increased the min signal strength requirement as well. if truly OTA, and splitters are involved, do the math. See how much signal is really getting to the tuner. Splitters are not created equal.
It’s easy to blame splitters, and sometimes they are in fact the culprit, but in my case I don’t believe that signal strength is the issue. In my setup I’m using an Electroline EDA2900MMA to distribute signal throughout my house, and all unused ports are capped with terminators. I’m also running a MoCA filter on the main CATV feed from the street. In any case the screenshot of the tuner status on one of the channels that failed consistently to tune with 1.14.x clearly shows a good strong signal, and that channel is tunable without issue via the HDHR app (tested on windows 10 and Android)
TL:DR - In my case signal strength is NOT likely the cause.
I do not blame splitters out of hand. There are enough cases though where someone will have the TV connected to the -3.5 port and the tuner connected to the -7.5 dB port when the reverse is best. Ideally, a balanced splitter (50 cents more) is worth it.
In your case, your CATV feel strength is good and almost a bit hot. I have seen them run super hot (10+ dBmV) which is way over spec of (0-8 dBmV) and where 0 dBmV is spot on. Spec states -8 -> +8 dBmV with 0 as ideal.
I have an HDHR3 Prime but without cable, I can’t see what PMS is doing.
The transcoder does start, opens the tuner, and starts reading from it. If it doesn’t get input in time, it faults with the ‘blame antenna’ error. This really could be the CPU. Without actually seeing it in action and comparing against the Silicon Dust app directly, there is zero way I can help further. I’m sorry.
