previously with 1.41.6.9865 everything was running smoothly.
After update to 1.41.7.9799 plex throws the error “500 Internal Server Error” in browser when
trying to access via domain or public ip (not nat) .
Plex is not reachable via any client or the app.plex.tv website too
Locally on the server plex can be opened and playback works.
The error 500 comes definitely from plex’s internal webserver and not from the reverse proxy.
Plex error log shows “Exception parsing request: bitset test argument out of range”
When I revert to 1.41.6.9865 the plex is immediately reachable and everything works.
Hello, I have exactly the same problem with an error 500 and the log “ERROR - Exception parsing request: bitset test argument out of range” when trying to access the server with my domain, using a reverse proxy. It was working before the upgrade.
When I access directly the server (local or with public IP with NAT), it’s working. I tried in HTTP instead of HTTPS and to modify headers but I see no difference.
Hi there, I have exactly the same issue on my install. It’s on Fedora 41 using the container image provided by you running under Kubernetes.
I’m also using a reverse proxy (HAProxy), so I guess this is the common denominator. All the traffic is meant to pass through the reverse proxy in my case, no “direct” access using the port and the IP directly.
Here are the logs in debug + verbose mode: Plex Media Server.log (872.1 KB)
Unfortunately, I did not see much more info, so you guys will need to test with a reverse proxy on your side
As soon as I installed this update my Win 11 Plex App could not make contact with my WD Cloud EX NAS - had to revert to the previous version and it’s working OK again.
Chris had to fix the Dolby transcoding problem as that was actually higher priority.
While not minimizing the DB growth problem, I think it “ONLY” (ducks for cover) impacts those transcodes for users not using a Plex account (which I think ALSO includes managed users – or Guest users)
– AGAIN, I’m not fully briefed on what feeds the growth but I do see how it manifests in the DB. Please forgive me if I’m not 100% knowledgable.
I think they are targeting PMS 1.41.8 to finally fix the DB growth problem.
I also saw internal discussion where testing was showing the DB was shrinking on its own without any manual intervention.
If you need remedy, DBRepair will reduce the DB for you but it might take time and will shutdown PMS for the duration.
If you want the previous 1.41.6, I can and will get it for you.
It’s odd. I did the delete rows/vacuum tip and the size didn’t reduce. I then did a dump of the db then recreated the db from the dump and it finally went back to a normal size.
