Package Details: plex-media-server 1.40.2.8395-1

Git Clone URL: https://aur.archlinux.org/plex-media-server.git (read-only, click to copy)
Package Base: plex-media-server
Description: The back-end media server component of Plex.
Upstream URL: https://plex.tv/
Keywords: DLNA
Licenses: custom
Conflicts: plex-media-server-plexpass
Submitter: alucryd
Maintainer: fryfrog (tixetsal)
Last Packager: fryfrog
Votes: 350
Popularity: 0.97
First Submitted: 2014-10-14 22:11 (UTC)
Last Updated: 2024-04-19 01:45 (UTC)

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 107 Next › Last »

techwiz commented on 2019-11-21 04:44 (UTC)

@user98170, Uhh... Well I would say that you probably want to reinstall pacman and/or base-devel. That error seems to be related to your system not this package. Maybe try the forums for more help.

user98170 commented on 2019-11-21 04:33 (UTC)

Been experiencing an issue for a few days now. Don't know what to do. Keep getting:

==> ERROR: Unknown download protocol: https -> Downloading plexmediaserver-1.18.2.2041-3d469cb32.x86_64.rpm... /usr/share/makepkg/source/file.sh: line 72: Aborting...: command not found ==> ERROR: Failure while downloading https://downloads.plex.tv/plex-media-server-new/1.18.2.2041-3d469cb32/redhat/plexmediaserver-1.18.2.2041-3d469cb32.x86_64.rpm Aborting...

techwiz commented on 2019-11-20 18:23 (UTC)

@j1simon, yes you can modify the PKGBUILD to meet your needs and maintain your patched repo yourself. As fryfrog mentioned, the change is trivial and the maintenance would be equally trivial for you. Asking the community, which agreed on “The Arch Way,” to bend over for your request is of course going to be met with resistance. Sorry for the inconvenience, but this is how we’ve all agreed things should be.

j1simon commented on 2019-11-20 17:32 (UTC)

I don't agree again. There are a way to solve this but someone decides doesn't use it because ¿the Arch way?

fryfrog commented on 2019-11-20 17:29 (UTC)

@j1simon: It doesn't matter if you agree or not, the Arch way is to not start or restart daemons and so that is how all the packages I manage operate. I personally would love if Arch came up w/ a way for packages to notify that they need restarting, so that at the end of a big upgrade, a user could be presented w/ all the services that might need restarting... but that doesn't exist.

You are of course welcome to take this AUR package and modify it how you'd like it to work. Keeping it up to date is as easy as changing a couple version fields and updating the checksums.

j1simon commented on 2019-11-20 17:24 (UTC) (edited on 2019-11-20 17:24 (UTC) by j1simon)

I don't agree. Every time Plex is upgraded, I have to restart Plex service manually because the service is in a state of error after upgrade. That should never happen if the update was correct.
For that is the .install file and this package uses it. In the post_upgrade() section it would be necessary to check if the service is started and if that is the case to restart it.

techwiz commented on 2019-11-20 14:41 (UTC)

@j1simon refer to this reddit post from 2013 that does a good job of explaining why Arch packages don’t start or stop services: https://www.reddit.com/r/archlinux/comments/1s1p9t/comment/cdt8mo1

The gist is that it’s up to the user to configure and run their software, and as such many packages don’t ship with a default config that makes sense to run out of the box. Since we don’t know if the user wants to start the service right away or if the default config is good enough, pacman does not manage services, it just installs them.

j1simon commented on 2019-11-20 10:10 (UTC)

Why is not the service restarted when upgraded?

techwiz commented on 2019-10-31 02:37 (UTC)

@ectospasm: “ tl;dr, my ~/.cache/pikaur directory was a symlink to an NFS share, and for whatever reason this location was causing the bsdtar unpacking of the rpm to have permissions of 750, not 755.”

This makes sense as an NFS mount is not a local file system. Your NFS server is (correctly) defining your permissions as the file system is local to the server not your machine. Glad you figured out your issue.

ectospasm commented on 2019-10-31 02:29 (UTC)

@fryfrog: I solved my issue. See https://bbs.archlinux.org/viewtopic.php?pid=1871148 for my troubleshooting effort.

tl;dr, my ~/.cache/pikaur directory was a symlink to an NFS share, and for whatever reason this location was causing the bsdtar unpacking of the rpm to have permissions of 750, not 755.