laten zien hoe downloads en zo gaan

2026-10-29 10:39:35 +01:00
parent f7f4d440b8
commit 3fda5c2485
8 changed files with 293 additions and 69 deletions
@@ -143,6 +143,23 @@ the agent exits; it is not retained across restarts.
 A track that is not cached is still downloaded completely before playback.
 The HTTP server allows up to one hour for a response, including media
 transfers, so large lossless tracks can finish over slower connections.
+The agent imposes no total download deadline: receiving another chunk restarts
+its 30-second inactivity timer. A connection or transfer with no response bytes
+for 30 seconds fails, closes its ports and removes the partial file. The private
+@tt{call-with-http-timeout} procedure runs an HTTP operation with a
+@tt{progress!} callback; each callback restarts this timer. Cancellation unwinds
+the worker before its custodian closes the remaining HTTP resources.
+
+The browser displays the selected agent's reported download filename and byte
+counts, including prefetch downloads. Server logs record agent download start,
+progress every five seconds while sending, and completion or interruption with
+client address, filename and byte counts. DLNA media transfers are logged by
+@tt{racket-upnp} with client address, method, range and elapsed time.
+
+Browser API requests time out after 30 seconds, freeing the request queue and
+allowing status polling to resume. Timing out a browser request does not undo a
+command already accepted by the server.
+
 The next track is fetched after the play command completes. Commands are
 processed in server order, so a pending prefetch can still delay a later manual
 track selection.