Embedding twitch channel and expectations

There is no Category for embed so I’m using the API instead.

I’ve used the recommended method of "embed Everything’ and am receiving constant messages like this:

{eventName: ‘UPDATE_STATE’, params: {…}, namespace: ‘twitch-embed-player-proxy’}

It causes the browser to stop functioning because there are so many messages.

How can I debug this?

Link to broken page to help investigate please

Please try app.totalvu.live/demo/index.html#/conference

Go to the far left and click on the icon that opens the sidepanel. Click on the Twitch icon.
Open the browser console and observe there are many messages per second coming from the twitch embed.

I don’t see anything out of the ordinary.

It’s state update messaging which your JS is logging to the console.

Nothing seems to be broken the embed has embedded correctly. I see nothing wrong here.

Barry, Thank you for taking another look!
We have other embeds such as shopify, games etc. None of them are sending messages constantly.

The message seems to imply that something needs updating. However the channel is offline and nothing is changing within the embed. So we wouldn’t expect to receive any messages at all. Instead we are getting 2-3 per second.

You seem to be logging all the player/window/frame events.

The player is broadcasting a status update message. Regardless of anything actually changing. And it’s not a message that is normally exposed for use having a quick look over the docs. So you are abnormally capturing it anyway. It’s not even for your namespace.

Again for clarity:

Barry,

Wow thank you for helping. We do see a lot of load from these messages so if we can get the root cause and fix it that would be great. Here is how we are creating the embed:

  twitchLoad(){
    if (this.state.twitchEmbed == null)  {
      let te = new Twitch.Embed("twitch-embed", {
        width: this.state.twitchSize.width,
        height: this.state.twitchSize.height,
        channel: this.state.twitchChannel,
        parent: this.state.twitchParents
      });
      this.setStateOnMount((state) => ({
        ...state, twitchEmbed: te
      }));
      console.log("twitchEmbed ", te);
    }
  }

As you can see there are no unusual options or debugging or logging verbose type of parameters passed into the creation.

Regarding your evaluation of the messages, any idea why the player is sending these multiple times a second?
Also, how are we able to see them in our console if they are not for us? By namespace are we talking about DNS domain / App ID /Twitch channel or something else? We were using both ugcleague and ugc as our channels and received the messages with either one.

Thats just how the player works. The Player is talking to itself and you seem to be capturing them for some reason.

No if you look at the message being logged it declares a namespace.

There is something somewhere else that is binding to events and logging them.

I didn’t dig too deeply into your code to trace the issue, the log function appears to be a generic log function that will catch logs from I don’t know where.

SoundKeypad has window.addEventListener("message", this.receiveSoundFromIframe.bind(this));, and that accounts for 2 of the console.log functions.

ConferencePage has window.addEventListener('message', this.confMessage.bind(this)); accounts for the 3rd console.log.

You have 2 things listening to the event message which both console.log stuff. The Twitch embed triggers 1 message a second, that’s part of how the embed works. If you don’t want to see spam in the console you need to stop having event listeners for that same event spam messages to console.

Also as a side-note, your Emojis component seems to be excessively spamming requests for the same images.

1 Like

Hey Barry,

Great to get your time on this.

Looking deeper, these messages are for our embed (we are using the recommend name):

  1. offline message

It is telling us they are offline. Is there any way for us to poll the status, instead of being pounded with messages that all say offline?

Otherwise, are we expected to change our embed in some way when the channel is offline? For example, is there a way to destroy the player, then re-create it later?

  1. update state message

These messages:

{
    "eventName": "UPDATE_STATE",
    "params": {
        "channelName": "ugc",
        "channelID": "50796963",
        "currentTime": 0,
        "duration": 0,
        "muted": false,
        "playback": "Idle",
        "quality": "auto",
        "qualitiesAvailable": [],
        "stats": {
            "videoStats": {
                "backendVersion": "1.6.0-twitch.1-rc.1",
                "bufferSize": null,
                "codecs": "",
                "displayResolution": "0x0",
                "fps": 0,
                "hlsLatencyBroadcaster": 0,
                "playbackRate": 0,
                "skippedFrames": 0,
                "videoResolution": "0x0",
                "latencyMode": "Normal Latency"
            }
        },
        "volume": 0.5,
        "ended": false
    },
    "namespace": "twitch-embed-player-proxy"
}

Appear to be for something called “twitch-embed-player-proxy”

We are not using any sort of proxy in our workflow. Also, the event is UPDATE_STATE., but the state remains the same from message to message. So it seems something is incorrectly sending the UPDATE message even when there is nothing to update. This adds load to our app.

  1. nolinit

The last message we are getting is:
rcv from frame https://embed.twitch.tv says nolInit
I googled nolinit but found nothing obvious.

Call the API instead of asking the embed.
Or listen for PLAYING
Or check if the player is playing or not.

You are binding/listening to an event that is not documented and as dist notes you are binding to listen to ALL events from iFrames. Rather than just the ones you are supposed to use.

So your code is capturing extra events than those it’s supposed to listen on.

The fault is in your code not the Embed.

Thanks again for the input all.

From our side, the point isn’t that we notice the messages, but that we are seeing load from them. We are receiving at least 3-4 per second not just 1. There are three different messages.
Our goal is to reduce the number of messages we are receiving.

We need to be able to embed the channel. It seems that just by embedding the player, we are getting these messages.

We can turn of the logging of messages in general but that won’t reduce the load of receiving them.

Barry your suggestions :slight_smile:

Call the API instead of asking the embed.

  • the embed is sending the messages, we are not asking it. However, if we could poll …
    Or listen for PLAYING
    Or check if the player is playing or not.
  • These above make sense as long as the player is embedded.
    The problem is that we keep getting the messages regardless of when we listen for Playing.

Does the embed have a way for us to destroy it? We could just recreate it periodically then.

Thanks

You shouldn’t be listening to this message in the first place.

It’s not a bug or problem to be fixed. It’s just how the embed works.

document.getElementById(‘theplayer’).textContent = ‘’;

or change channels Twice.

An embed should also start playing when the stream goes live. So you can listen for the PLAYING event.

You are bound wrong.

See Twitch Embed example

  player.addEventListener(Twitch.Embed.VIDEO_PLAY, function() {
    log('The video is playing');
  })

Or bind to for Twitch.Player.ONLINE

Will report when a video is playing (ie the stream is live)

You are bound to every message the embed sends instead of a specific player event. Hence the “spam” in your console. As your logic is wrong.

Barry,

We are listening to the message event. That is because we use messages in our app, aside from the twitch embed. We check at the top of each routine that uses messages if the message is for that routine or not, so we don’t do any extra work, and so we can stop the message chain when it is consumed. Messages are not specific to iframes, as we use them over a real time messaging channel as well.

Regarding the frequency of logging versus frequency of messages, the Dist says we should be getting 1 per second. Since we are receiving three different messages (nolinit, update status, and offline) that makes at least 3 per second.

Regarding listening for the play event, that will only trigger if we have created the embed in the first place, correct ? Since we are receiving these messages when the player is created, listening for the layer event won’t help us stop the messages. We cannot listen for the Player ONLINE or VIDEO PLAY if we haven’t created the embed. Hope that helps clarify our thinking about these suggestions.

The problem is that you are bound and listening to all messages and capturing a undocumented/unsupported event that you shouldn’t be handling in the first place.

Correct, no embed no Twitch.Player events as documented.

No embed, no messages at all.

So if you want to do stream status (well player status) checks without an embed. You’ll need to consume the API or EventSub product(s) instead.

Hey Barry, Team,

The problem is that you are bound and listening to all messages and capturing a undocumented/unsupported event that you shouldn’t be handling in the first place.

From our perspective, we have discovered the source of extra load and interrupts. So
please try to see it from our side as well. Just because we ignore them doesn’t mean they are not happening and eating up performance and causing interruption to screenshare display.

Is there a documented way to destroy the embed so the messages will stop?
Something like TwitchEmbed.remove() (similar to jquery… FYI we are not using jquery)

I’ve tried to point out that all three of these message types appear to be unnecessarily frequent and repetitive. Hopefully that is helpful feedback to the team.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.