🔴 IINA 1.3.0 BUG: Error Cannot prevent display sleep!

[Thomas-Harrell]

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

• MPV does not have this problem.

[svobs]

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?

[low-batt]

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.

[Thomas-Harrell]

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.

Thanks for the detailed answer, I will upload the log next time I have a problem again

[low-batt]

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

[leeoem]

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

[low-batt]

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.

[leeoem]

归档.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

[low-batt]

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.

[leeoem]

Thank you for your help. I will feed back this problem to apple

[BenSokol]

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.

[low-batt]

@BenSokol, thanks for the additional data point. If it happens again please:

• Capture the IINA log file
• Run pmset -g everything >pmset.txt in Terminal
• Open Console and check for coreaudiod and powerd crash reports
• Post iina.log, pmset.txt and 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:

• coreaudiod was making thousands of calls to powerd
• powerd ran out of memory
• coreaudiod was 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]

I'm getting the same error on Ventura 13.0 Beta (22A5321d)
pmset.txt.zip

[low-batt]

@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.

[Arch-0]

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.

[BenSokol]

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.

[low-batt]

@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.

[low-batt]

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.

[stalonium]

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.

[low-batt]

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.

[Arch-0]

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]

@Arch-0 I will propose such a fix. Working on it...

[Thomas-Harrell]

@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.

1. 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.

2. 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.

3. I found the ACE framework in Audio MIDI Setup.app, and then I uninstalled the BlackHole.

4. Delete ACE framework in Audio MIDI Setup.app, delete /Library/Audio/Plug-Ins/HAL/ACE.driver in Finder, restart my computer after that.

5. Since uninstalled the BlackHole, from the last issue of the issue to the present, that problem has never occurred again.

6. My system Version is macOS Big Sur 11.6.2.

[low-batt]

@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.

[low-batt]

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.

[alexoftheweek]

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.

[low-batt]

@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.

[low-batt]

Comments on MacRumors indicate the six developer Beta of Ventura, which was just released publicly, contains a fix to powerd.

[stalonium]

Can confirm this issue has disappeared and IINA is working flawlessly again for me since the update to Ventura Public Beta 4 (Build 22A5331f)

[low-batt]

@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.

[low-batt]

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.

[austinarchibald]

All of a sudden I am getting this very annoying alert on a headless mac mini. It pops up twice every time you play or pause a video. Never had a problem until now. Is there a quick fix for now until a new update can fix it? sudo pmset schedule cancelall did nothing for me. Understood the underlying error isn't IINA's fault - but the annoying popup still shouldn't be there. Makes IINA unusable right now. Would hate to reinstall VLC 🤢

I tried installing v.1.2.0, but when I try to play a video, IINA crashes.

[low-batt]

The fix that keeps IINA from repeating this alert as well as allowing you to permanently suppress this alert has been merged into develop. At the moment the fix is only available in an unsigned nightly build or if you build IINA yourself from the develop branch.

This alert is present in 1.2.0, however the code to display the alert was incorrect and triggered a crash. So 1.2.0 crashing is expected. For 1.3.0 the code was corrected to properly display the alert and to log the error code macOS returned.

The alert means macOS power management is broken on your Mac. That is BAD. Problems with power management should not be tolerated. We should try and figure out what is going wrong on your Mac.

Open Terminal, run this command:

pmset -g everything >pmset.txt

Drag and drop the resulting pmset.txt file to this issue. I will see if it points to a cause.

Also open Console and check for crash reports, especially from macOS daemons. In particular see if coreaudiod is crashing. If that daemon is crashing post one of the crash reports.

You did not mention the version of macOS the Mac mini is running. So far we have only identified two root causes of the macOS power daemon failing. The recent one was due to a regression added by Apple in a Ventura Beta release. Executing sudo pmset schedule cancelall would temporarily workaround the problem in the Ventura Beta. The expectation is that Apple fully fixed that problem before Ventura was officially released.

The other known macOS power management failure was not due to Apple. It was traced to an old version of the Audio Capture Engine (ACE) framework from Rogue Amoeba. That framework is included in products from other companies. It could be some company is shipping a product with an outdated ACE framework.

[austinarchibald]

Thanks! Here is the file. Running 11.6 Big Sur.
pmset.txt

[low-batt]

In both of the previous cases macOS power management was returning this error code to IINA:

(iokit/common) can't allocate memory (-536870211)

The macOS powerd daemon uses memory to remember "assertions". When playing a video IINA requests that macOS not put the display to sleep. The power daemon creates an "assertion" in memory to remember this. In one of the previous cases the coreaudiod daemon was creating tens of thousands of these requests, exhausting the daemon's memory.

This first clip from pmset.txt shows the expected use. The macOS screensharingd asks macOS to not allow the system to go to sleep because I user is connected. Then a bit over 5 minutes later it tells macOS it is ok to allow the system to sleep and the assertion is released:

2022-10-29 14:28:58 -0400 Assertions          	PID 7773(screensharingd) Created PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle PrevSleep DeclUser kCPU kDisp]          
2022-10-29 14:35:49 -0400 Assertions          	PID 7773(screensharingd) Released PreventSystemSleep "Remote user is connected" 00:06:50  id:0x0x70000a0a9 [System: PrevIdle DeclUser kDisp]  

I'm expecting that sequence represents a user logging in and then logging out. But after that as soon as screensharingd creates an assertion it releases it:

2022-10-29 14:35:59 -0400 Assertions          	PID 7773(screensharingd) Created PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle PrevSleep DeclUser kCPU kDisp]          
2022-10-29 14:35:59 -0400 Assertions          	PID 7773(screensharingd) Released PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle DeclUser kDisp]          
2022-10-29 14:36:01 -0400 Assertions          	PID 7773(screensharingd) Created PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle PrevSleep DeclUser kCPU kDisp]          
2022-10-29 14:36:01 -0400 Assertions          	PID 7773(screensharingd) Released PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle DeclUser kDisp]   
2022-10-29 14:36:03 -0400 Assertions          	PID 7773(screensharingd) Created PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle PrevSleep DeclUser kCPU kDisp]          
2022-10-29 14:36:03 -0400 Assertions          	PID 7773(screensharingd) Released PreventSystemSleep "Remote user is connected" 00:00:00  id:0x0x70000a0a9 [System: PrevIdle DeclUser kDisp]          

Not sure what to make of that. As the assertions are being released it should not run powerd out of memory. However if the Big Sur powerd daemon has a memory leak in that sequence then all this activity could run the daemon out of memory.

There was a 3rd macOS power management failure that was not seen with IINA. I found a post on the net discussing macOS returning this error:

Cannot prevent display sleep: (iokit/common) no such device (-536870208)

As if macOS lost communication (no such device) with the power management chip.

At this point we need to check the IINA log and see what error macOS is returning. Logging is disabled by default. To enabled logging follow these instructions:

• Start IINA
• Click on Preferences… under the IINA menu
• The preference panel appears
• On the left side of the panel click on Advanced
• Slide the Enable advanced settings toggle button to be on (blue)
• Click on the checkbox Enable logging
• Click on Open log directory
• A new Finder window appears
• Restart IINA to activate logging

Once IINA is restarted a new directory will appear in the Finder window. The directory contains two files, iina.log and mpv.log Each time IINA starts it creates a new directory to hold a fresh set of log files.

The log files can also be accessed using Terminal as shown here:

low-batt@gag com.colliderli.iina$ pwd
/Users/low-batt/Library/Logs/com.colliderli.iina
low-batt@gag com.colliderli.iina$ ls
2022-10-04-17-57-15_jVrbWy
low-batt@gag com.colliderli.iina$ cd 2022-10-04-17-57-15_jVrbWy
low-batt@gag 2022-10-04-17-57-15_jVrbWy$ ls
iina.log	mpv.log
low-batt@gag 2022-10-04-17-57-15_jVrbWy$ 

DO NOT FORGET to disable logging once you have obtained log files for the problem being investigated. IINA does not restrict the size of log files or delete old logs. If you leave logging enabled the logs will continue to accumulate.

In the IINA log file look for the text "Cannot prevent display sleep". Post the line of the log file with that text here, or drag-n-drop the log file to this issue and I will poke though it and see what it tells us.

[austinarchibald]

I updated to Ventura, now I don't get the error. So all is good! Not too concerned about some underlying issue. I'll be upgrading this to the M2 Mac Mini whenever it comes out anyhow. :) Thanks for all your help.

[low-batt]

Very glad to hear upgrading macOS to Ventura fixed this. Ventura definitely has some odd graphics problems. If you encounter odd problems look for IINA issues marked with the macOS Ventura label. Hopefully Apple will quickly release an update to Ventura that fixes these issues.

[low-batt]

The root cause was a defect in some of the macOS Ventura Beta releases. No such problems have been reported in the official release of macOS Ventura.

This problem also can be triggered by an old version of the Audio Capture Engine (ACE) framework from Rogue Amoeba. The ACE framework is also included in products from other companies. If you encounter this failure be sure you are not using an old version of this framework.

IINA behavior when macOS power management is broken was poor. That has been fixed in IINA 1.3.1. You now have the ability to suppress the alert from IINA.

[BenSokol]

Thanks for adding the way to disable the alert in iina.

Fyi, i have seen this occur once (a few days ago) after updating to the official release of macOS Ventura (13.0 (22A380)). Had to reboot to fix it.

[low-batt]

@BenSokol I appreciate the report. Did you upgrade from Monterey or a Ventura Beta?

If you were previously running a Ventura Beta then hopefully the problem was due to bad state left by the Beta version that has now been cleaned up. If however you experienced this upon upgrading from Monterey, then that is especially disturbing.

In the failure seen with the Ventura Beta the powerd daemon ran out of memory. Restarting macOS clears the problem for a while until that daemon runs out of memory again. As can be seen in the picture of the alert above it now contains the error code returned by macOS. If the problem occurs again please include that error code in any report.

In my opinion problems in the power management area of macOS must not be tolerated. Apple needs to take quality in this area of macOS seriously. The problem introduced in the Ventura Beta was obvious in the output of pmset. That should have been caught in development. If you take the attitude of "well it is a beta version" then you will lose beta testers over time.

The behavior of IINA in this case definitely needed to be improved. I'm hoping the problems in this area of macOS have been fixed and nobody will need to take advantage of new ability to suppress this alert. If that proves not to be the case I'd like to know about it.

[BenSokol]

@BenSokol I appreciate the report. Did you upgrade from Monterey or a Ventura Beta?

If you were previously running a Ventura Beta then hopefully the problem was due to bad state left by the Beta version that has now been cleaned up. If however you experienced this upon upgrading from Monterey, then that is especially disturbing.

In the failure seen with the Ventura Beta the powerd daemon ran out of memory. Restarting macOS clears the problem for a while until that daemon runs out of memory again. As can be seen in the picture of the alert above it now contains the error code returned by macOS. If the problem occurs again please include that error code in any report.

In my opinion problems in the power management area of macOS must not be tolerated. Apple needs to take quality in this area of macOS seriously. The problem introduced in the Ventura Beta was obvious in the output of pmset. That should have been caught in development. If you take the attitude of "well it is a beta version" then you will lose beta testers over time.

The behavior of IINA in this case definitely needed to be improved. I'm hoping the problems in this area of macOS have been fixed and nobody will need to take advantage of new ability to suppress this alert. If that proves not to be the case I'd like to know about it.

I updated directly from 12.6 (Monterey). I didn't run the macOS public/dev beta this year, however i have in past years.

[low-batt]

Well that is disturbing. Makes me worried that Apple only reduced the problem so that it takes a while to appear. I too upgraded from Monterey 12.6 directly to the Ventura public release. I have not encountered this problem. The suspension is that the offending changes support the new mail "send later" feature. I am not using email on my Mac that is running Ventura.

If you encounter this again then before rebooting and clearing the problem please capture information about the problem. Record the error code reported in the IINA alert. If you have IINA logging enabled there will be a log message that should have a description of what that error code means.

Open Terminal, run this command:

pmset -g everything >pmset.txt

Open Console and look for any crash reports, especially for coreaudiod or powerd crashing.

Use the Feedback Assistant to report the problem to Apple. Include pmset.txt, any crash reports for those daemons and the error code reported by IINA.

We need to keep bombarding Apple with reports until they fix macOS.