Chose promise, chose due, voici enfin le petit utilitaire abordé dans un précédent billet et qui permet d'historiser les pistes jouées par MPD afin d'en garder une trace dans un fichier texte ou dans une base de données.
Laissez-moi vous présenter : JMPDLogger (pour Java Music Player Daemon Logger).
Mais resituons le contexte : vous utilisez maintenant MPD pour diffuser votre radio personnelle, jouant la totalité de votre mp3thèque (ou oggthèque) en aléatoire. Vous écoutez donc tous ces titres depuis n'importe où, chez vous, au boulot, voire même depuis votre smartphone (mouais)...
Sékoicetitre (et son pote Sétékoicetitreyadeuminutes) ?
Sauf que quand vous tombez sur une piste que vous trouvez super bien, que vous ne la connaissez pas, et que celle-ci n'est pas correctement taggée (voire pas du tout), la seule solution est de vous connecter en vitesse au serveur par SSH puis de taper
$ mpc -f %file%
pour connaître le chemin vers le fichier en cours. Très franchement, c'est laborieux. Surtout que parfois on n'a pas de connexion SSH sous la main, ou bien le temps qu'on y arrive la piste a déjà changé.
Après maintes recherches sur la Toile, je n'ai pu trouver aucun petit système simple et propre permettant d'historiser les titres lus par MPD afin d'en conserver une trace horodatée. J'ai alors commencé à pallier ce manque par des petits scripts shell cronés mais c'était loin d'être efficace (il fallait détecter les changements de piste à l'exécution et ne pas logger plusieurs fois la même piste si elle était longue).
Je me suis donc mis à développer un petit outil pour effectuer ce job. Cela m'a permis aussi de retoucher à du Java et j'avoue que j'y ai pris beaucoup de plaisir (après le PHP de Magento sous Zend Studio pour manger, la comparaison est impossible). Ce fût encore plus simple que prévu une fois la bibliothèque JMPDComm récupérée proposant déjà toute l'abstraction nécessaire à la communication avec le daemon MPD.
Le log vers un fichier plat est sympathique et toujours appréciable pour sa versatilité, mais je préfèrais avoir plutôt (ou en plus) comme support une base de données. Plus pratique pour faire évoluer ensuite les fonctionnalités de consultation. J'ai donc implémenté un système très basique d'appenders spécialisés pour chacun des cas, et activables depuis un fichier de configuration.
Configuration de JMPDLogger
Pour télécharger JMPDLogger c'est ici (et les sources sont ici).
Le fichier de configuration (dont un exemple est présent dans l'archive) se présente comme ceci :
;================================================
;Global configuration
;================================================
global.host=127.0.0.1
global.pollingDelay=2
global.playlist.fileSeparator=/
global.errorLog.path=/var/jmpdlogger/error.log
;================================================
;Formatter/Parser/Appenders
;================================================
global.formatter=nnwl.jmpdlogger.formatter.SimpleFormatter
global.parser=nnwl.jmpdlogger.parser.SimpleParser
global.appenders=nnwl.jmpdlogger.appender.LocalFile,nnwl.jmpdlogger.appender.Db
;================================================
;Helpers-dependant properties
;================================================
nnwl.jmpdlogger.formatter.SimpleFormatter.lineFormat=%now% | %pos% | %artist% - %album% [%track%] %title% (%formatedTime%) | %fullpath%
nnwl.jmpdlogger.formatter.SimpleFormatter.dateFormat=yyyy-MM-dd'T'HH:mm:ss.SSSZ
nnwl.jmpdlogger.appender.LocalFile.path=/var/jmpdlogger/tracks.log
nnwl.jmpdlogger.appender.Db.connectionString=jdbc:mysql://127.0.0.1/jmpdlogger
nnwl.jmpdlogger.appender.Db.user=my_user
nnwl.jmpdlogger.appender.Db.password=my_password
Les directives dans la première section sont assez explicites, je me contenterai de préciser que la valeur global.pollingDelay définit en secondes la période séparant deux interrogations de l'état du daemon MPD. Il n'y a a priori aucune raison de la changer.
Le seconde section définit les classes helpers qui seront utilisés lors de l'exécution. Il ne peut y avoir qu'un formatter, qu'un parser, mais plusieurs appenders. Ici il y a un log vers un fichier et un autre vers une base de données.
La troisième et dernière section enfin, permet de configurer les helpers définis précédemment. On précise le format à utiliser par le formatter, le chemin vers le fichier cible pour le appender de type "fichier", et les informations de connexion pour celui de type "base de données".
À noter qu'il est possible d'utiliser MySQL et PostgreSQL en utilisant le bon JAR(1) et en précisant "mysql" ou "postgresql" dans la ligne :
nnwl.jmpdlogger.appender.Db.connectionString=jdbc:mysql://127.0.0.1/jmpdlogger
Les requêtes SQL de création de l'unique table utilisée sont fournies dans l'archive, dans le répertoire "/resources". Les deux formats sont proposés. La création de l'utilisateur et de ses permissions sont évidemment à la charge de l'utilisateur.
L'application se présente donc comme un JAR exécutable, prenant en paramètre le chemin vers le fichier de configuration. La commande sous Linux ressemble donc à (si vous avez copié le fichier de configuration dans /etc):
$ java -jar jmpdlogger.jar -c /etc/jmpdlogger.conf
Sous Windows, à condition que le PATH soit bien positionné et le JRE installé, la commande est similaire (le chemin vers le fichier de configuration sera par exemple dans C:\jmpdlogger\jmpdlogger.conf au lieu de /etc/jmpdlogger.conf)
Installation en tant que daemon
Mon principe ici était d'en faire un daemon également, installé sur la même machine et qui surveillerait MPD en notant scrupuleusement la playlist au fur et à mesure de son avancement. Comme j'utilise la fonction random sur la liste triée de ma bibliothèque, je ne connais pas à l'avance le prochain titre (et c'est tant mieux).
Cela étant, il n'est pas nécessaire d'installer ce logger sur la machine exécutant MPD, pas plus qu'il n'est obligatoire qu'elle soit sous Linux. Le fonctionnement est similaire depuis un client Windows externe par exemple, à condition que le port 6600 (par défaut) du serveur soit accessible. On adaptera seulement la directive global.host en conséquence (en précisant éventuellement le port si différent de 6600 avec la syntaxe standard IP:PORT).
Bien évidemment, dans mon cas tout est sous Linux. J'ai donc créé un script de démarrage dans /etc/init.d puis exécuté un petit update-rc.d (je suis sous Debian) pour que le processus soit lancé au boot. Ce script est disponible dans l'archive sous le nom jmpdlogger.init.sample, il suffit d'adapter les chemins et paramètres si ceux fournis ne conviennent pas.
Dans la configuration proposée par défaut :
- le binaire jmpdlogger.jar est placé dans /usr/local/bin,
- le fichier de configuration jmpdlogger.conf dans /etc,
- le fichier de log de la playlist nommé tracks.log est placé dans /var/jmpdlogger ainsi que le log des erreurs (errors.log).
On pensera à vérifier que les droits sur ces fichiers et dossiers sont adaptés à l'utilisateur exécutant le processus défini dans le script de démarrage (par commodité, je le fais tourner sous le compte "mpd", déjà créé et utilisé par le daemon mpd).
Téléchargements
JMPDLogger-0.2.5.tar.gz (contient les JARs pour MySQL et pour PostgreSQL)
JMPDLogger-0.2.5-src.tar.gz (sources)
Comment consulter l'historique : JMPDLoggerWeb
C'est très simple, grâce au viewer spécialement développé pour JMPDLogger. C'est une simple interface web codée en PHP, moche d'apparence (j'en conviens, c'était presque un objectif ^^) mais ultra-légère et skinnable au besoin.
Le rafraîchissement régulier est automatique et en plus de l'historique complet il est possible de consulter quelques statistiques (quel album a été le plus souvent joué, quel artiste, nombre total de pistes jouées).
La configuration de la connexion à la base de données (MySQL ou PostgreSQL) se fait en renommant le fichier config.inc.sample.php en config.inc.php et en éditant les valeurs classiques host, user, password, etc dans celui-ci.
Petit bonus, si vous avez installé mpc sur le serveur hébergeant MPD/JMPDLogger/JMPDLoggerWeb, vous pouvez utiliser l'interface de ce dernier pour contrôler MPD via les boutons PAUSE/LECTURE/SUIVANT situés dans le coin droit en haut de la page, classe !
Téléchargements
(1) C'est un mystère que je dois encore éclaircir : il n'est pas possible d'inclure 2 drivers JDBC différents dans un JAR, le second étant simplement ignoré et on se retrouve avec une exception "No suitable driver found for ...". Cela viendrait de la structure du dossier //META-INF/services/java.sql.Driver contenu dans le JAR (il ne pourrait y avoir qu'un seul fichier de ce nom).