Open 0xDEADCADE opened 3 years ago
Perhaps because it's not HTTPS?
1 curiosity:
After installing, why user has to manually type the https://sponsor.ajay.app/api/
for SponsorBlock to work?!
I really don't understand. For newcomers who are not nerds, this is a strange way to roll a feature.
It's to make opting into sponsorblock explicit. Using sponsorblock has(had?) privacy downsides. This is more of a relic of when it was intended to go upstream but is still a good UX choice w.r.t. privacy worth keeping IMO.
You also don't need to type it manually, you just need to press the question mark and that has a button for the official API and their privacy policy.
I have verified that my fork does query whatever endpoint you provide. As long as your private SponsorBlock instance can handle requests in the form "https://
Checklist
Steps to reproduce the bug
http://(server ip)/api/
, in my case that'shttp://192.168.2.151/api/
Actual behavior
The private SponsorBlock API is never accessed. Thus SponsorBlock does not appear to function on device. The instance does work, as when tested from a different device using SponsorBlock for Firefox, it functions normally. The instance also works from a web browser on the device running NewPipe, indicating there's no apparent connection issues between the instance server and the device running NewPipe. When using the official SponsorBlock API, (
https://sponsor.ajay.app/api/
), everything functions normally.Expected behavior
NewPipe should send requests to the private SponsorBlock instance, just like it does with the official instance.
Device info
Edit: After posting this issue I saw I was one version behind. I have updated and the issue remains.