I am trying to remove all references to (now uninstalled) arc-welder in my installation, see other posts. Any idea where I might dig further?
It doesn't seem like it is an issue with arc welder - the update check in the current 'stable' version is known to be broken, for a while there has been a 'release candidate' version available with lots of fixes in it. Having uninstalled it it should no longer be impacting your results.
Your OctoPrint install doesn't seem to be getting the responses back from GitHub that it expects, which is why it can't find suitable versions. It's getting 'a response' because it can still count the rate limit.
Try manually to see what response you get - the right URL is https://api.github.com/repos/OctoPrint/OctoPrint/releases. You could try it from the command line on your server with curl <URL>.
When I get the content in my browser on the PC, I seem to get the same as when I use putty on my pi:
Should I place the contents of releases somewhere on the pi?
Well then I can't explain why OctoPrint can't pick up that information when it tries to request it. Very confused at this point...
It actually seems to have an issue compairing versions, if you compare my versioncache.yaml (1.4 KB)
with yours, does mine miss information that can be traced back to what part of the checking is failing???
Alternatively, if there is some obscure way in which my 1.7.0rc2 version is failing to upgrade, is there a clean way to to download and apply the upgrade package for OctoPrint itself manually?
Yeah, you can update it manually on the command line:
~/oprint/bin/pip install octoprint==1.7.2
Your versioncache.yaml file explains the same thing the log did - it can't find out what the latest version is from the GitHub API, it is blank.
OK, that helps! Just embarrassed I did not try that myself before...
Upgrading to 1.7.2 worked flawlessly, it only took 15 seconds or so. The result:
success at last! so it seemed. Then I was suspicious that all versions were of the plugins "uptodate" (-or with an empty "message"), so I did a
~/oprint/bin/pip install octoprint==1.7.1
After that downgrade I got the good old "rate limit exceeded" from git when trying the upgrade, so wheter or not the problem is gone is not conclusive, I am still suspicious....
Tomorrow I'll know for sure. If it still will not automatically upgrade to 1.7.2, I'll do the full Octoprint install / restore backup... Unless I hear of something else I should try.
thnx for your help anyhow!
Safe mode had no effect. Same results - reports everything to be up to date when it isn't. I'll try manually updating to 1.7.1 and see if the upgrade to 1.7.2 happens like it should.
Well - the everything up-to-date mystery remains. Currently 1.7.2 is available (I just downgraded from it), but I cannot upgrade to it..... I could manually upgrade from 1.7.0rc2, but that apparently did not affect the root cause of my upgrade issue.
Octoprint for some reason cannot compare versions, even while connectivity to the current versions and git exists. I think at some point I need to admit defeat and pull the trigger on a fresh install? The cause is a mystery of dataprocessing, as I currently cannot think of other causes.
As I can print without any issues, I'll leave it in the current state for some time, in case someone ( @foosel perhaps? ) has something else to try.
Thank you for all suggestions!
I'm completely out of the ideas at the moment, sadly. The only way this could happen is if OctoPrint can't reach the GitHub API to fetch available releases. If it runs into rate limitation it should log that. No return at all would manifest in empty fields (I sometimes trigger those intentionally during tests, with a faked GitHub endpoint for update testing). But I don't see how this could happen if the Pi can access the internet. I can look into better logging here for the future, but right now I have no idea what is going on here.
Your explanation gave me an idea of how it could fail. For GitHub, I am using Oauth to authenticate, with a personal access token. If somehow something is wrong with this personal access token (expired? or renewed?), would that show in the logging? Would this explain the behavior?
Hm... I honestly have never tried that, but yes, it could, as that would most likely result in an error by GitHub on the invalid PAT instead of a release list response. Try removing the token as a test.
SOLVED
I tried to removed the token through the github settings, but could not find the menu to do this. So.... I removed the credentials in the "softwareupdate" section of config.yaml, forced the upgrade (ignoring the cache) and.... bingo:
Thanks to your explanation I found this! A long time ago, I configured OAUTH to prevent the "excessive checking" timeout (I think). It worked OK for a long time, but out of nowhere this apparently stopped working. This might also be what @R_Brian_Lindahl experienced, worth trying? If more people run into this (unlikely as noone of the frequent visitors ever observed this), detecting and throwing a dialog with the error and its potential cause might help. For now I am so happy the mystery is solved!
Including @Charlie_Powell and @Ewald_Ikemann to keep them in the loop.
PS could not find the checkbox to mark this as the solution, maybe only @R_Brian_Lindahl can?
Ah so GitHub was giving you a response, but probably one that said 'you don't have permission'. So while the API query didn't fail specifically, it didn't return the information OctoPrint was looking for.
Exactly! Unfortunately, we did not see it in the log, even though it was set to DEBUG level.
Which means we need a bit more logging there to help debugging situations like this. Roger 
edit Tracked in
Very good action,
I tried removing the credentials as described earlier... it didn't seem to work, even with "force". However, today, 2-3 days later, after a restart due to a power outage, here come the upgrades. So that would seem to be a successful result. Thanks to all who participated!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.