Anim Player Stops working In Video Sequence Editor #94994
Operating system: Windows 10
Graphics card: GTX 1070
Short description of error
When using the video editing functionality of Blender, if the file is left open for an extended period of time, upon return, pressing play will result in the current frame progressing by one, instead of playing.
Exact steps for others to reproduce the error
Open a file using the video sequence editor, leave for about an hour. Come back and attempt to play the file.
Changed status from 'Needs Triage' to: 'Needs User Info'
There was such issue but it should be resolved now. Please check if this happens with latest alpha build from https://builder.blender.org/download/daily/.
Hello Richard, I installed the 3.1.0 alpha, opened a recent file, and left it for an hour. Coming back to it, the problem is still present. I cannot play the file.
Actually, I can reproduce this issue, but forgot, that it still happens. Now when I resume machine from sleep, playback doesn't work and I can't quit Blender unless I kill it in task manager.
Changed status from 'Needs User Info' to: 'Confirmed'
Weirdly enough, I cannot reproduce the issue, although a friend could on his computer. @iss Could you run a debug build and see where/how it hangs in WASAPIDevice.cpp probably in the mixing thread?
Ok that's weird, I can't reproduce it now. I will keep this in mind and check when this happens next time
Finnally managed to reproduce something by accidentally kicking cable to USB soundcard (this is random issue, can not reproduce at will), so not sure whether this helps. When waking up it happened only twice and I have killed the process by accident.
In any case I see thread stuck in
mix((data_t*)buffer, length), where
buffer is NULL, length is 0 and goes back to sleep.
I guess I should have looked deeper at
setupRenderClient to see more info, will check that when I will have a chance.
Weird, I guess
buffer is okay, since
length is 0. That means that
padding have the same value. Could you please let me know what that value is next time this happens? Also it's likely that something fails silently, although it shouldn't... Could you track the value of result during one run through the endless loop and tell me if the value ever changes from
S_OK to something else? Thanks for keeping this bug in mind!
padding were equal, I think the value was 2048, but not 100% sure. Result seemed to be always S_OK. I was able to inspect
setupRenderClient but it looked to me same way as loop in
runMixingThread. Is there any significant difference?
I wasn't able to step with debuger into lower level functions though, is there is any setup I need to do in MSVC?
Ok, so nothing faulty there... To some extent I expected that, but it doesn't move us forward unfortunately. I can only suspect that the AudioClient somehow stopped playing back without telling us and I haven't found a way to check if it's started or stopped. You can't debug into lower level functions because those are part of WASAPI, i.e. the audio API off Windows (https://docs.microsoft.com/en-us/windows/win32/api/audioclient/nn-audioclient-iaudioclient).
I'm a bit at a loss for how to continue here. Something you can try with the debugger is setting
true when this happens and check if it recovers, but I'm also not sure if that's going to help if we don't have a way to figure out that something isn't working. After that my only ideas are hacky solutions such as tracking when
length was non-zero the last time to figure out this way that we're not playing back and then resetting...
I did another experiment, because I wasn't sure why I sometimes can reproduce hang after sleep - it seems, that this happens only in release builds. If PC was put to sleep while Blender was playing, this did not happen as well.
Fortunately I was able to reproduce with debugger, pause and inspect the thread. It was again stuck in
WASAPIDevice::runMixingThread() but this time
sleep_duration was very large and inconsistent between tests. Just initializing this value to 0 seems to resolve this problem.
I can not 100% confirm that it hits
goto stop_thread though. just adding
printf calls to check this in any way seems to cause issues where playback just doesn't start at all...
sleep_duration varies that much, because it depends strictly on the buffer size reported by WASAPI. Could you tell me what you mean by very large? Just approximately, in order of magnitude would be enough. If you say setting it to 0 resolves the problem, maybe we just need to limit it to 20 ms maximum or so.
In #94994#1307987, @neXyon wrote:
sleep_durationvaries that much, because it depends strictly on the buffer size reported by WASAPI. Could you tell me what you mean by very large? Just approximately, in order of magnitude would be enough. If you say setting it to 0 resolves the problem, maybe we just need to limit it to 20 ms maximum or so.
I meant to say that it was probably left uninitialized, because I think it hit
goto stop_thread before. But then
result != AUDCLNT_E_DEVICE_INVALIDATED would had to be false and thread did not actually stop but went to sleep.
So by wery large, I meant some random number like 42314783214688
This issue was referenced by
Nice catch! It indeed is uninitialized when the thread starts and the device fails to initialize immediately! I pushed a change that hopefully fixes this bug. @sketchysquirrel please feel free to reopen this, if the bug is not gone in the next release. Same for @iss if you encounter this again with that fix applied.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?