Casting any media from a PC to the RPi, other than on a Ethernet connection, results in a large number of errors, and an eventual crash. Streams are very responsive, and smooth at 720p at 30fps, but drops frames and lags sporadically, until that crash (~15min).
I’m unsure, but are the wireless routers are too slow? The 1 gigabit cable runs perfectly.
Otherwise, I’m not sure what I’m doing wrong, as I’ve spent hours on this and Moonlight seems unusable in terms of reliability. Other applications have latency times of up to 10 seconds (e.g. uv4l, OBS, VLC).
I’ve searched for each error, but find little information - any help (fixes or software / hardware alternatives) would be appreciated.
If I resolve this, I’ll come back and post the solution.
Objective: Wireless live cast of VR headset output to Moonlight.
Problem: While smooth and responsive for the most part (latency <50ms), Moonlight drops frames, and eventually crashes. How long it takes to crash appears to be dependent on both the intensity of applications run, and the connection medium between the PC and the RPi. Running a game (e.g. Fallout 4), will result in a crash in about 15 minutes.
Moonlight Configuration: moonlight stream -720 -fps 30 -app Steam x.x.x.x
- VR Headset: Samsung HMD Odyssey
- PCs: Asus ROG G751JT / Dell Inspiron 15 Gaming 7577
- Microprocessor: Raspberry Pi 2 Model B
- RPi Wi-Fi Dongle: EDUP (802.11N)
- Networking: Technicolor TG587 / Samsung Galaxy Note 4 / Direct Cat 5e RJ45
Attempted Troubleshoots: All configurations of the Asus or the Dell, through the TG587 or Note 4 or Cat 5e, to the RPi, to multiple HDMI-compliant screens.
Error Details: Direct Cat 5e Ethernet connection yields perfect results (aside from one crash when starting up Windows Mixed Reality; worked fine once running). However, any combination using the TG587 or Note 4 produces the following errors:
- “Returning RTP packet after queue overgrowth” / “Returning RTP packet queued for too long” followed by “Received OOS audio data (expected ####, but got ####)” - occurs dozens of times;
- “Waiting for IDR frame” - occurs hundreds of times;
- “IDR frame request sent” - occurs a few dozen times;
- “Network dropped an entire frame” - occurs about a dozen times;
- “Unrecoverable frame ###: ## + ## = ## received < ## needed” - occurs a few dozen times; and
- “Request IDR frame: Transaction failed: 11” / “Loss Stats: Transaction failed: 11” - occurs once right before crashing.
Possible Cause: Transfer rate of router / Wi-Fi dongle is too low to handle smooth, responsive and reliable casts?