Error unexpected EOF and it stop audio record immediately but stream is not end #136
Comments
Nekofoxmiu
changed the title
|
Hmm, I should add an option to dump the HTML when it cannot find the data we're looking for. The main thing I can think of that would cause this is it serving you some kind of verification page on that refresh attempt. |
|
Hmmmm...OK...so should I closed this issue or change the title? |
|
You can leave it as is for now. I might add the option later to dump the HTML on failing to extract a player response from it, and then upload a binary here for you to use. That way if it's something fixable I'll have something to go on, but if it's some kind of bot-check then we'll know you're out of luck for a while. |
|
After some admittedly unscientific testing, I think this has to do with using a cookies file. I’ve been running into this near 100% of the time around 1 hour in to streams recently, so I was messing around with it and tried several things including changing my IP to no effect, before noticing that dropping --cookies seemed to stop the issue. So I recorded two more streams with the exact same options except one loading the cookies file: and one without it: The former died at an hour despite the stream continuing while the latter was fine. Neither of these streams are members streams or actually need cookies, but I tend to leave the option in for convenience and only update the cookies file on the rare occasion I archive a members stream, so they are usually being loaded while out of date. Up until now this hasn’t been a problem outside of members streams themselves, but now I wonder if whatever refresh is happening at 1 hour is causing youtube to look at the outdated cookies for some reason. |
|
Someone else I have contact with ran into this too recently. I had him use a quick custom build that dumped the HTML on error. The image of the page is below. |
|
Removing cookies so far does seem avoid the error. |
|
Also been getting this issue with cookies, but it's not the most consistent... some streams break at 1 hour (and can break later after starting another download), while others run perfectly fine for hours. And sometimes when a stream ends and the archive's finished downloading, it will show the player response error even though nothing's broken.
I noticed that yt-dlp actively updates the cookies.txt file whenever you download through it; I haven't paid attention to what it changes, but perhaps this needs to be implemented here? |
|
I think that's exactly what we need to implement, i've tried exporting a new cookies.txt before the hour mark and even though the error still popped up, it continued to download after (presumably by reading the file again) |
|
That is interesting, but also separate from the issue at hand. That one does appear to be cookies no longer working mid-download, but it still retrieved the actual watch page, as opposed to some random page about cookie settings. Also it does not re-read the cookies file in the middle of downloading, only once at the start of loading yta (or at the start of each loop when monitoring a channel). According to the Golang docs: I could potentially write updated cookies to the file for the hell of it, but if you are running multiple instances of yta at once, that could be messy. I'm not sure how useful that actually is either since they are already desynced from your browser cookies the moment you export and load another Youtube page. |
|
Related issue for yt-dlp has a user workaround: yt-dlp/yt-dlp#8227 (comment)
|
It often happen after 1 hour record.
Also I am not sure it will affect or not, I am running ytarchive in node.js childprocess.
Here is my code.
The text was updated successfully, but these errors were encountered: