Bonjour,
J’ai 2 machines : 1 équipée d’un i3 sandy bridge, l’autre 1 d’un pentium Haswell (c’est a priori la seule différence de configuration). Je suis sous Linux Mint sur les 2. Alors que sur la 1ère, DT fonctionne parfaitement, j’ai un phénomène curieux sur la seconde : je dois attendre 30 secondes montre en main à chaque fois que j’ouvre DT pour que les vignettes s’affichent dans la table lumineuse, et ce quel que soit le nombre des vignettes en question : 3 ou 100, c’est 30 secondes !! Curieusement, passé ce délai précis, l’affichage est alors très rapide ! Et si je change de dossier pendant la session, aucun pb, les nouvelles vignettes s’affichent à une vitesse normale. Tant que je ne ferme pas DT, tout se passe normalement. Si je le ferme et le rouvre, j’ai droit à la même latence de 30 s à l’affichage des vignettes. Mes 2 DTs sont bien sûr réglés de façon identique puisque je ne mets pas mon grain de sel dans les préférences. Ce n’est pas très pénalisant . Un peu énervant quand même… Y aurait-il un réglage que empêcherait cette bizarrerie ?
Merci.
Commence par lancer darktable en console pour voir si quelque chose coince. Tu peux aussi jeter un œil aux paramètres généraux des deux versions que tu as installé. Il y a peut-être une variable mémoire mal configurée. Il reste encore la possibilité que ta base de données se soit un poil corrompue à la création sur ton deuxième pc. Tu pourras en dernier recours la supprimer et relancer sa création. Donnes nous tes retours
Tester en lançant « darktable -d all » pour voir ce qui s’affiche pendant les secondes d’attente. J’ai un comportement similaire avec un lancement assez lent, chez moi c’est l’initialisation d’OpenCL qui prend du temps (une hypothèse serait alors que la machine sur laquelle tu as le soucis a OpenCL et pas l’autre). Il y a peut être moyen d’améliorer ça mais ma solution est de ne pas lancer darktable souvent (c’est à dire de ne pas le fermer souvent !).
Pour l’affichage des vignettes avec du retard, et pire un ralentissement net de dt, sous Mac mon expérience, il peut s’agir d’un branchement USB — je débranche et les vignettes s’affichent et dt arrête de ramer comme un fou.
Merci pour vos réponses. J’ai désinstallé DT autant que j’ai pu (avec « purge »), l’ai réinstallé et, pour autant, le phénomène persiste. J’ai appliqué la méthode de mmoy et il m’a été indiqué que OpenCl n’était pas disponible sur mon système…
En définitive, je pense donc que LA solution de Mmoy est la bonne : faire avec ! 
Pas dramatique donc, d’autant que tout marche nickel par ailleurs.
Non la solution de mmoy est aussi de tester avec « darktable -d all » et voir ce qui bloque 
j’ai dû mal me faire comprendre (ou alors c’est moi qui n’ai pas compris…) : j’ai lancé la commande de mmoy et ça ne m’a a priori rien dit de particulier, si ce n’est que opencl n’est pas disponible (« available ») sur mon système . Et j’ai cru comprendre que là n’était pas le problème. Sauf si je me trompe ce qui est parfaitement envisageable 
L’idée est de regarder la sortie de « darktable -d all » et de vérifier ce qu’il fait pendant les 30 secondes. Sachant que dt met dans les 2 à 3 secondes pour se charger il doit essayer quelque chose et bloquer. Donc si tu peux voir la ligne où il bloque (ou où il passe du temps) on avancera…
Je crois comprendre (mais tu as compris que je suis nul en Linux) qu’après avoir chargé DT (DT est à l’écran, mais les vignettes sont vides), une série de plusieurs centaines de blocs d’instructions quasi identiques mais pas tout à fait, de 18 lignes chacune, puis de 11, sont exécutées, dont voici la 1er en copié-collé :
[lighttable] expose took 0,0074 sec
[add_job] 3 | load image 10702 mip 1 | queue: 1 | priority: 0
[add_job] found job already in queue: load image 10702 mip 1 | queue: 1 | priority: 4
[lighttable] image expose took 0,0005 sec
[add_job] 3 | load image 10703 mip 1 | queue: 1 | priority: 0
[add_job] found job already in queue: load image 10703 mip 1 | queue: 1 | priority: 4
[lighttable] image expose took 0,0003 sec
[add_job] 3 | load image 10704 mip 1 | queue: 1 | priority: 0
[add_job] found job already in queue: load image 10704 mip 1 | queue: 1 | priority: 4
[lighttable] image expose took 0,0003 sec
[mipmap_cache] thumbs fill 0,00/512,00 MB (0,00%)
[mipmap_cache] float fill 0/2 slots (0,00%)
[mipmap_cache] full fill 1/2 slots (50,00%)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] thumb | 100,00% | 100,00% | -nan% | 0,00% | 100,00%
[mipmap_cache] float | -nan% | -nan% | -nan% | 0,00% | 0,00%
[mipmap_cache] full | -nan% | -nan% | -nan% | 100,00% | 0,00%
et le dernier :
[lighttable] expose took 0,0091 sec
[lighttable] image expose took 0,0035 sec
[lighttable] image expose took 0,0027 sec
[lighttable] image expose took 0,0041 sec
[mipmap_cache] thumbs fill 0,93/512,00 MB (0,18%)
[mipmap_cache] float fill 0/2 slots (0,00%)
[mipmap_cache] full fill 1/2 slots (50,00%)
[mipmap_cache] level | near match | miss | stand-in | fetches | total rq
[mipmap_cache] thumb | 98,23% | 98,23% | -nan% | 0,00% | 100,00%
[mipmap_cache] float | -nan% | -nan% | -nan% | 0,00% | 0,00%
[mipmap_cache] full | -nan% | -nan% | -nan% | 100,00% | 0,00%
[lighttable] expose took 0,0135 sec
J’espère m’être fait à peu près comprendre. Si ça peux t’inspirer… :-/
Ne serais-ce pas la case à cocher « utilisation du disque pour les miniatures » (préférences → fonctionnement → 2èmez ligne), qui serait décochée sur la machine qui mets très longtemps à afficher les vignettes ? Ou éventuellement la première ligne qui serait à zéro ?
Je crois comprendre (mais tu as compris que je suis nul en Linux) qu’après avoir chargé DT
Non pas après, mais pendant. Dans ta console tu tapes: darktable -d all (comme tu as fait).
Et pendant ce temps tu regardes ce que dt écrit… Les questions sont:
-
est-ce qu’a un moment dt n’écrit plus rien?
-
si c’est le cas que faisait t-il juste avant et juste après?
Si il n arrête pas d’écrire des choses dans la console pendant les 30 secondes alors il faudra chercher ailleurs.
Le chargement proprement dit, qui dure effectivement moins de 3 secondes, se passe sans pb, sans a-coup ni blocage. c’est ensuite que s’écrit dans la console ce que j’ai essayé de décrire, les lignes (plusieurs centaines ou milliers) défilant à toute allure. Et ça dure 30 secondes jusqu’à ce que les vignettes apparaissent toutes d’un coup, au moment où apparaît la dernière ligne que j’ai mentionnée.
Et ça dure 30 secondes jusqu’à ce que les vignettes apparaissent toutes d’un coup, au moment où apparaît la dernière ligne que j’ai mentionnée.
Ok, donc probablement un problème de cache des vignettes. Et donc la question de jpverrue est très pertinente. As-tu regardé de ce coté?
As-tu vérifié les paramètres que j’ai cité dans mon message précédent ?
Envoyé de mon Nexus 10 en utilisant Tapatalk
Eh non, la case est bien cochée et la ligne du dessus sur 1. J’ai même (mais ça n’a donc pas de rapport) essayer en vain de monter la « mémoire à utiliser pour le cache des miniatures » à 512 Mo. C’est d’ailleurs la seule modif que j’ai dû faire dans les réglages d’origine.
Cherche pas, ça vient de là ! 1Mo max pour stocker les vignettes, c’est ridiculement petit. Donc, darktable re-génère à chaque lancement toutes les vignettes dont il a besoin pour l’affichage de la table lumineuse, car il ne peut pas les trouver dans le cache. 512Mo, c’est mieux, mais pas extraordinaire. Personnellement j’ai mis une valeur importante en sachant que de toute façon darktable ne consommera que la place dont il a réellement besoin.
Si les vignettes ne s’affichent pas rapidement quand tu as fixé la taille max du cache à 512Mo, c’est parce qu’elle doivent générées une première fois avant d’être affichées. Normalement si tu n’as pas re-modifié le réglage, lors du second lancement cela devrait aller beaucoup plus vite.
Ce que tu peux faire, c’est de faire générer la totalité des vignettes en traitement batch avec le outil darktable-generate-cache. Tu lances ce programme en mode console ce soir, et demain matin tu trouves toutes tes vignettes générées !
Si ton problème est résolu, peux-tu mettre la mention [Résolu] dans le titre du premier message de la discussion ? Merci d’avance !
Ben non.., désolé. J’ai fait tout ça et même, pour faire bonne mesure, ai mis 1500 Mo pour le cache des miniatures ; ça ne change rien. J’aurais bien aimé mais le contraire m’aurait étonné vu que sur mon autre machine je n’ai aucun problème alors même que je ne lui fait jamais subir le traitement batch en question. Une autre piste, peut-être : un petit souci lors de l’installation de Linux Mint ? Je ne pousserai pas l’abnégation jusqu’à réinstaller le système ! Je préfère faire avec ce (petit) problème à classer parmi les mystères de l’informatique… 
Merci à tous en tout cas de vous être penchés dessus.