[Feature] Allow Obico to Reprint from GCode stored on Octoprint-server if not available on Obico-server

[puterboy]

Currently, it seems that Obico can only "reprint" if you originally had uploaded the GCode to Obco-server but not if you had launched the print from Octoprint.

It would be great if the 'Reprint' feature would work more generally so that:

• If the original print was uploaded to Obico, then the reprint would use the GCode stored on the Obico-server (current behavior)
• If the original print was launched from Octoprint, then the reprint would use the GCode store on the Octoprint-server

This should not be too hard to do since Obco is already using the Octoprint api to allow users to browse and launch Gcode files stored on Octoprint from the "Printers" tab when you click on "Octoprint" under the heading "Open G-Coe File to Start Printing"

The suggested implementation logic would work roughly as follows.

1. Use the resident_printer_id stored in the app_gcodefile table to determine if the GCODE was uploaded to Obico or started with Octoprint (and then this is the Printer ID) [From my chat with @apex, I believe this is what the field does]
2. If the GCode was uploaded to Obico, then continue with current behavior
3. If the GCode was printed directly on Octoprint, then use the url field in the app_gcodefile table to launch the print from Octoprint (using the api similarly to how it is done now when you browse the GCode tree on Octoprint under "Open G-Code File to Start Printing").
   If GCode file no longer present return a "file not found" error.
4. Optionally, check the current stored GCode file size for consistency to make sure GCode file is the same.

There are multiple reasons why one may want to load your initial file from Octoprint but later want to reprint from Obico.
For example, most of the time I launch my printing from Prusa Slicer which has an automatic upload to Octoprint (and I don't think it can upload directly to Obico).

At the same time, I use Obico to monitor prints and I prefer it's print history to Octoprints -- so I often use Obico to identify a historical print that I want to reprint.

Thanks!

[kennethjiang]

We don't have the re-print button for gcode files in octoprint or klipper because there will be too many edge cases, such as:

• The gcode file is a/b/c.gcode in octoprint/klipper, but it was later deleted.
• The gcode file is a/b/c.gcode in octoprint/klipper, but it was later overwritten with a different version. The "reprint" button will print a different version, which may or may not be a surprise for the user.
• The gcode file is a/b/c.gcode in octoprint/klipper, but it was later moved to x/y/z.gcode. No matter what we do here, the result will be a surprise for the users.
• The gcode file is a/b/c.gcode in octoprint/klipper, but later overwritten with a different gcode file. "Reprint" will result in a wrong behavior.
• ...

Before we have a good way to handle edge cases like these, we can't add the "reprint" function.

[puterboy]

At least for Octoprint, all of the above edge cases could be mitigated if not solved if Obico stored the md5sum of the gcode in the Print History which could then be checked against the md5sum hash stored in the corresponding .metadata.json file.
This hash is accessible via the Octoprint API.

Basically, at the time of printing when the new Gcode info is added to the app_gcodefile table, an octoprint API query would be run to retrieve and enter the md5sum as a new field in the table.

Then at a later time when using Print history, the Obico server would query the api again to check if:

1. The gcode file exists in the same name/location as indicated in the url field of the app_gcodefile table
2. Check that the md5sum is unchanged.

If check 1 & 2 pass, then the reprint button would be enabled. If not, it stays grayed out.

Are there any edge cases not covered by the above?

[puterboy]

Alternatively, while not as robust, you could use the existing num_bytes field from the app_gcodefile table and the last print time from the app_print table to match against similar values available from the Octoprint API.

Of course, I understand that this might not be a priority at all - but technically I don't see any big conceptual issues to getting this right almost always.

And even if not perfect, it would still be better than the Octoprint list of gcodes that is much harder to navigate and silently overwrites itself so long as the name/print-time/filament-type are the same.

[kennethjiang]

Klipper is trickier, but it is still technically possible. Still, the user experience will be bad - in case of md5 mismatch, how do we explain it to the user?