Open efb4f5ff-1298-471a-8973-3d47447115dc opened 1 year ago
I'm experiencing the same issue, and additionally, I don't get any notification when segments do get skipped.
I'm having the same issue on Arch Linux AUR build.
Bug still exists (a bug doesn't disappear because its issue hasn't received comments for 28 days)
I think I found the issue. If the video have continuous segments (1 end at x and 1 start at x). Freetube will not skip the latter one as it is counted as already in the segment. You can test this here: https://youtu.be/Slwai2Jhy_A?si=mVC3UhiF-SQGBxg0&t=155. The segment at https://youtu.be/Slwai2Jhy_A?si=gpx4Um_AxMMF4mnU&t=563 will not be skipped.
Yep I've noticed the same behaviour - if there's continuous segments only the first will be skipped. Another example here: https://youtu.be/4XscfA1dT60 Even weirder; the intro was skipped, I don't have filler segments on autoskip so that played just fine, but then the sponsored segment at 3:30 wasn't skipped, I guess since all 3 are continuous.
This also happens when the video is on repeat. The intro gets skipped the first time it's played but not the second time.
Using: v0.19.1-nightly-3573 Beta
Confirming on https://www.youtube.com/watch?v=nn2-7jMkSGs with a ~1 minute long segment ~25 seconds in not being skipped or indicated at all
I think I found the issue. If the video have continuous segments (1 end at x and 1 start at x). Freetube will not skip the latter one as it is counted as already in the segment. You can test this here: https://youtu.be/Slwai2Jhy_A?si=mVC3UhiF-SQGBxg0&t=155. The segment at https://youtu.be/Slwai2Jhy_A?si=gpx4Um_AxMMF4mnU&t=563 will not be skipped.
Hey. I was wrong about this. The later segment does not start at x, it starts 0.067 second before x... Source: https://sb.ltn.fi/video/Slwai2Jhy_A/?page=3&sort=starttime. The current implementation have no check for this. Maybe the developers want to work with SponsorBlock directly on how this should be mitigated?
The sponsorblock solution is to skip the the end of the last chained segment
Here's the code from my JS client handling overlaps https://github.com/mchangrh/sb.js/blob/08b0e7026b1ac154f2783a6f1a15f9dfd731549f/src/sb.js#L77
Retrieved from dev chat
Currently each sponsorblock segment is skipped individually and as the browser player only fires the
timeupdate
event about once a second, by the time it fires you are already inside the next segment, so that "feature" prevents the jump from happening.The only way of keeping that "feature" that I can think of, would be to combine the jumps for consecutive segments into one. So if you have a segment at
00:10-00:15
and then another one at00:15-00:20
, we would jump straight from00:10
to00:20
, instead of the current system of jumping from00:10
to00:15
and then to00:20
this pull request is the culprit: https://github.com/FreeTubeApp/FreeTube/pull/3116
Hey. I was wrong about this. The later segment does not start at x, it starts 0.067 second before x... Source: https://sb.ltn.fi/video/Slwai2Jhy_A/?page=3&sort=starttime. The current implementation have no check for this. Maybe the developers want to work with SponsorBlock directly on how this should be mitigated?
SponsorBlock dev respond:
I get this too. If there are 2 differently-categorized skippable segments right next to each other, it looks like only the first one is skipped.
Example: https://youtu.be/l5fVfmt95G8 at 4:57 - there is filler and then immediately sponsor, only filler gets skipped.
This is happening more and more often, if segments overlap the second one isn't skipped :/
This issue is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Can someone work on this?
This issue is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Bump
This issue is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 7 days.
This issue is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 7 days.
Guidelines
Describe the bug
https://github.com/FreeTubeApp/FreeTube/assets/73130443/c92ec882-b24c-469d-81df-073701d888af
Expected Behavior
Last segment should also be skipped
Issue Labels
inconsistent behavior
FreeTube Version
https://github.com/FreeTubeApp/FreeTube/commit/a4d45b5fa8a8a1726808c9eebe307643f8dde9c9
Operating System Version
Win10 22H2
Installation Method
.exe
Primary API used
Local API
Last Known Working FreeTube Version (If Any)
No response
Additional Information
No response
Nightly Build