LizardByte / Sunshine

Self-hosted game stream host for Moonlight.
http://app.lizardbyte.dev/Sunshine/
GNU General Public License v3.0
19.44k stars 945 forks source link

macOS 15 connection issues #3340

Open soerenkampschroer opened 1 week ago

soerenkampschroer commented 1 week ago

Is there an existing issue for this?

Is your issue described in the documentation?

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

On macOS 15 sunshine is not able to connect to the client when started as a service (brew services start sunshine-beta). The server will advertise but upon connecting the logs show that the connection times out.

It may be a permission issue connected to the new Local Network permission. As far as I know it's impossible to add or whitelist programs for the permission and there needs to be a popup where you can confirm or deny access. I did manage to get the last beta build to work as a service by deleting all sunshine related permissions and reinstalling it, but due to the frequent name change of the beta build it needs new permissions after every update. I have not been able to get the latest build running, even though I again removed all permissions and reinstalled the latest build again after doing the update.

However, sunshine works fine if it's started manually by running it in terminal as a command.

This was not an issue on macOS 14, so my guess is it's the new Local Network permission, which has caused issues with other apps as well.

Firewall is turned off.

Related thread on this issue: https://forums.developer.apple.com/forums/thread/760964

Expected Behavior

Client being able to connect.

Additional Context

No response

Host Operating System

macOS

Operating System Version

15.0.1

Architecture

amd64/x86_64

Sunshine commit or version

v2024.1029.45450

Package

macOS - Homebrew

GPU Type

AMD

GPU Model

AMD RX 6800

GPU Driver/Mesa Version

OS Drivers

Capture Method

None

Config

encoder = videotoolbox
output_name = 4128836

Apps

I'm only using Desktop.

Relevant log output

[2024-10-30 01:07:15.619]: Info: // Ignore any errors mentioned above, they are not relevant. //
[2024-10-30 01:07:15.619]: Info: 
[2024-10-30 01:07:15.619]: Info: Found H.264 encoder: h264_videotoolbox [videotoolbox]
[2024-10-30 01:07:15.619]: Info: Found HEVC encoder: hevc_videotoolbox [videotoolbox]
[2024-10-30 01:07:15.619]: Info: Executing Do Cmd: [/Users/soeren/Documents/Projects/sunshine-scripts/start.sh]
[2024-10-30 01:07:22.014]: Info: Executing [Desktop]
[2024-10-30 01:07:22.189]: Info: New streaming session started [active sessions: 1]
[2024-10-30 01:07:22.748]: Error: opening microphone '' failed. Please set a valid input source in the Sunshine config.
[2024-10-30 01:07:22.748]: Error: Available inputs:
[2024-10-30 01:07:22.748]: Error:   Built-in Input
[2024-10-30 01:07:22.748]: Error:   BlackHole 16ch
[2024-10-30 01:07:22.748]: Error:   WH-H900N (h.ear)
[2024-10-30 01:07:22.748]: Error:   Built-in Line Input
[2024-10-30 01:07:22.748]: Error: Unable to initialize audio capture. The stream will not have audio.
[2024-10-30 01:07:32.259]: Info: 192.168.0.155: Ping Timeout
[2024-10-30 01:07:32.263]: Error: Initial Ping Timeout
ReenigneArcher commented 1 week ago

due to the frequent name change of the beta build

What do you mean by this? Specifically what name is changing?

soerenkampschroer commented 1 week ago

@ReenigneArcher the permission system tracks sunshine under the name of it's build for some reason. So if you update the beta build you need to give permissions all over again. For example for the Local Network permission it still lists "sunshine-v2024.1025" even though I have version v2024.1029.45450 installed. For every other permission (like screen recording) I'm getting a popup to allow it but I have only managed to get a popup once for Local Network. I've attached the settings screen you can see the old version is still there.

Screenshot 2024-10-30 at 01 24 43

ReenigneArcher commented 1 week ago

Oh that makes sense.

@Hazer do you have some idea about how to solve this?

soerenkampschroer commented 1 week ago

I just had another go at it and I think I figured it out by accident. The linked Apple developer thread talks about "identifying responsible code" so I tried self signing the binary before launching sunshine and this time it did prompt me for all permissions including Local Network.

So the steps would be:

  1. (optional) Uninstall sunshine
  2. Remove all permissions granted to sunshine
  3. Install sunshine-beta
  4. Run codesign -s - --force --deep /usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine (note the path will be different with every update)
  5. Start the server, grant permissions
  6. Connect a client and grant Local Network permissions

This will pollute the permissions screen a little, as you can't remove anything from there. I'm not sure if the OS will clear out old entries after a while, we'll see.

Screenshot 2024-10-30 at 01 45 52

ReenigneArcher commented 1 week ago

Maybe create a symbolic link and grant the permission to that instead of the exact binary?

soerenkampschroer commented 1 week ago

When I was starting sunshine manually I just typed sunshine which points to a symlink in /usr/local/bin/sunshine => /usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine. That's just how homebrew installs things. It will then show up as sunshine-v2024.XXXX. I don't know if that's different for the stable/release version, I just assumed it was a beta thing (can't test stable because of #3180 ).

Not sure what brew service uses, that might be something to look into. Maybe that's pointing directly to the binary.

But I'd imagine that macOS will follow symlinks to get to the binary anyway, otherwise couldn't you just steal permissions from another app by changing a symlink?

BTW: Thanks for your effort developing sunshine, it really is a great app! 👍

ReenigneArcher commented 1 week ago

I don't know if that's different for the stable/release version

It's unlikely to be different once we release stable.

soerenkampschroer commented 1 week ago

I poked around a little more, and the reason macOS recognizes Sunshine as a new app after each update is that the actual binary is named with the version included:

/usr/local/Cellar/sunshine-beta/2024.1029.45450/bin/sunshine-v2024.1029.45450

This is symlinked to sunshine in the same folder, which is then linked to /usr/local/bin/. So, macOS does follow symlinks, but it appears that to retain permissions, the binary needs to be named simply sunshine.

Additionally, the binary must be signed, either by you or the user; otherwise, the OS won’t prompt for permissions.

ReenigneArcher commented 1 week ago

The binary naming is all from homebrew, so there's nothing we can do about that as far as I know. And the version needs to be specified or else I believe homebrew won't understand when to do updates.

We could potentially add a step in homebrew to do the signing, which would effectively sign on the user's side. We don't actually publish macOS binaries, they are compiled by the user.

soerenkampschroer commented 6 days ago

@ReenigneArcher I managed to fix both signing and naming issues by editing the homebrew formula (sunshine-beta.rb).

To move the binary instead of symlinking it, you have to add a line right after calling make. Then to sign it, call codesign after that:

cd "build" do
  system "make"
  system "make", "install"

  # Move binary instead of symlinking it
  bin.install "sunshine-#{ENV["BUILD_VERSION"]}" => "sunshine"

  bin.install "tests/test_sunshine"
end

# Codesign installed binary
system "codesign", "-s", "-", "--force", "--deep", "#{bin}/sunshine"

It should then prompt for all permissions needed and keep them after updating as it shows up just as sunshine in the permission dialog.

Screenshot 2024-10-31 at 13 51 51

ReenigneArcher commented 6 days ago

@soerenkampschroer Nice work! Would you mind making a PR? This is where we keep the homebrew formula template: https://github.com/LizardByte/Sunshine/blob/master/packaging/sunshine.rb

ReenigneArcher commented 6 days ago

I saw you forked our homebrew repo, to clarify the formula lives in the Sunshine repo, and is then synced over to the homebrew repo automatically.

soerenkampschroer commented 6 days ago

@ReenigneArcher right, thank you! I was just about to file the pull request.

Also, do you want me to only edit the formula for sunshine-beta or sunshine as well because I can't test the non-beta formula at the moment due to build errors. I can add the changes now or when the main build is able to compile to have it tested.

ReenigneArcher commented 6 days ago

I mean, you forked the wrong repo. The file to modify is in the URL I pasted above. So to update the "beta" you need to update it here in the Sunshine repo directly (not in the homebrew repo).

If you want you can also update the stable in the homebrew repo, but it's not really necessary as that package is not usable as far as I know.

soerenkampschroer commented 6 days ago

I created the pull request on the main repo. Please let me know if it checks out. I don't exactly understand how sunshine-beta.rb is created compared to the regular sunshine.rb as both need to eventually be edited but sunshine-beta.rb is the one that is currently an issue here.

cathyjf commented 6 days ago

The changing filename of the binary is not what is causing the permissions to need to be re-granted with each new build. See my other comment: https://github.com/LizardByte/Sunshine/pull/3348#issuecomment-2450859080.

soerenkampschroer commented 6 days ago

Hey @cathyjf, you're right. I re-checked the permissions dialog in System Settings and now it's listing multiple "sunshine" entries. So I guess there is nothing we can do about that? I just read your comments on the pull request, thanks for clearing that up!

About the code signing thing: I wasn't aware that brew signs the build. But on my machine, unless you sign the binary yourself with codesign, the OS will not ask about Local Network permissions. Are you on macOS 15 and seeing different behavior? I'll install everything from scratch again tomorrow to make sure. Again, should have read your other comments first.

I'll keep the pull request open for the time being, just in case the codesign line does make a difference. But moving the binary doesn't do the trick, unfortunately.

Sorry about the confusion with the new pull request @ReenigneArcher, I'll make sure to just edit it next time.

soerenkampschroer commented 5 days ago

I did some more testing/research and homebrew is indeed only signing on arm64. This was fine up until macOS 15, because on x86 systems the new Local Network permission behaves like all the other permissions do on arm64, which is why homebrew started signing on arm64 in the first place (see apply_ad_hoc_signature ).

At least that is how I understood it. It seems like this is an issue that homebrew should address, surely sunshine is not the only package affected by this.

In the meantime, to make the build work on Intel Macs running macOS 15 I think it makes sense to include a platform specific codesign call in the formula.

ReenigneArcher commented 5 days ago

In the meantime, to make the build work on Intel Macs running macOS 15 I think it makes sense to include a platform specific codesign call in the formula.

I agree. We just need to check for architecture, in addition to the OS now.

soerenkampschroer commented 5 days ago

I've updated the pull request. It now includes the check for intel macs. I don't know much ruby, so please excuse if the code isn't up to standards. I've tested it on my machine, and it signs the binary for me with the edit I made.

I still have to start sunshine twice, even after signing. The flow is like this:

First run of brew services run sunshine-beta:

Second run:

That's the only caveat, but it is working now 🎉

00Dchapellebot commented 4 days ago

sudo rm -rf "$(brew --cache --build-from-source sunshine-beta)"

brew tap LizardByte/homebrew

brew install sunshine-beta

After successfully getting everything running I'm now experiencing a Similar Issue.

I'm wondering what the command is to 'update' sunshine-beta? // Or to uninstall it and remove permissions ?? (so I can install it again). After updating to Mac os sequoia, from Sonoma, now my WiiU client refuses to connect...to my Mac sunshine server. Apparently it's related to Local Network, privacy and security permissions in the new os (explained earlier)... where the first time you launch the Sunshine App it asks you to grant permission for Local network access... but if you have a previously installed version of sunshine with, an updated OSx it never asks for Local network permission, and Your client device Never connects...Again....Any Help? Thx in Advance!

cathyjf commented 4 days ago

Re: @00Dchapellebot, I can't determine what your problem is from what you're saying. However, unlike most permissions, there's no way that I know of to reset the state of the local network permission to force it to be re-prompted. (For example, you could force the Accessibility permission to be re-prompted using tccutil reset Accessibility, but there's no similar feature for local networking.) I don't think your problem is caused by not being able to reset this permission, however.

What steps have you taken to narrow down that the problem in your case is caused by the local network permission? There are a lot of other reasons that the client might not be able to connect.

You can uninstall a brew formula with brew uninstall sunshine-beta, if that is what you are asking. Or you can use brew update to update. I'm not sure these are related to your problem either, but you did ask about it.

cathyjf commented 4 days ago

To help figure out if the local network permission is actually the culprit, try directly running the binary in the foreground of your shell in Terminal.app (rather than using a background service). The local network permission shouldn't be required for processes run in this way.

cathyjf commented 4 days ago

I'm now noticing a problem on my machine where sunshine can access the local network, regardless of whether it is granted local network permission! What this suggests to me is that this setting is buggy. A review of the documentation, and posts from Apple employees on Apple's forums, implies that the feature works best for app bundles, rather than loose binaries like Sunshine. This part of the bug is tracked at https://github.com/orgs/LizardByte/discussions/547.

Separately, another part of the problem may be missing fields in the Info.plist file. I opened https://github.com/orgs/LizardByte/discussions/549 to track that part of the bug.

soerenkampschroer commented 4 days ago

Same here, today's update broke connectivity for me. With v2024.1101.204249 the server is not visible on the client. Logs are fine, no errors. Running in the foreground makes no difference.

I think the last build that I had working was the one before v2024.1101, but I can't remember what it was, and the tag is gone now. The issue may have been introduced in the last two builds.

soerenkampschroer commented 4 days ago

It doesn't look like an issue regarding Local Network permissions, because with that the client was able to see the server but not connect and there was an error in the logs. Must be something else.

cathyjf commented 4 days ago

If running in the foreground makes no difference, it theoretically shouldn't be related to the local network permission, but as I said, my own tests establish that that permission is buggy, so who knows.

cathyjf commented 4 days ago

It doesn't look like an issue regarding Local Network permissions, because with that the client was able to see the server but not connect and there was an error in the logs. Must be something else.

This is not necessarily conclusive because only some local network operations actually require the permission. For example, incoming TCP connections supposedly do not require it.

One thing I'm concerned about is that your fix to invoke codesign manually might not work correctly if a previous binary at the same inode was signed in the past. Homebrew's codesigning has a workaround for that issue, but of course we're not using it here. On arm64, code that is not correctly signed won't run at all, and although that's not the case on Intel, who knows what unusual issues it might cause.

Everything is still working fine for me on my arm64 mac machine on the latest commit (03253fc114bf9b1f1375cee9e2dab7c5c7b8c917).

soerenkampschroer commented 4 days ago

@cathyjf I misread your previous post thinking you are now having trouble connecting, but I see now it's actually the opposite. Maybe it's just an issue on my end, I'll look into it.

The same inode should only be a problem if you reinstall the same version though, wouldn't it? The path changes with every version. And reinstalling hasn't led to any more problems for me. But the manual signing should only be a stopgap until it's properly signed like you said or brew updates it's signing logic.

The permission is (or was?) buggy for sure. Before I opened this issue, I saw a lot of complaints about this in multiple different places. Not being able to add or remove anything manually certainly doesn't help. Some of the issues appear to have been resolved in previous beta builds (like in one of the threads you posted in the separate discussion), so it's a bit difficult to get a sense of what the current state of it is.

Can I ask you something unrelated to this issue: When you disconnect your client from your macOS sunshine server, does sunshine spike to 100% CPU usage on your machine? It's not entirely crashing as I can just stop the service and start it again, but once I've disconnected the client it stays at 100% usage and I can't connect again until I restart the server.

soerenkampschroer commented 4 days ago

It's working now, it was the client on my tablet that was causing the connection issue.

00Dchapellebot commented 4 days ago

@cathyjf Hey, I tried running sunshine beta as a foreground process....NOt sure if it makes a difference moving a process to the foreground vs Starting a process in the foreground in shell... I'm not familiar with homebrew: So What is the command to start sunshine-beta this way/ in foreground? My Wiiu client is still not connecting after 'moving' the process to foreground .....

As far as narrowing down why my wiiU client which formally worked on Mac Sonoma three days ago and then stopped working after the upgrade to Sequoia...I am at a complete loss. Everything worked...I was running Hogwarts Legacy through Gameporting toolkit ...On Mac Sonoma ...streaming through Sunshine-beta ... playing on WiiU tv ... Then I wanted to take advantage of GPTK2 beta with support for ray tracing and other things....This works with the New OS Sequoia.... So I did those upgrades, everything runs fine ... Hogwarts looks great.... OS Sequoia, GPTK2....and now WiiU client cannot reach my sunshine-beta.... with error " Can't connect to server "

Moonlight on my iPhone 6s works/ And connects ....to sunshine beta on my sequoia...without issue .... So Maybe it's NOT the local networks permissions, except that my WiiUclient worked and connected perfectly up until the OS upgrade...

(because my client never reaches the server... I no longer get a prompt to PAIR the client device?)

In terms of trying to get the re-prompt for local network permissions on Mac Sequoia, And initializing a beta update, I've tried :

brew uninstall sunshine-beta : this returns " Error: No such keg: /usr/local/Cellar/sunshine-beta. "

brew reinstall sunshine-beta : Returns the proper current tag v2024.1101.204249, then terminal runs cmake and it builds .... but when I launch sunshine it still tells me I still have my old version : Version v2024.911.215654 ??

(so why didn't it build the version it identified?)

brew upgrade sunshine-beta : returns .......Error: lizardbyte/homebrew/sunshine-beta not installed

brew update ...runs and lets me know " Already up-to-date." ...?

Thanks again, for the advice, really appreciate it!

soerenkampschroer commented 4 days ago

@00Dchapellebot sounds like you had an older non-beta version of sunshine installed before upgrading. Try running: brew uninstall sunshine and brew uninstall sunshine-beta and then run brew update and brew upgrade.

Now do brew install sunshine-beta and start it in the foreground (by typing sunshine not sunshine-beta in the terminal). Note that on my machine if using it as a service, I have to start and stop it twice for it to ask for all relevant permissions.

If your iPhone can connect to your old sunshine install, this likely won't fix your problem with the WiiU. If your sunshine install has the problem mentioned in this issue then it will not be able to connect at all, regardless of the client.