Skip to content

Docker

Jump to bottom
acestream-scraper CI edited this page Sep 16, 2026 · 19 revisions

Docker Guide

Use the Docker command builder to choose your image, services, ports, and storage. For a first installation or an upgrade, start with Installation.

This guide covers the choices behind that setup:

Docker Compose saves your setup in a file so it is easy to update and recreate. Keep /app/config on persistent storage to retain your channels, settings, and database backups.

Recommended cache and temporary storage

These mounts are optional but highly recommended, especially on Unraid where unmapped writes consume docker.img. Keep the existing /app/config mapping for the database and backups, and add the applicable folders:

Use Container path Example Unraid host folder
Embedded AceStream on amd64 /root/.ACEStream/.acestream_cache /mnt/user/appdata/acestream-scraper/engine-cache
Embedded AceStream on ARM64 / ARMv7 /var/lib/acestream /mnt/user/appdata/acestream-scraper/engine-state
Bundled checking engine on any platform /var/lib/acestream-check /mnt/user/appdata/acestream-scraper/checker-state
Web player on any platform /tmp/acestream-player /mnt/user/appdata/acestream-scraper/player

In Unraid, add each as a read/write Path in the container template. Use host bind mounts: named Docker volumes can still occupy Unraid's Docker image. On other hosts, use suitable local folders, for example:

-v "${PWD}/acestream_cache:/root/.ACEStream/.acestream_cache" \
-v "${PWD}/player_data:/tmp/acestream-player"

The engine-cache example is for the bundled amd64 engine's default cache path. On ARM, replace that mapping with -v "${PWD}/acestream_state:/var/lib/acestream"; ACESTREAM_HOME only controls the ARM engine. If you customize engine cache/state paths, mount the paths the engine actually uses.

The player uses PLAYER_HLS_DIR=/tmp/acestream-player by default. If you change that variable, change the mount target too; the command builder does this for you. It deletes old HLS segments and cleans up inactive sessions, but the rolling playlist is not a hard byte quota. PLAYER_MAX_SESSIONS (default 3) can reduce concurrent playback storage and process usage; use 1 if only one distinct channel/audio session is needed. Alternatively set PLAYER_HLS_DIR=/dev/shm/acestream-player with an appropriate --shm-size (for example 256m) and disable the player bind mount. That uses bounded RAM storage; playback may fail if it fills.

Mounting a cache moves writes; it does not impose a size limit. AceStream cache limits must match the installed engine's supported options. Save any engine settings kept only in the old container before applying a template change. Recreating the container discards its old writable layer; a simple restart does not reclaim it. Disposable stream cache can be rebuilt. Preserve /app/config and its existing host mapping when recreating the container.

Engine cache retention

Bundled playback and checking engines use AceStream's native memory live cache (--live-cache-type memory --live-mem-cache-size 67108864). Channel verification must download a short A/V sample, but live probes no longer create disk-backed live buffers. This also applies when checks use the bundled playback engine. The 64 MiB setting is a live-cache buffer setting, not a total engine RAM cap; concurrent streams and engine overhead need additional memory.

Disk caching for other content remains enabled with explicit engine limits: 512 MiB for playback and 256 MiB for the checker (--cache-auto 0, --cache-max-bytes, and --disk-cache-limit). These are engine-managed limits, not a filesystem quota; do not assume they cover every temporary/HLS file. A custom ACESTREAM_START_COMMAND replaces the playback defaults, so include these flags there if you override it. External engines require configuration on their own host; this app cannot clean their storage.

The supervisor removes leftover regular media files from the default cache folders before starting/restarting an engine and after an operator Stop. It first terminates the old engine process group. Cleanup covers /root/.ACEStream/.acestream_cache on amd64, $ACESTREAM_HOME/.ACEStream/.acestream_cache on ARM, and /var/lib/acestream-check/cache for the checker. It preserves directories, symlinks, open/mapped files and everything outside those cache folders, including engine identity/configuration and the application database. If process inspection or filesystem access fails, cleanup is skipped and logged in the engine log. Custom cache paths are not swept. Cache mounts must be private to one container; process inspection cannot see users of a shared folder in other containers.

To reclaim an existing large cache, deploy the updated image and start the container: cleanup runs before the engine starts. On that image, Overview → Services → Restart also reclaims the corresponding engine cache, interrupting its current streams. A Stop reclaims it and leaves the engine intentionally stopped. There is no periodic deletion of files from underneath a running engine.

Optionally map /app/logs to retain diagnostics across replacement. Its console capture rotates each scraper/service/entrypoint log independently: up to 6 MiB per collector (54 MiB across all nine collectors). Other native service logs have their own retention. Docker's own console log is separate: configure rotation, for example --log-driver=json-file --log-opt max-size=10m --log-opt max-file=3. Existing bounded Docker logging can be retained.

Image Tags and Flavors

Docker images are published under pipepito/acestream-scraper.

latest is the full scraper-acestream-acexy image. These variants change which playback components are installed:

Image tag AceStream included Acexy included Use it for
latest / scraper-acestream-acexy Yes Yes The full package
scraper-acestream Yes No A bundled engine without Acexy
scraper-acexy No Yes A proxy for an external engine
scraper No No Scraping/playlists or external playback services

Every variant includes the web app, FFmpeg and ffprobe. On amd64 and arm64, every variant also includes Cloudflare WARP, IPFS (Kubo), ZeroNet and Tor. Removing the engine or proxy does not remove these shared tools.

With default settings, only the web app starts. FFmpeg/ffprobe are available when needed; AceStream, Acexy, WARP, IPFS, ZeroNet and Tor remain off until enabled. The command builder sets the appropriate service options. An engine-containing image can also run an optional separate checking engine.

Every flavor is published for linux/amd64, linux/arm64, and linux/arm/v7. The AceStream-enabled flavors (scraper-acestream, scraper-acestream-acexy, and latest) install a different engine per platform:

Platform Engine Support
linux/amd64 Native Linux engine 3.2.11 (upstream tarball) stable
linux/arm64 Android engine 3.2.17 from jopsis/acestream:v3.2.17-fix, digest-pinned and run natively stable
linux/arm/v7 Android engine 3.2.17 from jopsis/acestream:v3.2.17-fix, digest-pinned and run natively experimental

Upstream only publishes native Linux engine builds for x86_64. Both ARM images copy the matching platform variant from the digest-pinned jopsis/acestream:v3.2.17-fix image and run its Android engine against the matching bionic userland under /system. No chroot, --privileged, seccomp changes, or extra capabilities are needed. linux/arm/v7 builds and installs but has not been runtime-tested on real ARMv7 hardware yet, so treat it as experimental.

WARP is installed in every flavor's linux/amd64 and linux/arm64 images, but it only starts when ENABLE_WARP=true (it needs --cap-add NET_ADMIN --cap-add SYS_ADMIN and --device /dev/net/tun). The linux/arm/v7 images ship without the WARP client (Cloudflare publishes no 32-bit ARM build), so ENABLE_WARP is unsupported there.

ZeroNet works in two modes. The linux/amd64 and linux/arm64 images bundle a zeronet-conservancy node, pinned by commit to a state that carries DHT peer discovery — opt-in, nothing runs until ENABLE_ZERONET=true (add ENABLE_TOR=true for TOR, like the v1 image). The node runs on its own Python 3.11 under /opt/zeronet because its dependency set predates the app's Python; 32-bit ARM images ship without it because gevent publishes no armv7l wheels — there, and whenever you prefer it, ZeroNet runs as an external sidecar/service and the app reaches it through ZERONET_URL.

The bundled ZeroNet node keeps its configuration and private state in $ZERONET_DATA_DIR/.node (normally /data/zeronet/.node), alongside existing downloaded sites. On upgrade, legacy sites.json and users.json are copied into .node/private only when the destination is absent; the original files are retained. Mount the entire /data/zeronet directory to preserve both content and identities across container replacement. Back up that volume before upgrading; a rollback uses the retained legacy files, not subsequent v2 state.

The bundled node includes a targeted manifest-verification patch. See verification scope and remaining upstream limitations.

The checked-in compose stack keeps the zeronet service behind an optional zeronet profile and points the default app config at http://host.docker.internal:43110. It uses an amd64-focused sidecar image. On 32-bit ARM hosts, point ZERONET_URL at an external ZeroNet service or swap in a compatible sidecar. With the embedded node enabled, leave ZERONET_URL unset — the entrypoint targets the embedded UI port automatically.

IPFS is also bundled: every flavor ships the Kubo IPFS daemon on linux/amd64 and linux/arm64. Kubo publishes no 32-bit ARM build, so linux/arm/v7 images ship without it (the container exits with a clear error if ENABLE_IPFS=true is requested there — same situation as WARP). The daemon is opt-in: nothing IPFS-related runs until ENABLE_IPFS=true. ipfs:// and ipns:// sources are fetched through IPFS_GATEWAY_URL, which defaults to the embedded gateway at http://127.0.0.1:8081 — the gateway uses 8081 in-container because Acexy already listens on 8080. You can also scrape IPFS without the embedded daemon: keep ENABLE_IPFS=false and point IPFS_GATEWAY_URL at an external node, e.g. http://host.docker.internal:8080 for a Kubo/IPFS Desktop install on the Docker host (this works on every platform, linux/arm/v7 included).

AceStream platform availability is manifest-driven via docker/manifests/acestream.json. Adding a new supported AceStream architecture means updating that manifest. The manifest pins the engine source and support level (stable or experimental) per platform: conventional archives are checksum-pinned and vendored, while both ARM entries pin the jopsis multi-platform OCI digest.

If you run with ENABLE_WARP=true, the container must be started with the runtime capabilities NET_ADMIN and SYS_ADMIN.

Pre-release channel (develop)

The tags above are release tags: latest and the immutable vX.Y.Z / vX.Y.Z-<flavor> tags are cut from the main branch. Next to them, validated application or build changes on the develop branch publish a pre-release channel:

  • develop as the full scraper-acestream-acexy payload (the channel's equivalent of latest)
  • develop-scraper, develop-scraper-acestream, develop-scraper-acexy, and develop-scraper-acestream-acexy for the individual flavors

Channel tags are moving tags: they are re-pushed for the same platforms as the release flavors after application or build changes on develop pass CI, and there is no per-version or per-commit tag for them. Use them to test what the next release will contain, not for production. To run the pre-release, replace latest with develop (or develop-<flavor>) in the commands below, or set image: pipepito/acestream-scraper:develop in docker-compose.yml:

docker pull pipepito/acestream-scraper:develop

Basic Docker Commands

Tip: the Docker command builder generates the full docker run command or docker-compose.yml for your flavor, platform and features — ports, folders and capabilities included.

Pull the Image

docker pull pipepito/acestream-scraper:latest

Run the Container

docker run -d -p 0.0.0.0:8000:8000 --name acestream-scraper pipepito/acestream-scraper:latest

latest is the full scraper-acestream-acexy image. If you want to pin behavior explicitly, pull one of the flavor tags instead.

Important runtime env expectations:

  • ENABLE_WARP enables WARP only when set to true

  • WARP_ENABLE_NAT connects WARP and enables NAT at startup when set to true (default false; otherwise connect from the WARP page)

  • ENABLE_ACESTREAM_ENGINE starts the installed AceStream engine only when set to true

  • ENABLE_ACEXY starts the installed Acexy binary only when set to true

  • ACESTREAM_HTTP_HOST and ACESTREAM_HTTP_PORT define the in-container AceStream endpoint

  • ACEXY_HOST and ACEXY_PORT define the engine endpoint Acexy connects to

  • ZERONET_URL points the scraper at a ZeroNet node — the embedded one or an external sidecar/service

  • ENABLE_ZERONET starts the bundled ZeroNet node only when set to true (amd64 and arm64 images); ENABLE_TOR adds TOR for it

  • ENABLE_IPFS starts the embedded Kubo IPFS daemon only when set to true (amd64/arm64 images)

  • IPFS_GATEWAY_URL points the scraper to the IPFS HTTP gateway used for ipfs:///ipns:// sources (defaults to the embedded gateway http://127.0.0.1:8081)

With automatic connection enabled, startup waits for the tunnel to report Connected before launching the engines. If it cannot connect within the startup readiness budget, startup fails with a WARP error. The ARM engines follow DNS changes when WARP connects or disconnects.

If known-working IDs return failed to load content while cached channels still play, compare with WARP connected. Fresh ARM64 tests on 2026-09-15 resolved and played three IDs through WARP that failed on the direct route. This can indicate a network-path problem; increasing playback timeouts alone does not fix it. See the controlled comparison.

The default compose example uses http://host.docker.internal:43110 so the app can still boot when the optional zeronet profile is not enabled.

Example with WARP enabled:

docker run -d \
  --cap-add NET_ADMIN \
  --cap-add SYS_ADMIN \
  --device /dev/net/tun:/dev/net/tun \
  -e ENABLE_WARP=true \
  -e WARP_ENABLE_NAT=true \
  -p 0.0.0.0:8000:8000 \
  --name acestream-scraper \
  pipepito/acestream-scraper:latest

Run the In-Container AceStream Engine (amd64 and ARM)

The engine is installed in latest, scraper-acestream, and scraper-acestream-acexy, but it only starts when ENABLE_ACESTREAM_ENGINE=true. The same command works on linux/amd64, linux/arm64, and linux/arm/v7; Docker picks the matching image and engine for the host:

docker run -d \
  -e ENABLE_ACESTREAM_ENGINE=true \
  -p 0.0.0.0:8000:8000 \
  -p 6878:6878 \
  -p 8621:8621 \
  -p 8621:8621/udp \
  -v "${PWD}/config:/app/config" \
  -v "${PWD}/acestream_state:/var/lib/acestream" \
  --name acestream-scraper \
  pipepito/acestream-scraper:latest
  • ENABLE_ACESTREAM_ENGINE=true starts the engine; no extra capabilities are required (only WARP needs NET_ADMIN/SYS_ADMIN).
  • On ARM, /var/lib/acestream (ACESTREAM_HOME) holds the Android engine's state: acestream.conf, acestream.log, acestream_error.log, and the .ACEStream/ directory with the disk cache. A host-folder mount is optional but highly recommended so the cache and the per-install device id (.device_id) survive container replacement; the mount is harmless on amd64.
  • Ports: 6878 is the engine HTTP API (the backend talks to it through ACE_ENGINE_URL, default http://localhost:6878 when the bundled engine is enabled; otherwise empty); 8621 tcp/udp is the P2P port. Only publish 6878 if you want to reach the engine from outside the container, and only on trusted networks: the engine is started with --bind-all on every platform (ACESTREAM_BIND_ALL=true by default; set it to false to keep the engine's loopback/RFC1918-only filter) so published-port clients are accepted, and the engine HTTP API has no authentication.
  • Logs: the entrypoint supervises the engine, so its output shows up in docker logs acestream-scraper (on ARM the launcher passes --log-stdout for this). On ARM the engine also writes acestream.log / acestream_error.log under /var/lib/acestream. Every image flavour also captures bounded console history: use Overview → Services → Download diagnostics to save a ZIP from your phone, or GET /api/v1/system/diagnostics with the normal API token. Collection begins after upgrading to an image with this feature. Common credentials and URLs are masked on export; review before sharing. See runtime diagnostics for limits and retention.
  • Health: the backend polls /server/api?api_version=3&method=get_status and method=get_network_connection_status on the engine. To confirm which engine is running: curl "http://localhost:6878/webui/api/service?method=get_version" returns {"platform":"android","version":"3.2.17"} on ARM64 and ARMv7. The dashboard also shows Engine package: jopsis/acestream v3.2.17-fix with a link to the source image.

ARM caveats:

  • Raspberry Pi 5 (and any 16 KB-page kernel): the Android 9 bionic linker requires a 4 KB kernel page size. On Raspberry Pi OS 64-bit set kernel=kernel8.img in config.txt (the default kernel_2712 kernel uses 16 KB pages). The engine checks getconf PAGESIZE at startup and exits with an explicit error instead of segfaulting.
  • linux/arm/v7 is experimental: the image builds and installs, but the 32-bit engine cannot be executed under QEMU user emulation, so it has not been runtime-tested on real ARMv7 hardware. Prefer linux/arm64 wherever the device supports 64-bit containers.
  • Engine version skew: ARM64 and ARMv7 run Android engine 3.2.17 (both report "platform":"android"), while amd64 runs native Linux engine 3.2.11.
  • No WebRTC transport on ARM: the Android WebRTC module needs GPU/audio libraries that are not shipped; the engine logs a non-fatal error and keeps going. A few CPython accelerator modules also fall back to pure Python.
  • No WARP on linux/arm/v7 images: cloudflare-warp ships for amd64 and arm64 only.
  • Performance and streaming stability on real ARM hardware are not yet validated; report results if you try it.
  • Repackaging the official APK payload is a grey area under the AceStream user agreement, as with every community ARM image. Enable the engine at your own discretion.

Playing streams on ARM

The web player, remote players (VLC/Kodi) and the Jellyfin/Plex tuner all ask the engine to start a stream, so what they can do depends on which engine your platform runs:

  • amd64 runs the native Linux engine 3.2.11 and is unaffected. Everything works as documented.
  • arm64 runs jopsis/acestream:v3.2.17-fix. On 2026-09-15, tests on Apple Silicon verified audio/video delivery after correcting the bundled launcher to use the distribution's aceserve.main() entry point. The previous direct Core.run() call could return mod_detected despite healthy startup checks. The fix retains the pinned engine and persistent device identity. See the playback investigation for test scope and the successful fresh-ID comparison with WARP connected. This is not a guarantee for every source or ARM board.
  • armv7 uses the matching 32-bit variant of jopsis/acestream:v3.2.17-fix. It builds and installs, but cannot execute under QEMU user emulation and has not been runtime-tested on real ARMv7 hardware, so playback is unverified rather than promised.

The official Android engines are still known to answer playback outside AceStream's own app with "To continue, you need to activate premium"; the current ARM images use the community distribution described above. Do not work around that check by reporting a false app identity. The playback and checking engines share the Android DNS socket through a process lock; a second engine must not remove the active listener. Other failures can look similar:

  • A DNS blocklist. Pi-hole/AdGuard lists that sinkhole *.acestream.media or *.acestream.net cut the 3.2.x engines off from their licence check, and the failure looks identical. Allow those two domains on the host running the engine before blaming the engine version.
  • The engine refusing a client address. ACESTREAM_BIND_ALL (default true) applies on every platform: the entrypoint appends --bind-all to the engine start command so clients that are not on loopback or a private address — Tailscale, IPv6 LANs, unusual Docker networks — are accepted on a published 6878. Set it to false to restore the engine's own filter.

Run the Bundled ZeroNet Node (amd64 / arm64)

ZeroNet is installed in every amd64 and arm64 flavor but only starts when ENABLE_ZERONET=true:

docker run -d \
  -e ENABLE_ZERONET=true \
  -p 0.0.0.0:8000:8000 \
  -p 43110:43110 \
  -p 26552:26552 \
  -v "${PWD}/config:/app/config" \
  -v "${PWD}/zeronet_app_data:/data/zeronet" \
  --name acestream-scraper \
  pipepito/acestream-scraper:latest
  • /data/zeronet (ZERONET_DATA_DIR) holds the node's sites, keys and content; mount it so they survive container replacement.
  • The scraper reaches the node automatically (ZERONET_URL falls back to the embedded UI port when you don't set it), so zero:// sources work with no further setup.
  • Ports: 43110 is the ZeroNet web UI, 26552 the fileserver/peer port (ZERONET_UI_PORT / ZERONET_FILESERVER_PORT to change them). Publishing 43110 is only needed to browse the ZeroNet UI yourself — and ZeroNet only answers Host headers it knows, so add -e ZERONET_UI_HOST="myserver.lan 192.168.1.10" to reach it from another machine. The UI has no authentication: publish it on trusted networks only.
  • Add -e ENABLE_TOR=true to run TOR alongside; the node auto-detects it over the control port (same contract as v1). ZERONET_EXTRA_ARGS passes any extra zeronet-conservancy flags through.
  • 32-bit ARM images ship without the bundled node; use the external ZERONET_URL mode there. Both amd64 and arm64 bundle ZeroNet.

Run the Embedded IPFS Daemon (amd64 and arm64)

Kubo is installed in every flavor but only starts when ENABLE_IPFS=true:

docker run -d \
  -e ENABLE_IPFS=true \
  -p 0.0.0.0:8000:8000 \
  -p 4001:4001 \
  -p 4001:4001/udp \
  -p 8081:8081 \
  -v "${PWD}/config:/app/config" \
  -v "${PWD}/ipfs_data:/data/ipfs" \
  --name acestream-scraper \
  pipepito/acestream-scraper:latest
  • /data/ipfs (IPFS_PATH) holds the IPFS repository (keys, blockstore, config); mount it so the node identity and cache survive container replacement.
  • Ports: 4001 tcp/udp is the swarm port (publishing it improves peer connectivity), 8081 is the HTTP gateway (only needed outside the container if you want to browse IPFS content through the node). The RPC API on 5001 has no authentication and full control of the node; it binds to the container loopback by default. If you need the WebUI, set -e IPFS_API_HOST=0.0.0.0 and publish it only on the host loopback: -p 127.0.0.1:5001:5001.
  • Port overrides: IPFS_SWARM_PORT (default 4001), IPFS_API_PORT (default 5001), IPFS_GATEWAY_PORT (default 8081; 8080 is taken by Acexy in-container). The entrypoint re-applies these to the IPFS config on every boot.
  • Once running, add sources as ipfs://<cid>/path/list.m3u (or ipns://<name>/...) in the Scraper page — they are fetched through the embedded gateway. A bare ipfs://<cid> whose content is an M3U playlist also works; the scraper detects the playlist by content.

View Running Containers

docker ps

View Container Logs

docker logs acestream-scraper

Stop the Container

docker stop acestream-scraper

Remove the Container

docker rm acestream-scraper

Update to Latest Version

docker pull pipepito/acestream-scraper:latest
docker stop acestream-scraper
docker rm acestream-scraper
# Run the container again with your preferred configuration

Docker Compose Commands

Start Services

docker compose up -d

Start Services With The Example ZeroNet Sidecar

docker compose --profile zeronet up -d

View Logs

docker compose logs

Stop Services

docker compose down

Update to Latest Version

docker compose pull
docker compose up -d

Docker Data Persistence

Acestream Ids Scraper uses Docker volumes to persist data:

  • /app/config: Configuration files including database
  • /var/lib/acestream: AceStream engine state, disk cache, and logs of the ARM Android engine (only used when ENABLE_ACESTREAM_ENGINE=true in an AceStream-enabled flavor)
  • /data/ipfs: The embedded IPFS daemon's repository — node identity, config, and blockstore (only used when ENABLE_IPFS=true)
  • /data/zeronet: The bundled ZeroNet node's state — sites, keys, and content (only used when ENABLE_ZERONET=true)

These volumes should be mounted to local directories (or named volumes) to ensure your data persists when containers are updated or replaced.

Example:

docker run -d -p 0.0.0.0:8000:8000 -v "${PWD}/config:/app/config" pipepito/acestream-scraper:latest

This mounts your local ./config directory to the container's /app/config directory.

With the engine enabled on ARM, add -v "${PWD}/acestream_state:/var/lib/acestream" (or a local directory) so the engine cache is not rebuilt on every container replacement.

Isolate channel checks from playback

For images containing AceStream, enable ENABLE_ACESTREAM_CHECK_ENGINE=true alongside ENABLE_ACESTREAM_ENGINE=true. This opt-in starts one reusable checking engine, with independent state/cache under /var/lib/acestream-check and internal HTTP port 6880 (HTTPS reserves 6881, legacy API 62063, P2P 8622). Leave these ports unpublished and reserve them when customizing playback. You can mount a separate host directory at /var/lib/acestream-check; never reuse the playback state directory.

The command builder adds a separate checker-state mount when you enable Advanced settings → AceStream engine → Separate engine for channel checks. Its external checking field is omitted while the bundled checker is selected, so the generated command cannot enable both.

Other images can use a separate external engine via ACE_CHECK_ENGINE_URL. Choose the bundled switch or the external URL, not both. With neither configured, checks use the saved engine URL as before. An unavailable dedicated checker preserves previous channel results and never sends checks to the playback engine.

Overview → Services provides separate checking-engine Start/Stop/Restart controls. Its crashes recover automatically without restarting playback; its health is shown there rather than failing the entire container healthcheck. Diagnostic downloads include its own rotating log. The checker adds memory and bandwidth usage (256 MiB disk-cache limit, 64 MiB RAM live cache; total RAM is not capped by these values). Checks remain serialized. ARMv7 still requires testing on real hardware. See stream-check isolation for ownership behavior and remaining limitations with players connected directly to an engine.

Engines are optional for scraper-only use. Configure a playback endpoint in Settings → Playback, and optionally a dedicated checking endpoint in Settings → Automation. With neither configured, stream status checks are skipped. An external ACE_CHECK_ENGINE_URL is a default that can be overridden in Settings; bundled checker configuration remains controlled by the container. See stream-check routing.

For slow engine startup through Acexy, bundled images default ACEXY_NO_RESPONSE_TIMEOUT=30s; an explicit value overrides it. External Acexy instances need this configured separately. Keep PLAYER_START_TIMEOUT_SECONDS (default 45 seconds) long enough for the proxy response and initial HLS segments. Stream-status sampling uses the timeout saved in Settings and reads through HTTP, so it does not require mounting the engine's temporary files into the scraper.

Optional DNS override

The command builder's Use xdp.es DNS option is off by default. Enabling it adds --dns=85.208.114.52 to Docker commands or a dns: entry to Compose. It selects xdp.es Standard, without ad filtering, using ordinary unencrypted DNS. Recreate the container to apply or remove it; WARP may override DNS while connected.

Acestream Ids Scraper

Watch and manage

Get help

Contribute

Clone this wiki locally