kenzuya/unshackle
1
0
Fork 2
mirror of https://github.com/unshackle-dl/unshackle.git synced 2026-11-15 05:25:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Deployed 7a5ad502 with MkDocs version: 1.6.1

Browse Source
This commit is contained in:
2026-11-15 02:59:55 +00:00
parent a0fc5832f9
commit 87cdc295e1
11 changed files with 362 additions and 86 deletions
Download Patch File Download Diff File Expand all files Collapse all files
dev/creating-a-service/index.html
+3 -3
View File
@@ -2772,9 +2772,9 @@ Optional metadata keywords such as <code>album_artist</code>, <code>genre</code>
class for the current list.</p>
<p>From <code>get_tracks()</code>, give one <code>Audio</code> track for each codec and bitrate you offer
for the song. The framework then selects one with its usual audio options.
A <code>Song</code> skips the muxer, so restore the real container suffix on the track path
in <code>on_track_downloaded</code>. The <strong>MUSIC_EXAMPLE</strong> service shows the full music
surface.</p>
A <code>Song</code> skips the muxer: the framework reads the codec from the downloaded file
and gives the file its container, so a service does not rename the track path.
The <strong>MUSIC_EXAMPLE</strong> service shows the full music surface.</p>
</div>
</div>
</div>
dev/service-architecture/index.html
+6 -10
View File
@@ -2911,7 +2911,9 @@ final audio file under that suffix.
You can set these fields in <code>get_tracks()</code> too, and a remote client gets them back.</p>
<p>The tagger also falls back to <code>Song.data</code> for fields the constructor did not get, such
as the composer or a full release date. It reads the top level of that dict and a
nested <code>metadata</code> sub-dict, with the nested keys winning, so either shape works.</p>
nested <code>metadata</code> sub-dict, with the nested keys winning, so either shape works. The keys
that a remote client gets back are <code>MUSIC_DATA_KEYS</code> in <code>unshackle/core/titles/music.py</code>,
for example <code>artists</code> (a list) and <code>replaygain_track_gain</code>.</p>
<p>From <code>get_tracks()</code>, a music service gives <strong>one <code>Audio</code> track for each codec and
bitrate it offers for a <code>Song</code></strong>. The framework then selects one with its usual audio
options, <code>-a</code>/<code>--acodec</code> and <code>--abitrate</code>, and its usual audio sorting. A movie or an
@@ -2922,15 +2924,9 @@ separates a hi-res FLAC from a CD FLAC, and the audio sort already ranks it.</p>
music-specific service API and no separate music download loop. The
<code>GROUP_AUDIO_DOWNLOADS</code> flag, <code>get_music_track_options</code> and <code>get_music_collection_label</code>
no longer exist, and a music service does not need them.</p>
<div class="admonition warning">
<p class="admonition-title">Restore the container in <code>on_track_downloaded</code></p>
<p>Every track downloads to a temp file named <code>Audio_&lt;id&gt;.mp4</code> whatever it holds, and
the final move keeps that suffix. A <code>Song</code> skips the muxer, so its download <strong>is</strong>
the delivered file, and the tagger picks its metadata format from the suffix.
Rename the track path to the true container in <code>on_track_downloaded</code>, or a FLAC
lands as an untaggable <code>.mp4</code>. The event fires twice, once before decryption and
once at the end, so wait until <code>track.drm</code> is clear before you rename.</p>
</div>
<p>Core picks the container of a <code>Song</code> from the codec in the downloaded file, so a music
service does not rename the track path. Read
<a href="../../guide/output-and-naming/#music-output-files">Music output files</a>.</p>
<p>The <strong>MUSIC_EXAMPLE</strong> reference service, at <code>unshackle/services/MUSIC_EXAMPLE/</code>, shows
the full music surface.</p>
</div>