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

[triplestepab]

System and IINA version:

• IINA: 1.3.5 Build 141

Expected behavior:

Double clicking a local file should just show the movie.

Actual behavior:

Double clicking a file opens Iina which then tries to check checks previous links/files (for no reason at all). As my NAS wasn't online I got an never ending popups of There was a problem connecting to the server “MyNasServerName”. Check the server name or IP address, and then try again. If you continue to have problems, contact your system administrator..

Starting Iina was impossible until I reconnected to the Nas.

Steps to reproduce:

I would guess:

• Open a movie on the nas
• Close Iina
• Disconnect the nas
• Open a local file

How often does this happen?

Every time; force quitting didn't help.

[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]

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]

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