I have this impression because of some initially different decisions to a self-hosted architecture (where you usually have not that powerful machines at home), it feels like a proprietary original service they replicate, which is designed to serve millions of users off beefy machines. And because of how rapid the development is. I’d be surprised to learn it’s not heavily vibe coded, considering all the aspects of the project.

I did not disable all the features, because I had to pick a beefy server for it, otherwise I’d started using the project years ago (I’m only months in). I confirm, it was super slow first days (I have about 500 GB library), then it settled down. I’d love it to be designed around comfortably living on a cheap weak hardware, as I believe just accessing my library (and not processing it) should be trivial. I just hope against hope that would be possible at some later stage of the development. Perhaps that is possibly today, I haven’t investigated too much. But I guess the documentation would cover it then.

Yeah, I agree. That’s an interesting phenomenon.

I haven’t investigated, that’s my personal impression based on the architecture I think wasn’t given much thought (self-hosting and proprietary service for millions users with expensive hardware are very different) and how hungry it is for resources. I’d love to be very wrong here. Overall, despite me thinking it’s heavily vibe coded, I still make an exception for it and use it and recommend it, as it’s useful and truly easy to use. I just accepted the fact I need a beefy computer to host, instead of processing it on a beefy computer and then hosting on a NAS.

I’d love these two to be separated, so I could utilise my powerful PC to process everything, and then it would live on the NAS / SBC / anything smol.