Closed bcbwatt closed 1 year ago
Are you running this on Windows/Linux? And do you have the temporary files generated by ytarchive on the first run?
This is on linux (ubuntu 22.0.4). The temporary files aren't kept, but the merged mkv stays in the working folder.
Did you ever figure this out? I'm facing the same issue.
Seems to be an issue with the latest ytarchive version, I've rolled it back to v0.3.2. Feel free to reopen this issue if it still happens.
After a stream ends and the video is considered downloaded, hoshinova restarts the download. The first capture is never moved to the correct folder.
This is using the latest build of hoshinova, and a master build of ytarchive from a couple of weeks ago.
Here is the relevant log output:
I suspect it is happening because:
fps=28668 q=-1.0 size= 8109824kB time=04:12:12.00 bitrate=4390.4kbits/frame=909692 fps=28278 q=-1.0 size= 8125952kB time=04:12:41.61 bitrate=4390.5kbits/frame=914073 fps=27955 q=-1.0 size= 8166656kB time=04:13:54.63 bitrate=4391.4kbits/frame=920200 fps=27711 q=-1.0 size= 8223744kB time=04:15:36.74 bitrate=4392.6kbits/frame=926620 fps=27489 q=-1.0 size= 8283648kB time=04:17:23.74 bitrate=4394.0kbits/frame=938175 fps=27422 q=-1.0 size= 8390912kB time=04:20:36.34 bitrate=4396.1kbits/frame=944924
Possibly related is that video fragments often don't catch up with audio (by the end of a long stream the video fragments have been 10x fewer than audio). Before this started happening, I never got that output from ytarchive.