Emby.Releases Build speed issues

[deathbybandaid]

I follow github releases for stuff via RSS, so I always know when Emby drops a new release version.

Most of the time, it can take anywhere from an hour to a couple days for the new emby-server-deb_X.X.X.X_amd64.deb to actually be available.

If I run the script prior to this build being available, the handling for this script is to exit without restarting the service. Service then has to be manually restarted, making cron not worthwhile.

What I propose is also a change of order of operations:

1. Check for new version number, If not, WARN and exit.
2. Check if the appropriate release build is available, If not, WARN and exit.
3. Download new version, if file can't download WARN and exit.
4. Stop Server.
5. Attempt Installation, attempt to restart service on failure.
6. Start Server.

[doonze]

What I'm checking for is the new .deb file to be available. Every time the script runs, what it checks for is a more recent deb (or whatever the file is for the flavor of linux your running) file. If it doesn't find a new file it simply does nothing.

If it's shutting down the server on your system every time it checks, something is wrong. It checks FIRST, before doing anything else. I also have the server stop/start functionality turned off by default, as on Debian/Ubuntu the deb package installer handles processing the stop/start automatically without any other actions needed. I originally had it in the script as I thought it was needed. I found out it wasn't. I left it in as I don't use anything but Debian, so I was unsure if other distro's need that functionality. (Some research has said maybe only Arch does).

I guess I'm unsure what behavior you're wanting to correct?

[deathbybandaid]

I think I found a possible reason for some issues updating.

At the time of writing, 4.8.0.34-beta is the newest beta release on github. When running the update script I get:

You are running Python version 3.10 ,CHECK PASSED!
Database exists! CHECK PASSED!
05/02/23 11:27:59 EmbyUpdate(self): App is up to date!  Current and Online versions are at v4.0 - Beta. Continuing...
05/02/23 11:28:01 EmbyUpdate: Most recent online version is 4.8.0.34 - Beta and current installed version is 4.8.0.33 - Beta for server emby1. We're updating Emby.

05/02/23 11:28:01 EmbyUpdate: Starting update......
Starting Package download... Please wait, this can take several minutes.
Package downloaded!
Installing/Updating Emby server....
dpkg-deb: error: 'emby-server-deb_4.8.0.34_amd64.deb' is not a Debian format archive
dpkg: error processing archive emby-server-deb_4.8.0.34_amd64.deb (--install):
 dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
 emby-server-deb_4.8.0.34_amd64.deb
Install/Update failed! Exiting!

This error is caused because the normal linux amd64 build is not listed under "Assets" (at this point in time). Updating works normally when their build process goes through.

I must have missed the update for 4.8.0.33-beta, as I was still running 4.8.0.32-beta.

What I'd propose is that the script:

• verifies that the newest release "Asset" url validates
• If not ^, then check the prior release
• issue a WARNING to the user that there is a newer release version, but at the time is not available to install.

[doonze]

Interesting. I'm betting they don't roll out all the versions at the same time, I pick up on when the first instance is rolled. I think I could add a check, my only question is, in the end, why would it matter? You can't update anyway till they roll the package did your system anyway. The script will update it as soon as it's available.

…

On Tue, May 2, 2023, 10:39 AM Deathbybandaid ***@***.***> wrote: I think I found a possible reason for some issues updating. At the time of writing, 4.8.0.34-beta is the newest beta release on github. When running the update script I get: You are running Python version 3.10 ,CHECK PASSED! Database exists! CHECK PASSED! 05/02/23 11:27:59 EmbyUpdate(self): App is up to date! Current and Online versions are at v4.0 - Beta. Continuing... 05/02/23 11:28:01 EmbyUpdate: Most recent online version is 4.8.0.34 - Beta and current installed version is 4.8.0.33 - Beta for server emby1. We're updating Emby. 05/02/23 11:28:01 EmbyUpdate: Starting update...... Starting Package download... Please wait, this can take several minutes. Package downloaded! Installing/Updating Emby server.... dpkg-deb: error: 'emby-server-deb_4.8.0.34_amd64.deb' is not a Debian format archive dpkg: error processing archive emby-server-deb_4.8.0.34_amd64.deb (--install): dpkg-deb --control subprocess returned error exit status 2 Errors were encountered while processing: emby-server-deb_4.8.0.34_amd64.deb Install/Update failed! Exiting! This error is caused because the normal linux amd64 build is not listed under "Assets" (at this point in time). Updating works normally when their build process goes through. I must have missed the update for 4.8.0.33-beta, as I was still running 4.8.0.32-beta. What I'd propose is that the script: - verifies that the newest release "Asset" url validates - If not ^, then check the prior release - issue a WARNING to the user that there is a newer release version, but at the time is not available to install. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF6BHW6MUIBBOY6MUROFBVLXEETERANCNFSM5DZF6Z2A> . You are receiving this because you commented.Message ID: ***@***.***>

[deathbybandaid]

so in the example above, I was 2 versions behind. The current logic only checks against the newest release. It would be beneficial to at least update to the most recent version possible to update to.

[doonze]

Ahhh...I see. I'd have to see what I can get from the API

…

On Tue, May 2, 2023, 4:52 PM Deathbybandaid ***@***.***> wrote: so in the example above, I was 2 versions behind. The current logic only checks against the newest release. It would be beneficial to at least update to the most recent version possible to update to. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF6BHW6RVAPRG6PE2NUVRLLXEF62XANCNFSM5DZF6Z2A> . You are receiving this because you commented.Message ID: ***@***.***>