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.
It seems if a service sets the expiration time in seconds or by a timestamp, then this resolves as expired up to 14 hrs too early, or 14 hours too late, depending on what your timezone is relative to UTC+00:00.
However, I haven't fully confirmed if this is the right fix to make. As in, I'm not sure if changing datetime.utcnow() to datetime.now() should be done, or the other way around. However, I've had multiple people tell me changing it this way worked for them so I'm just going to roll with it.
The new system now downloads and decrypts segments individually instead of downloading all segments, merging them, and then decrypting. Overall the download system now acts more like a normal player.
This fixes#23 as the new HLS download system detects changes in keys and init segments as segments are downloaded. DASH still only supports one period, and one period only, but hopefully I can change that in the future.
Downloading code is now also moved from the Track classes to the manifest classes. Download progress is now also actually helpful for segmented downloads (all HLS, and most DASH streams). It uses TQDM to show a progress bar based on how many segments it needs to download, and how fast it downloads them.
There's only one down side currently. Downloading of segmented videos no longer have the benefit of aria2c's -j parameter. Where it can download n URLs concurrently. Aria2c is still used but only -x and -s is going to make a difference.
In the future I will make HLS and DASH download in a multi-threaded way, sort of a manual version of -j.
If EXT-X-KEY of Method=NONE is encountered, it assumes no DRM should be used, even if other supported DRM may have already been or is going to be iterated.
rlaphoenix
varyg