Freeze à l'ouverture de certaines pellicules dans la table lumineuse (3.1.0~git1731)

[lilbenny972]

Salut les gars, je créée ce thread pour remonter un bug assez gênant rencontré à l'instant sur darktable version dev 3.1.0~git1731.17f84f9c1.

Suite à la mise à jour de darktable, une mise à jour de la base de données m'a été proposée, mise à jour que j'ai accepté. Cependant, à l'ouverture de la table lumineuse, en essayant d'ouvrir certaines pellicules, darktable freeze tout simplement. Je suis obligé de fermer à la sauvage car la fenêtre devient totalement inactive.

En passant par le terminal, au moment d'ouvrir la même pellicule qui a tout fait planter, je retrouve ce message en dernier :

Code :

[image_cache_allocate] failed to open image 21416 from database: no more rows available

Cela me fait le coup avec 5-6 pellicules. Point commun à ces pellicules, pour certaines images, j'avais créé des clones  afin d'y appliquer d'autres traitements et avoir plusieurs versions d'une image ( 1 en couleur, 1 en N&B, etc...)

Je précise également que réinitialiser l'affichage de la table lumineuse pour afficher l'ensemble des images fait également planter darktable.
En effaçant le fichier library.db et en réimportant spécifiquement les pellicules qui posaient problème, je récupère l'accès aux photos, les clones sont eux aussi visibles, mais sans aucun traitement, ce qui invalide cette solution.

J'ai donc l'impression qu'il s'est passé quelque chose avec la base de données et mes "clones" d'image auxquels d'autres traitements sont appliqués. Je suis un peu coincé du coup, entre perdre mes 10 aines de traitements pour retrouver accès à ma collection de photos dans la table lumineuse, sans savoir si d'autres pellicules sont elles-aussi concernées ( ce qui est certainement le cas), ou continuer à importer des photos sur une base de données qui est certainenement corrompue, en n'ayant plus la possiblité d'afficher l'intégralité de mes images dans la table lumineuse...
D'ailleurs, réimporter une version plus ancienne du fichier library.db ne solutionne pas le problème, d'autant plus que je ne sais pas si le bug à été introduit par la dernière version de développement, ou si elle date d'avant . Dans tous les cas, la dernière version propose de mettre à jour la base de données. Dernière précision qui pourrait être utile, la dernière fois que j'ai importé / traité des images remonte à lundi 18 mai environ. Et je ne crois pas avoir eu ce bug, vu l'ampleur , cela m'aurait certainement interpellé.

J'espère que vous pourrez m'aider, j'ai une copie des fichiers RAW+XMP " avant bug" sur un NAS au cas où.

PS: J'ai aussi remarqué qu'en réimportant un dossier complet contenant des pellicules nommées sous ce format : YYYYMMDD ( par exemple: 2020/20200502_photos_tata_Juju, l'ordre alphabétique et numérique n'était pas respecté. Est-ce un comportement normal? ( cette question est secondaire, dans le cas ou je serais obligé de passer par une réimportation complète de mes photos...)

Je suis sous Ubuntu 20.04 et utilise darktable version dev depuis un sacré moment déjà.

[nicoauffray]

Déjà, utiliser une version de développement, c'est obligatoirement prendre des risques et donc s'attendre à des déconvenues de ce genre. C'est tout le principe d'une version de développement : faire évoluer le logiciel et voir ensuite les résultats. Là, tu demande si c'est normal alors qu'il est évident que ce que tu décrit ne l'est pas. Par ailleurs, tu viens de compiler une version toute fraîche donc il n'y a pas encore eu de retour. Et idéalement, les rapports de "bugs" de ce genre sont préférables à poster sur Github (en anglais, avec l'aide de Deepl si besoin) ou plus de développeurs pourront le voir et éventuellement te réponde.

La seule manière d'éviter ce genre de situation reste d'utiliser une version dite stable.

Après, en attendant, le mieux serait que tu utilise une version de développement plus ancienne où tu n'avais pas ce problème (et donc restaurer ta base de données avant mise à jour). Tu utilise la master via le dépôt OpenSuse ou tu compiles ?

---

Ceci étant dit, vu le commit que tu cite, je ne vois que cette PR (pull request) ajoutée hier en master qui pourrait en être à l'origine (éventuellement) : https://github.com/darktable-org/darktable/pull/5134. Le développeur étant français mais ne passant pas souvent sur le forum, je viens de l'inviter à venir te lire.

[nicoauffray]

@lilbenny972 : je viens de voir qu'il y a eu un correctif autour de ce genre de choses ajouté ce matin par @phweyland. Pas sûr mais peut-être lié. Fais une mise à jour vers la dernière master (git1736) et refait le test. C'est peut-être déjà résolu.

[jpverrue]

Oui, je confirme, suite à mon travail puis au travail de Philippe, ce bug est apparu. Philippe l'a corrigé hier soir après quelques échanges ;-) et Pascal l'a fusionné ce matin.

[lilbenny972]

Oui, bien sûr, la version developpement est à considérer comme version instable, (même si 99% du temps c'est raisonnablement stable, c'est pas comme si vous faisiez du travail de sagouin    ) et je fais les mises à jour en toute connaissance de cause.
L'objectif était effectivement de vous remonter un bug, même si j'aurais pu le remonter sur github pour une reconnaissance encore plus rapide ( bon en même temps entre mon post et la résolution du bug a priori, il s'est passé moins de 24h...    ).

Dès que je rentre, je fais la mise à jour ( par les dépôts Opensuse @nicoauffray) et vous confirme la résolution du bug!

@nicoauffray, lorsque je demandais si le comportement lors de l'importation de dossiers multiples était "normal", c'était pour souligner le petit changement d'ordre dans la liste des pellicules , en comparaison avec l'ordre qui me semblerait "logique ou naturel". Je cherchais à savoir si c'était une autre méthode de tri qui était implémentée lors de l'importation des dossiers, ou si c'était aussi éventuellement un petit bug qui se serait glissé. Cela ne gêne absolument pas l'affichage des images dans la table lumineuse, selon le critère de tri que l'on veut.

Pour finir, depuis les dernières mises à jour, j'ai quand même la sensation que la table lumineuse est vraiment plus rapide dans l'affichage de multitude d'images ( enfin, jusqu'à ce que j'aie eu mon bug ).
C'est noté pour github, je vais créer un compte pour pouvoir remonter ce genre de bug. Je pensais que la section développement de ce forum pouvait servir aussi à remonter ce genre de bug, surtout que pas mal des développeurs très actifs sont également dessus.

[phweyland]

Bonjour,
j'ai essayé de reproduire le problème...
Avec la version 3.1.0+1209~gec7d533cc je m'assure que j'ai des clones (créés soit en darkroom soit en lighttable).
Je mets à jour à la version 3.1.0+1727~gb9ab4c8a9, je ne reproduis pas les problèmes décrits ci-dessus...
EDIT: idem en migrant vers 3.1.0+1736~ga6fc3dc68

Peut-être que quelques précisions aideraient ...
- version de dt avant migration ?
- façon de créer les clones
- est-ce qu'il y a des clones supprimés
- dans quel ordre sont les images d'origine, nom de fichier, étoiles, ...
- filtres ...

j'oubliais, le fichier log complet (darktable -d all en console);

[lilbenny972]

Bonjour,

Je joins ici un LOG mais également une vidéo de ce que je fais exactement, en MP ( pour des raisons de confidentialité je ne peux mettre en partage public les images qui s'affichent.)

- Je n'ai pas d'idée exacte de la dernière version utilisée avant la migration, la dernière fois ou je suis quasiment sur que tout fonctionnait, j'étais au minimum sur la version darktable 3.1.0~git1537.10f133ddd ( selon les derniers JPEG que j'ai exporté)

- Je créée les clones généralement en utilisant le module gestion des clones dans la chambre noire (darktable)
- Oui, cela m'arrive de supprimer certains clones, toujours dans la chambre noire généralement.
- Pour les filtres de tri, j'utilise le tri par date/heure, l'affichage de toutes les images sauf celles rejetées ( que je supprime lorsque j'ai fini de traiter l'ensemble de ma pellicule, donc en toute fin de travail). J'utilise le classement par étoiles également, toutes les images classées en dessous de 2 étoiles sont systématiquement rejetées par la suite, et supprimées en fin de travail.
- J'utilise également les pastilles couleurs, généralement la pastille rouge pour marquer les photos en noir & blanc
- J'ajoute également des tags à mes photos, afin de les retrouver plus facilement.
- Les noms de fichiers respectent la nomenclature suivante : 

$(YEAR)/$(YEAR)$(MONTH)$(DAY)_$(JOBCODE) pour le nommage de la pellicule

$(EXIF_YEAR)$(EXIF_MONTH)$(EXIF_DAY)_$(EXIF_HOUR)$(EXIF_MINUTE)$(EXIF_SECOND)_$(SEQUENCE).$(FILE_EXTENSION) pour le nommage des fichiers.

Voici le fichier LOG: LOGFILE

J'espère avoir répondu avec suffisamment de détails!

[phweyland]

Voilà beaucoup d'information à digérer. Merci. Je reviens vers vous dès que j'ai du nouveau.
J'ai jeté un coup d’œil sur la vidéo, c'est une excellente idée, mais j'ai un peu de mal à décoder. Vous avez un écran de bonne définition mais la vidéo est en 720p, ce qui est un peu limite.

[phweyland]

Est-ce que les images avec les id 21416 ou 21376 existent dans la table "images" de la base de donnée ?
D'après le message d'erreur il semble que non. Peut-être un début de piste.
EDIT: Sur la vidéo, position 9:00", quel est l'id correspondant au message d'erreur ? Et celui indiqué dans information de l'image ? Sont-ce les mêmes ? Est-ce que le dernier existe dans la table "images" ?

[lilbenny972]

Est-ce que les images avec les id 21416  ou 21376 existent dans la table "images" de la base de donnée ?
D'après le message d'erreur il semble que non. Peut-être un début de piste.
EDIT: Sur la vidéo, position 9:00", quel est l'id correspondant au message d'erreur ? Et celui indiqué dans information de l'image ? Sont-ce les mêmes ? Est-ce que le dernier existe dans la table "images" ?

Dans la vidéo ainsi que dans mon logiciel, l'image id de la photo en noir et blanc ( le clone) est 21453, avec un group id étant de 21416. L'image ID de la photo originale est 21417 et le group ID est également 21416. Par contre je n'ai pas de photo ayant pour Image ID 21416. C'est probablement la photo originale que j'ai supprimé une fois qu'un edit sur un clone me semblait satisfaisant.
Autrement, oui les ID apparaissant dans la vidéo sont ceux que je vois encore, et ils semblent correspondre aux informations de l'image.