bug: SponsorBlock skipping a non-music segment at end of music video in playlist dont autoplay next video in playlist

[Xycotic01]

Bug description

This is the same issue I brought up about a week ago (https://github.com/ReVanced/revanced-patches-template/issues/68). It was resolved, but I discovered a new video where SponsorBlock skipping a segment at the end of a video (the video is in a playlist) somehow disables the autoplay of the next video in a playlist. I was listening to a music playlist and found this example (https://www.youtube.com/watch?v=SECVGN4Bsgg). Not sure if others may be able to replicate my issues. Just wanted to bring it up. When my previous issue was patched, all of my example videos worked properly (and still work fine).

Error logs

No response

Solution

No response

Additional context

No response

Acknowledgements

• This issue is not a duplicate of an existing bug report.
• I have chosen an appropriate title.
• All requested information has been provided properly.

[oSumAtrIX]

Have you disabled the SponsorBlock patch and confirmed it was caused by it?

[Xycotic01]

Yes, it is caused by the SponsorBlock patch. I disabled SponsorBlock and it worked fine.

[LisoUseInAIKyrios]

@oSumAtrIX change ReVanced/revanced-integrations@3d660e1 fixed some situations, but it's still not fixed for playlists using this particular video. Add this video to the first of a playlist, change non music sections to autoskip, and at the end of the video it won't skip to the next video.

It's worth noting that skipping using the double tap to skip or manually seeking to the end of the video has no problem. Perhaps a different seek hook might fix all of this, as there's some YT logic to act differently depending on the source of the seek using a seek source enum. Or maybe this can be fixed with more adjustments of the seek time if it's near the end.

[inotia00]

In my case I tried to fix it with the following commit:
inotia00/revanced-integrations@206b9ba

I'm not sure if this is the most ideal workaround, but @LisoUseInAIKyrios, could you test it?

[LisoUseInAIKyrios]

Yes it seems to work correctly for this use case.

Although it might be better keeping the segment times the same as SB provides, since they show up in the voting menu and users might think the timing is wrong and down vote them. The time adjustment could be in VideoInformation#seek() as it's not called often.

[oSumAtrIX]

Prior to the linked commit, Videoinformationen#seekTo() did seek 500ms earlier if requested to seek more than the video length, but that did not fix all issues.

[LisoUseInAIKyrios]

Before it removed 100ms if it was near or over the video end time, but that still means it can skip to a time past the end of the video.

Prior code:
final long seekToMilliseconds = millisecond <= videoLength - 500 ? millisecond : millisecond - 100;

Code that appears to work:
final long seekToMilliseconds = Math.min(millisecond, VideoInformation.getVideoLength() - 250);

[oSumAtrIX]

I am noticing that instead of subtracting 100 milliseconds of the length to seek to, it should subtract it from the video length. This was an oversight in the previous code and should be fixed.

[LisoUseInAIKyrios]

100ms doesn't appear to be enough to fix this particular video (playlist stops and does not advance).

250ms works, but I haven't tried between 100-250ms.