Tell us about your process and discipline; I see `engineering-quality` in the repo, which seems to be some sort of QA harness. Makes this a bit more interesting than just-another-yt-dlp-ui. Do you follow some similar design process, like speckit?
I'm not using Spec Kit specifically, my approach is pretty simple. Everything should have separation of concerns and clear ownership to help prevent nasty subtle bugs and can help point to a single entity when things go wrong.
Also, it is specifically designed to avoid only following happy paths, it exercises the actual download pipeline with yt-dlp, ffmpeg, and real output files. It will introduce things like interrupted connections, failed requests, cancellation of downloads, and unwritable destinations. It also checks for processes that were left running when a download completes as to not waste resources.
I also wanted to distinguish between headless pipeline tests and testing the actual packaged app. Passing the headless pipeline doesnt prove the UI, queue, or restart UX works. This same idea influences the design. The library should reflect the actual saved state for example. Completed should mean a valid file was produced and so the engineering quality harness is there to test assumptions and pressure test the application in ways unit tests can easily miss. It is still evolving but that is where im putting effort right now so that we dont conclude "it just works" and walk away because it needs to work well and shouldnt rob your computers memory cause it feels like holding on to it and it has helped find many issues that unit tests have missed, which is great.
One example of something the harness helped find before was regarding the processes being left over and it was found a subtle memory leak in vodforge where yt-dlp’s terminal-capability/progress machinery was retaining the per-download logger, which in turn kept the entire YoutubeDL + DownloadJob graph alive after the job finished. I believe this was in part to the fact that python methods are bounded when you access them through object instances and so yt-dlp simply needed to have its native progress path disabled since vodforge already owned progress presentation. Engineer-quality harness was able to make this subtle memory leak a massive red flag when simulating 100 downloads and then showing 100 dead job graphs still sitting in memory.
Yeah simply put. The main thing I've focused on are precisely selecting output settings based on source quality, organizing downloads by channel and playlist automatically, keeping a searchable library, in-app player, and maintaining dependencies so others don't have to. The tools under the hood are great. I wanted to make the workflow easier to use and just get the best option without thinking about it.
That’s fair. MP3 is there for compatibility but preserving the original opus/aac stream avoids another lossy conversion. We should offer both rather than present mp3 as the highest quality option.
yes it uses yt-dlp and that is a good idea. Currently, vodforge does not add random delays between downloads, it will start the next in queue immediately when the former finishes but I can add that as an option in a future update if desirable as well as scheduling.
Tell us about your process and discipline; I see `engineering-quality` in the repo, which seems to be some sort of QA harness. Makes this a bit more interesting than just-another-yt-dlp-ui. Do you follow some similar design process, like speckit?
I'm not using Spec Kit specifically, my approach is pretty simple. Everything should have separation of concerns and clear ownership to help prevent nasty subtle bugs and can help point to a single entity when things go wrong.
Also, it is specifically designed to avoid only following happy paths, it exercises the actual download pipeline with yt-dlp, ffmpeg, and real output files. It will introduce things like interrupted connections, failed requests, cancellation of downloads, and unwritable destinations. It also checks for processes that were left running when a download completes as to not waste resources.
I also wanted to distinguish between headless pipeline tests and testing the actual packaged app. Passing the headless pipeline doesnt prove the UI, queue, or restart UX works. This same idea influences the design. The library should reflect the actual saved state for example. Completed should mean a valid file was produced and so the engineering quality harness is there to test assumptions and pressure test the application in ways unit tests can easily miss. It is still evolving but that is where im putting effort right now so that we dont conclude "it just works" and walk away because it needs to work well and shouldnt rob your computers memory cause it feels like holding on to it and it has helped find many issues that unit tests have missed, which is great.
One example of something the harness helped find before was regarding the processes being left over and it was found a subtle memory leak in vodforge where yt-dlp’s terminal-capability/progress machinery was retaining the per-download logger, which in turn kept the entire YoutubeDL + DownloadJob graph alive after the job finished. I believe this was in part to the fact that python methods are bounded when you access them through object instances and so yt-dlp simply needed to have its native progress path disabled since vodforge already owned progress presentation. Engineer-quality harness was able to make this subtle memory leak a massive red flag when simulating 100 downloads and then showing 100 dead job graphs still sitting in memory.
What is CTV? We don't know your industry's jargon.
Apologies. It means Connected Television. The streaming apps on your TV like on Roku such as, Netflix, Prime, etc.
So it's a yt-dlp gui where you can also re-encode to something else?
Yeah simply put. The main thing I've focused on are precisely selecting output settings based on source quality, organizing downloads by channel and playlist automatically, keeping a searchable library, in-app player, and maintaining dependencies so others don't have to. The tools under the hood are great. I wanted to make the workflow easier to use and just get the best option without thinking about it.
For cases where audio quality is important it's best not to add another round of lossy compression by reencoding Youtube's opus/AAC track to MP3.
That’s fair. MP3 is there for compatibility but preserving the original opus/aac stream avoids another lossy conversion. We should offer both rather than present mp3 as the highest quality option.
does it use yt-dlp under the hood. also is there an option to add random delays between downloads?
yes it uses yt-dlp and that is a good idea. Currently, vodforge does not add random delays between downloads, it will start the next in queue immediately when the former finishes but I can add that as an option in a future update if desirable as well as scheduling.
Good luck with the launch!
Thank you Dylan!