(This notice was initially posted here, with reuploads of affected archives.)
Due to a tooling bug, some fragments were not properly written in the publicly distributed archives of Ame's unarchived waiting room-turned-karaoke and 4th of July karaoke streams.
The bug is due to YouTube offering zero-length fragments without raising error codes under certain conditions (seems to be caused by lag on the streamer side, but not completely sure).
This behavior was not observed on every stream.
The bug was present in a new tool that was being tested, and has been fixed for future recording operations.
ytarchiveis unaffected by this bug.- Unsure whether or not
yt-dlpis affected by this; it's difficult to trace their fragment handling code.- 2024-07-17 update: yt-dlp (version 2024.07.02 on my machine, likely more) possibly affected? Unsure if root cause is the same; yt-dlp has been observed to report "ERROR: Did not get any data blocks" and "[download] fragment not found; Skipping fragment {seq} ..." during a stream, which does result in a significant final archive size mismatch.
No other karaoke archives that were published with the affected tool (between 2024-06-26 and 2024-07-05; prior releases were made using ytarchive) appear to be affected.
Audio-only uploads were produced via ytarchive and are unaffected.
You can validate the archives yourself by counting the actual number of video segments produced by this command; note that the segment number in the filename will be off by one since the first file is segment 0:
Replace ${INPUT_FILE} with the path of a video file, and change the working directory to an empty folder so you can delete the thousands of generated files later.
To check audio, you must compare against a known reference file in something like Audacity, or verify that the actual decoded duration matches the length specified in the stream.
The outputs of the new tool will undergo review again to ensure they match ytarchive's outputs for the short term until I'm assured there are no remaining issues. ytarchive can't cover 100% of streams since it doesn't handle certain edge cases very well.
(Note: They were already being reviewed, but I also started prioritizing VP9 streams simultaneously, which is only offered by a subset of streams.)