| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Records why the original no-root call was wrong (mixing, not cost) and
points at the new §4.3b protocol section — same treatment already given
to the WMA/Musepack transcode amendment above it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tagging and covers for these two formats landed already, but neither one
decodes in any mainstream browser's <audio> element at all — a real
library scan turned up 273 such files that would show up correctly in the
Music app and then simply fail on click. This closes that gap: the node
transcodes to AAC/M4A on request (a one-shot whole-file conversion, not
live-piped like video's fMP4 segments — an audio file is small enough that
streaming it buys nothing), caches the result under its own content hash
the same way a TMDB poster or a MusicBrainz cover is cached, and serves it
back through the ordinary file_req/chunk path. That path used to assume
anything in the media cache was thumbnail-sized (single chunk, always);
generalized it to slice a cached blob the same way a real file on disk
gets sliced, since a transcoded track can be several MB.
New MNP pair (`audio_transcode_req`/`_resp`, version bump to 0.9), shares
its concurrency cap with video's transcode pool rather than getting its
own — both are real ffmpeg processes on the same node. Every other audio
format is untouched: this only fires for .wma/.mpc, the two extensions
that need it.
|
|
|
Proposal only, not implemented. Same plug-in mechanism as Videos
(apps.md), but no new streaming path — a track is downloaded and
decrypted like any other file, not transcoded/remuxed like a film.
Metadata: local tags first (mutagen), MusicBrainz/Cover Art Archive
as node-side fallback enrichment, no API key needed (unlike TMDB) —
just a rate-limited, self-identifying client. Player state (queue,
shuffle, repeat) moves up into the group-page shell so playback
survives a tab switch, mirroring how the video/preview modal is
already shell-owned.
|