Changes from 1.4.4 to 1.5

Mac OS 13+ is now required. I've started to use SwiftUI for new UI component and plan to rewrite as much of the UI code as I can to use it, and unfortunately, most SwiftUI components are either not available or not stable prior to MacOS Ventura. Most of IINA's UI is still written using Interface Builder XIBs, which are delicate, bug prone, difficult to use with source control, slow, and do not support the bells & whistles of more recent iOS & MacOS releases. (Are any IINA Advance users even using MacOS 12 or below?)

This release could almost have been called v1.4.5, because most of the changes could be considered bug fixes. But quite a lot needed to be changed behind the scenes to make these improvements happen, and the requirement bump from MacOS 10.15 to 13 (detailed above) made a full version bump seem more prudent.

I realize this release is quite a bit lighter in changes that previous releases but, finding the code in a stable local maxima, now seems like a great time to publish. The future has too many variables. Best to seize the day.

Improvements

• Saved window state now stores media locations as MacOS bookmark data in addition to raw file paths, for both the currently playing media & all the playlist items. Don't confuse these with the more common concept of a "bookmark" as a synonym for a "favorite": Apple's bookmark refers to a proprietary Apple technology which uses an opaque blob of data which contains information used to identify a file. [From what I could gather, in modern Apple file systems, a unique numeric ID is assigned to every file which never changes until the file is completely deleted. It seems likely that bookmark data keeps track of this ID in addition to other metadata]. This means that even when a file is moved or renamed it can still be found, thus avoiding the dreaded "Cannot play file or stream!" error when restoring. More details (read at the first at least):
  • This is an Apple technology, so it only works for files on volumes which are in MacOS format: your Mac's local disk and Mac-formatted disks attached to its USB ports. Bookmarks won't work for Windows or Linux formatted disks (or more precisely, they will be created but won't offer much useful functionality over traditional file paths. They do encrypt the location data, but for the time being I am continuing to store the file path separately to use as a fallback). I have not tested it for Mac-formatted disks being served via local network, but I'm guessing those won't work either. Bookmarks will not be used at all for network streaming URLs.
  • The underlying player engine, mpv, doesn't support MacOS bookmarks; it uses file system URLs. So if for example, a file in the playlist is renamed or moved while the window is open, even if a bookmark has already been saved for that file, trying to navigate the playlist to play that file will be skipped because the file was not found, because mpv stores playlist items as URLs. However, quitting & re-opening the app will fix the broken link, because playlist URLs are regenerated from bookmark data at launch.
  • Creating bookmarks is a time-intensive process (about ~1sec per media file), so this necessitates some strategic handling. When items are added to the playlist, they are added via static URLs (which will break if the items are renamed/moved), and if the player is exited too quickly after that, only those URLs will be saved. A background task is used to silently generate bookmark data for each of them one-by-one. When quitting, any bookmark data which is created will be saved, and thereafter will be used at the next launch to get an up-to-date URL for the item. The currently playing item, unlike the other playlist items, will always be saved with a bookmark, to prevent a renamed file from causing the window to error out during restore.
• Video rendering now draws directly from the DisplayLink callback instead of enqueuing to a DispatchQueue from the mpv render callback.
  • More details: this will be controversial (for those who care) because doing this causes Xcode to emit a "priority inversion" warning. However, my own testing suggests the benefits outweigh the risks. Notably, it appears to significantly reduce redraw latency which has become even more crucial when using keepaspect=yes keepaspect-window=no, as I am doing with IINA Advance 1.4+. My unproven thesis is that mpv will drop frames or otherwise account for heavy load, rendering the Xcode warning irrelevant. This is taking a risk, which I love to do, but those who have read this far in this bullet point, please report any new performance issues or major hiccups.
• Significant improvements to playlist item loading, giving better load priorities to ensure that playlists have a much snappier load experience. In prior versions, when multiple windows were being restored, each with large playlists, sometimes the playlist items would fail to show up for several seconds.
• Replaced the "restore taking too long" prompt with a custom-built dialog (written in SwiftUI, of course). The old prompt used the built-in MacOS modal alert, which in recent versions of MacOS could not be dismissed via code once shown. The new custom dialog corrects that.

Bug Fixes

• Major: Finally fixed a timing issue during restore which could result in playlist items getting lost from the restored state if the app was quit too quickly after opening.
• Major: Finally fixed jerky behavior of the preview time & thumbnail when using scroll-to-seek. Previously, the scroll position seemed to want to "jump back" to a previous position in the time slider before continuing with the scrolled-to position. This was more noticeable when quickly scrolling large distances in the slider. (Embarrassingly, this originally worked correctly when I implemented it during v1.3 development, but just prior to the final v1.3 release this bug was re-introduced. So for those downloading the releases only, this never worked as intended. Oopsie).
• Fixed from 1.4: momentum scrolling was broken (caused by changes made by adding pinch-to-zoom).
• Fixed a bug introduced in v1.4: music mode layout for vertical video given incorrect layout constraints after toggling video from hidden to shown.
• Fixed bug introduced in v1.4: brief playlist layout glitches when restoring music mode windows.
• Minor fixes to music mode layout (vs. 1.4+) when video is hidden to ensure volume icon is not too close to playback controls.