Hello,
Cela fait plus de 3 ans qu’on utilise Mercurial dans les projets GeeXboX (avant on travaillait avec TLA Arch). Néanmoins on a de la peine à se conformer aux nouvelles fonctionnalités. Je souhaite en fait parler des branches. Avec Subversion (par exemple), les branches se présentent sous la forme de répertoires. Ça a le mérite d’être clair mais c’est un peu comme collectionner des copies du dépôt principal. Je n’ai jamais trop aimé cette approche, car personnellement je trouve ça un peu brouillon (ça n’engage que moi).
En parlant de brouillon, je vous invite à consulter cette page http://hg.geexbox.org qui liste tous les dépôts existants sous GeeXboX. Si vous regardez la colonne “Last change”, vous verrez des “3 years ago” par exemple. Autant dire que certains dépôts sont complètement obsolètes aujourd’hui. Et c’est même confus, prenez par exemple “geexbox-v2“. Son nom est devenu absurde avec le temps. Car la dedans vous trouverez nos tentatives foireuses de supporter Freevo ;-). Je vous épargne la description des autres.
Bref, là où je veux en venir c’est que pour faire des branches, on s’y prend à l’ancienne et on clone les dépôts. Je pense donc spécialement à “geexbox-1.2” qui est de loin pas obsolète, car c’est lui qui contient tous les backports (spécialement les corrections de bugs) qui ont permis les versions 1.2.1 à 1.2.4 de GeeXboX. Personnellement il ne me plait pas beaucoup. Toutes les versions 1.2.x devraient être dans le dépôt principal “geexbox“.
Ainsi depuis quelques temps je me suis un peu intéressé aux branches Mercurial. Et c’est sur ce point que je vais m’attarder dans ce billet. Il faut aussi savoir qu’en 2006-2007, une fonctionnalité que je vais présenter ici n’existait pas encore (en tout cas pas sous la même forme). Il n’y a donc pas vraiment de mal d’avoir trainé les bonnes vieilles copies de dépôts pour faire des branches…
Cet intérêt soudain pour les branches m’est venu spécialement depuis les releases de libnfo, libplayer et libvalhalla. Je pense par exemple à avoir des branches pour des éventuels corrections sur les versions 1.0.0. Et surtout, sans faire des copies à l’ancienne.
Les branches nommées (NamedBranches)
Mon but n’est pas d’écrire un tutoriel sur Mercurial. Je vais ainsi essayer d’aller à l’essentiel. Un dépôt peut contenir des “heads” et des branches. Plusieurs “heads” apparaissent quand on commit des changements par rapport à une révision antérieure au “tip“. Ce qui demande donc de faire un “merge” et de le “comitter“.
Par défaut il y a toujours une branche dans chaque dépôt et elle se nomme “default”. Passons directement à la pratique. J’aimerais gérer les corrections de bugs pour libplayer-1.0.0. Admettons que je sois à la racine du dépôt, je créer alors une branche “v1.0” à partir du tag “v1.0.0”.
$ hg update v1.0.0 33 files updated, 0 files merged, 7 files removed, 0 files unresolved $ hg branch v1.0 marked working directory as branch v1.0
A priori j’ai bien une nouvelle branche. Mais voyons ce que dit `hg branch` et `hg branches`.
$ hg branch v1.0 $ hg branches default 1326:cac53e7d727f
Du fait que je n’ai pas “commité” la nouvelle branche, on ne la voit pas dans la liste des branches. Mais la première commande confirme que je suis bien dans la “v1.0” fraichement créée. Je vais donc “commiter” ce changement localement.
$ hg commit -m "new branch v1.0 for bugfix" created new head $ hg branches v1.0 1327:1c0c025f8a73 default 1326:cac53e7d727f (inactive)
Si on désire passer d’une branche à l’autre, c’est très simple.
$ hg update default 40 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg branch default $ hg update v1.0 33 files updated, 0 files merged, 7 files removed, 0 files unresolved $ hg branch v1.0
A noter que s’il y avait des changements non “commités” dans le dépôt, il ne serait pas possible de passer d’une branche à l’autre sans qu’ils soient tous annulés ou “commités”. Mais regardons un peu ce que ça donne avec `hg view`.
On voit deux colonnes bien distinctes qui sont rattachées depuis le “tag” v1.0.0. Un petit tour dans `hg heads` nous montre bien qu’il y en a deux. Et chacun est sur une branche différente.
$ hg heads changeset: 1327:1c0c025f8a73 branch: v1.0 tag: tip parent: 1230:6b3e2fed5f7a user: Mathieu Schroeter <mathieu.schroeter@mycable.ch> date: Sun Jan 10 10:26:50 2010 +0100 summary: new branch v1.0 for bugfix changeset: 1326:cac53e7d727f user: Mathieu Schroeter <mathieu.schroeter@mycable.ch> date: Sat Jan 09 20:34:51 2010 +0100 summary: set winid to 0 by default (fix warning if USE_X11 is not defined)
La branche “default” n’est pas montrée explicitement.
Ce qui m’intéresse maintenant c’est de gérer les corrections de bugs. Cette branche “v1.0” est à considérer pour exister aussi longtemps que tout le dépôt.
Le “cherry picking”
C’est ce qu’on appel le “cherry picking” car seulement quelques “changesets” spécifiques m’intéressent. Les corrections de bugs sont toutes dans la branche “default”. Pour importer ces changements dans le dépôt “v1.0” il y a plusieurs manières de faire. Mais personnellement la majorité des solutions que j’ai trouvé ne me plaisent pas. Et il y a peu de temps, je suis tombé sur une extension officielle (mais non activée par défaut) qui permet de faire exactement ce genre de traitements (et même plus). Elle s’appelle “transplant” et c’est elle que je vais utiliser pour mon exemple.
Il faut commencer par l’activer dans le fichier ~/.hgrc:
[extensions] transplant=
Je vais prendre une partie des corrections intéressantes et les transplanter dans la nouvelle branche.
$ hg transplant 1242 application de 95461fb8613f patching file Makefile Hunk #1 succeeded at 18 with fuzz 1 (offset -3 lines).
Je répète pour chaque “changeset”. On peut spécifier plusieurs “changesets” en les séparant par ‘:’ pour une plage REV1:REV4 par exemple. Mais avec le Mercurial d’Ubuntu j’évite de le faire, simplement parce que l’extension me retourne une exception et un joli traceback Python. En prenant un après l’autre, aucun problème.
Le “screenshot” ci-dessus permet de voir les différents “changesets” appliqués sur la branche “v1.0”.
Pour continuer à travailler sur la devel (branche “default”), rien de plus simple.
$ hg update default 40 files updated, 0 files merged, 0 files removed, 0 files unresolved $ vi Makefile $ hg commit -m "dummy commit" $ hg heads changeset: 1335:55589e41d0eb tag: tip parent: 1326:cac53e7d727f user: Mathieu Schroeter <mathieu.schroeter@mycable.ch> date: Sun Jan 10 13:07:34 2010 +0100 summary: dummy commit changeset: 1334:81c124600c6b branch: v1.0 user: Mathieu Schroeter <mathieu.schroeter@mycable.ch> date: Sat Jan 09 20:29:01 2010 +0100 summary: fix 'make dist' in src
On voit clairement évoluer le “tip” de la branche “default” en parallèle à la branche “v1.0”.
Un “push” avec plusieurs branches
Tout ceci n’est qu’un exemple, ainsi pour montrer le “push” je vais utiliser un répertoire local. Admettons que je clone depuis http://hg.geexbox.org/libplayer.
$ cd .. $ hg clone http://hg.geexbox.org/libplayer libplayer-local requesting all changes adding changesets adding manifests adding file changes added 1327 changesets with 2268 changes to 111 files updating working directory 104 files updated, 0 files merged, 0 files removed, 0 files unresolved
C’est donc le dépôt original où j’ai qu’une seule branche. Je retourne dans le dépôt qui contient la branche “v1.0” et je vais faire un “push” sur libplayer-local.
$ cd libplayer $ hg push ../libplayer-local pushing to ../libplayer-local searching for changes abort: push creates new remote branch 'v1.0'! (did you forget to merge? use push -f to force)
Le “push” est automatiquement annulé. Ce qui est très bien, ainsi Mercurial nous préviens qu’on a créé une nouvelle branche. Il est alors nécessaire de le forcer (la première fois). Mercurial nous demande aussi si on a pas oublié de faire un “merge”. C’est légitime dans le cas où on ne veut pas avoir deux branches séparées sur le dépôt distant.
$ hg push -f ../libplayer-local pushing to ../libplayer-local searching for changes adding changesets adding manifests adding file changes added 9 changesets with 6 changes to 2 files (+1 heads)
Mercurial nous confirme qu’on a bien ajouté un “head”. A partir de ce point je me suis posé la question de ce qui se passe si quelqu’un clone ce dépôt avec ces deux “heads”. Est-ce qu’il va avoir un avertissement s’il tente de faire un “push”, du genre qu’il devrait faire un “merge” ou forcer le “push”?! Ce serait ennuyeux si c’était le cas, car les branches ne devraient pas intervenir. Le “head” n’étant pas sur la même branche. J’ai donc simplement testé pour m’en assurer:
$ cd .. $ hg clone libplayer-local libplayer-foobar updating working directory 104 files updated, 0 files merged, 0 files removed, 0 files unresolved
Cette manipulation revient au même que de cloner le dépôt sur hg.geexbox.org si j’avais “pushé” les modifications. Sans me soucier des branches, je vais faire une modification dans libplayer-foobar, la “commiter”, puis faire un “push” dans libplayer-local comme si c’était hg.geexbox.org/libplayer.
$ cd libplayer-foobar $ vi Makefile $ hg commit -m "still a dummy commit" $ hg push ../libplayer-local pushing to ../libplayer-local searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files
Il n’y a aucune remarque de Mercurial par rapport aux branches. Cela prouve que tout fonctionne correctement. Honnêtement j’avais toujours eu des doutes sur ces fonctionnalités. Au moins maintenant c’est clair. Je vais alors retourner dans le dépôt libplayer-local pour vérifier le résultat avec `hg view`.
Tout a fonctionné parfaitement..
Conclusion
Maintenant que j’en sais suffisamment sur les branches, je pense passer par ce moyen à l’avenir. Il pourrait être même judicieux (peut être) de repasser tous les backports de geexbox-1.2 dans le dépôt geexbox. L’idée serait de ne jamais écrire de nouveaux patchs dans les dépôts faisant références à des versions antérieures. Mais de toujours faire les modifications dans le “default” et uniquement des “transplant” dans les autres branches. Je pense par exemple au dossier debian/ dans les dépôts. Afin de garder l’historique, une nouvelle release tel que libplayer-1.0.1 par exemple, serait enregistrée dans les changelogs du “default”, puis un “transplant” mettrait à jour la branche “v1.0”.
Il reste une utilisation des branches qui me pose encore un problème. Les cas où l’écriture d’une fonctionnalité ne devrait pas se faire directement dans le “default” car elle introduirait des régressions. Une branche supplémentaire tel que “experimental” pourrait faire l’affaire. On devrait ensuite faire un “merge” de cette branche dans le “default”. Ce qui me dérange c’est qu’on finit par collectionner les branches comme par exemple ici: http://hg.geexbox.org/enna/. Il y a “new_vfs” et “new_vfs_system”. Ces branches n’ont plus vraiment de raison d’être car elles ont été “mergées”. Dans le cas de l’exemple présenté au-dessus avec la branche “v1.0”, c’est parfaitement normal de la garder pour toujours. Je n’ai donc pas encore trouvé de solution propre (c’est une question de point de vue) pour travailler avec des branches de courtes durées de vie.
Si quelqu’un à une idée…
A bientôt,
Mathieu SCHROETER
Skywalker13 
Même si je ne comprends pas toujours tout, je prends beaucoup de plaisir à lire tes billets. J’envisage même d’essayer d’apporter ma petite pierre à vos sources. En attendant il me tarde de lire ton prochain billet. Déjà plus de 20 jours que tu n’as plus rien postés.
CyberMomo
Hello
Merci! En général ça me prend pas mal de temps à les écrire. J’essaie d’avoir un rythme d’environ 1 ou 2 par mois mais pas plus. Et ça dépend surtout de ce que je suis en train de faire sur les projets. Ou alors je travail sur d’autres choses qui ne sont pas liées à GeeXboX.
N’hésite pas à essayer d’apporter une grosse pierre, on est pas beaucoup ;-).
Je ne sais pas si les commentaires de tes billets est le bonne endroit pour parler technique. Peu être le forum geexbox est plus adapté? La liste de DEV dans laquelle je me suis inscrits est intéressantes mais j’y participerais quand je maitriserais mieux mon sujet.
Bref passons au chose sérieuses. J’ai bien relu ton billet du 11 octobre et plus particulièrement le paragraphe “force stop”.
Sachant que je suis en mode test et que ma bibliothèque est énorme je rencontre un gros soucis.
une fois Enna lancé j’entre dans le module vidéo et je parcours mon disque réseau dans lequel se trouve des photos,vidéo, mp3. Bref pas mal de chose qui vont occuper valhalla pour un premier lancement.
Je vois bien mes accès disques local monté en flèche mais je ne m’en inquiète pas sachant ce qui se passe. Malgré tout je décide de fermer Enna et la c’est le drame car malgré la puissante machine que j’ai a disposition le programme met plus de 10 min a se fermer quand il ne se plante pas carrément.
J’ai tester de laisser tourner mais au bout d’un certain temps c’est le plantage.
Ton soucis de sauvegardé les données en cours pour éviter d’avoir à les regraber n’est pas mauvais mais d’une manière générale je pense qu’il vaux mieux faire le minimum de chose pour repondre au plus vite à un request de type “force stop”.
Finalement (non je n’ai pas encore regarder au code) à tu prévu un mode verbose ou l’on peu suivre le travail de ta librairie? Si oui comment l’activé?
C’est OK, tu peux même poster dans le billet qui parle du force-stop.. de toute façon je suis notifié par e-mail quand il y a un commentaire.
Tout d’abord j’suis bien content d’avoir enfin au moins un retour à ce niveau là. Tu dois être le premier qui fait remarquer une attente.
Tout d’abord la puissance de la machine n’a aucune importance à ce niveau. Je suis sûr que ton processeur faisait pas grand chose pendant les 10 minutes d’attente. En fait c’est typiquement un timeout sur libcurl car un des serveurs web d’un des grabbers a merdé, était injoignable ou autre chose du genre. Et dans libvalhalla-1.0.1 il n’y a pas de timeout explicite. Ainsi c’est l’OS qui est sensé faire lâcher la connexion après un temps que je ne connais pas et qui varie sûrement d’un système à l’autre. Tout du moins, d’une distribution à l’autre.
Le libvalhalla-devel ne devrait plus avoir ce problème, car j’ai forcé le timeout au maximum à 20 sec.
Ensuite tu parles de plantage.. il me faut des backtraces GDB sinon je ne peux rien faire. En OpenGL il y a de toute façon un segfault à la sortie d’Enna. C’est un problème connu mais qui n’a pas d’impact majeur. Ensuite il serait bon de me dire quel est la version de libsqlite3 que tu as. J’avais sauf erreur un problème avec un “COMMIT;” SQL avec l’une des version et certaines requêtes, mais je ne sais plus laquelle. En fait, sqlite se bloquait indéfiniment sur le COMMIT (je crois car je n’ai jamais pu reproduire le problème une deuxième fois, et donc un backtrace GDB m’intéresse fortement).
Concernant la sauvegarde des données en cours, honnêtement ce n’est pas ça qui prend du temps. Je suis sûr à (disons) 90% que c’est le timeout qui provoque les attentes de 10 min. Au force-stop il y a déjà une partie des fonctionnalités qui est sautée pour gagner du temps. C’était un problème visible avec les partages réseau qui sont extrêmement lents comparés à un disque dur.
D’ailleurs, est-ce que les fichiers scannés sont sur le réseau?
Maintenant que tu as fais resortir ce problème, je pense alors faire une release 1.0.2 avec au moins les améliorations sur les timeouts. Dans l’idéal il serait encore mieux si tu peux tester avec les versions devels des libs, et donc d’Enna.
Le meilleur moyen pour faire le test, c’est d’effacer la base de donnée, de relancer Enna et d’attendre par exemple ~60 sec que les queues soient bien pleines et que le downloader n’ait pas vraiment eu le temps de télécharger des covers (et donc qu’il y ait pas mal de contextes à devoir sauver). Puis de faire le stop (avec GDB également au cas où il y a un plantage).
Pour augmenter la verbosité de libvalhalla, il suffit de changer en verbosity=verbose dans la section [media_db] du fichier enna.cfg. Note qu’en verbose c’est très très verbeux (il y a aussi verbosity=info mais qui dit bcp moins de chose).. mais ça permet de bien voir où il y a l’attente.
Merci pour ce feedback.
PS: le force-stop et le ondemand sont les deux choses les plus complexes de libvalhalla. Dans libvalhalla-devel j’ai également amélioré le force-stop par rapport au ondemand. Car avec libvalhalla 1.x.x c’est un arrêt synchrone. C’est à dire que d’abord le ondemand est arrêté, ensuite tous les autres threads. Ce qui se passe c’est que pendant que le ondemand s’arrête il doit réveiller les autres threads (je ne vais pas rentrer dans les détails) mais pendant un court instant un grabber va commencer a bosser avec internet juste au moment ou le thread ondemand s’arrête, et tu ramasses des secondes d’attente si le serveur n’est pas rapide. Avec la devel, c’est asynchrone, donc tous les threads reçoivent en même temps l’ordre de s’arrêter.
Salut,
J’ai réussi à compiler enna-dev avec les version dev des libs. (Si j’ai bien compris mercurial j’ai téléchargé les dernier tip se matin en faisant un hg clone http… )
Je n’arrive pas à reproduire le problème de force-stop. Par contre le scan n’a pas l’air de s’arrêter.
[libvalhalla] [scanner.c:510] Verb: vh_scanner_suffix_cmp
[libvalhalla] [dbmanager.c:628] Verb: vh_dbmanager_action_send
[libvalhalla] [scanner.c:472] Verb: vh_scanner_path_cmp
en boucle.
Les infos grabbées ne sont pas vraiment pertinantes ou ne correspondent pas au films recherché mais cela est principalement du au mauvais choix des grabbers vu que presque tous les noms de films sont en français.
Ce n’est pas une priorité mais cela met en évidence un problème qui sera de toute façons à réglé en ajoutant la possibilité d’édité manuellement les données dans la bdd.
De refaire un scan manuel avec un nom de film corrigé ou différent.
Ou encore de créer une étiquette vide afin de l’éditer manuellement au cas ou aucun grabber n’aie trouvé d’infos.
Pour info j’utilise actuellement MediaPortal avec des plugins personnalisé.
Parmis ces plugin il existe movingpicture qui permet ce genre de choses et même plus avec la possibilité de créer ses propres catégories avec des conditions persos qui permettent une médiathèque rangées exactement comme on le souhaite. Bien entendu ce petit aparté ne concerne pas libvalhalla et est juste la à titre informatif.
Je serais probablement intéressé à développé ce genre de frontend pour enna il faudra juste avoir une structure de base de donnée plus ou moins figée.
Pense tu que d’autre on déjà pris cette initiative?
Dès que tu actives la verbosité tu ralentis fortement.. les printf c’est très méchant niveau ressources (c’est vraiment intéressant que pour le debug).. Les vh_scanner_path_cmp() se font après le scan.. il servent a contrôler tous les fichiers qui n’ont pas été “insérés” ou “updatés” pendant le scan. Le but est d’effacer de la base de données les fichiers qui n’existent plus. Ainsi si tu as 10’000 fichiers qui existaient déjà (donc pas “insert/update”) alors il va checker les 10’000. Si c’est à travers le réseau, en fonction des paramètres NFS ça peut être lent. Si tu fais bien du NFS, je peux redemander à celui qui m’avait parlé de ça.. c’est une option dans le fichier exports à ajouter et ça va ensuite beaucoup plus vite (le problème de lenteur est lié à la fonction access(), tu trouves des infos en googlant).
Pour ce qui est de la langue, c’est dans le TODO. Car il faut pouvoir gérer absolument n’importe quelles langues. Et certains grabbers sont potentiellement capable de gérer au moins 5 à 10 langues. Ce n’est donc pas une question de mauvais choix ou de bon choix. Il y a qu’un seul grabber qui gère le français. Mais libvalhalla aujourd’hui n’est fait que pour l’anglais (faut bien commencer qque part).
Donc pour le moment, le moyen correcte de faire c’est d’avoir des titres anglais. La lib est encore jeune, et je n’ai pas encore eu le temps de bosser la dessus.
L’édition des metadata est déjà possible mais pas interfacée dans Enna. libvalhalla-2.x gère aussi les priorités sur les metadata mais là aussi ce n’est pas encore accessible à la config pour l’utilisateur.
Figer complètement la base de donnée je ne peux pas encore le faire. Le fait de devoir gérer les langues pour les grabbers est la première raison. Tout ce que je peux te dire c’est que les base de données ont des versions pour pouvoir être différenciées. Il y a qqun qui était intéressé par faire un frontend pour touiller dans la BD, mais il a laissé tombé pour le moment. Je l’avais prévenus que j’allais devoir étendre la structure à cause en autres des priorités pour les metadata.
Ok je pense qu’il vaut mieux aussi postposé le front-end tant que la bdd n’est pas stable.
Concernant le fait que le scanner supprime les infos concernant un fichier non trouver j’ai une remarque importante.
Je viens de faire le test, je ne monte pas mon disque réseaux et je lance enna. Forcement la base de donnée est en cours de vidage au fur et à mesure des vérification. Donc voila un point ou pour cette partie l’idéal serait de vérifier si on à affaire à un disque réseaux ou pas et si celui-ci est en ligne avant de faire un quelconque erase.
Mais ce n’est pas tout que se passe t’il si comme moi on monte un lecteur réseau dans un répertoire du style “/home/myname/DisqueReseau” peu on déterminer que c’est un disque réseau monté à cette endroit?
libvalhalla c’est un scanner, et non une bibliothèque de stockage pour une collection de film/musique. Donc forcément, si les liens n’existent plus ils doivent être supprimés, ou alors tu as des “zombies” dans les browser Enna (par exemple) qui pointent sur rien.
Maintenant d’avoir un attribut supplémentaire qui dirait que tel fichier est considéré comme étant sur un media “amovible”, pourquoi pas. Par contre dans ce cas il faut trouver comment est-ce que valhalla peut savoir si cette entrée doit être supprimées ou non. En admettant que le partage réseau/CD/clef USB n’existera plus jamais.. qu’est-ce qu’on fait? Qu’est-ce qui dit à la lib qu’il faut effacer l’entrée et quand?
“En admettant que le partage réseau/CD/clef USB n’existera plus jamais.. qu’est-ce qu’on fait? Qu’est-ce qui dit à la lib qu’il faut effacer l’entrée et quand?”
Rien, si on clique sur le film dans la médiathèque et que celui ci n’est pas disponible on reçois un avertissement nous demandant d’insérer le disque amovible ou se trouvait le dit fichier OU la possibilité de le supprimé de la base de donnée.
On remplit ainsi la base donnée de divers films pas nécessairement directement accessible mais qui aura le mérite de nous présenté notre médiathèque complète. Aussi concernant les DVD ou BlueRay que l’on possède cela aura le mérite de traité tout les fichier amovible de la même manière.
Qu’en pensez vous?
Attention, je parle de libvalhalla et non d’Enna. La lib doit pouvoir être utilisée en continue sans aucune intervention d’un utilisateur. Par exemple, un serveur UPnP basé sur libvalhalla pour les metadata. Enna c’est un cas particulier et libvalhalla est un projet indépendant.
J’ai déjà eu plusieurs discussions avec les autres devs concernant le fait de pouvoir utiliser libvalhalla avec des DVD par exemple. Pour un humain, un DVD Video peut s’apparenter à un fichier. Sauf que d’un point de vue technique ça n’a strictement rien à voir. Un fichier c’est qqch de générique, on y accède toujours de la même manière. Mais un DVD, un CD Audio il la libdvdread, la libccdb, etc,..
Je répète, libvalhalla c’est un scanner de fichiers. Je préfèrerais même une lib en amont de libvalhalla pour gérer les cas particuliers comme les DVD, etc,..
Le mieux que je pourrais faire, c’est de permettre d’utiliser les grabbers en ondemand même pour qqch qui n’est pas un fichier (donc tu donnes des mots clef, le type puis valhalla te retourne les metadata sans considérer la base de donnée). Mais je n’intégrerai pas la gestion de ce qui n’est pas “fichier” directement dans libvalhalla. Beaucoup trop intrusif et ça n’a jamais été le but.
Concernant l’interface depuis Enna, rien n’empêche d’écrire un module Enna (browser) pour gérer une bibliothèque.
Au niveau metadata on a de toute façon du travail à faire encore dans Enna. C’est loin d’être terminé.
Vous voulez dire que si je met en PATH un lecteur dvd data (avec 6 films de type divx) les metadata seront insérées puis lorsque je changerai ou simplement retirerai le dvd ces même infos seront retirée?
Que l’insertion de DVD ou BlueRay ne fera pas réagir Valhalla?
Je suis conscient que le mécanisme que j’ai décrit ne concerne pas que libvalhalla mais la gestion des fichiers trouvé/non trouvé est faite actuellement par votre lib. Rajouté une couche intermédiaire ne ferais qu’alourdir les appel et servirais principalement a :
1 – rajouté l’option “détections du nom du film en fonction du DVD/BR inséré”
2 – rajouté ses metadata dans la BDD
3 – configurer valhalla pour empêcher le delete systématique des donnée de la bdd si le fichier est sur un support amovible.(si c’est possible)
4 – gérer les cas de demande de fichier non présent physiquement.
Les 2 premiers points sont compatible avec les fonctions de valhalla non?
Le point 3 nécessite pas mal de réflexion/programmation c’est clair.
Le point 4 est juste une donnée supplémentaire à envoyé à enna qui lui permettrais de savoir que ce fichier n’est pas directement disponible.
A l’heure actuel beaucoup de monde possède un NAS et lorsqu’on il ya une grosse bibliothèque de films le remplissage de la BDD prendra du temps, sans compter les non trouvé et les corrigé que l’on vas faire manuellement. Ce serait vraiment bête de perdre la bdd à cause d’un quelconque problème réseau non?
Je te promet qu’on est loin d’avoir beaucoup de couches avec Enna.
Pour le point 1, tout doit être indépendant du media. Que se sois un DVD ou un xvid sur une clef USB ça ne devrait rien changer. Mais tu ne me dis pas comment l’identifier de manière unique. Il y a beaucoup de gens qui ne mettent pas de nom particulier en gravant leur CD-R/DVD-R, du coup tous les DVD ont les même noms. C’est impossible de savoir d’où vient un fichier avec certitude.
Pour le point 2, pour autant que ça reste des fichiers sur un DVD,.. et non un DVD Video.
Pour le point 3, ça serait possible de le faire mais dans ce cas ça devient des cas particulier et libvalhalla devra ignorer ces fichiers.
Pour le point 4, c’est implicite. Dès le moment qu’une entrée existe dans la base de donnée, tu peux la retrouver. Après c’est le problème d’Enna.
Ta dernière remarque est pertinente. La seule solution que je vois actuellement c’est de rajouter une option pour chaque path= dans l’enna.cfg qui permettrait de dire (par défaut) à libvalhalla si elle doit ignorer les fichiers de ce path ou non. Une option qui devrait être modifiable à chaud par Enna lorsque le path en question serait à nouveau accessible.
Pour la partie libvalhalla c’est facile à dire, il y a qu’en même un hic. Ca ne peut marcher que dans un sens. C’est à dire :
path inaccessible -> enna démarre -> libvalhalla ignore -> path accessible -> enna informe libvalhalla -> libvalhalla considère les fichiers de ce path
Mais si un path devient inaccessible pendant qu’Enna tourne, étant donné que tout est parallélisé tu perdras forcément des entrées. Le temps qu’Enna se rende compte que ce n’est plus accessible et qu’il puisse informer libvalhalla, il y a forcément un peu de temps qui va passer et donc des entrées vont se faire effacer.
Il faut vraiment penser à tous les problèmes et les cas de figure.
A noter que ce message c’est la réponse de ton poste plus haut avec les 4 points.
Oups mon commentaire de réponse c’est placé plus haut j’ai du faire une erreur…
Et puis je viens de me rendre compte que je ne t’ai pas répondu sur le partage utilisé. C’est du Samba pour le moment.
Ayant placé le mode “verbosity” en “info” j’ai aussi pu remarqué que cette partie du code tournais en boucle.
[libvalhalla] [dbmanager.c:430] Info: [dbmanager_thread] End loop 2398
[libvalhalla] [dbmanager.c:363] Info: [dbmanager_thread] Begin loop 2399
[libvalhalla] [scanner.c:289] Info: [scanner_thread] End scanning : 426 files
[libvalhalla] [scanner.c:282] Info: [scanner_thread] Start scanning : /home/cybermomo/Nas/Vidéo
[libvalhalla] [grabber.c:686] Info: ====================================================================
[libvalhalla] [grabber.c:687] Info: Statistics dump (grabber)
[libvalhalla] [grabber.c:689] Info: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[libvalhalla] [grabber.c:705] Info: local | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: nfo | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: tmdb | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: lastfm | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: exif | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: chartlyrics | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: lyricwiki | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: tvdb | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: tvrage | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: imdb | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:705] Info: allocine | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [grabber.c:709] Info: ~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[libvalhalla] [grabber.c:716] Info: GLOBAL | 0/0 (100.00%)
[libvalhalla] [downloader.c:302] Info: ==================================================================
[libvalhalla] [downloader.c:303] Info: Statistics dump (downloader)
[libvalhalla] [downloader.c:305] Info: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[libvalhalla] [downloader.c:315] Info: Downloads | 0/0 (100.00%) 0.00 sec 0.00 sec/file
[libvalhalla] [downloader.c:316] Info: Skipped | 0/0
[libvalhalla] [dbmanager.c:556] Info: ==============================
[libvalhalla] [dbmanager.c:557] Info: Statistics dump (dbmanager)
[libvalhalla] [dbmanager.c:558] Info: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[libvalhalla] [dbmanager.c:561] Info: Files inserted | 0
[libvalhalla] [dbmanager.c:563] Info: Files updated | 0
[libvalhalla] [dbmanager.c:565] Info: Files deleted | 0
[libvalhalla] [dbmanager.c:567] Info: Files unchanged | 1022400
[libvalhalla] [dbmanager.c:569] Info: Relations cleaned | 0
[libvalhalla] [ondemand.c:339] Info: ==================================================
[libvalhalla] [ondemand.c:340] Info: Statistics dump (ondemand)
[libvalhalla] [ondemand.c:342] Info: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[libvalhalla] [ondemand.c:347] Info: Queries | 0 0.00 sec 0.00 sec/file
Est-ce normal? Je fais allusion plus particulièrement à
[libvalhalla] [dbmanager.c:567] Info: Files unchanged | 1022400
qui ne cesse d’augmenté. Bien sur je n’ai pas autant de fichier sur mon Nas…
Pour finir vu que vous ne m’avez pas encore répondu j’espère ne pas avoir été trop envahissant… Je n’ai pas encore étudié le code de Valhalla ayant porté ma priorité actuelle sur les EFL. Du coup si je suis vraiment à coté de la plaque n’hésitez pas à me le dire.
Oui c’est normal.. ce n’est qu’un chiffre.. chaque 15 minutes (par défaut, tu peux configurer dans l’enna.cfg) il recontrole les dates de dernières modifications de tous les fichiers. Et les statistiques reflètent l’état depuis le démarrage c’est pour cela que ça s’incrémente. Et c’est uniquement informatif.
Je n’ai pas encore répondu à ton autre message car je n’ai pas encore eu le temps. Je suis en train de bosser sur les ports Windows de libnfo et libvalhalla.
Mais je n’ai pas oublié!
Ok par contre ce test est fait en boucle malgré que dans enna.cfg j’ai bien
scan_loop=-1
scan_sleep=900
Quand je dis en boucle je veux dire directement sans tenir compte du sleep.
Je vais tentez de voir pourquoi.
Si jamais le fichier de config avec la devel est dans ~/.config/enna/ , le dossier est ~/.enna/ n’est plus utilisé.
A part ça, a moins d’avoir la fonction clock_gettime() qui retourne un temps absurde, l’attente ne peut pas ne pas se faire. Peut être que tu as tellement de fichier et que tu as le problème NFS que le contrôle prend plus de 15 minutes. Mais tu ne m’as pas répondu avant.. si tu es bien en NFS ou non.. et si c’est le cas il y a une config à corriger.
Rajouté une option n’est que retarder le problème. En fait l’idéal c’est d’ajouter une fonction du genre :
// bool is_removable_device(path)
// Permet de tester si un fichier se trouve sur un disque amovible.
Mes essais actuel ne donne rien quant au codage de cette fonction pour qu’elle prennent en compte tout les cas de figures.
En gros si cette fonction existe c’est valhalla qui se chargera de tout en restant indépendant d’Enna.
Un exemple en pseudo c de ce que je veux dire :
in scanner function
…
…
if (path_exist(path[i])){
..
..
}else{
// si le disque est considéré comme amovible on positionne un drapeau
// dans la base de donnée qui permettra au programme hôte(enna) de le
// savoir. Le cas de l’absence du fichier sur un support amovible
// existant est traité en verifiant l’accessibilité du périférique.
if (is_removable_device(path[i]) && !(device_exist(path[i]))) {
sql_update(SetNotPresentFlag,path[i],true);
}else{
sql_delete(metadata,path[i]);
}
}
A la question le scan se fait toute les 15min le chemin est peu être accessible, il suffit de la part d’enna de faire le test de présence avant un play et de demandé l’insertion du media ou l’effacement des donnée de la bdd.
Bon l’idéal est de t’envoyé un patch pour que tu essaye, je tacherai de voir ce que je peu faire la semaine prochaine. Merci en tout cas pour ces échanges constructif.