Yt-dlp => Pinchflat
Well, this is a pleasant surprise, with all the issues that I've been having with yt-dlp, or rather the issues that I've been having with YouTube, a friend of mine suggested that I look into Pinchflat. I was hesitant at first, as it looked like the software is just a more pleasant front end for yt-dlp, but after a bit of thinking I decided to give it a shot anyway.
The results have been mixed so far, but generally its going in a good direction. As Pinchflat has allowed me to work around the Youtube issues with less work then I was previously doing. The biggest thing is that Pinchflat automatically reschedules downloads, and indexing of the playlists. This allows me to not "babysit" the yt-dlp script to ensure that it eventually grabs the videos.
That being said, lets dig into the issues that I have had with it. Though I will note that the issues I having are small and probably subjective, or come from a lack of knowledge of the way that the underlying system works.
The first issue is that the Custom Aliases conflict with the global settings of "Restrict Filenames". "Restrict Filenames" is an underlying yt-dl setting that removes all problematic characters in the final filename and replaces them with an underscore. This allows you to not worry about issues with the filesystem because a streamer decided to include an emoji in the title of the video.
The next issue is the pure lack of helpful* logging. The reason that I believe this, is because of an ongoing issue that I'm having with one of my sources. In short, I believed that Pinchflat wasn't upholding this part of its feature set:
- Allows automatically redownloading new media after a set period
- This can help improve the download quality of new content or improve SponsorBlock tags
The source in question is a Youtube playlist of a streamer playing the "new" Blue Prince game. All the videos in the playlist are recorded and uploaded in HD quality, and at least a resolution of 1080. Yet after several indexing jobs, both forced and scheduled, Pinchflat would never download a video better the SD with a resolution of 640. Scouring the logs would produce no information about the index job other then the call to the yt-dlp. Eventually I discovered what I currently believe the problem to be. I believe the indexing job is running into documented issues with youtube concerning SABR protocol, which prevents the indexing job from seeing the higher quality videos. This is specifically an issue because I have my "Preferred Resolution" on the media profile set to 1080, and I knew that every one of the videos had the ability to get a 1080HD copy. I would have expected that if the indexer could not find a resolution equal to or better then the "Preferred Resolution" it would emit a Warning, or log in the file that it couldn't find a resolution to fulfil the "Preferred Resolution" of the media profile.
*I say helpful because I have switched the default logging level from "Debug" to "Info" due to the (almost) continuous stream of SQL query logging that happens at the debug level, which could be helpful but for the current issue is more of a hindrance.
Overall, I'm at least currently content with what Pinchflat is doing for me, and will continue to use the software in hopes that the issues I have will either be resolved or become non-issues over time. I would recommend that you should take a look too, if you're inclined to have your own Youtube backup library for when your internet fails too.