You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature request: faster upload detection (RSS/API), delayed SponsorBlock re-checks, and alerts when a video is edited or removed #968
First of all, thank you for this project. The pace of development, the documentation and the care that goes into every release are genuinely impressive.
My use case: I subscribe to a set of channels and want every new upload to land in my Jellyfin library as quickly as possible, ideally ad-free, so I can watch it offline on my TV. Four additions would make Youtarr the perfect tool for this, and I believe this combination would set it apart from everything else in this space.
1. Faster detection of new uploads
Right now, channel checks run on a cron schedule (hourly by default) and each run scans channels with yt-dlp. Running that every few minutes across many channels is heavy and risks rate limits.
Idea:
Poll each channel's YouTube RSS feed (https://www.youtube.com/feeds/videos.xml?channel_id=...) or the YouTube Data API (with an optional user-supplied API key) every few minutes. Both are lightweight and would only trigger a yt-dlp download when a new video ID appears.
Optionally support YouTube's WebSub (PubSubHubbub) push notifications for near real-time detection, for setups with a reachable callback URL.
Keep the full yt-dlp scan as a less frequent safety net.
2. Download now, remove sponsors later
SponsorBlock segments are submitted by the community, so minutes after an upload there usually aren't any yet. Downloading fast and removing sponsors currently work against each other.
Idea:
After the first download, re-check SponsorBlock for that video at configurable intervals (e.g. after 6 h, 24 h and 72 h).
When new segments appear, either cut them from the existing file with ffmpeg (no re-download needed) or re-download the video.
Stop re-checking after a configurable window.
3. Show which segments were or will be removed
Store the SponsorBlock segments per video and show them in the video details (category, start/end, already cut or not). That way I can start watching right away and still know which parts are or will be removed. Using "mark" (chapters) on the first download and switching to "remove" once segments are confirmed would be a great combination.
4. Alert when a video is edited, made private or deleted
I noticed Youtarr already checks whether downloaded videos still exist on YouTube, which is great. Building on that:
During a configurable watch window after download (e.g. 14 days), check each new video regularly on a schedule.
Detect when a video is deleted, made private/unlisted, or edited (for example when its duration changes).
Send an Apprise notification and show a badge/filter in the UI.
Never automatically replace the original file with the edited version: keep the original (or keep both).
Background: creators sometimes have to cut or remove a video after a strike. I'd like to keep the original version I downloaded and simply be informed when that happens.
I run Youtarr on Unraid with Jellyfin and would be happy to test any of this. Do you think something like this could fit Youtarr's direction?
Thanks for the detailed issue. These are all good ideas, but they're really four separate features, so they need to be split into separate issues. I'm also not planning to work on any of them right away.
Checking for new uploads more often (the rest of Update application name in README #1). One heads up on RSS: Youtarr used some of YouTube's RSS feeds early on to figure out which tabs a channel has. I had to replace that with yt-dlp because those feeds started failing at random and Youtarr ended up with bad data. So I'm pretty hesitant to depend on RSS again.
Activity
dialmaster commentedon Oct 26, 2026
Thanks for the detailed issue. These are all good ideas, but they're really four separate features, so they need to be split into separate issues. I'm also not planning to work on any of them right away.
Two of them already have issues:
The other two would be new issues:
Once those are split out, I plan to close this one.