So how ThirdTube works is it uses a decrypter and some base.js tomfoolery to access /player (without 403ing).
The issue with this approach is, well, it breaks a lot. It was fine when the dev was active, but the dev has not.
However
We don't need that, we just need to send IOS YouTube app data, and it makes it happy (this is one of the methods YT-DLP uses)
std::string video_content = R"({"videoId": "%0", %1"context": {"client": {"hl": "%2","gl": "%3","clientName": "IOS","clientVersion": "19.29.1","deviceMake": "Apple","deviceModel": "19.29.1","osName": "iPhone","userAgent": "com.google.ios.youtube/19.29.1 (iPhone16,2; U; CPU iOS 17_5_1 like Mac OS X;)\"","osVersion": "17.5.1.21F90"}}, "playbackContext": {"contentPlaybackContext": {"signatureTimestamp": %4}}})";
Issue
This causes the metadata to breaks, thankfully we just have a separate post_content and video_content strings and use both for
I have a fork in which it is fixed, https://github.com/erievs/FourthTube
But here is the fix
How The Fix Works
So how ThirdTube works is it uses a decrypter and some base.js tomfoolery to access /player (without 403ing). The issue with this approach is, well, it breaks a lot. It was fine when the dev was active, but the dev has not.
However
We don't need that, we just need to send IOS YouTube app data, and it makes it happy (this is one of the methods YT-DLP uses)
std::string video_content = R"({"videoId": "%0", %1"context": {"client": {"hl": "%2","gl": "%3","clientName": "IOS","clientVersion": "19.29.1","deviceMake": "Apple","deviceModel": "19.29.1","osName": "iPhone","userAgent": "com.google.ios.youtube/19.29.1 (iPhone16,2; U; CPU iOS 17_5_1 like Mac OS X;)\"","osVersion": "17.5.1.21F90"}}, "playbackContext": {"contentPlaybackContext": {"signatureTimestamp": %4}}})";
Issue
This causes the metadata to breaks, thankfully we just have a separate post_content and video_content strings and use both for