Metacritic Score Feed

Ein persönlicher RSS-Feed für Metacritic-Filme und -Serien, die einen Metascore ≥ Schwellwert erreichen. Default ist 0, d. h. jeder Titel, sobald er überhaupt einen Metascore hat (genug Critic-Reviews) — der Score steht in Titel und Beschreibung, du entscheidest im Reader, ob sich der Film lohnt. (Höher setzen für nur „gute": 61 = Metacritics „generally favorable"-Grenze, grünes Band 61–100.) Läuft kostenlos per GitHub Actions (Actions-Minuten sind für öffentliche Repos gratis), erzeugt eine feed.xml, die du in Readwise Reader, Tapestry oder jedem anderen RSS-Reader abonnierst. Jeder Eintrag trägt das Poster als Thumbnail.

---

Warum das nötig ist (und warum der alte Reddit-Ansatz nicht mehr geht)

Der klassische r/rss-Trick war: Metacritics eigene offizielle RSS-Feeds nehmen und nur die Einträge durchlassen, die schon einen Score haben (siehe claytono/metacritic-rss). Das Problem: Metacritic hat nach dem Fandom-Relaunch (~2023) alle eigenen RSS-Feeds abgeschaltet. Die Input-Quelle existiert nicht mehr.

Dieses Projekt holt die Daten deshalb selbst von den öffentlichen „Newest Releases"-Browse-Seiten und wendet dieselbe Filter-Logik an.

Der Kern-Trick: „Score kommt erst später"

Genau dein Bedenken — viele Titel werden zuerst ohne Score gelistet und bekommen erst später einen, wenn genug Kritiken da sind. Die Lösung ist ein Event-Log-Modell:

• Das Skript schaut regelmäßig auf die neuesten Releases (dort erscheinen bewertete und noch unbewertete Titel).
• Ein Titel wandert genau in dem Moment in den Feed, in dem er zum ersten Mal den Schwellwert überschreitet (bei Default 0: sobald er überhaupt einen Score hat). Achtung: Der Score wird dabei eingefroren — steigt er später, taucht der Titel nicht erneut auf.
• Der Zustand steht in state.json, indexiert über die Titel-URL (= die RSS-<guid>). Dadurch erscheint jeder Titel exakt einmal — beim ersten Qualifizieren.
• Der pubDate eines Eintrags ist der Zeitpunkt, an dem er qualifiziert hat (nicht das Kinostart-Datum). So taucht ein Film auch dann frisch oben im Reader auf, wenn sein Release-Datum schon etwas zurückliegt und der Score erst jetzt kam.

Du überwachst also den Übergang „bewertet und gut genug", nicht das ursprüngliche Einstellen. Der Reader dedupliziert über die <guid>, es gibt nie Doppelungen.

---

Schnelltest (lokal)

pip install -r requirements.txt

# Nur anschauen, nichts schreiben — zeigt jede geparste Karte:
python metacritic_feed.py --dry-run --debug --media movie --pages 1

# Echten Lauf machen (schreibt feed.xml + state.json):
python metacritic_feed.py --threshold 61 --media movie,tv --pages 3

Beim ersten echten Lauf werden alle aktuell sichtbaren, qualifizierenden Titel in den Feed geschrieben (der „Startbestand"). Danach kommen nur noch neu qualifizierende dazu.

---

Braucht es ein neues Repo?

Nein. Der ganze Ordner metacritic-rss/ ist in sich abgeschlossen und kann als Unterordner in ein bestehendes GitHub-Repo. Zwei Dinge müssen aber erfüllt sein, damit ein lebendiger Feed entsteht:

1. Ein Scheduler muss das Skript regelmäßig ausführen → dafür ist .github/workflows/feed.yml (GitHub Actions) zuständig. Ein reiner „Skill", den du in einer Session aufrufst, reicht nicht — der läuft nur on-demand, nicht automatisch im Hintergrund.
2. Die feed.xml muss öffentlich erreichbar sein, damit Readwise/Tapestry sie abrufen können.
   • Ist dein Repo öffentlich → passt, raw- oder Pages-URL funktioniert direkt.
   • Ist dein Repo privat → die Raw-URL braucht ein Token (für Reader unbrauchbar), und GitHub Pages auf privaten Repos gibt es nur in bezahlten Plänen. Lösung siehe unten.

Privates Repo? Kein Problem — drei Wege

Dein Code hier enthält keine Geheimnisse (nur ein öffentlicher Scraper), es spricht also nichts dagegen, ihn öffentlich zu machen. Trotzdem muss die feed.xml an einen öffentlich erreichbaren Ort:

1. Eigenes kleines öffentliches Repo (empfohlen, am einfachsten). Leg nur für diesen Feed ein neues öffentliches Repo an, wirf diese Dateien rein, Actions + Pages/raw an. Dein privates Memory-/Skills-Repo bleibt unberührt. Das ist der kürzeste Weg zu einer testbaren URL.

2. Code privat lassen, nur die feed.xml in einen öffentlichen Gist schreiben. Der Workflow läuft im privaten Repo, state.json wird dort committet, und nur die feed.xml wird in einen öffentlichen Gist gepusht. Feed-URL = https://gist.githubusercontent.com/DEIN_USER/GIST_ID/raw/feed.xml (zeigt immer die neueste Version). Nötig: ein Token mit gist-Scope als Repo-Secret GIST_TOKEN. Publish-Step statt des Commit-Steps:

   - name: Publish feed.xml to public gist
     env:
       GIST_TOKEN: ${{ secrets.GIST_TOKEN }}
       GIST_ID: "DEINE_GIST_ID"
     run: |
       python - <<'PY'
       import json, os, urllib.request
       body = json.dumps({"files": {"feed.xml": {"content": open("feed.xml").read()}}}).encode()
       req = urllib.request.Request(
           f"https://api.github.com/gists/{os.environ['GIST_ID']}",
           data=body, method="PATCH",
           headers={"Authorization": f"token {os.environ['GIST_TOKEN']}",
                    "Accept": "application/vnd.github+json"})
       urllib.request.urlopen(req).read()
       print("gist updated")
       PY
       # state.json weiterhin ins (private) Repo committen:
       git config user.name "github-actions[bot]"
       git config user.email "github-actions[bot]@users.noreply.github.com"
       git add state.json && git commit -m "Update state [skip ci]" || echo "no changes"
       git push
   

3. GitHub Pro/Team → dann kannst du Pages direkt auf dem privaten Repo aktivieren.

This is the beginning of the README. Read the rest at the original. Read the full README ↗