Film strip marker for image which is being processed is shown for more than one image

[horazont]

Is there an existing issue for this?

• I checked and did not find my issue in the already reported ones

Describe the bug

The film strip marks the image which is currently being edited with a black arrow and by highlighting it:

However, this marking is applied to multiple images in the film strip. This is quite confusing, because the highlight is very similar to the selection highlight. That makes it unclear which images an action such as R or number key (rating) applies to.

Steps to reproduce

1. Navigate to a collection with a non-trivial amount of images (20+?)
2. Open an image in the darkroom
3. Scroll through the film strip

Expected behavior

Exactly one image should be marked as being processed

Logfile | Screenshot | Screencast

Screen cast: https://github.com/user-attachments/assets/fd88f8b6-1406-4c72-b004-80211f494bee (I took the screen cast with a self-compiled version, but the same happens on 5.2.1 from Debian as reported)

-d common log file is at foo.log, but I suspect that it won't contain anything useful. If there's any more useful log for me to provide, let me know.

Commit

No response

Where did you obtain darktable from?

Debian repositories

darktable version

5.2.1

What OS are you using?

Linux

What is the version of your OS?

Debian testing

Describe your system

No response

Are you using OpenCL GPU in darktable?

No

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

Can you reproduce with another darktable version(s)?

Also affects a self-compiled darktable (5.3.0+888~g0224217809-dirty, the -dirty is only submodule commits (lua-scripts and rawspeed)).

Is the issue still present using an empty/new config-dir (e.g. start darktable with --configdir "/tmp")?

Yes, I started Darktable 5.2.1 (from Debian) using export XDG_CONFIG_HOME=/tmp/dt-test4/config XDG_DATA_HOME=/tmp/dt-test4/data and it has the same behaviour.

[TurboGit]

Never seen that, really strange indeed. If you have a definite reproducer, please write it there. TIA.

[vtyrtov]

Indeed, the problem is reproduced with 20+ images in filmstrip.

[horazont]

I can reproduce it 100% with the described procedure.

It looks to me as if the distance between the markers is exactly the amount of items visible in the film strip. So it seems as if the list item widget is somehow being reused without resetting the "this is the currently processed image" flag.

So you need enough images so that the film strip is longer than fits on one page of your screen.

[TurboGit]

I can reproduce it 100% with the described procedure.

It looks to me as if the distance between the markers is exactly the amount of items visible in the film strip. So it seems as if the list item widget is somehow being reused without resetting the "this is the currently processed image" flag.

So you need enough images so that the film strip is longer than fits on one page of your screen.

That's a good hint!

[TurboGit]

@vtyrtov : Are you looking at this for 5.4? I won't have time on my side.

[vtyrtov]

@TurboGit, I can handle it.

[TurboGit]

Thanks!