fix(watch): show persistent error for unavailable and removed videos

[aditya0155]

Pull Request Type

• Bugfix

Related issue

closes #8472

Description

Opening a removed/unavailable video currently shows a blank watch page with a error that disappears after a few seconds. The existing error overlay (used for members-only, age-restricted, DRM videos) never triggers because the catch blocks do not set errorMessage variable for unavailable videos.

I have made changes so that unavailable/removed video errors now set errorMessage, so the error stays visible inside the player instead of only appearing as a temporary toast.

Since unavailable videos may not have a usable thumbnail, the player area can shrink and hide the error. To avoid that, I added YouTube's official unavailable video fallback thumbnails:

• https://www.youtube.com/img/desktop/unavailable/unavailable_video.png for light themes
• https://www.youtube.com/img/desktop/unavailable/unavailable_video_dark_theme.png for dark themes

The thumbnail is chosen by checking the actual page background color with calculateColorLuminance, so it should keep working with current and future themes.

It also skips falling back to Invidious when the Local API error contains unavailable, since unavailable videos will fail there too.

Finally, I removed the redundant API error toast when the same message is already shown persistently in the player. The toast is now only shown when FreeTube is actually falling back to the other backend.

While testing the review feedback, I also found that the stale thumbnail/title issue existed before this PR. When FreeTube is playing a normal video and then switches to an unavailable video, the unavailable video request fails, but some data from the previous video, like thumbnail, videoTitle, channelName, and channelThumbnail, can still be kept around.

Before this PR, that was easier to miss because FreeTube mostly stayed visually on the previous video and showed a temporary unavailable-video toast. After this PR, the issue became more obvious because the unavailable message stays inside the player, so it could appear on top of the previous video’s thumbnail/title.

The fix is to clear the previous video’s state when the watch route changes, before loading the next video. Then, if the new video is unavailable, FreeTube shows the unavailable fallback thumbnail and persistent error instead of accidentally reusing details from the last normal video.

Screenshots

Before:

the error of video unavailable stays for only few seconds so if you're not actively looking for it, then you likely won't see it before it disappears.

After:

Testing On Multiple Themes

Testing.On.Multiple.Themes.mp4

Testing On Normal Video

Testing.On.Normal.Video.mp4

---

Before this PR during watch route change to unavailable video

Before.The.Pr.mp4

After this PR during watch route change to unavailable video

Fixed.Root.Cause.mp4

Testing

1. Open https://www.youtube.com/watch?v=Y0Aqc174FMM
2. Check that the "Video unavailable" error is shown inside the player and does not disappear.
3. Check that there is no duplicate API error toast when the player already shows the same error.
4. Open a normal video and check that it still plays.
5. Open other unplayable videos, like members-only or age-restricted videos, and check that their existing player error behavior still works.
6. Also retest the feature with different themes.

Desktop

• OS: Windows
• OS Version: 11
• FreeTube version: 0.24.0

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Hi @aditya0155 sorry for the delayed review. I had a random thought on this. What about using

https://www.youtube.com/img/desktop/unavailable/unavailable_video.png for light themes and https://www.youtube.com/img/desktop/unavailable/unavailable_video_dark_theme.png for dark themes

[aditya0155]

@efb4f5ff-1298-471a-8973-3d47447115dc hey I have tried to implement the required changes feel free to check whenever you get time.

I proposed 2 ways of solving this issue

1st :

1st commit tests:

Test.On.Many.Theme.mp4

Test.On.Normal.Video.mp4

although there is 1 problem

const LIGHT_BASE_THEMES = new Set([
'light',
'pastelPink',
'catppuccinLatte',
'solarizedLight',
'gruvboxLight',
'everforestLightHard',
'everforestLightMedium',
'everforestLightLow'
`])

LIGHT_BASE_THEMES is fragile because future light themes would need to be added here too but this is the most minimal edit and fixing the root problem is trickier because the app does not currently have a shared way to ask whether the active theme is light or dark.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[aditya0155]

final commit (fixing the root issue: recommended):

Instead of maintaining a hardcoded list of light themes, it now reads the page's actual background color at render time and uses the existing calculateColorLuminance helper to decide light vs dark.

also I extended calculateColorLuminance to handle rgb()/rgba() strings (not just hex like previously) since getComputedStyle returns those formats. This way, new themes automatically get the correct thumbnail without anyone needing to update the previous LIGHT_BASE_THEMES list.

Testing videos:

Testing On Multiple Themes

Testing.On.Multiple.Themes.mp4

Testing On Normal Video

Testing.On.Normal.Video.mp4

[efb4f5ff-1298-471a-8973-3d47447115dc]

Looked at #5922 briefly and it looks like the toast can be removed as the message in the player is the same.

Please also update the details in the PR body :)

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[efb4f5ff-1298-471a-8973-3d47447115dc]

LGTM! Thank you for implementing this :)

[PikachuEXE]

Is it expected/desired to show last normal video thumbnail/title when switching from viewing normal video to unavailable video?

[efb4f5ff-1298-471a-8973-3d47447115dc]

Doenst seem desired

[aditya0155]

I think the root cause existed even before this PR. When FreeTube is playing a normal video and then switches to an unavailable video, the unavailable video request fails, but some watch page state (thumbnail, videoTitle, channelName, channelThumbnail etc etc) from the previous video is still kept around.

Before this PR, this was easier to miss because FreeTube would mostly just stay on the previous video visually and show a temporary “video unavailable” toast although some times the button next to search bar doesn't work previously which was a bit frustrating (you can see from the video). After this PR, the issue is more obvious because the unavailable message stays inside the player, so it ends up being shown over the previous video’s thumbnail/title.

Before.The.Pr.mp4

I have implemented a fix is to clear the previous video’s state data when the watch route changes, "before" loading the next video. Then, if the new video is unavailable, FreeTube can show the unavailable fallback thumbnail and error instead of accidentally reusing details from the last normal video.

Fixed.Root.Cause.mp4

Also, I have updated the PR body

[efb4f5ff-1298-471a-8973-3d47447115dc]

@aditya0155 Thank you for addressing this! Hope to see more from you in the future :)