[Bug]: On pause, videoplayer resets playback progress to zero and player UI buttons become fully unresponsive.

[innersp4ce]

Guidelines

• I have encountered this bug in the latest release of FreeTube.
• I have encountered this bug in the official downloads of FreeTube.
• I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
• I have searched the documentation for information that matches the description of the bug I want to file, without success.
• This issue contains only one bug.

Describe the bug

When playing a video for more than 10 minutes it is possible that the videoplayer resets to 0:00 and the UI of the player becomes unresponsive. Refreshing the page does not work, you need to go to another page within the application. For example the subscriptions page, any page will do. Then reload last video or another video and playback for more than 10 minutes the behavior can happen again.

The behavior happens inconsistent. It happens more often after about 5 to 10 minutes of playback and the freetube window has been out of focus and been untouched for said duration.

1. Start freetube
2. Choose any video to play and start it. It can happen on any video
3. Pause the videoplayer either hitting space when in focus or click within the videoplayer to pause
4. The video stops playback
5. The playback time progress bar is set to 0:00 and shows the thumbnail in the videoplayer.
6. The play button become unresponsive
7. Playback speed button opens context menu but the options cant be clicked
8. Captions button same as point 8 and "auto generated english" option disappears
9. Clicking the cog wheel and change resolution is responsive but makes the cog wheel button disappear and does nothing.
10. Autoplay, loop button, volume slider and mute button are still responsiuve
11. PiP, Full screen, Theater mode buttons stay responsive and do change the videoplayer size as intended design.
12. Clicking within the videoplayer does not start playback
13. Click subscriptions/channels/history (any will do) or just click back and forward.
14. Go either to history to play last video or play a new video, or hit back and forward either via the buttons top left or with thumb mouse buttons that correspond to the same action.

Expected Behavior

When pausing the videoplayer pauses at current time, videoplayer UI stays responsive as inteded design, video playback progress is kept instead of set to 0:00

Issue Labels

feature stopped working

FreeTube Version

aur/freetube 0.23.1-1

Operating System Version

Linux user 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64 GNU/Linux

Installation Method

AUR (Unofficial)

Primary API used

Local API

Last Known Working FreeTube Version (If Any)

No response

Additional Information

Plasma DE, Wayland session.

Issue persists using the portable download from the github releases, release: v0.23.1-beta

Issues persists in the official nightly portable build pulled from this git repo as per instruction in the official documentation. Nightly build: Commit 5e16102

Terminal log: v0.23.1-beta

/usr/bin/xdg-mime: line 885: qtpaths: command not found
/usr/bin/xdg-mime: line 885: qtpaths: command not found
[40781:0210/172904.921163:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!

Terminal log nightly:

/usr/bin/xdg-mime: line 885: qtpaths: command not found
/usr/bin/xdg-mime: line 885: qtpaths: command not found
[38560:0210/165032.953875:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
[38560:0210/165039.007994:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
[38560:0210/165041.353485:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!

Probably irrelevant as these errors occur right away starting the freetube application either the v0.23.1 beta or nightly build. Line 3 through 5 do not happen on the beta but do happen on aur/freetube 0.23.1-1. No issues were experienced despite the errrors.

Issue: #6514
Error described sometimes occurs when quickly hitting back and forward with the thumb mouse buttons to reload the videoplayer. Doing it another time doesn't produce the error. The error is never occurs when starting a new video. I wouldn't have noticed this error if I didn't troubleshoot with different releases with fast switching back and forward to refresh the player rapidly due to getting into a routine habit. This is a symptom and not the subject of this issue.

Nightly Build

• I have encountered this bug in the latest nightly build.

[innersp4ce]

Addendum: I have encountered this issue for the first time in v0.22

[absidue]

FreeTube doesn't log to the terminal, please check the logs in the devtools console CTRL+SHIFT+I for any red messages (you can ignore yellow ones) and take screenshots of them please.

[innersp4ce]

As requested:

No error messages spotted. I set the log level to All to make sure to catch everything just in case.

Additionally i noticed 2 more situations in which the behavior occurs:

1. When the video is paused as design intended and the window is not in focus, after some time the player will set progress to 0:00 with all the OP symptoms.
2. When the window is not in focus and the playback progress bar is clicked, the bar is set to 0:00 with all the OP symptoms.

P.S.: I use a 3 multihead setup, so often the Freetube window is on the secondary or tertiary screen and not in focus. I don't seem to catch this behavior when its on any of the 3 screen and the window is in focus.

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

Hmm could you try updating your graphics drivers

[innersp4ce]

Since Arch is a rolling release, I perform regular full system upgrades more or less weekly.

Current version: mesa 1:24.3.4-1

I noticed this issue somewhere last month.

Below the upgrade data for reference

[2025-01-07T11:22:13+0100] [ALPM] upgraded mesa (1:24.3.2-1 -> 1:24.3.3-1)
[2025-01-14T10:16:38+0100] [ALPM] upgraded mesa (1:24.3.3-1 -> 1:24.3.3-2)
[2025-01-24T13:27:49+0100] [ALPM] upgraded mesa (1:24.3.3-2 -> 1:24.3.4-1)

The mesa repo was updated lastly 23/01/25

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

Hmm could you rollback the drivers a month or two and recheck the if the big persists

[innersp4ce]

It's not as simple as to rollback the mesa driver. I guarantee rolling back that driver will certainly break the graphical system and Arch will get stuck on it while booting. Looking at the dependencies installed on my system wayland is dependent as well, since its the display server protocol it'll be cascade of packages that need to be downgraded.

Can you please share your reasoning for thinking the GPU driver has something to do with it? Couldn't it be something else?

I understand that this issue is weird and I am most likely the only one / one of the few experiencing this issue.

[b2ag]

I'm somewhat afraid to chime in here because one member (I don't like to name) likes to jump to conclusions and bully people. But I want to help a fellow seeking help. To me this sounds a lot like the player is getting unloaded. Try to enter the following into console after the player/video has loaded and see if you still can reproduce the issue.
navigator.mediaSession.setActionHandler("stop", ()=>{console.error("stop")})

[innersp4ce]

Hi b2ag,

Thanks, very much appreciated! And noted, I guess 😄

For clarity, run it in the dev console when a video is playing?
Is it supposed to report undefined back to me and start a newline?

[b2ag]

For clarity, run it in the dev console when a video is playing? Is it supposed to report undefined back to me and start a newline?

Yes, run it in dev console when a video is playing. And yes, undefined is the expected result. The command overrides a handler set by shaka-player which normally reacts to a "stop" action by unloading the player. This is unwanted behavior in my opinion. Whenever the player gets initialized again, i.e. when navigating to another video or reloading the page, it re-installs it's normal handler. So to test if this normal handler indeed also causes problems for you, you would have to run the line again to override/disable it again.

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

I'm somewhat afraid to chime in here because one member (I don't like to name) likes to jump to conclusions and bully people.

@b2ag There is no member in our dev team that does such a thing. Please stay on topic and stop making accusations like that.

Consider this a warning as this toxic behavior isnt appreciated here. We are all volunteers doing this in our free time. If there is a decision made you dont like then have a discussion about it. Maybe we change our mind but if we don't then you shouldt hold a grudge against us.

[innersp4ce]

b2ag:

...To me this sounds a lot like the player is getting unloaded. Try to enter the following into console after the player/video has loaded and see if you still can reproduce the issue. navigator.mediaSession.setActionHandler("stop", ()=>{console.error("stop")})

Thanks for the suggestion b2ag, I think this is a good lead.

Following these instructions i cant one on one reproduce the issue I have so I regard this as a working workaround. Any of the triggers described in above post do not trigger the issue described in OP post.

However below I found out a reliable way to reproduce the original issue in OP post.

1. Play video for n amount of time, length does not matter.
2. AFK, and idle the PC. (Screen lock @ 15 minutes, Hiberante/Suspend: off, turn off screen 30 minutes but when locked after 20 seconds)
3. Wait for > 30 minutes (as far as I tried)
4. come back, login; the player is unloaded and unresponsive.

When I override the above handler and follow the above instructions, after coming back and login the console shows Error: stop. Which I think is what the above command is supposed to output.

Except the shaka player is still responsive and the video paused at the correct timestamp. The video can be resumed without issue as far as I can tell.

I am unsure if below is related:
Thirdly I had one error after 52 minutes of consecutive playback. This caused the shaka player to fallback to legacy video format, which couldn't be toggled manually or automatically back to DASH (let it play for 20 minutes).

The error was worked around by reloading the player/video. This caused the video to resume playback at the correct timestamp where it stopped when reloading the player/video.

Link to the used video for testing: GinoMachino: Dark Souls 3 But I'm ONLY LEVELING STRENGTH!

The issue itself is much more likely to occur on longer video's > 15 minutes. On a 40m to 3h length of a video its guaranteed when doing anything to trigger it in OP post.

[innersp4ce]

I have been able to generate the "stop" error a couple more times which I couldnt with the referenced YT video above. Yes I've sat through the full 3 hours trying to reproduce.

Used this video: PhlyDaily: This MASSIVE French Tank GOES NUCLEAR
Length: 28 minutes

First time:

1. Load video
2. Enter override command in console
3. Lose focus on the freetube application window
4. at 4 minutes click the playback bar to forward 2 minutes
5. Error stop count 2

Second time:

1. Let it play
2. lose window focus again
3. Click playback bar at about 22 minutes to rewind to 18 minutes.
4. Error stop count 3

P.S.: I forgot when the first of these 3 error messages occured. Could be left over from my previous post or another video.

Console shows this error:

Edit: Above happens in a similar pattern of occurences as without using the command

[innersp4ce]

So summary of where I am at with my issue.

1. navigator.mediaSession.setActionHandler("stop", ()=>{console.error("stop")}) works for me as a workaround
2. "stop" error messages are generated in a very similar pattern and rate, if not exactly the same, as the original issue is in OP post.
3. When the error stop message is generated, the player stays responsive and i can resume playback from the timestamp it stopped. There are no issues at all with the player.
4. New: Clicking the playback progress bar pauses the video and seems to unload the video buffer however playback can be resumed as the player stays responsive and just seems to very quickly rebuffer.
5. Some video's generate it more than others and it doesn't seem video length related (a 20 minute video generating it 5 times compared to a 3 hour video generating it 3 times.)
6. mesa driver doesn't look related concluded out of point 1 through 4. They negate the issue.

I'd be happy to dig further into this with your directions if need be. Otherwise I hope devs have acquired the information you need to resolve the issue. Thank you for your time

[b2ag]

I've recently found out the new player used since v0.22.0-beta is spamming MPRIS (the media player remote control interface on Linux) with a lot of seek events. As this behavior is highly unusually it can (and obviously does) lead to different random things happening around the media session control interface.

I've filed a bug with upstream, they fixed it and it hit their nightly. I'm already testing it since yesterday and it looks promising to be a fix for the random stuff I saw happening at my box.

For the fix to hit a FreeTube release, it first has to make it into an upstream release. I don't know how long this will take, but I can give you another workaround to try: dbus-launch freetube. The idea is to give FreeTube an isolated DBUS session so it can only spam itself. The command should NoT drop you back to shell for as long as FreeTube is running. If it does, make sure you close all FreeTube windows before running it, so that it has fully exited. Good luck!

Upstream bug for reference: shaka-project/shaka-player#8098
EDIT: commit is released in shaka-player v4.13.4

[innersp4ce]

Used freetube by means of dbus-launch yesterday. Sat through about 10h of footage mostly playing in the background. I couldn't reproduce the issue in OP post at all anymore. The freetube console stayed clean of errors. Behavior of Freetube was as expected.

However I can't test anymore since freetube is completely broken for me. It does not play any video due to [BAD_HTTP_STATUS: 403] Potential causes: IP block or streaming URL deciphering failed as of 12 hours ago related to issue 6701. For future purposes the issue is not linked to this issue because there is no relation to OP post issue as of my knowledge.

Conclusion:
The issue is with shaka player and not the freetube app itself. Reasoning is below 2 workarounds provide the expected result:
1. Within Freetube console every video enter: navigator.mediaSession.setActionHandler("stop", ()=>{console.error("stop")})
2. From shell: launch-dbus freetube
As of this moment waiting on upstream fix of shaka-player (see post above)

Devs, can close/lock per your procedures. Thank you for your time.
@b2ag Much love! Thank you for your detailed explanation, it has been very educative 😁

[b2ag]

I should mention that dbus-launch freetube also prevents FreeTube from receiving any legit MPRIS commands. So if for example your screenlocker upon activation is sending a "stop" to all running players this won't reach FreeTube. This behavior of sending a "stop" would still result in an unloaded player if FreeTube was started normally. A "pause" would work fine though. I've not made up my mind about filing an issue with upstream regarding this stop handler yet. But it looks like they just copied their demo code. And it would make sense to unload the player on stop on their demo website... ¯\_(ツ)_/¯