For now, so that you can safely get the server back up and running,
I recommend using PMS Public release 1.42.2.10156
ok thanks.
I just want to raise the awareness around users which are Plex members, yet cannot use Beta channel as there isn’t one for Debian/Ubuntu Linux, and have waited 2-3 months for stability fixes which have been added in the last three beta release. It’s not ideal and I dont know the complexity here for supporting two transcoders at the same time and having a feature toggle for ffmpeg 4 vs 6, but that would have been the ideal case…
So, continue with betas having ffmpeg and still push stability releases where users can opt in on ffmpeg 6 or simply skip it outside outside beta completely. I for instance don’t transcode anything and don’t care about regressions after ffmpeg bump, but I do care about core stability fixes
You can have betas on Linux… there’s just no beta repository with automatic updates.
1 Like
Having a toggle feature “v4” vs “v6” would be a great deal of work (manweeks of both developer and operations hours).
All the codecs would need to be renamed.
There would be no backward compatibility if you opted to use a PMS which didn’t have a v4/v6 flag.
We’d end up with three full sets of codecs (pre, v4, and v6)
I see. I’ve been waiting for almost 3 months now, so I don’t mind waiting for another month
A post was merged into an existing topic: Qr code on link screen
Also, it’s not like ffmpeg 6.x is some terribly new piece of software or wasn’t under extensive testing by thousands of people. Considering the latest ffmpeg - and indeed potentially troublesome - is version 8.0.x, you wouldn’t receive some “bleeding edge” or “early alpha” piece of software with ffmpeg 6.x.
In fact, the 6-branch of ffmpeg is older than my grandma and has been released back in 2023, so I don’t see any necessity worth the manweeks chuck pointed out for a toggle between v4 and v6.
Also, considering ffmpeg 4 is almost a decade old and the vast majority of programs where transcoding with ffmpeg or handbrake is involved updated to at least ffmpeg 7 months/years ago, it’s about damn time for an update, but that’s just my personal opinion.
With growing demand for transcoding soft- and hardware, new codecs, driver updates, etc. comes the necessity to increase compatibility and provide patches, right?
So I’d even have prefered ffmpeg 7, which I’ve found perfectly suiting my needs with other software I use where ffmpeg is involved and which is, already, perfectly stable in the very most hardware and software setups
Your Grandma ?
We decided on 6 because:
- 7 was really buggy at the time we started the development
- The feature gain from 6 to 7 wasn’t worth the additional PMS work required for those features.
Please remember, we had to
- take the “on its last breath” FFMPEG 4,
- pull out all the PMS-proprietary / copyright (license)-mandated changes
- fix/modernize that code ( a plethora of hacks )
- integrate it into FFMPEG 6 and update PMS to use it properly.
- upgrade all the drivers and codes (and device tables for the new CPU/GPUs.
- lay in the base work for a few other things everyone has wanted for a long time (NO, I’m not gonna tell ya
lol )
While the decision was made to go to FFMPEG 6, --------
That does NOT preclude updating to 7 sometime in the future.
There is nothing to gain by discussing 7 at this time.
We first need to deploy FFMPEG 6 and ensure it’s stable for everything.
This modernization effort is structured that the FFMPEG code is segregated into Upstream code and Plex code. This means that when FFMPEG fixes or new versions come, upgrading is not a monumental year-long task.
2 Likes
Do you know when the server update will be released? It sounded like it was just about ready to go before the holidays.
Server code wise – I think it’s ready for Beta but would need confirm with Chris.
The biggest holdup we have is the complete rewrite of the build system & repository.
This work is almost complete too.
I watch the progress daily and have been involved with a few recent discussions.
II don’t know the planned release date.
I know they’re working to meet the Debian 13/SHA-1 cutoff date
I just did package mods to make transitioning to the new package (cert & repo) seamless.
8 Likes
Bumping this thread… it’s been since September 2025 since there was a next stable release on QNAP… are there any expectations on a release? For Linux the download site shows
v.1.43.0.10492-121068a07
February 5, 2026
For QNAP it’s still
v.1.42.2.10156-f737b826c
September 18, 2025
1 Like
Dears
Does it mean that most of you do have problems while playing movies/series with 1.43? Did I got it well?
Me is having troubles for weeks that everything stuck after few seconds (even Transcoding is turned off and Direct Stream/Play is turned on).
I’m running PMS on a QNAP too and its been 5 months since the last update. Other platforms (including all other NAS’) have had updates available since early February.
Any idea on when the next update for QNAP will be released?
1 Like
I hope they just leave the Android version alone. Definitely don’t want the new experience.
1 Like
1 Like
In other words… hurry up and wait? 
yesterday I was thinking “man, that transcoder really pisses me off / is inconsistent and whatnot” - was happy to find this thread. will test 1.43. thanks for providing it <3
I have raised support ticket with QNAP to find out what the delay is with their side of the claimed certificate issue preventing media server update for QNAP. Q-202604-20100
3 Likes
6 months with no non-beta updates is approaching obscene. Looks like most every other platform has an official 1.43 release, while us QNAP folks are left behind.
Thank you for raising a ticket, hopefully they’ll provide an update.
1 Like
