Datenschutzerklärung / Privacy Policy

MediaForge Telemetry — Privacy Notice

Status: this document describes how the optional telemetry system works and what maintainers do with the data it collects. It reflects the design as implemented, informed by general research into current GDPR guidance on telemetry with a stable identifier. It is not a finalized legal document — a proper legal review of the exact wording here, and of the in-app consent dialog, is still recommended before this is treated as compliance-complete. Nothing below should be read as a legal guarantee.

The short version

• Telemetry is off by default. Nothing is sent until you actively say yes.
• What gets sent is controlled in fine detail — dozens of individual toggles, not one master switch — and you can see exactly what each one means before turning it on.
• Your data is identified only by a random install_id, not by an account or a real name. Starting from stage 2 this ID is pseudonymous, not anonymous: it stays stable and can, over time, build up a usage profile tied to that ID.
• You can see your own install_id, reset it (breaking the link to everything sent before), and request deletion or export of everything stored under it — at any time, for any reason, without needing to justify why.
• One provider (hanime_tv, an 18+ content source) is hard-excluded from almost all of this regardless of your settings — see "The hanime.tv exception" below.

The data stages

Telemetry is organized into seven stages, numbered 0–6. Each stage is a bundle of individually toggleable data points, not one big switch: turning a stage "on" enables every data point in it as a convenience, but you can immediately turn individual points back off without affecting the rest of that stage or any other stage.

Stage 0 — Off

No network connection to the telemetry server at all. No data of any kind leaves your installation.

Stage 1 — Crash & System Info (opt-in via a one-time consent dialog)

The only stage that has its own dedicated consent screen, shown once, before any other part of telemetry is even mentioned:

• Crash reports — a sanitized traceback (file/line/function only — never variable values, session tokens, or credentials) when the app crashes unexpectedly, plus a small snapshot of machine state at that moment (free RAM and RAM-use percentage, free disk on the download volume, load average, and live thread/file-descriptor counts) so an out-of-memory or disk-full condition is visible in the report. No titles, paths or content.
• System info — technical descriptors of the installation, used to place a crash or error report in context (e.g. a bug that only occurs on Windows, only inside a Docker container, or only without hardware acceleration): app version, operating system and version, container runtime (Docker/Podman/Kubernetes) if any and how MediaForge was installed (Docker/pip/pipx/PyInstaller), whether it runs with administrator/root privileges and on a read-only filesystem, whether a VPN interface is present, and the timezone; on Linux additionally the distribution, C library and kernel; Python version and implementation, the UI language, CPU architecture, CPU model and core counts, total RAM, detected GPU(s) and driver version, the hardware-acceleration methods and encoders the bundled ffmpeg supports and which of them actually initialise on this machine, and the versions of key components (ffmpeg, yt-dlp, mpv, captcha browser). It carries no hostname, username, IP address, or file paths. (The app sends no IP address. The server does record the address your connection arrives from — that is a separate thing, described under "Your network address" below.)

Both start off. The first-run dialog offers two equally-weighted buttons, "Yes, send crash reports" and "No thanks" — there is no pre-checked box and no visually favored button, because an affirmative, freely-given choice is what current guidance on telemetry consent calls for (see "Why opt-in instead of opt-out" below). Saying no changes nothing about how the app works; telemetry is never a requirement for any feature.

Stage 2 — Feature Flags (opt-in)

Pure yes/no-plus-counter data — "is this feature used, and how often" — for each of: AutoSync, SyncPlay, the upscaler, transcoding, library scanning, the release calendar, each configured integration (Crunchyroll, Fernsehserien, Seerr, MediaScan), the Jellyfin/Plex media-server connection (counted separately from the MediaScan library sync, and only that such a connection is set up and was tested/used — never a server URL, a server name, or any library or title data), push notifications, uptime monitoring, extensions, self-update, the direct-link downloader, the captcha solver, the external v1 REST API, and — separately, see below — hanime.tv.

Also at this stage, behind its own single switch: which of the built-in source sites you use (AniWorld, SerienStream, FilmPalast, MegaKino, filmo.to, 9anime, Aniwaves) and how often. The site's name and a counter, nothing more — no titles, no search terms, no URLs. This is what tells the project whether a source is worth maintaining. It is one switch even though each site is counted separately, because "may we see which sites you use" is one question. hanime.tv is deliberately not part of it and keeps its own strictly limited counter — see below.

No titles, no content, no error messages at this stage.

Stage 3 — Feature Details & Errors (opt-in)

More context on the same features, still without any titles or content: run counts and durations, error counts, which upscale preset was used, session statistics for SyncPlay (count and a bucketed participant number — never room content), connection failures per integration (never credentials), the folder names of loaded extensions, self-update success/failure, captcha solve statistics, and how often the external API is called.

Also here: network problems the app worked around on its own — the configured DNS resolver failing to resolve a host (so the system resolver was used instead), and a source site failing to load. What is sent is the kind of problem and, for a source outage only, the name of the source. Never a hostname, never the DNS server you configured, never your IP, never a URL.

Stage 4 — Download Content (opt-in)

This is where things become content-specific:

• Which series/movie was downloaded, from which provider (the video hoster) and which source site, which season/episode, and whether it succeeded. The site is only ever one of the built-in names listed under stage 2 — never a name a third-party module chose, and never hanime.tv.
• The error message for a failed download.
• URLs used through the direct-link feature (with query strings and tokens stripped — see "How data is cleaned" below).

Stage 5 — Playback Context (opt-in)

Which title or episode was started, and when — without any watch duration. Also covers what's playing in a SyncPlay room, if that stage is enabled (stage 3 only knows a session happened; this stage adds what was in it).

Stage 6 — Watch Behavior (opt-in, never bundled into "enable everything")

The most sensitive tier, and treated differently on purpose: it never gets turned on as a side effect of a stage-6-and-below bulk toggle, and the confirmation dialog for it carries a noticeably more serious warning than any other stage.

• Playback progress per episode/movie.
• Cumulative watch-time totals.
• Whether a title was watched to completion.

Combined with an install_id and the download/playback data from stages 4–5, this amounts to a genuine behavior profile — closer to what a streaming service's own analytics would capture than to ordinary crash reporting. We describe it that way on purpose rather than softening the language.

The hanime.tv exception

MediaForge includes an age-gated, 18+ content provider (hanime_tv). Regardless of which stages you have enabled — even if every other stage is fully turned on — the only telemetry ever collected for this provider is the stage-2 usage counter (flag.hanime_tv: used yes/no, and how often). No titles, no error messages, no play events, no playback progress, and no watch time are ever collected for this provider, at any stage.

This is not a setting you can override by enabling more stages — it is enforced in the client before an event is even constructed, so this data never leaves your device in the first place. The server additionally refuses (and logs) any download/play/watch event that somehow arrives tagged with this provider, as a second layer of defense in case of a bug or a modified client.

Anonymous, pseudonymous, and behavioral — used precisely, not loosely

• Stage 1 is close to genuinely anonymous: a crash report and system info carry no stable identifier that ties multiple reports together in a meaningful way for an outside observer, beyond the install_id needed to deduplicate.
• Stages 2–5 are pseudonymous: the install_id is stable across requests, which means usage patterns for a single installation can be observed over time even though no real name or account is attached.
• Stage 6 is behavioral data: combined with the above, it can reconstruct a genuine viewing profile for a given install_id.

We do not describe any of stages 2–6 as "anonymous" — that word is reserved for stage 1.

Your install_id

A random identifier (UUID4), generated once on first install, stored locally. You can view it in Settings and regenerate it at any time ("reset identity") — doing so breaks the link between everything sent under the old ID and everything sent afterward; nothing is migrated across the reset.

Your network address

Every list above describes what MediaForge sends. Your IP address is not in any of them, and the app never transmits it. But it is unavoidably visible to the server as part of the connection itself, and this server records it — so it is described here rather than left to the reader to assume either way.

What is stored. When a batch of telemetry is accepted, the server stores the address it arrived from in two places: the last known address on your installation's record, and the address on each arrival entry, which together form a short list of "this installation connected from these addresses, between these dates". Nothing else is derived from it automatically — no location lookup, no network or provider identification happens when your data arrives.

When it is looked up. An administrator can press a button to ask a third-party service what is known about an address (country, region, network operator). That only ever happens on an explicit action, never automatically, and the answer is cached so the question is not asked twice. If your operator has not configured such a service, no address ever leaves this server at all.

Who can see it. Only the role that can already see per-installation data — the same level of access needed to view watch history or issue an export. Staff who can triage crash reports cannot see it, and it does not appear on the operational screens showing incoming traffic.

How long. 30 days by default (TELEMETRY_IP_RETENTION_DAYS), after which the address is erased while the rest of the record stays. This is deliberately shorter than the retention for the crash and feature data it accompanies.

Your rights cover it. It is included in a data export, and a deletion request removes it along with everything else.

It can be switched off. An operator running this server can set TELEMETRY_STORE_CLIENT_IP=false, and no address is recorded for anyone.

Separately, and regardless of the above: addresses that were refused by the server — failed project keys, invalid signatures, floods — are recorded for up to 90 days as an abuse-defence measure (see the incident in docs/). Those are not linked to any installation, because a refused request never became one, and they are not part of anyone's export.

How data is cleaned before it's sent

• Tracebacks include only file, line number, and function name for each frame — never variable values or other runtime state, which is where credentials, session tokens, or stream URLs with embedded tokens could otherwise leak.
• Absolute file paths are shortened to a package-relative path, dropping anything that could contain your OS username or install location.
• URLs are stripped down to scheme, host, and path — query strings and fragments (where auth tokens and session IDs usually live) are removed, and so is any user:password@ part in front of the host, so a link to a password-protected NAS or media server never carries its credentials into a report.
• A regex safety net additionally scans the final text for patterns like Authorization:, Bearer, api_key, password=, token= and redacts any match, as a second line of defense on top of the structural cleaning above.
• Everything is size-capped so a pathological error (e.g. runaway recursion) can't produce an oversized payload.
• The server re-validates and re-truncates on arrival — a compromised or modified client is not trusted to have done its part correctly.

What is never reported, even when you have enabled the matching stage

Some things simply are not errors, and MediaForge does not report them as such:

• Anything you cancelled yourself. Stopping a download, closing the captcha window, aborting an upscale or transcode job, pressing Ctrl+C, or closing a browser tab that had a live stream open produces no crash report, no error event, and no download event — not even one marked "cancelled". The check happens on the client, before any payload is built, so nothing about the cancelled operation leaves your device.
• The devInfo server being unreachable. If this server is down, unreachable, or in maintenance, the client drops the affected events and stays silent about it. It does not retry, does not queue anything to disk, and does not write anything to your console.
• Ordinary HTTP responses the app handles itself, such as a 404 for a page a browser probed on its own.

The practical reason is the same as the privacy reason: a crash list flooded with people pressing "Cancel" hides the actual defects, and reporting your cancellations back to a server tells us about your behavior rather than about a bug.

Why opt-in instead of opt-out for stage 1

Telemetry data tied to a stable identifier — even a pseudonymous one like install_id — is personal data once it allows conclusions about a specific user. Relying on "legitimate interest" as the legal basis for that kind of collection, with an opt-out users have to find and click, is broadly discouraged by data protection guidance: users don't expect telemetry to be collected at all by default, and a right to object after the fact doesn't offset that. Consent — obtained before any data is collected, through an active choice, with no pre-checked box, and just as easy to withdraw as to give — is the safer and more defensible basis. That's why MediaForge asks before sending anything, rather than sending by default and letting you turn it off afterward.

Retention

• Crash signatures and their occurrence counts are kept to help fix recurring bugs; the identifying detail retained per occurrence is limited to install_id, app version, and timestamp.
• Feature usage counters and details are kept for as long as they remain useful for understanding how features are used and where they fail.
• Watch-behavior data (stage 6) is the most sensitive tier and is the first candidate for a shorter retention window than crash/feature data, in line with data-minimization principles — exact aggregation/deletion schedules are an operational decision made alongside this document, not hard-coded into it.
• Network addresses of accepted connections are erased after 30 days by default (TELEMETRY_IP_RETENTION_DAYS); the arrival record and the installation record stay, minus the address. Cached "what is this address" lookups expire after 90 days (TELEMETRY_IP_INTEL_RETENTION_DAYS). See "Your network address" above.
• Generated data exports (see below) are deleted automatically 30 days after creation, regardless of whether anyone downloaded them.
• Maintainers can switch off crash collection for a single installation and a single error type — for instance when one installation running an outdated version keeps re-sending a bug that has already been fixed. Matching crash reports are then discarded on arrival and never stored at all. Such a rule records only the install_id it applies to, the error type, an optional version ceiling, and how many reports it has discarded; it is removed along with everything else when a deletion request for that installation is processed.

Your rights: access, deletion, and export

Two ways to ask for your data to be deleted or exported:

1. From within MediaForge (preferred): Settings → "Manage my data" sends the request directly from your installation, which already knows its own install_id — nothing to type in, and it demonstrably comes from a device that has that ID, not from someone who merely saw it somewhere. You can check the status of your request and download a completed export directly from the same screen.
2. The public request form (fallback, for when the app is no longer installed): a webform where you provide your install ID, a name, and an email address. Because this path has no way to verify the ID actually belongs to you, export requests made this way go through additional manual review before anything is sent — a deletion request carries much lower risk either way and is processed as submitted.

Either way: submitting a request only queues it for review — nothing happens automatically. A deletion, once approved, is a hard delete across every telemetry table for that install_id — not a soft flag, and not reversible. An export, once approved, produces a time-limited (30-day) download link containing a structured, machine-readable copy of everything stored for that install_id, organized by category with an explanation of what's included.

Module store download counts (not telemetry, and not opt-in)

The module store counts how often each module and template version is downloaded. This is separate from everything above — it is not telemetry, it has no consent stage, and turning telemetry off does not affect it — so it is described here rather than left unmentioned.

What is recorded, per download: which release was fetched, on which UTC date, and a rotating pseudonym for the client. Nothing else.

That pseudonym is the point. It is HMAC(server secret + today's date, …) over either your install_id (if MediaForge sent one) or your IP address and User-Agent (if it did not). Three consequences follow, and all three are deliberate:

• The stored value cannot be reversed into an IP address, a User-Agent, or an install_id.
• Because the date is part of the key, the same client produces a different value every day — the rows cannot be linked into a history of who downloaded what over time, not even by us.
• It is therefore useful for exactly one thing, for exactly one day: not counting the same download twice. Each client counts once per version per day.

For a download, your raw IP address is never written to the database. It is read from the request, fed into the HMAC, and discarded. (This is about download counting specifically — telemetry does store the address of an accepted connection, described under "Your network address" above. Your web server's own access log is a third matter again, governed by whatever your operator configured it to keep.)

Two numbers are kept: a lifetime total per version, which is never deleted, and the dated event rows behind it, which are pruned automatically (default: 400 days, DOWNLOAD_EVENT_RETENTION_DAYS). Store operators can switch counting off entirely with DOWNLOAD_COUNTER_ENABLED=false.

Because no download row is linked to an install_id in any recoverable form, download counts are outside the scope of the deletion and export rights described above — there is nothing there to find under your ID, by design.

Where this data lives

Telemetry data lives in its own, physically separate database file from anything else this server manages (dev-info posts, module store data, admin accounts) — a backup or dump of one never contains a row of the other. This makes wholesale deletion for a given install_id possible without any risk of collateral damage to unrelated systems.

Questions

If anything in this document is unclear, or you want to ask about your data outside the formal request process above, reach out through the project's GitHub repository.