That makes sense. If you don’t mind me asking, how long does a beta version be a public one? I never monitored how long.
Most transition from beta to public within a couple days.
The thought here is to make 100% certain everything is OK (what Beta is all about) before unleashing on everyone.
Some times, there are emergency fixes which go to Beta & Public within hours of each other / if not immediately.
Ok, got it. I’m still going to troubleshoot the plexupdate script and see if the developer helps me. I set it to force reinstall the latest version. I ran it manually earlier and no issue. I’ll wait for the scheduled update to kick during the morning and check if the PMS is accessible after I wake up.
Most of us have weekly crontab jobs to run apt-get update && apt-get -y upgrade.
When PMS updates, remember, it will self-restart if running at the time. The newly installed version is immediately available.
Right. It’s just that the plexupdate script is smart enough to see if the PMS is being used to proceed with the update. If it is, then it skips the cycle and updates it on the next one.
Fair enough.
Being the package, inside the DPKG mechanism, the installation has already been commanded by time I’m aware of what’s happening.
I can only see if it’s running (I could see if it’s in use but that doesn’t help us at all).
On SSD-based systems like mine, I’ve been able to install updates while actively being used without anyone even noticiing.
Ahh, it’s that fast. If all else fails with the plexupdate, I’ll surely fallback to using a weekly crontab job, for sure.
@ChuckPa That’s only going to be playback, right? Any in-process recordings in the LiveTV/DVR will be interrupted?
You are correct. Any recording will be interrupted. Playback, because of how the players buffer, is stateless.
Thanks, Chuck.
@ChuckPa I decided to follow the autoupdate for the public channel and the issue happened again a few hours ago when the plexupdate udpated to “plexmediaserver_1.23.6.4881-e2e58f321_amd64.deb”. I’m still waiting for the developer’s reply but I just wanted to update the thread.
@ChuckPa I’ve been discussing the issue with the developer here and it’s proving to be harder to troubleshoot because he does not have a Debian system to test. Can you check out the thread and see if you have any inputs? We’ve checked all versions/permissions for both of my systems and they are 100% identical. Basically, the issue only happens when his cronwrapper script is run under cron.daily. If I put the cronwrapper script in crontab, the scheduled update works flawlessly.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
