Skip to content
donnyflyPublic

About

A self-hosted Discord bot that monitors your tracker provider activity like SIMKL/MDBList/WeTrakr and posts to a Discord channel

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Repository files navigation

Bingecord cinema chat mascot Bingecord

A self-hosted Discord bot that turns your SIMKL, WeTrakr, or MDBList watch activity into clean Discord updates for TV shows, anime, and movies.

It supports automatic provider syncing, episode grouping, artwork and ratings, personal/server statistics, achievements, XP progression, challenges, leaderboards, and optional weekly recaps. All linked-account data is stored locally on your own server.

photo_2026-10-13_13-32-32 photo_2026-10-13_13-32-50 photo_2026-10-13_13-32-46 photo_2026-10-13_13-32-39

What you get

  • 🎬 Automatic SIMKL, WeTrakr and MDBList activity tracking for TV, anime, and movies
  • 👥 Watched Together combines matching watches from the same polling cycle, including mixed-provider groups
  • 📺 Consecutive episode grouping for cleaner Discord posts
  • 🖼️ Title logos, episode stills and TMDB artwork with available provider fallbacks
  • ⭐ IMDb ratings and 🌸 MyAnimeList ratings where available
  • 🎨 Rich/minimal embeds, artwork choices, and short/detailed activity text
  • 🔗 Per-member, per-server source selection with multiple linked accounts
  • 📊 Personal and server watch statistics
  • 🎲 Watching lists, planned-list random picks, and recommendations
  • 🧩 Cross-provider watch mapping and shared XP duplicate protection
  • 🔥 Watch streaks
  • 🏆 Server leaderboards
  • 📈 XP, levels, ranks, and prestige
  • 🎯 Daily and weekly watch challenges
  • 🏅 Achievements with XP rewards
  • 📅 Automatic weekly recaps
  • ⚙️ Server-wide feature switches for communities that only want basic activity tracking
  • 🏠 Multi-server support
  • 💾 Local persistent storage
  • 🐳 Docker support with a pre-built image

Commands

The bot displays Playing /bingecord help. Use /bingecord help for a private command guide and first-time setup instructions.

Command Who can use it Purpose
/bingecord help Everyone View the command guide and setup steps
/bingecord link Everyone Link a SIMKL, WeTrakr or MDBList account
/bingecord source Everyone Select the linked account used in this server
/bingecord mapping Everyone Privately inspect cross-provider matches and possible duplicate awards
/bingecord unlink Everyone Unlink a provider account
/bingecord stats Everyone View your watch/progression profile
/bingecord achievements Everyone View achievements and XP rewards
/bingecord challenges Everyone View daily and weekly challenges
/bingecord leaderboard Everyone View server leaderboards
/bingecord server-stats Everyone View server watch statistics
/bingecord community Everyone View the rotating weekly cooperative watch goal
/bingecord watching Everyone View your selected account's watching list and next episodes where available
/bingecord random Everyone Pick from your selected account's planned list
/bingecord recommend Everyone Get recommendations using selected-source history and exclusions
/bingecord style Everyone Change personal activity-post preferences
/bingecord user-reset Everyone Reset your tracking history for the current server
/bingecord setchannel Manage Server Choose the activity channel
/bingecord style-server Manage Server Set server-wide style defaults
/bingecord features Manage Server Enable or disable optional feature groups
/bingecord timezone Manage Server Set the server timezone
/bingecord weekly-recap Manage Server Post/test a weekly recap
/bingecord status Manage Server View configuration and sync health; optionally check user: @username
/bingecord checknow Manage Server Check selected providers immediately
/bingecord debug Manage Server Preview progression notifications without changing XP

Prefer the simple tracker experience?

Admins can use:

/bingecord features preset: Activity only

This keeps the core activity tracker while disabling optional progression, achievements, challenges, recaps, community goals, leaderboards, and similar extras.

Watched Together: matching movies, episodes, or identical episode ranges in the same channel combine when each watch timestamp is within 30 minutes of the others. Mentions do not ping. Everyone keeps their own XP and history. Matching requires a shared title identity and the same movie or episode/range in the same server. Partial-overlap ranges remain separate. Group descriptions display up to five member mentions. Admins can toggle it with /bingecord features feature: Watched Together enabled: False. Watches beginning at S1E1, including ranges starting there, include “🆕 Started watching this series.” on the last line after the ratings and a blank line.

Use:

/bingecord features preset: All features

to restore the full experience.


Installation

Recommended: Docker Compose

Requirements

You will need:

  • A machine that can run Docker
  • A Discord bot token
  • A SIMKL Client ID if you want SIMKL tracking
  • A TMDB API key
  • A WeTrakr application key if you want WeTrakr tracking
  • An MDBList OAuth Client ID if you want MDBList tracking
  • An optional MDBList API key for additional ratings

1. Create a Discord bot

Create an application in the Discord Developer Portal, add a bot, and copy its token.

When inviting it to your server, include:

  • bot
  • applications.commands

Allow View Channel, Send Messages, Embed Links, Attach Files and Read Message History in the channel you choose.

2. Enable SIMKL tracking (optional)

Create an application in the SIMKL developer settings and copy its Client ID.

Individual Discord users will connect their own SIMKL accounts later with /bingecord link provider: SIMKL.

Leave SIMKL_CLIENT_ID blank to disable SIMKL. It is not required for WeTrakr or MDBList. Each provider is enabled independently by its own host credentials.

3. Get a TMDB API key

TMDB is used for artwork and media metadata.

The optional MDBLIST_API_KEY supplies additional IMDb/MyAnimeList ratings. It is separate from MDBList tracking authorization.

4. Enable additional tracking providers (optional)

WeTrakr

  1. Register or obtain a WeTrakr application key through its developer/API access process. See the official API documentation for authentication requirements.
  2. Set WETRAKR_API_KEY in the host's .env. This is the application's client ID, sent as the WeTrakr API key; it is not a member's account token.
  3. Start or recreate the bot. Each member runs /bingecord link provider: WeTrakr, follows the private authorization instructions, and approves with their own WeTrakr account.
  4. Select /bingecord source provider: WeTrakr.

The host configures the application once. Members do not need individual API keys. Private account data uses their separate OAuth tokens.

MDBList

  1. Register your own OAuth application at MDBList Developer, with device authorization available and read access for the bot.
  2. Set MDBLIST_CLIENT_ID in .env. Set MDBLIST_CLIENT_SECRET only if your registered application requires it for refresh.
  3. Start or recreate the bot. Each member runs /bingecord link provider: MDBList and approves the device authorization with their own MDBList account.
  4. Select /bingecord source provider: MDBList.

MDBLIST_CLIENT_ID enables tracking. MDBLIST_API_KEY enables optional ratings enrichment. They serve different purposes; the ratings key does not replace member OAuth authorization. See MDBList integration details for provider limitations and validation.

Enable any combination of SIMKL, WeTrakr and MDBList. None is the primary provider; leave unused provider credentials blank.

5. Create the Docker setup

mkdir -p ~/bingecord
cd ~/bingecord

Create docker-compose.yml:

services:
  bingecord:
    image: ghcr.io/donnyfly/bingecord:experimental
    container_name: bingecord
    restart: unless-stopped
    env_file:
      - .env
    volumes:
      - ./data:/app/data

Create .env:

DISCORD_BOT_TOKEN=your_discord_bot_token_here
TMDB_API_KEY=your_tmdb_api_key_here
# Optional tracking providers (configure only those you use):
SIMKL_CLIENT_ID=
WETRAKR_API_KEY=
MDBLIST_CLIENT_ID=
MDBLIST_CLIENT_SECRET=

# Optional additional ratings:
MDBLIST_API_KEY=

SIMKL_DEFAULT_TIMEZONE=Asia/Singapore

POLL_INTERVAL_MINUTES=60
POLL_CONCURRENCY=5
HISTORY_BACKFILL_CONCURRENCY=2

Start the bot:

docker compose up -d

Check it:

docker compose ps
docker compose logs -f

Once the bot is online:

  1. Run /bingecord setchannel to choose where activity should be posted.
  2. Each member runs /bingecord link for their provider, then /bingecord source to select it.
  3. An admin runs /bingecord checknow to import the initial history quietly.
  4. Mark a new watch after that import. Wait for scheduled polling or run /bingecord checknow again.
  5. Use /bingecord stats and /bingecord status to verify the selected account and sync health.

Running with Python

Docker is recommended, but the bot can also run directly with Python 3.13, matching the Docker image.

git clone --branch experimental https://github.com/donnyfly/Bingecord.git
cd Bingecord

python -m venv venv

Activate the environment:

Linux/macOS

source venv/bin/activate

Windows PowerShell

.\venv\Scripts\Activate.ps1

Check that python --version reports the intended Python installation before creating the environment.

Then:

python -m pip install -r requirements.txt

Copy .env.example to .env, fill in your credentials, and start:

python bot.py

Configuration

The main settings live in .env. Use .env.example as the complete template; leave optional credentials blank until configured.

Setting Required Default Purpose
DISCORD_BOT_TOKEN Yes — Discord bot token
SIMKL_CLIENT_ID For SIMKL — Host application ID enabling SIMKL tracking
TMDB_API_KEY Yes — Artwork and media metadata
WETRAKR_API_KEY For WeTrakr — Host application key for WeTrakr tracking
MDBLIST_CLIENT_ID For MDBList tracking — Host OAuth application ID
MDBLIST_CLIENT_SECRET Application-dependent — MDBList token refresh secret, if required
MDBLIST_API_KEY No — Additional IMDb/MAL ratings; separate from tracking
POLL_INTERVAL_MINUTES No 60 Polling interval in minutes for all selected providers
POLL_CONCURRENCY No 5 Concurrent SIMKL user checks
HISTORY_BACKFILL_CONCURRENCY No 2 Limits simultaneous SIMKL history imports
SIMKL_DEFAULT_TIMEZONE No Asia/Singapore Default timezone for all providers; legacy variable name
DISCORD_DEV_GUILD_ID No — Optional immediate development-server command sync
IMDB_RATINGS_DB_PATH No data/imdb_ratings.db Generated episode-rating database path

Server admins can override the timezone with /bingecord timezone.

First-import performance and progress

Historical XP reconciliation

When another provider already supplies watch observations, unmatched historical imports are held for review, rather than automatically credited as additional viewings. This includes apparently new historical titles until they can be reviewed; live activity still earns normal XP. Confirmed matches retain their existing award, first-account history imports keep their usual behavior, and held watches do not trigger watch-based challenge rewards. Stats can therefore include imported watches whose additional XP is pending.

Use /bingecord mapping repair_preview:True to refresh linked SIMKL catalog IDs and export bingecord-repair-preview.json. This can take several minutes for a large library. It normalizes verified episode references and complete absolute anime runs while preserving original observations. Different dates, aliases without verified IDs, incomplete episode crosswalks and conflicting IDs remain review items. Only unique, ID-verified duplicates within the strict live matching window produce a confirmed correction preview. The report includes projected XP, prestige, level and dependent challenge adjustments, without changing live XP.

For imported histories, /bingecord mapping primary_history:SIMKL saves your personal repair preference and generates a preview. It applies only to your Discord user across servers; it does not change the active tracking source, other users, or data on provider websites. Confirmed duplicate projections keep the primary provider's award. Uncertain date conflicts show the preferred historical date for review and still produce no deduction: choosing a primary does not prove that a separate rewatch was an import.

SIMKL identity metadata is also refreshed during full SIMKL reconciliation. These safeguards do not automatically deduct previously awarded XP or resolve held awards.

To apply the confirmed portion of a historical correction:

  1. Run /bingecord mapping repair_preview:True (or choose primary_history:SIMKL for your personal repair preference).
  2. Review the XP reduction and projected prestige/level. The response includes a unique /bingecord mapping repair_apply:TOKEN command when confirmed corrections exist.
  3. Run that exact apply command by itself. The bot first saves a private progression backup in data/repair-backups/ on the mounted data volume, then atomically commits the correction. No old activity or reward notifications are posted.

The token belongs only to the requesting Discord user, expires after 24 hours and is rejected if progression or linked account IDs changed since the preview. Generate a fresh preview in that case. Repeating an already successful token does not deduct XP again. A backup or store write failure leaves the correction unapplied. Backups contain the user's progression and repair plan, without authentication credentials; keep the data volume persistent.

The repair retains both provider observations as support for the remaining award and recalculates dependent watch challenge rewards, XP, level and prestige. Other users, active tracking sources, provider websites, achievements, community rewards and uncertain rewatches are unchanged. This does not resolve every imported-history discrepancy: different dates, conflicting IDs and incomplete anime crosswalks still require evidence and review. Existing preview exports from older builds cannot be applied; generate a new preview to obtain a server-side plan and token.

If no pre-import backup exists, a separate import rollback preview can hold older secondary-provider watch credits and a specified historical challenge grant batch. First choose a personal primary history, then use /bingecord mapping with all three options: rollback_source, rollback_import_before and rollback_rewards_at. Both timestamps must include a timezone; the reward timestamp selects the exact grant batch, while the cutoff selects watch dates strictly before it. The preview gives the exact selected amounts, projected progression and an apply token. This mode makes no provider calls.

This is an explicit policy rollback, not proof that the selected watches are duplicates or an exact restoration of a lost balance. Legitimate older history may be included. Selected watch awards are saved under pending_history_awards; original challenge credits are saved under pending_history_challenge_awards. The existing data-volume backup and stale-plan protections also apply. Held rewards require later review and have no automatic release command. Poll retries cannot re-credit held watch keys, and retained zero-credit challenge completions prevent immediate re-awards. Later watches, primary-provider watch XP and all source observations are retained. Review the scope before applying; use the ordinary confirmed-duplicate preview when this broader policy is inappropriate.

Rebuild progression from a provider

/bingecord mapping rebuild_source:SIMKL, rebuild_source:WeTrakr or rebuild_source:MDBList prepares a new balance from that provider alone. The existing rebuild_simkl:True shortcut still works. The bot fetches fresh full movie/episode history (all three catalogs for SIMKL), resolves metadata with four bounded workers, and checks provider activity markers before and after the read. Failed reads, changing activity or an empty dated snapshot do not create a rebuild plan. Your current XP remains intact during preview.

The private preview shows watch counts, watch XP at 4 XP per minute, qualifying achievement XP, eligible historical challenge XP and recorded community rewards preserved unchanged. Achievement eligibility respects each server's timezone and awards each achievement once globally. Challenges use the existing date-based calendar and history eligibility from January 2025. Missing runtimes use metadata lookups or the normal 25-minute episode/90-minute movie defaults. Undated episode rows are reported and skipped. Only dated watches returned by the chosen provider can be rebuilt; missing provider history cannot be reconstructed. Explicit unknown-date plays are reported and excluded from XP; failed pages, duplicate play IDs and incomplete identities abort the preview.

Review the breakdown and resulting level/prestige, then run the exact repair_apply command supplied in that preview. The bot checks provider activity again, saves a private backup of progression, server achievement locks and watch counters, and commits the rebuild atomically. The chosen provider’s cached watch counters are refreshed from the snapshot. Existing account links, active tracking sources, settings, community records and other members are retained. No old activity, level-up or reward notifications are posted by the rebuild. The result may be higher or lower than an earlier level: this recalculates today’s rules, discards old manual XP offsets, and does not target a previous rank.

Known secondary-provider observations and native play records stay seeded, with retired award pointers removed. Verified/established matches support the chosen provider’s new award; unmatched secondary history is excluded from the new balance and remains held for review. Re-importing known old keys cannot refill XP. New live event keys still earn normal XP subject to cross-provider matching. Held credits have no automatic release action. The same user-bound token, expiry, stale-progression/account guards, idempotent receipt and backup protections apply as other repair modes.

Admins with Manage Server can use /bingecord rebuild user:@member source:WeTrakr (or SIMKL/MDBList). Leaving out source uses the member's selected source in that server. The member must belong to that server and have the requested provider linked there. The private preview gives an exact /bingecord rebuild user:@member apply_token:TOKEN command; run it without source to apply. Permissions and the member's provider link are checked again at application. Tokens are bound to the requesting admin, target member and originating server; the receipt and backup record who requested the rebuild. This changes that member’s shared progression across servers, while preserving all other members. Previews and results are private, and historical activity/reward notifications are silent. A new preview for the same target replaces their earlier unused plan.

MDBList and WeTrakr first imports run as background jobs, so scheduled checks and normal posts for other members can continue. Each provider runs at most two import jobs and four enrichment lookups at a time. Concurrent requests for the same title, season or anime mapping share their in-flight metadata reads.

/bingecord checknow waits for this server's imports and refreshes its private progress message every 15 seconds. /bingecord status user:@username shows imported-page enrichment counts too. Counts describe downloaded plays, not an assumed percentage of the entire library. If Discord expires a long-running interaction, the background job continues; use status to check progress.

Completed pages and enrichment batches are staged in the existing data volume and can resume after interruption or restart. Staging is account-scoped, expires after 24 hours, and never changes watch XP or live history by itself. If the provider's activity stamps change, pagination restarts against the new snapshot while exact unchanged plays can reuse their enrichment. History is only reconciled after a complete validated read; initial imports remain quiet. No new environment settings are required.

Activity customization

Users can run /bingecord style to choose:

  • Rich or Minimal embeds
  • Automatic, poster, or backdrop artwork
  • Short or detailed activity text
  • Rating visibility
  • Personal-rating visibility, independently of public IMDb/MAL scores

Server admins can set defaults with /bingecord style-server. Personal settings override server defaults.

Titles and activity headers link to the provider entry and member profile when available. Status activities use posters. Episode watches can use episode stills/backdrops and show individual episode IMDb ratings. They omit MAL and do not substitute the whole show's rating for a missing episode rating. Anime movies and anime status activities can show title-level IMDb and MAL scores.

For MDBList, supported playback changes can produce Paused notices. Available notices depend on each provider's API.

Personal ratings and completion

SIMKL, WeTrakr and MDBList can display your own rating from your selected account alongside the existing public scores. Movies use Your rating; series status posts use Your series rating. A watched episode uses only your episode-specific rating when available, never the show's personal rating. At a season milestone, an available season rating takes priority; a series rating remains explicitly labelled. SIMKL anime entries that represent a verified single season use Your season-entry rating. Scores display on a 10-point scale; WeTrakr's valid zero and MDBList's precise half-point scores are preserved.

The final episode or episode-range post can include:

Label Required evidence
Finished Season N Every regular episode watched, all aired, and a confirmed finale, a later season already airing, or an ended/cancelled series
Caught up Every currently aired regular episode watched across the verified catalogue
Completed this series An ended/cancelled series with its complete regular-episode catalogue watched

Specials do not block completion. Missing metadata or uncertain anime episode mappings withhold an unverified milestone. Native completion notices merge into a recent final-watch post when possible; an unverified native status is labelled Marked as watched rather than claiming the whole series is complete.

Rate before watching to include your score immediately. If you rate, change or remove a score afterwards, the next successful poll updates the latest related bot post from the last seven days, including after a restart. Older posts stay unchanged. Deleted or inaccessible messages are not reposted. Source switches freeze the old account's posts; silent history imports produce no completion announcements. Removing a watch can invalidate a recent completion annotation. Rating edits and completion annotations never award XP.

Watched Together posts show each displayed member's own score, with at most five members' details. /bingecord style show_personal:Off hides your score; /bingecord style-server supplies the server default and its existing force-override control. Existing public-rating settings and data sources are unchanged. Personal ratings are read only: Bingecord does not submit ratings to your tracker.

See the ratings and completion test checklist for examples and live verification across all three providers.


Progression & statistics

When enabled, the bot adds a progression layer on top of normal watch tracking.

  • Episodes award watch XP
  • Movies award watch XP
  • Achievements and challenges can award bonus XP
  • Users progress through levels, ranks, and prestige tiers
  • /bingecord stats shows watch history, XP, streaks, achievements, recent activity, and more
  • /bingecord leaderboard compares server members across watch/progression categories
  • Weekly recaps summarize recent server activity

These systems are optional. Servers that only want activity posts can use the Activity only feature preset.

Watch XP rewards

All completed TV episodes, anime episodes, movies and anime movies earn 4 XP per minute of catalog runtime. Equal watch time earns equal base XP across providers and media types.

Watch Runtime Base XP
Anime episode 24 minutes 96
TV episode 45 minutes 180
Drama episode 60 minutes 240
Drama episode 72 minutes 288
Movie 90 minutes 360
Movie or anime movie 120 minutes 480

The bot uses the completed item's catalog runtime, not time spent with playback open. Fractional minutes are retained until the final XP is rounded to the nearest integer (halves round up). Three 24-minute episodes and one 72-minute episode each earn 288 XP.

Episode runtime comes from provider metadata or cached TMDB season details. If an exact episode runtime is unavailable, the series' typical episode runtime is used. If no valid catalog runtime can be found, the fallback is 25 minutes / 100 XP for an episode or 90 minutes / 360 XP for a movie. Estimated duration also counts toward minute-based challenges.

Community Watchathon

The current community goal switches to watch time across TV, anime and movies immediately after deployment. Unfinished goals for the server-local week beginning 12 October 2026 and future weeks use Watchathon. Already reached or paid legacy goals retain their original rules and rewards.

  • The target is 180 minutes per recently active member, based on the preceding 14 days of credited, selected-source activity. It stays fixed for the week. With no recent duration data, a new server starts with a one- or two-member baseline.
  • Members need 30 minutes to qualify. The goal requires one to three qualifying contributors, depending on the baseline size; a two-member baseline requires both members.
  • The bonus pool is 2 XP per target minute: half shared equally among qualifying members and half proportional to their watch minutes. Rewards settle after the week ends and are recalculated after removals.
  • Confirmed duplicate watches count once. Estimated runtime counts; legacy awards without recorded runtime do not supply guessed minutes.
  • Progress notices cover 25%, 50%, 75% and 100%, with only the highest new milestone posted per check. A 100% time milestone still needs enough qualifying contributors.
  • /bingecord community shows contributors, remaining minutes and the server-timezone reset countdown. New members may contribute without changing the frozen target.

The personal minute-based daily/weekly challenge pools permanently replace the old pools immediately for the current periods; this is permanent, not a temporary event.

Multiple providers, one progression

Each member selects one source per server. The selected account supplies watch totals, history, watching/planned lists and recommendation exclusions. Servers can combine members using different providers.

XP, levels, ranks and prestige remain shared for the Discord user. Initial imports and source-switch catch-up do not post old watches or replay progression animations. Switching itself does not remove XP.

A shared watch ledger matches confirmed cross-provider occurrences using catalog IDs and episode identities. The same matched watch earns XP once; genuine rewatches remain separate. Uncertain matches remain separate for review. A watch removal reverses its contribution only when no other imported provider observation supports it; inactive-account changes become known when that source syncs again.

/bingecord mapping privately shows matches, unpaired watches and possible duplicate awards without changing XP. /bingecord user-reset resets this server's imported tracking state and achievements while retaining links, global XP and personal style; subsequent history import is quiet.


Updating

When moving to the renamed project, stop the existing Compose deployment before replacing its configuration so two containers do not poll the same accounts. Keep the same ./data:/app/data mount and existing .env. The new image is ghcr.io/donnyfly/bingecord:experimental; pull it after the build finishes. The Discord application's display name can be changed separately in the Developer Portal.

Docker Compose

cd ~/bingecord
docker compose pull
docker compose up -d

Python

git pull
python -m pip install -r requirements.txt

Then restart the bot.

Keep your existing data directory when upgrading from SIMKL-only releases. Back it up before a migration; do not unlink accounts or delete state as a routine update step. The unified commands use /bingecord … names. After editing .env, recreate Docker containers with docker compose up -d --force-recreate to load the new values.

When this branch is promoted and a stable image containing multi-tracker support is published, switch the image tag to :latest and remove --branch experimental from new source installations.


Data & backups

Persistent data is stored in the mounted data directory.

The important file to back up is:

data/store.json

It contains bot state and linked-account authentication information, so keep it private.

The IMDb ratings database can be rebuilt automatically and does not normally need to be backed up.


Troubleshooting

Bot is online but does not post activity

Check that:

  1. You linked your account with /bingecord link and selected it with /bingecord source.
  2. An activity channel is configured with /bingecord setchannel.
  3. The bot can send messages in that channel.
  4. The initial quiet import has finished and there is new provider activity to post.

Admins can run /bingecord checknow and /bingecord status for an immediate check. Use /bingecord status user: @username to inspect one member; server results are paginated in groups of five.

A “no active SIMKL targets” log is normal when everyone selects another provider. Provider quota delays and authorization errors appear in sync health. WeTrakr journal entries can take several seconds to become visible; a check immediately after marking a watch may return zero, with the next poll picking it up.

Ratings or artwork are missing

An MDBList TIMEOUT or NETWORK_ERROR means the API connection/read failed. Read requests retry once, with a 10-second connection limit and 30-second total limit per attempt; repeated failures trigger a 60-second cooldown shared by personal-rating reads and watch polling. Existing ratings, watch history, checkpoints and XP stay intact. OAuth token requests are never automatically replayed. If timeouts continue, check the bot host's outbound connectivity to api.mdblist.com; these errors alone do not mean you need to relink or reset data.

Availability depends on provider/catalog metadata. Individual episode IMDb scores may be missing even when the series has a rating. The bot keeps source episode coordinates for metadata lookups separately from mapped anime display numbering.

Slash commands are missing

Make sure the bot was invited with both the bot and applications.commands scopes.

Discord global command changes can also take some time to appear.

Container keeps restarting

docker compose ps
docker compose logs --tail=100

Most startup/configuration problems will be shown in the logs.


Security

Never publicly share or commit:

  • .env
  • Discord bot tokens
  • Host application keys and client secrets
  • SIMKL, WeTrakr and MDBList account tokens
  • data/store.json

If a Discord bot token is exposed, regenerate it immediately in the Discord Developer Portal.


Development & validation

The root bot.py launches the application. Source lives in trackerbot/, organized into shared core/, provider integrations/, metadata/, presentation/ and read-only validation/ modules. Automated coverage lives in tests/.

The shared interface supports adding providers, but each adapter still needs authentication, API-specific reconciliation and capability checks. Complete the outstanding live checks before promoting multi-tracker support as full production parity.


License

Bingecord is licensed under the MIT License.

About

A self-hosted Discord bot that monitors your tracker provider activity like SIMKL/MDBList/WeTrakr and posts to a Discord channel

Topics

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages