Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stutters every so often on macOS #159

Open
kujohn opened this issue Jan 6, 2019 · 133 comments
Open

stutters every so often on macOS #159

kujohn opened this issue Jan 6, 2019 · 133 comments

Comments

@kujohn
Copy link

kujohn commented Jan 6, 2019

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
Copy link
Member

cgutman commented Jan 6, 2019

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.

@cgutman cgutman changed the title stutters every so often stutters every so often on macOS Jan 6, 2019
@kujohn
Copy link
Author

kujohn commented Jan 6, 2019

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
Copy link
Author

kujohn commented Jan 6, 2019

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

@cgutman
Copy link
Member

cgutman commented Jan 6, 2019

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
Copy link
Author

kujohn commented Jan 6, 2019

Ah, good insight. 👍

@cgutman
Copy link
Member

cgutman commented Jan 6, 2019

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
Copy link
Author

kujohn commented Jan 7, 2019

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
Copy link
Author

kujohn commented Jan 7, 2019

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
Copy link

euroclydon37 commented Jan 7, 2019

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
Copy link
Author

kujohn commented Jan 8, 2019

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
Copy link
Member

cgutman commented Jan 8, 2019

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
Copy link
Author

kujohn commented Jan 8, 2019

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
Copy link
Author

kujohn commented Jan 9, 2019

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
Copy link
Member

cgutman commented Jan 9, 2019

@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
Copy link
Author

kujohn commented Jan 9, 2019

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
Copy link
Member

cgutman commented Jan 9, 2019

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
Copy link

starchaser01 commented Jan 9, 2019

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

System Preferences -> Security & Privacy -> Location Services

@kujohn
Copy link
Author

kujohn commented Jan 10, 2019

@starchaser01 🏆 🎖 👏 👏

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

@kujohn
Copy link
Author

kujohn commented Jan 13, 2019

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

@mattbell87
Copy link

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
Copy link

eaferrari24 commented Oct 14, 2019

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
Copy link

jannislehmann commented Dec 18, 2019

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
Copy link

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
Copy link

eaferrari24 commented Dec 24, 2019

@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
Copy link

@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).

@cgutman cgutman reopened this Dec 25, 2019
@eaferrari24
Copy link

eaferrari24 commented Dec 25, 2019

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

@oshulaev
Copy link

oshulaev commented Dec 16, 2023

I'm on Sonoma 14.1.2. Turned off airdrop and handoff in settings but no result.
Turning off wifi on iphone helps a little. Disabling my iphone resolves the issue.

upd: changing wifi channel to 44 also fixed the issue.

@zhaomaosu
Copy link

Meet the same issue on my Mac mini (Sonoma 14.2.1). Seems existing my Apple ID resolved this issue.

@NapalmDest54
Copy link

NapalmDest54 commented Feb 13, 2024

I have the Eero 6 Pro (not 6e) and it does seem to be more specific issue to some apps compared to others. I am not able to update the wifi channels on this mesh system.

Some of my test results:

  • M1 MBP Wired - 4k 60FPS, no issues
  • M1 MBP Wireless - 4k 60fps constant issues. 1080p 30fps, constant issues
  • M1 MBP Wireless (awdl off, air drop off, bluetooth off) - 1080p 30 fps constant issues
  • Razer Linux Wireless - 4k 60fps, no issues
  • Even more interestingly is using parsec as a comparison, the M1 MBP on wireless with awdl on, airdrop on, bluetooth on, has no issues with 4k 60fps.

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.

@gykpro
Copy link

gykpro commented Feb 14, 2024

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
Copy link

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
Copy link

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
Copy link

rramnel commented Mar 23, 2024

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
Copy link

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
Copy link

tymscar commented May 17, 2024

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
Copy link

DrPsychick commented May 17, 2024

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
Copy link

GrimalDev commented May 18, 2024

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
Copy link

tymscar commented May 18, 2024

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
Copy link

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

@toxox
Copy link

toxox commented Jun 5, 2024

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
Copy link

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
Copy link

tranbaohuu commented Jun 6, 2024

I have fixed exactly this issue with the solution is

Caused by:

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

image

Terminal to inactive this:

sudo ifconfig awdl0 down

or

sudo ifconfig awdl0 up (to re-enable)

Software to auto disable when login:

image

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
Copy link

I have fixed exactly this issue with the solution is

Caused by:

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

image Terminal to inactive this:

sudo ifconfig awdl0 down

or

sudo ifconfig awdl0 up (to re-enable)

Software to auto disable when login:

image 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
Copy link

cordelac commented Aug 6, 2024

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
Copy link

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
Copy link

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
Copy link

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
Copy link

cordelac commented Aug 7, 2024

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
Copy link

tranbaohuu commented Aug 7, 2024

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.

  1. Do you use Sunshine or Nvidia Experience (self-host)?

  2. 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
Copy link

ds-sebastian commented Aug 22, 2024

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
Copy link

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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests