new to Linux... best way to update PMS to latest version

server-linux

#1

I'm currently running PMS v1.11.3.4803 on a Linux Mint machine. Update Manger is prompting me to upgrade to v1.12.0.4829-6de959918, and will do the install automatically at the click of a button. However, the Plex Server / Settings / General tab warns to "Please install (the update) manually", which downloads a .deb file with identical version.

This is my first PMS update since building my Linux machine, and being new to Linux, I have no clue what to do with a .deb file.

Can someone explain why I shouldn't just let Update Manager do the install? And if that's not a good idea, details on how to do a manual install would be appreciated.


#2

The notification inside Plex doesn't mean you cannot use the update manager. The Windows version of the Plex Media Server (and I think the macOS one too) support directly updating the server from the homepage. There, the notification will state "click here to update".

so...
1. you can keep going with the update manager -- no need to manually download the file and update it on your own
2. if you prefer doing it by yourself... process is the same as for installing it in this support article : https://support.plex.tv/articles/200288586-installation/ (in short... use the terminal/console and run sudo dpkg -i plexmediaserver_0.9.8.18.290-11b7fdd_amd64.deb -- replacing the last filename with the name of the package you downloaded)


#3
  1. Check your "Update Channel" to see why it's reporting as it is.
  2. If you've added the repository to apt and it runs automatically for you, then you can let it do its thing)

Regarding the version of PMS you referenced, If that's what is telling you about updates, manually update now. That version is some 3+ years old now. Anything below 1.0 won't work properly with plex.tv

Additionally, it's so old that none of us are tooled up to support it. The oldest I can support is 1.5.3 (last mandatory update version)


#4

@tom80H said: The notification inside Plex doesn't mean you cannot use the update manager.
Not sure why it would be worded "Please install manually" in the Linux distro unless there's a reason. I'm aware of other software that recommends manual updates, apparently because repository doesn't maintain latest version. In this case, the repository has latest, so if that's the only reason, then I'll let Update Manager do the install. In any case, thank you for posting manual install command syntax. That's useful to know.

@ChuckPA said: Check your "Update Channel" to see why it's reporting as it is.
Not sure what you mean. Update Manager is simply prompting me to install new version, as one would expect it to do. When I initially installed PMS on my Linux machine last fall, I followed manual install instructions found elsewhere in this forum, which included the following command:

sudo add-apt-repository ppa:plexapp/plexht

@ChuckPA said: Regarding the version of PMS you referenced... That version is some 3+ years old

You must have mis-read my post. I'm currently running v1.11


#5

This repository reference looks like PHT, not PMS sudo add-apt-repository ppa:plexapp/plexht , which is no longer under Plex maintenance.

May I point you to confirm this is the repository specification you have?

https://support.plex.tv/articles/235974187-enable-repository-updating-for-supported-linux-server-distributions/


#6

@ChuckPA, turns out the command I posted wasn't the one I used. I carelessly grabbed it from a thread in Linux Mint forum where I had sought help with the installation. That was five months ago and at the time I looked at a lot of discussions and honestly can't recall what I did to add PMS to my update channel. But it's clear that Update Manager has it right. I just updated to v1.12 from Update Manager.

I have a question that's been bugging me ever since I installed PMS on my Linux machine...

My Linux machine has a fast CPU (7700K), 32GB of RAM and a SDD. So why does it take MUCH longer to load the Plex app on Roku and start movies than when running Classic Plex (v0.9), which is served on my ancient XP machine that has a 12-year-old CPU, 2GB and a mechanical HDD?

I just took these stats, starting with freshly booted machines and nothing else running...

XP machine
Plex Classic Roku app takes 9 seconds to load
starting a movie (not counting navigation clicks) takes 7 seconds

Linux machine
Plex Roku app takes 43 seconds to load
starting the same movie takes 64 seconds


#7

You can't really compare that way.

  1. Different OS
  2. 0.9.x compared to now? There has been so much functionality added. Just look at the size of the actual executables. Additionally, since 0.9.x , the first time you use a particular codec, it must be downloaded. This was done to keep the download size (a complaint) as small as possible
  3. Roku app capabilities are a lot more sophisticated as well in addition to a lot of changes forced by Roku due to their firmware updates. The app could no longer function the way it used to (Roku SceneGraph)
  4. Lastly, a core change in the utilization of Plex.tv and how features work.

#8

Ouch. So are the load times I mentioned in line with what others experience with current version? Maybe I should revert to an older version on my Linux machine. The reason we're still using the XP version is because of the terrible load times for new version. But at some point I'll be retiring that machine.

Aside from slow loading, I don't care for the new UI, and none of the new features hold ANY interest for me, other than Plex no longer having to transcode everything as with 0.9.x. But I'm getting decent transcoding performance on my old XP machine so my new machine shouldn't break a sweat.

So what's the oldest Linux version and where can I find?


#9

If everyone saw it, there would be countless complaints.

I have an i7-6700 on Linux, HDD only, and it's crisp. VERY crisp. 3 seconds max.

If you have an existing 0.9.8.x database, I really do advise just starting over. There are so many schema updates it's got to be painful and grossly fragmented.

XP support was dropped long ago after Microsoft dropped XP. Any comparisons to it are not valid.

If you're running windows 10, from what I hear, all bets are off. every update, from what I hear, breaks stuff. Just another reason I'm glad I've never used it for more than minimal debugging of problems for someone else.

Plex only offers current PMS version for any server or player.


#10

@Chuck, I took your earlier comment to mean that my slow load times are in-school with what should be expected on my high performance CPU due to all the changes you outlined. Your own confirms that's not the case.

Not sure what you mean by having "an existing 0.9.8 database"... My Linux install (and Plex) was built totally from scratch so there's no potential for my XP 0.9.8 install to affect the other.

I timed some more loads and learned several things...

First, since my Roku's are wireless, I eliminated the possibility that distance to the router as being the culprit. Next I ruled out that my slow load times could have been caused by codec downloading. Whatever codec may have been used by the test video must have already been installed since the video took equally long to load (around 65 seconds) to load in a 2nd test.

I then re-did the tests on a different Roku device, and therein lies the problem. I have four Roku's and three are different models: Roku HD (2500), Roku 2 XD (3050), & Roku 3 (4200). The initial test was on the Roku HD. In the 2nd test on the Roku 2 XD, the Plex app and video each loaded almost twice as fast (but still too slow for my taste). Finally I tested on the Roku 3 and to my amazement, load times dropped to 5 or 6 seconds! Wow. I knew there were h/w differences but it didn't occur to me how much this would affect load times because with Plex 9.8, there wasn't enough difference in load times among devices to even notice. It all makes sense now. Problem solved.


#11

65 seconds to start playback?

May I have the logs of that? That is absolutely unacceptable No Way, No How

The only way it could take that long is if you're trying to play 4K HEVC UHD and transcode it, in software, on that 7700. Only the GPU, which you don't have access to without a Plex Pass, has the speed needed to transcode down to anything less than HEVC HDR (2K or 4K)


#12

I've never accessed the logs before. The zip file has over a hundred files going back to October. So I re-ran the test on a 2nd gen Roku HD device and again, it took 45 sec. to load Roku Plex app and 63 seconds to load 720x302 video. I repackaged the only two log files that updated during current session, which starts at roughly 04:22 and lasts a couple minutes to the end. I deleted my email address. Let me know if you need anything else. I'm off to bed now.


#13

Your logs should only contain the main + 5 roll-over versions of it. There should not be over 100 files

Thank you for the log you provided . I see the problem. It is the Roku itself.

PMS started your playback and began a direct streaming session within 5 seconds. The Roku then broke the connection. This continued several times until it began playback. Please notice the "disconnected' messages where the Roku has closed the connection.

This usually indicates something in the firmware (old or buggy version. Roku does have a history of faulty firmware. I recommend performing a device reset and application reload

Mar 10, 2018 23:36:10.241 [0x7f66e1ffd700] DEBUG - [Now] User is whetstone (ID: 1)
Mar 10, 2018 23:36:10.241 [0x7f66e1ffd700] DEBUG - [Now] Device is Roku (Roku HD - 18C27C053058).
Mar 10, 2018 23:36:10.241 [0x7f66e1ffd700] DEBUG - [Now] Profile is Roku-7.x
Mar 10, 2018 23:36:10.242 [0x7f66e1ffd700] DEBUG - [Now] Updated play state for /library/metadata/6.
Mar 10, 2018 23:36:10.242 [0x7f66e1ffd700] DEBUG - Statistics: (b942aabbf4eec09bd06111fe65f1998e) Reporting active playback in state 2 of type 1 (scrobble: 0) for account 1
Mar 10, 2018 23:36:10.245 [0x7f66ee7fe700] DEBUG - Completed: [192.168.1.75:51679] 200 GET /:/timeline?time=0&duration=8359446&state=buffering&ratingKey=6&key=%2Flibrary%2Fmetadata%2F6&guid=com.plexapp.agents.imdb%3A%2F%2Ftt2119532%3Flang%3Den&playQueueItemID=78 (6 live) TLS GZIP 4ms 464 bytes (pipelined: 5)
Mar 10, 2018 23:36:10.696 [0x7f66ee7fe700] DEBUG - Failed to stream media, client probably disconnected after 999424 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:10.696 [0x7f66ee7fe700] DEBUG - Completed: [192.168.1.75:51684] 200 GET /library/parts/5/1491261074/file.mp4 (6 live) TLS 6692ms 999424 bytes (pipelined: 1)
Mar 10, 2018 23:36:15.291 [0x7f66ee7fe700] DEBUG - Auth: authenticated user 1 as whetstone
Mar 10, 2018 23:36:15.292 [0x7f66e27fe700] DEBUG - Request: [192.168.1.75:51686 (Subnet)] GET /library/parts/5/1491261074/file.mp4 (6 live) TLS Signed-in Token (whetstone)
Mar 10, 2018 23:36:15.292 [0x7f66e27fe700] DEBUG - Request range: 5655914 to 0
Mar 10, 2018 23:36:15.296 [0x7f66e27fe700] DEBUG - Content-Length of /media/Plex/Movies/Hacksaw Ridge.mp4 is 652406782.
Mar 10, 2018 23:36:17.267 [0x7f66ee7fe700] DEBUG - Failed to stream media, client probably disconnected after 1802240 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:17.267 [0x7f66ee7fe700] DEBUG - Completed: [192.168.1.75:51685] 200 GET /library/parts/5/1491261074/file.mp4 (6 live) TLS 8740ms 1802240 bytes (pipelined: 1)
Mar 10, 2018 23:36:22.060 [0x7f66eefff700] DEBUG - Failed to stream media, client probably disconnected after 1818624 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:22.060 [0x7f66eefff700] DEBUG - Completed: [192.168.1.75:51686] 200 GET /library/parts/5/1491261074/file.mp4 (5 live) TLS 6768ms 1818624 bytes (pipelined: 1)
Mar 10, 2018 23:36:24.378 [0x7f66eefff700] DEBUG - Auth: authenticated user 1 as whetstone
Mar 10, 2018 23:36:24.378 [0x7f66e1ffd700] DEBUG - Request: [192.168.1.75:51688 (Subnet)] GET /library/parts/5/1491261074/file.mp4 (5 live) TLS Signed-in Token (whetstone)
Mar 10, 2018 23:36:24.378 [0x7f66e1ffd700] DEBUG - Request range: 946120 to 0
Mar 10, 2018 23:36:24.383 [0x7f66e1ffd700] DEBUG - Content-Length of /media/Plex/Movies/Hacksaw Ridge.mp4 is 652406782.
Mar 10, 2018 23:36:24.549 [0x7f66ee7fe700] DEBUG - Auth: authenticated user 1 as whetstone
Mar 10, 2018 23:36:24.549 [0x7f66e1ffd700] DEBUG - Request: [192.168.1.75:51679 (Subnet)] GET /:/timeline?time=0&duration=8359446&state=buffering&ratingKey=6&key=%2Flibrary%2Fmetadata%2F6&guid=com.plexapp.agents.imdb%3A%2F%2Ftt2119532%3Flang%3Den&playQueueItemID=78 (5 live) TLS GZIP Signed-in Token (whetstone)
Mar 10, 2018 23:36:24.550 [0x7f66e1ffd700] DEBUG - Client [b942aabbf4eec09bd06111fe65f1998e] reporting timeline state buffering, progress of 0/8359446ms for guid=com.plexapp.agents.imdb://tt2119532?lang=en, ratingKey=6 url=, key=/library/metadata/6, containerKey=, metadataId=6
Mar 10, 2018 23:36:24.550 [0x7f66e1ffd700] DEBUG - [Now] User is whetstone (ID: 1)
Mar 10, 2018 23:36:24.550 [0x7f66e1ffd700] DEBUG - [Now] Device is Roku (Roku HD - 18C27C053058).
Mar 10, 2018 23:36:24.550 [0x7f66e1ffd700] DEBUG - [Now] Profile is Roku-7.x
Mar 10, 2018 23:36:24.551 [0x7f66e1ffd700] DEBUG - [Now] Updated play state for /library/metadata/6.
Mar 10, 2018 23:36:24.551 [0x7f66e1ffd700] DEBUG - Statistics: (b942aabbf4eec09bd06111fe65f1998e) Reporting active playback in state 2 of type 1 (scrobble: 0) for account 1
Mar 10, 2018 23:36:24.554 [0x7f66eefff700] DEBUG - Completed: [192.168.1.75:51679] 200 GET /:/timeline?time=0&duration=8359446&state=buffering&ratingKey=6&key=%2Flibrary%2Fmetadata%2F6&guid=com.plexapp.agents.imdb%3A%2F%2Ftt2119532%3Flang%3Den&playQueueItemID=78 (5 live) TLS GZIP 4ms 464 bytes (pipelined: 6)
Mar 10, 2018 23:36:30.921 [0x7f66ee7fe700] DEBUG - Auth: authenticated user 1 as whetstone
Mar 10, 2018 23:36:30.921 [0x7f66e27fe700] DEBUG - Request: [192.168.1.75:51689 (Subnet)] GET /library/parts/5/1491261074/file.mp4 (6 live) TLS Signed-in Token (whetstone)
Mar 10, 2018 23:36:30.922 [0x7f66e27fe700] DEBUG - Request range: 4088518 to 0
Mar 10, 2018 23:36:30.926 [0x7f66e27fe700] DEBUG - Content-Length of /media/Plex/Movies/Hacksaw Ridge.mp4 is 652406782.
Mar 10, 2018 23:36:32.865 [0x7f66eefff700] DEBUG - Failed to stream media, client probably disconnected after 2588672 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:32.865 [0x7f66eefff700] DEBUG - Completed: [192.168.1.75:51688] 200 GET /library/parts/5/1491261074/file.mp4 (6 live) TLS 8486ms 2588672 bytes (pipelined: 1)
Mar 10, 2018 23:36:33.240 [0x7f66ee7fe700] DEBUG - Failed to stream media, client probably disconnected after 442368 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:33.240 [0x7f66ee7fe700] DEBUG - Completed: [192.168.1.75:51682] 200 GET /library/parts/5/1491261074/file.mp4 (5 live) TLS 36531ms 442368 bytes (pipelined: 1)
Mar 10, 2018 23:36:33.330 [0x7f66eefff700] DEBUG - Failed to stream media, client probably disconnected after 425984 bytes: 104 - Connection reset by peer
Mar 10, 2018 23:36:33.330 [0x7f66eefff700] DEBUG - Completed: [192.168.1.75:51689] 200 GET /library/parts/5/1491261074/file.mp4 (4 live) TLS 2408ms 425984 bytes (pipelined: 1)
Mar 10, 2018 23:36:36.166 [0x7f66eefff700] DEBUG - Auth: authenticated user 1 as whetstone
Mar 10, 2018 23:36:36.166 [0x7f66e1ffd700] DEBUG - Request: [192.168.1.75:51690 (Subnet)] GET /library/parts/5/1491261074/file.mp4 (6 live) TLS Signed-in Token (whetstone)
Mar 10, 2018 23:36:36.166 [0x7f66e1ffd700] DEBUG - Request range: 2517448 to 0

#14

Thanks Chuck. I will try resetting the Roku's and reloading the app when I get some time.

you wrote: There should not be over 100 files
Attached is a directory capture of my log zip. The files date back to the original installation last fall. As I mentioned previously, we aren't using Linux PMS as long as my XP machine remains in operation.

Glancing through the list, most of the files appear to be related to metadata. Since installation, I unchecked as many metadata options as possible in Server settings (especially those listed under the Agents & Library tabs). As an aside, it looks like some of my changes may have been reset with yesterday's upgrade, which may explain why some of the metadata log files recurred on March 10.

BTW, in the current Plex Media Server.log file, I noticed an 'invalid argument' warning occurred approximately 13,000 times within a span of about 1/2 second, shortly after I booted my Linux machine today. None of the Roku devices were awake at the time.

Mar 11, 2018 12:40:45.534 [0x7f66e73ff700] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.1.69 to 192.168.1.255: Invalid argument

During the initial 1/4 second, the above entry alternates with this one:

Mar 11, 2018 12:40:45.534 [0x7f66e73ff700] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.1.69 to 239.255.255.250: Invalid argument

13,000 discovery packets seems like overkill. Is this normal? Also, what's the significance of the 'invalid argument' error?


#15

@whetstone

Your post was apparently lost somewhere.
If you do not want me restoring from my notification log, I will remove it

whetstone commented on new to Linux... best way to update PMS to latest version

Thanks Chuck. I will try resetting the Roku's and reloading the app when I get some time.

> you wrote:  There should not be over 100 files

Attached is a directory capture of my log zip. The files date back to the original installation last fall. As I mentioned previously, we aren't using Linux PMS as long as my XP machine remains in operation.

 Glancing through the list, most of the files appear to be related to metadata. Since installation, I unchecked as many metadata options as possible in Server settings (especially those listed under the Agents & Library tabs). As an aside, it looks like some of my changes may have been reset with yesterday's upgrade, which may explain why some of the metadata log files recurred on March 10.

 BTW, in the current Plex Media Server.log file, I noticed an 'invalid argument' warning occurred approximately 13,000 times within a span of about 1/2 second, shortly after I booted my Linux machine today. None of the Roku devices were awake at the time.

 Mar 11, 2018 12:40:45.534 [0x7f66e73ff700] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.1.69 to 192.168.1.255: Invalid argument

 During the initial 1/4 second, the above entry alternates with this one:

 Mar 11, 2018 12:40:45.534 [0x7f66e73ff700] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.1.69 to 239.255.255.250: Invalid argument

 13,000 discovery packets seems like overkill. Is this normal? Also, what's the significance of the 'invalid argument' error?

Reply:

The warnings are telling me your Linux install isn't letting PMS join the multicast group. This indicates a problem.

Discovery works in Plex by server and clients joining the multicast group. It reduces 'net spray inquiry' traffic to a single "Who's here?" packet.

Since your host isn't allowing it, you're seeing PMS frantically trying to find clients. 13,000 packets is the obvious result from not joining the multicast group in the host network stack


#16

Yeah, my comment posted normally but when I attempted to edit, it went to the moderation queue (I've never seen that happen before). So I reposted and this time it went straight to moderation. I must have tripped some sort of spam filter.

Ouch, it happened again on this post after I attempted a 2nd edit. I should take better advantage of the Preview button :)

I'm re-attaching the log zip file directory capture since your probably didn't get that.

@ChuckPA wrote: The warnings are telling me your Linux install isn't letting PMS join the multicast group. This indicates a problem.
Since yesterday when I executed the commands on the support page you pointed me to that add PMS to my repository, my Update Manager generated the following error:

Malformed line 2 in source list /etc/apt/sources.list.d/plexmediaserver.list (type)

I apparently made a copy/paste error in Terminal. I just deleted the referenced file and re-ran the commands from the support page, which cleared the Update Manager error.

Could a corrupt plexmediaserver.list file explain the multicast error?


#17

No.. multicast errors are in the network layer of linux, not in the package management system (which uses the network layer )

i can't open that file. if 7.6K of text, copy paste please?


#18

Pasting directory list in the comment box is a mess due to the way the capture was formatted. Easier to dump into a spreadsheet since I failed to sort the directory capture by date. I've attached a pdf.

ChuckPA wrote: multicast errors are in the network layer of linux, not in the package management system (which uses the network layer )
I'll get some help with this over in the Linux Mint forum but it might help if I understood what "invalid argument' actually means in this context. I don't presume to understand these things but that's not the sort of feedback one expects to see for a network discovery failure.

In any case, Plex web and Roku app seem to be operating normally now so maybe this was an isolated glitch? I just checked the server log file and there's no recurrence of the packet burst after a reboot. I'll continue to monitor the logs, but it would help if I know what sort of log entry I can do a text search on, so I can see if PMS later succeeded in joining the multicast group...


#19

The error is coming back from the OS and PMS is simply forwarding it to you/us.

PMS makes a standard multicast group join. It works everywhere else so what's different about the mint kernel you have? Too old? perhaps too new?

The focal point for all this is glibc. Everything goes through it to get to the kernel... including networking. If the version is below 2.17, that's our problem PMS needs 2.17 as a minumim


#20

ChuckPA wrote: The error is coming back from the OS and PMS is simply forwarding it to you/us.
Ok. That makes sense.
what's different about the mint kernel you have? Too old? perhaps too new?
Maybe too new... Last week I upgraded to the last EOL kernel (4.13.0-36) that supports my particular version of Mint (18.2). It included fixes for Meltdown & Spectre CPU vulnerabilities. That's when I happened to notice Update Manager prompting me to upgrade PMS, which led to my original question here about manual vs automatic updates for PMS. But the 4.13 kernel isn't all that new. It was published last September, and by now is widely in use, or even retired.

But I don't understand how I'm able to use Roku Plex apps if my O/S won't allow PMS to join multicast to discover clients. The log shows lots of instances where the NetworkServiceBrowser is communicating with clients. Maybe the packet burst was just a glitch?

Also, what about your earlier comment re: 100+ files in my log zip?