Eliot Berriot is a user on mastodon.eliotberriot.com. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

It's been a while since my last post on the subject, but here are some exciting news about : the is actually usable now, as shown in the video below:

1. We follow another instance
2. We scan it's library
3. We import some tracks from it
4. We play those tracks from our own instance

You can't imagine how happy I am to see this actually working, after weeks working on the protocol/invisible stuff!

mastodon.eliotberriot.com/medi

@eliotberriot Une des questions que je me pose, c'est si on peu isoler 'sa' base de donnée musicale. Je suis ok pour partager mes métadonnées et mes fichiers, pas de souci, bien au contraire. Je suis ok pour accéder à des métadonnées et des fichiers externes, et de les écouter. Mais je suis très pénible sur la qualité de mes métadonnées, du coup je ne voudrais pas mélanger n'importe quoi avec ma collection.

Alors, si je peux distinguer, déjà sur l'interface, entre ce qui est local et ce qui ne l'est pas, par exemple pour la recherche, c'est bien. Il me semble que peertube permet ça. Et si les fichiers importés se retrouve dans un dossier séparé du mien, c'est encore mieux.

De même, dans subsonic, les fichiers uploadés par les utilisateurs ne sont pas versés dans le même dossier. J'aime bien ça, ça me permet d'importer les fichiers ensuite, avec mes critères. Qui ne sont pas vraiment compatibles avec MusicBrainz, qui, de plus, trop souvent ne connaît pas les disques que je décris, mais c'est une autre question.

Bref, je suis très, très curieux de #funkwhale, et super content que ce projet existe, et je me réjouis de l'essayer. Pour l'instant, c'est surtout le proxy Nginx qui me retient et aussi le fait que, si j'ai bien compris, le FLAC n'est pas (encore) supporté.

Cette histoire de gestion de ma collection m'intéresse beaucoup. Parce que celle-ci est plutôt volumineuse (4'500 artistes, 4'200 albums, 52'000 fichiers), et évolue constamment. Et j'y accède soit en local via gmusibrowser, soit en streaming via subsonic. C'est donc un disque distant monté sur différentes machines. Et j'aimerais continuer à m'éviter de gérer deux collections distinctes et simplifier les backups. Or, actuellement, en local je ne vois pas me passer de gmusicbrowser, parce qu'en plus des tags ID3, utilisés de manière déjà très performante, il y a une gestion par étiquette qui me permet de faire des tris assez fins.

Ce qui me fait penser à la fonction recherche de funkwhale. On peut faire des recherches complexes? Par compositeur, par genre, par date de publication, d'ajout, par note?

Désolé pour le gros pâté… Il ne reflète que mon intérêt pour ce projet. 😉

@igor je suis limité à 500 caractères par message donc je vais te répondre en plusieurs messages :p

Au niveau base de donnée, ce qui vient de la fédération et ce qui vient de la collection locale de l'instance est stocké de façon identifiable et exploitable. Il n'y a pas de contrôles pour le moment, mais c'est techniquement simple de filtrer seulement les pistes locales dans la recherche, par exemple.

Eliot Berriot @eliotberriot
Follow

@igor pour nginx et le flac, tu n'es pas la première personne à me remonter ça. Ce sont des problèmes ou des manques connus, mais j'ai manqué de temps ou de compétences (pour Apache) pour les traiter jusqu'à maintenant.

Une option en attendant d'avoir un config apache propre, c'est de faire tourner le nginx dans du docker (je l'ai fait avec quelqu'un, ça fonctionne), et d'utiliser apache comme reverse proxy devant.

@igor concernant ton besoin, à savoir ne pas dupliquer ta collection, là aussi, c'est un problème connu, (cf code.eliotberriot.com/funkwhal).

Pour le moment, funkwhale copie les fichiers à l'import, ce qui est bloquant dans ton cas. Cela va changer dès qu'on aura bosser sur ce ticket, qui permettra de laisser le choix à l'utilisateur (on copie ou pas).

Cela va demander un peu de changements, mais je suis assez confiant dans le fait qu'on va arriver à le faire sans trop de problèmes.

@igor dernier point (si je n'ai rien oublié), sur la qualité des métadonnées stockées dans Funkwhale : on est clairement en deçà de ce que tu décris. On stocke relativement peu d'informations.

Le bon côté c'est que l'on stocke les identifiants musicbrainz systématiquement (dans la mesure où on les a), donc on peut facilement récupérer ces infos.

Mais il faudra rajouter des champs dans me schéma de base de données de funkwhale, et aussi implémenter la recherche correspondante.

@igor je ne te cache pas que ce dernier point n'est pas une priorité *pour le moment*, vu tout ce qu'il y a faire sur d'autres aspects.

Cela ne veut pas dire que cela n'arrivera jamais, mais je préfère être réaliste, vu qu'on est assez peu à contribuer du code pour le moment :)

@eliotberriot Alors au moins 3 de tes réponses me réjouissent ! C'est bien entendu la dernière qui le fait moins. Je ne me rends pas compte de la complexité qui se joue à ce niveau, mais pour les collections un peu conséquentes, c'est vraiment utile. J'avais joué au boulot, avec un framework utilisant Elasticsearch (Invenio) à parser les tags ID3 de ma collection et de les indexer, c'est un vrai plaisir… ensuite. :) Ça se basait sur un jsonschema, notamment.

Mais comme en streaming, pour l'instant, mes utilisateurs et moi-même arrivons à se contenter de subsonic, funkwhale doit déjà faire le boutot. :)

Pour le reste, je suis bien content de voir que ce sont des questions déjà connues, voir abordées. Pour la base de données, la distinction ne se fait qu'au niveau postregsql, ou est-ce qu'il s'agit aussi de dossiers séparés ?

Pour mes premiers tests, j'envisage même de transcoder une partie de ma collection en OGG, pour pouvoir jouer. Et j'ai quand même pas mal de MP3 aussi… 😉 Du coup, le truc du Nginx dockerisé avec Apache devant, ça pourrait bien m'intéresser.

Merci pour tes réponses !

@igor pour moi, la difficulté ne réside pas tant dans la partie indexation/recherche que dans la partie interface, car offrir des recherches avancées sur des filtres complexes ça demande du développement, surtout si on ne veut pas déstabiliser les personnes qui ont une utilisation plus simple.

@igor

Au niveau stockage, on a les métadonnées qui sont dans postgresql, effectivement, et les fichiers audio, qui sont dans un dossier sur le serveur. Mais par défaut, les fichiers fédérés ne sont pas répliqués sur le serveur (enfin dans un dossier de cache, mais sur des périodes courtes).

Du coup, aucun risque de mélange avec tes collections :)

@eliotberriot Ok, je comprends. Voilà qui me rassure. :D
@eliotberriot Oui, je comprends. D'autant que la recherche avancée n'est utilisée que par peu d'utilisateurs…

@igor surtout que souvent il y des softs spécialisés qui font ça très bien. Après il y a peut-être d'autres façons d'aborder la question, par exemple en exposant les données via API et en intégrant ça avec un client existant ?