If a NAS share cannot be reached, iina fails to start

[triplestepab]

If a NAS share cannot be reached, iina fails to start

[low-batt]

Sorry, was offline doing stuff. The way you found works fine. Another way is to delete the cached copy of the Open Recent list from user defaults. In Terminal run this command:

defaults delete com.colliderli.iina recentDocuments

With the copy of the list deleted the workaround is unable to repopulate the list of recent documents.

[low-batt]

Your understanding is correct. IINA 1.3.4 does not have this problem. This is a serious regression added in IINA 1.3.5. The offending code was added as a workaround to address issue #4688.

As of Sonoma, macOS will clear the recent documents list for IINA if you execute an IINA binary that is not signed. This is a significant problem for developers who are constantly running such binaries. A workaround was developed that stores the list in UserDefaults. Upon startup if IINA detects the open recent list is empty and the list saved in UserDefaults is not then it will restore the open recents list using the copy saved in UserDefaults.

Initially this was only coded to be used by developers. But this meant users who try the publicly available nightly builds would have their list of recent documents erased. Signing nightly builds was investigated but rejected due to security risks. So the workaround was added to 1.3.5. Testing missed that restoring the list would cause macOS to require the files to be accessible.

Technically IINA isn't failing to start. It is blocked while macOS is trying to access the file and there is a long timeout before macOS gives up. Worse this will happen for each file that is on a remote disk, so effectively IINA is failing to start.

We did not find a way to prevent macOS from doing this, so the fix was to change the workaround to be controlled by a hidden setting that is disabled by default. This allows developers to still use the workaround, but disables it for normal users. This fix will be in the next release of IINA.

In IINA 1.3.5 this problem can be worked around by running a command to delete the saved copy of the list that is stored in UserDefaults. See this comment above.

It appears that users who are not running unsigned IINA binaries are encountering this problem. That could happen if you first run 1.3.5. Then go back to 1.3.4 and clear the list yourself. Then run 1.3.5. When you clear the list in 1.3.5 it clears the copy in UserDefaults. But that does not happen in 1.3.4. So in this scenario IINA 1.3.5 thinks macOS cleared the list and tries to repopulate it using the copy in UserDefaults. That seems like it would be a rare case. That raises the question as to whether macOS is sometimes glitching and clearing the list for no reason. At the moment how this is happening is a mystery.

[low-batt]

I suspect the method NSURL.bookmarkData is triggering the request to mount the disk. I found that if I declined each request to mount the disk eventually IINA would be able to open a video. If I then quit IINA normally the problem would not reproduce the next time I started IINA. Continuing to investigate…

[svobs]

@low-batt this reminds me that I meant to file an issue I've seen since restoreRecentDocuments was introduced. When the recent documents contained items on my remote NAS drive and I changed to a different WiFi network (in my case, tethered to my phone), the check for stale documents would take a really long time to time out, and this would get multiplied by the number of remote files. Because the check is on the main thread, when the list contained a lot of remote files it could take minutes for restoreRecentDocuments to return. In the meantime IINA would appear to be hung. Notably, this long timeout did not appear to occur if I stayed on the same network and unmounted the drive.

I did a workaround by putting the work on the HistoryController dispatch queue. But found a second gotcha. I had to be careful not to modify the recent documents list (e.g. using noteNewRecentDocumentURL) on two separate threads concurrently, because it could cause a sporadic crash.

Hope this helps.

[low-batt]

Caught me testing a fix for this. The creation of the URL in this line of code:

iina/iina/AppDelegate.swift

Line 1019 in 83b6725

let bookmark = try? URL(resolvingBookmarkData: asData, bookmarkDataIsStale: &isStale) else {

Needs to pass options to prevent mounting of an offline volume.

I will also test the scenario you describe and confirm the fix also addresses that case.

[low-batt]

@svobs The proposed fix solves the problem with the workaround triggering requests to the user to mount and unmounted volume. However I don't see a way to correct the problem with a long delay when a mounted volume is unreachable, like in the scenario you mentioned. So for that reason I have added a preference that is set to false by default.

This means users that try nightly builds or build IINA themselves will have their recent documents list cleared by macOS. Unfortunate, but this is a macOS problem and since our workaround has side effects I think it is better to expose users to the macOS behavior.

Thoughts?

[svobs]

Unfortunate, but this is a macOS problem and since our workaround has side effects I think it is better to expose users to the macOS behavior.

Sadly I can't disagree...

I'm assuming everyone involved with this issue is using SMB (aka Samba) file sharing. I've had a lot of headaches with it on my Macs over the last few years. To summarize what I learned: around 2011, Apple stopped using standard Samba after the project changed its licensing to GPLv3, and started developing their own version. For reasons I don't fully understand, Apple's version was absolutely terrible for many years. I recall often getting as recently as Big Sur (I think?) I'd often get a spinning beach ball cursor which would make the Finder unusable for 2 minutes at a time. I still have a shell script I would use (sudo -S killall NetAuthSysAgent; killall Finder) when things started getting unusable, though sometimes a reboot was the only way to reconnect to shares. Recent updates to MacOS have made considerable improvements. I still experience random connection errors, but they are less frequent and my Mac recovers faster and cleanly each time.

All of the above is a long-winded attempt to map out the environment we are trying to integrate with, and to support my otherwise unhelpful assertion that I doubt there's a cleaner solution available at present.

[low-batt]

@riobard Continuing the discussion from issue #2907…

Apple made a change in macOS Sonoma to the macOS sharedfilelistd daemon such that it requires the code signature of the executable reading the list to match the signature of the code that stored the list. If it does not then sharedfilelistd clears the list. For users that means the Open Recent menu will be empty if they test one of IINA's nightly builds as those are unsigned. For developers or users who build IINA with Xcode it effectively means the Open Recent feature is broken. This is issue #4688.

A workaround was added for #4688 that keeps a copy of the list in IINA's user defaults. When IINA starts it checks to see if the Open Recent list is empty. If that is true and there is a copy of the list saved in user default then IINA will repopulate the list. It was not noticed that the workaround could trigger a mount request when repopulating the Open Recent list.

@riobard To be sure our understanding is correct, are you running macOS Sonoma and did you run an unsigned version of IINA such as a nightly build or your own build? The workaround should not be kicking in unless the Open Recent was cleared by this macOS Sonoma "feature".

The proposed fix tells macOS to not prompt the user to mount the volume if it is offline. However there was a second problem. If macOS thinks the volume is online, but it is actually unreachable then the user is still prompted. I was not able to find a way to stop that, so the fix changes this workaround to be disabled by default.

[riobard]

@low-batt Thanks very much for the information. To be clear I'm running on macOS Sonoma 14.5 with a release build of IINA 1.3.5 downloaded from the home page at https://iina.io so not nightly builds or my own builds.

[riobard]

Additionally, can I make a feature request related to this? Can we have a setting in preferences to disable recording recently opened files altogether? There are numerous cases where that list leaks private information and/or create awkward moments when the user is screen-sharing with others or projecting in lectures…

[low-batt]

The ability to disable keeping history is already there. Open IINA's settings, scroll down on the General tab to the History section and you will see the settings.

I'm a worried about why this is kicking in without running an unsigned version of IINA. The other way this could be triggered is if after running 1.3.5 you go back to 1.3.4 and under 1.3.4 you clear the Open Recent list. When you clear it under 1.3.5 the list is user defaults is cleared. But going back and clearing under older versions will leave the copy in user defaults and make 1.3.5 think macOS cleared the list and it needs to be restored. I will take another look at the code and see if I missed something.

[riobard]

Great but right now I cannot change that setting as the app does not launch… 😂 Anyway way I can clear that list and launch IINA in a clean state?

[riobard]

Alright, figured out one way out:

1. Download IINA 1.3.4 and it open successfully.
2. Then disable history and recently opened files in preferences.
3. Then upgrade to 1.3.5.

It works for now!

[low-batt]

Be certain to run that full command. If you leave off recentDocuments at the end you will reset most of your IINA configuration.

[45gfg9]

Hi all, I'm experiencing the same issue yesterday, while I was on a plane and (of course no connection) and IINA just refuses to start.

Read about this issue and yes, I am also using a Samba share, on macOS Sonoma 14.5, IINA 1.3.5 Build 141 installed by Homebrew (so I guess it just downloads from iina.io and thus signed). One thing I don't understand is that this problem didn't occur to me in a previous version (1.3.4), and in 1.3.4, when the drive isn't connected, IINA starts with an empty "Open Recent" list. So this is happening to the signed version as well, or (probably) I have some misunderstanding?

I had a look at my macOS version history, it showed that macOS 14.5 was installed on 2024/5/25. IINA 1.3.5 was released on 6/1, so there was a week's gap and since I am a relatively heavy user I can be sure that 1.3.4 was working like a charm under macOS 14.5.