On MacOS Ventura; Error: "Failed to recognize file format" when attempting to play any YouTube video

[PuffyRainbowCloud]

Describe the bug
When attempts are made to play a YouTube video on either of my machines running macOS Ventura using MPV I receive the error message "Failed to recognize file format" and nothing plays. I can play the same videos fine using SyncPlay and MPV on Windows 10. This applies to SyncPlay version 1.6.8, 1.6.9, and 1.7 Beta 1.

To Reproduce
Steps to reproduce the behavior:

1. Launch SyncPlay.
2. Fill out relevant server- and room information.
3. Choose MPV as the video player.
4. Attempt to play a YouTube URL via any of the methods within the UI of MPV or SyncPlay.

Expected behavior
The linked YouTube video should start playing.

Version and platform:

• OS: macOS Ventura 13.0
• Syncplay version and build type: Syncplay 1.6.8
• Media player and version: MPV 0.35.0

[Et0h]

Does it work fine if you're running mpv on its own without Syncplay? Do you have the latest version of ytdl installed?

[girlmaya]

Does it work fine if you're running mpv on its own without Syncplay?

Yes, it plays fine in mpv. It doesnt even reach mpv from syncplay as far as i can tell. Can provide info just let me know, i would really like this fixed

Edit:

• macOS Big Sur 11.7.3
• Syncplay v1.7.0 beta 1
• mpv 0.35.0

[ReeverM]

I'm having the exact same issue on Windows 10. When I /qa it, it removes it from the queue immediately seemingly without reaching mpv (just the "x has updated the playlist" message pops up).

When I turn off shared playlists, /qa the youtube video and then turn on shared playlists again, it DOES reach mpv but returns "failed to recognize file format" but in this case does NOT remove the entry from the playlist.

I initially thought it was related to ffmpeg, so I installed that and now mpv plays pasted youtube videos fine (lua script to paste) but the playlist issue prevails.

[girlmaya]

on Windows 10.

it DOES reach mpv but returns "failed to recognize file format"

I think this is a different bug to what i'm experiencing on macOS. Not sure about the original issue creator

[suhailskhan]

Having the same issue with macOS Sonoma. My mpv is able to play from YouTube URLs without Syncplay.

• macOS Sonoma 14.1
• Syncplay 1.7.1 RC1
• mpv 0.36.0
• yt-dlp 2023.10.13

[girlmaya]

Any update on this?

[suhailskhan]

My workaround is to substitute mpv with IINA, an mpv-based player with many enhancements made specifically for macOS. It works just fine with Syncplay.

[Et0h]

Thanks for the workaround @suhailskhan - I've now added it to the FAQ at https://syncplay.pl/guide/trouble/ to benefit others who have the same issue.

[suhailskhan]

Out of curiosity, I looked into the problem a little more and encountered #379.

I captured a debug log using the instructions @albertosottile provided in that issue thread, and interestingly the log appeared to similar to the one presented in the thread. Even though the logs are similar, this earlier issue ended up being resolved in an earlier release of Syncplay. I will leave my log at the end of this comment.

Here is my system and the versions of all the software I tested with:

• macOS Sonoma 14.4.1 (arm64)
• Syncplay 1.7.1
• mpv 0.37.0 (x86 build, installed with Homebrew as a cask)
• Python 3.12.2 (installed with MacPorts at /opt/local)
• yt-dlp 2024.03.10 (installed with pipx at ~/.local)

[17:59:25] player << Python path configuration:
[17:59:25] player << PYTHONHOME = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << PYTHONPATH = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << program name = '/opt/local/Library/Frameworks/Python.framework/Versions/3.12/Resources/Python.app/Contents/MacOS/Python'
[17:59:25] player << isolated = 0
[17:59:25] player << environment = 1
[17:59:25] player << user site = 1
[17:59:25] player << safe_path = 0
[17:59:25] player << import site = 1
[17:59:25] player << is in build tree = 0
[17:59:25] player << stdlib dir = '/Applications/Syncplay.app/Contents/Resources/lib/python3.12'
[17:59:25] player << sys._base_executable = '/opt/local/Library/Frameworks/Python.framework/Versions/3.12/bin/python3.12'
[17:59:25] player << sys.base_prefix = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << sys.base_exec_prefix = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << sys.platlibdir = 'lib'
[17:59:25] player << sys.executable = '/Users/suhailskhan/.local/pipx/venvs/yt-dlp/bin/python'
[17:59:25] player << sys.prefix = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << sys.exec_prefix = '/Applications/Syncplay.app/Contents/Resources'
[17:59:25] player << sys.path = [
[17:59:25] player << '/Applications/Syncplay.app/Contents/Resources',
[17:59:25] player << '/Applications/Syncplay.app/Contents/Resources/lib/python312.zip',
[17:59:25] player << '/Applications/Syncplay.app/Contents/Resources/lib/python3.12',
[17:59:25] player << '/Applications/Syncplay.app/Contents/Resources/lib/python3.12/lib-dynload',
[17:59:25] player << ]
[17:59:25] player << Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
[17:59:25] Not ready to send due to error
[17:59:25] <mpv> Ready to send: True
[17:59:25] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:25] <mpv> Throttling message send, so sleeping for 0.05
[17:59:25] <mpv> Throttling message send, so sleeping for 0.05
[17:59:25] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:25] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] <mpv> Throttling message send, so sleeping for 0.05
[17:59:26] player >> ['script-message-to', 'syncplayintf', 'get_paused_and_position']
[17:59:26] player << Python runtime state: core initialized
[17:59:26] player << ModuleNotFoundError: No module named 'encodings'
[17:59:26] player << Current thread 0x0000000200ef3240 (most recent call first):
[17:59:26] player << <no Python frame>
[17:59:26] player << youtube-dl failed: unexpected error occurred

[albertosottile]

@suhailskhan The problem is that the location of the Python that runs youtube-dl(/opt/local/Library/Frameworks/Python.framework/Versions/3.12/bin/python3.12) does not match the paths foreseen in https://github.com/Syncplay/syncplay/pull/381/files. Unfortunately, it is impossible for me to guess this for all the possible configurations (and the use of pipx definitely did not facilitate this). Ultimately, I think these are subprocess bugs more than Syncplay bugs...