New release candidate: 1.3.10rc1


After quite some time in development, I’m happy to present you the first release candidate of the 1.3.10 release!

The changelog is on the lengthy side again - don’t let that scare you though 😉

Here are some highlights from the release notes:

  • The OctoPi Support Plugin is now the Pi Support Plugin, will be enabled when a Raspberry Pi is detected as the underlying hardware platform and report on undervoltage or overheating situations.
  • Added the Backup & Restore Plugin: The new bundled plugin will allow you to make a backup of your OctoPrint settings, files and list of installed plugins, and to restore from such a backup on the same or another instance. This should make migration paths from outdated installations to newer ones easier.
  • Added the Anonymous Usage Tracking Plugin. Tracking will only take place if the plugin is enabled and you’ve decided to opt-in during initial setup (or enabled it manually afterwards, through the corresponding switch in the settings). The tracking data will give insight into how OctoPrint is used, which versions are running and on what kind of hardware OctoPrint gets installed. You can learn about what will get tracked (if you opt-in) on Please consider helping development by participating in the anonymous usage tracking ❤
  • Added the Application Keys Plugin: The new bundled plugin offers an authorization for third party apps that doesn’t involve manually copying API keys or using QR codes. Third party client developers are strongly advised to implement this workflow in their apps. Read more in the documentation. Thanks to Aldo Hoeben for the idea and initial implementation!
  • Automatic updates in outdated environments are no longer supported. After repeated issues out in the field with ancient installations and ancient underlying Python environments, OctoPrint’s Softwareupdate Plugin will no longer allow automatic updates of itself or any installed plugins via the Software Update Plugin if a certain set of minimum versions of Python, pip and setuptools isn’t detected. The current minimum versions reflect the environment found on OctoPi 0.14.0: Python 2.7.9, pip 9.0.1, setuptools 5.5.1. See also the related FAQ entry.
  • OctoPrint will now try to protect/educate more prominently against the dangers of opening up OctoPrint on the public internet via various new explicit warnings in the UI as well as a new notification that pops up if you log in from an external IP address. Thanks to the new bundled ForcedLogin Plugin OctoPrint will also no longer be accessible in a read-only way by anonymous guests - to get back the old behaviour, disable the plugin.
  • Added detection of EMERGENCY_PARSER firmware capability and if it’s present add M108 to the cancel procedure, to cancel blocking heatups.
  • Improved GCODE analysis speed
  • … and various further improvements and of course bug fixes.

There’s also a small heads-up for plugin authors:

OctoPrint has updated its sarge dependency. The new version 0.1.5 has a small breaking change - the async keyword was renamed to async_ for compatibility reasons with Python 3.7. This might also affect your plugin if you happen to use sarge somewhere therein. If so, make sure you to update your plugin to use async_ instead of async (or just use OctoPrint’s own octoprint.util.commandline.CommandlineCaller class which takes care of this and various other things).

See also here for the sarge changelog.

You can find the full changelog and release notes as usual on Github.

Special thanks to everyone who contributed to this release candidate, especially @bradcfisher, @eyal0, @fieldOfView, @gdombiak, @gerfderp, @hashashin and @tedder for their PRs.

If you are tracking the “Maintenance RC” release channel, you should soon get an update notification just like you are used to from stable releases.

If you want to help test this release candidate and aren’t yet tracking the “Maintenance RCs” release channel, you can find information on how to switch in this guide (also linked below).

If you are not interested in helping to test release candidates, just ignore this post, 1.3.10 stable will hit your instance via the usual way once reports indicate that it’s ready 😊

Please provide feedback on this RC. For general feedback you can use this ticket on the tracker. The information that everything works fine for you is also valuable feedback 😄 For bug reports please follow “How to file a bug report”.

Depending on how the feedback for this release candidate turns out, I’ll either look into releasing 1.3.10 or fix any observed regressions and push out a new release candidate ASAP.


This is a companion discussion topic for the original entry at


If you use Cura 3.5 or 3.6, you can help test this functionality. A beta of the OctoPrintPlugin can be downloaded here:
Once downloaded, drop it into a running Cura window and it should install.

Now, provided you have an OctoPrint 1.3.10 installation, you can request keys like this:

(edit: corrected link to plugin)


The link doesn't seem to work, sorry


Installed, anonymous tracking enabled, will soon try a backup/restore (after print completes). So far so good , great work!


Thanks, I have corrected the link in the comment.


Hi there

I have a question, mainly for curiosity purpose. Does the data of the anonymous usage would be available publicly ? I mean, basics and global stats like how many instances are running, on witch hardware/OS Octoprint is running, how many successfull/failed/aborted print so far, etc...

Just some almost-live metrics, absolutely anonymous, for all the curious peoples around here

Oh and BTW the backup plugin is just one of the greatest idea so far ! can't wait to test it


@gege2b currently not, but the long term goal is to have some public stats panel online somewhere that gets refreshed hourly or something like this. I simply haven't yet gotten around to looking into it yet (and refuse to buy the official Kibana reporting tool for this purpose so have to build something myself from the looks of it).


cannot enable or disable that shit anonymous tracking. No Button works. Now I have to reinstall octroprint completely. thanks for untested software. Genius!


Firstly, don't be rude. Secondly, are you not familiar with what a release candidate is for?


Yeah, I learned it. Dont ever install a release candidate!


I installed successfully.
Needed to reboot the Pi though, because after the automatic server restart there was an error due to "pip" missing, therefore no plugins were visible. After the pi reboot everything was fine.

Anonymous Usage Stats plugin is there and can be configured. No problems with that so far.

Now testing print. First impression is good, but GCODE Viewer is not working anymore. The "Reload" button is grey.

Any ideas what might be the cause of that?


There's nothing wrong with installing a release candidate, and in fact the feedback @foosel gets is invaluable, and contributes to a stable release. But one must understand, that an RC is not a stable release, and there very well can be problems.

@FanDjango this is unfortunately the wrong place for feedback, check out :slight_smile:


Its not that it is unstable, I cannot start it without giving the mandatory "configure Anonymous usage Tracking" a go.l Which is impossible, as all the buttons dont work.

So I am trapped in the first window. The "mandatory step". You may see it as "nothing wrong".


At this point there are two options.

One is to open a proper bug report, provide the requested log files and stand by to help iron out this issue. Which is btw what you should always be prepared to do when running a release candidate since the whole point of these things is figuring out stuff that breaks for people which only breaks under specific circumstances that I didn't encounter during my excessive testing.

The other is that you manually roll back to the previous version. How to do that is linked from the release announcement. That will get you going again. It will also guarantee that nobody will be able to figure out what went wrong in your case, since based on the first results of the "shit tracking" combined with the feedback so far received on that RC you are pretty alone with this specific problem.

Regardless of what option you choose, you should think long and hard about the attitude you display towards the labor of hard working open source developers. If you think running into such an issue is frustrating and justifies this kind of attitude, try being an open source developer having to cater to entitled users with bad attitudes for a couple of years.


I update my octoprint and I heave a problem with connect :frowning:
When I update octoprint restart and now I heave in connection section only button "Disconnect"
Restart Octoprint again "Disconnect" but printer is not connected :frowning:


See here. Issue between ForceLogin plugin and no configured access control. Disable the ForceLogin plugin for now until rc2 is released which contains a fix for that.

At everyone commenting here, as clearly stated in the blog post, if you run into any issues or otherwise want to give feedback, do that on the bug tracker, NOT HERE. That way you'll also actually see what has already been reported and possible workarounds for that or the possibility to help in analysis by providing your own logs, setup and reproduction steps.

The goal of RCs is to iron out issues out in the field and for that I need collaboration from people who run the RCs. The goal is NOT to get you new stuff faster.


Have you tried to clear you browser's cache ? As long as I can tell, disabling anonymous tracking should work fine (I disabled it on my instance for testing, then enabled it again 'cause I trust @foosel enough to give her my anonymous datas )

Release candidate are subject to various bugs, that's why they're called like this. There is no reason to be as rude as you did


Clear browser cache seems to work. What I do not understand why to make a unnessessary feature "Mandatory" in a RC.

I already knew that when I programmed (and built) my first Computer in 1975.


The feature isn't mandatory, the question whether you want to enable it or not is. If you've ever been in charge of any kind of software that ran on end user systems and had a large mostly anonymous user base, you should know that from a certain size of a project usage tracking is not even remotely "unnecessary" and in fact very necessary to keep things manageable. You should also know the difference between a stable release and a release candidate. And you should have manners.

And if I were you I'd now stop commenting before I continued to put my foot into my mouth.


Maybe you do not know your own program. This feature IS mandatory, you cannot advance to the main screen before you accepted it. And this does not work, because the buttons dont work.

BTW: The fun with the cleaned cache only lasted 10 minutes. Know I do not get a connection to the server anymore.