Il y a quelques jours le scrobbling de mon last.fm perso c'est arrêté pour cause d'erreur SQL bien foireuse. Ayant un peu la flemme de débugguer du code legacy-de-chez-legacy, je me suis dit que c'était l'occasion du passé de faire table rase, et de passer de MySQL à un vrai SGBD.
Je relance donc une installation de gnukebox, afin de créer la structure de la base, puis je crée un utilisateur. Reste à exporter les données de last.fm...
Et c'est là que ça se corse: le script d'export n'est visiblement pas capable de ramener plus d'une page, soit cinquante scrobbles par défaut. Et si on augmente le nombre de scrobbles au dela de mille, on se prends une erreur fatale du serveur. Bref, je suis pas arrivé avec mes 128 000+ scrobbles moi !
J'ai fini par trouver un script corrigé en python3 qui lui ramène tout, même si c'est très lent (une page par seconde, limité par l'API). Un autre script était beaucoup plus rapide mais ne générait pas un dump formaté pareil, donc je n'ai pas tenté.
J'ai un peu déchanté durant l'import dans la base de donnée, car le fichier n'est pas trié par date, et surtout que ladite date...est une date: et comme ce n'est pas un timestamp, c'est bien galère à trier (bienvenue au XXIème siècle). Effet de bord , la reprise du scrobbling à généré une cinquantaine de doublons (une page, si vous avez suivi...) car il semble comparer la page de résultat aux derniers enregistrements en base,qui, manque de bol, ne sont pas à la fin.
Bref ça sera bien suffisant, après tout les doublons sont une plaie pas si rare chez last.fm, on va donc pas se pleindre.
Reste encore à corriger les panneaux Grafana, ça va me faire pratiquer le SQL tiens (joie...)