After upgrade of Mac to the Golden Gate OS, the Topaz Video crashes every time I switch the monitor to another computer. After I switch back to mac, the GUI is crashed, the ffmpeg process still remains working and has to be killed manually.
This behavior is repeatable.
I have experienced this a lot as I was testing macOS beta versions. My current solution is to remove the audio from the video file, then Video AI does not crash. After processing, I add the audio back in.
The crash appears to be associated with a racing condition in the mpv library (this is as far as I can go, need the Topaz team to provide more insights)
Please let me know if you need some ffmpeg examples to perform this task.
Hope this helps!
Dom
P.S. I also export to PNG files so I can resume processing without losing anything. I have also written some scripts to monitor progress and perform backups in real-time
I just updated Topaz Video and before that to macOS Golden Gate 27. Application crashed trying to open twice and then crashed trying to upscale 2-minute video to 4K twice. Crash whether or not on computer or being charged for tokens in Cloud. Solutions?
Can you send the logs and crash reports to the support team for review into this situation? help@topazlabs.com
To gather logs, please select Help > Logging > Get Logs for Support and attach the zip file to your reply.
Here is a video to help with the steps of how to collect the logs.
Yes, I can confirm it is this issue. When the input file has no audio all works fine.
Curious, that before the Golden Gate problem did not manifest.
Well it is a bug then and as Topaz it is not a free software, I am awaiting a fix.
I just tried Topaz Video 1.7.0 as a demo on my M5 Max and it crashed as the video was finishing.
I’d like to buy Topaz Video, but I’m waiting until it actually works on macOS 27.
By the way, on Jul 29 I have submitted to Topaz another bug. When upscaling some files with rhea on Windows the process of upscaling fails just at the start. On Jul 30 I have got a reply from helpdesk to apply a workaround, to not use the automatic advanced tuning, but select a manual one and then click the ‘estimate’ button. It is ok with couple of files, but it is not a solution when 100+ files need to be processed.
The helpdesk wrote ‘I’ve passed this info along to our team and also created a bug report for Rhea on auto for our team to look into fixing!’… over two months have passed and the bug has not been fixed.
The new Mac Studios will start arriving next week with MacOS 27 installed. They need to have it working soon.
I have been trying Topaz version 1.7.1 with OS 27. Constantly crashes while using Starlight precise or Starlight Mini. The only way I have been able to get an extended run is to disable the energy saving setting that turns off the monitor. I also have to leave the topaz app running on the screen rather than minimizing it to the bottom bar.
Can you try removing the audio stream from your video? I have been experiencing this for months and found this was effective.
Topaz Video Crash Report - redacted.txt (226.0 KB)
attached is the crashed info for your investigation please.
Looking at your crash report, this could be related to the audio change issue I reported a while ago (I can see libmpv and CoreAudio)
Thread 34 Crashed:: Dispatch queue: HALC_ProxyNotification Call Listener Queue\
0 libmpv.2.dylib 0x1231485ec mp_msg_va + 40\
1 libmpv.2.dylib 0x123149a6c mp_msg + 28\
2 libmpv.2.dylib 0x123213aa4 hotplug_cb + 40\
3 CoreAudio 0x1a2fa9f2c HALObject::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 2260\
4 CoreAudio 0x1a2e24db4 HALSystem::PropertiesChanged(unsigned int, AudioObjectPropertyAddress const*) + 272\
5 CoreAudio 0x1a2e25818 HALSystem::ObjectsPublishedAndDied(unsigned int, unsigned int const*, unsigned int, unsigned int const*) + 2540\
6 CoreAudio 0x1a2e25eb8 HALSystem::AudioObjectsPublishedAndDied(AudioHardwarePlugInInterface**, unsigned int, unsigned int, unsigned int const*, unsigned int, unsigned int const*) + 196\
7 CoreAudio 0x1a2ef1084 HALC_ShellPlugIn::ProxyObject_PropertiesChanged(unsigned int, unsigned int, AudioObjectPropertyAddress const*) + 964\
8 CoreAudio 0x1a2f461f0 HALC_ProxyNotifications::CallListener(unsigned int, unsigned int, unsigned int, AudioObjectPropertyAddress const*) + 84\
9 CoreAudio 0x1a2f4669c void applesauce::dispatch::v1::async<HALC_ProxyNotifications::_SendPropertiesChanged(unsigned int, unsigned int, AudioObjectPropertyAddress const*, bool, std::__1::vector<HALC_ProxyNotifications::Listener, std::__1::allocator<HALC_ProxyNotifications::Listener>> const&)::$_0&>(dispatch_queue_s*, HALC_ProxyNotifications::_SendPropertiesChanged(unsigned int, unsigned int, AudioObjectPropertyAddress const*, bool, std::__1::vector<HALC_ProxyNotifications::Listener, std::__1::allocator<HALC_ProxyNotifications::Listener>> const&)::$_0&)::'lambda'(void*)::__invoke(void*) + 60\
10 libdispatch.dylib 0x19f8ca5a0 _dispatch_client_callout + 16\
11 libdispatch.dylib 0x19f8b8fc0 _dispatch_lane_serial_drain + 744\
12 libdispatch.dylib 0x19f8b9af4 _dispatch_lane_invoke + 448\
13 libdispatch.dylib 0x19f8bae74 _dispatch_workloop_invoke + 1604\
14 libdispatch.dylib 0x19f8c3f58 _dispatch_root_queue_drain_deferred_wlh + 284\
15 libdispatch.dylib 0x19f8c385c _dispatch_workloop_worker_thread + 720\
16 libsystem_pthread.dylib 0x19fa6df9c _pthread_wqthread + 292\
17 libsystem_pthread.dylib 0x19fa6cce0 start_wqthread + 8\
Have you noticed a crash when turning on/off a monitor or changing an audio device or connecting a bluetooth headset?
The solution I found is to remove the audio stream from the video file using ffmpeg or other tools. Then it’s been rock stable for me on macOS 27.
hope this can help your situation.
So far, it has been stable with OS 27.2 Beta. I have used Rhea and Starlight Mini without crashes. Will try Starlight Precise next
Starlight Precise and OS 27.2 Beta have been playing nice for 15 hours. Still very slow, but no crashes.
It is because your mac is connected to its own monitor that is not being switched between seveal inputs. If you have connjected let’s say pc and mac to the same monitor, than as soon as you switch to pc and back to mac the topaz video will be dead.
I was getting crashes regardless of the monitor setup with OS 27.0. Now it appears to be running reliably on Starlight Mini and Starlight precise. and OS 27.2 Beta. I did disconnect my monitor while running Starlight Precise and Topaz immediately crashed. There is obviously a problem, but the monitor issue does not affect my use of Topaz as long as I don’t need to switch the monitor. It would be nice if the Topaz team would give us an update on fixing the problem
The issue is around detecting or changing the audio device. In my case, if I connect or turn the HDMI monitor on, CoreAudio detects a new audio device (HDMI Audio). This generates the crash. When the monitor is on, switching manually from mac speaker to HDMI audio also crashes.
If your monitor does not support audio, it’s possible that no new audio device is detected and you do not run into the racing condition that causes the crash.
I have macOS 27 Beta 2 but I always remove the audio prior to processing, so I don’t run into the issue. I haven’t tried to prove the problem was still relevant.
Just tried it witth hd->4k with rhea (video+audio). The crash is immediate upon switching monitor inpuit.
I have a Mac Studio with an M4 Max CPU. Unfortunately, Video AI has been unusable since I upgraded to macOS 27.
Topaz Labs had plenty of time to test the software during the beta cycle, but it looks like they didn’t even do basic testing.
It’s too bad that they aren’t showing any accountability or offering a credit to compensate those who upgraded to macOS 27, since the software currently doesn’t work with any model.
Which version of Topaz are you using and which version of MacOS are you using?
