Darktable 3.0 ne démarre plus

[poulouseaweed]

bonjour,
mon Darktable a crashé en ouvrant un répertoire de photos. Maintenant à chaque tentative de démarrage,
je reçois le message suivant :

que se passe-t-il?

[nicoauffray]

Bonsoir,

Un problème dont il existe la réponse sur plusieurs fils du forum. Une recherche avec les mots 'database lock' par exemple te donnerait la réponse... Voir notamment ce fil : https://forums.darktable.fr/showthread.p...abase+lock

Et il y en d'autres déjà expliquant ce problème, pourquoi il intervient et comment le régler.

[poulouseaweed]

Bonsoir,

Un problème dont il existe la réponse sur plusieurs fils du forum. Une recherche avec les mots 'database lock' par exemple te donnerait la réponse... Voir notamment ce fil : https://forums.darktable.fr/showthread.p...abase+lock

Et il y en d'autres déjà expliquant ce problème, pourquoi il intervient et comment le régler.

Merci beaucoup, j'ai viré data.db.lock et library.db.lock et tout est rentré dans l'ordre. !

[senpai]

BRAVO,

Est ce que c'est possible d'éditer le post et ajouter [RESOLU] devant le titre du sujet?
[RESOLU] Darktable 3.0 ne démarre plus

Merci

[manu]

C'est un sujet hyper récurrent effectivement et on peut se demander pourquoi dt n'identifie pas tout seul au lancement qu'un lock reste posé, résidu d'une précédente exécution crashée et qu'il peut le virer lui-même.
Ce lock est juste un fichier contenant le PID du process dt. Sur une même session utilisateur, la probabilité que ce PID se retrouve deux fois de suite est quasi nulle, et presque aussi peu sur deux sessions utilisateurs différentes (dans le cas où dt avait été planté lors d'une session et que l'utilisateur l'ait relancé après un logout ou reboot).

Bien sûr, on peut aller supprimer ces locks dans le répertoire caché (encore faut-il le savoir et savoir le faire).
J'ai écrit un script bash (linux) de lancement de dt qui, si un lock existe à cause d'un précédent plantage de dt, vérifie que le process n'est plus actif et dans ce cas fait le ménage tout seul avant de lancer dt. Autrement affiche un pop-up pour informer qu'une instance dt est toujours active. Accessoirement, ayant le cache sur un disque secondaire, il vérifie que le disque est bien monté et le spécifie dans l'option --cachedir de lancement de dt.

[Atriaze]

Voila un petit script qui devrait être dans "les ressources " du site. :o)

[manu]

Voila un petit script qui devrait être dans "les ressources " du site.  :o)

Peut-être..., sinon ici en attendant, suppose Linux (écrit et testé sur Ubuntu + zenity) et la personnalisation de deux variables indiquées dans le code.

[patrick L]

Bonsoir,

Un problème dont il existe la réponse sur plusieurs fils du forum. Une recherche avec les mots 'database lock' par exemple te donnerait la réponse... Voir notamment ce fil : https://forums.darktable.fr/showthread.p...abase+lock

Et il y en d'autres déjà expliquant ce problème, pourquoi il intervient et comment le régler.

Merci beaucoup, j'ai viré data.db.lock et library.db.lock et tout est rentré dans l'ordre. !

attention  ça peut être dangereux.    ça m'arrive d'avoir le message d'erreur avec affichage du numero de processus.  Si c'est un truc genre 125853 c'est utilisateur.   Si c'est comme vous 1141  faut vérifier qu'aucune transaction est pendante.   


une transaction c'est fait  contre les crashs  et pour éviter de casser les bases de données qui fonctionnent avec des identifiants pour relier les groupes de données entre eux.   Des fois ca arrive des plantages en cours de travail et alors en redémarrant on  retombe sur la collection au démarrage.    alors faut recharger le dossier d'importation.    c'est que darktable voit la transaction en cours et pour rester stable vire toutes les opérations dans la transaction.   

généralement le fait d'avoir un .lock   ca veut dire   un probleme du genre.    et donc que l'annulation des manips n'a pas marché.    des fois y a pas de conséquence.   D'autres si au démarrage on a viré l'alerte    et qu'il y a un probleme  ça devient très vite ennuyeux.  si le numéro de pid    est supprimé avec le fichier .lock va savoir le processus qui a planté.    alors seule solution   de tout vérifier dans les tables de la base de données.    et c'est plutôt  stressant.   Et  souvent on annule les transactions et on  recharge toutes les photos.

pour faire la suppression  des .lock   faut que le script vérifie que les bases de données  data.db  ni library.db   n'aient de transactions en cours... et si c'est pas le cas  faut vérifier si aucune  transaction en écriture et que le script  vérifie les n° de version   des tables.   et ça c'est lire des journaux. Également  faire un backup de la base de données  format sql   ensuite lister les updates   et sur les tables liées vérifier   que les tables liées soient  elles aussi modifiées).


les transactions c'est simple.    dans le fichier  image_2020-01-26.raw    vous demandez de modifier  le niveau relatif  blanc  à  15  au lieu de 25.     et en meme temps vous modifiez dans exposition    exposition  +2ev    au lieu de +3ev.   

ensuite le programme se plante   et alors la premiere est mise à jour    et erreur sur la seconde.       la transaction   liste les modifis faites...   comme ca    on sait revenir à l'etat initial.

[pascal]

> Si c'est un truc genre 125853 c'est utilisateur. Si c'est comme vous 1141 faut vérifier qu'aucune transaction est pendante.

Je ne pense pas que le numéro fasse une différence. C'est le pid (process id) du l'instance de darktable et ça peut être n'importe quel nombre mais cela ne comporte aucune sémantique.