[solved] ART crashes quite often

I’m also with Manjaro (Xfce) and so I use the compilations with the PKGBUILD from AUR.
I also sometimes have crashes, I think related to my hardware configuration, dt crashes on its side with OpenCL for some time. An update of my GPU driver seemed to have fixed the problem… but no :face_with_raised_eyebrow:
I’d like to investigate further but I need the debug version.

To get the debug version I think you just have to modify the PKGBUILD before starting the compilation. The GUI pamac allows this.
If I understand correctly what is said on rawpedia, i just have to add this line in the cmake of the PKGBUILD
-DCACHE_NAME_SUFFIX="5-dev"
Am I wrong?

I get the same behavior on my system.

For a debug build you have to change the line -DCMAKE_BUILD_TYPE=Release to -DCMAKE_BUILD_TYPE=debug in the PKGBUILD file.

Search for CMAKE_BUILD_TYPE on this rawpedia page for more info: Linux - RawPedia

@agriggio If you cannot reproduce this problem I can try to build a debug version and see if that crashes. If so, I can get you a stacktrace. Please let me know if you want me to do that.

I still can’t reproduce. However, that crazy clicking surely can cause troubles, as it will continuously trigger the image processing pipeline. I have therefore changed the behaviour so that after a click to pick the wb, the mouse pointer goes back to “normal”, and you have to re-click on the “pick” button (or press “shift-w”) to select another spot. That should at least make it less likely to trigger this behaviour by accident…

Do you have NR active with chrominance automatic? This introduces a lot of lag in here.

See various settings here. I’m clicking 8 times each as fast as I change cursor direction:

I’m not seeing art freezing here. It does become slow, but it never freezes. Anyway I’ve changed the behaviour now, to at least hide this under the rug :slight_smile:

I would guess this is what he meant by almost like frozen.

@agriggio I just build a debug version for 1.16.3. and could not reproduce the crash.

The slow-down when clicking the white balance eye-dropper tool repeatedly is (of course?) bigger when there are more modules active. I think that your solution is a good work-around.
I’m not familiar with the ART code base but is it possible to discard ‘old’ (not yet processed) WB updates if there is a newer one?

It is possible to interrupt early, but only at certain sync points. If you click fast enough the updates will queue up anyway eventually…

Thanks for your explanation and keep up the good work for this amazing piece of software!

I have had similar crashes but without the Panasonic. In the end it turned out that it was my fault.

Closing ART and deleting ~/.cache/ART, then restarting ART solved my problems. Something went wrong in the cache and now everything works “honky-dory”.

There’s another notable difference between art-rawconverter and art-rawconverter-bin:
art-rawconverter will use the libs shipped with your distribution (e.g. Arch or Manjaro), while art-rawconverter-bin brings all required libs with versions defined by Alberto.

This especially means that art-rawconverter will not make use of libraw unless you manually switch to libraw-git as ART requires libraw 0.21 which has not been released yet. In this case ART will use the vendored dcraw.c which might result in strange behaviour - ART is going to switch to libraw for a reason. :wink:

1 Like

Unfortunately, I understand too little of the details mentioned. But may I conclude that it is better to install the -bin version? Is this generally true in the AUR?

Yes, that’s what I mean: everything becomes very slow, I can’t select any new places with the picker for a few seconds, but the mouse can still be moved and at the bottom you can see “Processing image” with the yellowish bar, which sometimes stands still, sometimes moves to the right. And when it arrives to the right, ART rages normally again.
Now I switched off the noise reduction: Now the delay is only half a sec., if Sharpening, Noise reduction, Impulse noise reduction and Defringe are switched on, the delay is quite 8 sec. or more.

@agriggio I don’t think you need to change anything, this behavior is normal.

I am very happy that ART with the -bin version is stable after all.
Thank you all very much.

1 Like

As the -bin version seems to fix the issues for you, in your case it is better to use the -bin version. This might not be the case for other people - generally speaking there is no “better” in such cases, it’s just different with different pros and cons.

1 Like

Why not reach out to the aur packager?

Thats why i joined the discusssion in the first place. :wink:

I’m maintainer of art-rawconverter and co-maintainer of art-rawconverter-bin

1 Like

@guzzisti
For information the construction of art-rawconverter-bin is not possible anymore, the ART-1.16.3-linux64.tar.xz archive is not on agriggio / ART / Downloads — Bitbucket

Construction de art-rawconverter-bin...
==> Création du paquet art-rawconverter-bin 1.16.3-1 (mer. 02 nov. 2022 11:15:27)
==> Vérification des dépendances pour l’exécution…
==> Vérification des dépendances pour la compilation…
==> Récupération des sources…
  -> Téléchargement de art-rawconverter-1.16.3.tar.xz…
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0 53021    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
==> ERREUR : Erreur lors du téléchargement de https://bitbucket.org/agriggio/art/downloads/ART-1.16.3-linux64.tar.xz
    Abandon…
Impossible de construire art-rawconverter-bin

That’s because we have 1.16.4 now – sorry for the confusion! (ping @guzzisti – I should have notified you about that indeed…)

Yes, that’s what I understood, I wanted to test it for my problem