Je rencontre un problème avec DT 2.2.1 installé sur une Mint 18 depuis le ppa de pmjdebruijn.
Les fichiers xmp ne sont pas créés automatiquement et un clic sur le bouton « sauver en xmp » ne fait rien. L’option de création automatique des xmp est bien activée, j’ai essayé de décocher et recocher, pas mieux. Je n’ai rien vu dans le darktablerc qui ressemblerait à cette option.
Le bouton « charger » ouvre bien la boite de dialogue de chargement.
Si l’un de vous a une idée, je suis preneur. Merci d’avance.
C’est effectivement le premier truc auquel j’avais pensé, mais même pas.
Du coup je viens de faire des tests :
[list]
[]pour les dossiers que je n’avais jamais importé, les xmp se crééent à l’importation, si je les supprime je peux les recréer avec le bouton « sauver en xmp »
[]pour les dossiers déjà importés et présents dans la bibliothèque, les xmp n’ont pas a été créés (sauf pour 1 dossier) et pas moyen de recréer les xmp à partir du bouton.
[/list]
Donc la création automatique fonctionne pour les nouveaux dossiers. A part le bouton « sauver en xmp », existe il un autre moyen d’extraire les données de la db et de les écrire dans un xmp ?
Pour préciser, parce que c’est un peu confus -y compris pour moi.
Les dossiers avec les xmp présents ont été importés avec la version de DT qui était packagée dans Mint 17.3. C’était surtout pour faire des tests sur quelques lots de photos. J’ai décidé de basculer complétement vers DT aux alentours de Noël (merci la news sur linuxfr), donc upgrade vers Mint 18, suppression du .config/darktable pour repartir de zéro et installation de la version de DT packagée dans le ppa de pmjdebruijn, refonte de ma façon d’importer / trier / classer / backuper… Trop de modifs en trop peu de temps pour vraiment savoir ce qu’il s’est passé.
J’ai l’impression que le problème de non création des xmp s’est posé avec la version 2.2.0 qui a très vite été mise à jour en 2.2.1. Entre deux j’ai commencé à traiter sérieusement un certain nombre de photos, et en cas de problème ça m’embêterait de perdre l’historique. Rien d’insurmontable, à peu près une cinquantaine de photos, mais si un moyen existe, je suis preneur !
Surtout avant de continuer plus avant je veux m’assurer que le problème est réglé, donc si vous avez des idées de tests complémentaires à effectuer.
L’option est belle et bien cochée, ce que je ne comprends vraiment pas c’est que cela fonctionne pour les dossiers jamais encore importés, mais pour ceux que j’ai déjà importé.
Je n’ai pas vraiment d’idée… Je cherche un peu au hasard : est-ce que tu utilises les copies locales ?
Extrait du manuel :
Si c’est le cas, les copies locales manipulent les fichiers XMP ; c’est peut être une piste. Voir le manuel § 2.2.9
[hr]
… Et aussi § 2.3.6.1, resync copie locale
Je viens de tester avec la version « master » et je n’ai pas ce problème. J’ai ouvert une image non modifiée depuis 2014, j’ai édité l’image et après avoir quitté darkroom mon .xmp est mis à jours.
Ensuite tu peux tenter de réimporter les photos (fais un A/M de darktable avant pour forcer l’écriture et la fermeture/ouverture de la BdD). Ensuite tu peux faire un test d’enregistrement d’un XMP et si tout va bien tu peux recharger les informations de traitement à partir des fichiers jpeg.
J’ai pas mieux à te proposer. C’est juste du bricolage pour sauver les meubles, mais ça ne solutionne pas le bug : on n’a pas trouvé la cause.
Merci à tous pour les recherches et les tests que vous avez fait, je viens de trouver après quelques mois. Le fait que les xmp s’écrivent parfois aléatoirement m’avait beaucoup freiné dans une bascule complète vers DT et m’en avait écarté. Enfin bref, par pur hasard, j’ai enfin trouvé !
La cause est capilotractée : le nom du propriétaire enregistré dans mon 5D et donc dans les Exif comporte un tréma, qui passait comme un caractère inconnu. Juste en modifiant le « creator » dans le metadata editor fait que les xmp s’écrivent sans problèmes ! Merci les problèmes d’encodage… Problème qui ne se posait pas avec les RAW issues de mon G10, le nom du propriétaire n’étant pas renseigné.
Bravo pour la résolution ! Ça pourra peut-être servir un jour à quelqu’un. D’ailleurs ce cas devrait être rapporté au développeurs pour qu’ils intègrent un correctif dans le code du module d’exportation.
