Trouble with Moonlight streaming to LG webOS : worked 6 months but now connection unstable & black screen

[rems1989]

Moonlight Version

1.6.36

Device Type

webOS TV

Device Model

LG C4

Device OS

webOS 10.2.2

Host OS

Windows

Host Software

Sunshine

Host Setup

Windows 11
NVIDIA GPU RTX 3070
i7-10600kf
2x16gb

Bug Description

I’m running into a very inconsistent issue when streaming my Windows 11 PC with apollo (fork of Sunshine) to my LG C4 TV using Moonlight (webOS). The setup worked perfectly for about 6 months at 2K / 90 FPS with high bitrate.

Around 2–3 weeks ago, the issue started without any clear change on the PC side (possibly after a webOS update). Moonlight on the TV shows “connection unstable” with a black screen

Behavior is inconsistent and unpredictable : sometimes nothing works at all with black screen, sometimes 2K / high bitrate work or not, yesterday 2K didn't work but lowest resolution (1280x..) worked
Streaming to my phone seems to work fine, so the host PC and network seem OK

What I’ve tried:

• Clean reinstall of Moonlight on the TV and Apollo/Sunshine on the PC
• H.264 only (no HEVC, no AV1, HDR off for testing)
• All bitrate / FPS / resolution combinations
• Ethernet and Wi-Fi
• Different Windows display modes
• Virtual display disabled

Reproduction Steps

No response

Expected Behavior

No response

[chnithinkrish111]

Yeah, observed the same, stream is exiting after few mins of gameplay with error msg: connection error. Restarting the moonlight application fixed the issue for few min and games are not playable because of this.

[Rainowy]

Hi everyone,

I've had an 83" LG C5 for about two months now, and right from the start, I was struggling with a black screen issue when streaming from my host PC (running Sunshine) to the Moonlight app on the TV.

After digging into the issue, I found a workaround: changing the "Speed & Duplex" setting on the host PC's Intel network card (i225-V) to 100 Mbps Full Duplex. This helped the NIC communicate properly with Moonlight, and the stream finally showed up.

To improve my network setup, my next step was buying a Gigabit USB Ethernet adapter (Cabble Matters) and plugging it into the TV to bypass LG's slow built-in network card. Speed tests in the TV's browser jumped to around 300 Mbps, but surprisingly, this didn't fix the black screen bug. If I set the host's Intel NIC back to "Auto Negotiation", the black screen returned. I was forced to keep my PC bottlenecked at 100 Mbps.

I finally managed to properly solve the problem by enabling Flow Control on my TP-Link switch. Specifically, I enabled it on the exact port that connects the switch to the Gigabit USB adapter on the LG TV.

Thanks to this single change, I was able to revert my host PC's Intel NIC back to Auto Negotiation. I'm now successfully streaming 4K HDR at 120Hz with the Moonlight bitrate set to 95 Mbps, and it runs flawlessly.

Hope this helps someone dealing with the same headache!

Cheers

[fasdasfsa534332]

@Rainowy This solution works for me.

My setup:

• LG C1 (webOS 03.53.45)
• Moonlight TV 1.6.36
• Sunshine
• AMD RX 6700 XT
• Realtek 2.5GbE LAN
• Wired Ethernet connection through a Vodafone Docsis 3.1 router

Symptoms:

• Stream starts normally.
• After a few seconds, Moonlight reports "unstable connection".
• Network frame drops jump to very high values.
• Decoder latency becomes "Not Available".
• Stream freezes or turns black.
• Sunshine logs show no encoder or capture errors.
• Steam Link works perfectly on the same hardware and network.

What significantly improved the situation for me was changing the Ethernet link negotiation settings on the host PC. I forced it to

In the Realtek adapter properties, forcing the Speed & Duplex setting to 100 Mbit/s instead of relying on Auto Negotiation changed the behavior and fixed the issue.
It might be useful to investigate whether Moonlight webOS is sensitive to link negotiation, flow control, or specific Ethernet driver behavior on Realtek 2.5GbE adapters.

@mariotaku please mark this as a solution or update the readme. I spend good week to find and confirm it works.

cc. @rems1989

[mariotaku]

Disclaimer: This writeup was drafted by an AI assistant working from network captures, kernel counters, and ethtool output. The reproduction was done on equivalent — but not identical — hardware: a Raspberry Pi 5 as the gigabit sender, an NEC Aterm home router as the switch, and a Steam Link as the 100 Mbps receiver. None of this is an LG TV. The mechanism described (asymmetric 802.3x pause negotiation + switch egress buffer overflow on 1G → 100M speed mismatch) applies to any host/switch/NIC combination with that pause-capability shape, including the LG TV setups reported in this thread. The matching workarounds reported by @Rainowy, @fasdasfsa534332 and others on real LG hardware corroborate the model.

Reproducing this in the lab pinned the failure to a specific Ethernet-layer mechanism. The two workarounds in this thread (force the host to 100 Mbps, or enable 802.3x flow control on the switch port facing the TV) both work for the same underlying reason, and which one applies depends on what gear is in the path.

The mechanism

When a streaming host sends a video frame, it pushes a burst of UDP packets onto the wire as fast as its NIC will go. An IDR keyframe is typically 4–10× larger than a P-frame: at moonlight's common bitrates that means a 1080p60 H.264 IDR at 40 Mbps is roughly 330 KB – 830 KB, and a 4K60 HEVC IDR at 80 Mbps is roughly 670 KB – 1.7 MB. At gigabit line rate that's a 3–15 ms volley. The receiver's link is 100 Mbps, so the switch port facing the TV (or USB Ethernet adapter, or whatever the LG side terminates on) drains at 1/10 the rate the burst arrives. The switch buffers the difference.

Consumer router/switch chips have small per-port egress buffers — in our reproduction, around 100 KB. Whatever doesn't fit gets dropped silently.

The Ethernet-layer mitigation for this is 802.3x flow control / pause frames: the switch tells the sender "stop, my queue is full" before it overflows. But pause negotiation has both Symmetric and Asymmetric variants, and during link autoneg the result is one of:

• Both ends Symmetric → switch can pause sender, sender honors it → no drops
• Sender advertises Transmit-only, switch Symmetric → sender can pause the switch but the switch cannot pause the sender — the wrong direction for our problem
• Either end "no pause" → no flow control at all

Many cheap or low-end NICs (and their drivers) advertise Transmit-only — sometimes hard-coded in the driver with no software way to change it. When that's what's at the end of the cable, the switch buffers the IDR burst, overflows, and silently drops 80–90% of the packets. The decoder receives a destroyed keyframe, can't decode, requests a new one, and the next IDR gets shredded the same way. That's the "unstable connection" / black-screen spiral.

Lab reproduction

• Sender: Raspberry Pi 5, gigabit eth0 (Cadence macb driver). Supported pause frame use: Transmit-only — hard-coded; ethtool -A eth0 rx on returns "Operation not supported".
• Switch: NEC Aterm home router's internal LAN switch, Link partner advertised pause frame use: Symmetric.
• Receiver: Steam Link, 100 Mbps NIC. Wire counters read directly from /sys/class/net/eth0/statistics/.

Three experiments isolate the failure mode:

1. Sustained UDP at moonlight bitrates — clean, not the problem

Smooth-paced iperf3 UDP at typical moonlight bitrates, 10 seconds per rate, into the same 100 Mbps Steam Link:

Target	Delivered packets	Drops
10 Mbps	8,988	0
30 Mbps	26,849	6
50 Mbps	44,702	0
60 Mbps	53,627	0
90 Mbps	80,432	14

Zero meaningful loss, including right at the wire ceiling. Bandwidth itself is not the problem.

2. Burst sizes from 10 KB to 90 KB at gigabit line rate — also clean

Same receiver, but now sending bursts at NIC line rate (≈958 Mbps from a tight sendto loop) with 16.7 ms idle gaps between bursts. 30 bursts per size.

Every burst size from 10 KB to 90 KB delivered 100% intact (peak per-burst loss 0.00%). The switch's egress buffer to the 100 Mbps port comfortably absorbs anything under ~100 KB.

3. Burst sizes shaped like real moonlight IDRs — catastrophic loss

Converting each bitrate setting to a typical 60-fps IDR burst (avg frame × 7 — middle of the 4–10× IDR-to-P range for game content), gigabit sender, default Pi NIC autoneg, no flow control honored:

Moonlight bitrate	Per-IDR burst	Peak loss per IDR
10 Mbps	142 KB	34%
20 Mbps	285 KB	67%
30 Mbps	427 KB	78%
35 Mbps	498 KB	81%
40 Mbps	569 KB	80%
50 Mbps	712 KB	79%
60 Mbps	854 KB	83%
90 Mbps	1.28 MB	84%

The asymptote sits around 89%, which is exactly the 10× speed ratio: once the switch's egress buffer saturates, the steady-state drop ratio matches the ratio of arrival rate to drain rate.

4. Force the sender to 100 Mbps — total fix

Same burst test, but with ethtool -s eth0 speed 100 duplex full autoneg off on the sender:

Burst	Peak loss per burst
128 KB	0.00%
512 KB	0.00%
1 MB	0.00%
5 MB	0.00%
10 MB	0.00%

Zero drops at any size. The 10 MB burst takes ~860 ms on the wire instead of ~80 ms — and the receiver still gets every packet. The sender's NIC TX queue absorbs the burst at the same rate the switch can drain it, so the speed mismatch (and therefore the switch buffer overflow) disappears.

Why this is not a moonlight-tv bug

This is happening at the Ethernet layer, before any packet reaches moonlight or the decoder. The TV's NIC driver advertised the wrong pause capability at link autoneg time; moonlight has no way to influence that. No software change in moonlight-tv can recover packets that the switch already dropped.

It also matches why the symptoms only appeared "after a webOS update" for some reporters: a driver update can change the advertised pause capability, and a TV that previously did Symmetric pause and got the switch's backpressure may now do Transmit-only and not.

What about lowering the bitrate?

A common first instinct is "I'll just lower the bitrate." It doesn't work. The lowest realistic moonlight setting in our test (10 Mbps) still produces 142 KB IDRs that lose ~34% of their packets every time, deterministically. The decoder asks for another, the next IDR is also 142 KB, also loses ~34%, repeat. Lowering bitrate only delays the spiral; it doesn't break it.

Working mitigations (any one of these will fix it)

The fix is to make sure flow control works somewhere in the path, in the direction switch-to-host. In order of preference:

1. Enable 802.3x flow control on the switch port that faces the TV. This is what @Rainowy did with the TP-Link, and it's the cleanest fix because it preserves gigabit throughput on the host side. Requires a managed switch (TP-Link Easy Smart, Mikrotik, Netgear ProSafe, Zyxel, etc.). On many consumer routers flow control is disabled by default in firmware and not exposed in the UI — in that case go to (2).

2. Force the host PC's NIC to 100 Mbps full duplex. Removes the speed mismatch entirely so there's nothing for the switch to drop. Confirmed working by @fasdasfsa534332, @Rainowy and others in this thread. Downside: caps total host bandwidth at 100 Mbps, so bitrates above ~80 Mbps will be unstable for the opposite reason (genuinely insufficient bandwidth).

3. Plug both host and TV into the same managed switch directly, then either (1) above, or set both ports to the same speed.

4. Use a different NIC on the TV side. A USB Ethernet adapter with a chip whose driver advertises Symmetric pause (verifiable with ethtool -a on a Linux box first) will let the switch backpressure it. Note that @Rainowy's USB adapter alone didn't fix it — it took switch flow control too. The combination of "switch sends pause" + "host honors pause" must hold somewhere in the path.

Diagnosing your own setup

Plug your host PC into the same network and run (Linux): ethtool -a <iface>. You want:

RX:    on
TX:    on

…and Advertised pause frame use: Symmetric on both your end and Link partner. If either end says Transmit-only or No, flow control won't apply backpressure to the sender on overload.

If ethtool -A <iface> rx on tx on fails with "Operation not supported", the driver has hard-coded the pause advertisement and you cannot fix this from the host side — go to switch flow control (path 1), or force the speed (path 2).

---

A pinned issue / FAQ entry seems worthwhile here: this isn't a moonlight-tv bug but it's going to keep coming back from anyone running an LG webOS TV through a typical consumer switch.