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.

Projects

• RockHeaven.Player — the Avalonia GUI: views, view models and the player-only services (mpv playback, API client, theme, fonts). It is a client of the server and holds no database of its own.
• 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, shared by all three.
• 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; the player needs it
dotnet run --project RockHeaven.Player

Playback shells out to mpv, so that has to be installed.

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, the address the player talks to, 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 player-v<n>, server-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.