Open Stage session page freezing

Community General Discussion
1

This has happened a couple of different times, with a couple of different browsers.

Going along just fine in a performance -- and then suddenly, the Open Stage client page in a browser on a tablet just... freezes. The controls stop responding.

I actually mentioned this a month ago: Client lost values when reloading the page on a slow connection -- "In my last show, at some point, the browser on the tablet barfed and I had to reload the page" -- but I didn't think much of it at that time because it was a one-off.

It happened again today, twice -- using a different browser from the one I was using earlier. Same problem, different browsers suggests that it's not browser-specific.

(Of browsers: The first time this happened, it was with the stock Huawei browser, which I assume is a fork of the stock Android browser, but I'm not completely sure of that. The second and third time, today, was with Microsoft Edge. So, why don't I use an officially supported browser? Chrome uses too much screen space for itself, so it doesn't display all of my page. Firefox has a really wonky way of responding to faders -- they think "don't respond to accidental touches," but the result is really gross discontinuity in control signals -- it's unusable on stage. It seems that I don't have any really good options. Basically, the least objectionable option now is to use Edge until it crashes, and then reload per my safety mechanism. As a performance instrument, this goes in the "you've got to be kidding me" bucket, but, best I can do at this point. I'm a wee bit frustrated.)

Fortunately, per the earlier thread, I did install a hook to refresh the session state, so if it happens on stage on Sunday, I can just reload the page and let my software resync the values.

But I used Open Stage onstage for a year or two without seeing this problem, and now I've seen it multiple times within the last month. So it seems worth it to investigate -- has something regressed in my environment? Or has it regressed in Open Stage itself?

hjh

PS I have a show on Sunday :scream:

2

Hey, sorry I didn't respond to your previous thread, I too am a bit busy with artistic projects too (on tour right now) and I'm really sorry for the inconvenience.

Chrome uses too much screen space for itself, so it doesn't display all of my page.

Doesn't fullscreen mode (client main menu) work on chrome + android ? It's supposed to.

Firefox has a really wonky way of responding to faders -- they think "don't respond to accidental touches," but the result is really gross discontinuity in control signals -- it's unusable on stage.

I'll need to investigate on that, maybe there's a way to fix it in o-s-c.

But I used Open Stage onstage for a year or two without seeing this problem, and now I've seen it multiple times within the last month. So it seems worth it to investigate -- has something regressed in my environment? Or has it regressed in Open Stage itself?

There was no significant change in the past few months (none that I can link to the issue I mean), but it doesn't mean it's not a bug in open stage control, maybe something in your environment ended up triggering a long standing rare bug, hard to say. Did you make significant changes in your session ? Did the problem start occurring after a particular update ? Did you by any chance identify recurring factors ("occurs after X minutes of interaction", "occrurs when interaction with widget X or Y") ?

In any case it would be good to able to rule out the browser part and confirm that the freeze occurs on a supported browser too. It may help to be able to load and test your session file too, if you could upload it.

3

Chromium doesn't seem to have a full screen menu option. EDIT: OK I'm an idiot -- you meant the Open Stage hamburger menu, not the browser's menu. I see it now. -- Is there a way, then, to have the browser open the page fullscreen by default?

(Then, when I was testing it just now, Chromium crashed and now won't relaunch. So I guess Chromium is permanently out of the running.)

Chrome on Android will not run at all in mainland China without a VPN.

Here's a screenshot of what I'm seeing. In both cases, the first movement is just for calibration -- a quick move to "reset." Then I move the fader very slowly upward.

The top graph shows what happens when I move a fader very slowly in Edge -- each step is the smallest possible unit. The lower graph is the same action, in Firefox. It skips over one or two steps and jumps a larger distance at first. It doesn't look like much, but when the fader is mapped onto a 20-20000 log-linear range (such as for a filter), even this slight jump is disruptive to the expressivity of the gesture.

edge-v-firefox-2
edge-v-firefox-2422×672 28.4 KB

My session file has been stable, and I haven't updated Open Stage in a few months.

The issue is sporadic, but only occurs after the session has been open for at least 20 minutes. So it's not easy to reproduce.

First time it happened (stock Android browser): A jam session, on stage. I would have been actively using the interface the whole time.

Second time (Edge): A bit different because my collaborator had a second tablet (Safari) opened to the same session page. (This was for a shared timer display, and also so that he could control his mic mixer mute/unmute by himself.) At one point, his tablet's screen went to sleep, and this seemed to break the session for both of us -- but that might be a spurious observation, because I've seen freezes outside of that situation. (It's also possible that the session froze first, and this allowed his screen to sleep -- no way to know after the fact.)

Third time (Edge): I was not actively interacting with the session, then reached over to touch it and found it was unresponsive.

The session consists of buttons, faders, one text field, one pop-up menu, in a structure like:

  • Panel 1
    • Tab 1
    • Tab 2
  • Panel 2

So, a fair number of widgets, but not anything terribly exotic AFAICS.

open-stage-lc-2mics.json (180.5 KB)

EDIT: Happened again in the afternoon -- just had the session open for a long time, functioned normally until it didn't.

Thanks --
hjh

4

Thanks for the details, a similar issue has been reported before actually, and so far I haven't been able to tackle it, I'll keep you posted if I find anything.

Is there a way, then, to have the browser open the page fullscreen by default?

No, the browser won't go fullscreen without a user interaction, you could try adding the page to the home screen from the browser menu, IIRC it makes it run fullscreen.

(I confirm the touch issue on firefox; Edit: I could reproduce the firefox issue in v115 but not in nightly v130 so there's hope there)

5

When the session freezes, does the 3-dots menu still work ? Does scrolling work ?

6

Sorry for the late reply -- I wasn't using the interface for awhile, during a dev phase.

It just happened again -- the 3-dots menu is broken too. The only recourse is to swipe back in the browser to redisplay the tab bar, and reload from there (but then recovery is successful).

Scrolling, I don't know, I was in fullscreen mode and everything fits on that page.

hjh

7

BTW: It just happened again, while I was actively using it -- just, freeze. It was a bit of a long session, and I had taken some breaks in the middle. But this is a new data point: touch a control one second, OK; touch it a second later, everything is frozen.

I can't end fullscreen either, in that case. Edge got stuck in some weird state and I couldn't recover.

OK, let me upgrade to nightly 130 and go back to Firefox then. (Unsurprising that a Microsoft browser's behavior is sub-par.)

EDIT: I can't find nightly builds. So, let me try 1.27 and see what happens first.

EDIT: Firefox is still a problem vs 1.27. Can I please get a pre-release of 1.30 then? I've got a deadline and I'm fighting with browsers again...

hjh

8

EDIT: Firefox is still a problem vs 1.27. Can I please get a pre-release of 1.30 then? I've got a deadline and I'm fighting with browsers again...

I was referring to firefox' version (130, not 1.30), I haven't changed anything on osc's side.

Given the fact it only happens after a while I tried to look for memory leaks but could find any significant leak under a heavy stress test (on a laptop and on some random smartphone I could get my hands on the other day). I come to think it'd be worth (if possible) testing your setup with a different device, in case it's a system specific failure of some kind (which I'm not sure I could solve).

9

Ah, OK, that wasn't clear to me.

I don't have another tablet, though, so that test might not happen for awhile. Agreed that it would be important to rule that out.

hjh