What is the best/safest procedure for restarting the Organelle when it freezes? I’m stuck in Orac right now, and I’d rather not loose my settings by unplugging the PSU, but I can’t find any other way. The Organelle stopped responding completely.
BTW – isn’t it ironic it got stuck while in a Freezer module that currently says “Not Frozen”
I think the red exclamation mark (hand?) does the same? (not sure as I dont use this at all)
but if desktop UI is slow, sounds like cpu issue
if a patch uses a lot of CPU, not much left for UI… also using PD in graphics mode also consumes more CPU.
(though the buffer size is increased to help ease this )
if you find this happening alot with a particular patch when using the desktop, you could increase the audio buffer for it. (using pd-opts.txt)
something to be aware of here…
when the organelle “freezes”, usually what this means is PD has crashed,
the issue is, if the patch has taken over the encoder (which modern patches do all the time for menus etc),
then the issue is you cant get back to the main menu.
so whilst it feels like the organelle has crash/frozen it hasn’t really…its just you cant get back to the menu.
(restart-mother is just an easy way to take back control to the menu)
what would be ideal is if we could introduce some kind of ‘key combination’ that the patch launcher could always intercept, and take back control - but unfortunately, have kind of use up all key combos for patches
I had this happen many times when messing around in orac.
I don’t always start wifi if I’m not expecting to use it (since it involves taking up one of the usb slots and I’m often using both with orac). And I don’t have a keyboard/monitor/mouse setup, so I have two questions.
What could the potential harmful cumulative effects be of just unplugging?
might there be some other way to implement a reset directly from the organelle?
As it is I’m afraid to try things in orac that might push the cpu, which is… okay, but a little bit sad to be scared to experiment freely
Yes, I’d also like to be able to do it all the time and have a proper reset, as this would allow me to freely play with orac without any worry. I don’t get to back up as often as I’d like, so presently I’m avoiding this kind of experimentation.
I’m aware of this! Really just suggesting the required hold time is extended and that it is applicable on all patches. 5 seconds… display message, hold for further 5 seconds to shutdown? Also, shutdown process is aborted if an organelle key press is detected.
I wouldn’t mind going through 10 seconds of waiting to avoid corruption on a freeze up. I do usually use the regular menu shortcut in normal use though anyway.
Is this more a case of semantics? The organelle certainly does become unusable/frozen up if a user accidentally (or on purpose!) uses a combination of high draw modules in the orac patch. I understand the distinction, but I believe what people are describing as a crash is when they cannot use the menu of, hear or in any way operate the organelle due to cpu load. Brds module crashes occasionally for me but this usually resolves and brings me back to the main menu screen, like a reload.
as with all tech, like it or not, specifics are important… since the fix or resolution is dependent on exactly whats going on , rather than what the user perceives is going on…
if it’s just heavy CPU load, then I would expect (with patience) eventually the patch will respond and return you to the main menu, and so eventually you’d be able to shutdown.
caveat : unfortunately, those pesky details rear their heads again here… somethings might use timers, which might screw up and things become a bit unpredictable - either making functionality, like menus, work intermittently or not at all.
in this case the shutdown shortcut may or may not work, due to those timing issues, as we have no way to get more priority to the mother executable, in fact its actually running at a lower priority than audio (which is what you normally want)
however, if the patch crashes (due to an external, or pd acting up) , then its a different thing entirely - the patch cannot return the control to mother executable.
I have actually talked with @oweno about a different solution for this, we could be periodically checking the patch is running and if we find its died, we could then ‘cease’ control, and return to the main menu.
likelyhood is , different people are describing both… this is why I use try to find out some specifics, rather than just the organelle has crashed or frozen - because from a technical standpoint this doesn’t actually tell us anything at all…
connect a keyboard/monitor (or log in via ssh) and see if PD is still running
the thing is, it wont just start responding… you’d need to be actively trying to exit the patch etc.
a) I think we can do something to improve this e.g. “shutdown shortcut” could also kill pd/regain control… we just need (including C&G) what exactly the ‘kill switch’ is.
b) as I first said, its actually unlikely that powering off will corrupt your sd/usb.
c) priority really is to ‘fix patches’ , since patches dying is not good anyway.