To many events queued about thumbfast HOT 15 CLOSED

Any more details? Were thumbnails working for a few seconds, minutes?
Did you have to hover the timeline a bunch to trigger this?

from thumbfast.

few seconds

from thumbfast.

Does reverting 7d813a9 fix it?

from thumbfast.

No

from thumbfast.

Max is 1000 events, it couldn't possibly be coming from our observed properties, must be some recursion somewhere.
Can you try removing or (rotate == nil and not disabled)? This is the most obvious cause I can think of.

from thumbfast.

Not fix.
And freeze happens before error message.

from thumbfast.

If it's some recursion somewhere, you can try finding it with print(debug.traceback())

from thumbfast.

Reverted until I can reproduce this and figure it out, use the observe-properties branch if you want to take a crack at it.

from thumbfast.

And freeze happens before error message.

Yes, I never saw any error in console but thumbnail just quickliy lost response.

from thumbfast.

@po5 Freezing was introduced by be884c6

from thumbfast.

Weird, surely it's possible to keep the Windows socket open. I'll try booting into Windows.

from thumbfast.

Turns out the pipe just stops responding after we send it 4096 bytes of data. Gotta love Windows.
I'll reopen the file every time we hit 4096 bytes, problem solved and we keep the speedup of reopening a file, most of the time.

from thumbfast.

Should be fixed?

from thumbfast.

Turns out the pipe just stops responding after we send it 4096 bytes of data. Gotta love Windows.

That can also happen on linux/posix if the other end isn't draining the pipe (although PIPE_MAX is typically higher than 4KiB, at least on linux). Or are you saying it stops after sending 4KiB in total - regardless of whether the other end drained it or not?

from thumbfast.

Total, the pipe seems to never clear. I tried different opening modes.
If you know a way to get it to work, that would obviously be nice.

from thumbfast.