Using setready.g starts the next job, but leaves it at the top of the queue  

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Hmm, I just tried it again, and it might just be a graphical glitch in the print queue view. The duplicated job disappeared on page reload...

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Hi, okay, that might be it, becazse we tried it and weren't successful. I relay that to the team. Thanks

RE: Using setready.g starts the next job, but leaves it at the top of the queue

I've definitely had it happen twice now since then. Not just a visual bug, the job was still there in the queue after reloading the page.

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Welp, that sucks, if you can think of anything we could try to replicate this on our end, please let me know. As is, we cannot get it to happen making a fix unlikely to be made 🫤

Also please let me know whether you can start the print twice just by selecting set ready a second time. Thanks

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Welp, that sucks, if you can think of anything we could try to replicate this on our end, please let me know. As is, we cannot get it to happen making a fix unlikely to be made 🫤

As a developer myself, I know that feel... Will get back to you if I figure out a pattern in the issue. One thing I did notice the last time it happened was that the printer briefly said "No internet connectivity" just after starting (and then saying "Errors resolved" within less than a minute). I don't think I've seen that before, though, and I think this was after Prusa Connect noticed that the print had started. I should probably also mention that I'm using a basic Pi Zero (i.e. non-W) in my printer, with a USB hub with Ethernet connected to it (specifically, this thing).

Also please let me know whether you can start the print twice just by selecting set ready a second time. Thanks

Good point. I'll try to remember to try that next time I see it happen. So far I've just removed the extra job manually.

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Okay, that can do it. Thank you for that tidbit of info. You basically lose one message sent to connect while the print is starting. That definitely can cause weird stuff to start happening. But why do you lose just one? Hmm

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Any log files I should check?

RE: Using setready.g starts the next job, but leaves it at the top of the queue

Could be interesting to see the syslog, just please tell me approx the time it happened

RE: Using setready.g starts the next job, but leaves it at the top of the queue

I found interesting things in daemon.log. It seems like there were connectivity issues both times this happened today:

Oct 30 08:41:34 replicator prusa.link.printer_adapter.print_stats[472]: INFO: New file analyzed. It has inbuilt percent and time reporting. {info():195}
Oct 30 08:41:37 replicator prusa.link.printer_adapter.state_manager[472]: WARNING: State was State.PRINTING {warning():205}
Oct 30 08:41:39 replicator prusa.link.printer_adapter.state_manager[472]: WARNING: State was State.ATTENTION {warning():205}
Oct 30 08:41:45 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:41:55 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:42:06 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 08:42:06 replicator prusa.link.printer_adapter.lcd_printer[472]: WARNING: Displaying an error message No Internet access  {warning():205}

/.../

Oct 30 13:01:00 replicator prusa.link.printer_adapter.print_stats[472]: INFO: New file analyzed. It has inbuilt percent and time reporting. {info():195}
Oct 30 13:01:10 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}
Oct 30 13:01:20 replicator connect-printer[472]: ERROR: HTTPSConnectionPool(host='connect.prusa3d.com', port=443): Read timed out. (read timeout=10) {loop_step():748}

Interestingly, the second time (13:01) was the time I noticed the "No internet" message, but there's nothing about it in the log that time.

RE: Using setready.g starts the next job, but leaves it at the top of the queue

The error system could use a lot of work. The read timed out is causing an exception which is actually triggering this message. I want to improve this, but need to figure out a quick solution that is hopefully a little more true to what's happening. It's related to connect dropping the connection.