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.
[pbs] Failed to download Nova video #14305
Closed
Comments
|
Okay, out of curiosity, I grabbed the embed code for the video: <iframe width="512" height="376" src="http://player.pbs.org/viralplayer/3004606354/" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" seamless allowfullscreen></iframe>Then I feed the URL directly to youtube-dl. And it seems to work! Verbose partial output (still in download at the moment) follows: |
|
PBS/Nova has been broken for awhile. The value of "pbs_video_id_*" used to contain only digits and the pbs extractor code matches this. But at some point the value became a string ending with "==" , "IrutAxizvuIvkt__hRsh-A==", for example, for the death-dive-to-Saturn program. Somehow that turns into "3004606354". It looks like base64, but isn't. So I've reached the extent of my expertise. Hopefully someone else will recognize the format. |
|
#14351 does NOT close this issue. Tested with exact same URL, still ended with error: |
More investigation:The strangely-encoded value of Feeding that URL to youtube-dl, though, properly triggers the download of the video by .ts chunks using |
|
Are you sure my fix does not work? I download without problems --edit |
|
Hmmm... I think I made a mistake when pulling. I'll try again. |
|
The page source of:
By assembling the embedURL, embedType, and id values in sequence, this url is contructed:
which are redirects to http mp4 and hls, respectively. However, if for the embedURL value, "viralplayer" is used instead of "portalplayer", like this: Yet still, if the encoded value is used with an embedURL value of "partnerplayer, like this: then yet another hls redirect variant is revealed. This last variant seems to reveal the higher hls bitrates directly, and it probably caused by being logged in somehow. Also, the http mp4 naming convention has changed. http mp4 doesn't seem to go higher than the 3000k name for newer videos. Previously, http mp4 url names ranged up to 6500k. Those qualities now seem to be exclusively hls. |
|
So the real id is |
|
|
|
Now my pull request ( #14351 ) handle all of this, check it. |
|
@stinkteeth one point to note is that I am not a "passport" subscriber, yet if I pull |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Make sure you are using the latest version: run
youtube-dl --versionand ensure your version is 2017.09.15. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.Before submitting an issue make sure you have:
What is the purpose of your issue?
The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue
If the purpose of this issue is a bug report, site support request or you are not completely sure provide the full verbose output as follows:
Add the
-vflag to your command line you run youtube-dl with (youtube-dl -v <your command line>), copy the whole output and insert it here. It should look similar to one below (replace it with your log inserted between triple ```):Description of your issue, suggested solution and other information
Not sure if this is related to #7095 or not, but since #7095 is an "old" issue (opened 2015, last update Jan 2017) with a possible solution #b0db58b, I think a new issue is in order.
I also don't think this is related to #8538, but since youtube-dl totally failed finding any video, probably not.
If you need more info or things to try out, feel free to ask.