fix: thumbnail not updating

[jneilliii]

Fix issue with thumbnail not updating if the same file was being printed sequentially, resolves #2. This change currently only updates the image on a forced refresh, needs some kind of cache busting on the front-end I think.

[foosel]

Found an issue with the current version of OctoPrint's dev branch, fixed that on main and merged it here, plus fixed the location where the plate_number parameter is being evaluated.

Still, issues as described in OctoPrint/OctoPrint#5341 (comment)

[foosel]

To just document my findings with the A1 mini here, to first quote myself on OctoPrint/OctoPrint#5341 (comment):

Created a two plate print job, uploaded it to the A1, started print of plate 2 (still ongoing, is actually the correct one). Thumbnail showed the right plate. Disconnected, reconnected, plate 1 is shown. Checking the data I get from the printer there's no info at all about the plate number. The filename is just <project>.gcode.3mf (here: X4+Case.gcode.3mf uploaded through Orca), so no chance to match it out of the name there. Fun thing: Display of the A1 also shows the thumbnail auf plate 1. So at least things are matching up? 😅 Not sure how to proceed here though, as we simply don't seem to get the necessary data from the printer at all.

and then on OctoPrint/OctoPrint#5341 (comment)

I'm suspecting a general issue with the A1 mini firmware here, as its own display shows the wrong thumbnail (plate 1) when printing plate 2.

@jneilliii Based on the implementation, I'm guessing on your X1 you get a different file name back and that contains the plate number that then can get fetched via a regex? If so, maybe we need a model check here and only actually return the specific plate thumbnail at all if the model is not A1, and otherwise stay on plate 1 - otherwise we have a weird behaviour between what the printer shows and what OctoPrint shows, and also a behaviour change on OctoPrint's end between "print just started through OctoPrint" and "print was already running when connecting".

Here's the file I used for testing yesterday (two accessories for my new Xteink X4 e-reader, two plates & colors, case on plate 1, light on plate 2):

X4+Case.gcode.3mf.zip

[jneilliii]

I'm guessing on your X1 you get a different file name back and that contains the plate number that then can get fetched via a regex?

for the X1 the MQTT payload gives the subtask_name in most cases as the file name (or some variant that the plugin is checking) and the gcode_file is the actual file inside the 3mf that would typically match that regex pattern I was using as fallback report topic here.

I'm curious if @synman has any input on this.

[synman]

I can test with @foosel's 3mf on my A1 with latest firmware and report back

[synman]

But yes, I too am used to see the gcode file with plate # in gcode file... Subtask tends to have the 3mf name without a path or .gcode.3mf extension

[synman]

This is the case on both my h2d and a1 ... All running latest firmware

[foosel]

Maybe a firmware bug on my end then. I haven't updated that thing ever so far.

[synman]

they do have an offline upgrade process now that runs about a quarter behind their OTA updates. It works fairly well too.

A1 - https://wiki.bambulab.com/en/a1/manual/a1-firmware-update-from-SD-card
Mini - https://wiki.bambulab.com/en/a1-mini/manual/a1-mini-firmware-update-from-SD-card

[synman]

but the fact remains either way they make it very difficult for consumers to figure out what is printing if the consumer is not active when the job starts. Even with the 3mf file being extrapolated from subprocess name and gcode file, there still remains the possibility that 3mf exists with the name in multiple locations on the sdcard. BPM uses a brute force method to figure this out today and ultimately goes with the first filename match it finds.