Question / Help Recent Build Recording Issues - Corrupt Files

FerretBomb

FerretBomb

Active Member
Hey, just wondered if anyone else was getting this. On longer casts, I've had OBS end with a 'wait 15 seconds for recording to finish?' error, but I've already ended the recording and stream a good five minutes prior. After it waits, it exits and I'm left with an unplayable FLV; it doesn't even start playing when I try to check the archive.
Also, toward the end of some casts I start getting a 'High CPU Usage' warning, even though my CPU is hovering in the (entirely normal) 80% range. There are no capped cores, and no other process seems to have any issue with the 'high load'.

I also recently had an NTFS.sys crash; the associated drive vanished on reboot, so I figured a disk fail was at-fault. But this has started happening since updating to the most recent version, and I'm now wondering if OBS' local disk write may have caused the BSOD somehow, and corrupted the disk, rather than the disk failing causing the BSOD.

This has only started becoming an issue after upgrading to OBS v0.651b on Win7-64.

Logfile: http://pastebin.com/gujbAFq9
 
FerretBomb said:
Hey, just wondered if anyone else was getting this. On longer casts, I've had OBS end with a 'wait 15 seconds for recording to finish?' error, but I've already ended the recording and stream a good five minutes prior. After it waits, it exits and I'm left with an unplayable FLV; it doesn't even start playing when I try to check the archive.
Also, toward the end of some casts I start getting a 'High CPU Usage' warning, even though my CPU is hovering in the (entirely normal) 80% range. There are no capped cores, and no other process seems to have any issue with the 'high load'.

I also recently had an NTFS.sys crash; the associated drive vanished on reboot, so I figured a disk fail was at-fault. But this has started happening since updating to the most recent version, and I'm now wondering if OBS' local disk write may have caused the BSOD somehow, and corrupted the disk, rather than the disk failing causing the BSOD.

This has only started becoming an issue after upgrading to OBS v0.651b on Win7-64.

Logfile: http://pastebin.com/gujbAFq9
Click to expand...

From my memory, FLV is the one you want in general since MP4 will be corrupt if an error happens. I bet your drive is going out.
Code: 
Using custom x264 settings: "threads=10"

device: Logitech HD Pro Webcam C920
chosen type: I420, usingFourCC: false, res: 1920x1080

Using Mic QPC timestamps
Syncing audio to video time (WARNING:
you should not be doing this if you are just
having webcam desync, that's a separate issue)

CFR: no

PERFORMANCE WARNING: Scene change took 507 ms, maybe some sources should be global sources?

So let me help you fix your issues first and see if it helps on your next recording.
let OBS chose the amount of threads to use, remove "threads=10" from custom x264 settings
you are streaming at 720p so lower your webcam resolution to 720p as well
dont use mic QPC time stamps or sync audio to video
CFR should probably be enabledfor both twitch and local recording (if editing later)
Last but not least, set your webcam up in global sources, this will assist with scene changes.

Once you get that done, retry your recording
 
DPing, speaking respectfully, this isn't my first dance with OBS. The settings are there for good reason. They are not the problem, as this only started to occur after the most recent update, and only happens erratically. My drive is extremely unlikely to be 'going out'; SMART health shows it solid green... even bad sectors are exceptionally low considering the drive's age.

I *was* using FLV; apparently it switched back to MP4 at some point and I didn't notice. Possibly following the drive crash, when I had to re-path the video files to a different drive. The long-termination was happening prior to this though, when I was still using FLV.

The thread limiter is set as OBS by default will spawn more threads than it actually needs, which can result in excessive handoffs between cores/vcores. A limit of 10 on an 8-vcore system can help to reduce this and improve system utilization due to the lower switching overhead. Again, all 8 cores were showing ~80% usage, which 10 threads are able to push to 100% with more aggressive settings.

My cam is set up at 1080p as I do switch into 1080p mode fairly regularly for some games which are low-action or are especially beautiful at higher resolutions (Ori and the Blind Forest, Kingdom Hearts, Armello, etc). At 1080p the delay is stable and there is no reason to mess with switching resolutions when my workspace is 1080p and post-downscaled, and working out the new delay with the lower USB bandwidth choke.

Mic QPC timestamps prevent the mic audio from drifting, an issue which does develop regularly on my machine. Likewise, sync audio to video timestamps is on as the system audio also drifts if this is not enabled, leading to desynchronized game audio/video.

CFR will only assist if you are using a program which cannot read VFR video files without spazzing out (like Vegas, which I do not use). This will NOT help with Twitch AT ALL.

My webcam is already configured as a global source, as are all of my video capture hardware devices. That is a standardized error as the delayed scene transition is most commonly caused by someone not doing so.


So. With all of that advice explained and most of it discarded, I'm curious if @Jim or @HomeWorld might be able to comment on the utilization issue and long-termination? This is a major issue, as I lost a 10-hour stream today, and a 6-hour stream yesterday. (13.7 and 6.8GB of garbage now, respectively.) Going to reset the video format to FLV and hope that I'll at least be able to salvage any future casts that have this issue. Seriously, why does it default to MP4?
Also, not sure if it would be possible that OBS might have caused the ntfs.sys crash and corrupted the volume in the process, leading to the disk being unreadable, or if it is as I'd initially assumed; that the disk dying and vanishing caused the BSOD.
 
Last edited:
FerretBomb said:
DPing, speaking respectfully, this isn't my first dance with OBS. The settings are there for good reason. They are not the problem, as this only started to occur after the most recent update, and only happens erratically. My drive is extremely unlikely to be 'going out'; SMART health shows it solid green... even bad sectors are exceptionally low considering the drive's age.

I *was* using FLV; apparently it switched back to MP4 at some point and I didn't notice. Possibly following the drive crash, when I had to re-path the video files to a different drive. The long-termination was happening prior to this though, when I was still using FLV.

The thread limiter is set as OBS by default will spawn more threads than it actually needs, which can result in excessive handoffs between cores/vcores. A limit of 10 on an 8-vcore system can help to reduce this and improve system utilization due to the lower switching overhead. Again, all 8 cores were showing ~80% usage, which 10 threads are able to push to 100% with more aggressive settings.

My cam is set up at 1080p as I do switch into 1080p mode fairly regularly for some games which are low-action or are especially beautiful at higher resolutions (Ori and the Blind Forest, Kingdom Hearts, Armello, etc). At 1080p the delay is stable and there is no reason to mess with switching resolutions when my workspace is 1080p and post-downscaled, and working out the new delay with the lower USB bandwidth choke.

Mic QPC timestamps prevent the mic audio from drifting, an issue which does develop regularly on my machine. Likewise, sync audio to video timestamps is on as the system audio also drifts if this is not enabled, leading to desynchronized game audio/video.

CFR will only assist if you are using a program which cannot read VFR video files without spazzing out (like Vegas, which I do not use). This will NOT help with Twitch AT ALL.

My webcam is already configured as a global source, as are all of my video capture hardware devices. That is a standardized error as the delayed scene transition is most commonly caused by someone not doing so.


So. With all of that advice explained and most of it discarded, I'm curious if @Jim or @HomeWorld might be able to comment on the utilization issue and long-termination? This is a major issue, as I lost a 10-hour stream today, and a 6-hour stream yesterday. (13.7 and 6.8GB of garbage now, respectively.) Going to reset the video format to FLV and hope that I'll at least be able to salvage any future casts that have this issue. Seriously, why does it default to MP4?
Also, not sure if it would be possible that OBS might have caused the ntfs.sys crash and corrupted the volume in the process, leading to the disk being unreadable, or if it is as I'd initially assumed; that the disk dying and vanishing caused the BSOD.
Click to expand...

I'm aware, just pointing out some irregularities as I would with anyone to "uncomplicate" things. Its always easier to rule things out then try 15 things only to find out one of those is at fault.

So speaking of large file size, I had a guy the other day that had corrupt videos after a while of recording, I recommended the video splitter, even though it was only a bandaid, so if there is something becoming corrupt at large filesize, then maybe the new version is at fault?

I've heard of the manually setting the thread, but if I recall, it was 1.5x core count



Off topic, high webcam res can cause AV to get out of sync in my experience, but if your settings mitigate that, then I guess its a non issue.
 
Yep, have been using these settings for quite some time now, the corruption issue only started with the most recent update.

May want to look into the video splitter myself at that point; 2-hour chunks even would allow me to save *most* of a cast then. Assume it's a plugin?

Yep, with my setup, 1080p on the c920 results in a reliable 300ms delay. I don't want to touch it as it works no matter if I'm going at 1080 or downscaling to 720. One of those 'if it's working, don't screw with it' things.
 
Unplayable FLV? I've never heard of that happening before. I'm not sure. I'd be more interested in having a copy of the FLV. I would say "try in MP as well and see if you get the same issue" but I think there are still features you're waiting for before it's usable for you, plus that sounds like a rather sporadic and difficult-to-reproduce issue. I couldn't even theorize why that would happen.

As for MP4 files, I'm going to fix the issue in MP but haven't had a chance to get around to writing the new muxers.
 
Yep, after the archive disk death I redirected the recordings to a different disk, didn't notice that it swapped from FLV to MP4 in the process. That one's entirely my bad. Already removed the files as truncated MP4 can't be saved or repaired as far as I'm aware (seriously? this seems like a major file format flaw). The FLVs are on the (now dead) disk, and may have been related to that; I'm hoping that WD will spring for DR service, or I might dd it to an image and see what I can pull with a scraper.

The MP4 issue does persist though; high-CPU at the end of the cast with nothing taking ownership of it in task manager. The recording was ended, then the broadcast was ended (I usually run an ad-tail for a minute or so at the end of cast, and don't want to have an extra minute of logo-splash). Buttons had returned to 'start broadcast/start recording' and were/should have been clickable. Exited OBS and got the 'still writing file, wait 15 seconds to end recording?' popup, and clicked to let it finish. It apparently waited 15 seconds (maybe without closing the file handle?) and then hard-exit, nuking the MP4 file apparently. Going to test tonight with FLV and see if the same thing happens. May just be an MP4 bug in this case. Shortest video file I've had it happen on is 5 hours, longest was over 10 hours.

Yeah, I've grabbed the MP rewrite to give it a look, but it's missing major features to the point it's non-viable as compared to the classic OBS. Better than nothing if you're stuck with a Mac, a good improvement over console-native, but feature-skeletal at present as compared to OBS Classic.
Was kind of curious if the scene setup was eventually going to run something similar to Autodesk Maya's Hypershade for linking source, asset, and filter nodes, with a set of 'output deck' layers for compositing precedence.
 
FerretBomb said:
Yep, after the archive disk death I redirected the recordings to a different disk, didn't notice that it swapped from FLV to MP4 in the process. That one's entirely my bad. Already removed the files as truncated MP4 can't be saved or repaired as far as I'm aware (seriously? this seems like a major file format flaw). The FLVs are on the (now dead) disk, and may have been related to that; I'm hoping that WD will spring for DR service, or I might dd it to an image and see what I can pull with a scraper.

The MP4 issue does persist though; high-CPU at the end of the cast with nothing taking ownership of it in task manager. The recording was ended, then the broadcast was ended (I usually run an ad-tail for a minute or so at the end of cast, and don't want to have an extra minute of logo-splash). Buttons had returned to 'start broadcast/start recording' and were/should have been clickable. Exited OBS and got the 'still writing file, wait 15 seconds to end recording?' popup, and clicked to let it finish. It apparently waited 15 seconds (maybe without closing the file handle?) and then hard-exit, nuking the MP4 file apparently. Going to test tonight with FLV and see if the same thing happens. May just be an MP4 bug in this case. Shortest video file I've had it happen on is 5 hours, longest was over 10 hours.

Yeah, I've grabbed the MP rewrite to give it a look, but it's missing major features to the point it's non-viable as compared to the classic OBS. Better than nothing if you're stuck with a Mac, a good improvement over console-native, but feature-skeletal at present as compared to OBS Classic.
Was kind of curious if the scene setup was eventually going to run something similar to Autodesk Maya's Hypershade for linking source, asset, and filter nodes, with a set of 'output deck' layers for compositing precedence.
Click to expand...
testdisk works well to
 
You must log in or register to reply here.
Back
Top