Sickchill not showing current version

LSIO Discussion Container Support
1

I had noted for a long time that, with LSIO and updating using the recommended method of creating a new container, the Sickchill version would be incorrect or missing in the web ui.

This was supposedly changed recently as mentioned in the thread Sickchill Permission Errors. (There was an unfortunate side effect of no longer being able to use the built-in version checker from within the Sickchill UI, but at least I could tell the version easily).

But after the most recent update three days ago, again using the docker create method as outlined in the LSIO instructions, the version of Sickchill in the GUI no longer updates.

Did I do something wrong? Or did something else change?

Thanks.

Ron

2

Have you checked if there was a new version of sickchill?
Just because the container was updated doesn’t mean the app was updated. We also updates dependencies and OS packages when there are new releases.

3

in addition to what saarg says, you say you’re using the docker create method from our instructions, but are you properly following the docker create update instructions?

4

Yes I have. The version showing in sickchill (since I updated first after the change was made) is ebcb4d616200cde7fba8e5b5f4601ecbcd402c1d

There was a subsequent update to:
e9ccfe43f7515ddcacb872f3dc679694ad707481

which I accomplished, but the version showing did not change.

5

Yes. That is the section titled Updating Info

6

@saarg

Any suggestions as to how to figure out why it is not working for me?

I’ve checked the file at /app/sickchill/.git/HEAD which contains the correct version, but the version from the preceding update is what is showing in the sickchill UI

7

just checking, you’ve repeated you followed the instructions a couple times now and 90% of the time with our userbase, it turns out to be that they follow SOME of the instructions but not all.

i even tried spinning up a fresh copy and can’t replicate your issue. Previously you asked if you’re doing anything wrong but outside of saying “I followed the instructions” you haven’t shown us anything.

What exact commands are you running when you try to update, did you verify the commit isn’t just cached. HELP US HELP YOU :slight_smile:

image
image948×138 14.2 KB

8

@driz

Thank you for getting back to me. I am new to this forum and not always certain exactly what to supply.

The very first time I did this, when I was having what appeared to be a Permissions problem and did not realize it was in issue with LSIO, I uninstalled and reinstalled Docker on my synology NAS, using the Synology tools, and selected to remove everything (after saving the config folders for Sickchill and also nzbGet which I am also running.

Then I restored both programs; restored the config folders, and everything was running OK.

In addition, the Commit and Version lines for Sickchill were showing the correct (for that time) values.

There subsequently was a new commit for Sickchill, and I updated using the recommended commands, but the Commit did not change, and the Version was missing as seen in the screenshot below.

At one time, I also tried an update using watchtower, but that did not make any difference.

These are the commands I run and the responses (I recorded a log as I repeated them):

The only difference between this time and the first time I updated to this version, is that the first time docker pull command actually downloaded an image. There hasn’t been an image update for the past few days since, so this time the response was "image is up to date… "

docker pull linuxserver/sickchill
Using default tag: latest
latest: Pulling from linuxserver/sickchill
Digest: sha256:097f75d0c4dc47f58bc32f51bdfd0811b19ac972e85ae6f146cf1c6cdde221c5
Status: Image is up to date for linuxserver/sickchill:latest
root@DS718:~# docker stop sickchill
sickchill
root@DS718:~# docker rm sickchill
sickchill
root@DS718:~# docker create \
>  --name=sickchill \
>  -e PUID=1024 \
>  -e PGID=100 \
>  -e TZ=America/New_York \
>  -p 8081:8081 \
>  -v /volume1/docker/sickchill/config:/config \
>  -v /volume1/nzbGetDownloads:/downloads \
>  -v '/volume1/video/TV Shows':/tv \
>  --restart unless-stopped \
>  linuxserver/sickchill
2ac617cc8ab09d4b7e4f55f0a44288acfc8e54acc0a41cf6fd030bfe960c953f
root@DS718:~# docker start sickchill
sickchill

From the Sickchill UI:

image

I also executed the following to get the current sickchill LSIO version:

root@DS718:~# docker image ls
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
linuxserver/sickchill   latest              7267610af1cc        3 days ago          504MB
linuxserver/nzbget      latest              7c6a7d69dd06        12 days ago         193MB
containrrr/watchtower   latest              609dda97f756        7 weeks ago         14MB
root@DS718:~# docker image inspect  7267610af1cc | grep build_version
                "build_version": "Linuxserver.io version:- v2020.05.08-4-ls37 Build-date:- 2020-05-08T08:50:15+00:00",
                "build_version": "Linuxserver.io version:- v2020.05.08-4-ls37 Build-date:- 2020-05-08T08:50:15+00:00",

Please let me know what else I can tell you, or do.

Thank you.

9

if you open that same page in an incognito mode browser, do you still see the same commit?

I just went and pulled a 14day old tag, then removed my tag, went through the update process and it worked fine. your 3 day creation seems pretty accurate for the latest build and as you know, that build_version is the latest as you mentioned previously. This leads me to think the commit you’re seeing is a cache issue, hence the incognito test.

let us know (feel free to try other browsers too if you like)

10

@driz
Tried a different browser in incognito mode and the UI commit appearance looks the same.

11

interesting, i wonder if this is something specific to syno then. We only have 1 team member with a syno and i’m not sure if he is ready for testing on it yet. Might be best to come into discord and see if anyone with a syno device has ever experienced your issue.

to be clear though, i think you already realize this is a cosmetic issue

12

@driz I do realize that it does not affect the function of Sickchill. But it does affect how easy it is to tell what version I’m actually running.

To figure out now what version I am running, I have to SSH into my synology, and either do a docker pull command, or navigate to /app/sickchill/.git/HEAD in the running version and inspect that. Not as convenient as looking at the sickchill info and then checking the sickchill git page. (and also not as convenient as the built-in version checker in Sickchill which won’t work anyway).

Unless you have another idea, since it worked once, maybe I’ll try uninstalling/reinstalling docker, and then see what happens after the next SC update.

13

I get it (i mean not really, i dont pay attn to that, i just docker pull and rely on that) but you have an issue we can’t replicate that no one else is facing, it’s difficult to troubleshoot a 1-off.

14

@driz Some experimentation this morning suggests and issue with the sickchill config.ini

  • I cleared out the docker/sickchill/config folder
  • “updated” the container to the previous image.
  • proper version shows in UI (sickchill created a new config.ini)
  • copied back to the config folder everything except config.ini
  • updated to this mornings new image
  • again, the UI showed the updated correct version.

So now I need to compare the two files and see if I can figure out where the difference is.
I’ll do that later today.

Thanks for your help and the work you’ve done to help me work through this issue.

Ron

15

great news, let us know what you find!

16

Definitely a work in progress.

I made some changes in settings – setting up an NZB search provider; post-processing stuff, etc.

I did this using the sickchill GUI and saving it.

Then I restarted Sickchill.

What I notice is that initially, the Sickchill Info panel showed Commit and Version similar to what you showed in your screen shot. But after making these changes in Settings, The Version is no longer present – as showing similar to my screenshot.

The differences between the files seem trivial – various unused parameters showing NONE vs ""

We’ll see what happens with the next sickchill update.
Curious.

17

@driz :frowning: There was a Sickchill update this morning. Ran through the Docker Create update method and, although the image appears to have updated, as evidenced by the docker image inspect command, the commit level on the Sickchill Info page remains set to the previous commit (i.e. the commit created when I created an image with no config.file present).

For me, it seems there is something about the process of editing the config.ini file that is interfering with the ability to:

  • Display the version (i.e v2020.mm.dd-n)
  • Update the Commit

Of course, there could be some other interaction of which I am unaware.

In your testing, did you edit the Settings at all? Or did you just install/update using different tags?

18

Look, our whole process is automated.

We check the endpoint (hourly IIRC) and grab the release version from the sickchill tag here with:

curl -sX GET https://api.github.com/repos/SickChill/SickChill/tags \
	| jq -r 'first(.[]) | .name'

So we’re not pulling from head, but instead checking out a specific version.

They’ve released two things today already within two hours of one another, an we’ve produced two containers.

To be honest, if you’re that obsessessed by specific commits and intend to pin your versions to a specific git commit or are a dev and need a dev environment then you really she be controlling your own environment rather than relying on an automated docker pipeline and running latest.

Whilst we can tell this is something that is clearly troubling you, I think we’re struggling to understand where you’re coming from in terms of needing to know to that sort of detail?

19

To update the .ini file with version each time, which is what you’d need is not something I imagine we’d be too keen on as it’d mean altering everybodies main config file at each container update, if that file gets corrupted/damaged then they’d be a lot of unhappy people

20

@chbmb I understand the undesirability of updating the config.ini file in your update process, and would not recommend that.

Here is where I am coming from:

Up until a few weeks ago, the update process was different. Then I started to see errors which I reported.

According to @aptalca in Sickchill Permission errors

People kept complaining that sickchill didn’t display the current version in the webgui (unless you used the built-in updater). So we fixed it. The way we fixed it (git checkout tag) doesn’t work with the built-in updater, hence the errors.

But that is not happening. The current commit and version is only showing the very first time the container is created. After that, the commit stays the same and the version disappears.

Another side effect for me is that the download for the update is now much larger (by about 4x) which is an issue for me on a slow DSL connection.

For the moment, for me, it seems the update method LSIO was using a month ago was “better”, but I understand that may not be the case in general, and it may be better this way in that the built-in updater is disabled.

Part of my confusion here is that the commit/version display seemed to be proper (and changes appropriately with updates) until I edit the settings. It is only after I changed the settings (which writes something to the baseline config.ini file), that things freeze up.