Closed the-ress closed 1 year ago
Could you provide the result of the API call or the metadata entries causing this. Also a single GCODE file would be nice to have an example.
I like to check if there are some single larger elements. Also you can disable storing the standard metadata in the plugins settings and define your own to reduce the amount entries. With my PI4 I cannot see any noticeable difference...
Here's one file as an example:
gcode: 08-Adjust Button_0.1mm_PA_MK3S_14m.txt
Needs some time to think about structural changes to perhaps not solve but optimize it.
In the meanwhile you can use folders as the API will return the files in the actual folder only.
If you switch to development version and update to the newest commit you will see two new buttons in the development tab.
Please press "Update Metadata stored" to update the metadata. Entries larger 50 bytes (like the start gcode) will be ignored now. I like to test if this will speed up the files api or if users have to deselect metadata to reduce the number of entries.
Also it would be nice if you can compare the speed between no custom metadata and metadata published. For that you can delete all metadata "Delete Metadata stored". It can be rebuild with the other button afterwards...
SlicerEstimator adds a large
slicer_metadata
field to each file and it makes/api/files/local
response 3x bigger causing performance issues. And I don't think OctoPrint has a way to get a file list without these extra data.I have about 500 gcode files and each has ~275 entries in
slicer_metadata
(I'm using PrusaSlicer). When listing the files on RPi Zero 2, it spends over 6 seconds just serializing to JSON.