Open Xyde opened 3 years ago
--geo-bypass-country CODE Force bypass geographic restriction with
explicitly provided two-letter ISO 3166-2
country code
What this option does is supply an additional X-Forwarded-For
header with an IP of the country assigned as value, in your case
[debug] Using fake IP 133.126.171.56 (JP) as X-Forwarded-For.
to stream manifest requests, and successfully functions only on geofenced services where this "hack" actually fools their geolocation-based access-control-lists (ACLs); this is usually only true where the stream CDN itself does not geoblock, only the playlist generating API does...
AFAIAA, the --geo-bypass-country
flag does NOT work for YouTube, that is in order to watch a geoblocked yt clip, you have to employ a whitelisted HTTPS/SOCKS5 proxy and/or a full blown VPN; in any case, the --geo-bypass-country
supporting code does not (and was not designed to) touch at all the clip-title code...
BTW, be kind enough to trim down your verbose log to just include the first and last clips in the yt playlist, we get the drift already, it is counter-intuitive to have to scroll such a long way down to just comment/help... 😉
Kind regards
--geo-bypass-country CODE Force bypass geographic restriction with explicitly provided two-letter ISO 3166-2 country code
What this option does is supply an additional
X-Forwarded-For
header with an IP of the country assigned as value, in your case
[debug] Using fake IP 133.126.171.56 (JP) as X-Forwarded-For.
to stream manifest requests, and successfully functions only on geo-fenced services where this "hack" actually fools their geo-location circumvention measures; this is usually only true where the stream CDN itself does not geoblock, only the playlist generating API does...
AFAIAA, the
--geo-bypass-country
flag does NOT work for YouTube, that is in order to watch a geoblocked yt clip, you have to employ a whitelisted HTTPS/SOCKS5 proxy and/or a full blown VPN; in any case, the--geo-bypass-country
supporting code does not (and was not designed to) touch at all the clip-title code...BTW, be kind enough to trim down your verbose log to just include the first and last clips in the yt playlist, we get the drift already, it is counter-intuitive to have to scroll such a long way down to just comment/help... 😉
Kind regards
My bad, this is the first tiem I've posted CMD logs on github so I just didn't want to miss out anything on accident.
I noticed that for the first video there was this additional debug line
[download] Downloading video 1 of 87
[debug] Using fake IP 133.248.221.231 (JP) as X-Forwarded-For.
[youtube] enm9Lz3x018: Downloading webpage
[youtube] {18} signature length 106, html5 player 16e41f55
where it managed to encode the original title, I think: 【歌ってみた】エバ _ 柊キライ【Kotone(天神子兎音)cover】-enm9Lz3x018.mkv
Whereas the second and third video (which is the one I listed) didn't :
[download] Downloading video 3 of 87
[youtube] 09z87O1CgIw: Downloading webpage
[youtube] {18} signature length 106, html5 player 16e41f55
I'll just crop everything from the 1st to the 3rd video in the OP, I hope that would suffice.
@blackjack4494 : The New Issue template has to follow latest yt-dlc version, OP wrote:
- [x] I've verified that I'm running youtube-dlc version 2020.10.31
at a time (Nov 9th 2020, 15:18 UTC) when latest release is 2020.11.07 (?)
The playlist data contains only localized title, whereas the video page contains both versions in different places.
Perhaps title_localized
should be added as output template option? (See also.)
In the video page I looked at, they appeared as:
original title
html: <title>
, <meta name="title">
js: ytInitialPlayerResponse['videoDetails']['title']
original description
html: <meta name="description">
js: ytInitialPlayerResponse['videoDetails']['shortDescription']
localized title
html: <meta property="og:title">
, <meta name="twitter:title">
js: ytInitialPlayerResponse['microformat']['playerMicroformatRenderer']['title']['simpleText']
js: ytInitialData['contents']['twoColumnWatchNextResults']['results']['results']['contents'][0]['videoPrimaryInfoRenderer']['title']['runs'][0]['text']
localized description
html: <meta property="og:description">
, <meta name="twitter:description">
js: ytInitialPlayerResponse['microformat']['playerMicroformatRenderer']['description']['simpleText']
js: ytInitialData['contents']['twoColumnWatchNextResults']['results']['results']['contents'][1]['videoSecondaryInfoRenderer']['description']['runs'][['text']]
@blackjack4494 : The New Issue template has to follow latest yt-dlc version, OP wrote:
[x] I've verified that I'm running youtube-dlc version 2020.10.31
at a time (Nov 9th 2020, 15:18 UTC) when latest release is 2020.11.07 (?)
Well this is the first time I've submitted a bug tracker with a log. But you can see in the verbose log that it is indeed using the latest version. I will edit now. I just kept the default bug track message as it is because I thought that it would update to the latest version by itself. Dumb I know.
@Xyde : You've done nothing wrong 😄 !
I just kept the default bug track message as it is because I thought that it would update to the latest version by itself.
This is a matter that needs to be addressed by the repo/issue tracker owner...
The behaviour exhibited by the upstream (original youtube-dl
) issue tracker was that after a stable release, the New Issue templates would have been modified accordingly, to reflect the newly released yt-dl version; e.g., in the update 2020.09.20 -> 2020.11.01:
https://gitlab.com/dstftw/youtube-dl/-/commit/3429951
(Currently, yt-dl's issue tracker on GitHub remains invisible, the temp repo on GitLab just hasn't had the original issue tracker exported...)
@Xyde : You've done nothing wrong 😄 !
I just kept the default bug track message as it is because I thought that it would update to the latest version by itself.
This is a matter that needs to be addressed by the repo/issue tracker owner... The behaviour exhibited by the upstream (original
youtube-dl
) issue tracker was that after a stable release, the New Issue templates would have been modified accordingly, to reflect the newly released yt-dl version; e.g., in the update 2020.09.20 -> 2020.11.01:https://gitlab.com/dstftw/youtube-dl/-/commit/3429951
(Currently, yt-dl's issue tracker on GitHub remains invisible, the temp repo on GitLab just hasn't had the original issue tracker exported...)
They had some local scripts. I use GitHub Actions (CI/CD Pipeline) to completely be transparent. However it is unfortunately not possible to automate updating the issue templates as github restricts actions to make any changes to .github folder. But the templates are located there unfortunately. So I am sometimes too lazy or simply forget to update these. If someone wants to open a PR regarding this they are welcomed to do so. However those are still JUST templates. This means users can edit them to reflect their current status. Nothing wrong with editing the version to a newer one (when available). That rather shows me that people either do not even read or check versions OR are too afraid of changing the version in the template :P
Checklist
Verbose log
Description
I want to avoid parsing the localised title by using the --geo-bypass-country flag, however it is only applied to individual videos, and not playlists, channels (randomized url) and and user channel (non randomized url). I only used playlists in the verbose log but the same problem also happens to channels (tested with another channel).
Say for the video 09z87O1CgIw, In the example below I got the filename【歌ってみた】KING Kanaria【Kotone(天神子兎音)cover】-09z87O1CgIw.mkv but in the example above (where I used playlist) I got the filename 【I tried to sing】KING Kanaria【Kotone (Tenjin Kotone) cover】-09z87O1CgIw.mkv .
The below is the log of applying on a single video: