Discussion :

[tepaze]

Bonjour,

Je travail actuellement à un script me permettant de travailler sur un grand nombre de fichier vidéo (plusieurs centaines / milliers).
Afin de savoir si un fichier à été déjà traité, j'y ajoute des métadonnées, et j'ajoute son chemin absolu à une liste dans un fichier texte.
Aussi, lors de la recherche de nouveaux fichiers, le script vérifie qu'il ne sont pas présent dans la liste du fichier texte. Je verifie, avec une application tierce, qu'il ne contient pas non plus les métadata que j'y ajoute, afin de ne pas lui appliquer un traitement qui est parfois long. Si le traitement à déjà été effectué, j'ajoute ce nouveau chemin absolu au fichier texte.

Et je ne pose un question toute bête :
Qu'adviendra t il dans quelques années, lorsque j'aurais un fichier texte qui contiendra plusieurs milliers de lignes... Voir plusieurs dizaine de milliers de lignes si un zozo s'amuse à renommer les dossiers ou les fichiers ?
Je suis plutot novice en sh, mais en programmation en général, il faut ce mefier des ressources consommées, et je me demande s'il est pertinent d'adopter cette solution...
Ne devrais je pas plutôt me diriger vers une vérification systématique des metadata via le binaire externe, et zapper le fichier texte ???
D'autant que le script risque de tourner 24/24-7/7 pour la 1ere passe durant plusieurs mois...

Bref, vous l'aurez compris, j'ai une partie de ma réponse dans la question, mais vous qu'en pensez vous ?

Bien cordialement

Tepaze

[BufferBob]

salut,

les fichiers que tu traites (nouveaux + anciens) sont ils dans des arborescences spécifiques ou disséminés un peu partout ?
une solution simple pourrait être de déplacer les fichiers vers un répertoire déjà_traités/ par exemple
edit: note que même sans parler de déplacer physiquement les fichiers, il est peut-être envisageable de faire un répertoire déjà_traité/ contenant uniquement des liens symboliques vers les fichiers, il devient alors facile de checker si un lien est cassé (fichier renommé/déplacé/supprimé)

le point que tu soulèves vis à vis du nom de fichier et de son éventuel renommage est pertinent, si on considère qu'on travaille exclusivement sur une même partition (que les fichiers ne sont pas déplacés d'une partition à une autre) le numéro d'inode pourrait être un identificateur plus fiable

mais comme tu le fait remarquer la solution la plus safe reste encore de vérifier directement la présence de tes metadatas, en revanche niveau perfs c'est précisément là que ça risque d'être consommateur

[tepaze]

Merci BufferBob,

Je n'avais pas pensée aux liens symboliques. Cela me semble être une solution à creuser... Mais quid des fichiers ayant le même nom ?

Tous mes fichiers sont disséminé dans des ensembles de dossiers, sous dossiers et de volumes sur plusieurs NAS. Beaucoup de fichiers ont exactement le même nom, et cela n'est pas modifiable.

Niveau perf, je suis partagé. Les processus appliqués aux fichiers durent plusieurs heures, voir plusieurs jours, donc checker si un fichier contient les métadatas est certes une perte de temps lorsque l'on doit re-scanner l'ensemble des volumes, en même temps c'est relatif comparé aux traitements à proprement dit...

Bref, je suis toujours preneur de d'avis et de conseils :-)

[Flodelarab]

Bonjour

Afin de savoir si un fichier à été déjà traité, j'y ajoute des métadonnées, et j'ajoute son chemin absolu à une liste dans un fichier texte.

Bon ben, déjà, là, ça fait doublon. Écrire des métadonnées est malin pour ne pas avoir de fichier de recensement à côté.

j'y ajoute des métadonnées

Si il y a une entête DESC=13 et que tu la transformes en DESC=14, ce n'est pas facilement détectable. Mais si tu ajoutes TEPAZE_MODIFIED, tu peux faire un truc similaire à ce qui suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ find repertoire -name "*.mp4" -exec grep -a -i -o -H TEPAZE_MODIFIED {} \;

Un exemple similaire qui recherche la chaine jpg dans un fichier jpg (donc binaire)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$ find monRepertoire -name "*.jpg" -exec grep -a -i -o -H jpg {} \;
monRepertoire/toto/polo.jpg:jPg
monRepertoire/toto/polo2.jpg:jPg
monRepertoire/toto/polo3.jpg:JPG
monRepertoire/toto/polo4.jpg:jpG
monRepertoire/titi/pola.jpg:jPg
monRepertoire/titi/pola.jpg:jpg
monRepertoire/titi/pola2.jpg:JPG

[disedorgue]

Bonjour,

En reprenant l'idée du lien symbolique, tu peux très bien faire un md5sum du fichier et incorporer celui-ci dans le nom du lien.

Par contre, il y a une contrainte: si tu as 2 fois le même fichier avec le même nom mais dans un répertoire différent, tu n'auras qu'un seul lien.

Ce qui peut être un avantage, c'est qu'un fichier renommé gardera quand même le même md5sum (tant que l'on ne modifie pas son contenu).

[tepaze]

Ok, j'y vois plus clair au fur et à mesure.

Flodelarab, je ne comprend pas un truc, tu recherches une chaine dans un binaire (un jpg), mais, j'avoue, je ne sais pas comment est construit un binaire, aussi, actuellement j'utilise soit un exif, soit un metadata specifique aux flux video. Alors, comment procede tu toi pour ajouter ton metadata ?

Je crois que je vais me diriger vers un examen systématique du fichier à la recherche du métadata, et mettre de coté les autres options. Merci BufferBob et Disedorgue pour vos pistes de reflexion.

EDIT :
Et aussi, un fichier de plusieurs milliers de ligne peut il poser probleme à l'ouverture au sein du script ?

[Flodelarab]

On ne s'est pas compris. J'imaginais des métadonnées, que tu as ajoutées, en clair dans le fichier, qu'on aurait pu lire sans outil supplémentaire.
Ce n'est pas ça mais ce n'est pas grave. Il faudrait connaître l'extension de ton fichier vidéo.

• Si c'est un fichier libre *.ogg, tu peux utiliser "oggz-comment" pour lire ou modifier des méta-données.
• Si c'est un fichier *.mp4 ou *.flv ou ..., tu peux utiliser "avprobe", du paquet libav-tools, pour extraire les meta-données. (Je n'ai rien installé à l'instant, et ça marche)

[tepaze]

Si c'est un fichier *.mp4 ou *.flv ou ..., tu peux utiliser "avprobe", du paquet libav-tools, pour extraire les meta-données.

C'est ce que je fais actuellement avec ffprobe.
Un instant j'ai cru que l'on pouvais ajouter à un binaire des données réutilisable avec un simple editeur de texte. J'etais étonné, mais aussi intéressé :-)

Merci

Bonne soirée

[Sve@r]

Bonjour

Ce boulot que tu décris (recensement des fichiers déjà traités) est typique d'une base de données. Pourquoi alors ne pas utiliser une vraie base de données ? Au-moins, même dans quelques années, quand ton récapitulatif sera devenu méga important, les perfs de recherches resteront relativement correctes (et plus que correctes si tu places de judicieux index).

Et si la question installation bdd (serveur, config, etc) te fait peur, tu as à ta disposition sqlite qui est une base de données mais fichier. C'est à dire que le moteur bdd stocke ses datas dans un gros fichier (illisible par un outil texte évidemment). Un peu moins puissant qu'une vraie base de données (type Postgres) mais performances très correctes et l'avantage c'est qu'il n'y a pas de serveur à installer...

[Flodelarab]

Si j'osais être impertinent, je dirais qu'on voit bien là le traitement d'un scientifique qui ne fait pas la différence entre la réalité et sa modélisation de la réalité.
On n'a pas besoin de tenir à jour la liste des fois où ses enfants sont allés chez le coiffeur pour savoir quand ils ont besoin d'y retourner.

Ces fichiers jpg sont traités ou non-traités. Pas besoin de bdd.

Mais je ne suis pas impertinent.

[Sve@r]

Justement si, je fais très bien la différence entre la réalité et sa modélisation car il y a une différence flagrante entre "regarder des cheveux pousser sur 2 ou 3 têtes" et "tenir une comptabilité de (je cite) plusieurs centaines / milliers de fichiers". Si le soucis du PO avait été la comptabilité de 15 ou 20 fichiers je n'aurais pas proposé une bdd.
Encore que même pour 15 ou 20, une bdd permet de gérer le besoin immédiat tout en étant prêt pour un futur accroissement éventuel mais dans ce cas effectivement ça aurait été plus discutable sur la probabilité de cet accroissement éventuel. Mais dans notre cas ici, il n'y a pas matière à discuter car le besoin est avéré (sauf si quelqu'un peut dire sans rougir qu'il est capable de gérer plusieurs centaines / milliers de fichiers de tête).

Donc le PO a posé un problème précis, je tente d'y répondre avec mes connaissances de scientifique en y apportant des réponses différentes de celles qui ont déjà été données mais sans porter de jugement sur la pertinence du problème en lui-même...

[Flodelarab]

Oui! Tu as raison. Re-tester un fichier peut devenir lourd.

[tepaze]

Ok messieurs, j'ai bien pris note. Mais une question pointe alors son nez à ma barbe :
Si je met la base de données en place, ce que je pense faire à moyen terme (dans un second déploiement), les vidéos étant référencées au sein de la BDD par leurs chemins, je risque de me retrouver avec des "Entrées Mortes" dues à un changement inopiné du nom d'un dossier par exemple (comme dit plus haut, je ne maitrise pas ce type de changements). Donc cela veut dire qu'il va falloir que je mette -aussi- en place des routine de vérification d'existance de fichiers, afin de purger la BDD !?

La réponse est dans la question...

Etant entendu que j'aurais un nombre croissant de fichiers vidéos... D'abord quelques centaines, puis certainement quelques milliers...

Enfin, comment manier une base de donnée (SQLite je pense pour des questions de facilité de portage) en SH... Je ne suis pas un familier de SH, ni des commande SQL (même si le code d'une façon générale ne me rebute pas)

En tout cas, merci pour vos conseils, qui par la même m'encorage à pousser plus en avant le développement de mon script.

Cordialement

[Flodelarab]

Jusqu'ici ta BDD ne sert qu'à une chose: ne pas avoir à re-analyser un fichier déjà analysé. Si il y a eu un changement de nom ou de dossier inopiné, pas grave, tu analyseras à nouveau tes fichiers.

Pourquoi celui qui modifie le nom ne modifierait-il pas la BDD ?

[BufferBob]

Pourquoi celui qui modifie le nom ne modifierait-il pas la BDD ?

on se place dans le cadre d'un PEBKAC^* j'imagine

^*problem exists between keyboard and chair

[tepaze]

on se place dans le cadre d'un PEBKAC^* j'imagine
^*problem exists between keyboard and chair

C'est exactement cela.

Merci à tous.

[Sve@r]

Ok messieurs, j'ai bien pris note. Mais une question pointe alors son nez à ma barbe :
Si je met la base de données en place, ce que je pense faire à moyen terme (dans un second déploiement), les vidéos étant référencées au sein de la BDD par leurs chemins, je risque de me retrouver avec des "Entrées Mortes" dues à un changement inopiné du nom d'un dossier par exemple (comme dit plus haut, je ne maitrise pas ce type de changements). Donc cela veut dire qu'il va falloir que je mette -aussi- en place des routine de vérification d'existance de fichiers, afin de purger la BDD !?

Hélas toute solution a ses inconvénients. Effectivement si tu mets en place un contrôle de nom, tu ne maitrises pas celui qui va modifier le nom "à la mano". Ce problème existe d'ailleurs déjà de partout. J'ai écrit un logiciel de gestion de librairie, qui utilisait une bdd (Postgresql) et une IHM (Qt). Celui qui utilise le logiciel peut rajouter des clients, enlever des clients, modifier leurs éléments (nom, adresse, tel, etc), rajouter des livres, modifier le prix, bref gérer sa librairie. Mais rien n'empêche l'admin d'ouvrir Postgres via l'interface sql et taper dans la bdd par des commandes sql. C'est l'inconvénient des tiers "de confiance", il faut leur "faire confiance" pour ne pas faire de conneries. D'ailleurs en allant plus loin, rien n'empêche l'admin du poste d'ouvrir une console root et de taper rm -fr /*...

Donc te faudra effectivement te créer un outil annexe destiné à vérifier la cohérence entre "ce qui est enregistré" et "ce qui est"......

Enfin, comment manier une base de donnée (SQLite je pense pour des questions de facilité de portage) en SH... Je ne suis pas un familier de SH, ni des commande SQL (même si le code d'une façon générale ne me rebute pas)

De façon très simple: toute commande quelle qu'elle soit possède un canal input (stdin) et un canal output (stdout). Et tu peux très bien lier l'output de la commande 1 à l'input de la commande 2 par un pipe.

Donc si par exemple tu as une commande 1 qui te génère une requête sql (par exemple un echo qui affiche ton select à l'écran style "echo select * from truc where chose...") il te suffit d'envoyer cette commande dans la commande sqlite (avec les bons paramètres) qui pourra lire et traiter cette requête. Ca donnera alors un echo "select * from truc where chose..." | sqlite ....

Ensuite le shell te permet de récupérer ce qu'une commande affiche à l'écran. Il suffit d'entourer la commande par un $(). Dans ce cas, ce qui est affiché ne part plus à l'écran mais retourne dans le shell et peut alors être utilisé (pour remplir une variable, pour être évalué, etc).
Exemple: pwd affiche ton dossier courant à l'écran mais si tu écris rep=$(pwd) alors ce dossier courant sera récupéré et stocké dans la variable "rep" que tu pourras alors traiter en écrivant echo $rep ou autre chose style if test "$rep" = "/home/truc"; then echo "je suis ici"; fi.

Donc en associant les deux techniques, si tu veux générer une requête via echo, la faire exécuter via sqlite et récupérer son résultat dans une variable "x", ça s'écrira alors ainsi: x=$(echo "select * from truc where chose..." | sqlite ...).

A partir de là, tu n'as plus de soucis pour interfacer n'importe quoi avec n'importe quoi...