It's been a while since my last post on the subject, but here are some exciting news about #funkwhale: the #federation 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!
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.
Ping @nicod_@mamot.fr :D cf mon message précédent ;)
@eliotberriot Excellent
@eliotberriot c'est si beau *_*
@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 Youyouyouyou
@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!
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 https://code.eliotberriot.com/funkwhale/funkwhale/issues/153).
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 :)
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.
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 :)
@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 : https://funkwhale.audio/
Tu peux également t'inscrire sur l'instance publique https://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 merci à toi, je fonce voir ça ;)
@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.
@jibec
You should find some answers and starters here : https://docs.funkwhale.audio/ 😃
@eliotberriot
Well, this is too much, now I feel like doing it before RMLL, stop teasing me ;)
@eliotberriot Bravo ! C'est vraiment super ! :-)
@eliotberriot wait whoa https://medium.com/we-distribute/funkwhale-an-open-source-grooveshark-alternative-begins-activitypub-implementation-cbc10a412b20
there are a bunch of activitypub implementations in progress I apparently don't even know about now
@cwebber
Yes, I'm sorry I forgot to mention you about that! Funkwhale will be using activitypub soon to federate music libraries accrues instances :)
@eliotberriot that's awesome!
@eliotberriot i really like the interface btw
@teslawf
Thank you, I'm doing my best to make it usable and good looking :)
@donblanco thanks, there is an issue with the underlying Gitlab server, I'm looking into it!
@donblanco it should be good now!
@eliotberriot hey, sorry to hijack. Quick question: just discovered Funkwhale - can I setup locally an throw my audio files at this as a music player? Yours hopefully.
@ldexterldesign Hi, don't be sorry ;)
Funkwhale can run on any host that support Docker and on Debian platforms (it should work on others OS too, it's just not documented yet).
You can also import music files from a directory on the server (see https://docs.funkwhale.audio/importing-music.html#from-music-directory-on-the-server).
However, depending on what you mean by locally, it may be simpler to use a desktop music player or a smaller application instead, such as https://github.com/phanan/koel)
@eliotberriot Thanks for reply. Apologies for delay. Riiiiiggght, so FW is like a federated http://emby.media ? Yours hopefully.
@eliotberriot seems to have come a long way since last year - good job! Regards.
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!