Emby rockon update (2)

Rock-ons
1

Hello to the community.

I recently updated my Rockstor installation from Centos to Opensuse and it’s going fine.
On Centos I had Emby installed outside of Rockstor, but with the upgrade I decided to go with the Rockon version which works pretty good as well.

I wanted to know whether the steps mentioned by @Flox here are still relevant or there has been any development I have missed.

With the previous installation, updating Emby was as simple as shutting down the server and running installation manually.
From what I get; I now have to re-install the rockon and then re-enter all of my shares?
And what happens to the libraries I have already setup?

Thanks in advance.

2

@Sky12016 theoretically the removal and reinstall is the process to get the latest version for this Rock-on.
However, you can also install the Watchtower Rock-on that allows you to have this process executed in the background (you can also have Watchtower check this periodically).
I can’t check now but I think the license is stored in the Config share you specified and hence will remain in place during a reinstall (manual or otherwise).
Sorry for the brevity here but I am on my phone right now.

2 Likes
3

A post was split to a new topic: Emby playback issues

4

Hi @Hooverdan .

So you say that I won’t have to re-enter any of my libraries? What about the shares? Will I have to re-expose them to the Emby Rock-on?

Cheers!

5

If you use the Watchtower Rock-on, it will preserve all the settings (i.e. shares mapping, etc.). Since you have a share that stores the config, your library should remain intact whether you use Watchtower to perform the update of the image in the background, or you follow the manual uninstall/install process.

On the manual re-install process, I have not done this in a while (since I’m always using watchtower), I believe, in order to get the latest image pulled, a quick uninstall/reinstall (using the WebUI) is not going to do the trick, as the docker run command looks whether the underlying image to the container it’s building already exists. If the docker image is still there (after the WebUI uninstall), then it will just use that image and not update it (update: see following response to thread). So, you would first run the uninstall through the WebUI and then from the command line:

$ cd /opt/rockstor
$ poetry run delete-rockon 'Emby server`

then run an update on the Rock-ons list (upper right hand corner) to get the Emby server definition re-populated. Finally, you can run through the installation process again.
The downside of this is that it removes all the Rock-on settings from the database as well, so when you reinstall, you have to enter them again. But if you copy the table of the summary screen you find under the little “wrench” icon into a document (I use word or g-docs) before the above de-installation procedure you should be able to just copy and paste the settings back into the fields (the shares you will have to select).
But all your settings on the config share will remain preserved, so after a reinstall you should be up and running without any issues.

6

@Sky12016 I stand corrected. While it’s correct that the docker run command uses an image if it’s already there, @Flox pointed out to me that during the install using the WebUI we are actually executing a docker pull to ensure there is always an updated image used to build the container and deploy the Rock-on. I found it in the coding and it can be seen here where this is done:

So, an uninstall/install via the UI will do the trick actually, and aside from the share list, other parameters are usually retained as “pre-populated” on the reinstall.

In case you wanted to take the manual route, I hope I caught you in time. Otherwise, my apologies for creating a bit more work for you.

2 Likes
7

Reinstalling was always a painless procedure for me.
I only had to re-add the additional shares, IIRC.

3 Likes
8

Hello @aremiaskfa .

I am a bit puzzled with your response.
How many shares do you have to re-add every time you update Emby? I have 5 or 6 and I have to restart the Emby rockon for every single one of them so that takes some time!
And given that Emby rolls out updates roughly every month how is it you don’t remember the process?
You just leave Emby not updated or do you also use Watchtower rockon?

Kind regards!

9

I had used Emby only for a month or so.
When I updated my rockons in general, there weren’t any problems.
While I wish I there was a simple one-button solution, it works OK for my use-case.

Indeed that is annoying, but there is a trick. Add the share, click next, then click previous. Now add the next share. Rinse and repeat.
The added shares are remembered in-between.

EDIT: I did not know about the watchtower. I will try it!

1 Like
10

Hello girls and guys once again.

I am afraid the watchtower automatic update did not go as planned.

This is the Watchtower settings:

watchtower_settings
watchtower_settings787×234 19.3 KB

And this is emby server (rockon):
emby_version

Apparently I am missing something.
Maybe the label?

1 Like
11

Hiya,
yes, I think the label you need to add to emby Rockon should look like this:

com.centurylinklabs.watchtower.enable=true

like here:

image
image1049×286 17.5 KB

1 Like
12

Hi @Hooverdan

I suppose you mean the Watchtower Rockon; not the emby one right?

13

No, you need to add the above label to any Rock-on that you want Watchtower to monitor. I should have been a little bit more clear about that:

https://containrrr.dev/watchtower/arguments/#filter_by_disable_label

Incidentally, while it’s not always recommended (depends on your appetite for risk), I have the label on all of my Rock-ons, including the Watchtower Rock-on. Watchtower uses that label to decide whether it should update (or not) that container (if you don’t add the label, it assumes that it’s set to “False” as that’s the default).

2 Likes
14

Hi again.

I have added the label to emby rockon.
But I can’t find a way to change the cron setting of watchtower in order to test whether it’s working.

From what I read I need to edit docker-compose.yml but I can’t find the specific file. Where is it?

15

If I remember correctly, when you stop and restart the watchtower Rock-on it will check right away and then follow the CRON schedule that you specified during the installation.
Since the Rock-ons use the docker run construct and not the docker-compose function there is no yml file to edit

2 Likes
16

I was finally able to check on my own system. Looks like if a CRON job is set, it won’t do the update upon starting the container.

If you want to see whether the update works right away, here is what you could do:

  • assuming you have maintained the label on the emby Rock-on (or any other)
  • stop the running watchtower Rock-on
  • go into terminal and force a one-time check/update (container will be brought up, check is executed, anything updatable is taken care, then the container is destroyed again) using this command line (taken into account 2 of the parameters that you maintained in the Rock-on config above, to be consistent). Copy the entire 5 lines into the terminal window and hit Enter (sorry, if that seems trivial, but I remember struggling with the command line when I first started on Linux):
docker run --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
-e WATCHTOWER_LABEL_ENABLE=true \
-e WATCHTOWER_CLEANUP=true \
containrrr/watchtower --run-once

It will take a few seconds for a log to appear, and if there is a new image, it will take a minute or two to complete the update. Once everything is complete, it will exit the container, and you’ll be back at the command prompt.

On the example of a new netdata docker image being available today, the log could look something like this:

time="2023-06-04T17:53:22Z" level=info msg="Watchtower 1.5.3"
time="2023-06-04T17:53:22Z" level=info msg="Using no notifications"
time="2023-06-04T17:53:22Z" level=info msg="Only checking containers using enable label"
time="2023-06-04T17:53:22Z" level=info msg="Running a one time update."
time="2023-06-04T17:54:02Z" level=info msg="Found new netdata/netdata:latest image (3e6578793901)"
time="2023-06-04T17:54:09Z" level=info msg="Stopping /netdata_official (657cac6c4516) with SIGTERM"
time="2023-06-04T17:54:15Z" level=info msg="Creating /netdata_official"
time="2023-06-04T17:54:21Z" level=info msg="Removing image 4ff3f5ca4f8c"
time="2023-06-04T17:54:22Z" level=info msg="Session done" Failed=0 Scanned=9 Updated=1 notify=no
time="2023-06-04T17:54:22Z" level=info msg="Waiting for the notification goroutine to finish" notify=no

Hopefully, in your case the emby server image will show up in the log.

On a side not, if during the one-time update it does not see anything new to update, you would see the message level=info msg="Session done" Failed=0 Scanned=9 Updated=0 notify=no in the log output.

After the above process, if you want Watchtower to periodically check for updates, just restart the watchtower Rock-on and forget about it :slight_smile:

Or, you stick with the manual method as described above, and whenever there is a new release of an Emby Server docker image, go into the terminal and execute the above command (easier now, since you’ve maintained the watchtower label on the Rock-on, otherwise you have to specify the docker container to check for updates of the underlying docker image).

Let us know, how you get on with it.

2 Likes
17

Hi.

Instead of going into all that cli rumble, I just uninstalled the Watchtower rockon, I installed from the beginning adding the correct cron settings, and afterwards I added the label com.centurylinklabs.watchtower.enable=true
to both the emby and watchtower rockon.

I now have my emby server up to speed!

Thanks for your help!

3 Likes