Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Restart a stream doesn't work anymore in OBS Studio #2865

Closed
DJ-PD opened this issue May 4, 2020 · 34 comments · Fixed by #4147
Closed

[BUG] Restart a stream doesn't work anymore in OBS Studio #2865

DJ-PD opened this issue May 4, 2020 · 34 comments · Fixed by #4147
Assignees
Labels
Regression Regression from a previous version

Comments

@DJ-PD
Copy link

DJ-PD commented May 4, 2020

Platform

Operating system and version: Windows 10 v1909 64bit
OBS Studio version: v25.0.8

Expected Behavior

Start Streaming = start the stream (it's ok and works today)
Stop Streaming = stop the stream (it's ok and works today)
Start Streaming again after a stop = shall start the stream as task 1 as with OBS Studio v24.0.3

Current Behavior

Start Streaming = start the stream (it's ok and works today)
Stop Streaming = stop the stream (it's ok and works today)
Start Streaming again after a stop = stream doesn't start, control button "Start/Stop Streaming" is totally grey and I can't do any thing with this button. Exit OBS studio works but the program still runs in background and process task need to be ended via Windows task manager. Thereafter can OBS Studio be started and used again until next stop.

OBS Studio v25.0.8 part of log file when issue occur

11:29:13.744: ---------------------------------
11:29:13.744: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
11:29:13.744:
11:29:13.746: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
11:29:13.750: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
11:29:16.507: [rtmp stream: 'adv_stream'] Connection to rtmp://192.168.0.174/live/ successful
11:29:16.514: ==== Streaming Start ===============================================
11:29:52.048: [rtmp stream: 'adv_stream'] User stopped the stream
11:29:52.048: Output 'adv_stream': stopping
11:29:52.048: Output 'adv_stream': Total frames output: 880
11:29:52.048: Output 'adv_stream': Total drawn frames: 957
11:29:52.053: ==== Streaming Stop ================================================
11:29:52.116: warning: 2 frames left in the queue on closing
11:32:28.898: [jim-nvenc: 'streaming_h264'] settings:
11:32:28.898: rate_control: VBR
11:32:28.898: bitrate: 2500
11:32:28.898: cqp: 20
11:32:28.898: keyint: 125
11:32:28.898: preset: llhq
11:32:28.898: profile: high
11:32:28.898: width: 1920
11:32:28.898: height: 1080
11:32:28.898: 2-pass: false
11:32:28.898: b-frames: 2
11:32:28.898: lookahead: false
11:32:28.898: psycho_aq: true
11:32:28.898:
11:32:28.920: ---------------------------------
11:32:28.921: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
11:32:28.921:
11:32:28.922: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
11:32:28.923: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
11:32:28.927: HandleInvoke, error decoding invoke packet

Steps to Reproduce

Start Streaming = start the stream
Stop Streaming = stop the stream
Start Streaming again after a stop = stream doesn't start

Additional information

Tested both v24.0.3 and v25.0.8 / uninstalled and installed 3 times and totally left the server side.
Version 24.0.3 works as a charm every time but 25.0.8 fails on the second "Start Streaming" all the time.
I refer to closed case #2849 and ask for a investigation before closing this new support ticket.

@notr1ch
Copy link
Member

notr1ch commented May 4, 2020

What RTMP server are you streaming to?

@DJ-PD
Copy link
Author

DJ-PD commented May 4, 2020

MistServer

@notr1ch notr1ch added the Regression Regression from a previous version label May 4, 2020
@armpdq
Copy link

armpdq commented May 9, 2020

i can confirm, same issue with flussonic rtmp server

@govz
Copy link

govz commented May 9, 2020

The same issue is happening with Flussonic Media Servers, the exact same issue.
And I got the same in logs

21:30:54.208: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://xx-xx/static...
21:30:54.444: HandleInvoke, error decoding invoke packet

@chgordonchoi
Copy link

chgordonchoi commented May 12, 2020

I can confirm such issue also occur when using Castr multistreaming service. The error log also ends at

HandleInvoke, error decoding invoke packet
before manually shutting down.

In our case, we have the same issue since v25.0 and all the way up to v25.0.8

notr1ch added a commit to notr1ch/obs-studio that referenced this issue May 13, 2020
This reverts commit 2b131d2.
Trying to keep state in the RTMP structure wasn't working well and was
introducing regressions such as
obsproject#2865.

This commit moves mbedTLS initialization to obs_module_load, which is
the only place we can guarantee that loading / freeing occurs on the
same thread.
notr1ch added a commit to notr1ch/obs-studio that referenced this issue May 13, 2020
This reverts commit 2b131d2.
Trying to keep state in the RTMP structure wasn't working well and was
introducing regressions such as
obsproject#2865.

This commit moves mbedTLS initialization to obs_module_load, which is
the only place we can guarantee that loading / freeing occurs on the
same thread.
@notr1ch notr1ch self-assigned this May 15, 2020
@ZloyDyadka
Copy link

ZloyDyadka commented Jun 16, 2020

Same issue with Flussonic media server
Additional: https://obsproject.com/forum/threads/obs-multiplatform-refuses-to-start-stream-by-2nd-try.36394/

@eric
Copy link
Contributor

eric commented Jun 17, 2020

I'm running into problems on v25.0.8 properly reconnecting to an nginx-rtmp-module streaming server. It sometimes will reconnect but other times will not. I am using rtmp:// and not rtmps://.

@Thulinma
Copy link
Contributor

Thulinma commented Jun 21, 2020

Hi there! MistServer dev here.
I've found the reason for this bug: the librtmp state isn't being correctly reset on reconnect.
This causes the connection to be started with an incorrect max chunk size (whatever was in use when the last disconnect happened, and not the 128 byte RTMP default), and thus fails to parse multi-part chunks.
Most servers set a new max chunk size only right after sending the _result response to the connect call, since some RTMP implementations fail if you do so before responding to the connect call.

In short: please reset the librtmp internal state in between reconnect attempts, as fixing this on the media server side will break other client implementations instead. 🙁

@Banderi
Copy link

Banderi commented Jul 1, 2020

Oh, I've been trying to find the culprit to this for ages... Google served me no luck and yet it was reported here all along! I'm glad the cause was narrowed down and I wasn't just going crazy. Hopefully it's an easy fix!

@eric
Copy link
Contributor

eric commented Jul 2, 2020

I found that my issue was not this problem but was caused by #3078.

@LosTigeros
Copy link

LosTigeros commented Jul 19, 2020

I've tested it on master and it still can't connect after one disconnect.

[rtmp stream: 'simple_stream'] Connecting to RTMP URL rtmp://stream.tokyo.[redacted]...
[rtmp stream: 'simple_stream'] Interface: Intel(R) PRO/1000 MT Desktop Adapter (ethernet, 1000 mbps)
[rtmp stream: 'simple_stream'] Connection to rtmp://stream.tokyo.[redacted] successful
obs_encoder_audio: Null 'encoder' parameter
==== Streaming Start ===============================================
[rtmp stream: 'simple_stream'] User stopped the stream
Output 'simple_stream': stopping
Output 'simple_stream': Total frames output: 311
Output 'simple_stream': Total drawn frames: 404
==== Streaming Stop ================================================
[rtmp stream: 'simple_stream'] Connecting to RTMP URL rtmp://stream.tokyo.[redacted]...
[rtmp stream: 'simple_stream'] Interface: Intel(R) PRO/1000 MT Desktop Adapter (ethernet, 1000 mbps)
RTMPSockBuf_Fill, remote host closed connection
[rtmp stream: 'simple_stream'] Connection to rtmp://stream.tokyo.[redacted] failed: -3
==== Streaming Stop ================================================

And in the rtmp server logs:

client connected '***.***.***.***'
too big message: 5242880, client: ***.***.***.***, server: 0.0.0.0:1935
disconnect, client: ***.***.***.***, server: 0.0.0.0:1935
deleteStream, client: ***.***.***.***, server: 0.0.0.0:1935

After increasing max_message to 10M on the server OBS just freezes while reconnecting.

[rtmp stream: 'simple_stream'] Connecting to RTMP URL rtmp://stream.tokyo.[redacted]...
[rtmp stream: 'simple_stream'] Interface: Intel(R) PRO/1000 MT Desktop Adapter (ethernet, 1000 mbps)

And after connecting for the 2nd time it just get's stuck at connecting.
image

@Banderi
Copy link

Banderi commented Sep 21, 2020

Any updates on this?

@Banderi
Copy link

Banderi commented Oct 1, 2020

I have updated to 26.0.0 this morning and it seems as if the bug is gone! There have been tons of bugfixing in the version so I'm not sure if this was one of them, or one of them was tangential to this issue and was fixed as consequence, nonetheless I couldn't find it mentioned in the changelogs at first glance. I think we can set this as "solved" if anyone can confirm it was fixed?

@notr1ch
Copy link
Member

notr1ch commented Oct 1, 2020

This wasn't explicitly fixed in v26, but I can also confirm it's no longer crashing. One of the unrelated commits might be masking the issue.

@eric
Copy link
Contributor

eric commented Oct 1, 2020

@Banderi what behavior were you seeing? Was OBS hanging and needed to be killed and restarted? If so, it's likely you were running into #3078 that was fixed in 26.0.0.

@Banderi
Copy link

Banderi commented Oct 1, 2020

From what I understand it's not exactly the same bug, I saw the ticket you linked back in July but thought the behaviour fit better this issue here rather than that one. Nonetheless, it could be!

@Thulinma
Copy link
Contributor

Thulinma commented Oct 1, 2020

Looking at the changes, I don't think that particular pull request fixed this particular bug.
Probably something else that caused this problem to go away as a side effect.
If nobody else has been able to confirm this by next week, I'll try to make some time to confirm whether it was indeed solved.

@DJ-PD
Copy link
Author

DJ-PD commented Oct 3, 2020

Hi all, unfortunately I do have and see the same problem in v26.0.0.
Upgraded from working version v24.0.3 to v26.0.0 and same problem is back.
Extra note, untouched OBS settings and server side.

  1. Start the stream = Works good
  2. Stop the stream = Works good
  3. Start the stream again = Start/stop streaming button changes to "connecting" thereafter game over, nothing happens which looks like a refuse of a new connection.
    See below log (looks like we can see some more events after HandleInvoke error)...

12:54:50.186: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
12:54:50.186:
12:54:50.191: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
12:54:50.195: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
12:54:52.953: [rtmp stream: 'adv_stream'] Connection to rtmp://192.168.0.174/live/ successful
12:54:52.971: ==== Streaming Start ===============================================
12:58:35.827: [rtmp stream: 'adv_stream'] User stopped the stream
12:58:35.827: Output 'adv_stream': stopping
12:58:35.827: Output 'adv_stream': Total frames output: 5563
12:58:35.827: Output 'adv_stream': Total drawn frames: 5641
12:58:35.874: ==== Streaming Stop ================================================
12:58:35.946: warning: 2 frames left in the queue on closing
12:59:29.657: [jim-nvenc: 'streaming_h264'] settings:
12:59:29.657: rate_control: VBR
12:59:29.657: bitrate: 2500
12:59:29.657: cqp: 20
12:59:29.657: keyint: 125
12:59:29.657: preset: llhq
12:59:29.657: profile: high
12:59:29.657: width: 1920
12:59:29.657: height: 1080
12:59:29.657: 2-pass: false
12:59:29.657: b-frames: 2
12:59:29.657: lookahead: false
12:59:29.657: psycho_aq: true
12:59:29.657:
12:59:29.683: ---------------------------------
12:59:29.683: [FFmpeg aac encoder: 'avc_aac_stream'] bitrate: 320, channels: 2, channel_layout: 3
12:59:29.683:
12:59:29.685: [rtmp stream: 'adv_stream'] Connecting to RTMP URL rtmp://192.168.0.174/live/...
12:59:29.685: [rtmp stream: 'adv_stream'] Interface: Intel(R) 82574L Gigabit Network Connection (ethernet, 1000 mbps)
12:59:29.689: HandleInvoke, error decoding invoke packet
13:04:30.285: RTMPSockBuf_Fill, remote host closed connection
13:04:30.286: RTMP_ReadPacket, failed to read RTMP packet body. len: 16711680
13:04:30.286: [rtmp stream: 'adv_stream'] Connection to rtmp://192.168.0.174/live/ failed: -3

Downgraded to v24.0.3 and all is good again.

@Banderi
Copy link

Banderi commented Oct 3, 2020

It seems either I was having a different issue or the tangential fix only solved it for specific situations and not in the general case, I'd think. Still doesn't seem to me like #3078, my issue was perfectly described by the above and I do remember checking the logs gave me almost the same messages.

On the other hand it could also be that the servers I'm streaming to now (Picarto.tv) just changed on their end, the same day version 26.0.0 came up for me.

@Thulinma
Copy link
Contributor

Thulinma commented Oct 4, 2020

@Banderi As I am one of the people maintaining the streaming software on Picarto's servers, I can confirm that we implemented a workaround for this OBS bug months ago. OBS will work there, despite this bug being present. You're welcome. 😉

@DJ-PD
Copy link
Author

DJ-PD commented Jan 4, 2021

Upgraded to v26.1.0 but still the same issue as before, can someone else check and comment.
I am again forced to downgrade to v24.0.3 to get rid of this "one shoot of connection per application boot" phenomena.

@LosTigeros
Copy link

@Banderi As I am one of the people maintaining the streaming software on Picarto's servers, I can confirm that we implemented a workaround for this OBS bug months ago. OBS will work there, despite this bug being present. You're welcome. 😉

It'd be nice if you'd share us what workaround you did because that bug still exists.

@notr1ch
Copy link
Member

notr1ch commented Jan 4, 2021

Upgraded to v26.1.0 but still the same issue as before, can someone else check and comment.
I am again forced to downgrade to v24.0.3 to get rid of this "one shoot of connection per application boot" phenomena.

What server software are you streaming to?

@Thulinma
Copy link
Contributor

Thulinma commented Jan 4, 2021

It'd be nice if you'd share us what workaround you did because that bug still exists.

I describe the exact problem + how to fix it, here: #2865 (comment)
Our workaround detects OBS through matching the application version string, and sends a command to change the chunk size immediately after the connection comes in. This breaks several non-OBS RTMP implementations, which is why the version string match is needed. By forcing the chunk size immediately, we effectively sidestep the bug in OBS entirely.

EDIT: For reference, this is the exact code of our workaround: DDVTECH/mistserver@b45fd85

Just to be clear: this is 100% a problem in OBS, and easily fixable. Unfortunately I don't know the OBS code base enough to contribute a fix, but using my earlier post it should take a knowledgeable developer no more than a few minutes to fix this problem. Server-side software can work around it (as we have done), but that's not how this should be resolved at all.

@DJ-PD
Copy link
Author

DJ-PD commented Jan 7, 2021

When I raised this potential bug 2th of May 2020 (#2849) it was ignored and closed with a comment that the issue is on server side. A new case was opened 4th of May asking for a deeper investigation before just closing the ticket.
Other OBS users see the same phenomena and several server DEVs has been forced to implement quick fixes. Thulinma investigated, comment and as I also believe served a possible solution on a silver plate 6 month ago. Why is this still ignored?

@mmusicman
Copy link

mmusicman commented Jan 10, 2021

Hi Newbie here..

The newest versions of OBS caused me GREAT GRIEF! I was live-streaming a New Year's Eve event (to Mistserver), and had to constantly keep rebooting the program when the stream was interrupted (in my case due to exceeding my own bandwidth issues). Every time it hung, I also had to shutdown a persistent OBS in task manager too, which added to my troubles. The video essentially was unreliable.

I had no idea what "I" was doing wrong.. only to learn later the program is broken.

The issue that prevents the OBS program from "start > stop > restarting" again.. also prevents the "auto-reconnect" from working as well. To duplicate the issue, just temporarily physically pull the network connection, then reconnect.. OBS will hang indefinitely.

Through much forum searching I discovered that someone posted that earlier versions (up to) 24.03 still worked fine, which I found to be the case for me too. After that version, they no longer work correctly. I tried the most recent version 26.1.1 and it failed like the others. I'm back with 24.03 which works great. (should note I found the same issue on both 32 & 64 bit machines)

Workaround: I've found with newer OBS versions that if I setup the stream with udp://ip:port/streamname/live.. it continues streaming (even with network interruptions). I don't know if using UDP for live streaming is a bad idea or not ... (I'm pretty new to video streaming) but it seemed to work, I assume since the stream (in this case) doesn't actually stop or disconnect.

@Fenrirthviti Fenrirthviti added this to the OBS Studio 27.0 milestone Jan 25, 2021
@Fenrirthviti
Copy link
Member

Tagging this to look at before v27. The fix for this is not simple, which is why we have not fixed it yet. The problem exists deep in librtmp and we haven't sorted out exactly what or where, and it's also difficult to replicate without access to a deployed custom RTMP server, which makes testing cumbersome.

@Thulinma
Copy link
Contributor

Thulinma commented Jan 26, 2021

@Fenrirthviti A cursory glance at the source code tells me uncommenting this line should do the trick.

Full explanation:
The problem is caused by m_inChunkSize not being set to the default value of 128 (RTMP_DEFAULT_CHUNKSIZE) on reconnect. A search in the source code tells me there are only two places where m_inChunkSize is written to, one being in the handler of the chunk size change message from the other end of the connection (good) and the other being on init (also good). The problem is thus that init is not being called on reconnect.
I'm assuming (based on function name alone) that try_connect is called for every connection attempt, which would mean that uncommenting that line should fix the problem.

Should this not be enough to solve the issue, I'd be happy to provide an RTMP endpoint for you to test against (without workarounds, so the bug triggers). Though I believe practically all streaming services are affected by this bug.

It looks like the problem was introduced in this commit, which fixed a thread safety issue in librtmp but also commented out the line in question (probably because it also initializes the TLS context). Splitting the TLS init and the RTMP state init into two separate functions should resolve that cleanly.

@Fenrirthviti
Copy link
Member

Doing that breaks RTMP authentication, which is why we have not just uncommented it. A different fix needs to be found.

@Banderi
Copy link

Banderi commented Jan 26, 2021

Might need more info if a back and forth of "can't do that" is to be avoided. How does that break authentication, and why does that only happen on versions of librtmp above the ones before that commit?

As far as I can tell, this has been going on for ages with no proper response while Thulinma and others have been giving the closest to a transparent explanation of what's going on, and piecing together how to fix it.

Moreover, this only happens in OBS and it only happens after said commit, and there wasn't another major issue like this one beforehand; so either literally no other streaming app uses librtmp, or they use a patched version/correct implementation, or whatever issue was solved by the commit is a compromise they are willing to accept.

@Fenrirthviti
Copy link
Member

@Banderi I understand that it seems like there is "no proper response" but we don't really have anything to report. It's been acknowledged, and we're looking in to how to properly fix it. I don't have the technical knowledge to explain the specifics, I will leave that to @notr1ch, but my understanding is that any attempted fixes have broken other parts of librtmp because of the thread safe issues referenced in that commit.

Have the proposed fixes been tested in OBS and all conditions and features that change might affect also been tested (which is really every single librtmp function that OBS uses to ensure there's no other potential regressions)? If so, why is there no PR for the fix? If there is a solution that has been properly vetted and tested, then it should be submitted as a PR so we can review and verify.

@Banderi
Copy link

Banderi commented Jan 26, 2021

@Fenrirthviti thanks for the full response. From what I'm seeing it's only surface speculation, even though I'm sure there's enough experience to be able to find the cause if given time and chance on their part (and again closest to explanation of what's going on than what has been given yet, which is more than we could ask for). That said, again I must stress I really find strange that this happens only in OBS and only after said commit, and no other streaming app has this issue. It doesn't add up to me.

You say it's a deeper problem with librtmp itself, which means there is indeed info that could be provided (if who you mentioned would have time to respond of course). What is the actual issue? Can you please provide a link to a ticket on their trackers, if it's been reported?

@Thulinma
Copy link
Contributor

I'll post a pull request after I get out of the office today with a clean solution that won't break threading or encryption. I figure that's the fastest way to get this fixed. Expect it somewhere in the next 10 hours or so, I'll link back to this issue to make sure it's found. 👍

Thulinma added a commit to Thulinma/obs-studio that referenced this issue Jan 27, 2021
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end.
This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library.
The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with.
Thulinma added a commit to Thulinma/obs-studio that referenced this issue Jan 27, 2021
Bug is caused by the internal connection variables not being reset on reconnect, leading OBS to both be unable to parse valid packets from and send valid packets to the remote end.
This commit splits RTMP_Init off into a new RTMP_Reset function, which resets these internal variables without re-initing the rest of the library.
The original RTMP_Init calls the new function, perfectly preserving the old behaviour while adding a new reset function to address the issue with.
Thulinma added a commit to Thulinma/obs-studio that referenced this issue Jan 27, 2021
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end.
This commit splits RTMP_Init off into a new RTMP_Reset function, which
resets these internal variables without re-initing the rest of the
library.
The original RTMP_Init calls the new function, perfectly preserving the
old behaviour while adding a new reset function to address the issue with.
@Fenrirthviti
Copy link
Member

Thanks for the PR, definitely the fastest way to get the ball moving. I'll make some time in the next few days to run through testing and make sure things that were causing issues previous are not affected.

jp9000 pushed a commit to Thulinma/obs-studio that referenced this issue Feb 1, 2021
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end.  This commit splits RTMP_Init off
into a new RTMP_Reset function, which resets these internal variables
without re-initing the rest of the library.  The original RTMP_Init
calls the new function, perfectly preserving the old behaviour while
adding a new reset function to address the issue with.

Fixes obsproject#2865
jp9000 pushed a commit that referenced this issue Feb 1, 2021
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end.  This commit splits RTMP_Init off
into a new RTMP_Reset function, which resets these internal variables
without re-initing the rest of the library.  The original RTMP_Init
calls the new function, perfectly preserving the old behaviour while
adding a new reset function to address the issue with.

Fixes #2865
1div0 pushed a commit to 1div0/obs-studio that referenced this issue Apr 22, 2021
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end.  This commit splits RTMP_Init off
into a new RTMP_Reset function, which resets these internal variables
without re-initing the rest of the library.  The original RTMP_Init
calls the new function, perfectly preserving the old behaviour while
adding a new reset function to address the issue with.

Fixes obsproject#2865
tommyvct pushed a commit to tommyvct/obs-studio that referenced this issue May 22, 2021
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end.  This commit splits RTMP_Init off
into a new RTMP_Reset function, which resets these internal variables
without re-initing the rest of the library.  The original RTMP_Init
calls the new function, perfectly preserving the old behaviour while
adding a new reset function to address the issue with.

Fixes obsproject#2865
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Regression Regression from a previous version
Projects
None yet
Development

Successfully merging a pull request may close this issue.