-
-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Blocking]: List of things to do before working on new features #415
Comments
I'll help where I'm able and have the time. |
Should we add "Allow videos to fail to download, but continue the queue" with exception handling as an additional marker, as noted in #307? I know we don't want a ton of tasks here, but that seems to be one of the overarching problems that is causing the download lock to become stuck. |
That is implemented on expected errors that can't be recovered from, e.g. if the video became unavailable after it got added to the queue but before it's downloaded, in that case, the queue will continue: Additionally there are timeouts and retries from yt-dlp too, to recover from small networking interruptions. But the more severe problems like, connection gets interrupted beyond the timeouts and retries, or a container disappears, I think it makes sense to stop the queue there. I mean if the internet is gone, it makes no sense to try again with the next video. But to recover from that, that's where |
I'm going to take a look at moving the config persistence to ES (and hopefully removing the need for the Redis JSON plugin). It's a chunky bit of work so it might take me a bit of time. |
Sounds good. You are free to have the draft PR and also welcome to join the Discord and discuss on our #help-contribute channel. For the most part, we should be able to re-initialize Redis on each TA restart. That should mean that all configurations should be in ES first, then TA should push those configurations across to Redis for ease of access during runtime. Changes to those configurations should then first be pushed to ES and then re-initiate a pull to Redis. |
Most of that is now completed. Or at least on the way. There is still work to be done to migrate away from the redis plugins, we'll tackle that going forward. |
Background: This project has grown very fast, too fast, new features were implemented at the cost of reduced maintainability and reliability of the project. Functionality wise, this project has a lot going for it, now its time to revisit some of these early flaws, so:
This is a potentially none complete list of blocking things to figure out, before working on additional major features. Outlined solutions may or may not be good ideas.
/<channel-id>/<video-id>.mp4
Additionally, not strictly blocking but high priority:
This list will be updated as we go. Expect this to take as long as it takes. Any help with this is highly welcome. Reach out on Discord to coordinate.
If you want to work on new features or fixes not listed here, reach out on Discord first, to make sure your code doesn't interfere with problems outlined above.
The text was updated successfully, but these errors were encountered: