Checklist
Preface (edit):
I hope my linked video is not deemed inappropriate. I have used Gamers Nexus GPU Black Market documentary because of its length. I am aware PipePipe does support Bilibili and therefore Chinese users, so I want to apologize if any dev or participant finds this insensitive or inappropriate.
I do not want to pass any judgment about the topic or politics of either party here. I am a human like all of you.
Describe the bug
I mentioned this here before, but for exposure and clean separation, here's the issue:
When playing a long video (I will elaborate below) and stopping it for example halfway, closing it via "X", killing the app and restarting it, the video is resumed from a exactly doubled amount of elapsed time.
Meaning if an video is 01:00:00, you stop it at 00:20:15 and follow these steps, it resumes at 00:40:30.
This happens with SABR (MWEB and WEB) for me, but not on HLS (Safari WEB) yet.
It also might not happen 100% of the time, but I can consistently reproduce it on my end.
A strange observation:
When this happens, the video sometimes "rushes" pictures until the doubled time and the seek bar shows only half, like this
(refer to preface if the video is insensitive for anyone)
and what I just noticed now, if you keep the player UI and seek bar visible, you can see the loaded part actually catching up, like buffering, but I assume it loads all data between both points, which is why it also takes a long time to load and resume.
To reiterate: I can confirm it is always exactly double the amount of time the player tries to resume from, and it just so happens that it looks like some of the video gets loaded before and then catches up to the wrong point.
So the initial load point might be correct. At first it also shows the correct elapsed time (red) at the bottom left on the thumbnail on the player if the video is opened without auto-play, but fails the way described after pressing play.
I'm sure I forgot something, but I'll update it once I read it over and cleared some thoughts.
As I have been asked in the other issue, here is an example video link of a video, where it happens. I can reproduce this on shorter videos, but longer videos will take time buffering and one could see the catching up behavior mentioned above.
https://www.youtube.com/watch?v=1H3xQaf7BFI
(Gamer's Nexus)
Skip to 1 hour or so, let it run for 5 seconds, then pause and close with X, etc. You'll see it resuming from 2 hours instead after the next launch.
Also, to account for the other questions of Priveetee's in the other issue:
- playback speed is 1x
- not logged in
- no error report
- mentioned above, but SABR was used with both MWEB and WEB
- does not happen without SABR
Version
5.2.1beta3, but happened betas before
Frequency
Often (80-90% of the time)
Device
Miatoll, LineageOS 22.2
Steps to reproduce the bug
- open a long video (to be sure)
- skip to a point somewhere between 30-40%
- play a couple of seconds, then pause
- close the video by pressing X at the top left
- kill the app
- restart the app, go to history and play the video
- it will now try to resume from the doubled time at 60-80%, dependent on the above
- optional: try to keep the UI active and pay attention to the seek bar, as it progressively fills until reaching the dot and then actually resumes
Additional context
Like I said, I just tested it with Safari WEB extraction point and it resumed at the correct point in time.
I have another report on SABR potentially messing up timestamps, so it would not surprise me if anything on YouTube's side messes this up as well, or if the player misinterprets the wrong value, like getting the initial value, then setting it on top of it, making it doubled.
Checklist
Preface (edit):
I hope my linked video is not deemed inappropriate. I have used Gamers Nexus GPU Black Market documentary because of its length. I am aware PipePipe does support Bilibili and therefore Chinese users, so I want to apologize if any dev or participant finds this insensitive or inappropriate.
I do not want to pass any judgment about the topic or politics of either party here. I am a human like all of you.
Describe the bug
I mentioned this here before, but for exposure and clean separation, here's the issue:
When playing a long video (I will elaborate below) and stopping it for example halfway, closing it via "X", killing the app and restarting it, the video is resumed from a exactly doubled amount of elapsed time.
Meaning if an video is 01:00:00, you stop it at 00:20:15 and follow these steps, it resumes at 00:40:30.
This happens with SABR (MWEB and WEB) for me, but not on HLS (Safari WEB) yet.
It also might not happen 100% of the time, but I can consistently reproduce it on my end.
A strange observation:
When this happens, the video sometimes "rushes" pictures until the doubled time and the seek bar shows only half, like this
(refer to preface if the video is insensitive for anyone)
and what I just noticed now, if you keep the player UI and seek bar visible, you can see the loaded part actually catching up, like buffering, but I assume it loads all data between both points, which is why it also takes a long time to load and resume.
To reiterate: I can confirm it is always exactly double the amount of time the player tries to resume from, and it just so happens that it looks like some of the video gets loaded before and then catches up to the wrong point.
So the initial load point might be correct. At first it also shows the correct elapsed time (red) at the bottom left on the thumbnail on the player if the video is opened without auto-play, but fails the way described after pressing play.
I'm sure I forgot something, but I'll update it once I read it over and cleared some thoughts.
As I have been asked in the other issue, here is an example video link of a video, where it happens. I can reproduce this on shorter videos, but longer videos will take time buffering and one could see the catching up behavior mentioned above.
https://www.youtube.com/watch?v=1H3xQaf7BFI
(Gamer's Nexus)
Skip to 1 hour or so, let it run for 5 seconds, then pause and close with X, etc. You'll see it resuming from 2 hours instead after the next launch.
Also, to account for the other questions of Priveetee's in the other issue:
Version
5.2.1beta3, but happened betas before
Frequency
Often (80-90% of the time)
Device
Miatoll, LineageOS 22.2
Steps to reproduce the bug
Additional context
Like I said, I just tested it with Safari WEB extraction point and it resumed at the correct point in time.
I have another report on SABR potentially messing up timestamps, so it would not surprise me if anything on YouTube's side messes this up as well, or if the player misinterprets the wrong value, like getting the initial value, then setting it on top of it, making it doubled.