Possible buggy behavior with changing content timing?

[Ryan Gallagher]

"Recent" versions of DOM seem to be doing this for me on my home Windows 10 machine. Definitely .19 and .20

Will create a DCP and pull in about 35 still images for our pre-roll walkin deck. Everything is normal until you try to adjust the timing on the whole block of 35. Highlight everything, and moving timing from my default of 5s to 10+ seconds. I aim for these decks to be 10 minutes so the actual time varies between stills and the size of the deck.

The buggy behavior is waiting for DOM to update after that timing change. It used to take "a while" to adjust the timing and update the timeline so you can scrub again. Now it just never seems to get there. I have to save/close and re-open the project and everything works as expected.

I also tried "playing" the DCP on DOM after giving it a good long wait to update, and it will try, but it keeps resetting to 0:00:00 after only a few seconds and just restarting constantly, never getting past the first defaut 5 second slide that I changed the timing on.

One nuance is this is an older dual proc 12 core xenon machine, 3.86ghz. The timing update process seems to be single-threaded and part of the long wait, but it used to at least complete and be preview-able again without a reload. It really shouldn't take longer to update the content timing than it does to render the DCP entirely?

Work-around exists, but it is not something I used to have to do. Let me know if there are any further details I can share to narrow it down.

Our Windows 11 laptop at work does not seem to have this problem, although there is still quite a single-threaded wait to do that timing update before the application becomes usable again. However it may be on a prior DOM version, I'll have to check tomorrow.

[carl]

It's weird that it never gets there, but I just tested it on some fairly small images and it does seem slow. Loading them also seems to be pretty flickery and slow on Windows (at least on a quite slow VM that I'm testing on).

I'll have a look and see what can be done to speed it up.

I added a couple of bugs to the tracker to keep an eye on them: https://dcpomatic.com/bugs/view.php?id=3063 and https://dcpomatic.com/bugs/view.php?id=3064

[Ryan Gallagher]

Yeah I think it's a non issue with one or two images, but when you have a whack ton of them whatever steps it's doing for the timing change seem excessively slow. I can watch the core on the process monitor, and it does calm down and act like it's "done", but the UI never comes back to a usable state, at least not in the amount of time I'm willing to wait for it without resorting to my workaround.

My image sources are always 1080p JPGs, not dealing with particularly oversized files.

Thanks for digging into it.

[Carsten]

Wasn't there a recent change to the 'select multiple' functionality ? I remember a discussion here.