RockHeaven

A personal music library of hundred-track volumes, with a desktop player, a web player and a phone app over it. Started as a copy of RockHaven.Player; the Avalonia player that came out of that has since been replaced by the Qt one.

Projects

• RockHeaven.Server — the API over the library and the web player on top of it. The one program that opens the database and the mp3 files.
• RockHeaven.Core — the supporting library: the PostgreSQL database (EF Core) and the domain services it builds on. Only the server references it.
• RockHeaven.Common — the wire contracts, the volume arithmetic and the configuration and logging layers.
• RockHeaven.Qt — the desktop player, Rust + Qt (QML) over the server's API, with its own Cargo build and its own CLAUDE.md. Not in the solution.
• RockHeaven.Android — a React Native app over the same API, with its own build and its own CLAUDE.md. Not in the solution.

Build and run

dotnet build RockHeaven.sln
dotnet run --project RockHeaven.Server   # the library; every player needs it

The desktop player builds with Cargo from RockHeaven.Qt/ — see its CLAUDE.md.

Configuration

appsettings.json in the repository root is copied next to the binary on every build. It names the music folder the collections sit in, the address the server listens on, and the Serilog sinks.

Nothing secret goes in it — it is in the repository. The database connection string, the fanart.tv key and the credentials for sending a login code live in ~/.config/rockheaven/settings.json, or in the environment (DatabaseSettings__ConnectionString, SmsSettings__Password, …), which is how the container is told.

Signing in is a code sent by mail or text message to somebody in the users table; there is no shared password. The first row goes in by hand — see CLAUDE.md.

The database user needs to own the schema, which on PostgreSQL 15 and up it does not by default — dotnet ef database update fails with 42501: permission denied for schema public otherwise. CLAUDE.md has the two lines that fix it.

Release

Pushing to main runs the workflows under .forgejo/workflows/, which publish framework-dependent linux-x64 tarballs to Forgejo releases tagged server-v<n>, qt-v<n> and android-v<n>. The server workflow also builds and pushes the Docker image out of the same publish. The prefixes matter: the build number is per workflow, so two projects releasing under a bare v<n> would overwrite each other.