I'm using Crossbow in tandem with youtube-dl as a privacy-preserving way of subscribing channels, playlists etc on YouTube.
To know how, check crossbow-cookbook(7). Long story short, users channels and playlists are associated to a feed:
- User →
https://youtube.com/feeds/videos.xml?user=$user - Channel →
https://youtube.com/feeds/videos.xml?channel_id=$channel - Playlist →
https://youtube.com/feeds/videos.xml?playlist_id=$playlist.
…and once the video URL is known, the excellent youtube-dl can handle the rest.
Unfortunately, this technique recently broke, as Youtube added a HTTP redirection in between the feed URL and the actual resource. To fix it, I'll have to modify Crossbow slightly.
Technical details
The current behaviour consists into feeding the feed URL directly to libmrss/libnxml which in turn will leverage libcurl to do the actual download. The fact that libnxml has the capability of downloading the feed XML has an obvious advantage in terms of convenience, although it is a feature I don't like much:
It is not possible to configure much of the outbound HTTP calls. For instance, I can't tell the library to follow redirects, and this is the reason why Crossbow is not trivial to fix.
More generally, the library has much more capabilities than what actually needed.
Although libcurl is a really good library, having it as a forced dependency is bad (e.g. what if I want to use another one, for some reason? Will both require openssl? Will there be two parts of the code that get to initialize openssl? I witnessed race conditions happening in similar situations).
Now, it is a good while that I'm caressing the idea of moving away from libmrss/libnxml. This problem forces me into taking the first steps into his migration. Moreover, this opens up for further improvements (e.g. I'm thinking of making the feed download asynchronous, so more downloads can happen simultaneously).