SponsorBlockServer
SponsorBlockServer copied to clipboard
ajayyy
[Suggestion] Only allow endcards / credits tags in the last ~20% of the video.
I've come across many false tags recently and one thing that would help eliminate false endcards / credits tags would be to restrict the time ranges on when they can be submitted. I think any time within the last 20% would be sufficient, but it could be adjusted accordingly.
What if somebody adds a static image for the last four minutes of a video in an attempt to get a video above the ten minute mark?
How about if the segment just has to have some part of it in the last ~20%, and can extend earlier if needed? So in your example, the segment would be allowed if it goes from 6:00 to 10:00, but not 6:00 to 7:30.
https://github.com/ajayyy/SponsorBlockServer this is a better place for this issue, as this is where it would be implemented
As soon as you have these - arguably arbitrarily chosen - limitations, you'll have to deal with edge case that fall through the cracks. 20% might seem like a good guess for most of the videos, but there will be edge cases, on a huge platform like YouTube for sure.
Why not solve the real problem? The real problem is users don't choose the right segment when submitting.
So, SponsorBlock could do a better job at explaining the categories at submission time, and how people can correct incorrect categories (currently it's hidden behind the downvote button, which you won't find if you never click on it).
Endcards and credits are not the same thing. Someone can say "thanks to my patrons on Patreon" at any part of the video, not just the last two minutes.
@LoganDark The category is called "Endcard/Credits", referring to a credits screen appearing at the end.
Yes, that's what I tag it as. I also sometimes tag it as interaction reminder.
Getting back to the original topic, I think it was made clear, that there might not be a rule that fits all cases.
My suggestion would be to have a "soft rule" for this, instead of imposing a strict limit via the server by not accepting certain segments. "Breaking" such a soft rule could cause the extension to show a warning/dialog, asking the user if a mistake happened and they would like to edit the segment. At the same time they would have the possibility to acknowledge the warning and continue to submit the segment.
More input for those interested:
Such soft rules could include timing related rules, as proposed by OP, as well as segment-category-rules if anyone has an practical idea on how to implement one.
The easier, less over engineered way would be to just hardcode a set of rules into the browser extension and update them via new extension versions if needed. The extension could also download the rule set from a server periodically.
A more complicated, but also more sophisticated solution would be to have some kind of server reliant rules. While certainly being more expensive, this could allow for fancy checks, based on all the data you've collected.
For example if a channel already has an large amount of segments, but none of them is music related, it might be unlikely for new videos of them to have music related segments in them. You could display a warning if someone tries to submit a music related segment for a video from that channel, while you don't show such warnings in other cases. And having a soft rule would still leave enough room for edge cases.
Such rules would obviously need to be autogenerated, which in turn would also allow for dynamic adjustments as the underlying data (i.e. the segments collected) changes.
As I said, if any at all, the client side solution seems to be the way to go at this point of time, but you could keep the server side idea in the back of your head for later, if this whole thing continues to grow in interest.
Necro'ing this thead:
We're discussing how to implement a highly specific solution (limiting certain tags to certain parts of a video), to solve what is essentially the issue of users not understanding when to use which tag. Maybe a more holistic solution would be to improve the way we communicate this kind of information to new users? This should catch even more edge cases too :)
I'm saying that because this is a project I recently found out, became really excited about, and then learned contributing is not as straightforward as I'd expect it to be - manageable for me as a technical user, but I wouldn't really expect most of the potential target group to "get it".
