Pluralsight content too short

[CollinChaffin]

The Pluralsight extractor seems to be pulling okay but a growing amount of the videos even when highly throttled are producing unfinished ".part" files basically failed videos. This obviously results in having to re-start the list. Out of 36 I think the last run had 7 failures with this error and I still haven't quite gotten all the missed ones. Repeatedly re-running eventually gets the file, but obviously re-running 5+ times to get the missing ones may further risk of drawing attention and a possible ban.

Here's one example of the pertinent error using -Verbose. Let me know how I can help test further.

[download] 14.0% of 8.41MiB at 8.40KiB/s ETA 14:41 ERROR: content too short (e
xpected 8816947 bytes and served 1231463)
Traceback (most recent call last):
File "youtube_dl\YoutubeDL.pyo", line 1643, in process_info
File "youtube_dl\YoutubeDL.pyo", line 1585, in dl
File "youtube_dl\downloader\common.pyo", line 350, in download
File "youtube_dl\downloader\http.pyo", line 236, in real_download

ContentTooShortError

[dstftw]

content too short is usually an indication of network issues.

[CollinChaffin]

Hi is there a way yet to do automatic retries on the content too short errors? The --retries doesn't seem to work if it is just network related I'm okay retrying but cannot seem to find an easy way other than to keep re-processing the entire list and skipping those that were successful. If there is a way to get the --retries XX to literally retry the failed video XX times, that would be awesome!

[CollinChaffin]

Hey Sergey you may want to look at re-opening this one and allow community to help collect some additional debug info - I see some others posting that PS has changed something and now a growing number of their playlist will for some reason error in content too short, yet no one (including me) has any other content too short (or any other) network related issues with ydl or anything else. If I get a bit more time I'll try to get a wireshark cap of it since the YDL verbose doesn't really offer any hints, but others are reporting this is somehow a new way for them to then flag those (even throttling) to just watch for the playliist being retried multiple times for a ban but I have not been able to confirm.

[CollinChaffin]

Did not yet run any wireshark caps yet, but can confirm that this is in fact caused by setting the option of "--rate-limit" in YTDL. Used 50k as example and a large number from playlist will fail and can easily be reproduced. Removing the ratelimit results in 100% success and adding it back immediately causes failures.