Never thought about it. Is there an inside joke am i missing @@

Hahaha WTF.

Is Rust that much better than Go?

IMHO, rust and go are two differents things. The reason I choose Rust is because it is fast and calling C code from rust is supported really well since Rust's goal is to become a system language. Navidrome is just calling the ffmpeg binary. While in my project, I've compiled the neccessary parts of ffmpeg myself (thanks to vcpkg) and call the function directly from Rust. It leads to smaller and fully static final binary (because no ffmpeg bin) as well as faster transcoding time since we don't have to wait for the ffmpeg binary to finish transcoding the whole file before load the result from the filesystem to the memory.

Would it have been impossible to submit your changes to Navidrome as pull requests?

You can see here. This is the biggest reason why I've decided to start my own implementation. Beside, I share my server with several friends so I want a mechanism to prevent mixing musics from different people.

Does this import the Navidrome database?

This could be a feature request in the future. I could add a python script to import users/songs/playlists/playcount/etc from Navidrome.

Thank you! Please give it a try and give me some feedbacks XD

Here you go. But setting up a testing environment on github actions is too hard so it is built only for now.

Edit: test is added now

I am trying adding a FreeBSD CI. Will let you know later if it is working or not

In the opensubsonic response there will be two fields for artist, one is artistid with only one artist (this is for compatible with old subsonic) and the other is artists with a list of artist ids. The server only sends back the list of artists ids and only these two clients read that field.