"No video information found, somehow" error when using cookies

[ALXMRW]

Seemingly out of nowhere, I'm unable to use the --cookies command on ytarchive with any success. When using --cookies, every video I attempt to download throws me this error. --verbose and --debug don't give any further information either.

Using a random public video as an example:

WARNING: Failed to retrieve data from https://www.youtube.com/get_video_info?video_id=-3Ns_n_7QzU&el=detailpage: HTTP Error 404: Not Found
WARNING: No video information found, somehow

If I don't use --cookies, I can download it no problem but that doesn't solve the problem of being able to record unarchived members-only streams which is what I prefer using ytarchive for. I've attempted this on two different computers with the same result. Additionally, I use yt-dlp for all non-live archiving and it's recording members-only livestreams without an issue so I know it's not my cookies. Something similar happened to me with youtube-dl months ago and I think it turned out to be on YouTube's backend that changed but not for everyone at once.

[Kethsar]

Interestingly enough I was getting this same issue with Streamlink just last night. Consistently failed if I had it set to wait for a stream, but worked if the stream was already running.

Will look into this.

[Kethsar]

From what I can tell, there are probably some bad youtube servers that have get_video_info removed or inaccessible from some update that was pushed out in the past week. Someone I know said he's been getting a lot of 404s on his RSS as well, so it might affect more than just this. It's quite surprising you get such a consistent 404 using ytarchive with cookies.

I have implemented a potential fix. Unfortunately because the problem is so intermittent I cannot be 100% certain it works. That is, if for some reason even the watch page 404s when the script tries to download it, I don't think I'll be able to do much. If you could test by attempting to use the newest commit on a members-only video, that would be great. Doesn't even have to be a livestream since the failure normally happens before it even gets far enough to check normally.

If you are using the .exe from the releases page instead of the .py file, let me know and I'll create a new one for you from the most recent commit. I'll be going to bed soonish though, and might not be around for ~10 hours once I do.

[ALXMRW]

Yeah, I'm using the .exe since I couldn't ever fully grasp Python. No worries about getting to it when you can.

[Kethsar]

ytarchive.zip

Okay, I've attached a zip containing the exe built from the newest commit. Please try using it.

[ALXMRW]

Just want to make sure these trojans from the .exe are false positives before I test it:

Trojan:Script/Wacatac.B!ml
Trojan:Win32/Glupteba!ml

[Kethsar]

They are. It's a side effect of what has to be done to bundle a Python program into an exe, since they aren't meant to be.
See issue #9

Edit: This is part of the reason I am doing a rewrite in Golang as well. Will allow releasing binaries for each platform effortlessly, even if I do pull in a couple deps for that version. Gonna take me a while though.

[ALXMRW]

And here's where I mention that I'm still running Win7 and due to that, the program gives me an error about not having api-ms-win-core-path-l1-1-0.dll. I remember this happening with another program I use in CLI and I think finding out that .dll is only available for Windows 8 and above.

[Kethsar]

The installer now also actively disallows installation on Windows 7. Python 3.9 is incompatible with this unsupported version of Windows.

Hah, go figure. I switched to 3.9 in my VM when testing a previous issue.
Shit as it is, you should look into upgrading to Win10 at some point.
I've attached another zip, this time running pyinstaller from a Python 3.8 context. Should hopefully work.

ytarchive.zip

[ALXMRW]

Yeah... I'm getting to that point with how many program updates are becoming obsolete for me.

There aren't any members-only livestreams happening for me so I've tested with what I can. Attempting a public livestream with the use of --cookies seems to work without a problem, I just get the error with a followup showing it getting data from the watch page. I then tried a non-live members-only stream and I get this:

WARNING: ←[33mFailed to retrieve data from https://www.youtube.com/get_video_info?video_id=p7maIgwwfzY&el=detailpage: HTTP Error 404: Not Found←[0m←[K
WARNING: ←[33mget_video_info failed to return data.←[0m←[K
WARNING: ←[33mAttempting to get data from watch page.←[0m←[K
Traceback (most recent call last):
  File "ytarchive.py", line 2206, in <module>
  File "ytarchive.py", line 1957, in main
  File "ytarchive.py", line 844, in get_video_info
  File "ytarchive.py", line 613, in get_playable_player_response
  File "ytarchive.py", line 493, in get_player_response
  File "json\__init__.py", line 357, in loads
  File "json\decoder.py", line 340, in decode
json.decoder.JSONDecodeError: Extra data: line 1 column 62709 (char 62708)
[182584] Failed to execute script ytarchive

[Kethsar]

Hmm, I wonder if member watch pages have extra data there or something.
Could you go to that same video in your browser, right-click somewhere on the page, click "save page as", upload it to https://litterbox.catbox.moe/ as a 1-hour expiration, and post the link here?

Nevermind, I can see even from my end without being able to play the video. Will fix.

[Kethsar]

Okay, one more time please.

ytarchive.zip

[ALXMRW]

This one is definitely looking promising. I'm getting the expected result of "Livestream has been processed, use youtube-dl instead." I'll try it out on a members-only livestream in the next couple days and let you know how it goes.

Thanks for all the help so far!

[Lytexx]

I just got it for the first time and its on a public stream
seems like what you added fixed it not sure if its different on members streams

C:\Users\Lytexx\Downloads>yta
Enter a youtube livestream URL: https://www.youtube.com/watch?v=Hbt-FqWt50A
15:57:00 INFO: Loaded cookie file cookies.txt
15:57:00 WARNING: Failed to retrieve data from https://www.youtube.com/get_video_info?video_id=Hbt-FqWt50A&el=detailpage: HTTP Error 404: Not Found
15:57:00 WARNING: get_video_info failed to return data.
15:57:00 WARNING: Attempting to get data from watch page.
Available video qualities: audio_only, 144p, 240p, 360p, 480p, 720p, 720p60, 1080p60, best
Enter desired video quality:
Selected quality: 1080p60 (h264)
15:57:02 INFO: Starting download to Hbt-FqWt50A__2g4g8y8o\[20210518] ういニングライブ #しぐれうい2周年 [しぐれうい] (Hbt-FqWt50A).f140.ts
15:57:02 INFO: Starting download to Hbt-FqWt50A__2g4g8y8o\[20210518] ういニングライブ #しぐれうい2周年 [しぐれうい] (Hbt-FqWt50A).f299.ts
Video fragments: 3608; Audio fragments: 3609; Max sequence: 3608; Total Downloaded: 1.34GiB

edit:

From what I can tell, there are probably some bad youtube servers that have get_video_info removed or inaccessible from some update that was pushed out in the past week. Someone I know said he's been getting a lot of 404s on his RSS as well, so it might affect more than just this. It's quite surprising you get such a consistent 404 using ytarchive with cookies.

it only happens when you are logged in when i log out i can open the get_video_info link without any issue

[Kethsar]

It used to be a lot more intermittent, but I've been noticing it consistently hitting a 404 when using cookies as well now.
The cause might be propagating through the servers. I just hope it was unintentional and gets fixed, but that might be a ways out before we know.

[ALXMRW]

Did some more testing and it looks like things are recording without a problem for me with your hotfix version. Only thing is the console window gets flooded with the 404 error when they don't start exactly on schedule but that's just cosmetic. Also thought it was worth mentioning that the latest stable release doesn't even work without use of --cookies anymore like it used to.

[Kethsar]

Yeah I'm not surprised. I wasn't planning on tagging a new release for the Python version but I just might with this issue.
For the most part I think this can be considered fixed though. Closing.