I noticed when i tried to setup a test doing a very long recording that it would simply stop recording at some point. Everything looks like it's normal, except that the MB and Time is stuck. The third time it happened at 02:18:29 with 10.8gb size. But it happened the first time at a bit larger (13GB, not sure about the time). And second time it happened quite fast (which made me think it was something i did, as i record in the background). However i haven't been able to reproduce the problem at will, it simply stops. Codec is MagicYUV set to RGB. I record Direct3D on Snes Emulator playing an intro in loop forever (Super Mario World). Not sure how to bugtrack but any suggestion is appreciated, hopefully it's something on my part. EDIT: Happened again during me writing this, stopped at 7:19 minutes.
Try to use different codec to see if it is codec related. If it doesn't help - try to enable video recording log in SaveMedia.cfg in RTSS folder.
Stuff like this seems to appear in the SaveMedia64.log Code: 04-02-2015, 08:25:23 HostThread VideoCopy : assembler queue is full, dropping frame, 8 dropped frame(s) total 04-02-2015, 08:25:23 HostThread VideoCapture : 1 ms, B8G8R8 299x224 frame 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, copy performed per client request 04-02-2015, 08:25:23 HostThread VideoCopy : assembler queue is full, dropping frame, 9 dropped frame(s) total 04-02-2015, 08:25:23 HostThread VideoCapture : 1 ms, B8G8R8 299x224 frame 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, copy performed per client request 04-02-2015, 08:25:23 HostThread VideoCopy : assembler queue is full, dropping frame, 10 dropped frame(s) total 04-02-2015, 08:25:23 HostThread VideoCapture : 1 ms, B8G8R8 299x224 frame 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, copy performed per client request 04-02-2015, 08:25:23 HostThread VideoCopy : assembler queue is full, dropping frame, 11 dropped frame(s) total 04-02-2015, 08:25:23 HostThread VideoCapture : 1 ms, B8G8R8 299x224 frame 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, copy performed per client request 04-02-2015, 08:25:23 HostThread VideoCopy : assembler queue is full, dropping frame, 12 dropped frame(s) total 04-02-2015, 08:25:23 HostThread VideoCapture : 1 ms, B8G8R8 299x224 final frame 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, copy performed per client request 04-02-2015, 08:25:23 HostThread VideoCopy : 0 ms, 62 of 60 assembler queue slot(s) in use 04-02-2015, 08:25:23 CompressorThread1 Idle : 56829 ms 04-02-2015, 08:25:23 CompressorThread1 VideoConvert : 0 ms, B8G8R8 298x224 final frame to R8G8B8 04-02-2015, 08:25:23 AudioThread Idle : 999 ms 04-02-2015, 08:25:23 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) 04-02-2015, 08:25:23 AudioThread Idle : 999 ms 04-02-2015, 08:25:23 AudioThread AudioCapture : 0 ms, 192000 byte(s) 04-02-2015, 08:25:24 AudioThread Idle : 1000 ms 04-02-2015, 08:25:24 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) 04-02-2015, 08:25:24 AudioThread Idle : 999 ms 04-02-2015, 08:25:24 AudioThread AudioCapture : 0 ms, 192000 byte(s) 04-02-2015, 08:25:25 AudioThread Idle : 1000 ms 04-02-2015, 08:25:25 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) 04-02-2015, 08:25:25 AudioThread Idle : 999 ms 04-02-2015, 08:25:25 AudioThread AudioCapture : 0 ms, 192000 byte(s) 04-02-2015, 08:25:26 AudioThread Idle : 1000 ms 04-02-2015, 08:25:26 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) 04-02-2015, 08:25:26 AudioThread Idle : 1000 ms 04-02-2015, 08:25:26 AudioThread AudioCapture : 0 ms, 192000 byte(s) 04-02-2015, 08:25:27 AudioThread Idle : 1001 ms 04-02-2015, 08:25:27 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) 04-02-2015, 08:25:27 AudioThread Idle : 1000 ms 04-02-2015, 08:25:27 AudioThread AudioCapture : 0 ms, 192000 byte(s) 04-02-2015, 08:25:28 AudioThread Idle : 999 ms 04-02-2015, 08:25:28 AudioThread AudioCapture2 : 0 ms, 96000 byte(s) In the EncoderServer64.log it looks just like normal. Download Logs
I'm afraid I cannot help even with log, it tells that compressor thread simply hangs at some point. Cannot imagine anything but hw issue and cannot offer you anything, sorry.
Hmm this is worse than i thought. Will try to see if i can figure out something. Weird thing is that this has never happened before with MSI Afterburner. Will report back if i find out anything.
32bit Encoder Server seems to work without locking (at 1:40 hours). EDIT: Okay failed at about 2:29 hours.
Unwinder, When the assembly queue gets full instead of writing what's in it, what's happening really? What's preventing the images from getting through? Trying to pinpoint the error. If it's that it can't read the image (the capture), or if it just can't encode the image, or perhaps just not write it to the Disk for some reason. Thanks
Assembler queue contains raw captured frames, the frames in queue are being asynchronously encoded by separate thread then written to disk by assembler. It is neither capture nor write failure in your log, the thread that encodes queued frames just hungs on your system at some point. And once again, I cannot help with resolving it.
Ok that's great. Thought it could have been some kind of write failure first so did some testing for that. Know you can't help, just need information so i can troubleshoot. Hmm, this is really weird. May be the process being captured, snes9x.
And why not using zsnesw? Has snes9x any advantage? xD Im sure zsnesw will work, if it only stops at snes9x. Or does it stop on every game?
Tried Higan same results. Even in fullscreen it crashes, however then it doesn't just stop like nothing has happened, the EncoderServer64 crashes (in window mode it doesn't crash until i close MSI Afterburner or use Task Manager). Tried both with Snes9x fullscreen and Higan, Snes9x survived 6hours i think? Well thing is that it's completely random, it can fail in 10min, 5 hours etc. Which makes this really frustrating. EDIT: If possible could you Demon record Super Mario World when you go to sleep, letting it run till you wake up? (The longer recording the better, but around 5+ hours is ok). Cause need someone to test this, 1: for the crashing issue. 2: for the desync issue. I will try access another PC to do this test on as well to make sure it's not system dependent. (Pretty sure all systems will have desync though, just more or less).
