Open Spydyr opened 3 weeks ago
Missing thumbnails usually means the pre processor has failed to parse or has timed out parsing the gcode
Do you have
[file_manager] default_metadata_parser_timeout: 30
in moonraker.conf to increase the default timeout from 10sec? Issues parsing gcode files are also logged to the moonraker.log file and may provide additional insights
No I do not but that is a minor issue. The big issue is history not showing the files are missing even the one that is printing with both set to True. Could that timeout be part of it?
https://drive.google.com/file/d/1MtbN-Zlt5R4S6PCnAZKAnIK56_xqZsX5/view?usp=drivesdk
Here I the pic I took to show. The top one was printing when I took the photo.
Highly likely as the preprocessor essentially rewrites the gcode file to expand HH tokens like !referenced_tools!
!colors!
, !temperatures!
, etc. If it times out, it won’t replace the gcode file or expanding the tokens.
Recommend you quickly override the default moonraker timeout to 30sec and retest - upload a new, sizable gcode file you have been having issues with and confirm the thumbnail is visible (might take > 10sec depending on the size of the file and SD card performance). Export the parsed gcode and check the HH tokens have also been expanded and replaced with expected values.
If you still have issues after setting this, please upload an extract from your moonraker.log and confirm your moonraker version. this is what you are looking for - Running MMU enhanced .... block
2024-10-30 18:15:46,855 [application.py:post()] - Processing Uploaded File: MM_Test_print_9_colors_ABS_0.4_1h12m.gcode
2024-10-30 18:15:47,191 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Running MMU enhanced version of metadata
2024-10-30 18:15:47,198 [shell_command.py:pipe_data_received()] - INFO:metadata:Object Processing is enabled
2024-10-30 18:15:47,215 [shell_command.py:pipe_data_received()] - INFO:metadata:File 'MM_Test_print_9_colors_ABS_0.4_1h12m.gcode' currently supports cancellation, processing aborted
2024-10-30 18:15:47,302 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Pre-processing file: /home/pi/printer_data/gcodes/MM_Test_print_9_colors_ABS_0.4_1h12m.gcode
2024-10-30 18:15:47,624 [shell_command.py:pipe_data_received()] - INFO:metadata:Reading placeholders took 0.32s. Detected gcode by slicer: OrcaSlicer
2024-10-30 18:15:47,868 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Writing MMU placeholders,Inserting next position to tool changes took 0.24s
2024-10-30 18:15:47,921 [shell_command.py:_check_proc_success()] - Command (/home/pi/moonraker-env/bin/python /home/pi/moonraker/moonraker/components/mmu_server.py -m -n -p /home/pi/printer_data/gcodes -f "MM_Test_print_9_colors_ABS_0.4_1h12m.gcode" --check-objects) successfully finished
2024-10-30 18:15:47,927 [application.py:log_request()] - 201 POST /api/files/local (192.168.2.185) [_TRUSTED_USER_] 1193.44ms
Also a sliced and unprocessed gcode file that has this issue so we can verify what you are experiencing (slice and export directly to a file)
I will try it out after the current print finishes in about 8 hours.
This is the latest log 4 attempts with the same file that shows the thumbnail regardless. History show the file does not exist when printing the file. And now it doesn't matter whether enable_object_processing is True or False.
OK, it looks like you have spoolman integration enabled which maybe the issue here given recent updates to the preprocessor to support this. Can you upload the unprocessed B_1_Yellow_PLA_5h19m.gcode
file (export from slicer) as well as the processed gcode from fluidd/mainsail?
https://drive.google.com/file/d/1U8eLYl4KQYVXj6BDns9_oJv5N6jtyqNc/view?usp=drive_link
Here is the link to it. It is like 25mb.
Now if I rescan metadata after the upload then history works as it should. Also I've only been running spoolman for 2 weeks and this issue by timeline started well before that.
I rarely use history and had a look on my other printer (v0.2) which doesn't have HH installed and can see same issue with missing icons for some jobs although others are fine (all sliced with the same 2.1.1 version of orcaslicer). Maybe a moonraker issue or orca related and a problem with the small embedded icon. Unsure what the cause is at this stage.
Your gcode file parsed fine on my HH system with tokens correctly expanded and icon visible in the jobs queue. However after submitting and cancelling the job its icon isnt visible in the History queue. Snap from my v0.2 showing the same issue in fluidd:
I use the history for seeing my most popular prints and for tweaking slicers so the times are close. And keep track of actual Total Print Time. I tried in Fluidd too and like you I got the same thing. I'm just not sure if it is a moonraker issue or a HH. I have thought about downgrading back to 2.7.1 because it was working with it.
As mentioned i see this issue on my v0.2 which doesnt have HH installed so definitely not caused by HH
My Sapphire doesn't have the issue and it doesn't have hh this is why I'm confused. But I do think it's more moonraker metadata issue than anything. There is something different and I just can't find it
I'm not sure I understand the problem completely but I do know that if the moonraker pre-processor times out then lots of problems can ensue.. no icon, TTC when KlipperScreen is running on same rpi (because of the MASSIVE amount of error logging klipperscreen will emit), etc. So make sure that:
[file_manager]
default_metadata_parser_timeout: 30
Where the timeout is plenty big enough to cope with the pre-processing time. Also check moonraker logs to see if there are pre-processing failures..
I added the timeout and it is at 600. There are no errors that we have been able to find. In the history it shows files that have printed as being no longer there when they haven't been moved or deleted. It also shows the current file printing as not being there as well. This doesn't matter if it is uploaded through the slicer or uploaded through mainsail/fluidd. I have confirmed it is both. HOWEVER, if you right click and select scan metadata after upload it loads into history just fine. My Voron has this issue where my Sapphire does not. The only difference is HH. Now @ningpj has it on both one with HH and one without. Which is the confusing part. I can't rule out HH but it seems to be a combination of things. Trying to narrow it down. HH, Moonraker, OrcaSlicer.
When HH will do a metadata scan whenever the file is created or changed. It piggybacks on the very same metadata scan that moonraker would have ran anyway. However if parsing does result in modification of the file then it would appear as "new" (not in print history). Not sure what might be happening without research but I can't do that ATM because I'm deep into Happy Hare v3.0. I'll keep this issue open to track. In the mean time if you or @ningpj have any more insights I'm all ears...
One thing that you can pay close attention to is the datestamp on the gcode
files. Are they changing after a print?
I just checked and no dates are not changing after printing. Also my Sapphire does not have spoolman installed on it. I just finished a print with it. I will test installing spoolman and loading a print. I will also be install long HH on it as I have to remove my ERCF from my Voron because I will be printing PPS-CF for the next week and can run it through there. That will give another test point. If it is strictly related to my Voron I will wipe it completely out and start over.
I will keep you informed of my findings over the next week.
So I believe I found an issue with the history.
If you have [file_manager] enable_object_processing: False
And
[mmu_server] enable_file_preprocessor: True
Then print history works as normal. However larger gcode files may not have the thumbnail. That's not the issue. If both are set to True history records the gcode prints as not the here including the one the has is currently printing. With both set to True though thumbnails always work. This problem started with 2.7.2 as I back tracked to when it was working fine. I have cleared history and gcode files to see if it was "overloaded" and that didn't correct it.