Eliot Berriot
Follow

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

So, what's next?

First, there are still some things to implement, especially, right now, we're importing by hand, but it can be completely automated. I have to work on that part.

Also, the front-end part to administrate the federation still miss some features/views.

This should be done by the next release though!

Also, on the example video, the files are never hosted on your instance unless you listen to them. Basically, the first time you listen to a federated track, the track is downloaded from the source instance and cached on your instance.

It's removed after a configurable duration, meaning you can federate with a lot of instance without eating to much disk space.

@eliotberriot Ouais, ça a l'air vraiment cool.
Y'a beaucoup d'instances ? Faut que je teste ça en auto-hébergement, j'ai des dizaines de Go à partager avec les potes :)

@eliotberriot Ah, et sinon j'adore le nom :)

Et tu devrais remettre l'url à chaque fois...

@nicod_ pour l'instant il y a quatre ou cinq instances qui sont up je crois, mais la seule qui est publique et ouverte c'est funkwhale.mastodon.host/, gérée par @gled

@eliotberriot @gled J'ai un vieux NAS synology, faut que je voie si je peux le réinstaller pour faire tourner funkwhale et d'autres trucs en auto hébergement du coup.
Je vais regarder ça ce WE.

@nicod_ génial, hésite pas à passer sur riot.im/app/#/room/#funkwhale: pour discuter de tout ça et poser tes questions.

Je sais pas si funkwhale tournera sur Synology, ça sera intéressant de tester :D

@eliotberriot Je pense pas m'emm... avec DSM mais installer une debian dessus, pour avoir les mains libres.
Pour le plaisir de bricoler quoi :)

Une autre question : n'importe qui peut venir écouter de la musique sur une instance funkwhale ? on peut gérer des autorisations ? Le but c'est aussi de filer l'adresse aux copains pas geeks, voir qu'ils puissent participer en uploadant aussi...

@nicod_ il va y avoir du boulot sur les permissions dans un avenir proche mais d'ores et déjà voici ce que tu as par défaut avec ton instance funkwhale:

- Un contrôle sur qui peut écouter la musique : tout le monde, même anonyme, ou seulement les utilisateurs authentifiés.
- Un contrôle sur les inscriptions: ouvertes ou fermées
- Un contrôle sur qui peut importer de la musique dans l'instance (il faut rajouter les permissions aux personnes concernées)

@nicod_ donc tu peux tout à fait mettre ton instance à disposition pour des ami.e.s ou de la famille :)

@eliotberriot En train d'installer une debian jessie en chroot sur mon NAS synology (qui est en DSM 4).
Ça peut marcher tu crois ?

@eliotberriot Ah mais je suis bloqué par le kernel du NAS, qui reste en 2.6 😕
DSM 6 peut être ?
Je tente...

@nicod_ euh je sais pas du tout. Funkwhale tourne de source sûre sur Jessie, donc a partir du moment où ton install est propre et ou tu peux installer les dépendances, je pense que ça devrait le faire ?

@eliotberriot
Pas pour Docker apparemment, qui demande un kernel au moins 3.2, et j'étais en 2.6
En train d'upgrade le nas...

@nicod_ après tu peux faire tourner funkwhale sans docker. Mais dans tous les cas, 2.6, ça commence à dater un peu, donc c'est peut-être pas plus mal d'upgrade.

@eliotberriot
Merci, j'ai mal lu effectivement. Mais la mise à jour fera pas de mal.

@eliotberriot Ah ben ça répond à ma précédente question :)

@eliotberriot Ça répond à mes interrogations avant même que je les pose :)

@Panda_Fuligineux je suis assez content du résultat oui, c'est fluide. Après là je suis en local, il faudra tester dans la vraie fédération, mais déjà si ça tourne bien en local c'est pas mal :p

@eliotberriot Wow ! Bravo ! Faut vraiment que j'essaye.
On peut écouter des morceaux d'une autre instance sans les "télécharger" chez soi ?

@eliotberriot OMFG so its a decentralized soundcloud, isnt it ? 😍

@adidal yes, it is (I was more of a grooveshark user, so this was my target :D).

Note that this work is still not merged/released. It should happen pretty soon!

@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.

@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 ?

@eliotberriot Ça m'intéresse carrément ce projet, j'en avais jamais entendu parler encore. Il y a des instances ouvertes aux inscriptions ou pas encore ?

@satak si tu as besoin, voici le site du projet, avec un lien vers la démo : funkwhale.audio/

Tu peux également t'inscrire sur l'instance publique funkwhale.mastodon.host/, qui est à ma connaissance la seule instance en accès libre.

Par contre la bibliothèque n'est pas très fournir encore, mais ça te permettra de tester :)

@eliotberriot That looks really fucking cool, congratz on the work and handing all the bunches of invisible stuff !

@eliotberriot
Be sure I'll spent some time helping to package your app for #YunoHost :) Bravo !

@jibec
That would be really great, it was requested by a lot of people but I lack the time and knowledge to do it!

@eliotberriot
Well, when I'll try, I'll ask you many questions. For now, if just publish releases and a minimalist documentation, it will be enough.

@eliotberriot
Well, this is too much, now I feel like doing it before RMLL, stop teasing me ;)

@cwebber
Yes, I'm sorry I forgot to mention you about that! Funkwhale will be using activitypub soon to federate music libraries accrues instances :)

Sign in to participate in the conversation
Mastodon

mastodon.eliotberriot.com is one server in the network