This document describes how everything in this repository fits together except the Electron front end, per the user request. It is meant to be an orientation layer that points you toward the deeper, per-directory breakdowns added alongside it.
app/mtgatracker_backend.pyis the CLI entry point that accepts log-watching flags, spins up an asyncio websocket server (default127.0.0.1:8089), and boots worker threads.- A
KillableTailerdefined inutil.pyfollowsoutput_log.txt(or a provided log) and pushes raw log “blocks” intoapp/queues.block_read_queue. app/tasks.block_watch_tasknormalizes those blocks, extracts JSON payloads, and forwards structured blobs tojson_blob_queue.app/tasks.json_blob_reader_taskdeduplicates blobs, keepsmtga_app.mtga_watch_appin sync, and publishes game/deck/collection changes to dedicated multiprocessing queues (e.g.,game_state_change_queue,decklist_change_queue,general_output_queue).app/dispatchers.pyinspects each blob to determine which parser routine inapp/parsers.pyshould run (game state messages, deck updates, inventory events, direct challenges, etc.).- Parser routines manipulate the domain model under
app/models/, update the runningGame/Matchobjects, persist deck collections viamtga_watch_app, and emit derived insights (draft pick analysis, chess timers, draw odds). - The websocket handler in
mtgatracker_backend.pymultiplexes coroutine tasks that streamgame_state,decklist_change, andgeneral_outputmessages to any connected UI (typically the Electron client). - Ancillary tooling—root-level scripts, docs, legal copy, and static assets—support development, release pipeline, and community operations.
┌──────────┐ blocks ┌────────┐ blobs ┌────────────┐ events ┌──────────┐
│ Tailer │───────────►│ tasks │──────────►│ dispatchers│─────────────►│ parsers │
└──────────┘ │ block/ │ │ + queues │ └────┬─────┘
│ json │ └────────────┘ │
└────────┘ ▼
┌──────────────────────────────────┐
│ mtga_watch_app (state + models) │
└──────────────┬───────────────────┘
│
┌──────▼──────┐
│ websocket │
│ server │
└──────┬──────┘
│
UI / automation clients
| Directory | Purpose | Key entry points | Deeper documentation |
|---|---|---|---|
app/ |
Python log-watching backend, domain models, parsers, queues | mtgatracker_backend.py, tasks.py, parsers.py, models/ |
app/ARCHITECTURE.md |
docs/ |
Static marketing/docs site served via GitHub Pages | index.html, js/main.js, explore/ content |
docs/ARCHITECTURE.md |
.readme_data/ |
Image assets embedded throughout the main README and guides | Image files referenced via raw GitHub URLs | .readme_data/ARCHITECTURE.md |
issues/ |
Contributor-facing instructions for reporting bugs and feature requests | issues/README.md |
issues/ARCHITECTURE.md |
legal/ |
Privacy policy & terms of service referenced from installers and docs | privacy.md, tos.md |
legal/ARCHITECTURE.md |
scripts/ |
One-off or historical maintenance scripts (card ID generation, log splitting) | generate_base_mtga_id_lookup.py, log_splitter.py |
scripts/ARCHITECTURE.md |
webtasks/ |
Placeholder for the serverless endpoints consumed by docs/js/main.js |
Public README explaining move to private repo | webtasks/ARCHITECTURE.md |
electron/ |
Desktop UI (explicitly out of scope for this documentation pass) | electron/main.js, renderer bundles |
electron/ARCHITECTURE.md (scope caveat) |
requirements.txtandrequirements-tests.txtpin the Python dependencies used byapp/. Install these into your virtual environment before runningmtgatracker_backend.py.build.sh,deploy.sh,appveyor.yml, and.travis.ymlcapture historical CI/CD steps used to package the Electron app with the Python backend via PyInstaller.util.pyis intentionally at the repo root because it is shared by both the backend and packaging scripts. Notable exports includeKillableTailer, deck-processing helpers, rarity/color ranking utilities, andresource_path()for PyInstaller compatibility.mtgatracker_backend.specdefines the PyInstaller build manifest that glues the Python backend into the Electron bundle.- Global documentation such as
README.md,CONTRIBUTING.md,CODE_OF_CONDUCT.md, andstream_guide.mdremain the authoritative references for users and contributors; the per-directory docs you are reading layer on internal details needed for engineering work.
- Log storage expectations:
mtgatracker_backend.pyassumes Windows-style%APPDATA%/../LocalLow/Wizards Of The Coast/MTGA/output_log.txtunless--log_fileis provided. Running it on other platforms requires pointing to a captured log file. - Threading model: The backend mixes
threading.Threadworkers (for log parsing and mouse hooks) withasynciocoroutines (for websocket IO) andmultiprocessing.Queueinstances (for inter-thread communication). Avoid blocking operations in parser functions to keep the websocket loop responsive. - Message contract: Websocket messages are JSON dictionaries annotated with a
data_typefield (game_state,decklist_change,message,error). Downstream clients should be tolerant of missing keys because replay logs sometimes omit fields. - Persistence: Deck lists and collection snapshots are serialized to
%APPDATA%/../LocalLow/MTGATracker/settings.jsonviamtga_watch_app.save_settings(). Editing that file manually without recalculating hashes can desynchronize odds calculations. - External services: The only active network calls outside the websocket listener are the optional HTTP requests in
mtga_app.mtga_watch_app(for version hashing) and the marketing site’s calls to Auth0 Webtask endpoints (seedocs/js/main.js).
- Electron renderer/main-process behavior, build tooling (
npm, webpack, Sass), and UI assets live underelectron/and remain intentionally undocumented here other than a pointer. - Commercial/legal artifacts kept in private repositories (notably the Auth0 webtasks referenced from the docs site) are described only at a high level because their implementation lives elsewhere.
Refer to the per-directory ARCHITECTURE.md files for drills-down into each area.