Closed Chromagram closed 2 years ago
Chromagram
commented
2 years ago Note: The posted logs are from earlier tests, but the issue has persisted through several years of macOS and several versions and builds of IINA. If you do need brand new logs as well, please let me know. For now, here are more logs.
low-batt
commented
2 years ago These issues appear to be the same crash reported in this issue:
Same failure: [NSNextStepFrame _displayName]: unrecognized selector
Machine: M1 MacBook Air
macOS: 11.2.2
IINA: 1.1.2
Did not reproduce on 2010 MacBook Pro running macOS 10.13.6 & IINA 1.1.2
Same failure: [NSNextStepFrame _displayName]: unrecognized selector Machine: M1 MacBook Air macOS: 11.3 Beta IINA: 1.1.2 & 1.2.0
Same failure: [NSNextStepFrame _displayName]: unrecognized selector Machine: ? macOS 11.0 Beta IINA 1.1.0
I was not able to reproduce this problem under macOS 10.15.7.
Under macOS 12.0.1 on a M1 Max following steps 1 and 1a reproduced the crash every time. Forcing IINA to run under Rosetta 2 did not make a difference, IINA still crashed.
This portion of the crash report shows the crash happens when IINA is notified of an event and attempts to update the window's title:
7 IINA 0x00000001044b8f78 $s4IINA20MainWindowControllerC11updateTitleyyF + 828
8 IINA 0x00000001044edf28 $s4IINA22PlayerWindowControllerC13windowDidLoadyyFy10Foundation12NotificationVcfU1_TA + 52
9 IINA 0x0000000104595a0c $s10Foundation12NotificationVIegn_So14NSNotificationCIeyBy_TR + 104
10 Foundation 0x000000019a54f794 -[__NSObserver _doit:] + 348
11 CoreFoundation 0x0000000199699160 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 28This code in PlayerWindowController.windowDidLoad established the observers that are being called:
addObserver(to: .default, forName: .iinaMediaTitleChanged, object: player) { [unowned self] _ in
self.updateTitle()
}
addObserver(to: .default, forName: .iinaFileLoaded, object: player) { [unowned self] _ in
self.updateTitle()
}The observers are calling MainWindowController.updateTitle. The call to NSWindow.setTitleWithRepresentedFilename in this method triggers the exception:
@objc
override func updateTitle() {
if player.info.isNetworkResource {
window?.title = player.getMediaTitle()
} else {
window?.representedURL = player.info.currentURL
window?.setTitleWithRepresentedFilename(player.info.currentURL?.path ?? "")I did not find anything wrong with the call to setTitleWithRepresentedFilename.
Changes in Big Sur broke legacy full screen. The method MainWindowController.legacyAnimateToFullscreen was conditionalized to get legacy full screen working again:
private func legacyAnimateToFullscreen() {
guard let window = self.window else { fatalError("make sure the window exists before animating") }
// call delegate
windowWillEnterFullScreen(Notification(name: .iinaLegacyFullScreen))
// stylemask
window.styleMask.insert(.borderless)
if #available(macOS 10.16, *) {
window.styleMask.remove(.titled)
(window as! MainWindow).forceKeyAndMain = true
window.level = .floating
} else {
window.styleMask.insert(.fullScreen)
}If this line is commented out IINA does not crash:
window.styleMask.remove(.titled)However if that line is removed legacy full screen malfunctions.
The problem seems to be isolated to the setTitleWithRepresentedFilename method. Setting the title directly works. I do not have an Intel Mac running Big Sur or Monterey so I can't confirm it, but the reports suggest the problem only occurs on an M1.
My conclusion is that IINA is doing nothing wrong and this is a defect in the Cocoa framework.
I will shortly post a pull request to address this issue.
The "fix" in the pull request works around the problem by setting the window's representedFilename and title properties directly:
if Preference.bool(for: .useLegacyFullScreen), #available(macOS 11.0, *) {
window?.representedFilename = player.info.currentURL?.path ?? ""
window?.title = player.info.currentURL?.lastPathComponent ?? ""
} else {
window?.setTitleWithRepresentedFilename(player.info.currentURL?.path ?? "")
}At least I think that is all the setTitleWithRepresentedFilename method is doing. Rather than replace the call to setTitleWithRepresentedFilename with the code to set the properties directly for all cases the code is conditionalized to only perform this workaround when legacy full screen is being used as calling the setTitleWithRepresentedFilename method is the correct way to perform this operation. If this issue is fixed in a future macOS version then the conditionalization can be further restricted to only apply the workaround to defective versions.
With this workaround in place I was unable to trigger the crash. Testing was done on a MacBookPro18,2 with a M1 Max chip running macOS 12.0.1. A native version of IINA was used, built using Xcode 13.1.
Always troubles me to put in workarounds like this when the root cause of the problem has not been confirmed. But further analysis requires access to Apple's Cocoa framework sources.
Thoughts? Critical reviews welcome.
Chromagram
commented
2 years ago @low-batt and @CarterLi, I wanted to pop in and say huge thanks for solving this. I first reported this back in February, but as you saw from the error, I've had the issue for years now. It sat unfixed for so long, and you swooped in to figure it out and to create a working .dmg/app. I'm ecstatic, fixing this has immediately put IINA back as my favourite Mac media player.
Huge thanks again.
Chromagram
commented
2 years ago I just have one last thing to check:
With the new commit, legacy full screen works very nicely without crashing. It appears that it does not respect my macOS setting to permanently display the top menu bar and just puts the player up to the very top.
On the M1 Pro/Max machines (like I have), I prefer that the legacy full screen mode gets letterboxed under the menu bar. This ensures that subtitles and other video content doesn't get lost into the camera notch at the top.
I'm not sure if there's a setting I'm missing, but I did play around with a bunch of them and couldn't get it to adapt.
low-batt
commented
2 years ago I'm merely another IINA user trying to help out the overloaded IINA developers, so anything from me is "unofficial".
I didn't mention it, but the "2-3 years" of crashes troubled me. Since this issue started with Big Sur, it can't be what was causing a crash 3 years ago. I've posted pull requests with proposed fixes for several other crashes. Maybe it was one of those that you were hitting years ago.
There is another crash that has been reported 7 times, if my analysis is right. See #3475 I was not able to reproduce that one. It is one my list to come back to and try and reproduce it again.
On the "notch" issue, that is the Scale to fit below built-in camera feature Apple has added. That is a brand new feature so there might be problems with it. Enter that as a separate issue. I'm not a UI programmer, so the changes needed to support that feature are probably beyond my skills.
low-batt
commented
2 years ago I took a very brief look into the "notch" issue. Without legacy full screen enabled I was not seeing the notch area used while in full screen. With legacy full screen enabled and the onscreen controller configured to be on top the full screen was used and the notch blocked a portion of the controller's slider. If I then enabled "Scale to fit below built-in camera" for the IINA application as discussed in that Apple support note, the notch area was not used with legacy full screen.
So give that setting a try.
The issue of proper "notch" handling still requires a detailed investigation into Apple's recommendations and IINA's behavior.
Chromagram
commented
2 years ago Thanks! I appreciate it. I’ll post a new issue for the menu bar because IINA still won’t respect the “Always Show Menu Bar” option in macOS. However, the tick box does help right now with the content cutting into the notch, so thank you again for that. I actually don’t dislike the notch, but I would like the space to be used for the menu bar as Apple intended.
Much much much less of an issue than the legacy full screen crashing. Having that fixed has been such a lifesaver.
low-batt
commented
2 years ago As you can see above I reported the issue with the camera housing obscuring IINA's window when in full screen mode with legacy full screen enabled in issue #3558. I have also posted a pull request with a proposed fix for that issue.
With that fix legacy full screen performs just like you see when that preference is not enabled. That fix will also eliminate the "Scale to fit below built-in camera" as an option since it should no longer be needed with IINA properly handling the "notch".
low-batt
commented
2 years ago I have reproduced the NSWindow.setTitleWithRepresentedFilename failure in the tiny test program below. I have submitted a defect report against AppKit with Apple using the Feedback Assistant app. I will update this issue if I hear anything from Apple.
low-batt
commented
2 years ago The fix in PR #3547 has been merged into the develop branch.
low-batt
commented
2 years ago Closing. Fixed in IINA 1.3.0.
SwineBurglar
commented
3 months ago @Chromagram Hey there! Sorry to bother you, but I just found this thread of yours after installing IINA last night on my home theater M1 Mac Mini while trying to switch over from VLC and discovering the bug you reported of IINA with legacy full screen floating on top of all the other windows/apps despite the "float" setting being turned off.
I am running IINA 1.3.5 (latest) on macOS 13.5.2. I noticed in your comment (here) from Nov 24, 2021 in this thread that you mentioned another user had fixed the problem and made available a .dmg of IINA without the bug, but I can't seem to find that .dmg anywhere on the page or in the repository. Were you just referencing the latest release of IINA at the time when you wrote that comment? The bug seems to still exist in the latest release, so I'm just trying to figure out if the .dmg you referenced is somewhere else, or if my issue is being caused by a different bug not addressed by the fix made that you were referencing.
I tried using IINA 1.0.0, as I saw in another thread someone mentioned that was the last version that didn't contain the bug, however it has another, equally annoying bug that doesn't exist in later versions, so 1.0.0 unfortunately not a viable solution for me.
If you could point me in the right direction of that .dmg you referenced, or let me know legacy full screen is working as intended on your end in IINA 1.3.5 and that the issue must be on my end, I would greatly appreciate it!
low-batt
commented
3 months ago Hi @SwineBurglar
On this:
IINA with legacy full screen floating on top of all the other windows/apps despite the "float" setting being turned off
I don't see where @Chromagram reported that?
Could you say a little more about what you are experiencing?
When IINA is in full screen mode it is expected that it will be on top of all the other windows/apps, regardless of whether legacy full screen is used or not.
There is a problem with legacy full screen where if you bring up one of IINA's other windows, for example the settings window, it is hidden behind the player window instead of coming up in front of it. Is that what you are referring to?
Apple in macOS Big Sur changed AppKit and broke custom full screen implementations. I've not checked recently, but I would not be surprised to find AppKit is still broken. Workarounds were used to get legacy full screen limping again.
svobs
commented
3 months ago @SwineBurglar CarterLi's IINA+ is now defunct. But I believe I have solved the floating problems in my IINA Advance fork (you can find a zip file of the latest 1.1 release at the bottom of this page). Please let me know if it addresses your concerns in the ways you'd expect.
SwineBurglar
commented
3 months ago @low-batt
I don't see where @Chromagram reported that?
Could you say a little more about what you are experiencing?
I'm so sorry! I totally goofed here. I had several threads pulled up last night, trying to figure out if my problem had been reported and/or solved. I got this thread completely mixed up with this one, which accurately reflected what I'm experiencing. It looks like it's still an open issue.
To summarize the bug briefly: If I use the legacy full screen mode option (with window floating turned off), the full screen window still floats, making it impossible to switch to another app/window using the "cmd+tab" application switcher.
From your description, it sounds like that is intended. I was used to VLC's implementation of full screen mode, where the window is still able to fall behind other apps/windows, so that a video can be in full screen mode but still be hidden by switching another application to the frontmost position using the application switcher.
And yes, I also noticed that even IINA's own settings window can't get in front of the legacy full screen window.
I was hoping that, since legacy full screen works in IINA 1.0.0 even on Big Sur and later versions of macOS, it would be possible to get it working again in current releases of IINA.
@svobs Wow! I just read through the release notes for 1.0 and 1.1. This looks amazing! I should be able to take it for a spin tonight. I'm looking forward to it. Thank you for making me aware of it. I'll report back with my findings either way.
low-batt
commented
3 months ago On this:
From your description, it sounds like that is intended.
Ah no. I did not understand the issue you were reporting. We'd like legacy full screen to mostly work similar to Apple's full screen mode. It is definitely broken. I've not had a chance to get back to it and try and improve it.
@svobs Do you have some fixes to legacy full screen mode you haven't proposed?
On this:
since legacy full screen works in IINA 1.0.0 even on Big Sur and later versions of macOS
That is useful news to me. I will have to check the source history and see how it was implemented back then. I'm relatively new to the IINA project and have not looked at sources older than version 1.2.0.
SwineBurglar
commented
3 months ago Ah no. I did not understand the issue you were reporting. We'd like legacy full screen to mostly work similar to Apple's full screen mode. It is definitely broken. I've not had a chance to get back to it and try and improve it.
Just FYI, I also noticed with the non-legacy full screen mode, when I switched back and forth between the non-legacy full screen IINA and a non-full screen app, roughly 33% of the time switching away from IINA to the other app, any other app it seems, the other app/desktop as a whole would render as just a black screen.
That is useful news to me. I will have to check the source history and see how it was implemented back then. I'm relatively new to the IINA project and have not looked at sources older than version 1.2.0.
Yeah, I read this comment, also from @Chromagram, where they mentioned legacy full screen working correctly on 1.0.0 but not on 1.2.0. I downloaded 1.0.0 and tested it and found legacy full screen does work correctly, but unfortunately it has a bug where the text in the title bar and the "traffic light" buttons in the top left corner of the window don't disappear in full screen.
Thanks for your work on IINA! It's a great app overall. I was pretty impressed after coming from a couple decades of using VLC. :)
svobs
commented
3 months ago We'd like legacy full screen to mostly work similar to Apple's full screen mode. It is definitely broken. I've not had a chance to get back to it and try and improve it.
I found it has a lot of outstanding bugs. I'm not sure I'd call it "broken" still. But I think it's important to get on the same page about what the goal of "legacy full screen" should be.
It would be very hard, if even possible, to make legacy full screen work just like Apple's full screen, but I don't see how it's desirable to do that. For example I don't like the fact that the full screen window is forced into a separate Space. And in fact, by choosing to implement full screen from scratch there are good opportunities to customize it in ways that Apple doesn't provide, such as whether to make use of the space around the Macbook notch, or speed up the full screen toggle animation. Features like those can give it special value, which I why I felt it appropriate to rename it to "custom full screen" in my fork, because "legacy full screen" would seem to imply something inferior or deprecated.
So it's in that line of thinking that I've been iterating through heuristics for managing the focus state in legacy full screen. To simplify: when the FS window loses focus then I restore window.level to .normal; when it regains focus, it is restored to .iinaFloating. This allows the user to multitask and use other windows/apps. But it strays further away from the native full screen behavior, which would never let you display something on top of it.
low-batt
commented
3 months ago That was why I was careful to include "mostly" in "mostly work similar". I vaguely recall asking IINA users what they liked about legacy full screen and one thing that was mentioned was that it did not use spaces.
I believe the Apple term for this is "custom full screen mode". It was discussed in the Apple Human Interface Guidelines, but from a quick look just now I don't see it mentioned anymore. Apple may be pushing harder for developers to use the "system-provided full-screen experience".
@SwineBurglar On this:
Just FYI, I also noticed with the non-legacy full screen mode, when I switched back and forth between the non-legacy full screen IINA and a non-full screen app, roughly 33% of the time switching away from IINA to the other app, any other app it seems, the other app/desktop as a whole would render as just a black screen.
I noticed you are on an older version of macOS Ventura. There were macOS defects that could result in black screens some of the time. This was reproduced without using IINA. Not sure if that is what you are encountering. We will need to try and reproduce that behavior and investigate.
Make sure you don't have the IINA setting Black out other monitors while in full screen enabled.
SwineBurglar
commented
3 months ago @svobs
For example I don't like the fact that the full screen window is forced into a separate Space
I very much agree with you on this. If I want a full screen window (or any other window) in a separate space, I'll put it there. I don't understand why they force this. It doesn't look good animating from windowed to full screen.
To simplify: when the FS window loses focus then I restore
window.levelto.normal; when it regains focus, it is restored to.iinaFloating.
I tested out IINA-Advance last night. And yes, the custom full screen window does all other applications to be on top of it! The only slight negative I noticed is that, when I switch back to the custom full screen window from some other app, the custom full screen window slides down into place by an amount that is the height of the menu bar. I am planning to look at the macOS system settings and see if there is anything there that I can tweak to stop that behavior, but I figured I'd mention it to you, and I am wondering if it is relative to what you mentioned in the quote from your previous comment that is directly above this paragraph.
Also, for what it's worth, VLC has the legacy full screen mode implemented perfectly, where the legacy full screen windown doesn't move at all when switch to or away from it. I only mentioned this because VLC is open-source and on GitHub, so you could possibly look at how VideoLAN is implementing legacy full screen in VLC and copy that over or using it as a guide. VLC offers legacy full screen and the modern full screen that uses a separate space. In VLC, legacy full screen is enabled by opening the "Preferences" window at VLC>Settings... unchecking the box in the "Video" tab, under the heading "Fullscreen settings" titled "Use the native fullscreen mode".
@low-batt
I vaguely recall asking IINA users what they liked about legacy full screen and one thing that was mentioned was that it did not use spaces
That would be my response as well.
I noticed you are on an older version of macOS Ventura. There were macOS defects that could result in black screens some of the time. This was reproduced without using IINA. Not sure if that is what you are encountering. We will need to try and reproduce that behavior and investigate.
This very well might be what I am experiencing. I wasn't aware of that bug. The computer I tried out IINA on is a home theater computer, not my daily driver, and I have never used any other application in macOS's modern/current full screen mode on it, so if it is a system-wide bug in macOS 13, than I simply hadn't encountered it until now.
Make sure you don't have the IINA setting Black out other monitors while in full screen enabled.
I did check on that setting two nights ago when I was trying out IINA and it was not enabled, but thanks for mentioning that.
Also, as I mentioned above to the other person (sorry to repeat myself but just want to make sure you see this), VLC has the legacy full screen mode implemented perfectly. I only mentioned this because VLC is open-source and on GitHub, so you could possibly look at how VideoLAN is implementing legacy full screen in VLC and copy that over or using it as a guide. VLC offers legacy full screen and the modern full screen that uses a separate space. In VLC, legacy full screen is enabled by opening the "Preferences" window at VLC>Settings.. and unchecking the box in the "Video" tab, under the heading "Fullscreen settings" titled "Use the native fullscreen mode".
svobs
commented
3 months ago I tested out IINA-Advance last night. And yes, the custom full screen window does all other applications to be on top of it! The only slight negative I noticed is that, when I switch back to the custom full screen window from some other app, the custom full screen window slides down into place by an amount that is the height of the menu bar. I am planning to look at the macOS system settings and see if there is anything there that I can tweak to stop that behavior, but I figured I'd mention it to you, and I am wondering if it is relative to what you mentioned in the quote from your previous comment that is directly above this paragraph.
I must admit this feature is still a work in progress. I've already made some improvements to it over what you're seeing in v1.1. I managed to eliminate the vertical jump when using legacy full screen on the built-in Macbook display, but it's still doing the jump on other monitors. I think I can get that done for the v1.2 release which I'm hoping to get out in the next month or so (July is turning out to be a busy month for me unfortunately). I also tweaked the logic so that the menu bar will not be shown if switching to another IINA full screen window on another screen.
I am planning to look at the macOS system settings and see if there is anything there that I can tweak to stop that behavior
Don't bother - I am certain that it's an implementation-level problem which I need to fix in code (and having it fixed for one case already gives me good confidence in my assertion).
Another thing to fix, as someone has already reported, is that IINA (and also IINA Advance) don't actually honor the system setting for Automatically hide and show the menu bar - we are currently assuming a value of In Full Screen Only. I am thinking of putting that off to the future though.
Also, for what it's worth, VLC has the legacy full screen mode implemented perfectly, where the legacy full screen windown doesn't move at all when switch to or away from it. I only mentioned this because VLC is open-source and on GitHub, so you could possibly look at how VideoLAN is implementing legacy full screen in VLC and copy that over or using it as a guide
This is a good idea. I thought I investigated VLC's Mac UI code some time ago but it seems I had brought up the Linux QT code by mistake 😵💫 ...So I took a quick look at some of the code just now, and I see that they are using a separate window entirely for legacy full screen, rather than trying to modify & reuse the existing window. That would bypass a few headaches which we've had to deal with in the past! It's still not clear to me how they differentiate between the two full screen modes. I'll dig deeper when I have more time. It would be great if they have addressed the above menu bar setting.
svobs
commented
3 months ago @SwineBurglar I found that the unwanted window movement was being caused by the fact that I added code to show the menu bar & Dock in addition to changing the depth order. VLC isn't doing that. The main reason I added that was because the version of MacOS at the time (I think somewhere between 13.0 & 14.0) in which hiding the menu bar took effect globally. So it wouldn't come back when switching to other apps. It looks like that is no longer the case in MacOS 14.5, so I'll remove that behavior the window jump will be fixed in IINA-A 1.2. I'll try also to submit a PR for IINA as well.
SwineBurglar
commented
3 months ago @svobs That's great that you got the screen jump issue fixed. I'm excited to test drive version 1.2!
Chromagram
commented
3 months ago It seems my brain just accepted using the native full screen option all this time, because I switched to it to band-aid the issue and forgot about the report until now. Would definitely still love to go back to the media player's full screen option- I have enough macOS spaces already for work and I much prefer just filling up the space on desktop if it works.
Thanks for continuing to converse on this and working on it. :)
Probably for the last 2-3 years, IINA has gone from my absolute favourite media player to my worst. It all stems from legacy mode being completely busted, and it actually used to be perfect. It needs to be addressed if this player has any future, because as workflows get larger and we use up more spaces in macOS, all we want is a player that can utilize the basic feature of legacy full screen.
System and IINA version:
Expected behavior: Legacy full screen should be stable, allowing all functions of IINA like seeking, chapter skip, open media in fullscreen and everything else without crashing.
Actual behavior: All of the listed actions in the expected behavior causes IINA to crash, but only when legacy full screen is ticked. Allowing IINA to start media in legacy full screen causes the app to crash immediately. If you start in windowed mode and enter legacy full screen, then all it takes is seeking forward/backward, chapter skip, jumping to a spot in the timeline, or basically any other action that affects the playback point to completely crash IINA. These issues do not exist at all when legacy full screen is ticked off.
Crash report:
``` Process: IINA [3961] Path: /Applications/IINA.app/Contents/MacOS/IINA Identifier: com.colliderli.iina Version: 1.1.2 (128) Code Type: X86-64 (Translated) Parent Process: ??? [1] Responsible: IINA [3961] User ID: 501 Date/Time: 2021-02-06 03:28:57.199 -0800 OS Version: macOS 11.3 (20E5172i) Report Version: 12 Anonymous UUID: 4569F1B2-442C-CA64-D1ED-DD827C46C34E Sleep/Wake UUID: A91F9095-E299-4448-956D-5C00E48426D8 Time Awake Since Boot: 54000 seconds Time Since Wake: 20000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSNextStepFrame _displayName]: unrecognized selector sent to instance 0x7fa50f4d4530' abort() called terminating with uncaught exception of type NSException Application Specific Backtrace 1: 0 CoreFoundation 0x00007fff2064926f __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007fff20381bbb objc_exception_throw + 48 2 CoreFoundation 0x00007fff206cbab8 -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x00007fff205b07ad forwarding + 1448 4 CoreFoundation 0x00007fff205b0178 _CF_forwarding_prep_0 + 120 5 AppKit 0x00007fff22e1bb5b -[NSWindow title] + 140 6 AppKit 0x00007fff2358b0c2 -[NSWindow _calcAndSetFilenameTitle] + 79 7 IINA 0x0000000100a04eb1 $s4IINA20MainWindowControllerC11updateTitleyyF + 785 8 IINA 0x0000000100a3fb27 $s4IINA22PlayerWindowControllerC13windowDidLoadyyFy10Foundation12NotificationVcfU1_TA + 39 9 IINA 0x0000000100af6d29 $s10Foundation12NotificationVIegn_So14NSNotificationCIeyBy_TR + 105 10 Foundation 0x00007fff21253c5a -[__NSObserver _doit:] + 287 11 CoreFoundation 0x00007fff205c4589 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 12 12 CoreFoundation 0x00007fff206604f8 ___CFXRegistrationPost_block_invoke + 49 13 Foundation 0x00007fff2125ff0f NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK + 7 14 Foundation 0x00007fff2125fe07 -[NSBlockOperation main] + 98 15 Foundation 0x00007fff2125fd9a NSOPERATION_IS_INVOKING_MAIN + 17 16 Foundation 0x00007fff2125f04e -[NSOperation start] + 785 17 Foundation 0x00007fff2125ed1f NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION + 17 18 Foundation 0x00007fff2125ebf2 __NSOQSchedule_f + 182 19 libdispatch.dylib 0x00007fff2032b673 _dispatch_call_block_and_release + 12 20 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 21 libdispatch.dylib 0x00007fff20338b9f _dispatch_main_queue_callback_4CF + 940 22 CoreFoundation 0x00007fff2060c32e CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 23 CoreFoundation 0x00007fff205cde18 __CFRunLoopRun + 2769 24 CoreFoundation 0x00007fff205ccc60 CFRunLoopRunSpecific + 567 25 HIToolbox 0x00007fff28ac5dc3 RunCurrentEventLoopInMode + 292 26 HIToolbox 0x00007fff28ac5b25 ReceiveNextEventCommon + 587 27 HIToolbox 0x00007fff28ac58c3 _BlockUntilNextEventMatchingListInModeWithFilter + 70 28 AppKit 0x00007fff22cdf63e _DPSNextEvent + 864 29 AppKit 0x00007fff22cdde11 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1364 30 AppKit 0x00007fff22cd0185 -[NSApplication run] + 586 31 AppKit 0x00007fff22ca4330 NSApplicationMain + 816 32 IINA 0x000000010097d429 main + 9 33 libdyld.dylib 0x00007fff204f1e6d start + 1 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a7936 __pthread_kill + 10 2 libsystem_c.dylib 0x00007fff2042b411 abort + 120 3 libc++abi.dylib 0x00007fff20499ef2 abort_message + 241 4 libc++abi.dylib 0x00007fff2048b5fd demangling_terminate_handler() + 266 5 libobjc.A.dylib 0x00007fff203843d3 _objc_terminate() + 96 6 libc++abi.dylib 0x00007fff20499307 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x00007fff204992a9 std::terminate() + 41 8 libdispatch.dylib 0x00007fff2032c86a _dispatch_client_callout + 28 9 libdispatch.dylib 0x00007fff20338b9f _dispatch_main_queue_callback_4CF + 940 10 com.apple.CoreFoundation 0x00007fff2060c32e CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9 11 com.apple.CoreFoundation 0x00007fff205cde18 __CFRunLoopRun + 2769 12 com.apple.CoreFoundation 0x00007fff205ccc60 CFRunLoopRunSpecific + 567 13 com.apple.HIToolbox 0x00007fff28ac5dc3 RunCurrentEventLoopInMode + 292 14 com.apple.HIToolbox 0x00007fff28ac5b25 ReceiveNextEventCommon + 587 15 com.apple.HIToolbox 0x00007fff28ac58c3 _BlockUntilNextEventMatchingListInModeWithFilter + 70 16 com.apple.AppKit 0x00007fff22cdf63e _DPSNextEvent + 864 17 com.apple.AppKit 0x00007fff22cdde11 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1364 18 com.apple.AppKit 0x00007fff22cd0185 -[NSApplication run] + 586 19 com.apple.AppKit 0x00007fff22ca4330 NSApplicationMain + 816 20 0x000000010097d429 main + 9 21 libdyld.dylib 0x00007fff204f1e6d start + 1 Thread 1:: com.apple.rosetta.exceptionserver 0 runtime 0x00007ffdfff675d8 0x7ffdfff65000 + 9688 1 runtime 0x00007ffdfff70bc8 0x7ffdfff65000 + 48072 2 runtime 0x00007ffdfff72538 0x7ffdfff65000 + 54584 Thread 2: 0 runtime 0x00007ffdfffbf99c 0x7ffdfff65000 + 371100 Thread 3:: Dispatch queue: com.colliderli.iina.controller 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a3d3e __psynch_cvwait + 10 2 com.apple.Foundation 0x00007fff2126f5c0 -[NSOperation waitUntilFinished] + 697 3 com.apple.CoreFoundation 0x00007fff205952a7 CFXNotificationPost + 910 4 0x0000000100ac7dde PlayerCore.postNotification(:) + 190 5 0x0000000100ac0a84 PlayerCore.fileLoaded() + 1908 6 0x0000000100ae9883 MPVController.onFileLoaded() + 1523 7 0x0000000100ae8810 MPVController.handleEvent(_:) + 416 8 0x0000000100aefd0a partial apply for closure #1 in MPVController.readEvents() + 42 9 0x0000000100ae39de thunk for @escaping @callee_guaranteed () -> () + 14 10 libdispatch.dylib 0x00007fff2032b673 _dispatch_call_block_and_release + 12 11 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 12 libdispatch.dylib 0x00007fff2033263a _dispatch_lane_serial_drain + 606 13 libdispatch.dylib 0x00007fff203330fd _dispatch_lane_invoke + 366 14 libdispatch.dylib 0x00007fff2033cc5d _dispatch_workloop_worker_thread + 811 15 libsystem_pthread.dylib 0x00007fff204d34c0 _pthread_wqthread + 314 16 libsystem_pthread.dylib 0x00007fff204d2493 start_wqthread + 15 Thread 4: 0 runtime 0x00007ffdfffbf99c 0x7ffdfff65000 + 371100 Thread 5:: Dispatch queue: com.apple.SkyLight.UpdateManager.SerialSema 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a1356 semaphore_wait_trap + 10 2 libdispatch.dylib 0x00007fff2032b673 _dispatch_call_block_and_release + 12 3 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 4 libdispatch.dylib 0x00007fff2033263a _dispatch_lane_serial_drain + 606 5 libdispatch.dylib 0x00007fff203330fd _dispatch_lane_invoke + 366 6 libdispatch.dylib 0x00007fff2033cc5d _dispatch_workloop_worker_thread + 811 7 libsystem_pthread.dylib 0x00007fff204d34c0 _pthread_wqthread + 314 8 libsystem_pthread.dylib 0x00007fff204d2493 start_wqthread + 15 Thread 6:: Dispatch queue: com.Metal.CommandQueueDispatch 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a131a mach_msg_trap + 10 2 com.apple.framework.IOKit 0x00007fff22b9ccd3 io_connect_method + 384 3 com.apple.framework.IOKit 0x00007fff22b9caef IOConnectCallMethod + 186 4 com.apple.IOGPU 0x00007fff38d1d8be IOGPUCommandQueueSubmitCommandBuffers + 131 5 com.apple.IOGPU 0x00007fff38d11d40 -[IOGPUMetalCommandQueue _submitCommandBuffers:count:] + 670 6 com.apple.IOGPU 0x00007fff38d11a80 -[IOGPUMetalCommandQueue submitCommandBuffers:count:] + 65 7 com.apple.Metal 0x00007fff28689518 -[_MTLCommandQueue _submitAvailableCommandBuffers] + 811 8 com.apple.Metal 0x00007fff28691a9c __40-[_MTLCommandQueue submitCommandBuffer:]_block_invoke + 26 9 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 10 libdispatch.dylib 0x00007fff2033961e _dispatch_lane_barrier_sync_invoke_and_complete + 60 11 com.apple.Metal 0x00007fff28691a60 -[_MTLCommandQueue submitCommandBuffer:] + 112 12 com.apple.AppleMetalOpenGLRenderer 0x0000000122325f3d GLDContextRec::flushContext(bool) + 465 13 com.apple.AppleMetalOpenGLRenderer 0x00000001222d1aab GLDContextRec::loadCurrentQueries() + 767 14 com.apple.AppleMetalOpenGLRenderer 0x0000000122325aa8 gldUpdateDispatch + 4214 15 GLEngine 0x00007fff6c4a22ec gleDoDrawDispatchCoreGL3 + 674 16 GLEngine 0x00007fff6c45f39a glDrawArraysInstanced_STD_GL3Exec + 343 17 GLEngine 0x00007fff6c45eb24 glDrawArrays_UnpackThread + 33 18 GLEngine 0x00007fff6c49d45b gleCmdProcessor + 77 19 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 20 libdispatch.dylib 0x00007fff2033961e _dispatch_lane_barrier_sync_invoke_and_complete + 60 21 GLEngine 0x00007fff6c4230f9 glIsQuery_ExecThread + 19 22 libmpv.1.dylib 0x000000010fdbe9c1 gl_timer_start + 49 23 libmpv.1.dylib 0x000000010fdaa044 timer_pool_start + 36 24 libmpv.1.dylib 0x000000010fdafd8f pass_draw_osd + 111 25 libmpv.1.dylib 0x000000010fdab0ba gl_video_render_frame + 1738 26 libmpv.1.dylib 0x000000010fda330a render + 186 27 libmpv.1.dylib 0x000000010fdc3ce0 mpv_render_context_render + 784 28 0x0000000100a8676a specialized closure #1 in closure #1 in ViewLayer.draw(inCGLContext:pixelFormat:forLayerTime:displayTime:) + 154 29 0x0000000100a85185 closure #1 in ViewLayer.draw(inCGLContext:pixelFormat:forLayerTime:displayTime:) + 133 30 0x0000000100a869bd specialized ViewLayer.draw(inCGLContext:pixelFormat:forLayerTime:displayTime:) + 557 31 0x0000000100a851e1 @objc ViewLayer.draw(inCGLContext:pixelFormat:forLayerTime:displayTime:) + 33 32 com.apple.QuartzCore 0x00007fff27020241 CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 2002 33 com.apple.QuartzCore 0x00007fff2701f8a8 -[CAOpenGLLayer display] + 582 34 0x0000000100a854fa @objc ViewLayer.display() + 58 35 0x0000000100a85261 ViewLayer.draw(forced:) + 97 36 0x0000000100af13c2 partial apply for closure #1 in mpvUpdateCallback(:) + 18 37 0x0000000100ae39de thunk for @escaping @callee_guaranteed () -> () + 14 38 libdispatch.dylib 0x00007fff2032b673 _dispatch_call_block_and_release + 12 39 libdispatch.dylib 0x00007fff2032c856 _dispatch_client_callout + 8 40 libdispatch.dylib 0x00007fff2033263a _dispatch_lane_serial_drain + 606 41 libdispatch.dylib 0x00007fff203330fd _dispatch_lane_invoke + 366 42 libdispatch.dylib 0x00007fff2033cc5d _dispatch_workloop_worker_thread + 811 43 libsystem_pthread.dylib 0x00007fff204d34c0 _pthread_wqthread + 314 44 libsystem_pthread.dylib 0x00007fff204d2493 start_wqthread + 15 Thread 7:: mpv/mpv core 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a3d3e __psynch_cvwait + 10 2 libmpv.1.dylib 0x000000010fd37d09 mp_dispatch_queue_process + 345 3 libmpv.1.dylib 0x000000010fd746ce run_playloop + 2958 4 libmpv.1.dylib 0x000000010fd6a86c mp_play_files + 6860 5 libmpv.1.dylib 0x000000010fd5022e core_thread + 62 6 libsystem_pthread.dylib 0x00007fff204d6954 _pthread_start + 224 7 libsystem_pthread.dylib 0x00007fff204d24a7 thread_start + 15 Thread 8:: mpv/lua script (stats) 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a3d3e __psynch_cvwait + 10 2 libmpv.1.dylib 0x000000010fd4fa0f wait_wakeup + 95 3 libmpv.1.dylib 0x000000010fd503e5 mpv_wait_event + 357 4 libmpv.1.dylib 0x000000010fd6c3f6 script_wait_event + 102 5 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 6 liblua.5.1.dylib 0x000000010ce6010c luaV_execute + 3514 7 liblua.5.1.dylib 0x000000010ce56f19 luaD_call + 97 8 liblua.5.1.dylib 0x000000010ce53550 lua_call + 41 9 libmpv.1.dylib 0x000000010fd6bf53 load_scripts + 291 10 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 11 liblua.5.1.dylib 0x000000010ce56f08 luaD_call + 80 12 liblua.5.1.dylib 0x000000010ce5664f luaD_rawrunprotected + 84 13 liblua.5.1.dylib 0x000000010ce57180 luaD_pcall + 68 14 liblua.5.1.dylib 0x000000010ce535db lua_pcall + 105 15 libmpv.1.dylib 0x000000010fd6baeb run_lua + 1307 16 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 17 liblua.5.1.dylib 0x000000010ce56f08 luaD_call + 80 18 liblua.5.1.dylib 0x000000010ce5664f luaD_rawrunprotected + 84 19 liblua.5.1.dylib 0x000000010ce57180 luaD_pcall + 68 20 liblua.5.1.dylib 0x000000010ce5363f lua_cpcall + 45 21 libmpv.1.dylib 0x000000010fd6b533 load_lua + 147 22 libmpv.1.dylib 0x000000010fd76ba2 script_thread + 114 23 libsystem_pthread.dylib 0x00007fff204d6954 _pthread_start + 224 24 libsystem_pthread.dylib 0x00007fff204d24a7 thread_start + 15 Thread 9:: mpv/lua script (console) 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a3d3e __psynch_cvwait + 10 2 libmpv.1.dylib 0x000000010fd4fa0f wait_wakeup + 95 3 libmpv.1.dylib 0x000000010fd503e5 mpv_wait_event + 357 4 libmpv.1.dylib 0x000000010fd6c3f6 script_wait_event + 102 5 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 6 liblua.5.1.dylib 0x000000010ce6010c luaV_execute + 3514 7 liblua.5.1.dylib 0x000000010ce56f19 luaD_call + 97 8 liblua.5.1.dylib 0x000000010ce53550 lua_call + 41 9 libmpv.1.dylib 0x000000010fd6bf53 load_scripts + 291 10 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 11 liblua.5.1.dylib 0x000000010ce56f08 luaD_call + 80 12 liblua.5.1.dylib 0x000000010ce5664f luaD_rawrunprotected + 84 13 liblua.5.1.dylib 0x000000010ce57180 luaD_pcall + 68 14 liblua.5.1.dylib 0x000000010ce535db lua_pcall + 105 15 libmpv.1.dylib 0x000000010fd6baeb run_lua + 1307 16 liblua.5.1.dylib 0x000000010ce56ab6 luaD_precall + 455 17 liblua.5.1.dylib 0x000000010ce56f08 luaD_call + 80 18 liblua.5.1.dylib 0x000000010ce5664f luaD_rawrunprotected + 84 19 liblua.5.1.dylib 0x000000010ce57180 luaD_pcall + 68 20 liblua.5.1.dylib 0x000000010ce5363f lua_cpcall + 45 21 libmpv.1.dylib 0x000000010fd6b533 load_lua + 147 22 libmpv.1.dylib 0x000000010fd76ba2 script_thread + 114 23 libsystem_pthread.dylib 0x00007fff204d6954 _pthread_start + 224 24 libsystem_pthread.dylib 0x00007fff204d24a7 thread_start + 15 Thread 10:: AMCP Logging Spool 0 ??? 0x00007ffe94c0aab8 ??? 1 libsystem_kernel.dylib 0x00007fff204a1356 semaphore_wait_trap + 10 2 com.apple.audio.caulk 0x00007fff2878e836 caulk::semaphore::timed_wait(double) + 110 3 com.apple.audio.caulk 0x00007fff2878e784 caulk::concurrent::details::worker_thread::run() + 30 4 com.apple.audio.caulk 0x00007fff2878e502 void* caulk::thread_proxympv log:
``` ```Steps to reproduce:
1a. Turn on Fullscreen option under "When Media is opened" section. The app will automatically crash when opening.
1b. Turn off Fullscreen option under "When Media is opened". Then, enter legacy full screen manually. Seek forward in quick succession and the app will crash.
1c. Like 1b, enter legacy full screen manually. Try skipping forward a chapter, and the app will crash.
1d. Enter legacy full screen manually, and click anywhere in the playhead. The app will crash.
How often does this happen? Without fail, this happens every single time I open media using legacy full screen and the multiple different actions listed in the Actual Behavior section.