stutters every so often on macOS #159

kujohn · 2019-01-06T07:38:16Z

Describe the bug
Stream is perfect but every so often, maybe around 5-10min, video/audio stutters for few seconds. The controls still work during this time, but stutters and skips until it's over. Then it's flawless streaming until the next stutter.

Moonlight settings (please complete the following information)
I have tested with all variant of settings, changing Video bitrates from 20 ~ 150, v-sync, frame pacing, etc.. Occasional stutter still remains.

Client PC details (please complete the following information)

OS: Mac OS X 10.14.2
Moonlight Version: v0.8.0

Server PC details (please complete the following information)

OS: Windows 10 1803
GeForce Experience version: 3.16.0.140
Nvidia GPU driver: 417.35

Moonlight Logs (please attach)
Moonlight-1546797780.log

cgutman · 2019-01-06T19:52:59Z

I've also seen this periodically on my MacBook, but it doesn't happen on either of my other two non-Mac computers streaming over the same WiFi network. Mine is the Early 2016 MacBook. What model is yours?

My guess is that it's something macOS is doing in the background that's eating up either CPU or network resources. Moonlight doesn't do any periodic work while streaming like that, so I can't imagine what it could be inside Moonlight. I'm going to try to catch the stutter in the Instruments profiler and see what's going on with the system at the time.

kujohn · 2019-01-06T20:14:44Z

Thanks, I did some testing before your post. I had run the stream and concurrently ping against the host computer and surprisingly the ping did not loose packet at all during the stutter.

369 packets transmitted, 369 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.522/8.366/140.319/12.945 ms

This just reconfirms that it might be a macOS thing and not network inefficiency. Thanks!

kujohn · 2019-01-06T20:18:37Z

My model is MacBook Pro (Retina, 15-inch, Late 2013

cgutman · 2019-01-06T20:22:15Z

I wouldn't totally trust the ping results. Ping is sending/receiving about 1 packet per second, while Moonlight (depending on how much is happening on screen) can be receiving 1,000 packets per second or more. If the network was only dropping a fraction of the total packets, the odds that one of the dropped packets would be your ping packet in all of that traffic is very low.

kujohn · 2019-01-06T20:30:08Z

Ah, good insight. 👍

cgutman · 2019-01-06T23:55:31Z

I captured a trace of it in Instruments System Profiler and found some interesting stuff:

Timestamp	Narrative	
00:05.286.573	Called "recvfrom(fd:45, buf:0x3ab2200, len:1.37 KiB, flags:0x0,...) = 0 Bytes" for 100.39 ms, end-of-file was encountered.
00:05.286.583	Blocked for 100.30 ms (99.9% of recvfrom's duration) starting at priority 47.  Thread is waiting for event/lock with id 0xa33ba8a859006e9f.	__recvfrom ← (6 other frames)	
00:05.386.880	The thread was made runnable by a timer expiration (handled by CPU 0's timer interrupt handler).  It waited for an available CPU for 66.54 µs (0.1% of recvfrom's duration) before running again at a priority of 47.
00:05.386.947	Ran for 51.42 µs on CPU 0 at priority 47
00:05.386.976	Called "recvfrom(fd:45, buf:0x3ab2200, len:1.37 KiB, flags:0x0,...) = 323 Bytes" for 52.55 ms
00:05.386.998	Blocked for 52.51 ms (99.9% of recvfrom's duration) starting at priority 47.  Thread is waiting for event/lock with id 0xa33ba8a859006e9f.

So it really appears that recvfrom() is blocking for over 100 ms without receiving a packet. The Moonlight receive thread is not being preempted during that time or anything, since it's able to run and call recvfrom() again when the first call times out.

This confirms the issue is not our fault and lies with the network or OS network stack.

kujohn · 2019-01-07T00:44:29Z

Wow interesting. I wonder if other real-time streaming platforms (PS4 remote play) would have the same problem or if there is a workaround.

kujohn · 2019-01-07T01:55:37Z

Just want to report some of the things I've tried to resolve the issue that didn't work:

reset NVRAM
disable spotlight indexing (adding disk to privacy)
disable most settings in 'energy saver'
removing 'mediaanalysisd' daemon from startup source

euroclydon37 · 2019-01-07T15:40:21Z

This whole thread is very insightful. And I've had the same issue for what it's worth. But, it's also worth noting that I get this issue on iOS as well. Both on my 2016 iPad Pro and iPhone 6s Plus.

kujohn · 2019-01-08T06:11:28Z

During the stutter, there is still interim packets of video/audio that was received. So it seems like recvfrom isn't entirely blocked..

If @euroclydon37 has problems on iOS too, does it mean the mac version and ios version utilize the same framework?

cgutman · 2019-01-08T09:15:48Z

In the trace I recorded, I saw recvfrom() take over 150 ms to return a single packet at one point. This is consistent with the stutter observed, because we are getting a bunch of data dropped and the rest delayed significantly.

I'm highly suspicious of jumping to conclusions that iOS may be affected. Moonlight iOS and PC have totally different codebases and I haven't personally seen iOS affected myself.

We need to remember that 99.9% of the time these issues really are transient network problems that have nothing to do with Moonlight. It takes pretty extraordinary evidence to prove that it's not the network's fault when we can prove that packets are being delayed or dropped before reaching the client. I'm not even totally convinced this isn't what I'm seeing on my own network.

Very short network congestion conditions arise all the time, especially on WiFi with multiple clients and shared airspace, and real-time remote gameplay is about as intolerant of application to an imperfect network as you can find. In many ways, you are really seeing and hearing your network's performance. When packets are delayed, you see the video run in slow motion. When packets get dropped, you hear the audio crackle as it runs out of audio to play and see the video freeze until the congestion passes.

kujohn · 2019-01-08T23:46:04Z

So it looks like the packet drop from the recvfrom blockage has something to do with the network layer for OS X, right? I was just wondering if OSX and iOS share the same network layer framework, thus creating similar issues. It's possible that the internal implementation is different though. Sorry, pure speculation on my part since I don't know moonlight codebase.🥉

However, I am going to test it out further on the same machine:

PS4 remote play
Windows 10 bootcamp

I'll report back the findings later this week.

kujohn · 2019-01-09T04:41:28Z

Did some snooping around with packet capture on the server and client, found that during the hiccup, the packets were unable to reach port:

src             dest
192.168.1.20	192.168.1.100	ICMP	70	Destination unreachable (Port unreachable)

And server tries to initiate a new TLS handshake:

src             dest
192.168.1.100	192.168.1.20	TLSv1.2	916	Server Hello, Certificate, Certificate Request, Server Hello Done
192.168.1.20	192.168.1.100	TLSv1.2	1363	Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
192.168.1.100	192.168.1.20	TLSv1.2	105	Change Cipher Spec, Encrypted Handshake Message

cgutman · 2019-01-09T05:08:55Z

@kujohn do you have the full packet capture of those packets (including port numbers and the original packet that the ICMP message was referring to)?

There should be no HTTP/HTTPS activity from Moonlight after the stream is established until the session ends.

kujohn · 2019-01-09T05:41:35Z

Is this what you're looking for?

Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
    Checksum: 0x47fe [correct]
    [Checksum Status: Good]
    Unused: 00000000
    Internet Protocol Version 4, Src: 192.168.1.100, Dst: 192.168.1.20
        0100 .... = Version: 4
        .... 0101 = Header Length: 20 bytes (5)
        Differentiated Services Field: 0xe0 (DSCP: CS7, ECN: Not-ECT)
            1110 00.. = Differentiated Services Codepoint: Class Selector 7 (56)
            .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
        Total Length: 1436
        Identification: 0x3bb1 (15281)
        Flags: 0x0000
            0... .... .... .... = Reserved bit: Not set
            .0.. .... .... .... = Don't fragment: Not set
            ..0. .... .... .... = More fragments: Not set
            ...0 0000 0000 0000 = Fragment offset: 0
        Time to live: 128
        Protocol: UDP (17)
        Header checksum: 0x74f7 [validation disabled]
        [Header checksum status: Unverified]
        Source: 192.168.1.100
        Destination: 192.168.1.20
    User Datagram Protocol, Src Port: 47998, Dst Port: 62455
        Source Port: 47998
        Destination Port: 62455
        Length: 1416
        [Checksum: [missing]]
        [Checksum Status: Not present]
        [Stream index: 4]

cgutman · 2019-01-09T06:25:59Z

Without the full context of the packet capture, I can't tell whether that packet is expected or not. When Moonlight is disconnecting, we can expect to sometimes see a port unreachable message from the client to the server since the client has closed its socket but the server doesn't know yet.

I'm also curious about those TLS packets you mentioned and what ports those were on?

Can you send me a link to the full pcap file at cameron@moonlight-stream.org?

starchaser01 · 2019-01-09T12:14:01Z

Please try disabling location services. It might interrupt your stream when it scans for nearby wifi networks.

System Preferences -> Security & Privacy -> Location Services

kujohn · 2019-01-10T05:32:19Z

@starchaser01 🏆 🎖 👏 👏

That was it. I haven't had any issue since turning off. I will test further!

kujohn · 2019-01-13T21:02:28Z

No issues at all. The location services caused the hiccups for me. Thanks all!

mattbell87 · 2019-08-22T00:44:55Z

This had been driving me crazy for a couple of months since using a Mac until I found this issue. It only affects WiFi.

@cgutman it would be awesome if there was a small message that appears on macOS that notified you about this problem (like first time you start Moonlight), I can open another issue if you'd like.

eaferrari24 · 2019-10-14T19:02:03Z

I think there is now a new variant of this issue... I know it sounds insane, but is it possible for the iPhone 11 to interfere with the connection when using Moonlight on MacOS? Every time I wake up an iPhone 11 in proximity to my laptop, regardless on if it is on the WiFi network/bluetooth, Moonlight stutters for 10+ seconds afterwards. This time, disabling location services results in no improvement. Can somebody else replicate this setup?

Host Computer: Windows 10 custom built w/ ethernet
Streaming Device: MacBook Pro 2015, macOS Catalina, AC Wifi
Phone: iPhone 11 Pro Max

Is it possible the new U1 / wideband chip triggers some weird signal interferes with moonlight? This issue did not exist with the iPhone XS. Likewise, this issue does not affect Steam In Home Streaming. How does this make any sense?

jannislehmann · 2019-12-18T09:54:24Z

I have the same issue as @eaferrari24
Host Computer: Windows 10 w/ ethernet
Streaming Device: MBP 2019, Catalina, Ethernet
Phone: iPhone X

This also occurs, when my Apple Watch screen turns on.
Maybe we should open a new issue.

dsedivec · 2019-12-24T05:07:42Z

I think there is now a new variant of this issue... I know it sounds insane, but is it possible for the iPhone 11 to interfere with the connection when using Moonlight on MacOS? [...]

I think I used to have this, and I suspect it was due to Continuity/Handoff/etc. Maybe try disabling Handoff? I'm not sure if this is just in System Preferences or elsewhere. Maybe also check that you have AirDrop turned off.

Also, I'm guessing this doesn't happen if you use wired ethernet and turn off the wifi?

My vague recollection is that Continuity/Handoff works via Apple Wireless Direct Link (AWDL), which technically involves the wifi radio switching between channels rapidly. Perhaps see also https://stackoverflow.com/a/51786787 for further details.

eaferrari24 · 2019-12-24T05:56:40Z

@dsedivec
Thank you for the insight and sharing the link. I’ll try disabling Handoff/AirDrop but having those features enabled has never been a Moonlight problem for me on past MacOS/iOS/iPhones. Likewise, this mystery doesn’t affect Steam in-home streaming.

The other reason I don’t think it is handoff related is because other iPhone 11’s not affiliated with my Apple ID trigger this jitter/packet loss on my moonlight game stream when in proximity to my laptop.

Honestly, I haven’t really followed up on this in a while. I mostly just keep my iPhone on the other side of the house or off when playing games and rely on MacOS to notify me of iMessage/FaceTime/Calls.

The post above you by @Cludch suggests it also happens when connected via Ethernet. The iPhone X doesn’t have the U1 chip, so I’m stumped. Perhaps it is yet another variant of this problem. I’ve personally never had the iPhone X/XS trigger this jitter/packet loss just from waking the screen.

My memory is vague but I recall replicating this issue in airplane mode... which makes me think the U1 chip doesn’t obeys the iOS airplane mode setting. Apple did recently confirm that the currently released versions of iOS continue to broadcast the U1 even if location services are disabled.

Considering this doesn’t affect moonlight streaming onto the Apple TV or iPhone 11 and Steam in-home streaming works fine in all settings, I don’t think it’s the shield protocol or a macOS networking driver/interface issue. It has to be something with the macOS implementation of moonlight. Isn’t Steam’s in-home streaming open source? Maybe they communicate with the networking hardware in a different way? I’m out of ideas.

dsedivec · 2019-12-25T00:49:44Z

@dsedivec
[...] Likewise, this mystery doesn’t affect Steam in-home streaming.

If that's the case, I would like to shift my suspicion to Qt. Quick story: I used to use a VoIP client written in Qt, and I would experience a huge ping spikes during calls on a regular basis. It turns out, Qt makes macOS rescan wireless networks periodically, which has the same effect as having location services on. I don't think this is related to your problem, since yours happens only when you wake up your phone, but I think it demonstrates that Qt can do some surprising things to the system.

Still, I doubt Qt on macOS has anything to do specifically with iPhones, so it would have to be something like "Qt causes a delay when a new BT/wifi device appears, which only happens when the iPhone wakes up". Something like that.

I assume you're on wifi and not wired ethernet. If so, maybe you could enable wifi logging (https://apple.stackexchange.com/a/348574) and see if you can spot any hints as to what happens when you wake your iPhone?

The other reason I don’t think it is handoff related is because other iPhone 11’s not affiliated with my Apple ID trigger this jitter/packet loss on my moonlight game stream when in proximity to my laptop.

That is weird. iPhone is not connected via USB? Is the phone paired to your computer with Bluetooth at all?

Honestly, I haven’t really followed up on this in a while. I mostly just keep my iPhone on the other side of the house or off when playing games and rely on MacOS to notify me of iMessage/FaceTime/Calls.

Understood. I just happened upon this issue after finding that I, too, needed to disable location services for a smooth experience (and sometimes quit/restart Firefox afterwards). Feel free to ignore my comments, thought I'd throw some ideas out. I just found it terribly disappointing (and, if you'll permit me, kind of funny) that you have to put your phone in another room to play games.

The post above you by @Cludch suggests it also happens when connected via Ethernet. The iPhone X doesn’t have the U1 chip, so I’m stumped. Perhaps it is yet another variant of this problem. I’ve personally never had the iPhone X/XS trigger this hitter/packet loss just from waking the screen.

My memory is vague but I recall replicating this issue in airplane mode... which makes me think the U1 chip doesn’t obeys the iOS airplane mode setting. Apple did recently confirm that the currently released versions of iOS continue to broadcast the U1 even if location services are disabled.

Since AFAIK no MacBooks have U1 chips, the only way I can think of the U1 chip playing a role here is if you're getting your network through wifi and the UWB signals are interfering with wifi. If that's the case, and it's not just a defect in your particular phone, I suspect the FCC (or your national equivalent) and Apple would very much like to hear about this!

Does your iPhone leave Bluetooth on in airplane mode? I noticed mine does, presumably since newer iPhones need BT for the headphone jack.

At some point in troubleshooting this I would have to start wondering if there is a defect with your specific iPhone and it's giving off RF interference.

[...] It has to be something with the macOS implementation of moonlight. Isn’t Steam’s in-home streaming open source? Maybe they communicate with the networking hardware in a different way? I’m out of ideas.

I don't know if it's open source, but I wouldn't be surprised if moonlight-qt is using Qt's networking facilities, whereas Steam in-home streaming is not using Qt for networking (if it's using Qt at all).

eaferrari24 · 2019-12-25T18:03:27Z

Still, I doubt Qt on macOS has anything to do specifically with iPhones, so it would have to be something like "Qt causes a delay when a new BT/wifi device appears, which only happens when the iPhone wakes up". Something like that.

I think you and I are in sync on our suspicions with QT.

At this point, I've seen this happen from multiple iPhone 11's so I really don't think its a defective phone. Likewise, since it doesn't affect Steam In Home Streaming I don't think it is appropriate yet to get Apple or the FCC involved. Yes, one iPhone has never been connected to my MacBook in any way, wired or wireless, and causes the issue. My airplane mode does leave bluetooth on, but I also manually toggled everything off.

This variant of the issue REALLY messes up the connection compared to the original location services packet loss this issue was opened for. I'll try to get some wifi logging info in the next few weeks.

Valves Open Source GitHub with a fair amount of their projects: https://github.com/ValveSoftware

Since the issue was re-opened, maybe someone will have a similar configuration that they can replicate! Thank you @dsedivec & @cgutman

Below is all speculation, but has anybody done any investigation into the UWB frequency range? Maybe it isn't too far off from 5ghz and is an independent chip purely for efficiency reasons. This may be why the newest 16 inch MacBook released a month ago doesn't have a dedicated chip.

EDIT: https://www.techinsights.com/blog/apple-u1-delayering-chip-and-its-possibilities

gykpro · 2024-02-14T02:14:07Z

Definitely seems to be Mac specific. Seeing same issues on Vision Pro and the iPad. However, Parsec and Steam streaming do not have the same issues. Also, streaming wirelessly to GeforceNow for 4k 60fps does not have the constant stuttering and frame issues as Moonlight does.

I have an M1 Max MBP. In my case, moonlight sometimes performs ok but most times not, Steam streaming and Geforce Now the same: sometimes OK sometimes not. Interestingly, every time I restart the Mac, they performs OK. And it's also the same situation when streaming from PS5.

My other devices in the same wireless environment: android phone, steam deck, PC, they works perfectly streaming from sunshine, PS5 and Steam.

NapalmDest54 · 2024-02-17T13:01:33Z

I ended up buying a cheap WifI 6 Asus router. Put the router into AP mode and changed the 5ghz channel to 149. I connect my apple devices to that, works great now. I still keep the Eero mesh system with this setup.

GrimalDev · 2024-03-22T23:48:26Z

Switching my wifi channel to 44 seemed to fix the issue. I updated to Sonoma 14.1 to 14.1.1 on the same day so I cant say for sure which of these solved the issue. Switching Handoff/Bluetooth/Location Service didnt solve the issue, so I left them on.

Im also on 14.1.1 and I still have the issue even after switching off Bluetooth/Location Services. Haven't played around with Wi-Fi channels yet.

EDIT: Im in EU so no channel 149 for me. Channel 44 did not fix the issue.

Hi, using custom network setup here 🙋‍♂️. What channel should I set the my 5GHz wifi to?
PS: I'm in the EU too.

rramnel · 2024-03-23T09:42:33Z

I am in the EU and I use Channel 44 which fixed the issue for me. Also make sure that your router is not near many electrical appliances as this was also an issue for me. I had to find the "right" location within my apartment to reduce Network Jitter

GrimalDev · 2024-03-23T09:55:34Z

I am in the EU and I use Channel 44 which fixed the issue for me. Also make sure that your router is not near many electrical appliances as this was also an issue for me. I had to find the "right" location within my apartment to reduce Network Jitter

Thank you for triggering some
research on my side, if anyone comes accros this, here is a good article that explains a little of possible interferences:

https://help.keenetic.com/hc/en-us/articles/213968709-What-affects-Wi-Fi-networks-The-possible-sources-of-interference

tymscar · 2024-05-17T21:31:51Z

Honestly, I always had this issue and my fix has always been turning the interface for awdl0 down. That was not ideal as I genuinely find it useful to be there.

Now, I changed my 5Ghz channel from 40 to 44 and its perfect!

DrPsychick · 2024-05-17T22:57:09Z

I just did a short test with macOS Sonoma. Disabled the cron and kept awdl0 UP while I was pinging my Windows host and playing... no lags whatsoever, even when trying to use AirDrop with my Phone.

I don't know if the workaround is still needed, I will keep the cron disabled and an eye out for lags.

PS: my Wifi was also using 5G Channel 44 at that time.

GrimalDev · 2024-05-18T11:04:52Z

I just did a short test with macOS Sonoma. Disabled the cron and kept awdl0 UP while I was pinging my Windows host and playing... no lags whatsoever, even when trying to use AirDrop with my Phone.

I don't know if the workaround is still needed, I will keep the cron disabled and an eye out for lags.

PS: my Wifi was also using 5G Channel 44 at that time.

This would mean that the best current solution is switching to channel 44 on 5Ghz

tymscar · 2024-05-18T21:36:19Z

Yes, this is also on Sonoma 14.4.1. No cron, no awdl0 disabled, no nothing. As long as wifi is 5Ghz on channel 44, it works great!

marcosscriven · 2024-05-19T20:36:15Z

I'm just popping in to say that turning off Location Services on my new iPad Pro M4 fixed this stuttering as well.

toxox · 2024-06-05T03:57:46Z

On top of everything mentioned in this thread, what ended up fixing the stutters on M2 MPB for me was setting both the host's output display and the mac's display refresh rates to 60hz. For the mac side, the setting is in Settings -> Displays, and by default it was set to "ProMotion" instead of 60hz.

I'm also running the latest currently available dev build from here, not sure if that matters.

GrimalDev · 2024-06-05T09:09:18Z

Yes, this is also on Sonoma 14.4.1. No cron, no awdl0 disabled, no nothing. As long as wifi is 5Ghz on channel 44, it works great!

confirming that after some time of using moonlight without any cron to disable the interfaces, everything is perfect. Except for the sound stutters sometime (have tried reducing de bitrate, etc and have a perfect connection) It seems to be coming in waves which sounds a lot like a network scan from macos that would impact every now and then. but it gets a hole lot better since the channel change. Now that I think about it it seems I haven't have the problem since a while now... It feels very weird that all this stuff was caused by a channel overlap...

tranbaohuu · 2024-06-06T07:21:58Z

I have fixed exactly this issue with the solution is

Caused by:

terminal run: ifconfig you will see the name is: awdl0.

Terminal to inactive this:

sudo ifconfig awdl0 down

or

sudo ifconfig awdl0 up (to re-enable)

Software to auto disable when login:

Conclusion:

I've been using this app for over 3 months then the lagging issue not happened to me. Hope this solution will help you all.

GrimalDev · 2024-06-06T11:37:44Z

I have fixed exactly this issue with the solution is

Caused by:

terminal run: ifconfig you will see the name is: awdl0.
Terminal to inactive this:
sudo ifconfig awdl0 down

or

sudo ifconfig awdl0 up (to re-enable)

Software to auto disable when login:
Conclusion:
I've been using this app for over 3 months then the lagging issue not happened to me. Hope this solution will help you all.

What you are referring too has already been responded with the crontab solution. Which is an out of the box solution compared to installing yet another app.

cordelac · 2024-08-06T06:11:30Z

Just put Moonlight for the first time on my M3 Macbook Pro and been struggling with this, tried everything suggested, and it only went away when I turned off Bluetooth. Unacceptable given I need it for the controller (not to mention keyboard / trackpad), will have to check if other streaming solutions work better.

Really disappointing because everything worked perfectly fine a year ago on my M1 Air.

tranbaohuu · 2024-08-06T07:46:22Z

Just put Moonlight for the first time on my M3 Macbook Pro and been struggling with this, tried everything suggested, and it only went away when I turned off Bluetooth. Unacceptable given I need it for the controller (not to mention keyboard / trackpad), will have to check if other streaming solutions work better.

Really disappointing because everything worked perfectly fine a year ago on my M1 Air.

did you disable "Game Mode" the controller symbol on the taskbar (we have the feature since MacOS Sonoma)?

GrimalDev · 2024-08-06T07:53:47Z

Just put Moonlight for the first time on my M3 Macbook Pro and been struggling with this, tried everything suggested, and it only went away when I turned off Bluetooth. Unacceptable given I need it for the controller (not to mention keyboard / trackpad), will have to check if other streaming solutions work better.

Really disappointing because everything worked perfectly fine a year ago on my M1 Air.

did you disable "Game Mode" the controller symbol on the taskbar (we have the feature since MacOS Sonoma)?

But didn't Moonlight stop activations gamemode on launch?

tranbaohuu · 2024-08-06T08:00:37Z

Just put Moonlight for the first time on my M3 Macbook Pro and been struggling with this, tried everything suggested, and it only went away when I turned off Bluetooth. Unacceptable given I need it for the controller (not to mention keyboard / trackpad), will have to check if other streaming solutions work better.

Really disappointing because everything worked perfectly fine a year ago on my M1 Air.

did you disable "Game Mode" the controller symbol on the taskbar (we have the feature since MacOS Sonoma)?

But didn't Moonlight stop activations gamemode on launch?

See it, I've confused to the previous version on Moonlight that was activated the Game Mode.

cordelac · 2024-08-07T02:51:05Z

did you disable "Game Mode" the controller symbol on the taskbar (we have the feature since MacOS Sonoma)?

I was using the latest version of Moonlight, so it doesn't activate. I did try an older version (5.x) just to see if Game Mode might even help, no luck though.

tranbaohuu · 2024-08-07T03:01:09Z

did you disable "Game Mode" the controller symbol on the taskbar (we have the feature since MacOS Sonoma)?

I was using the latest version of Moonlight, so it doesn't activate. I did try an older version (5.x) just to see if Game Mode might even help, no luck though.

Do you use Sunshine or Nvidia Experience (self-host)?
After you turn off the "awdl0", on Terminal keep watching it by using the command "ifconfig" to see if is it auto re-enable. Because I see it has the agility to re-enable.

ds-sebastian · 2024-08-22T15:20:01Z

I'm having similar issues on my M3 Macbook Air (Sonoma 14.6.1). I'm trying to stream the native resolution of my macbook.

I tried the following steps:

Installing & running WiFriedX
Disabling Universal Control
Disabling Bluetooth
Setting AirDrop to "No One"
Turning off AirPlay related settings
Never used Game Mode (latest version with updated metal renderer)
Crontab solution
Sunshine (tried both stable and beta)
1GB Ethernet connection (seems to work fine then as long I disable everything above including WiFi)

I'd prefer not to change my network channel that's managed by UniFi if possible?

However, based on what @tranbaohuu said, I do notice that even when running sudo ifconfig awdl0 down there exists IPv6 address for awdl0 that will not go away, even with sudo route delete

I just can't get rid of `awdl0 ....

GrimalDev · 2024-08-22T17:07:42Z

I'm having similar issues on my M3 Macbook Air (Sonoma 14.6.1). I'm trying to stream the native resolution of my macbook.

I tried the following steps:

Installing & running WiFriedX

Disabling Universal Control

Disabling Bluetooth

Setting AirDrop to "No One"

Turning off AirPlay related settings

Never used Game Mode (latest version with updated metal renderer)

Crontab solution

Sunshine (tried both stable and beta)

1GB Ethernet connection (seems to work fine then as long I disable everything above including WiFi)

I'd prefer not to change my network channel that's managed by UniFi if possible?

However, based on what @tranbaohuu said, I do notice that even when running sudo ifconfig awdl0 down there exists IPv6 address for awdl0 that will not go away, even with sudo route delete

I just can't get rid of `awdl0 ....

You should really try the channel switch. Let us know if you see improvements!

ds-sebastian · 2024-08-22T21:18:37Z

You should really try the channel switch. Let us know if you see improvements!

Thanks! I figured it was worth trying lol, so I changed my Channel Width to 20Mhz and Channel 149 & Channel 6 for all WiFi APs. Seems slightly better, but the issue persists.

I also lowered the Moonlight FPS to 30 FPS, and used the automatically chosen bitrate for 27Mbps. My WiFi speeds are around 180Mbps Up/Down, yet I still get random periods of stuttering, about once every few minutes, for about 5-10 seconds.

It runs flawlessly with no stuttering even up to 90Mbps except for random periods where it tells me to lower the bitrate. It seems to happen even at a 2 Mbps bitrate or even using Steam Link

GrimalDev · 2024-08-22T21:45:16Z

You should really try the channel switch. Let us know if you see improvements!

Thanks! I figured it was worth trying lol, so I changed my Channel Width to 20Mhz and Channel 149 & Channel 6 for all WiFi APs. Seems slightly better, but the issue persists.

I also lowered the Moonlight FPS to 30 FPS, and used the automatically chosen bitrate for 27Mbps. My WiFi speeds are around 180Mbps Up/Down, yet I still get random periods of stuttering, about once every few minutes, for about 5-10 seconds.

It runs flawlessly with no stuttering even up to 90Mbps except for random periods where it tells me to lower the bitrate. It seems to happen even at a 2 Mbps bitrate or even using Steam Link

I really don't have this anymore after (I use to have it a lot) switching to sunshine, channel, location activated, AirDrop arctivated, Bluetooth on, cron fix.
I play with my wife on to différent streams in the same natwork. So I really don't think I would have a bandwidth issue.

I'm on an m1 no stutter and apple tv

DrPsychick · 2024-09-18T22:19:17Z

Damn... for quite a long while I had zero issues with moonlight/sunshine. Today, the issues is back, even with Wifi channel 44 and the cron (disabling awdl0) enabled. Disabling the cron/enabling awdl0 did not change anything, neither did disabling AirDrop in the menu. The only thing I did today was rebooting the Mac, not sure how that is related.

If found an llw0 interface, but disabling it did not solve the issue.

Every ~10 seconds, I get high pings to a host on the local network and stuttering in Moonlight.

64 bytes from 192.168.1.60: icmp_seq=197 ttl=128 time=2.728 ms
64 bytes from 192.168.1.60: icmp_seq=198 ttl=128 time=2.620 ms
64 bytes from 192.168.1.60: icmp_seq=199 ttl=128 time=38.570 ms
64 bytes from 192.168.1.60: icmp_seq=200 ttl=128 time=106.182 ms
64 bytes from 192.168.1.60: icmp_seq=201 ttl=128 time=149.785 ms
64 bytes from 192.168.1.60: icmp_seq=202 ttl=128 time=2.461 ms
64 bytes from 192.168.1.60: icmp_seq=203 ttl=128 time=2.005 ms

PS: I get these ping results also when not using Moonlight at all, so it must be a general network/wifi issue.

Update: I rebooted the Wifi AP, tried disabling things on Mac - nothing helped. I then restarted my Mac and now everything is back to normal 🤷‍♂️

gzeronone · 2024-10-11T14:57:57Z

The fix is to temporarily disable a couple of Airdrop/Handdrop interfaces running a simple bash script, and re-activate with ctrl + c: https://www.reddit.com/r/MoonlightStreaming/comments/1dkz628/comment/l9lepvt/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

hoonlight · 2024-10-24T04:04:25Z

Important: After completing all settings, completely shut down and restart your device. It's not enough to just change the settings, in most cases it seems that restarting the device is necessary for the relevant settings to take full effect. I can't believe it took me years to figure this out!

Along with all the tips above, this almost completely solved my problem - I now have no stuttering on moonlight at all.

cgutman changed the title ~~stutters every so often~~ stutters every so often on macOS Jan 6, 2019

cgutman closed this as completed Jan 27, 2019

cgutman mentioned this issue Feb 6, 2019

Video artifacts, audio glitch #172

Closed

cgutman reopened this Dec 25, 2019

marcosscriven mentioned this issue May 19, 2024

Sound and video stutter on iPad Pro M4 moonlight-stream/moonlight-ios#627

Open

cgutman mentioned this issue Jun 8, 2024

Choppy audio on loss of focus after v6.0 MACOS #1303

Open

Murmur2k mentioned this issue Sep 4, 2024

Native CoreAudio renderer with spatial audio #1399

Open

stutters every so often on macOS #159

stutters every so often on macOS #159

Comments

kujohn commented Jan 6, 2019 • edited Loading

cgutman commented Jan 6, 2019

kujohn commented Jan 6, 2019

kujohn commented Jan 6, 2019

cgutman commented Jan 6, 2019

kujohn commented Jan 6, 2019

cgutman commented Jan 6, 2019

kujohn commented Jan 7, 2019

kujohn commented Jan 7, 2019 • edited Loading

euroclydon37 commented Jan 7, 2019 • edited Loading

kujohn commented Jan 8, 2019 • edited Loading

cgutman commented Jan 8, 2019

kujohn commented Jan 8, 2019

kujohn commented Jan 9, 2019

cgutman commented Jan 9, 2019

kujohn commented Jan 9, 2019

cgutman commented Jan 9, 2019

starchaser01 commented Jan 9, 2019 • edited Loading

kujohn commented Jan 10, 2019

kujohn commented Jan 13, 2019

mattbell87 commented Aug 22, 2019

eaferrari24 commented Oct 14, 2019 • edited Loading

jannislehmann commented Dec 18, 2019 • edited Loading

dsedivec commented Dec 24, 2019

eaferrari24 commented Dec 24, 2019 • edited Loading

dsedivec commented Dec 25, 2019

eaferrari24 commented Dec 25, 2019 • edited Loading

gykpro commented Feb 14, 2024

NapalmDest54 commented Feb 17, 2024

GrimalDev commented Mar 22, 2024

rramnel commented Mar 23, 2024

GrimalDev commented Mar 23, 2024

tymscar commented May 17, 2024

DrPsychick commented May 17, 2024 • edited Loading

GrimalDev commented May 18, 2024 • edited Loading

tymscar commented May 18, 2024

marcosscriven commented May 19, 2024

toxox commented Jun 5, 2024

GrimalDev commented Jun 5, 2024

tranbaohuu commented Jun 6, 2024 • edited Loading

GrimalDev commented Jun 6, 2024

cordelac commented Aug 6, 2024

tranbaohuu commented Aug 6, 2024

GrimalDev commented Aug 6, 2024

tranbaohuu commented Aug 6, 2024

cordelac commented Aug 7, 2024

tranbaohuu commented Aug 7, 2024 • edited Loading

ds-sebastian commented Aug 22, 2024 • edited Loading

GrimalDev commented Aug 22, 2024

ds-sebastian commented Aug 22, 2024

GrimalDev commented Aug 22, 2024

DrPsychick commented Sep 18, 2024 • edited Loading

gzeronone commented Oct 11, 2024

hoonlight commented Oct 24, 2024 • edited Loading

kujohn commented Jan 6, 2019 •

edited

Loading

kujohn commented Jan 7, 2019 •

edited

Loading

euroclydon37 commented Jan 7, 2019 •

edited

Loading

kujohn commented Jan 8, 2019 •

edited

Loading

starchaser01 commented Jan 9, 2019 •

edited

Loading

eaferrari24 commented Oct 14, 2019 •

edited

Loading

jannislehmann commented Dec 18, 2019 •

edited

Loading

eaferrari24 commented Dec 24, 2019 •

edited

Loading

eaferrari24 commented Dec 25, 2019 •

edited

Loading

DrPsychick commented May 17, 2024 •

edited

Loading

GrimalDev commented May 18, 2024 •

edited

Loading

tranbaohuu commented Jun 6, 2024 •

edited

Loading

tranbaohuu commented Aug 7, 2024 •

edited

Loading

ds-sebastian commented Aug 22, 2024 •

edited

Loading

DrPsychick commented Sep 18, 2024 •

edited

Loading

hoonlight commented Oct 24, 2024 •

edited

Loading