I've moved log.info calls to console.log calls to reduce conflicts of logs at the same time as console refreshes, but also to reduce unnecessary log level text being printed to the console.
We don't need to know if a log is an `info` level log, but I've kept log.error's and such as we would want to know if a log is an error log and such.
This changes all logs via logging to be printed to the rich console instead. Specifically, using my custom ComfyRichHandler making the logs padded horizontally.
In this change the time is no longer printed. The log level is still printed but it's now the full log name in bold.
These add a bit of margin around all console prints/logs. It makes the logs feel a bit more comfortable rather than being crammed edge-to-edge in the terminal.
The methods used here are by no means good, but they work quite well. If you can find a better way to do it, please make a pull request.
These seem to occur when using HTTP+S proxies when connecting to a HTTPS URL. E.g., NordVPN proxies to https://google.com. While not ideal, we can't solve this solution and the warning logs are quite annoying.
It seems on Windows the pathlib.iterdir() function is always in order. However, on Linux or at least some machines this is not the case. This change fixes the order.
If you think you were affected, check your previous downloads that used DASH or HLS segmentation and make sure they dont randomly change scenes out of order.
Turns out, even if you manually set the Range header AND the server has full support, it does not work. It will act like it works, but it seems internally aria2c gets confused on what bytes it requested, what it returned, and it will either just download the full file, or the range requested (but still complain, and freeze!).
Yikes.
For some reason I had the partial removed and replaced with the direct function, meaning services using `title` and `track` during the license and service cert functions would crash.
This fixes the usage of vaults across different threads. It now makes a truly unique connection for each thread. The previous code did this as well, but put back the connection from x thread, to re-use in y thread. Now it simply creates and reuses the connection on their own thread.
Once the thread is closed, the data is now also garbage collected. This now reduces the risk of filling up memory over time.
Just like the commit for HLS multi-threading, this mimics the -j=16 system of aria2c, but manually via a ThreadPoolExecutor. Benefits of this is we still keep support for the new system, and we now get a useful progress bar via TQDM on segmented downloads, unlike aria2c which essentially fills the terminal with jumbled download progress stubs.
This mimics the -j=16 system of aria2c, but manually via a ThreadPoolExecutor. Benefits of this is we still keep support for the new system, and we now get a useful progress bar via TQDM on segmented downloads, unlike aria2c which essentially fills the terminal with jumbled download progress stubs.
This is required in segmented scenarios when multi-threaded where the same `track.path` would be get and set from possibly at the same time. It's also just better logically to do it this way.
rlaphoenix
varyg