mirror of
https://github.com/Screenly/Anthias.git
synced 2026-06-10 09:08:09 -04:00
da53e045a6
* fix(server): stream the backup download so large libraries don't time out Part of issue #2987 ("Get backup" reportedly never completes on a Pi 3B+): the settings download built the whole tar.gz on disk before sending the first byte. tar+gzip at the default level 9 measures 98 s for 355 MB on a Pi 4 (~3.6 MB/s) — a multi-GB library on a Pi 3 sends nothing for longer than a browser keeps a byte-less request alive, so the download always aborted. - settings_backup now streams the archive while it is built (StreamingHttpResponse over a pipe fed by a tarfile producer thread): first bytes hit the wire immediately, nothing is staged on the SD card, and a client disconnect stops the producer. - gzip level drops to 1 for both the streamed and the API (create_backup) paths — backups are mostly already-compressed media, so level 9 burned minutes of CPU for ~no size win. - The Content-Disposition filename is RFC-8187-escaped via Django's content_disposition_header (player_name is operator-controlled). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(server): surface backup-stream producer failures, fix mypy type - stream_backup() re-raises a producer failure once the pipe drains, so the response aborts mid-transfer instead of completing 200 with a silently truncated archive (review feedback). Client disconnects still log-and-stop without morphing into spurious errors. - Return type is Generator (not Iterator) — the disconnect test calls .close(), which mypy rejects on Iterator. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>