Closed gstudios2 closed 1 year ago
Seems like anyone using an external controller style device with websockets ends up crashing with this filter at the moment unfortunately. Hopefully it's not too hard of a fix because this simple filter is an absolute game changer.
Is Someone supporting this plugin still?
I have not been able to replicate the issue on my system yet, so if you have detailed steps to reproduce from a clean obs setup for me that would help.
Thanks for your response. I've got the information you asked me:
1) Made an obs fresh install. 2) Made a deckboard fresh install (the websocket controller) 3) Added a media source, and put an Audio monitor on that 4) The audio monitor is sending the signal to "A" 5) "A" in added also to the scene, as audio source 6) On the source "A", define a 2nd audio monitor filter sending the signal to "B"
Also have the same issue using SAMMI.
I could also get it to crash if I switch scenes, but basically if obs has ANY audio monitor filter, as soon as you restart it will cause a hard crash of OBS. I do have VB-Audio cables installed (not sure if this is relevant)
The situation is the same over here. When attempting to connect it via websocket, SAMMI causes OBS to crash. Both SAMMI and Audio Monitor are incredibly impactful, so it would be amazing if we could establish a connection between them.
Ready to send $10 to PayPal for a fix
Maybe someone found some tricky workaround?
Well, i´ve tested out the audio-monitor plugin as well, in combination with TouchPortal (connected through websockets). If Audio-Monitor is active, and one filter on any source is existing, OBS crashes after restarting OBS. If i remove this one (only one for testing installed) with active audio-monitor and websocket connected, everything is fine. If i readd the filter = OBS crashing.
The devices i send my monitoring through, are "online", so i guess it seems to be caused by 1st init of audio-monitor. The devices are physical - nothing virtual.
Tried to replicate this bug again today with OBS 29.1.3, audio monitor version 0.8.2 with Bluetooth, internal and virtual audio devices. Applications I tested with: Aitum, Streamer.bot, Deckboard, Sammi and Touch Portal. None of my tests has had a crash. Used a media source and a video capture device with audio monitor.
Can you check if the crash shows in windows event viewer and if it maybe created a .dmp file in %LOCALAPPDATA%\CrashDumps
If that is the case can you provide me that .dmp via a private message on discord or twitter.
Windows Eventlog (sorry, i use german): Name der fehlerhaften Anwendung: obs64.exe, Version: 29.1.3.0, Zeitstempel: 0x894f06bf Name des fehlerhaften Moduls: ucrtbase.dll, Version: 10.0.22621.608, Zeitstempel: 0xf5fc15a3 Ausnahmecode: 0xc0000409 Fehleroffset: 0x000000000007f61e ID des fehlerhaften Prozesses: 0x0x6998 Startzeit der fehlerhaften Anwendung: 0x0x1D9C88BF6E66158 Pfad der fehlerhaften Anwendung: E:\X-Streaming\OBS-Studio\bin\64bit\obs64.exe Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\ucrtbase.dll Berichtskennung: f333d292-94d0-42e8-9283-9b4843db8fb1 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
I made a fix, can you test if it works for you? https://github.com/exeldro/obs-audio-monitor/actions/runs/5783088154 at the bottom of that page you should be able to download a test version when you are logged in on GitHub
Downloaded, seems to be working.
Fixed with release 0.8.3
Obs closes (with no crash reports)
SAME
I am running OBS v30 in the newest version with 0.8.3 - no problems since fix.
I use an application called deckboard(*) trough websocket in order to control visibility of the sources
When audio monitor is put on some audio sources, and external application is connected via websocket, OBS closes immediately when I change the visibility state of any source in any scene, even with a static picture or a text: at the same moment in which I change the visibility state, obs closes.
It happens even with audio monitor filters put on the sources, but off.
I'm sending you the log file, with websocket debugging information 2023-04-25.19-53-05.txt