search

cameroncros / OctoPrint-DiscordRemote

Discord plugin for OctoPrint
MIT License
68 stars 32 forks source link

Added ability to send .zip files #158

Closed Stwend closed 3 years ago

Stwend commented 3 years ago

I have added the function /unzip with which the user can send zipped files (both .zip and multi-volume .zip.001, zip.002, etc files) to the Discord bot. Only gcode files are extracted from the zip, after extraction the zip files are deleted and the gcode file is available for printing as usual.

By using zipped files it is possible to circumvent Discord's 8MB upload limit. The function allows for up to 99 multi-volume zips which can be 8MB each, enabling users to upload huge .gcode files.

How to use:

Case A - single-volume zip: Call /unzip filename.zip

Case B - multi-volume zip: Call /unzip filename.zip.001 The function will automatically search for the rest of the multi-volume.

If there are multiple gcode files in a zip, the function will extract them all.

! Make sure the Discord bot has accepted all of your files before calling /unzip !

cameroncros commented 3 years ago

This all looks great. I will test and merge it. As a possible future suggestion, maybe when a zip file is uploaded, you could automatically try the unzip function, and quietly fail if not all files are ready. That way you can upload all parts of a zip, and when is ready, the GCODE files will be ready to be printed?

Stwend commented 3 years ago

This all looks great. I will test and merge it. As a possible future suggestion, maybe when a zip file is uploaded, you could automatically try the unzip function, and quietly fail if not all files are ready. That way you can upload all parts of a zip, and when is ready, the GCODE files will be ready to be printed?

Thanks! I've thought about auto-unzipping, too, my 2 cents: It might be a little tricky to detect when multi-volume zips have finished uploading. The first file should have some info in its header about the overall size, though, and the multi-volume assembly code might lend itself to some easy "is-the-zip-working-yet testing". Alternatively, I could add a code snippet to the file downloader and make it judge the progress by adding up file sizes of received zip.xxx files until the file size in the zip.001 header is matched. Rather than silently failing, I'd do a progress report, something along the lines of "5 of 8 files received", or "5 of ??? files received" if the plugin doesn't know the final file count yet.

It does sound like a good thing overall, I'll open a ticket, but I don't know when I'll be able to try it out :)

cameroncros commented 3 years ago

I figured that it could be detected just by trying to unzip, and catching the failure. But, I don't really know. Like it said, cool feature, but in no way is it essential or urgent.