VDMX & Vuo crashing on startup, file doesn't open unless I run Vuo in separate processes

Hi, I’ve had this issue on and off but this is now persistant and I’m unable to open the file again.

I load a bunch of Vuo comps in, and all is good. Until I close the project and reopen it. VDMX gets stuck on this screen, and I have to force quit VDMX. Following that - I cannot open VDMX again, it stops responding. Clearing the Vuo cache and restarting my laptop has not solved the problem, it’s as if it breaks the file. I have a show tomorrow and next weekend - has anyone had this and knows how to fix it? I had the previous version of VDMX installed when this happened now, and upgraded to 8.7.2.9 and it’s the same issue.

Thanks

Adding to this that I have tried to open another VDMX file that has Vuo comps and it’s stuck on a similar screen. Opening another file with QC compositions is fine.

Edit: I’ve tried opening the file with Run Vuo files in separate processes checked on and that seems to have fixed the issue. So does this mean one of my Vuo files is causing the crash? When I created the project and imported the Vuo files, I was able to run them for 2+ hours without a problem - it’s only when closing the project and re-opening it again that this happens.

I’m looking at the logs to see if there is a hint there was to what is causing this. Does anyone know what these errors mean?

I’d recommend sending a bug report and following up to support with an email. After it crashes and you re-open. Does it ask to send a report to VDMX? (Not the apple one, that goes to Apple). Thanks

1 Like

I know nothing about Vuo but that error is your audio driver crapping out. Have you tried a different soundcard or audio device?

2 Likes

@msp mentioning the audio driver makes sense. I had an audio routing issue which I was trying to replicate for David but for me it was intermittent and difficult to reproduce.

On the audio side I was using Sound Siphon and switched to Loopback along with b8.7.2.9 which appeared to solve my crashing issues. This was in August and I’ve not had any regular crashing since. I’m also a Vuo user but not heavy. I use audio routing for test/development sessions 4-5 times a week and have done around 10 VDMX based jobs (average 8 hours) with this version of VDMX and all good.

Actually that’s likely a red herring about audio. ASIO is an audio driver protocol but it looks like it’s also the name of a c++ networking lib called boost.asio!

Likely one for the devs here then:

https://stackoverflow.com/questions/67754693/asio-bad-file-descriptor-only-on-some-systems

1 Like

Ok, so do you think the red herring made it difficult for me to replicate. I was obviously not thinking about network I/O. Maybe a suggestion for the testers to turn off / limit network activity as a production machine to see what happens. When I was having issues I would have been using various network protocols but limit this when live.

I’m totally guessing here as I don’t know the codebase and just did a 2 minute Google on the error log but the thread above seemed to say they coded around the issue as a solution. Or at least certainly didn’t uncover a root cause that demonstrated the behaviour so reproducing it consistently could be tricky.

Really sounds like one for the devs to debug to me.

Thanks for the input here, I was able to do the show on Saturday without issues, and able to re-open VDMX projects containing Vuo files when I have Run Vuo files in separate processes checked on, so that is at least a workaround for now. I will compile a bug report and mention the audio / network comments above. Sidenote, I am using iShowU Audio Capture as a replacement for Soundflower as it was a free solution. I do suspect this crash is related to Vuo files since running in separate processes sorts out the issue.

Hi again

I have identified the issue. The issue was with an Vuo Image Filter Protocol file that I had as a effect on the VDMX mixer.

In the end it was not a solution to Run Vuo files in separate processes as it means that triggering a new file causes the VDMX output window to pause each time a new Vuo file is loaded into another channel, even if it has been loaded in before. This was disastrous for my upcoming show on Saturday. After some troubleshooting I noticed the below error in the console. By removing this Vuo filter that I made called “PixelStretch_Audio_Offset” I am able to open and run VDMX without Run Vuo files in separate processes and VDMX loads up much quicker with the Vuo files now too. I assume this is a bug with the Vuo Image Filter, there is no way to set the width and height within that protocol.

I hope this helps someone else, I was very stressed for a little while there. I will file a bug report.

|2021-10-12 23:32:54.468 VDMX5[16502:2247263] ||err: no width port name, -[VuoGLScene _applySize] - /Users/joellesnaith/Library/Application Support/VDMX/vuoFX/PixelStretch_Audio_Offset.vuo|
|---|---|---|
|2021-10-12 23:32:54.468 VDMX5[16502:2247263] ||err: no height port name, -[VuoGLScene _applySize] - /Users/joellesnaith/Library/Application Support/VDMX/vuoFX/PixelStretch_Audio_Offset.vuo|


Edit: pasted a screenshot too