Fixes the run ledger added in 1.26.2341504, which never recorded anything. If you are on 1.26.2341504, update: its counter is silently dead. No other behaviour changes.
The run ledger never wrote a line
_append_ledger_entry read self.LEDGER_FILE. That constant, and LEDGER_MAX_BYTES, are defined on the PluginConfig class rather than on Plugin, and every other file path in the plugin is reached as PluginConfig.NAME. The read raised AttributeError on every applied run that changed a channel, so /data/event_channel_managarr_ledger.jsonl was never created.
Both reads now go through PluginConfig.
Why it was not obvious
The writer catches Exception on purpose, so that a failure to record a run can never fail a scan that has already changed channels. That is still the right behaviour, but it meant the only trace was a single line in the container log:
Could not append to the run ledger ('Plugin' object has no attribute 'LEDGER_FILE');
the scan itself is unaffected.
Everything else looked healthy: scans ran and applied their changes correctly, and the ledger being absent is indistinguishable from an installation where no run has changed anything yet.
Nothing else was affected. Channel visibility, the managed dummy EPG, the CSV exports and the scheduler all behaved correctly throughout; only the run ledger, and any counter built on it, were dead.
Test coverage for the class of mistake
tests/contract/test_self_constants_resolve.py now asserts that every self.SOME_CONSTANT read anywhere in the Plugin class is actually defined on Plugin. That catches this whole category rather than this one instance, and it carries a guard against passing vacuously. Two narrower tests name the ledger constants directly.
The existing tests missed the bug because they checked structure: that the writer exists, catches exceptions, opens the file in append mode, and is called after the database transaction commits with transition counts. None of that exercises attribute resolution.
Verification
The fixed writer was exercised against the deployed code inside a running Dispatcharr container, with the ledger path pointed at a throwaway file, and produced a well-formed entry:
{"ts": "...", "version": "1.26.2351639", "shown": 3, "hidden": 1, "scheduled": true}Upgrading
Nothing to configure. No setting or action was added, removed or renamed, and plugin.json fields are unchanged. The ledger begins recording on the first applied run that changes a channel's visibility after this build loads.