Overwolf.streaming - OBS crashes when quota is reached

TL;DR: if we fix the quota issue that our users are currently suffering from, every 2nd recording (on average) is going to fail in fullMatch

This is at High priority & Severity, and we don’t have a workaround for this issue.
On average, every 2nd match will not be recorded due to this issue.

In Outplayed,in full match capture, we use overwolf’s streaming API in order to record the full match.
we just fixed a faulty integration we had with the quota feature, and it seems that the quota feature 100% crashes the stream that is in progress.


  1. user starts playing (with current folder size bigger then mentioned quota)
  2. on match start, we call overwolf.streaming.start with all the relevant parameters (see sample streamSettings below)
  3. receive success from start streaming
  4. we receive an a streaming error of type Start_Error_Update_Driver from onStreamingError and OBS crashes

streamingSettings sample:

         "sub_folder_name":"League of Legends/League of Legends_6-28-2020_18-19-12-887"

After researching the topic, we noticed that the OBS log says:

21:47:13.369(ERROR)[2c84]: Start output error 'Overwolf Output' : fail to start
21:47:13.369(ERROR)[2c84]: failed to start recording [err: UnableToWritePath
21:47:13.369(ERROR)[2c84]: WarnWindowsDefender]
21:47:13.369(INFO)[2c84]: Failed start recording (id:5).

after digging into OBS docs, we found out that it’s probably related to file access & permissions:

UnableToWritePath="Unable to write to %1. Make sure you're using a recording path which your user account is allowed to write to and that there is sufficient disk space."
WarnWindowsDefender="If Windows 10 Ransomware Protection is enabled it can also cause this error. Try turning off controlled folder access in Windows Security / Virus & threat protection settings."

Logs: OverwolfLogs_2020-06-29_11-48-45.zip (1.4 MB)

@shir.brass got it.

Before I forward it to the R&D, are there any updates on this one since you opened it?

@eransharv as far as I know work on it was already done by platform and it’s pending release in 0.149.2 (which is planned for July 12th)

in the meanwhile, we made a workaround until this fix is deployed