You can access the Parsec console for diagnostics on the Parsec stream at any time. Once you click on the console, you'll see this dialogue box. It can reveal some interesting information about the quality of your streaming experience.
"I've been asked for my console log, how do I do that?"
You might be asked to share the logs via tickets or the Discord server for troubleshooting.
The logs needed are usually the ones from whoever is hosting (unless asked otherwise). While the client is connected, put in a video or a game that is visually active for a few minutes to generate some useful logs. To share it:
- Copy the host's log using copy to clipboard
- Put it in pastebin with Ctrl+V
- Set it to unlisted and hit Create New Paste
- Copy the URL from your browser and share it with whoever asked (preferably in private messages if you're in the Discord server)
What these lines mean;
FPS is somewhat self explanatory, but it's the current frames per second that Parsec is sending. Parsec does not send frames when the screen isn't changing. This helps us save bandwidth.
You should see the FPS value go up to about your display's refresh rate, or your encoder_fps advanced setting if you've set that. You can test this by going into a game with a free camera and moving it around quickly.
If it doesn't reach the FPS you're expecting, then encoder_fps may need to be set, or there may be a bug which you can let us know about on our Discord.
L measures encoding latency in the last 100 frames. The first number is the average encoding latency. The second number is the maximum encoding latency. My encoding latency is pretty great on the computer I'm using since it's an Nvidia host.
Bear in mind, this is not a measure of stream latency, but of how long it takes the GPU to encode your stream. When a lot is happening on-screen, Nvidia usually sits around 5ms, Intel around 11ms, and AMD around 15ms. Take note that the maximum frametime for 60FPS is 16.67ms (1000ms / 60), and anything too close to or higher than this will mean that the stream can't reach 60FPS, potentially causing stuttering and other issues.
If you do have a high encoder latency, reducing your screen resolution can lower it, or switching to a 30FPS stream can reduce the 'requirement' (1000ms / 30 = 33.33ms) for a smooth stream.
Likewise, if you want to stream above 60FPS, ensure that your encoder latency is low enough to manage it smoothly. Divide 1000 by your encoder latency, and you will then have the highest encoder_fps value you can realistically set. In the case of the average Nvidia system being 5ms latency, that means that same Nvidia system can manage 200FPS streaming. Just bear in mind that higher FPS streams are useless if the host's display can't render all the frames (200FPS is useless on a 60Hz display).
B measures your bitrate. The first number is your current bitrate and the second number is your maximum bitrate. The maximum adjusts based on how much congestion we see in the network. You may have set the maximum to 10 Mbps, but if there's a lot of network congestion, we'll lower it to save bandwidth. Here, you can see it's dropping a bit due to the bad connection.
Keep in mind that your maximum bitrate is set by your Bandwidth Limit hosting setting, or encoder_bitrate in Parsec's configuration file. This value determines the quality of the stream, but also the internet requirements. In the case of hosts, this will be limited by upload, and download for clients. You should do an internet speed-test on both ends to ensure that you don't set this too high for either end, if able.
N measures your network stats. The first number is how many slow retransmits have occurred during the stream. The second number is the number of fast retransmits. The third number is the number of congestion events. You want all of these numbers to be as close to 0 as possible. The slow retransmits and congestion events indicate serious connection issues. As with bitrate, you can see here that my connection isn't particularly great.
If you see your retransmits rising and want to resolve the issue, you should ensure that both ends of the connection are reliably connected to the internet. This means connecting with ethernet on both ends where possible. Additionally, find the models of each of the routers on either end and look them up on wikidevi , if either router has an Intel Puma chip in it, then you should look to replace it, as these chips do not handle intensive network tasks very well and often cause severe stream issues.
These are commands sent from the UI to the daemon. Most of the time these aren't really necessary to pay attention to unless someone asks.
Certain lines in the log like SRV.encoder, CLI.decoder, and exit_code can potentially be important and useful in getting support. SRV.encoder and CLI.decoder tell you what the host (SRV) and client (CLI) are using to encode and decode the stream.
In the case of the stream log above, this was SRV.encoder = Nvidia, while the client's log showed CLI.decoder = Intel. When you have a stream disconnecting without an error code, you may see that code in the console log as exit_code = (code).