random
SHA-1 is my favorite random number generator
except for ChaCha20
(Side-note for everybody, please include the commit hash when posting version numbers [e.g. version an issue is happening on, last known good version prior to a regression etc.], it makes our lives dramatically easier, which means your issues get investigated quicker!)
So, has there been a case where a hotfix (or whatever) was applied to a release and only the commit ID changed, but not the build number? That would be even more confusing (and would likely not trigger any update prompt).
@Ridley - FYI, the forum post and in-app alert are for 1.29.1.6260, but the version available to download from https://www.plex.tv/media-server-downloads/ is still 1.29.1.6241. I assume this is just things catching up with each other?
FWIW, hashes arenât listed on the Forum announcements post, and they arenât listed in PMS itself, either in the in-app Update notification or Settings â General.

It was edited from 6241 earlierâŠ
Nope, thatâs not possible; a build number refers to a specific build, produced at a specific time, from a specific commit.
OK, one more thing then, and forgive me if this was already answered (it probably was). If a fix was applied in letâs say version 1.34.2.7445, and later version 1.34.3.7442 is released, does that mean that fix is in version 1.34.3.7442 or not?
Not automatically, but generally if we backport a change to an older release branch, itâs either already in any newer release branches, or is backported to them at around the same time.
The latest package listed on the Announcements section should be the current release with all previous fixes merged in from earlier releases.
1.29.1.xxxx has all the fixes from 1.29.0.xxxx +some. Otherwise itâs confusing for the people downloading the software.
xxxx doesnât matter unless itâs a subsequent release of the same eg: 1.29.0.
No offense, but I donât think youâve read the whole thread. What you just stated is not necessarily the case, as previously established. Letâs leave it at that.
No offence but Iâm pretty sure Iâm stating how it should be. Key word is âshould beâ in the last post.
Patch .1 is going to have all the fixes that patch .0 has plus any other fixes. Unless the release notes state otherwise then itâs a complete cluster â â â â for the people downloading and using the software. PERIOD.
Ever hear of the term regression? Why on earth would any software company release a fix and then in the subsequent version not include it? Unless it is specifically dropped for a reason it makes no sense.
I genuinely love that phrase because it can convey nearly-opposite meanings.
- âShouldâ can mean âI believe that it is currently so.â
- âShouldâ can also mean âIt would be better if this was the case.â
Another example today of a build being published (6313) where no release notes are included saying what changed between it and the previous build (6276) ![]()
@anon5074910 nailed it. I came to ask the same question. The 6276 beta is running well for me, but now the 6313 changes that are in the public release are a mystery.
I see its been edited to add the changes â thanks!
Well they added changes, but removed the âpublicâ version 1.29.1.6313 and replaced it with a beta version 1.29.1.6316 and yet the (plex pass version) on the downloads page is only offering 1.29.1.6276
I was offered the beta 6313 update, but when I clicked on the download button nothing happened and now it says 6276 is the most current. Weird goings on.
Iâm now getting offered 6316 in the beta channel, and a file with the correct version name does download (for Linux), but Iâm waiting this one out for a while.
So, here we go again:
1.30.0.6359-1185e28d9, October 31, 2022
1.29.2.6364-6d72b0cf6, November 1, 2022
Anyway, I donât want to get into the whole âbuildâ discussion again, but if someone could expand on what this means:
- (PlexMatch) Add support for pattern matching (#13899)
Also, what is this fix about, since this has always worked:
- (Scheduled Tasks) Perform periodic metadata refreshes on TV shows too (#13920)

