FormerLurker / Octolapse

Stabilized timelapses for Octoprint
GNU Affero General Public License v3.0
638 stars 99 forks source link

Octolapse Render Failed: Inner Exception: unsupported format character error #788

Open ShamusTheTinker opened 2 years ago

ShamusTheTinker commented 2 years ago

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: _REPLACE_THISOCTOLAPSE_VERSION_GOES_HERE

Version of OctoPrint

OctoPrint Version: 1.7.2

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: YES

What were you doing when the problem occurred

  1. After the print completed I clicked on the button for unfinished rendering
  2. Clicked on the render with selected settings video button
  3. Changing settings continued to cause the error

I recently updated my octoprint build on my system. Prior to the update my rendered timelapse videos were always available to download in completed timelapses. I did make sure to turn on Verbose G-code in PrusaSlicer.

What should have happened?

I expected to download the rendered video

What happened instead?

Rendering failed for camera 'Webcam - Default OctoPi 0.16.0'. render-error: Unknown render error. Please check pluginoctolapse.log for more details.. Inner Exception: unsupported format character '' (0x5f) at index 37

Operating System running OctoPrint and Octolapse

OS Name: Windows Os Version: 10 64 bit

Printer model & used firmware incl. version

Printer Model: Prusa mk3s+ Printer Firmware Version: 3.9.2-3524

Browser and version of browser, operating system running browser

Browser: Chrome Browser OS: 96.0.4664.45 (Official Build) (64-bit)

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: (https://gist.github.com/ShamusTheTinker/53b66cfb7530a3a06381223efc3e632d)

Link to settings.json

Link to settings.json with all passwords removed: (https://gist.github.com/ShamusTheTinker/19a866393459dee0ce3411f9802c1690)

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://gist.github.com/ShamusTheTinker/9e22d69f4b652675a5c80fcf14696892

Link to octoprint.log

Link to octoprint.log: https://gist.github.com/ShamusTheTinker/0881815bd9e3e8727ad753c659111f72

Link to contents of Javascript console in the browser

Link to javascript console output: _REPLACE_THISLINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: _REPLACE_THISLINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

szafran81 commented 2 years ago

+1 here

I've just noticed that I have unrendered octolapses since 17.10.2021 (so about that time something changed in OL or OP that made it stop working - I haven't changed anything in my config for a long time). But my printer had some off time lately, so it could be something that chenged a bit earlier.

I'v always used the same naming scheme - so no changes here either.

The rendering always fails after 'Adding overlays' step.

Currently I'm on:

OctoPrint 1.7.2
Python 3.8.10
OctoLapse 0.4.1

Those are my errors:

2021-11-27 20:40:48,361 - octolapse.render - ERROR - Rendering Error
Traceback (most recent call last):
  File "/home/szafran/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/render.py", line 1565, in _render
    self._apply_pre_post_roll()
  File "/home/szafran/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/render.py", line 2137, in _apply_pre_post_roll
    self._temp_rendering_dir, self._render_job_info.snapshot_filename_format % 0
ValueError: unsupported format character '_' (0x5f) at index 69

It's always about the underscore character, just the index changes.

EDIT1: On further inspection... LOG:

2021-11-27 20:55:20,211 - octolapse.render - ERROR - Rendering Error
Traceback (most recent call last):
  File "/home/szafran/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/render.py", line 1565, in _render
    self._apply_pre_post_roll()
  File "/home/szafran/OctoPrint/venv/lib/python3.8/site-packages/octoprint_octolapse/render.py", line 2137, in _apply_pre_post_roll
    self._temp_rendering_dir, self._render_job_info.snapshot_filename_format % 0
ValueError: unsupported format character '_' (0x5f) at index 40

and corresponding job/file name (note 2 spaces after ABS):

Dust Bag Clip___Prusa ABS  MMU2_0.20_15%_5gr___34m

That gives '%' at index 40. I think that something changed in OP that earlier saved '%' in filenames as '-'. All my previous timelapses had '%' changed to '-' and now it stays as '%'.

EDIT2: Yup, it was some change in the OP code that takes care of file names of uploaded files. I've checked tha archived gcode file names. A file uploaded on 30 sept has '-', and the next file uploaded on 17 oct has '%'. So some update between those dates screwed something up.

ShamusTheTinker commented 2 years ago

Ok, so looking at my log I get the below error, I just have no clue how to fix it. Do I need to change the naming format of my gcode files? Or is it something more involved.

2021-11-25 08:16:03,000 - octolapse.render - ERROR - Rendering Error Traceback (most recent call last): File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/render.py", line 1565, in _render self._apply_pre_post_roll() File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/render.py", line 2137, in _apply_pre_post_roll self._temp_rendering_dir, self._render_job_info.snapshot_filenameformat % 0 ValueError: unsupported format character '' (0x5f) at index 37

gmueller2000privat commented 2 years ago

I can confirm this problem as well. Just removed % from the filename and everything works fine again.

FormerLurker commented 2 years ago

Yeah, the % char is special in python when formatting strings. I need to encode those, then format, then decode. I'm surprised it took this long to find. I just never have a percent sign in my file name. I'm guessing this is being added by some slicer automatically where it was not previously. Can someone verify?

szafran81 commented 2 years ago

As I recall (and that is verified by my archived gcode files) it was substituted by '-' (minus sign) by OctoPrint automatically when the files were uploaded (a couple of OP versions back). And now it's not.

ShamusTheTinker commented 2 years ago

Ok, important question then. Does this mean I need to pull the SD card and edit the file on it? Or can I edit it through Octoprint somehow?

FormerLurker commented 2 years ago

I can provide a workaround, or if you are willing to wait until tomorrow, I will be pushing a patch into dev

ShamusTheTinker commented 2 years ago

I can provide a workaround, or if you are willing to wait until tomorrow, I will be pushing a patch into dev

I'm willing to wait till tomorrow. Thanks

Jordan87 commented 2 years ago

I can confirm that i run into same issue, log looks a little bit different but i also have % in my files name.

2021-12-11 16:48:28,486 - octolapse.render - ERROR - Rendering Error Traceback (most recent call last): File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/render.py", line 1565, in _render self._apply_pre_post_roll() File "/home/pi/oprint/lib/python3.7/site-packages/octoprint_octolapse/render.py", line 2137, in _apply_pre_post_roll self._temp_rendering_dir, self._render_job_info.snapshot_filename_format % 0 ValueError: unsupported format character 'C' (0x43) at index 32

I'm using now Plugin "Gcode Filename Format Plus" in Cura with format: [base_name] [material] [layer_height]mm [infill_sparse_density]% [material_print_temperature]C [material_bed_temperature]C Objects [object_count] t [print_time] Supports [support_enable] And that's why i run into this issue ;)

FormerLurker commented 2 years ago

So, I've put several hours into this. It turns out a lot of what Octolapse does relied on the fact that the file names were slugified (stripped of most non-ascii characters). Since the % character used to be stripped, this has caused problems with the creation of snapshot files, rendering files, archives, and a ton of other stuff. I resolved these problems only to find that these special characters also break the C++ code, which I tried to resolve by implementing wide character file name support. That broke all of the python 2.7 routines, though I believe I've got it fixed for Python 3.7+ (at least in windows.. not looking forward to getting this to work on the pi).

Also, when running on older versions of Octoprint, the files stored on the pi get renamed to the slugified versions, which is adding another level of complexity.

In other words, this is a can of worms I'm not sure that I can resolve while keeping existing versions of Octolapse running, and while supporting legacy systems. I'll keep working today, but I think that no matter what I do Octolapse will be broken for some. I'll post an update when I have one.

ShamusTheTinker commented 2 years ago

@FormerLurker do you know if there is a way for me to fix it in the filenaming I use for Prusa? If I just need to avoid certain characters, that'll be an easy short term fix until you are able to get a permanent fix in. I did have the % sign in my file name which is not a problem for me to remove.

FormerLurker commented 2 years ago

Killing the % sign will work for now, and no extended characters seem to work either (umlauts, etc...).

FormerLurker commented 2 years ago

Holy cow, i might have gotten it working, and it only took about 14 hours, lol! Here's a devel link you can install to test via the plugin manager: https://github.com/FormerLurker/Octolapse/archive/7d9479091232ed88e8789754cce6ce9f5a03a398.zip

I have NOT tested this on a Mac or a non-raspberry pi linux machine, or python 2.7 on the raspberry pi, but it is working in the following cases:

Windows Python 2.7 Windows Python 3.7 Raspberry Pi Python 3.7.3

If anyone can get back regarding 2.7 and 3.10 on the PI, any linux version (no rpi) and macos, I'd be very happy.

Thanks!

ShamusTheTinker commented 2 years ago

I'll see about downloading and testing it a bit later. Got a print going so it'll have to wait. Thank you for working on it.

ShamusTheTinker commented 2 years ago

Ok, I've installed the updated version and I'm launching a benchy to test. I'll let you know if it works.

ShamusTheTinker commented 2 years ago

@FormerLurker The fix worked perfectly on octoprint version 1.7.2

FormerLurker commented 2 years ago

Thats a relief, thanks!

Jordan87 commented 2 years ago

For me this also solved my issue with rendering. Thank You

s53zo commented 2 years ago

Me too...

szafran81 commented 2 years ago

@FormerLurker Hey, nice work, any ETA when this will make it to a release of OL?

PurseChicken commented 2 years ago

Holy cow, i might have gotten it working, and it only took about 14 hours, lol! Here's a devel link you can install to test via the plugin manager: https://github.com/FormerLurker/Octolapse/archive/7d9479091232ed88e8789754cce6ce9f5a03a398.zip

I have NOT tested this on a Mac or a non-raspberry pi linux machine, or python 2.7 on the raspberry pi, but it is working in the following cases:

Windows Python 2.7 Windows Python 3.7 Raspberry Pi Python 3.7.3

If anyone can get back regarding 2.7 and 3.10 on the PI, any linux version (no rpi) and macos, I'd be very happy.

Thanks!

I had a % in my file name causing the problem stated in this issue. I updated using this zip and restarted. As soon as I did this, Octolapse rendered my timelapse as expected when I manually kicked it off. Thanks so much for the fix.

OctoPrint: 1.7.3

KL2001 commented 2 years ago

I also had a "%" in some filenames and this fixed the issue. OctoPrint 1.8.1 (OctoPi)

anthony-cannon commented 1 year ago

7d9479091232ed88e8789754cce6ce9f5a03a398.zip still didnt work for me.

But I did find an Octolapse fork which works! https://github.com/pneumaticdeath/Octolapse