iina
iina copied to clipboard
iina
🔴 IINA 1.3.0 BUG: Error Cannot prevent display sleep!
System and IINA version:
- macOS Big Sur 11.6.2
- IINA 1.3.0
Expected behavior:
Actual behavior:
-
After running IINA for a period of time, about 2-3 days, there is a high probability of appearing
-
After this error, opening the media file, continuing playback after a pause, and dragging the progress bar will all result in this error
-
Restore settings and reinstall software did not fix it
-
After restarting the computer, the problem can be solved, but after a period of operation, it will reopen again
Crash report:
Error Cannot prevent display sleep!
mpv log:
Steps to reproduce:
- After running IINA for a period of time, about 2-3 days, there is a high probability of appearing
- [x] MPV does not have this problem.
It looks like IINA should be logging the details of the error. Can you try to enable logging (Preferences > Advanced > Enable logging, the quit & reopen IINA) and then if it happens again, grab the iina.log file and attach it here?
Summary
This is not a bug in IINA. This is how IINA informs you that macOS power management is broken on the Mac IINA is being run on.
Please take the follow actions:
Check if you have any products from Rogue Amoeba installed on your Mac. If any are found check to see if there are pending updates to those products that have not been installed. It is critical that Rogue Amoeba's Audio Capture Engine (ACE) framework is up to date.
The ACE framework may be included in products from other companies as discussed in the post Licensing Rogue Amoeba's ACE SDK. If you do not have products from Rogue Amoeba installed check for any audio related applications and see if they use the ACE framework. Make sure any audio related applications are up to date.
Check if you have Zoom installed on your Mac. If you do and are familiar with the history of security problems (see articles like tom's guide Zoom security issues: What's gone wrong and what's been fixed) and still want to use it, check to see if there are pending updates that have not been installed. Make certain the latest version is installed.
Please let us know if these actions resolve the issue.
If not then when the problem occurs capture and post the IINA log file as @svobs requested. Only the IINA log is needed, no need for the mpv log in this case.
Also, before rebooting macOS please open a terminal window and run the following command:
pmset -g everything >pmset.txt
Add the pmset.txt file to this issue along with the iina.log file. To add files to a GitHub issue you can drag and drop them when preparing a response.
Analysis
As we don't have an IINA log, this analysis is based on previous history with this kind of failure. The log can tell us if this is the issue seen before or a new variation on it.
IINA Behavior
The root cause of the issue is not in any way the fault of IINA. IINA is reporting that it called the macOS IOKit framework method IOPMAssertionCreateWithName and that method was not successful. IINA is calling that method merely to request that macOS not put the display to sleep. That request is never supposed to fail, and yet in this case it did. The error code returned by macOS should be in the IINA log.
The behavior of IINA in this case has changed in 1.3.0. In 1.2.0 IINA was trying to post the above error message, but failed to use the main thread resulting in a crash. In 1.3.0 that code has been corrected to properly post the alert.
What can be questioned about IINA's behavior is whether this situation should be treated as a fatal error. A typical software industry practice is to not even check the return code when calling a method "that can't fail". That is definitely a bad practice in my opinion and at minimum such failures need to be logged. It should be noted that it is likely because most applications do not alert users to such problems that whatever the root cause of the problem at hand is it was not noticed by developers or quality assurance and was released out the door to the public where it is quietly causing hard to track down trouble.
So should IINA just log that power management is malfunctioning and quietly continue on? It might only result in the "don't let the display sleep while playing" feature appearing to be unreliable. But with macOS power management malfunctioning there could be other problems happening on the Mac that could cause odd IINA behavior. @lhc70000, @saagarjha thoughts on IINA's behavior in this case?
macOS Behavior
Note that the macOS power management malfunction is not due to IINA. The root cause of this issue appears to have to do with other products improperly interacting with macOS. IINA is merely reporting that macOS is broken and is not involved in the core issue. Even though IINA is not involved, as Mac users we still want to know what might be breaking our Mac's without our knowledge and causing such problems, so one such case has been deeply investigated.
Issue #3478, "INA 1.2.0 crashes instantly (Big Sur)" is an example of the 1.2.0 behavior where instead of IINA displaying the alert seen above, IINA crashed while trying to display that alert. In that case a lot of investigation caused us to suspect Rogue Amoeba's Audio Capture Engine (ACE) framework was the culprit. After updating to the latest version the problem no longer reproduced. We know this thanks to @VanyaTheSpark who patiently worked with me to gather enough information to pinpoint the cause. Thanks again @VanyaTheSpark!
In that case it was found that the macOS component coreaudiod was making thousands of calls to macOS power management. So many calls were made that eventually the macOS component powerd ran out of memory. In addition coreaudiod was frequently crashing and restarting. Crashes involved the Rogue Amoeba ACE driver as seen here:
Thread 154 Crashed:: Dispatch queue: com.apple.audio.device.EQMDevice.event
0 com.apple.audio.CoreAudio 0x000000018aaf61f8 _XObject_GetPropertyData_DAI32 + 424
1 com.apple.audio.CoreAudio 0x000000018aaf61ec _XObject_GetPropertyData_DAI32 + 412
2 com.rogueamoeba.ACE.driver 0x00000001078387f0 0x107820000 + 100336
3 com.apple.audio.CoreAudio 0x000000018aafb3a0 HALB_MIGServer_server + 104
The expectation in that case was that macOS power management was returning this error code to IINA:
(iokit/common) can't allocate memory (-536870211)
If you want to know more see the many replies to issue #3478.
The pattern reported above where everything works upon rebooting macOS but after a time the failure comes back is consistent with macOS power management working fine until it runs out of memory. Restarting macOS restarts the power management daemon, clearing the problem until again memory is exhausted.
To confirm that is what is happening in this case we'd want to see the error reported in the IINA log file. In researching issue #3478 posts on the net indicated other problems with macOS power management. So it is possible something else could be going on with macOS power management.
Summary
This is not a bug in IINA. This is how IINA informs you that macOS power management is broken on the Mac IINA is being run on.
Please take the follow actions:
Check if you have any products from Rogue Amoeba installed on your Mac. If any are found check to see if there are pending updates to those products that have not been installed. It is critical that Rogue Amoeba's Audio Capture Engine (ACE) framework is up to date.
The ACE framework may be included in products from other companies as discussed in the post Licensing Rogue Amoeba's ACE SDK. If you do not have products from Rogue Amoeba installed check for any audio related applications and see if they use the ACE framework. Make sure any audio related applications are up to date.
Check if you have Zoom installed on your Mac. If you do and are familiar with the history of security problems (see articles like tom's guide Zoom security issues: What's gone wrong and what's been fixed) and still want to use it, check to see if there are pending updates that have not been installed. Make certain the latest version is installed.
Please let us know if these actions resolve the issue.
If not then when the problem occurs capture and post the IINA log file as @svobs requested. Only the IINA log is needed, no need for the mpv log in this case.
Also, before rebooting macOS please open a terminal window and run the following command:
pmset -g everything >pmset.txtAdd the
pmset.txtfile to this issue along with theiina.logfile. To add files to a GitHub issue you can drag and drop them when preparing a response.Analysis
As we don't have an IINA log, this analysis is based on previous history with this kind of failure. The log can tell us if this is the issue seen before or a new variation on it.
IINA Behavior
The root cause of the issue is not in any way the fault of IINA. IINA is reporting that it called the macOS IOKit framework method IOPMAssertionCreateWithName and that method was not successful. IINA is calling that method merely to request that macOS not put the display to sleep. That request is never supposed to fail, and yet in this case it did. The error code returned by macOS should be in the IINA log.
The behavior of IINA in this case has changed in 1.3.0. In 1.2.0 IINA was trying to post the above error message, but failed to use the main thread resulting in a crash. In 1.3.0 that code has been corrected to properly post the alert.
What can be questioned about IINA's behavior is whether this situation should be treated as a fatal error. A typical software industry practice is to not even check the return code when calling a method "that can't fail". That is definitely a bad practice in my opinion and at minimum such failures need to be logged. It should be noted that it is likely because most applications do not alert users to such problems that whatever the root cause of the problem at hand is it was not noticed by developers or quality assurance and was released out the door to the public where it is quietly causing hard to track down trouble.
So should IINA just log that power management is malfunctioning and quietly continue on? It might only result in the "don't let the display sleep while playing" feature appearing to be unreliable. But with macOS power management malfunctioning there could be other problems happening on the Mac that could cause odd IINA behavior. @lhc70000, @saagarjha thoughts on IINA's behavior in this case?
macOS Behavior
Note that the macOS power management malfunction is not due to IINA. The root cause of this issue appears to have to do with other products improperly interacting with macOS. IINA is merely reporting that macOS is broken and is not involved in the core issue. Even though IINA is not involved, as Mac users we still want to know what might be breaking our Mac's without our knowledge and causing such problems, so one such case has been deeply investigated.
Issue #3478, "INA 1.2.0 crashes instantly (Big Sur)" is an example of the 1.2.0 behavior where instead of IINA displaying the alert seen above, IINA crashed while trying to display that alert. In that case a lot of investigation caused us to suspect Rogue Amoeba's Audio Capture Engine (ACE) framework was the culprit. After updating to the latest version the problem no longer reproduced. We know this thanks to @VanyaTheSpark who patiently worked with me to gather enough information to pinpoint the cause. Thanks again @VanyaTheSpark!
In that case it was found that the macOS component
coreaudiodwas making thousands of calls to macOS power management. So many calls were made that eventually the macOS componentpowerdran out of memory. In additioncoreaudiodwas frequently crashing and restarting. Crashes involved the Rogue Amoeba ACE driver as seen here:Thread 154 Crashed:: Dispatch queue: com.apple.audio.device.EQMDevice.event 0 com.apple.audio.CoreAudio 0x000000018aaf61f8 _XObject_GetPropertyData_DAI32 + 424 1 com.apple.audio.CoreAudio 0x000000018aaf61ec _XObject_GetPropertyData_DAI32 + 412 2 com.rogueamoeba.ACE.driver 0x00000001078387f0 0x107820000 + 100336 3 com.apple.audio.CoreAudio 0x000000018aafb3a0 HALB_MIGServer_server + 104The expectation in that case was that macOS power management was returning this error code to IINA:
(iokit/common) can't allocate memory (-536870211)If you want to know more see the many replies to issue #3478.
The pattern reported above where everything works upon rebooting macOS but after a time the failure comes back is consistent with macOS power management working fine until it runs out of memory. Restarting macOS restarts the power management daemon, clearing the problem until again memory is exhausted.
To confirm that is what is happening in this case we'd want to see the error reported in the IINA log file. In researching issue #3478 posts on the net indicated other problems with macOS power management. So it is possible something else could be going on with macOS power management.
Thanks for the detailed answer, I will upload the log next time I have a problem again
I will keep an eye out for the log file. The IINA log should tell us the error macOS is reporting which will either confirm the suspicion that the power management portion of macOS has run out of memory, or point to a different problem.
The IINA log is insufficient to track down what is causing power management to fail. To try and figure that out we'd want collect information that section of macOS. That is what this command does:
pmset -g everything >pmset.txt
Can we add an option to temporarily turn off this error prompt? In Ventura beta 4, this error box pops up almost all the time and makes people crash It would be great if there is a shielding function that is not prompted this time or not prompted this day
It is certainly possible to add some sort of preference to IINA that would cause IINA to ignore this error. BUT don't forget that if you are seeing this power management in macOS is BROKEN. Alarming that you are reporting this is happening a lot with Ventura Beta. That might be something that needs to be reported to Apple.
When this happens IINA will log the error returned by macOS. We need to see what error is being reported. The other critical diagnostic information can be gathered using pmset. Open Terminal and execute the following command:
pmset -g everything >pmset.txt
That will create a file pmset.txt which contains a history of what has been happening with power management. Drag-n-drop that file to this issue and I will see what it tells us.
归档.zip This is my log file. This error reappears when recording logs. I mainly use iina to watch online classes, so this error basically occurs at the beginning of the pause. In other cases, it is not clear thank you
This needs to be reported to Apple as soon as possible. Please use the Feedback Assistant application, which I believe comes with macOS Betas, to report this to Apple.
You do not want to mention "IINA" in your report as an Apple developer quickly skimming the report might think you are asking Apple to fix IINA and just close the report. I suggest something like the following...
Subject:
Power management fails reporting: can't allocate memory
Description:
Applications are reporting that calls to IOPMAssertionCreateWithName with kIOPMAssertionTypeNoDisplaySleep
are failing with error kIOReturnNoMemory, code: -536870211, text: (iokit/common) can't allocate memory.
The state of power management was captured by running:
pmset -g everything >pmset.txt
File attached.
Looking at that file, this section:
INVOKE: pmset -g assertions
Lists a LOT (7,000+) of outstanding assertions of this form:
pid 119(powerd): [0x000080f8000d9bc9] 00:00:04 InternalPreventSleep named: "com.apple.powermanagement.wakeschedule"
Timeout will fire in 0 secs Action=TimeoutActionRelease
$ grep -c 'pid 119(powerd):.*InternalPreventSleep.*com\.apple\.powermanagement\.wakeschedule' pmset.txt
7207
Could that be what has exhausted the memory of powerd?
Include pmset.txt with the report. Don't include the IINA and mpv logs.
Searching the macOS 13 Ventura Beta 4 Release Notes I did not find any known bugs in this area. So it is important to let Apple know powerd is failing like this.
For reference, I have also seen this in macOS 12 Monterey (12.4) When it happened, I restarted my mac and since then I haven't seen it (probably ~2-3 weeks ago). I have also updated to 12.5 since then.
@BenSokol, thanks for the additional data point. If it happens again please:
- Capture the IINA log file
- Run
pmset -g everything >pmset.txtin Terminal - Open Console and check for
coreaudiodandpowerdcrash reports - Post
iina.log,pmset.txtand crash reports here
The IINA log file will tell us the failure reported by macOS. So far it has been this:
17:44:56.038 [iina][e] Cannot prevent display sleep: (iokit/common) can't allocate memory (-536870211)
That indicates IOPMAssertionCreateWithName failed reporting kIOReturnNoMemory. That is bad bad bad. It means power management in macOS is broken. Specifically the powerd daemon has run out of memory.
So why has powerd run out of memory? In what ways will the Mac malfunction when this macOS daemon is broken? These questions need to be answered by Apple, but we can investigate a bit ourselves. The output from pmset tells us what powerd has been doing. Crash reports, if present may provide additional clues.
It appears that there is more than one way powerd can run out of memory. In issue #3478:
-
coreaudiodwas making thousands of calls topowerd -
powerdran out of memory -
coreaudiodwas crashing - Rogue Amoeba's Audio Capture Engine (ACE) was installed
- The user updated to the latest version of ACE
- The problem stopped occuring after ACE was updated
From a software architecture viewpoint what is bad about the above scenario is that one malfunctioning macOS daemon, coreaudiod, caused another macOS daemon to malfunction, powerd, which then caused requests from applications, IINA, to fail. Would have been nice if powerd enforced an outstanding request quota on clients to prevent one malfunctioning client from breaking macOS power management for all.
The pmset.txt provided by @leeoem is inconsistent with the problem in issue #3478. In the case at hand the powerd daemon seems to be running out of memory due to too many InternalPreventSleep assertions. That seems like a self-inflicted wound. Some sort of change to powerd in Ventura? That behavior needs to be explained by the Apple macOS developers that work on powerd.
As to what is causing the failure for @Thomas-Harrell under Big Sur, or the failure you experienced under Monterey, we need to collect the evidence I noted above and see what it tells us.
If either of you have any audio related applications installed, make sure they are up to date in case an old version of the ACE driver is triggering the problem.
@hereisderek Have you reported this to Apple using the Feedback Assistant application? It is looking like Apple may have introduced a new defect into macOS power management in Ventura.
When reporting this to Apple be sure not to start out discussing IINA or the Apple engineer may think you are asking Apple about a defect in IINA and toss your report in the trash. See my advice on reporting this to Apple in my previous post above.
The IINA issue is that IINA is treating this macOS failure as a fatal error. The change to IINA this issue requests is to be able to configure IINA to work when this portion of macOS is malfunctioning. IINA is not responsible for this macOS failure, just reacting to it. If power management in macOS is going to be this unreliable then IINA will need to be more forgiving. But this is not good. Apple needs to fix the macOS power management daemon.
In this case don't have the IINA log file, so we can't confirm this is another case of the macOS power management daemon, powerd, running out of memory, but the output from pmset is consistent with the daemon running out of memory. Similar to the previous report from Ventura there is a huge number of outstanding internal assertions:
low-batt@gag 2022-08-16$ grep -c 'pid 114(powerd):.*InternalPreventSleep.*com\.apple\.powermanagement\.wakeschedule' pmset.txt
16986
This doesn't look good either:
INVOKE: pmset -g powerstate
Driver ID Current State Max State Current State Description
Internal failure: Failed to get power state information
Internal failure: Failed to get power state information
Internal failure: Failed to get power state information
Internal failure: Failed to get power state information
Internal failure: Failed to get power state information
It seems like there is a new defect in the area of power management in macOS Ventura. Of course I'm not an Apple software developer. We need to hear from Apple as to why macOS is malfunctioning.
To all of the people on Ventura powerd has been broken ever since the first beta dropped. Since I'm on a hackintosh Apple has been ignoring my Feedback Assistant reports. The problems lies with the power management scheduler setting to send an email in 2062. To verify you have the same problem you can do:
On a Terminal run the command: pmset -g assertions
which outputs (on my machine) hundreds of lines
pid 110(powerd): [0x0000411d000d81b2] 00:00:04 InternalPreventSleep named: "com.apple.powermanagement.wakeschedule"
Running: pmset -g sched will display all the scheduled tasks, on my hackintosh I only had this one:
Scheduled power events:[0] wake at 04/11/62 19:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
You can cancel the schedule with: sudo pmset schedule cancelall and it is an immediate fix, no need to reboot or do anything, really.
Now IINA should not display the error any longer. On my macbook doing the above steps also helped the fans stop spinning when on idle and the machine goes back to sleep properly, only on my hackintosh it keeps coming back oddly enough.
you could also delete the file com.Apple.autoWake.plist located in Library/Preferences/SystemConfiguration but this one didn't work for me, your mileage may vary.
As @low-batt stated this problem is completely unrelated to IINA. If you are on macOS Ventura and facing the same issue please send feedback through the Feedback Assistant application in hopes Apple finally fixes this issue.
I had the issue occur again yesterday on macOS Monterey 12.5 (21G72). Tried Force quitting powerd in Activity Monitor (it auto restarted) and that solved the issue for now.
Regardless, IINA should be updated to not cause repeated prompts for this issue. Yes, it is Apple's bug; However, IINA shouldn't be broken (basically unusable) when it occurs.
@BenSokol, I'm currently discussing with the developers on how IINA should handle this failure with macOS reliability continuing to decline. We may end up removing the alert and just logging the issue. I've been putting the emphasis on this being an Apple defect that needs to be reported to Apple in the hopes that Ventura will not go out the door broken like this. But yes, the IINA behavior needs to be changed.
NOTE that we don't know what is happening in your case. The post from @Arch-0 confirms the macOS failure we have been discussing is a regression in Ventura. If that is correct then that is not what you are experiencing in macOS 12.5.
The other time this was deeply investigated was in issue #3478. That was traced to a defect in Rogue Amoeba's Audio Capture Engine (ACE) framework that is fixed in the latest version of the ACE driver. That driver is embedded in products from other companies. If you post the pmset.txt generated by running this command in Terminal:
pmset -g everything >pmset.txt
Post that file and I will take a look and see what it tells us. Also check your machine for coreaudiod crash reports.
If it is not that then it is some new way power management is failing that we have not seen yet.
@Arch-0, Excellent information. Thanks for posting.
Checking the recent pmset.txt posted by @hereisderek shows two scheduled power events in 04/12/2262:
INVOKE: pmset -g sched
Scheduled power events:
[0] wake at 04/12/2262 11:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
[1] wake at 04/12/2262 11:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
The pmset.txt posted by @leeoem shows six scheduled power events in 04/12/2262:
INVOKE: pmset -g sched
Scheduled power events:
[0] wake at 08/02/22 11:33:29 by 'com.apple.alarm.user-visible-com.apple.CalendarNotification.EKTravelEngine.periodicRefreshTimer'
[1] wake at 04/12/62 07:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
[2] wake at 04/12/62 07:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
[3] wake at 04/12/62 07:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
[4] wake at 04/12/62 07:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
[5] wake at 04/12/62 07:47:16 by 'com.apple.alarm.user-visible-com.apple.email.SendLaterDelivery' User visible: true
Horrible to see Apple messing up macOS power management like this.
Poking around the net using the additional information posted by @Arch-0, people are blaming the issue on this new Mail feature listed on the Apple page New features available with macOS Ventura:
Scheduled send Schedule email to be sent at the perfect moment.
Most people are reporting this because it is causing powerd to use so much CPU time that the CPU heats up and causes the fans to run continuously.
People are reporting the workaround posted by @Arch-0:
sudo pmset schedule cancelall
Is working, but the problem comes back after waking the Mac from sleep.
Sure hope Apple fixes this before Ventura goes out the door.
I still wish there was an option to disable IINA asking macOS to prevent display sleep because whether its Apple's fault or not, this makes IINA unusable and I had to start using VLC again which is a little frustrating.
I have asked the developers how to deal with macOS becoming so unreliable. Likely IINA will be changed to just log and error message indicating macOS is broken.
I have asked the developers how to deal with macOS becoming so unreliable. Likely IINA will be changed to just log and error message indicating macOS is broken.
It would be great if IINA displayed the message with an option to never show the warning again instead of outright removing the warning and just logging it. I find the warning useful albeit annoying.
@low-batt
Check if you have any products from Rogue Amoeba installed on your Mac. If any are found check to see if there are pending updates to those products that have not been installed. It is critical that Rogue Amoeba's Audio Capture Engine (ACE) framework is up to date.
The ACE framework may be included in products from other companies as discussed in the post Licensing Rogue Amoeba's ACE SDK. If you do not have products from Rogue Amoeba installed check for any audio related applications and see if they use the ACE framework. Make sure any audio related applications are up to date.
-
It's been a long time since I uninstalled the ACE framework program in question, and I haven't had that error again until now.
-
I used to use this software BlackHole
BlackHole is a modern macOS virtual audio driver that allows applications to pass audio to other applications with zero additional latency.
-
I found the ACE framework in Audio MIDI Setup.app, and then I uninstalled the BlackHole.
-
Delete ACE framework in Audio MIDI Setup.app, delete
/Library/Audio/Plug-Ins/HAL/ACE.driverin Finder, restart my computer after that. -
Since uninstalled the BlackHole, from the last issue of the issue to the present, that problem has never occurred again.
-
My system Version is macOS Big Sur 11.6.2.
@Thomas-Harrell Thank you very much for posting that information.
Glad to hear the ACE driver was responsible in your case. One worry is that there are other causes for this macOS power management failure other than use of an old version of the ACE driver and the regression in the Ventura Beta.
I've posted a proposed fix to the alert. The fix:
- Changes IINA to only show the alert once per invocation
- Adds a button to the alert to allow the user to permanently suppress the alert
- Changes the alert to include the error code returned by macOS
Critical brutal mean reviews are welcome.
The alert changes from:
To:
The failure is always logged. The log messages look like:
19:52:45.572 [iina][e] IOPMAssertionCreateWithName returned 0xE00002BD8, (iokit/common) can't allocate memory
19:52:45.572 [iina][e] Cannot prevent display sleep because macOS power management is broken on this machine
Of course the above text will change if the error code returned by macOS is not kIOReturnNoMemory.
This also occurs when I run apps like OneSwitch to keep Mac awake. This feature might mess up the power management scheduler. Using sudo pmset schedule cancelall can solve this problem. The IINA alert never reoccurs again.
@alexoftheweek Thanks for reporting this.
This app?: https://fireball.studio/oneswitch Which macOS version?
If you execute this when IINA is reporting the problem:
pmset -g everything >pmset.txt
And post the pmset.txt here I will take a look and see what the debug output tells us.
Comments on MacRumors indicate the six developer Beta of Ventura, which was just released publicly, contains a fix to powerd.
Can confirm this issue has disappeared and IINA is working flawlessly again for me since the update to Ventura Public Beta 4 (Build 22A5331f)
@stalonium Excellent news. Thanks for reporting.
Even though the current macOS problem has been fixed it is clear the IINA behavior should be improved. The PR is currently in review. Some sort of change will be merged to allow users to suppress this alert.
This area of macOS seems to be problematic. The report from @alexoftheweek that One Switch can trigger this failure is concerning. @alexoftheweek If you encounter this problem again please use pmset to gather debug information, post it here and I will take a look and see what is going on in that case.
Although macOS daemon failures are an issue for Apple and not the IINA project, it is still useful for all of us Mac users to know these failures are occurring and what is causing them. It is not readily apparent that background processes are malfunctioning, so a user that is experiencing poor video playback may not know that it is due to one of these daemons looping and consuming CPU time and thus interfering with playback.
The fix in PR #3924 has been merged into the develop branch.
The fix improves IINA's behavior when macOS power management malfunctions as was occurring in the macOS Ventura Beta releases.
If IINA ever displays the alert shown above then macOS power management is broken on your machine and that needs to be investigated.