Deployed b6429ecd with MkDocs version: 1.6.1

dev/rest-api/remote-sessions/index.html

@@ -2708,7 +2708,9 @@ the raw license bytes come back for your local CDM to parse.</p>
 <p>The <strong>server's CDM</strong> does everything. The client sends track IDs (or a PSSH),
 the server checks its key vaults, loads the device configured for your API key,
 runs the CDM flow, and returns <code>KID:KEY</code> pairs directly. The client needs no
-CDM.</p>
+CDM. When the server's <code>cdm</code> entry for the service names a <code>widevine</code> and a
+<code>playready</code> device, the server loads the device of your local CDM's DRM system.
+See <a href="../../../reference/configuration/drm/"><code>cdm</code></a>.</p>
 <ul>
 <li>Enable with <code>server_cdm: true</code> in the server entry.</li>
 <li>The server tells the client which DRM type it used
@@ -2737,7 +2739,10 @@ session create response tells the client who licenses the session in <code>serve
 the limit in <code>server_cdm_max_height</code>. In a server CDM session, the batch licence response
 lists each track the server refused to license live under <code>capped_tracks</code>. A single-track
 server CDM licence answers <code>403 SERVER_CDM_CAPPED</code> for such a track. In both cases the client
-licenses those tracks in proxy mode with its own local CDM. See
+reads its own key vaults first, then licenses those tracks in proxy mode with its own local
+CDM. When the track has no DRM of that CDM's system, the client uses the device that its own
+<code>cdm</code> entry names for the track's DRM system. With no such device, the download of that track
+stops. See
 <a href="../../../reference/configuration/services/"><code>server_cdm_max_height</code></a>.</p>
 </div>
 <h3 id="your-own-device-identity">Your own device identity<a class="headerlink" href="#your-own-device-identity" title="Permanent link">&para;</a></h3>

reference/configuration/drm/index.html

@@ -2170,7 +2170,11 @@ height is known. If the value is still a dict after that, unshackle uses
 <p>When an entry holds <code>widevine</code> and <code>playready</code>, their order sets which device unshackle loads
 first. A track that offers the two DRM systems licenses with that system. A track that offers
 only the other system uses the other device. A <code>widevine</code> / <code>playready</code> dict in a quality key
-does not set the order. The server CDM of a remote session follows the same order.</p>
+does not set the order.</p>
+<p>On a server, an entry that holds <code>widevine</code> and <code>playready</code> gives a remote session the server CDM
+of the DRM system of the client's local CDM. The service then makes its manifest for that system,
+so the client's vault keys and its own device apply to the tracks. A client with no local CDM gets
+the device that the entry lists first.</p>
 <p>A quality key can also hold a dict of <code>widevine</code> / <code>playready</code> devices, and so can the
 top-level <code>default</code> entry:</p>
 <div class="language-yaml highlight"><pre><span></span><code><span id="__span-2-1"><a id="__codelineno-2-1" name="__codelineno-2-1" href="#__codelineno-2-1"></a><span class="nt">cdm</span><span class="p">:</span>