My release schedule is so out of wack that here’s another release 3 days later! 0.5.x is practically an LTS at this point
Bad news: Radios with listen ranges are broken
Good news: I fixed it
Bad news: It’s not until 0.6.0 and I still have tons of stuff to do.
Although it comes with a nice visualization to show you how much I missed some tracks (A score above 2 is bad)
With a little +1,609 −1,142 diff, you can now sort all entities by listened duration. Results may surprise you! (And finally get rid of those pesky OST albums that are full of 1 minutes tracks that get shoved to the top even if you don’t listen to them that much).
Joke aside, this is actually a big refactor to allow customizing how entities get linked to listens. This means being able, for example, make listens count for remixer artist, add sample recordings, etc…
So expect a few updates to the stats soon
Builds are frying, and should soon be available
You can now get tag stats.
Greatly improved recording stats compilation times (again). Now it should be pretty much instant
The repository migrated to a classic github flow architecture as github really doesn’t want to have anything else… So for those with a local clone of the project:
To rename your local develop branch, you can use:
git branch -m develop master
git fetch origin
git branch -u origin/master master
git remote set-head origin -a
Builds are simmering, and should soon be available
wrong-mapping now correctly link to your user’s listens instead of mineunless you’re @Maxr1998, you can skip this one 
I’m not sure if I’m doing something wrong but when I use the radio overdue or daily commands Alistral starts fetching recordings and it says that the ETA is 1/2 hours (237 recs). Is this right?
Yup. That seems fine to me.
To calculate the stats (used in the commands) I need to know what each mapped MBID correspond to which recording… Meaning I need to fetch every listened recordings… At one fetch per second…
Mine’s 1h15 long last time I tried. Luckily it’s all cached and will be preserved between runs (except the 20 oldest of each entity, so that the data doesn’t get stale)
Sadly I can’t just ask for better rate limit as my app doesn’t have a fixed IP since it runs on the client. Maybe one day I’ll add the possibility to add mirrors as alternate apis but I don’t have a mirror myself (nor the storage for one)
Builds are slow cooking, and should be available soon
This is fantastic. Rust is a a bit low-level for my blood, so I was trying to think of other ways to contribute. I was gonna set up a formula on Homebrew to make it easier for folks to install and keep updated, but they want to see a bit more social engagement with the Github repo (stars, watchers, forks, etc). Get on it, folks!
Thanks. But yeah, currently it’s a one person passion project sadly…
More package manager options are always welcome though, as I don’t use many platforms and thus cannot guarantee my package builds.
… And debian’s process is so confusing that I gave up on that front.