Utiliser des KID comme noms de fichiers

Bases
1

Voilà on va commencer direct par un crochet du droit.

Utiliser des noms de fichiers selon le sens du vent ou des majuscules à la mode a de moins en moins de sens vu tout ce qui passe par l’application. Et ça rend plein de code extrèmement compliqué :

  • Ajout / suppression des karas : le nommage des fichiers dépend des tags, quand tu changes un tag tu fous le bordel dans le nom de fichier

Et y’a sûrement vingt mille autres endroits où j’ai pesté contre ça en codant des trucs.

Du coup je comprends bien qu’il y en a que ça va faire râler, surtout ceux qui éditent leurs fichiers à la main alors qu’ils ne devraient pas le faire vu que l’app peut tout gêrer désormais mais il faut aussi bien qu’ils se rendent compte qu’une vaste majorité des bugs sont liés à des noms de fichiers qui changent, des soucis de majuscules/minuscules sous Windows, et d’autres joyeusetés.

Maintenant, qu’est-ce qu’on peut faire pour palier à ça ? Réfléchissons en admettant qu’on utilise ce système :

  • Ecrire un fichier texte dans le dossier medias. Ce fichier aurait la liste des KIDs avec en face le nom du kara. Ca pourrait ^même être un CSV pour être triable dans un tableur si vous voulez.
  • Indiquer le KID du kara sur son Karadetail côté opérateur et côté systempanel quelque part afin que l’on sache rapidement quel est le KID à modifier à la mano si vraiment on doit le faire à la mano, par exemple pour réencoder.
  • Avoir une option pour créer un dossier de symlinks des paroles et des médias. En gros, pour les non-initiés, un symlink est un lien symbolique dans le système de fichiers. C’est très utilisé sous Linux, moins sous Windows (parce que un peu contraignant) mais l’idée c’est quand on veut qu’un dossier par exemple soit dispo à deux endroits simultanément on crée un lien symbolique à la place qui pointe vers le fichier original. C’est un fichier spécial, et quand on y accède (en lecture/écriture) on accède en fait au fichier original même s’il n’est pas dans le même dossier. Sous Windows c’est pas implémenté de la même façon mais l’idée est là : créer un dossier “medias-symlink” à côté du dossier medias contenant les fichiers sous forme de UUIDs.mp4. Le dossier symlink aura lui les noms de fichiers à l’ancienne. Et ce “lien” sera MAJ par KM à chaque modification de la bdd/génération. Ca pourrait palier au problème du “je veux voir les noms de fichiers legacy” mais je doute un peu de l’utilité.
  • Avoir un bouton “Ouvrir le média” dans le systempanel
  • Avoir un bouton "Selectionner le média dans le finder/explorateur dans le systempanel.
  • Une interface simplifiée pour FFMPEG pour faire des réencodages éventuellement. Il faudrait pour ça analyser quels paramètres sont variables et qu’on pourrait executer sur le média, voir proposer d’entrer la ligne de commande soi-même. On peut imaginer un truc comme ça simplifier aussi pour ajouter une cover à un mp3 par exemple.
  • Pour les gens qui utilisent pas KM mais la base on pourrait imaginer un script de renommage généré à chaque changement de la base afin de permettre à quelqu’un de renommer tous les UUIDs en noms de fichiers**. Après ça pose un souci potentiel de conflit : imaginons que deux KIDs donnent le même nom de fichier au final.

J’aimerais bien que les principaux intéressés nous aident à connaître les cas qui les obligent à manipuler les fichiers de KM à la main, afin qu’on comprenne ce que ça pose comme soucis qu’il faudrait prendre en compte et comment on peut les résoudre, par exemple en faisant en sorte que KM puisse le faire pour vous.

Désavantages

Parce qu’une idée n’est jamais sans désavantages :

  • Si un jour on gère le multi-medias et multi-lyrics par kara, on est un peu niqué. Enfin il faudra probablement revoir un peu ça.
  • Retrouver des fichiers via gitlab (même si gitlab de toutes façons limite les recherches sur notre git car il est trop gros). Après les noms des commits générés par KM devraient suffire
  • Les gens qui utilisent la base sans passer par KM (en convention par exemple)
2

Pas forcément en fait. On a des champs “version” et “default” dans le json. Donc on peut dire si default à true alors que le kid sinon kid-version. voilà.

3

Oui on peut faire un truc comme ça en effet. Le souci c’est que ça attache encore un nom de version libre de saisie à l’utilisateur et le jour où je sais pas moi “Madoka Vers.” devient “Minako Vers.” bah euh… :slight_smile:

Ou alors faut donner des ID numériques à attacher derrière, qui serait le numéro de la version dans le tableau

4

Since this thought doesn’t let me sleep peacefully, here my thoughts on that:

I see why having the KID as filename would make it easier handling the files in the code. It’s good being already able to manage much of the base like the lyrics in KM itself, but I think there are still cases where the actual name in the filename is useful. It seems that this change would make the base itself much more depending of the KM App, making it less “open” / managable / modular on a file basis.

As someone who often works with the files itself, either for debugging, quickly finding the files for a new version, an edit or some other project, or for managing a local base, I think this would make some things more complicated for some people.

Although I prefer the current naming convention, maybe something in between, like adding the kid on the end of the filename - like the tags are - could make it better?

5

Merci pour ce commentaire @Themio :stuck_out_tongue:

L’argument “dépendent de KM App” est recevable et je le comprends, c’est vrai que c’est un point non négligeable à prendre en compte. Je n’y avais pas pensé.

Ajouter le KID (ou une partie) dans le nom du fichier ne changerait pas grand chose. L’avantage qu’ont les tags c’est qu’ils changent très rarement de nom, alors qu’un fichier kara.json change plus souvent, il suffit de l’éditer et qu’un tag qu’il utilise ait été modifié pour que son nom change de nouveau.

Bref, j’ai l’impression que ce problème est peut-être insoluble…

6

Utilisatrice de l’enfer, bonjour.
Pour résumer, j’ai mon installation KM sur mon PC fixe sous Windows, et ma base sur un disque dur externe. Il m’est arrivé de transporter le disque avec la base séparément, pour transférer des karaokés sur les ordinateurs et bases d’autres personnes qui n’ont pas forcément KM installé. En plus de ça, il m’arrive de chercher des .ass directement dans le finder de windows, pour en faire des copies pour créer des karas enfants, ou pour les exporter pour d’autres projets. Pareil pour les vidéos, il y a certaines dont j’ai du faire des copies pour les modifier (-tousse- oui, les problèmes de compression. J’espère avoir appris ma leçon, pour le coup.)
Il y a plusieurs manipulations qui restent plus pratiques à faire à travers le finder, notamment pour rechercher plusieurs karas d’une même série dont le nom est sur le fichier.

  • Ecrire un fichier texte dans le dossier medias . Ce fichier aurait la liste des KIDs avec en face le nom du kara. Ca pourrait ^même être un CSV pour être triable dans un tableur si vous voulez.

Cela rend le fait de trouver des karas plus difficile. Il faudrait ouvrir le fichier, ctrl+f ce qu’on veut, retourner dans le finder pour chercher le KID correspondant, rincer répéter…

  • Indiquer le KID du kara sur son Karadetail côté opérateur et côté systempanel quelque part afin que l’on sache rapidement quel est le KID à modifier à la mano si vraiment on doit le faire à la mano, par exemple pour réencoder.

Même problème que soulevé au dessus + il faudrait ouvrir KM (donc l’avoir installé sur le poste sur lequel on travaille.) Mais je me demande si indiquer le KID du kara quelque part sur sa fiche ne pourraît pas être utile pour d’autres cas? (Rien qui me vienne en tête, par contre)

  • Avoir une option pour créer un dossier de symlinks des paroles et des médias . En gros, pour les non-initiés, un symlink est un lien symbolique dans le système de fichiers. C’est très utilisé sous Linux, moins sous Windows (parce que un peu contraignant) mais l’idée c’est quand on veut qu’un dossier par exemple soit dispo à deux endroits simultanément on crée un lien symbolique à la place qui pointe vers le fichier original. C’est un fichier spécial, et quand on y accède (en lecture/écriture) on accède en fait au fichier original même s’il n’est pas dans le même dossier. Sous Windows c’est pas implémenté de la même façon mais l’idée est là : créer un dossier “medias-symlink” à côté du dossier medias contenant les fichiers sous forme de UUIDs.mp4 . Le dossier symlink aura lui les noms de fichiers à l’ancienne. Et ce “lien” sera MAJ par KM à chaque modification de la bdd/génération. Ca pourrait palier au problème du “je veux voir les noms de fichiers legacy ” mais je doute un peu de l’utilité.

Pas sûre d’avoir compris. Ca serait comme des raccourcis renommés? Est-ce que t’as des exemples de ça que je peux regarder sur windows pour avoir une meilleure idée? S’il y a un moyen d’avoir ces fichiers qui permettent de faire les manipulations que j’ai souligné au-dessus, ça me paraît pas mal.

  • Avoir un bouton “Ouvrir le média” dans le systempanel
  • Avoir un bouton "Selectionner le média dans le finder/explorateur dans le systempanel.

Je mets les deux suggestions ensemble, je préfère la deuxième. Je pense que ça peut être bénéfique de toute façon, comme il y a cette option pour les .ass. Ca nécessiterait tout de même d’avoir KM installé sur le poste et de faire les manipulations une à une.

  • Une interface simplifiée pour FFMPEG pour faire des réencodages éventuellement. Il faudrait pour ça analyser quels paramètres sont variables et qu’on pourrait executer sur le média, voir proposer d’entrer la ligne de commande soi-même. On peut imaginer un truc comme ça simplifier aussi pour ajouter une cover à un mp3 par exemple.

…???

  • Pour les gens qui utilisent pas KM mais la base on pourrait imaginer un script de renommage généré à chaque changement de la base afin de permettre à quelqu’un de renommer tous les UUIDs en noms de fichiers**. Après ça pose un souci potentiel de conflit : imaginons que deux KIDs donnent le même nom de fichier au final.

Ca peut être intéressant, est-ce qu’il y a un moyen de renommer les fichiers en [nom de fichier (1) [nom de fichier (2)] s’il y a des conflits?

Autrement, l’option proposée par meuhlake pour sélectionner plusieurs karas et exporter un .zip avec les noms de fichiers selon le template actuel semble pas mal.

Pour reclarifier, quels sont les problèmes avec le système actuel? Dont je me souviens:

  • Majuscules/ minuscules sur Windows
    → Est-ce qu’il y a un moyen de régler ça en modifiant les fichiers par étapes? Par exemple en modifiant un nom de fichier une fois en quelque chose de différent
    ([Nom du kara (temp)], que sais-je),
    puis en le remodifiant avec le vrai titre les majuscules appropriés?
    ([Nom du Kara]).
    (Merci Windows!)

  • Versions alternatives d’une même chanson qui se retrouveraient avec le même nom de fichier.
    → C’est embêtant, mais d’un côté, spécifier “~[…] vers.” dans le titre du kara permet également de distinguer les deux versions plus facilement au premier coup d’oeil.

Après vous aurez compris, mes suggestions se font du point de vue de quelqu’un qui n’a pas touché une ligne de code sur le logiciel, donc je sais pas qu’est-ce qui est faisable ou pas.

7

Le problème de détecter les renommages de majuscules/minuscules c’est qu’au final on se prend la tête pour corriger des bugs de WIndows.

En fait tu as pas vu ce que j’ai posté sur le canal Discord mais que j’ai pas reporté ici il est vrai :smiley:

En gros, ne plus renommer les fichiers sauf si la personne qui fait l’edit le mentionne explicitement dans le formulaire du kara.

Ca résoudrait beaucoup de soucis cités plus haut. Par contre ça laisse quand même beaucoup de code. Par exemple qui sert à nommer les fichiers correctement, etc.

8

Je reposte ici les différents soucis répertoriés:

  • Le kara qui une fois éditer se retrouve avec le même nom que l’ancien parce qu’on a oublié de cocher la version alternative hein @fabthehedgehog ? :slightly_smiling_face:
  • Les différences de majuscules/minuscules quand on change le nom d’un kara parce qu’on est un petit peu maniaque (hein @Kmeuh ? :slightly_smiling_face: )et comme Windows ne gère pas la différence on se retrouve avec un pipeline pêté.
  • Les gens qui modifient les fichiers de la base sans passer par KM. Qui sont-ils, quels sont leurs réseaux ? Là au moins pas de risque de pêter le pipeline en éditant un fichier kara.json à la main pour aller plus vite.
  • Le kara qui a un caractère relou dans son nom qu’on a pas vu et qui est interprêté différément sous Windows, macOS ou Linux. Joie.
  • Les karas avec des titres+séries beaucoup trop longs parce que certains OS ne gèrent pas plus de 255 caractères pour un nom de fichier par exemple
  • Live qui marche pas quand la vidéo et le sub ont pas le même nom pour une raison X ou Y
9

Proposition de Meuhlake puis de moi et @Lasagna :

“Exporter les chansons” depuis une playlist créerait les bons fichiers dans un dossier de notre choix (avec un .m3u limite tant qu’à faire)

En gros ça copie les uuid.mp4 et .ass sous forme de noms de fichiers lisibles (en gros comme on fait actuellement) dans le dossier du choix de l’utilisateur.

Ce qui répondrait à son besoin à elle en général.