Display of Overlays seems unreliable

Extensions
1

I’ve been watching data stream in from one of Overlay extensions.
I’m aware the streamer has installed the Overlay on their channel, and I’m seeing data stream in from thousands of viewers, and they’re actively interacting with it.

But from my machine, I’m actually not able to see the Full Screen Overlay render on any of my browsers on that particular stream. That suggests some viewers can see the Overlay, others cannot.

This is not the first time we’ve seen this. Going back a month, we were able to confirm that at any given point in time some people were able to see the Overlay, other were not.

I’m on a MacBook Pro 16, with latest OS, latest versions of Safari, Chrome, FireFox, and none of them sees the Overlay at this point in time that channel, even while others can. I’m actually able to see the extension on some other channels.

There is no right-side icon on the viewing screen allowing the extension to be on or off. It’s simply not there, and there’s no iFrame for the extension the browser inspector. That suggests it’s not a coding error on our end but rather a Twitch side bug where sometimes an Overlay is served up and rendered, other times it is completely ignored.

2

Sounds like

Where the streamer changes what extensions are active and the updated list is not pushed to connected clients properly as the client is disconnected/not correctly connected. A refresh by the user reloads the data from master

3

It’s possible the streamer changed the extension during their webcast. We wouldn’t be able to tell for sure, but my understanding is they have not, in part because we’ve seen this happen multiple times, and our understanding, in conversations with the streamer, was that they hadn’t made any changes.

But going on the assumption that they HAVE changed their extensions mid-stream… Are you saying in that situation viewers who had been seeing the Overlay continue to see it while newly-arrived viewers do not?

Or are the results erratic where some newly-arrived viewers see the Overlay and other newly-arrived viewers do not.

Note: A prior question attempted to address this same issue: Is it possible for an Overlay Extension to default / automatically open and/or close?
When we posted that question we were wondering why some viewers were seeing the extension and others were not.

Also note: We (developers) may have already lost this battle with our client. From their perspective the Overlay Extension is not a reliable feature. They can see the extension works, they can coordinate with streamers to deploy the Extension, but no one has any confidence that the Overlay is displaying for all viewers of a given streamer’s webcast.

4

I’m saying if extensions are changed during a stream

existing viewers see the previous setup
new viewers see the new setup

Where setup is whatever that setup maybe.

For me, I’ll swap CohhCarnage Video and Dropped Frames (or vice versa) into the Active Video Overlay and it won’t swap them for “Active viewers whom have had the stream open all day” but new visitors and people that reload the page will get the updated stream setup.

I’ve not been able to replicate this problem

The problem I describe only talks about when the streamer changes what is active.

With the problem you describe it suggests it’s not what I describe,

If your extension is not appearing for some reason it could be ad/script blockers userside interfering, BTTV/FFZ extension blocking or something else.

Either way, the problem you describe, if the streamer is not changing extensions is different to what I describe in my GitHub issue. But there are no other reports of this issue, since it should be effecting others. So I wonder if adblocking scripts or similar are coming into play for you. Causing the issue

In this scenario,

  • the streamer turned the extension off mid stream (can even occur when not live and this occurs),
  • some viewers will remain see-ing the extension as active.
  • new viewers won’t see an extension at all as it was turned off.

totally ignoring issues where BTTV/FFZ/other stuff have blocked extensions loading at all.

As covered in that issue.

Extensions can’t self open, only self close.
An extension can detect the width of the stream and choose not to display anything (aside from a warning to make the page bigger)

But your problem is that you are not even getting the extension taskbar, which points either to the extension not being active, or something else going on that might be, beyond your control.

5

But your problem is that you are not even getting the extension taskbar, which points either to the extension not being active, or something else going on that might be, beyond your control.

It’s weirder than that. What I saw yesterday was that sometimes (albeit occasionally) the extension taskbar would briefly flash our extension, but then it would disappeared again. At no point did the Overlay itself appear – at best just the taskbar, and then only occasionally and briefly (for less than a second). At no point was I able to find the extension listed as an iFrame in the browser inspector, suggesting it never loaded. Mind you the very same Overlay was working fine on other streams running at the same time. And also at the same time I was seeing data pipe in to our server from that streamer, suggesting for some viewers the Overlay was up and running for some but not for me.

As covered in that issue. Extensions can’t self open, only self close.

Yes, understood. That was very helpful in resolving that question. The reason I brought up the prior post is that then as now we were experiencing these inconsistent Overlay renders, where some viewers were seeing it, and others were not. Even my experience was mixed: sometimes seeing it render on those days, sometimes not. And that brief taskbar appearance: flashing on, then disappearing, was also a thing. (That’s what prompted the original question: about whether Overlays can auto open / close)

it could be ad/script blockers userside interfering, BTTV/FFZ extension blocking or something else.

Possible. Safari’s latest browser (released this month) has a new on-by-default tracker blocker. Considering I was able to see the Overlay play on other streamers’ channels suggests it’s not blocking our extensions’s iframe. We don’t have “trackers” but I don’t know for sure how Safari is defining what it detects. In any event we were testing with not only Safari, but also Firefox and Chrome, all on Mac OS

I’m saying if extensions are changed during a stream
existing viewers see the previous setup
new viewers see the new setup

That would make sense. I’ll try to confirm whether they made any changes mid-stream.

Thanks.

6

As best as I can tell – It’s turned out to be difficult to get definitive info back from the streamers – but looking over the data feed and keeping an eye on traffic, it seems there may be a Twitch-side bug that manifests itself when there are large numbers of visitors to a particular stream using a Full Screen Overlay.

At some point the Overlay becomes unreliable – it’s installed, but it only sometimes loads / sometimes doesn’t. It seems to have nothing to do with the streamer changing settings / installation of the Overlay. Perhaps.

We seem to have no problem where traffic is under 5,000 viewers per day (though I can’t be sure – perhaps even at those numbers the Overlay doesn’t load for X percentage of viewers.

Above 10 or 15,000/day we’re seeing it. On a day with 400,000 visitors we saw 60,000 loads.

7

Do you have any EBS, or API requests, that could be struggling to scale? If there are issues when there are a large number of viewers that would usually indicate a problem with scaling on your end, as there are many successful Video Overlay extensions that scale without issue to hundreds of thousands of concurrent users.

8

Possible but doesn’t seem likely. There’s one server handling API requests. The requests are data only and all under 1kb – even under 100bites. That server handled the 60,000 requests no problem and has been bench tested multiple times to handle as many as 10M requests per day. We’ve tested turning off the server – server not returning data to the extension, and the extension nonetheless loads.

What makes this issue challenging is we (and for that matter others) have very little ability to know when an extension load fails for a particular viewer. From our perspective it may be loading just fine, while others see nothing. The only way we find out about it is a) if, by chance, it’s our browser that’s not seeing the load, or b) we get analytics feedback from the streamer showing they had X # of viewers vs our Y # of extension loads.

9

Also, keep in mind, when the extension doesn’t load for a particular viewer there’s not even the extension taskbar indicating its existence. The taskbar is beyond the scope / reach of the extension, which is why, at the moment, we’re under the impression this is a Twitch-side issue.

10

I’d suggest trying to contact those who are experiencing the issues, and seeing if anyone can open dev tools and provide you with the info to narrow down the issue. My hunch is still something that it’s on your side, such as improper onAuthorized handling (I’ve seen some extensions that work based on lifecycle events, or are JS heavy, that have other processing/mounting happening prior to onAuthorized being handled which causes Twitch to think the extension has failed and doesn’t display it), or it could be range of issues but impossible to diagnose without knowing what your extension is doing.

11

As luck would have it, I’ve been one of those whose experienced the issue and did chase through the dev tools
There’s no console error.
In fact, there’s no iframe for the extension in the streamer’s main page. So it’s not that the extension fails to appear, it’s that it’s iframe that holds it never loads in the first place, suggesting its internal JS never even runs.
Again, there’s not even an extension taskbar icon. *

( * Actually it’s a little stranger than that: occasionally – but not always – there IS an extension taskbar icon, but it only lasts a split second before disappearing. If the problem were a result of JS coding , I’d expect the extension’s iframe to persist and fail to render, and an error to appear and persist in the console.)

I suspect Twitch does not have code to remove an iframe from the streamer’s DOM after loading. It seems more likely the iframe never loaded to begin with.

12

All of this points to a problem on the Twitch side: failing to load the extension as opposed to failure of the extension.

13

Another thing to check then would be the network tab in devtools, that way you can see if it attempts to load the HTML (which would in turn load the JS). That would help rule out any client-side issues such as browser extensions that may be blocking it from loading (and extensions that fail to correctly load can result in the sidebar not loading if there are no functioning extensions).

14

Did that as well. In my particular case I have no extensions whatsoever, and tested it across several browsers: Safari, Chrome, Firefox, and TOR (effectively a stripped version Firefox but coming from a different IP)

When the extension fails to appear for me, all browsers are affected, suggesting it’s not extension related.

Keep in mind, the extension usually DOES appear for me. If I check the data feed on our server and can see someone has recently loaded the extension, I can see which stream that came from, and generally speaking I will be able to see it too.

The exception has been for streamers with large numbers of viewers. I can see their hits coming in, and usually I can load the Overlay, but sometimes I can’t. Again, it varies throughout the day and seems to affect others as well.

Since the extension is coded to load and render whether or not it gets a response from our server, and since I can see others feeding data to our server even when, at times, when I can’t load the Overlay myself – that suggests something outside of our scope.