Lytexx
commented
2 years ago @Kethsar just got this issue on a stream for the first time
2022/01/22 16:31:01 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:01 DEBUG: audio3: Fragment 12654: 10/10 retries
2022/01/22 16:31:01 DEBUG: audio3: Fragment 12654: Stream still live, continuing download attempt
2022/01/22 16:31:02 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:03 DEBUG: video2: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:04 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:05 DEBUG: video2: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:05 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found
2022/01/22 16:31:07 DEBUG: audio3: HTTP Error for fragment 12654: 404 Not Found and the googleurl says id=<id>.4 instead of .1 for some reason, there was only one manifest change from what i can tell
this worries me a lot since it can happen without warning and make ytarchive run in a loop forever ;w; please look over it whenever you have motivation again
edit: just happened again and it uses .5 now so I probably just missed the first 3
It appears occasionally youtube will actually create a new manifest for a Stream. That, or the streamer can by messing with something. Currently ytarchive fails when this happens as the new manifest resets the fragment number back to 0. The manifest and googlevideo URLs will have an id parameter set to
<videoid>.<manifest number>. Check this parameter and keep track of the manifest number, resetting the fragment number as necessary.Also turns out a new manifest can end up with different qualities. So a stream starting with up to 1080p can end up only having up to 720p if the streamer decided to reduce their quality without making a new frame. This may require muxing for each manifest rather than appending to the stream as a whole.