Anim Player Stops working In Video Sequence Editor #94994

New Issue

Joel · 2022-01-18T00:23:52+01:00

Joel commented

2022-01-18 00:23:52 +01:00

System Information
Operating system: Windows 10
Graphics card: GTX 1070

Blender Version
Broken: 3.0.0
Worked: 2.9

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.

**System Information** Operating system: Windows 10 Graphics card: GTX 1070 **Blender Version** Broken: 3.0.0 Worked: 2.9 **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.

Joel commented

2022-01-18 00:23:52 +01:00

Added subscriber: @sketchysquirrel

Richard Antalik commented

2022-01-18 17:43:34 +01:00

Added subscriber: @iss

Richard Antalik commented

2022-01-18 17:43:34 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2022-01-18 17:43:34 +01:00

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/.

Joel commented

2022-01-19 03:46:38 +01:00

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.

Richard Antalik commented

2022-01-19 17:12:50 +01:00

Added subscriber: @neXyon

Richard Antalik commented

2022-01-19 17:12:50 +01:00

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.

CC @neXyon

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. CC @neXyon

Richard Antalik commented

2022-01-19 17:13:07 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Joerg Mueller commented

2022-01-21 14:15:36 +01:00

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?

Richard Antalik commented

2022-01-21 19:59:55 +01:00

Ok that's weird, I can't reproduce it now. I will keep this in mind and check when this happens next time

Richard Antalik commented

2022-02-06 05:02:45 +01:00

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 WASAPIDevice::runMixingThread(), calls 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.

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 `WASAPIDevice::runMixingThread()`, calls `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.

Joerg Mueller commented

2022-02-07 18:40:16 +01:00

Weird, I guess NULL for buffer is okay, since length is 0. That means that buffer_size and 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!

Weird, I guess `NULL` for `buffer` is okay, since `length` is 0. That means that `buffer_size` and `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!

Richard Antalik commented

2022-02-07 19:12:41 +01:00

Yes, buffer_size and 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?

Yes, `buffer_size` and `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?

Joerg Mueller commented

2022-02-07 19:34:41 +01:00

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 m_default_device_changed to 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...

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 `m_default_device_changed` to `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...

Richard Antalik commented

2022-02-14 13:46:21 +01:00

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...

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...

Joerg Mueller commented

2022-02-15 07:22:53 +01:00

Interesting, that 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.

Interesting, that `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.

Richard Antalik commented

2022-02-15 08:58:23 +01:00

In #94994#1307987, @neXyon wrote:
Interesting, that 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.

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

> In #94994#1307987, @neXyon wrote: > Interesting, that `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. 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

blender-admin commented

2022-02-15 20:04:42 +01:00

This issue was referenced by 4782713390

This issue was referenced by 47827133901b1fa5467a7c070db0eb168e87b546

Joerg Mueller commented

2022-02-15 20:05:55 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Joerg Mueller closed this issue

2022-02-15 20:05:55 +01:00

Joerg Mueller self-assigned this 2022-02-15 20:05:55 +01:00

Joerg Mueller commented

2022-02-15 20:07:42 +01:00

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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Anim Player Stops working In Video Sequence Editor #94994