fix: python 3.14 compat issues on macOS

[vidonnus]

Fix Python 3.14 Compatibility Issue on macOS

Issues

Closes #473
Closes #484

Problems

Issue 1: RuntimeError on startup (Python 3.14+)

On Python 3.14+, the application crashes on startup with:

RuntimeError: context has already been set

This occurs in mpv_shim.py when calling multiprocessing.set_start_method() on macOS. In Python 3.14, the multiprocessing context is initialized earlier in the import process.

Issue 2: Objective-C fork crash (Python 3.14 on macOS)

On Python 3.14 with macOS, the application crashes with:

objc[41698]: +[NSMutableString initialize] may have been in progress in another thread when fork() was called.
objc[41698]: We cannot safely call it or ignore it in the fork() child process. Crashing instead.

This occurs because forkserver (which still involves forking) is incompatible with macOS's Objective-C runtime when GUI frameworks are loaded.

Root Cause

The original fix from 2020 set forkserver on macOS to avoid crashes with the fork start method. However:

1. Python 3.7: Default was fork (unsafe with Objective-C) → forkserver was a workaround
2. Python 3.8+: Default changed to spawn (safe with Objective-C)
3. Python 3.14:
   • The multiprocessing context is set earlier, causing RuntimeError if we try to set it again
   • The explicit forkserver setting now causes crashes with Objective-C frameworks

The forkserver method still uses os.fork() internally, which is problematic on macOS when Objective-C frameworks (tkinter, pystray, PIL) have been initialized.

Solution

1. Wrap in try/except: Handle the RuntimeError when context is already set (Python 3.14+)
2. Use spawn instead of forkserver: Safe for all Python versions on macOS

• Python 3.7: Overrides unsafe fork default with spawn
• Python 3.8-3.13: Explicitly sets spawn (already the default, but ensures it)
• Python 3.14+: Fixes both the RuntimeError and Objective-C crash

Changes

jellyfin_mpv_shim/mpv_shim.py

if sys.platform.startswith("darwin"):
    try:
        # Use 'spawn' to avoid Objective-C fork crashes with GUI frameworks.
        # - Python 3.7: default is 'fork' (unsafe with Obj-C)
        # - Python 3.8+: default is 'spawn' (this is a no-op but explicit)
        # - Python 3.14: 'forkserver' also crashes with Obj-C (issue #473)
        multiprocessing.set_start_method("spawn")
    except RuntimeError:
        # Context already set, ignore
        pass

Impact

• ✅ Fixes RuntimeError on Python 3.14+ when context is already set
• ✅ Fixes Objective-C crash on Python 3.14+ macOS (issue Can't Launch on macOS #473)
• ✅ Maintains compatibility with Python 3.7+ (project requirement)
• ✅ Uses the safest multiprocessing method for macOS with GUI frameworks
• ✅ Graceful degradation if context is already set
• ✅ No functional changes to multiprocessing behavior

Technical Details

The spawn method starts a fresh Python interpreter for each process, avoiding:

• Objective-C runtime state being copied via fork
• Thread safety issues with forked processes
• GUI framework initialization conflicts

This is why Python 3.8 changed the macOS default from fork to spawn.

The try/except block ensures that if the context has already been set (Python 3.14+ behavior), we gracefully continue with the existing context rather than crashing.

Testing

Tested on:

• Python 3.14.2 on macOS (previously crashed with both errors, now works)
• Application starts successfully with GUI enabled
• Multiprocessing (tkinter windows, system tray) functions normally