FreeTube icon indicating copy to clipboard operation
FreeTube copied to clipboard

[Bug]: SponsorBlock segment isnt skipped

Open efb4f5ff-1298-471a-8973-3d47447115dc opened this issue 2 years ago • 20 comments

Guidelines

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

Describe the bug

  1. Go to SponsorBlock settings
  2. Enable SponsorBlock
  3. Enable Notify when sponsor segment is skipped
  4. Set Skip Option for all segments to Auto Skip
  5. Set different colors for all the segments
  6. Go to https://youtu.be/qLVgr29NMA0
  7. Skip to 17:24
  8. See that first segment is skipped but the last one isnt

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

I'm experiencing the same issue, and additionally, I don't get any notification when segments do get skipped.

xdpirate avatar Aug 21 '23 21:08 xdpirate

I'm having the same issue on Arch Linux AUR build.

Revival8697 avatar Sep 21 '23 13:09 Revival8697

Bug still exists (a bug doesn't disappear because its issue hasn't received comments for 28 days)

xdpirate avatar Oct 20 '23 07:10 xdpirate

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.

Revival8697 avatar Oct 20 '23 17:10 Revival8697

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.

RyanHx avatar Oct 22 '23 21:10 RyanHx

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

arch-btw avatar Oct 28 '23 07:10 arch-btw

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

metoxys avatar Nov 02 '23 01:11 metoxys

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?

Revival8697 avatar Nov 06 '23 12:11 Revival8697

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

mchangrh avatar Nov 06 '23 19:11 mchangrh

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 at 00:15-00:20, we would jump straight from 00:10 to 00:20, instead of the current system of jumping from 00:10 to 00:15 and then to 00: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: Screenshot_20231107_075227 cleaned

Revival8697 avatar Nov 07 '23 00:11 Revival8697

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.

mooreye avatar Dec 09 '23 20:12 mooreye

This is happening more and more often, if segments overlap the second one isn't skipped :/

mooreye avatar Jan 03 '24 22:01 mooreye

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?

mooreye avatar Mar 01 '24 13:03 mooreye

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.

github-actions[bot] avatar Mar 30 '24 01:03 github-actions[bot]

Bump

mooreye avatar Mar 30 '24 10:03 mooreye

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.

github-actions[bot] avatar May 16 '24 01:05 github-actions[bot]

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.

github-actions[bot] avatar Jun 19 '24 01:06 github-actions[bot]

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.

github-actions[bot] avatar Jul 18 '24 01:07 github-actions[bot]