When the console doesn't provide enough information to solve a problem alone, the next step is to check the network panel to ensure that the video stream is reachable and valid.
Before we check all of the requests though, we must counter the modern web's tendency towards spamming hundreds of requests. And this is where filters become handy.
Most of the time, a simple filter will work. If you are looking for HLS manifests, filter by "m3u8." If you are looking for DASH manifests, filter by "mpd." If you want to see segments, figure out what container format you're looking for and filter by that (often .ts and .mp4/.m4f).
Make sure the video stream is reachable
If you see any relevant manifest or media requests that have failed (highlighted red, or with a 400 or 500 range HTTP status code, then it's possible the stream is not reachable, and that is the source of the issue.
For instance, from the previous example, where the console shows a MEDIA_ERR_SRC_NOT_SUPPORTED error, the network tab revealed the following:
Be careful making the assumption that a failed request is the cause of failed playback. It's possible that only one rendition failed, and other renditions are fine. Often though, failed requests will come with a log in the console from the video player (unless us video player devs forgot to put one there...).
Make sure the video stream is valid
If the manifest(s) and media files are reachable, then it's good to perform some high level manifest validity checks.
There's a lot to cover on this subject, so check out the stream issues section for a list of checks.
Using the network panel for reproducing an issue
When a problem only occurs in low bandwidth environments and your dev computer is hardwired to a gigabit connection, throttle your connection through the network tab.
For all those times when the cache is making things faster, but also not providing updated responses.