funoteka 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +22 -3
- package/DEPLOY.md +23 -3
- package/README.md +2 -2
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -9,6 +9,21 @@ The version lives in exactly one place — `package.json`.
|
|
|
9
9
|
|
|
10
10
|
_(nothing yet)_
|
|
11
11
|
|
|
12
|
+
## [0.1.1] — 2026-09-17
|
|
13
|
+
|
|
14
|
+
### Fixed
|
|
15
|
+
|
|
16
|
+
- **The release pipeline verifies the package from outside the checkout, and on
|
|
17
|
+
the Node the package asks for.** `npx funoteka@<version>` run in the repository
|
|
18
|
+
root resolves the bin from the project it happens to stand in — whose own name
|
|
19
|
+
is `funoteka` — and reported `funoteka: not found` about a package that
|
|
20
|
+
publishes and installs fine; and the check ran on whatever Node the runner
|
|
21
|
+
ships, while the CLI needs `node:sqlite`. **No server code changed in this
|
|
22
|
+
patch:** `0.1.0` and `0.1.1` are the same program, and the image and the package
|
|
23
|
+
of `0.1.0` are published and verified. This is the release that proves the
|
|
24
|
+
pipeline end to end, taken as a patch because a tag whose verification is red
|
|
25
|
+
is not a release.
|
|
26
|
+
|
|
12
27
|
## [0.1.0] — 2026-09-17
|
|
13
28
|
|
|
14
29
|
First public release. A Subsonic-compatible server that reads whatever is on
|
|
@@ -88,14 +103,18 @@ folders happen to be laid out is not a question a client ever has to care about.
|
|
|
88
103
|
funoteka, and the same package carries the CLI (`scan`, `serve`, `stop`, `status`).
|
|
89
104
|
Node refuses to strip types from anything under `node_modules`, so the package ships
|
|
90
105
|
the sources compiled once at release — the repository itself still needs no build.
|
|
106
|
+
- **A published container image**: `ghcr.io/kzntsv-dev/funoteka:0.1.0` and
|
|
107
|
+
`:latest` — `linux/amd64` and `linux/arm64` in one manifest, so the main
|
|
108
|
+
install path needs no checkout.
|
|
91
109
|
- Daemon mode with `status` and `stop`, a pid file that is checked against the
|
|
92
110
|
OS rather than believed, and `DEPLOY.md`.
|
|
93
111
|
|
|
94
112
|
### Known limitations
|
|
95
113
|
|
|
96
|
-
- **
|
|
97
|
-
|
|
98
|
-
|
|
114
|
+
- **The `arm64` leg of the published image is built under emulation** on an
|
|
115
|
+
`amd64` machine, and the `Dockerfile` in this repository still builds on the
|
|
116
|
+
machine that runs it — the path taken where a published image is not wanted or
|
|
117
|
+
not reachable.
|
|
99
118
|
- **ffmpeg is needed for one case only:** cue segments inside m4a/ALAC. Without
|
|
100
119
|
it those tracks answer with error code 70 and everything else keeps working.
|
|
101
120
|
- **Some Subsonic endpoints are stubs** and say so instead of inventing an
|
package/DEPLOY.md
CHANGED
|
@@ -60,9 +60,29 @@ node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
|
|
|
60
60
|
|
|
61
61
|
## 3. Path A — Docker (main path)
|
|
62
62
|
|
|
63
|
-
Works the same on a laptop, a NAS and a VDS.
|
|
64
|
-
|
|
65
|
-
|
|
63
|
+
Works the same on a laptop, a NAS and a VDS. There is a **published image** —
|
|
64
|
+
`ghcr.io/kzntsv-dev/funoteka:0.1.1`, `linux/amd64` and `linux/arm64` in one
|
|
65
|
+
manifest — and `build: .` still builds on the machine that runs it (that is the
|
|
66
|
+
path where a published image is not wanted or not reachable).
|
|
67
|
+
|
|
68
|
+
With no checkout to build from, the image and four values are the whole
|
|
69
|
+
installation (verified by running exactly this against the published image):
|
|
70
|
+
|
|
71
|
+
```sh
|
|
72
|
+
MUSIC=/absolute/path/to/your/music
|
|
73
|
+
docker run -d --name funoteka -p 4533:4533 -p 4534:4534 \
|
|
74
|
+
-e FUNOTEKA_USER=you -e FUNOTEKA_PASSWORD=change-me \
|
|
75
|
+
-e FUNOTEKA_ADMIN_TOKEN=<the token you generated> \
|
|
76
|
+
-e FUNOTEKA_SUPERVISED=1 -e FUNOTEKA_LOG_FILE=/data/funoteka.log \
|
|
77
|
+
-v "$MUSIC":/music:ro -v funoteka-data:/data \
|
|
78
|
+
--restart unless-stopped ghcr.io/kzntsv-dev/funoteka:0.1.1
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
`FUNOTEKA_SUPERVISED=1` is what makes `POST /restart` a restart rather than a
|
|
82
|
+
stop, and the restart policy beside it is what supervises the process. The first
|
|
83
|
+
scan is still a command, not a startup side effect — see the end of this section.
|
|
84
|
+
|
|
85
|
+
From a checkout, the same installation is the compose file:
|
|
66
86
|
|
|
67
87
|
```sh
|
|
68
88
|
git clone <this repository> funoteka
|
package/README.md
CHANGED
|
@@ -125,8 +125,8 @@ classification and you edit that layer, not your music.
|
|
|
125
125
|
and the music reaches you through the Subsonic client you already like.
|
|
126
126
|
- **Not tag-driven.** It will not merge your pressings, rename your artists to match an online
|
|
127
127
|
database, or call home. Nothing about your collection leaves the machine.
|
|
128
|
-
- **Not overclaiming.** Where a thing does not exist yet — a
|
|
129
|
-
say so instead of pretending.
|
|
128
|
+
- **Not overclaiming.** Where a thing does not exist yet — a Subsonic endpoint that is still a
|
|
129
|
+
stub, the `arm64` leg built under emulation — the docs say so instead of pretending.
|
|
130
130
|
|
|
131
131
|
## Documentation
|
|
132
132
|
|