Skip to content

Collect Backbone diagnostics

Last updated: 2026-10-27

A useful report identifies the appliance, client, source type, exact safe error, and reproduction path without exposing credentials or private content. Backbone does not currently provide an automatic sanitized support-bundle command. Create a plain-text summary manually and review every line before sending it.

Record the version and source context

Include the following when they are available:

  • the appliance version and source edition reported by the appliance status check;
  • the active database schema revision and head revision;
  • the client name, application version, operating system, and device category;
  • whether the setup is Local Install or LAN Backbone, and whether the provider is Xtream or live M3U with optional XMLTV;
  • the installed image digest and the distribution's recorded source commit or export-manifest provenance, if supplied;
  • whether the issue began after installation, upgrade, restore, provider change, or account/trust change; and
  • approximate date, time, and time zone of the most recent reproduction.

Do not guess a version or copy a provenance identifier from another installation. If Standard is not yet publicly distributed in your setup, describe the reviewed distribution you actually used without publishing private source material.

Capture safe existing status

The appliance status check is the first read-only check. It reports service, database, version, edition, trust mode, and schema state. Status responses can contain the appliance identity; redact identifiers that are not needed by support.

For a sync problem, record these details from the paired client status view:

  • the current sync state and last sync timestamp;
  • any reported sync error code and whether it is marked retryable;
  • relevant counts and phase results from the bounded sync summary; and
  • whether a new sync request was queued, rejected because a sync was already active, or rate-limited.

These status projections are designed to omit provider configuration and raw provider errors. Still review the copied text instead of assuming every other log or API response has the same redaction.

Appliance logs can add context around the same timestamp, but log output is not automatically a safe support bundle. Copy only the relevant safe lines, and do not include request headers, tokens, URLs, device names, or local addresses.

For an owner investigating a TMDB match, the existing owner-only title debug resource can expose persisted match state for one movie or series. It is a read-only diagnostic, not managed enrichment and not a general support export. Use it only when relevant and review its output before sharing.

Opt-in ambiguous-match logging can also record bounded title/channel candidates for match investigation under the appliance data directory. It is disabled by default and can contain catalog titles and identifiers. It excludes URL-shaped fields, but that does not make the file safe to send wholesale.

Describe a minimal reproduction

Write numbered steps that another operator could follow without your secrets:

  1. Name the client screen or API operation in general terms.
  2. State what you expected and what happened instead.
  3. Include the exact safe error code or message, without embedded URLs or tokens.
  4. Say whether the problem occurs on one client or several, one provider or all, and one title/channel or an entire category.
  5. Note whether a manual connection works when discovery fails, and whether a different item from the same source plays.
  6. Include the smallest useful non-sensitive example, such as a redacted title label or an error code, rather than an entire catalog response.

Do not repeatedly reset providers, databases, devices, or key material just to make a report reproducible. Preserve the original state when support needs to distinguish a sync, trust, migration, metadata, guide, or playback failure.

Contact support

Send the manually reviewed summary to frontrow@wyredeck.com. Include the version and reproduction details above, plus what you already tried from Troubleshooting. Support may ask for a narrower follow-up; do not send an entire data directory in response.

General account, payment, and privacy guidance remains on the WyreDeck Help center and Privacy policy.

Never share these items

Remove the following from messages, screenshots, copied logs, terminal output, and archives:

  • anonymous account numbers or account-shaped credentials;
  • local or Cloud device tokens, claim polling secrets, and pairing codes;
  • provider usernames, passwords, source headers, API keys, and TMDB keys;
  • .env files, environment dumps, keyfiles, and encryption-key values;
  • SQLite databases, database snapshots, backup bundles, or their key material;
  • playlist, stream, guide, provider-server, or credential-bearing URLs;
  • trusted-device IDs, appliance IDs, local hostnames/addresses, and customer or household names unless support explicitly needs a redacted label; and
  • complete provider catalogs, viewing history, or profile-state exports.

A provider ID or request code can still identify private state even when it is not a password. Redact identifiers by default. Never place a secret in a URL, command-line argument, or public paste service for support.

For recovery-related evidence, keep the original backup private and follow the non-destructive checks in Operate and recover.