[BUG] <title>Color changes to display after performing move operation on files in digikam

[sendtoworthington]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When moving photos to new album location, the color get affected and all photos have a "blue" hue filter applied. Restart of docker container fixes the issue.
Move operation completes normally (digikam functionality is not affected).

Expected Behavior

No affect on display / color. ?vnc issue?

Steps To Reproduce

1. Select photos in existing album
2. Right click and select move photos
3. Select existing or new album to move photos too
4. Observe color change affecting the entire output with blue overlay.

Environment

- OS:Ubuntu
- How docker service was installed: manually

CPU architecture

x86-64

Docker creation

# digikam - Photo Management
  digikam:
    image: ghcr.io/linuxserver/digikam:latest        
    container_name: digikam
    depends_on:
      - mariadb
    volumes:
      - $DOCKERDIR/appdata/digikam:/config
      - /media/Pictures:/config/Pictures
    #ports:
    #  - 3000:3000
    environment:
      <<: *default-tz-puid-pgid
    labels:
      - "traefik.enable=true"
      ## HTTP Routers
      - "traefik.http.routers.digikam-rtr.entrypoints=https"
      - "traefik.http.routers.digikam-rtr.rule=Host(`digikam.$DOMAINNAME0`)"
      ## HTTP Services
      - "traefik.http.routers.digikam-rtr.service=digikam-svc"
      - "traefik.http.services.digikam-svc.loadbalancer.server.port=3000"

Container logs

[migrations] started
[migrations] no migrations found
usermod: no changes
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
[custom-init] No custom files found, skipping...
which: no nvidia-smi in (/command:/lsiopy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
[ls.io-init] done.
Openbox-Message: Failed to open the display from the DISPLAY environment variable.
2024/10/01 14:25:25 [warn] 183#183: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 o
r types_hash_bucket_size: 64; ignoring types_hash_bucket_size
_XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.
_XSERVTransmkdir: ERROR: Cannot create /tmp/.X11-unix
_XSERVTransSocketUNIXCreateListener: mkdir(/tmp/.X11-unix) failed, errno = 28

Xvnc KasmVNC 1.2.0 - built Sep 29 2024 04:26:07
Copyright (C) 1999-2018 KasmVNC Team and many others (see README.me)
See http://kasmweb.com for information on KasmVNC.
Underlying X server release 12014000, The X.Org Foundation

19
which: no nvidia-smi in (/command:/lsiopy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
Obt-Message: Xinerama extension is not present on the server
 2024-10-01 14:25:38,634 [INFO] websocket 0: got client connection from 127.0.0.1
 2024-10-01 14:25:38,682 [PRIO] Connections: accepted: @67.184.250.174_1727810738.634988::websocket
 2024-10-01 15:03:51,836 [PRIO] Connections: closed: @67.184.250.174_1727810738.634988::websocket (Clean disconnection)
 2024-10-01 15:06:26,995 [INFO] websocket 1: got client connection from 127.0.0.1
 2024-10-01 15:06:27,023 [PRIO] Connections: accepted: @67.184.250.174_1727813186.996069::websocket
 2024-10-01 15:06:58,883 [PRIO] Connections: closed: @67.184.250.174_1727813186.996069::websocket (Clean disconnection)
 2024-10-01 15:06:59,814 [INFO] websocket 2: got client connection from 127.0.0.1
 2024-10-01 15:06:59,858 [PRIO] Connections: accepted: @67.184.250.174_1727813219.815038::websocket

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[j0nnymoe]

Check the display settings of kasm, might just be setting there.

[sendtoworthington]

Tried that already. Every setting option, no go. Went to a different computer and same thing there. I reached out to digikam, they report no issues in their end and suggest it is vnc issue. Digikam would have no effect on the display output. Looking for any thoughts here on how to triage this...

…

-----Original Message----- From: j0nnymoe ***@***.***> To: linuxserver/docker-digikam ***@***.***> Cc: sendtoworthington ***@***.***>, Author ***@***.***> Sent: Tue, 01 Oct 2024 3:15 PM Subject: Re: [linuxserver/docker-digikam] [BUG] <title>Color changes to display after performing move operation on files in digikam (Issue #45) Check the display settings of kasm, might just be setting there.

-- Reply to this email directly or view it on GitHub: #45 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[sendtoworthington]

closing the digikam gui within the kasmvnc and reopening (Right click in the KasmVNC viewer after closing) resolves the issue (i don't need to restart the container itself).

[sendtoworthington]

Dragging the file manually to another album/folder doesn't give the same issue.

[simonmcnair]

Can confirm I have this issue too and it is related to Kasm as a reopen of the application resolves the issue.

[simonmcnair]

Have asked input at Kasm and kde.

kasmtech/workspaces-images#117

[J1fle]

I can confirm having the same issue, but would like to add that it's likely not a KasmVNC issue.
Steps to reproduce the proof for this:

1. Introduce the bad color behaviour as already described before.
2. Pick any image and hit DELETE button, as if you would like to delete the image.
3. A confirmation dialogue popup shows, in which the image is shown with correct colours!

To me, this means that Digikam is showing bad colours in some but not all cases. Had it been bad behaviour from KasmVNC, the error would have been consistent. Right or wrong?