sclang crash on system time sync

tehn commented 6 years ago

sclang crashes when time/date change by a substantial amount

this happens when connecting to a wifi network which syncs time/date

tehn commented 5 years ago

short term solution.

add menu item for disable/enable audio engine. starting a wifi network session will automatically shut down audio.

sudo systemctl stop norns-crone
sudo systemctl start norns-crone

tehn commented 5 years ago

sudo systemctl stop norns-crone doesn't work.

we'll have to do

killall sclang
killall supernova

simonvanderveldt commented 5 years ago

sudo systemctl stop norns-crone doesn't work.

@tehn Why doesn't that work?

catfact commented 5 years ago

@simonvanderveldt @tehn it works for me

catfact commented 5 years ago

three more points:

it might be cleaner to shutdown SC from within SC (s.quit, ("kill "++thisProcess.pid).unixCmd). this would also allow a slick fadeout of the audio instead of a hard stop.
when restarting, will have to go through the handshake procedure as in audio.restart(). beware of cairo thread safety for the audio connect animation (nothing else can be using the screen)
and of course the real difficulty is detecting timesync. @artfwo proposed a manual method of having a thread in matron that checks the system time delta. (this, i could help with.) other possible solutions involve adding systemd services, which is beyond me.

tehn commented 5 years ago

oh indeed it works, i made a mistake in my launching earlier.

slick fadeout

!!!

would be nice on shutdown as well.

lazzarello commented 5 years ago

I've run into reproducible screen lock ups, button latency and audio drop outs when I turn on wifi. I'm worried that all these hard resets might make the filesystem on the eMMC get corrupt. So I've been doing a reboot via SSH, which doesn't actually reboot the screen or wifi.

I wonder if disabling NTP will fix this problem? Now that I have a shell, I'm tempted to do "normal linux stuff".

tehn commented 5 years ago

@lazzarello when you turn on wifi and NTP sync's you MUST reboot crone. otherwise you'll experience problems.

i'm preparing an update which disables crone on wifi connection, and implemented a menu option to reboot crone.

ngwese commented 5 years ago

fyi: i'm running into problems with the new wifi logic.

power up, load earthsea
go to SYSTEM > WIFI > NETWORK
select the desired network, confirm password, OK ...at this point i'm immediately taken to the main SYSTEM menu again (not the WIFI sub menu as previous) ...the loaded script say AUDIO ERROR which is somewhat expected since the engine just got stopped.
navigate to SYSTEM > WIFI > NETWORK again and the status reads failed
select SYSTEM > RESET AUDIO ...when returned to the menu and select a script they don't load, i can only get as far the the script help screen
attempt to enable wifi again and i always get "password fail"
second attempt at RESET AUDIO appears to work

tehn commented 5 years ago

thanks for the report. i need to prioritize a wifi overhaul.

the only thing that changed is that upon wifi activation crone is shut down (to be manually re-activated after connection is established.) i should add a message when activating wifi that explains this.

i'm not sure why it would take two attempts, and why wifi is still saying failed, however.

simonvanderveldt commented 3 years ago

@tehn Why was this closed? I don't think we have a solution for this yet, right?

tehn commented 3 years ago

this was closed in the great-ticket-purge at the march meetup. likely as it wasn't reported as a problem for some time.

have there been issues with this? (AFAIK, no?)

simonvanderveldt commented 3 years ago

It still happens every now and then that someone runs into this. Maybe we should keep this open keep track of it? Although realistically there isn't much we'll be able to do about it ourselves.

antonhornquist commented 3 years ago

Mentioned by @lazzarello: ” I wonder if disabling NTP will fix this problem? ”

This is probably one way to address this. Or have people manually sync upon confirming that the script/engine is restarted or something (weird ”fix” but would probably work anyhow).

antonhornquist commented 3 years ago

And this is messy still - any engine and script using a high rate polls stall upon time change. I think there’s reason to reopen this.

tehn commented 3 years ago

ah, i forgot about the poll-heavy crash on startup w/ wifi attached.

monome / norns

sclang crash on system time sync #399