plex-media-player VS flathub

Are you actually using Plex Media Player (a deprecated player that hasn't received updates for several years now) or Plex for Windows/Plex HTPC ([the currently available clients)?

I've tried both cables now, though the previous cable was able to push 4K@160Hz before. This appears to be an issue with the application causing rapid FPS fluctuations while gsync is enabled that the monitor can't keep up with. https://github.com/plexinc/plex-media-player/issues/1060

The last release of PMP was 2.58.0 (from May 2020), which you can download directly from Plex here: https://downloads.plex.tv/plexmediaplayer/2.58.0.1076-38e019da/PlexMediaPlayer-2.58.0.1076-38e019da-windows-x64.exe. 2.58.1 is technically the latest version, released in June 2021, but I don't think Plex released binaries for it, so you'd have to build it from source. The real issue though is trying to use Windows 7 with services still in active development. You'll likely run into more issues over time with a 2+ year old client attempting to communicate with the latest server version, so I'm guessing you'll eventually have to bite the bullet and change the OS, potentially to a Linux distro that supports Plex HTPC if you don't want to update to Windows 8/10/11.

Because we're specifically talking about Plex for Mac, Windows, and Linux, which, as you mentioned, is not the same as Plex HTPC or Plex Media Player. Both Plex HTPC and Plex for (Mac|Windows|Linux) are available to download here:

I'd normally advice just using the desktop app, but they still don't have a Linux client outside of the still-in-forum-preview Plex HTPC, or the essentially abandoned Plex Media Player that you have to build from source.

Plex for Windows is closed source. Plex Media Player is the closest you'll get, which hasn't seen active development in several years.

Looks like this github issue is describing what you're seeing (Plex blocked all external access to nightlies.plex.tv), and a reply mentions it's likely caused by the passed in DQTROOT not existing. Did you download the right version of QT from qt.io, or ensure you're passing in the right QT root?

I did however find this. As far as I can tell, the media player's UI runs on a local instance of their web client. When building, it fetches the web client using a build ID. Now the web client is not open source I think, but I imagine that it *should* be possible to choose which client we want to use.

Plex for Windows is different to PMP, it doesn't contain the TV mode, it's essentially just Plex Web App without the browser. As far as I know, there is no easy way to have it controlled by a remote etc. I actually still use an older version of PMP, several versions before support was stopped an update broke skipping forwards and backwards. It introduced a delay after the button press, (unlike Kodi there was no way to change the setting either.) After several threads popped up on the forums and it was announced to be fixed (and it not being fixed), I ended up finding the last version that worked and have stuck on that one and disabled all auto updates. One thread here. I understand apps will be slowly phased out etc, but at least have the replacements work fully before stopping support for the one platform that could do everything.

> Nobody ever even audits the binary contents of flatpaks on flathub (were they actually built from the source? the author attests so!).

IME/IIRC There aren't (or shouldn't be) any binary contents on Flathub that are submitted by the author, at least for projects with source available? You're supposed to submit a short, plain-text recipe instead, which then gets automatically built from source outside the control of the author.

> The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.

https://docs.flathub.org/docs/for-app-authors/submission/#ho...

Usually the recipes should just list the appropriate URLs to get the source code, or, for proprietary applications, the official .DEBs. Kinda like AUR, but JSON/YAML. Easy to audit if you want:

https://github.com/orgs/flathub/repositories

I also don't believe third parties maintainers packaging software on flathub is a big issue but I'm also not familiar with how other distro repos trust their maintainers. Hopefully more developers maintain their flatpak themselves (or someone they trust) and get their apps verified. If most apps are verified, warning users of unverified apps might be a good idea.

There's ongoing discussion about splitting open source and proprietary apps in to seperate repos [1]. Additionally having seperate repos for verified and unverified apps might make it more obvious where an app comes from in the cli.

But I don't know how seamlessly an app could transition between being in the third party repo and being in the official repo. Having the user quietly stop receiving updates seems like a bad idea, but automatically migrating might not be desirable either.

I also think flatpaks cli interface needs some work. It is functional but far from distro package managers.

Being verified is especially important for critical apps. Recently someone added malicious versions of apps to the snap store [3]. This lead to people getting their cryptocurrency stolen.

[1] https://github.com/flathub/flathub/issues/691

[2] https://docs.flathub.org/docs/for-app-authors/requirements

[3] https://forum.snapcraft.io/t/temporary-suspension-of-automat...

That means Linux users can now install Bforartists on any Linux distro easily, regardless of glibc version! https://github.com/flathub/flathub/pull/4295

Still having some problems with the flathub build, see https://github.com/flathub/flathub/pull/4082 for the current status.

Here is the flathub draft pull request: https://github.com/flathub/flathub/pull/4082

i assume you dont know how flathub works , theirs little or no QC , done flathub is just get told theirs an update for the package , if yo go look at the github repo pes https://github.com/flathub/flathub/pull/4164 for example , only updates the link to the girt repo , theirs 0 code checked

It all should be written in pages for contributors, read the docs for fusion, and the docs for flathub.

These are criticisms of the flatpak ecosystem as it stands today. Currently, the Firefox ESR package on flathub seems to be caught in limbo or maybe dead. Mozilla publishes both a snap and a flatpak of Firefox latest, but only a snap of the ESR version. This raises the question of why. Have Mozilla chosen to invest more in snaps than in flatpaks? If so, what's their reasoning? (More users on snaps, making it similar to why they put more investment into Windows than Linux? Something else?) If they haven't invested more into snaps than flatpaks, is this a sign that it's harder to maintain flatpaks (or at least on flathub) than snaps? If that's true, I would hope that flatpak/flathub would be soliciting feedback from Mozilla about it.

Because that may be very hard to sandbox: https://github.com/flathub/flathub/issues/3366