metrics: track unidentified innertube errors

[Fijxu]

Closes #103 and #151

The second commit will contain fixes and new errors that are not directly related to #103, so if it's possible, don't squash this PR, otherwise, I can create a new PR after this gets merged

[Fijxu]

Note to self:

• Add metrics to count 403 errors returned by the /videoplayback endpoint.
• Add LIVE_STREAM_OFFLINE status to the ignore list.
• Add Premieres in * and This live event will begin in * to the reason ignore list.

[Fijxu]

I'll leave it as a draft for now since I plan to refactor some things and I still need to add some metrics

[Fijxu]

we could track all status codes, but seems overkill to me. I've personally never seen any other http status code more than 403 when the request to /videoplayback fails for any reason

[Fijxu]

We can't track Video unavailable errors because Youtube.JS throws an error when the status is ERROR, which includes reasons like Video unavailable and subreasons like This video is no longer available because the YouTube account associated with this video has been terminated. or subreasons related to videos that have been deleted by copyright claims.

https://github.com/LuanRT/YouTube.js/blob/92b8623374a126d60604a54fa4be67b460ddc5e3/src/core/mixins/MediaInfo.ts#L58-L59:

    if (info.playability_status?.status === 'ERROR')
      throw new InnertubeError('This video is unavailable', info.playability_status);

We would need to catch that error somehow in:

invidious-companion/src/lib/helpers/youtubePlayerHandling.ts

Lines 54 to 58 in f9f89a2

	const video = new YT.VideoInfo(
	[youtubePlayerResponse],
	innertubeClient.actions,
	generateRandomString(16),
	);

Or maybe override the MediaInfo class of https://github.com/LuanRT/YouTube.js/blob/92b8623374a126d60604a54fa4be67b460ddc5e3/src/core/mixins/MediaInfo.ts#L33C1-L33C33 so we can handle the ERROR status ourselves. Maybe there is better way tho.

[Fijxu]

Note to self:

• Add metrics to track [BUG] "No valid URL to decipher" #60

[Fijxu]

Now it should track Video unavailable errors as per #103 and URL deciphering errors. I'll leave it running on my instances of invidious-companion to add more subReasons that can appear on some Video unavailable reason.

[Fijxu]

We should filter the errors by the client used? Because since we switched to MWEB and TV, I got a lot of unknown reaons and subreasons like: This video is private, instead of the one that the WEB client returned which was Private video

For example, WEB returns this on a private video:

{
  "playabilityStatus": {
    "status": "LOGIN_REQUIRED",
    "messages": [
      "This is a private video. Please sign in to verify that you may see it."
    ],
    "errorScreen": {
      "playerErrorMessageRenderer": {
        "subreason": {
          "simpleText": "Sign in if you've been granted access to this video"
        },
        "reason": {
          "simpleText": "Private video" // <- the reason we are catching
        },
        ...

meanwhile MWEB returns:

{
  "playabilityStatus": {
    "status": "LOGIN_REQUIRED",
    "reason": "This video is private", 
    "messages": [
      "This is a private video. Please sign in to verify that you may see it."
    ],
    "errorScreen": {
      "playerErrorMessageRenderer": {
        "subreason": {
          "runs": [
            {
              "text": "If the owner of this video has granted you access, please "
            },
            ...

Meanwhile, I'm going to adapt it so it can search for the reason on every JSON object, without client filtering. In my opinion, having a label or some way to display which client was used to display the unknown error would be better.

[unixfox]

@Fijxu the fallback clients shouldn't be tried if there are no streamingData returned, that's what a private video do. There are no streams URLs returned since it's a private video.

https://github.com/iv-org/invidious-companion/blob/master/src/lib/helpers/youtubePlayerReq.ts#L58-L65

Or maybe my algorithm is wrong. On those cases, only WEB should be tried.

[Fijxu]

the fallback clients shouldn't be tried if there are no streamingData returned

You're right 😅 I did that because I didn't even read 16d06cd at the time you pushed it.

When I was adding those type of errors, I used ClientType.MWEB in Innertube.create on my Invidious companion fork, and then I got that chunk of errors that are valid for MWEB, but didn't used to appear on WEB.

I'll delete those that I added because of MWEB, but some are still valid for the WEB too

[Fijxu]

I consider this ready to merge. It has been working pretty well from my testing. My metrics are public so here is how they look like:

https://metrics.nadeko.net/d/1-0-0/invidious-companion?orgId=2&from=now-7d&to=now&timezone=browser&refresh=5s

[Copilot]

Pull Request Overview

This PR implements metrics tracking for unidentified InnerTube errors to improve monitoring and debugging capabilities. The changes expand error categorization and add tracking for video playback failures and player deciphering errors.

• Enhanced metrics system to support labeled counters for better error categorization
• Added comprehensive error tracking for InnerTube responses including status, reason, and subreason classification
• Implemented tracking for video playback 403 errors and YouTube.js player deciphering failures

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/routes/videoPlaybackProxy.ts	Adds metrics tracking for 403 forbidden responses from YouTube's videoplayback endpoint
src/lib/helpers/youtubePlayerHandling.ts	Implements error tracking for player deciphering failures with try-catch wrapper
src/lib/helpers/metrics.ts	Major refactoring to support labeled metrics and comprehensive InnerTube error categorization
grafana_dashboard.json	Updates dashboard configuration to display new metrics with improved visualization

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}