Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Pluralsight content too short - ONLY when <rate-limit> option used #9530
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey Sergey,
Since #9504 was closed I tried to comment there after doing more research into the issue but since it is still closed will open a new issue to explain in better detail.
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.
In fact I now find it is IMO impossible to download more than half an entire playlist using --rate-limit option, while I have 100% success rate on the same playlists upon removing only the --rate-limit option from the active YTDL command line.
My strong guess is that PS is either implementing something to detect non-player usage, or perhaps since they have also been plagued for years with their HTML5 player having issues, that some new buffering implementation is not returning expected results to the YTDL rate-limit mechanism.
Given those PY line numbers shown in #9504 comments, is there anything else short of a wireshark cap we can do to narrow down what is being triggered in YTDL to cause it to sense a network error and drop the connection ONLY while using it's rate-limit mechanism? I'm happy to help where I can just let me know.
Collin