Temperature graph missing history for higher extruders (only visible in 1.10.0rc3)

[smurfix]

Is your feature request related to a problem? Please describe.

After an UI reload (or when opening Octoprint on another host after starting to print), the temperature graph looks like this:

Describe the solution you'd like

Octoprint should remember all temperatures, not just the first extruder's.

Describe alternatives you've considered

No response

Additional context

No response

[jneilliii]

IIRC you are running OctoPrint 1.10.0rc3?

[foosel]

This sounds rather like a bug, so please share a system info bundle.

In general it's always a good idea to share one with a reproduction if you stumble across some behaviour that you want to see changed, even as request, as it very much increases the likelihood that I can actually reproduce the behaviour and see what I can do about it.

Help me to help you instead of making me constantly ask for details, thanks.

[smurfix]

@jneilliii Yes.

@foosel Here it is, during a print that exhibits the problem.

octoprint-systeminfo-20240330105323.zip

---

Bundles:

• octoprint-systeminfo-20240330105323.zip

edited by @github-actions to add bundle viewer links

[foosel]

So this is actually a bug, but not a regression in 1.10.0rc3. OctoPrint actually does keep the full history. The problem is that the graph doesn't render it right on load, because at that point it hasn't yet received the information on the configured printer profile, thus falls back on the default values, and therefore refuses to draw anything but the first extruder and the bed. I haven't confirmed it yet, but I'm pretty sure the chamber temperature would be affected here as well.

It's not a regression because it was always behaving this way, it simply didn't show because so far the temperature graph always started at the time of the reload and no history at all was rendered, that's a new feature in 1.10.0.

I'm scheduling a fix for this for 1.10.1 - it's a bug, but frankly too minor to justify yet another RC round on its own.

[foosel]

Sidenote, please don't unpack and repack the system info bundle, and also:

octoprint.version: 1.3.12+g91435d3cd.dirty

this version that your instance is reporting there is definitely not 1.10.0rc3 even though the code might be, and that commit is unknown in OctoPrint/OctoPrint and apparently from a fork of you (which would also explain the complete outdated version that's being reported).

When opening tickets of any kind, make sure you can reproduce whatever you are opening them about on an official release, not any forks, especially not dirty ones.

[smurfix]

Sidenote, please don't unpack and repack the system info bundle

The problem was that one of the log files was too big. I had to truncate it.

Sorry about the version, that was my installer dropping the tag on the workshop floor. The code itself is 100% official Octoprint. I'll fix that nonsense in time for the next bug report.

[foosel]

Gotcha.

I've also just pushed a new version of the bundle viewer that now supports the actual bundle being in a subfolder (which was the reason why I mentioned it), so IF you should have to repack things in the future due to size reasons, it should now no longer cause issues with the viewer.

[foosel]

Good news I guess, we need another RC for 1.10.0 after all, and I'll include this fix in that.

[foosel]

Fixed in 1.10.0rc4.