overwolf.media.replays.getState gives false status in secondary windows

Steps to reproduce:
Prerequisite: having 2 windows in the app

  1. In main window, turn on capturing
    These are the settings I used, whereas enabledHighlightFeatures is an Array of feature names, e.g. [‘kill’, ‘death’]:
const settings: ReplaySetting = {
  settings  : {
            video: {} as StreamVideoOptions
          } as StreamParams,
          highlights: {
            enable            : true,
            requiredHighlights: enabledHighlightFeatures

this.$overwolf.media.replays.turnOn(settings, console.log)
  1. once it’s turned on, try to get the state in both the Main window and the second window:

Expected result: get the correct state for isOn
Actual result: within the main window (the one that turned capturing on) the state is correct, in the other window it remains false

Impact for my app: [mid]
It’s not breaking anything (anymore after figuring it out), but it means not being able to rely on the result of the getState call, which might produce hard to detect bugs for other developers too.

@Colorfulstan If you call to start capture on one window, and register for stop capture event on this window AND another window, you are going to find out that the event is triggered in both windows (as expected) - but the second window will not get all the info from the callback (for example, the URL of the captured media).
What I wanted to say here, that it’s the way our API works. If you are using our recommended background controller methodology, you should not have any issues with that.

I know that it’s sometimes can be confusing, and I might improve it in the future. If you think that we should add some more explanation on that somewhere on our site, please let me know.


I don’t know if I understand how that is related to the function getState. I do control starting and stopping in a background window.

My use case is, I want to show a “start capture“ button, if capturing is not already turned on.
But the getState method gives me false information, and is therefore not reliable for information.
It also is not stated on the documentation of the method, which would be necessary if that’s the expected behaviour.
However, I don’t think this is desired behaviour at all for an informational method.

@Colorfulstan excuse me for some reason I mixed up between your question and a question regarding overwolf.windows.onstatechanged… but it’s a very similar answer: currently, you get the state only from the window that turned the capturing on. I’m not sure why it designed like this. But as it’s a low priority and you have a workaround, I think that the best option is to add some note in the docs, which I did:

With your permission, I will close the ticket. Please feel free to comment.