moonlight-stream / moonlight-embedded

Gamestream client for embedded systems
https://github.com/moonlight-stream/moonlight-embedded/wiki
GNU General Public License v3.0
1.5k stars 325 forks source link

Network dropped an entire frame; Unrecoverable frame 1 #656

Open DerKapi opened 6 years ago

DerKapi commented 6 years ago

Please provide the following info.

NVidia Geforce Experience version: 3.13.1.30 @GTX1080Ti DriveerVersion 391.35 Moonlight Embedded version: I guess the newest but i dont know how to check this :S Moonlight Embedded running on: Raspberry Pi 3B Moonlight Embedded running on distribution: Raspbian Jessie

Verbose output -verbose of Moonlight Embedded: moonlight stream -720 -fps 30 OR moonlight stream -1080 -fps 60 has the same result.... OR moonlight stream Searching for server... Connect to 192.168.178.25... Initializing platform...done Resolving host name...done Starting RTSP handshake...done Initializing control stream...done Initializing video stream...done Initializing audio stream...done Initializing input stream...done Starting control stream...done Starting video stream...done Starting audio stream...done Starting input stream...done Error: cannot keep up Unrecoverable frame 1: 15+1=16 received < 30 needed Unrecoverable frame 2: 2+0=2 received < 20 needed Unrecoverable frame 3: 2+1=3 received < 19 needed Unrecoverable frame 4: 13+1=14 received < 20 needed Unrecoverable frame 5: 14+1=15 received < 21 needed Unrecoverable frame 6: 14+1=15 received < 21 needed Unrecoverable frame 7: 14+1=15 received < 21 needed Unrecoverable frame 8: 14+1=15 received < 21 needed Unrecoverable frame 9: 14+1=15 received < 21 needed Unrecoverable frame 10: 14+1=15 received < 21 needed Unrecoverable frame 11: 14+1=15 received < 21 needed Unrecoverable frame 12: 14+1=15 received < 21 needed Unrecoverable frame 13: 14+0=14 received < 20 needed Unrecoverable frame 14: 14+1=15 received < 21 needed Unrecoverable frame 15: 14+1=15 received < 20 needed Unrecoverable frame 16: 14+1=15 received < 20 needed Unrecoverable frame 17: 14+1=15 received < 18 needed Network dropped an entire frame Waiting for IDR frame IDR frame request sent Waiting for IDR frame Waiting for IDR frame Waiting for IDR frame

[.................................................................]

Network dropped an entire frame Waiting for IDR frame IDR frame request sent Waiting for IDR frame Waiting for IDR frame Unrecoverable frame 404: 14+1=15 received < 21 needed Unrecoverable frame 405: 14+1=15 received < 19 needed Unrecoverable frame 406: 14+0=14 received < 15 needed Network dropped an entire frame Waiting for IDR frame IDR frame request sent Waiting for IDR frame Control stream received disconnect event Input: sendInputPacketOnControlStream() failed: -1 Stopping input stream...done Stopping audio stream...ENet wait interrupted Control stream connection failed Loss Stats: Transaction failed: 11 done Stopping video stream...done Stopping control stream...done Cleaning up input stream...done Cleaning up audio stream...done Cleaning up video stream...done Cleaning up control stream...done Cleaning up platform...done

What is the expected result? -Steam Starts in big-picture mode -It streams input to host and recives video output and able to stream What happens instead of that? -Steam Stats in big picture mode on HostPC (correct) -Input (Gamepad, Keyboard) is streamed from Raspi to Host (correct) -One or two Pictures are revieved from Host-PC then the picture ist freezed -Audio Output works

HostPC and Raspi are connected via Ethernet to a Fritz!Box 7560 Issue is very simular to #512 , but i dont know how he solved it, so i can't try it by myself.... "Could you try to reduce the network speed of the windows machine to 100mbit to check if it solves your issue?"

Thank you for your help!

welly321 commented 6 years ago

I had this same problem and it was fixed by rebooting my router. I did notice that when this problem occured, I could not ping my raspberry pi by hostname from my PC. ping retropie would return host not found ping 192.168.xxx.xxx would work After rebooting my router, i could once again ping by hostname and stream without errors. Could this somehow be a DNS or internal network issue?

excelsi0r commented 5 years ago

I just had this issue and I think I found some information regarding this. First some information about my Network architecture. My Windows Host is connected to a manageable switch, from that switch, connects a Router/AP, Tp-link Archer C2, and from that Router/AP, connects my client (RPi, raspbian). Everything is wired over gigabit. What happens is that my Router/AP is dropping packets sent/received by host or client. This happens only over gigabit Ethernet. I tried the solution #512 in which i changed the connection from my Host to the switch to fast Ethernet (100mbit)(I am able to change since it is a manageable switch) and it worked!. But of course, this is not ideal, I want my gigabit Ethernet at all times. So, I isolated the problem being my Router/AP, I tried to change QoS settings, IGMP and IPTV settings without success. The Router/AP keeps dropping those frames. But then it occurred me. I decided to replace the router with another gigabit switch, and it also worked! So, having a "direct" connection over switches only works nicely. Since I needed that Router/AP as well, I just needed to connect it to that same second switch in order to have Wireless. I believe there is some sort of protocol or configuration that I might be able to change on the Router/AP for it to make it work. I just need some time to dig into the moonlight-embedded architecture and communication protocols to understand why are these Routers so eager to block that traffic.

chgitgor commented 4 years ago

I am having this same issue with a RPI 3B+ and realized that connecting it to a managed switch was causing this. The Host PC is also connected to this managed switch. I had a dumb switch laying around so I just connected it in between the managed switch and the RPI, and it solved my problem. I don't see this issue on my RPI4. I still need to figure out what's going on with the managed switches.

EDIT: Hope the fix I found below helps somebody with this same problem. I followed the recommendation out there of limiting the RPI 3B+ to 100 full duplex and the issue is not present, no ideal in my opinion. So playing a little bit more regarding issues with ethernet on this RPI model, looks like my dumb switch has something called Flow Control enabled by default and can't be turned off since it's unmanaged, this was effectively helping the host computer know that they were sending packets too quickly for the RPI to handle. Then, in the managed switch I enabled symmetrical flow control ONLY on the port that the RPI is connected to, without limiting the speed to 100 full duplex. The issue is gone this way! And I don't need the dumb switch anymore sandwiched in between the managed switch and the rpi.

insanemal commented 2 years ago

Still having this issue. I'm on an RPI4, using dumb switches. Restricting network to 100Mbit doesn't help.

Doesn't make sense. This is the only app that has this issue. Steam streaming doesn't work well with vulkan under linux but Moonlight+Sunlight does. All my x86 machines work fine. And weirdly the PI works over WiFi, just not as well as wired would.

It should be all smooth sailing from my desktop to the Rpi, network wise. I've got one switch in one room with the pc on that and then a cable running through the walls to the other room going into my routers switch then up to the rpi via wall cables.

This needs looking at as it's quite weird.

clarkemw commented 1 year ago

Enabling flow control on my switch also fixed this issue for me. Very strange but at least it works.

jackhric commented 1 year ago

Using QT, posted in wrong area. However, issue is still present in Moonlight itself it seems like

Getting this issue at the moment, very frustrating. Running a managed Cisco Catalyst 2960-S for my switch. Speed of interface, flow control (on or off) both did nothing. Looking into disabling QoS for testing.

Got a weird problem though, on my Windows client connected to the same switch + same cable, I have no issues whatsoever. Windows builds seem to be smooth as butter, all the way up to 105Mbps (compared to the Linux's 45Mbps). Could this potentially be a Linux-specific issue with dropped frames?

This is what I get in the QT logs: image

And the display is frozen for the most part, except for a couple times where some packets (I'm assuming) go thru.

insanemal commented 1 year ago

Just to add some info, I have no problems getting streams working at over 100Mbit from Linux to an RPi now. The issue was one of configuration on the RPi.

Alan502 commented 1 year ago

I'm running into this issue too now on the flatpak version of moonlight.