GCode filenames with percent sign (%) in the filename causes timelapse screenshot saving to fail.

[pvince]

What were you doing?

When a filename has "%" characters in it, timelapses will not be created. Octoprint.log logs the following error message each time it tries to capture a snapshot:

2022-01-08 18:48:33,257 - octoprint.events - ERROR - Got an exception while sending event ZChange (Payload: {'new': -10.0, 'old': 10.0}) to <bound method ZTimelapse._on_z_change of <octoprint.timelapse.ZTimelapse object at 0x9e7c2350>>
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/events.py", line 203, in _work
    listener(event, payload)
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/timelapse.py", line 873, in _on_z_change
  File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/timelapse.py", line 693, in capture_image
    self._capture_dir,
TypeError: not enough arguments for format string

Line 693 of timelapse.py is:

OctoPrint/src/octoprint/timelapse.py

Lines 691 to 694 in 4b12b0e

	filename = os.path.join(
	self._capture_dir,
	_capture_format.format(prefix=self._file_prefix) % self._image_number,
	)

I added a debug line immediately before this one to output the variables involved, that resulted in this log statement:

octoprint.timelapse - INFO - capture_dir: /home/pi/.octoprint/timelapse/tmp, capture_format: {prefix}-%d.jpg, prefix: CE3PRO upload
s_files_880895_tree_crown_loop_012 3D Max PLA lw 0.4mm lh 0.12mm if 5% ext1 210.0C bed 60.0C_20220108202600, image_number: 0

Note the value of prefix is CE3PRO upload s_files_880895_tree_crown_loop_012 3D Max PLA lw 0.4mm lh 0.12mm if 5% ext1 210.0C bed 60.0C_20220108202600.

This is because in Cura I am using a plugin called 'Gcode Filename Format Plus' which by default sets the filename to [abbr_machine] [base_name]2 [brand] [material] lw [line_width]mm lh [layer_height]mm if [infill_sparse_density]% ext1 [material_print_temperature]C bed [material_bed_temperature]C

When the first part of Line 693 resolves: _capture_format.format(prefix=self._file_prefix) we end up with the string:
CE3PRO upload s_files_880895_tree_crown_loop_012 3D Max PLA lw 0.4mm lh 0.12mm if 5% ext1 210.0C bed 60.0C_20220108202600-%d.jpg

When Python attempts to format that string to replace the %d, it finds itself with two candidates, % and %d but it only has one input parameter self._image_number

I suspect the fix for this would be to insert the image number first, then replace the prefix.

For now, I have worked around the issue by updating the Gcode Filename Format Plus to ommit the percent sign.

What did you expect to happen?

Timelapse screenshots to be taken, and the timelapse to be gneerated.

What happened instead?

OctoPrint generates an error at each ZChange event. (see above for error)

Did the same happen when running OctoPrint in safe mode?

I tracked down the issue in the source code, so I did not try in safe mode.

Version of OctoPrint

OctoPrint 1.7.2 Python 3.7.3 OctoPi 0.18.0

Printer model & used firmware incl. version

Ender 3 Pro w/ GTT SKR Mini v2.0. Custom Marlin 2.0.9.3

Browser and version of browser, operating system running browser

Firefox 95.0.2

System Info Bundle

octoprint-systeminfo-20220108132352.zip

Link to contents of Javascript console in the browser

N/A

Screenshot(s)/video(s) showing the problem:

I have read the FAQ
.

[jneilliii]

Confirmed bug, I'm able to reproduce. I suspect this is related to the recent feature of allowing special characters in filenames that was not possible previously. Thank for the detailed report @pvince

[jneilliii]

Thinking changing _capture_format = "{prefix}-%d.jpg" to _capture_format = "{prefix}-{image_number}.jpg" and _capture_format.format(prefix=self._file_prefix) % self._image_number, to _capture_format.format(prefix=self._file_prefix, image_number=self._image_number), would potentially resolve this issue. Of course would have to adjust throughout all references.

[jneilliii]

Initial testing seems to be positive. One thing I noticed while looking at this is the _capture_glob wasn't being used for the _render function, which I think it should have been versus _capture_format. Will submit PR shortly once this test render completes.