@driz
Tried a different browser in incognito mode and the UI commit appearance looks the same.
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
@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.
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.
@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
great news, let us know what you find!
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.
@driz 
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?
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?
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
@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.
Sure, but why is it so important? We’re not pulling specific git commits, we’re pulling specific tagged versions from here.
and our tags match that, essentially a completely different versioning system from git commit.
Ease of telling whether I need to update:
With the current commit level showing in the UI, and the ability to check for updates from within the UI available, I can tell immediately when I open the UI whether or not there has been an update. There is a pop-up that appears.
Without that, I need to
- start up Putty
- SSH into my NAS
- sudo -i to root
- execute a docker pull
or
- navigate to some page on the web and see if the listed latest commit time matches my memory of when I last updated.
Then perhaps suggest sickchill implement a way of displaying the release used?
They do that now by changing the entry in config.ini when you use the internal updater. Unfortunately, to run Sickchill on my Synology, I have to Docker, so can’t take advantage of that.
in order to version control, we do git checkout tagname so the HEAD is detached. Sickchill’s built-in updater can’t check which branch it is in because it is not in any branch, as it is detached.
Nothing we can do about it.
The other way you could approach this is fork/make your own container, and build from GIT commit.
Is that hard to do starting with practically no knowledge?
I suspect there’d be a steep learning curve for me to be able to do that.
Easier for me, personally, with my current knowledge state, would be if you went back to doing the updates the way you were a month or so ago; then I could write a script to update my config.ini file. There’d also be the advantage of a smaller download.
Yes I think from what you’ve said you’d find it difficult.
No, we’re not changing anything on our end, we’re not going back to doing git commit builds. In the last 2 days sickchill have released 5 different versions.
Look how many commits have occurred over the same period.
Every single build we do, is built on our own hardware. Personally I have 8 cores of my server dedicated 24/7 to running a virtual machine to build the docker images, other members of the group contribute even more that that.
There’s no reason for us to dedicate our hardware, power use/money to building what would be 12 releases so far in the last two days because it’s easier for you.
The download size is immaterial, as it will be so small it’s insignificant and I’m not quite sure where you’re getting this metric from.
Consider the matter closed.