polymorphicshade
Sponsorblocks applied to downloads
Checklist
- [X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
- [X] I have read the FAQ and my problem isn't listed.
- [X] I'm aware that this is a request for Tubular itself and that requests for adding a new service need to be made in vanilla NewPipeExtractor.
- [X] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
- [X] This issue contains only one feature request.
- [X] I have read and understood the vanilla NewPipe contribution guidelines.
Feature description
Apply sponsorblocks to downloaded content.
Why do you want this feature?
Currently, when downloading content (specifically audio only), the content is downloaded and saved without applying sponsorblocks.
Why ist the feature relevant to this fork?
This fork implements the sponsorblock functionality.
Additional information
No response
Is that even possible? Unless you're talking about playing downloaded videos through Tubular?
No not proposing playing downloaded content through Tubular. I don't know how sponsorblock is implemented in Tubular, but it is able to be done through yt-dlp - the content is downloaded, then sponsorblock timecodes are applied and the resulting file is saved sans the blocked bits. Knowing yt-dlp, this is probably done by running through ffmpeg with the cuts from sponsorblock, but orchestrated by yt-dlp.
I was suggesting that Tubular might be able to do the same thing at the end of the download action.
I should add one crucial information: that's really useful to download music without non-music segments. There were times I preferred downloading music over yt-dlp over Tubular only because it supports Sponsorblock.
In a version of NPxSB, I had an experimental feature of having an offline video player that worked with SponsorBlock.
It was a hack and didn't work very well... I have yet to implement something like this in Tubular because It think the core implementation should be in NewPipe (see: https://github.com/TeamNewPipe/NewPipe/issues/10542).
Nonetheless, I really like the idea of incorporating yt-dlp in Tubular. There are several offline video players on android already, so just adding yt-dlp in Tubular would bridge the gap nicely I think.
There are several offline video players on android already, so just adding yt-dlp in Tubular would bridge the gap nicely I think.
Yes, and in my use case it's mainly for audio files for which there are also numerous players. Typically I just use the audio player within my file browser since it supports m4a nicely.
I listen to podcasts that are downloaded.. This would be nice for that as well.
If it's of any help, yt-dlp does have an in-built function that omits including SponsorBlock segments from the downloaded file itself. However, I don't think it's customisable or is able to read user-made segments. I think what could be done instead is download the pieces that aren't SponsorBlock segments — with respect to user-made segments via Tubular — using yt-dlp, then stitch them together via Ffmpeg. I don't know if Ffmpeg works on Android, though.
Seeing this issue is a little funny to me, actually. A few days ago, I was thinking of issuing a feature request to replace the NewPipe downloader with yt-dlp outright, and this issue was one of the things I cited in a draft — the others pertained to the ability to choose specific stream codecs.
I just swapped out newpipe for tubular for this exact purpose because it claims to have sponsorblock, only to find out that sponsorblock only works for streaming... As someone that does a lot of traveling I almost exclusively only download videos from youtube when conditions allow because often my connection is not good enough to stream at decent quality.
I find it disingenuous to advertise sponsorblock as a feature when it's only partially functional and granted that this report is a year old I'm not left with much confidence that this will ever get done.
Back to newpipe and yt-dlp I guess. Even though command line interface applications on a mobile device are quite the terrible experience...
The guy from the last comment is a troll: just Google him, they posts a lot of comments on public repos blaming developers for issues without any consideration. No sane person wishing Sponsorblock would ever switch from Tubular with a partial implementation to NewPipe without anything of it implemented, thus I guessed it could be a troll. The Google search just confirmed my guess. They even made their GitHub activity private to hide their troll activity. Just ignore them.
@qgustavor
All I can say is that you better learn to handle criticism better if you're going to operate within the public sphere but alas, apparently having a different opinion than you makes me "not sane" despite you being the one condoning a fork when the main feature that differentiates it from upstream is only a partial implementation with no progress in a year. What does that say about you?
Either way, I'll elaborate a little more to explain why I switched back to newpipe. On top of the aforementioned lack of proper sponsorblock implementation, tubular is also vastly less stable. Crashing or hanging while performing basic tasks that don't occur with vanilla newpipe on the same device. So I see no need to deal with that in addition to the advertised feature not being finished to meet my use case.
Grow a thicker skin.
While this might be tricky to implement (given you can't just grab the file, it'd have to be encoded on-the-fly), it would be a cool feature to have, yes.
Some videos can literally have up to a third of the entire video being skipped, so would be great if we could not include any of that when downloading a video, to save bandwidth and storage-space.
Or, as an alternative:
Maybe downloaded videos could be playable within Tubular itself (not an external app) and the SponsorBlock skips could be saved into a local database and so still get applied when an offline, local video is then played?
Maybe downloaded videos could be playable within Tubular itself (not an external app) and the SponsorBlock skips could be saved into a local database and so still get applied when an offline, local video is then played?
I concur. This would be the simplest way of implementing SB to downloads; allowing Tubular to play local videos from the downloads menu, with SB segments stored internally or in some user-level JSON to read off of.
While some may complain of the file size, not all SB segments are fool-proof and that implementing file-level SB (i.e. physically removing segments) may result in unwanted omissions. Keeping the video as it is would let users come back to skipped segments should they want/need to.
While having Tubular play the local files from the downloads menu would work, it might make sense to break it up into 2 separate stories from an implementation perspective.
Story 1: Implement yt-dlp with sponsorblock into the download function of Tubular. That way users get downloaded files with sb content removed. Files would be downloaded and stored just as they are today and played via whatever means the user wants.
Story 2: Implement the playing of the downloaded local files (with the sb content removed) through Tubular.
For anyone still crossing their fingers with a hope and a preyer that sponsorblock will ever be fully implemented into fibular, (despite the fact that this is the predominant selling feature of the app over upstream) just install yt-dlp through termux instead.
The yt-dlp repo has idiot proof copy + paste instructions clearly outlined on how to install yt-dlp and update it when needed:
https://github.com/yt-dlp/yt-dlp/wiki/Installation
No need to continue waiting for this to be done in fibular, maybe, some day, if the stars ever align at the same time as an equinox.