# ESPuino Mediahub - Feature Requests

**URL:** <https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779>\
**Category:** Feature Request\
**Created:** [20. September 2026 um 18:07 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779 "2026-09-20T18:07:35Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [20. September 2026 um 18:07 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/1 "2026-09-20T18:07:35Z")

</div>

Hallo zusammen,

vielen Dank für die kontinuierliche Weiterentwicklung von ESPuino! Ich freue mich nun vor allem über das tolle neue Feature mit dem serverbasierten Bereitstellen der MP3s, da ich es oft nicht geschafft habe, neue Musik oder Geschichten auf meine zwei Musikkisten zu spielen, das Problem gehört nun der Vergangenheit an. Ich habe den Mediahub gemäß Anleitung problemlos aufsetzen können und nach dem Firmware-Update der beiden ESPuinos auch verbinden können.

Ich plane zukünftig ausschließlich MP3s per Mediahub bereitzustellen, und ich möchte, das die Karten auf beiden Kisten gleichermaßen funktionieren. Dafür wären folgende Anpassungen hilfreich:

1. Eine eingelesene Karte, die der ESPuino nicht kennt, wird automatisch als Mediahub-Karte registriert, ohne das ich sie im ESPuino zuweisen muss.
2. Eine im Mediahub konfigurierte Karte funktioniert gleich auf allen angebundenen Geräten. Aktuell muss ich nach dem Scannen der Karte auf Gerät 1 (und Zuweisung von Mediahub und Konfiguration im Mediahub) die gleiche Kartf auf dem zweiten Gerät scannen, zuordnen und im Mediahub konfigurieren.

Meine Wunschvorstellung wäre also: Scannen der Karte auf einem beliebigen Gerät, dann direkt Zuordnung der Karte im Mediahub, ab jetzt läuft die Karte auf beiden Geräten. Denkt ihr, das wäre sinnvoll / möglich?

Außerdem habe ich vom Podcast-Server im Nachbarthread gelesen, um ARD Sounds zu verbinden. Frage mich natürlich nun, ob sich das auch in den Mediahub integrieren ließe 🙂.

Viele Grüße

Dirk

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [20. September 2026 um 19:34 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/2 "2026-09-20T19:34:10Z")

</div>

Zu 1) Automatisch registrieren halte ich nicht für sinnvoll - da sammeln sich dann ggf. Leichen an für Requests, die nie beantwortet wurden von Mediahubs. Was ich mir indes vorstellen könnte ist aber so ähnlich: Man kann eine Option aktivieren, die dafür sorgt, dass für Karten, die unbekannt sind, automatisch Requests an alle Mediahubs geschickt werden (nacheinander mit Timeout - der erste, der antwortet, „gewinnt“). Kennt ein Mediahub die Karte, weil sie zuvor dort angelernt wurde, antwortet er mit einem Manifest. Das im Gegenzug ist ein Trigger für ESPuino, dass er die Karte nun wirklich selbst registriert. Da startet dann auch direkt der Download. Kommt hingegen kein Manifest, so passiert einfach nichts auf der ESPuino-Seite. D.h. ESPuino kennt die Karte dann weiterhin nicht.

Zu 2) Ja, man könnte mit einer Checkbox-Liste definieren, für welche ESPuinos der jeweilige Anlernvorgang gültig ist. So kannst du dann gleich mehrere ESPuinos in einem Zuge für eine Karte anlernen (oder auch nur einen). Ich stelle mir das so vor, dass man in den Grundeinstellungen des Mediahubs definiert, was der default ist. Ist der default „alle“, so sind per default alle ESPuinos zum Anlernen ausgewählt. Wenn nicht, dann nicht. Man kann es beim Anlernvorgang jedoch jedes Mal per Häkchen ändern.

Wobei (2) halt nur einen Benefit bringt, wenn für alle ESPuinos die gleiche Karte verwendet wird. Ist das nicht der Fall und man will dennoch duplizieren, dann braucht man eher einen Copy-Mechanismus: Zum Beispiel Karte 222222222222 soll sich verhalten wie Karte 111111111111.

Problematisch wird aber sicherlich, wenn mehrere Karten auf einem Mediahub „pending“ sind. Da wird man schnell den Überblick verlieren, was welche Karte war.

> [@albert0815](#):
>
> Außerdem habe ich vom Podcast-Server im Nachbarthread gelesen, um ARD Sounds zu verbinden. Frage mich natürlich nun, ob sich das auch in den Mediahub integrieren ließe 🙂.

Da habe ich ehrlich gesagt nix mit am Hut - das ist ein Userprojekt. Kann ich nix zu sagen.

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [20. September 2026 um 20:59 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/3 "2026-09-20T20:59:26Z")

</div>

Danke für die schnelle Rückmeldung. Soweit ich Deine Vorschläge zu 1 und 2 verstehe, kommt das ja schon recht nah an meine Wunschvorstellung ran. Der einzige Unterschied wäre, das ich bei der ersten Registrierung der neuen Karte (wo ja kein Manifest vom Mediahub zurück käme), explizit eine Zuordnung vornehmen müsste. Für den zweiten bräuchte es dann nicht mehr. Und ja, „Karte kopieren“ wäre für mich vermutlich auch etwas, was ich nutzen würde. Gibt natürlich teilweise den Wunsch, das gleiche Stück für jeden mit einer eigenen Karte zu verknüpfen.

Für mich wäre denke ich das Thema von zu vielen „Pending“ Karten nicht so problematisch, verstehe aber natürlich auch, dass da unterschiedliche Nutzer unterschiedliches Vorgehen haben.

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [21. September 2026 um 06:24 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/4 "2026-09-21T06:24:48Z")

</div>

> [@albert0815](#):
>
> Der einzige Unterschied wäre, das ich bei der ersten Registrierung der neuen Karte (wo ja kein Manifest vom Mediahub zurück käme), explizit eine Zuordnung vornehmen müsste.

Nein. Du aktivierst (optional) eine Option auf dem ESPuino, so dass alle unbekannten Karten zum Mediahub gepusht werden. Und zwar ohne, dass die Karte auf dem ESPuino registriert ist. Einfach so „best guess“-mäßig, Da der Mediahub die Karte noch nicht kennt, kommt kein Manifest zurück. Es passiert erstmal nix - ESPuino kennt die Karte weiterhin nicht. Nun hast du die Karten-ID auf dem Mediahub und sorgst dort für die Zuweisung mit Inhalt. Legst du die Karte auf den ESPuino nun erneut auf, so kennt ESPuino die Karte weiterhin nicht und schickt daher erneut einen Request an den Mediahub. Diesmal jedoch kommt ein Manifest zurück. In der Folge (weil ein Manifest als Antwort kam) wird ESPuino die Karte selbst vom Typ Mediahub anlernen - ab dann kennt er sie. Der Download startet dann auch direkt.

Wenn du den Inhalt beim Anlernen auf dem Mediahub gleich einem weiteren ESPuino zuweist, so wird, wenn du auf diesem zweiten ESPuino die Karte auflegst, diese auch erst unbekannt sein. Er wird die Anfrage an den Mediahub schicken, der antwortet direkt mit einem Manifest und der Download geht sofort los.

Also im Grunde ist mein Ansatz identisch zu deinem und von der Art, wie du es anwendest, äußerlich nicht unterscheidbar. Der Unterschied ist einfach nur, dass ESPuino unbekannte Karten nicht automatisch als Typ Mediahub anlernt, sondern es erst dann tut, wenn ein Manifest als Antwort kam. Das umschifft potentielle „Karteileichen“.

> [@albert0815](#):
>
> Für mich wäre denke ich das Thema von zu vielen „Pending“ Karten nicht so problematisch, verstehe aber natürlich auch, dass da unterschiedliche Nutzer unterschiedliches Vorgehen haben.

Man muss da halt am Ball bleiben. Wenn da fünf Karten pending sind, dann wird man Probleme haben, die zuzuordnen. Ich muss mal schauen, ob man den vorab Alias-Namen geben kann aktuell. Ist schon wieder so lange her 😃.

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [21. September 2026 um 06:59 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/5 "2026-09-21T06:59:29Z")

</div>

Okay, verstehe, das wäre ja dann optimal :).

Noch was anderes: heute Morgen ist es passiert, das die Karte, die schon erfolgreich konfiguriert und heruntergeladen war, nochmal runtergeladen wurde. Werd das mal im Auge behalten, weiß nicht genau, was da passiert ist, hab keine Logs vom ESPuino. Die Karte wurde aufgelegt, angehört, ESPuino aus, gleich wieder an, Karte drauf, Download fängt an. Der Mediahub lief die ganze Zeit durch, in den Logs sieht man nur, das Manifest und MP3s geladen wurden.

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [21. September 2026 um 17:59 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/6 "2026-09-21T17:59:12Z")

</div>

Nochmal zum Thema Podcasts / ARD-Sounds. Ich habe mir die bisherigen Ideen und Lösungen von @sandwich und @openplayer angeschaut - vielen Dank für Eure bisherige Arbeit!

Eine Idee, wie das im Mediahub aussehen könnte: Neben die bestehenden Optionen Audiofile und Webradio eine neue Option „Podcast“ (oder etwas spezielleres für ARD Sounds). Wenn das ausgewählt wird, könnte der Mediahub eine Suche nach Podcasts / Sounds anbieten und aus den Treffern könnte man wählen (entweder ausgewählte Folgen, oder eben „aktuellste“). Der Mediahub könnte die Quellen abrufen und lokal vorhalten. Wenn die Karte dann gescannt wird, lädt der ESPuino das Podcastfile vom Mediahub runter und hat es damit auch lokal (heißt: Offline-Verfügbarkeit und Kompatibilität mit der aktuellen Mediahub-Karte, also ohne Anpassung der Firmware des ESPuino selber).

Die hierfür notwendige API für ARD Sounds ist undokumentiert, wie stabil das läuft, hängt also auch ein bisschen davon ab.

Passt so etwas in die Richtung, die Du für den Mediahub im Kopf hast, @biologist?

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [21. September 2026 um 21:56 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/7 "2026-09-21T21:56:11Z")

</div>

Also generell klingt das für mich erstmal ok, wenn man sagt, dass der Mediahub die Podcast-Archive „abscannt“ (was auch immer das dann heißt) und das lokal speichert. Und das kann man dann irgendwie zu Karten/ESPuinos zuweisen. Weil wenn man es gespeichert hat, dann ist es ein File, wie der ganze Rest auch.

Die Frage ist dann aber halt, wie man damit umgeht, dass da neue Folgen hinzukommen und ob man alte aber wieder löschen will. Also ich bin kein Podcast-Hörer und insofern weiß ich nicht, was da wünschenswert wäre bzw, üblich ist.

Ich weiß nur, dass ich keine neuen Playmodes möchte. Aber das sollte ja kein Problem sein: Wenn ich es eh schon auf dem Mediahub gespeichert habe als Audiofile, dann muss sich ESPuino ja nicht dafür interessieren, dass das eigentlich ein Podcast war. Weil es muss ja dann nicht mehr gestreamt werden, sondern es wird vom Mediahub einfach runtergeladen. Insofern sollte das für einen ESPuino einfach sowas wie ein Hörspiel sein.

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [26. September 2026 um 10:31 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/8 "2026-09-26T10:31:30Z")

</div>

So, das ist jetzt eingebaut:

> [@green\_book ESPuino Mediahub](https://forum.espuino.de/t/espuino-mediahub/4607/13):
>
> So, ich habe das jetzt umgesetzt: [Merge branch 'feature-mediahub-unknown-card' into dev · biologist79/ESPuino@2b653de · GitHub](https://github.com/biologist79/ESPuino/commit/2b653defc07e3aa9aea8e2eedecc7dba5181f284)@albert0815 @harle @fox Drei Sachen sind neu, ich habe mich nun also doch mehr den Wünschen angenähert: a) Man kann nun in der Mediahub-Kladde per Option aktivieren, dass das Verzeichnis .mediahub angezeigt wird. Seid euch bewusst, dass dortige Manipulationen zu „komischen“ Effekten führen können. Also Audiofiles löschen sollte kein Problem sein, die werden nachgelade…

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [28. September 2026 um 07:58 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/9 "2026-09-28T07:58:29Z")

</div>

Hab den neuen DEV Branch auf unseren Musikboxen aufgespielt, und auch den Mediahub aktualisiert, finde ich gut, vielen Dank für die schnelle Umsetzung!

Ich habe auch einen ersten Versuch bzgl. Podcasts probiert. Ich könnte hierfür PRs auf dem Mediahub-Repo erstellen. Ich habe das in zwei Teile aufgeteilt:

1. Generelle Funktionen für Podcasts: Referenzierung von Podcasts für Karten, Auswahl des Podcasts mit RSS-Feed, Selektion „Neueste“ oder bestimmte Folgen; Download der Folgen in einem Cache, so das ESPuino sie abspielen kann (ohne Firmware-Änderungen).
2. Ein PR basierend darauf, der die (inoffizielle) ARD Sounds API anbindet, um auch von dort Podcasts anbinden zu können.

Hier ein paar Screenshots, wie das aktuell bei mir aussieht:

 ![image](https://forum.espuino.de/uploads/default/original/2X/b/b637c514c1c99535e33e02cc04612042bbf007a4.png)

 ![image](https://forum.espuino.de/uploads/default/original/2X/b/b31524392624c3eaa5183c11bf0afdd801b051fe.png)

 ![image](https://forum.espuino.de/uploads/default/original/2X/d/d07f442c8451ece63641b4bbec35a2b01015327d.png)

@biologist wäre es okay, wenn ich dafür PRs auf Deinem Repo erstelle?

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [28. September 2026 um 19:38 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/10 "2026-09-28T19:38:17Z")

</div>

> [@albert0815](#):
>
> @biologist wäre es okay, wenn ich dafür PRs auf Deinem Repo erstelle?

Klar, kannst du gerne machen. Ich hab nur ehrlich gesagt noch nicht verstanden, wie das genau technisch funktioniert.

Fragen:  
a) Wer wartet/testet das im weiteren Verlauf?  
b) Wer schreibt die Dokumentation und hält sie bei Änderungen (an diesem Feature) aktuell?  
c) Wer leistet User-Support?

Also ich begrüße die Einbindung des Podcast-Supports, aber die Person, die das supportet, muss eine andere sein als ich 🙂.

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [29. September 2026 um 14:01 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/11 "2026-09-29T14:01:51Z")

</div>

> [@albert0815](#):
>
> 1. Generelle Funktionen für Podcasts: Referenzierung von Podcasts für Karten, Auswahl des Podcasts mit RSS-Feed, Selektion „Neueste“ oder bestimmte Folgen; Download der Folgen in einem Cache, so das ESPuino sie abspielen kann (ohne Firmware-Änderungen).

Was mir gerade noch einfällt: Ist das generisch, so dass es, von proprietären Schnittstellen (ARD) abgesehen, immer funktionieren sollte? Also vielleicht kann man ja annehmen, dass dieser Teil generisch ist.  
Aber wie auch immer: Es muss jmd. supporten und Doku brauchen wir.

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [29. September 2026 um 20:19 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/12 "2026-09-29T20:19:28Z")

</div>

Ja, ich habe es extra zweigeteilt. Der erste Teil ist generisch, für jede Art von Podcast, der einen RSS-Feed bereitstellt. Der zweite Teil ist dann speziell für ARD-Sounds.

Bzgl. Support: Ich könnte auf jeden Fall eine Doku bereitstellen. Ich bin stiller Mitleser im Forum und verfolge die aktuellen Threads mal mehr und mal weniger. Ich wäre schon bereit, bei Problemen zu den Funktionen zu unterstützen, wir sind ja auch selber Nutzer.

Habe mal versucht, einen Draft PR auf dem Mediahub-Repo zu erstellen, das schlägt aber noch fehl mit „Pull request creation failed. Validation failed: must be a collaborator”

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [30. September 2026 um 06:04 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/13 "2026-09-30T06:04:43Z")

</div>

> [@albert0815](#):
>
> Bzgl. Support: Ich könnte auf jeden Fall eine Doku bereitstellen. Ich bin stiller Mitleser im Forum und verfolge die aktuellen Threads mal mehr und mal weniger. Ich wäre schon bereit, bei Problemen zu den Funktionen zu unterstützen, wir sind ja auch selber Nutzer.

Ok, passt 👍.

> [@albert0815](#):
>
> Habe mal versucht, einen Draft PR auf dem Mediahub-Repo zu erstellen, das schlägt aber noch fehl mit „Pull request creation failed. Validation failed: must be a collaborator”

Dazu habe ich mal Claude befragt:

> Die Meldung **„must be a collaborator"** bedeutet etwas anderes, als sie klingt: Sie kommt, wenn der Quellzweig des Pull Requests in **deinem** Repository liegen soll statt in einem eigenen Fork. Genau das darf nur, wer Schreibrechte bei dir hat. Der Mitwirkende hat also vermutlich dein Repo direkt geklont und versucht, seinen Branch dorthin zu schieben — typisch, wenn man `gh pr create` in einem direkten Klon aufruft oder in der VS-Code-Erweiterung das falsche Ziel-Repository stehen bleibt.  
> Der richtige Weg auf seiner Seite ist der übliche Fork-Ablauf: dein Repo forken, den Branch in **seinen** Fork pushen und den Pull Request von `seinname:branch` nach `biologist79:main` öffnen. Ruft er `gh pr create` in einem Klon ohne Fork auf, bietet `gh` das Forken selbst an — man muss die Nachfrage nur bejahen statt sie wegzudrücken.

---

<div class="post-metadata">

**Author:** ![albert0815](https://forum.espuino.de/user_avatar/forum.espuino.de/albert0815/32/1624_2.png) [@albert0815](https://forum.espuino.de/u/albert0815)\
**Post date:** [30. September 2026 um 07:11 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/14 "2026-09-30T07:11:00Z")

</div>

Hi Torsten,

> dein Repo forken, den Branch in **seinen** Fork pushen und den Pull Request von `seinname:branch` nach `biologist79:main` öffnen.

das ist denke ich das, was ich versucht habe:

 ![image](https://forum.espuino.de/uploads/default/original/2X/8/884039ebe4edf430423b267d0d84ae8ad372d1b9.png)

„Mein“ Claude sagt:

> Seit Februar 2026 kann man auf GitHub die PR-Erstellung auf Collaborators beschränken, unter _Settings → General → Features → Pull requests → „Collaborators only"_. Dann lehnt GitHub jeden PR von jemandem ohne Schreibrechte ab, auch aus einem korrekten Fork.

Naja, wie dem auch sei, vielleicht magst Du zunächst mal einen Blick auf meinen Fork werfen, ist vielleicht einfacher 🙂 .

> <https://github.com/albert0815/ESPuino-Mediahub/pull/5>
>
> \## Was der PR macht
> 
> Neben Audiodateien und Webradio kann eine Karte jetzt einen… \*\*Podcast\*\* tragen: Feed-Adresse einfügen — dieselbe, die eine Podcast-App abonnieren würde — und entweder „immer die neueste Folge(n)“ oder feste Folgen wählen.
> 
> \*\*Der ESPuino lernt nichts Neues.\*\* Der Hub löst die Auswahl auf, lädt die Folgen in seinen eigenen Cache unter \`\<data\>/podcasts/\` und liefert ein \*\*ganz normales Datei-Manifest\*\* — gleiche Felder, gleiche \`size\`/\`sha256\`, nur eine andere \`filesBaseUrl\` (\`/podcast-media/\` statt \`/media/\`). Kein neues Manifest-Feld, kein neuer playMode, \*\*keine Firmware-Änderung\*\*, und die Karte spielt offline von der SD wie jede andere Zuweisung (Konzept §7.3).
> 
> \## Zuweisen
> 
> \- \*\*Feed laden\*\*, dann Modus wählen. Die Folgenliste ist in beiden Modi sichtbar, jeweils mit Datum, Dauer und — sofern der Feed sie angibt — \*\*Größe\*\*.
> \- \*\*„Immer die neueste“:\*\* Die Folgen, die die Karte gerade abdeckt, sind markiert, der Rest ist ausgegraut; das Zahlenfeld markiert live um. Ein Klick auf eine Folge wechselt zu einer festen Auswahl mit genau dieser Folge.
> \- \*\*„Bestimmte Folgen“:\*\* Auswahl per Checkbox, höchstens 20 pro Karte.
> \- \*\*Mehrere ESPuinos:\*\* Podcasts nutzen die Geräteauswahl des Formulars wie jeder andere Inhalt. Jedes Gerät bekommt eine eigene Zuweisung, die Folgen liegen auf dem Hub trotzdem nur einmal.
> 
> \## Wie es läuft
> 
> Auflösen und Herunterladen passieren in einem Hintergrund-Worker, nie im Request und \*\*niemals\*\* im Manifest-Request: genau ein Worker pro Container, per \`flock\` auf \`DATA\_DIR/podcast-sync.lock\` gewählt. Eine Karte, deren Folgen noch nicht im Cache liegen, antwortet \`preparing\` statt mit einem leeren Manifest; der Fortschritt steht in der Kartenliste. „Neueste“-Karten werden in einem einstellbaren Intervall oder per „Folgen prüfen“ nachgesehen; eine neue Folge greift — wie jede Inhaltsänderung — beim nächsten Auflegen.
> 
> \## Housekeeping
> 
> Folgen werden zwischen Karten geteilt und \*\*automatisch\*\* aufgeräumt — nach jedem Sync, bei jedem Karten-/Geräte-Löschen und stündlich als Netz. Zwei Bremsen gegen Vollaufen, beide \*vor\* dem ersten geschriebenen Byte: 512 MB Platzreserve auf dem Daten-Volume und ein Cache-Limit (Einstellungen, Default 4 GB). Greift eine davon, werden \*\*keine neuen\*\* Folgen geladen und nichts gelöscht; die betroffene Karte sagt, was los ist. Direkt beim Limit zeigen die Einstellungen Belegung, Zahl der Folgen, freien Platz und den letzten Aufräumlauf.
> 
> \## Neue Dateien
> 
> | Datei | Zweck |
> | --- | --- |
> | \`podcast\_feed.py\` | RSS-Feed lesen — stdlib-only (\`xml.etree\`), größenbegrenzt |
> | \`podcast\_cache.py\` | Cache unter \`\<data\>/podcasts/\`, Download über \`.tmp\` → SHA → rename, Platz-/Limit-Prüfung, Aufräumen |
> | \`podcast\_sync.py\` | Hintergrund-Worker, Zustände pending/syncing/ready/error |
> | \`ttl\_cache.py\` | kleiner In-Process-TTL-Cache |
> | \`static/js/podcast-picker.js\` | Feed laden, Folgen wählen (vanilla JS, kein CDN) |
> | \`static/js/podcast-status.js\` | Live-Sync-Status in der Kartenliste |
> 
> \*\*Keine neuen Abhängigkeiten\*\* — \`requirements.txt\` ist unverändert.
> 
> \## Hinweis
> 
> \`store.py\` schützt \`db.json\` bisher nur mit einem \`threading.Lock\`, also nicht zwischen den beiden gunicorn-Workern. Der Podcast-Worker schreibt aus einem Prozess regelmäßig Fortschritt, während der andere Requests bedient — ohne prozessübergreifende Sperre kann dabei eine Änderung verloren gehen. albert0815/ESPuino-Mediahub#1 behebt das (und den gelegentlichen Absturz beim Start) und sollte vorher gemergt werden.
> 
> \## Getestet
> 
> Gunicorn mit zwei Workern gegen lokale Testfeeds: Zuweisung → Sync → Manifest mit korrekten \`size\`/\`sha256\`, feste Auswahl, Aufräumen nach Auswahländerung, Fehlerpfade (unerreichbarer Feed, \`ftp://\`-Payload, unbrauchbare \`length\`-Angaben). Zuweisung auf zwei ESPuinos: beide synchron, identische Manifeste, eine gemeinsame Kopie im Cache. Picker im Browser (Playwright): Vorschau und Markierung, Einzeltitel-Modus, Klick auf eine Folge, Speichern und Wiederöffnen. DE/FR-Katalog vollständig.
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)
> 
> https://claude.ai/code/session\_01VwsWEf9cyzHocQyvoSBzrT

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [30. September 2026 um 07:19 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/15 "2026-09-30T07:19:11Z")

</div>

Das sind die aktuellen Einstellungen im Mediahub-Repo

 ![Einstellungen Mediahub-Repo](https://forum.espuino.de/uploads/default/original/2X/9/99ac48dc74ec726dbd19f28e9f20d932dab4f7ed.png)

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [30. September 2026 um 15:00 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/16 "2026-09-30T15:00:16Z")

</div>

> [@albert0815](#):
>
> „Mein“ Claude sagt:

Übrigens sagt „mein“ Claude, dass „deiner“ lügt und es sowas nicht gibt 😆.  
Ich habe den PR mal angelegt/übernommen in mein Repo.

---

<div class="post-metadata">

**Author:** ![Jonas1](https://forum.espuino.de/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@Jonas1](https://forum.espuino.de/u/Jonas1)\
**Post date:** [15. Oktober 2026 um 19:33 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/17 "2026-10-15T19:33:19Z")

</div>

Hi,

ich teste mich aktuell langsam durch den Mediahub.

Kann es sein, dass man für die Einstellung „zufälliger Unterordner, Titel sortiert“ keinen Ordner in der obersten Hierarchieebene auswählen kann, oder bin ich nur zu blöd. Der Mediahub scheint eine Audiosdatei zu erwarten, bekommt aber natürlich keine geboten, weil im ersten Ordner ja nur die Unterordner drin sind.

Außerdem habe ich immer wieder mit verschiedenen Boxen das Problem das eine Karte als neu erkannt wird (rote LEDs) aber kein Request an den Mediahub rausgeht. Das passiert sowohl bei ganz neuen Karten als auch bei denen, für die schon eine Info im Mediahub liegt. Lösen lässt sich das Problem meist nur durch einen (teils mehrfachen) Neustart der Box. Es wirkt fast so, als ob die Box „vergisst“ dass sie ja jetzt mit dem Mediahub sprechen soll und nicht auf sich alleine gestellt ist.

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [15. Oktober 2026 um 20:58 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/18 "2026-10-15T20:58:50Z")

</div>

1. Ich habe mal eine neue Version (Mediahub und ESPuino) hochgeladen. Bitte mal testen.
2. Ist ein Mediahub nicht erreichbar, dann merkt sich ESPuino das und kontaktiert diesen bis zum Neustart nicht mehr. Das soll verhindern, dass es. ständig nervige Timeouts gibt und man warten muss, bis der Abspielvorgang startet. Was steht denn in den Logs?

---

<div class="post-metadata">

**Author:** ![Jonas1](https://forum.espuino.de/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@Jonas1](https://forum.espuino.de/u/Jonas1)\
**Post date:** [16. Oktober 2026 um 08:47 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/19 "2026-10-16T08:47:00Z")

</div>

1. Funktioniert jetzt, vielen Dank!
2. Funktioniert jetzt natürlich…wenn der Bug wieder auftaucht werde ich mal das Log vom Espuino auslesen. Wahrscheinlich liegt das an der von dir genannten Funktion. Könnte man das Verhalten vielleicht so abwandeln, dass er z.B. bei jeder neuen RFID-Karte einmal zu kontaktieren versucht oder 3 Versuche macht oder nach einer Wartezeit erneut probiert?

Gibt es die Möglichkeit eine integrierte Updatefunktion wie bei den Espuinos zu implemetieren?

Ich finde das Projekt wirklich super hilfreich, spätestens bei der zweiten Box. Bisher ist das aber ja wirklich nur was für erfahrene User. Ich gebe offen zu, dass ich das ohne Anfängeranleitung von Claude niemals gewagt hätte. Wäre eine einsteigerfreundliche Version z.B. auf Basis eines Rasperry-Pi mit einem Containerimage realistisch?

---

<div class="post-metadata">

**Author:** ![biologist](https://forum.espuino.de/user_avatar/forum.espuino.de/biologist/32/66_2.png) [@biologist](https://forum.espuino.de/u/biologist)\
**Post date:** [16. Oktober 2026 um 13:36 UTC](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779/20 "2026-10-16T13:36:37Z")

</div>

> [@Jonas1](#):
>
> 1. wenn der Bug wieder auftaucht

Erstmal schauen, ob das überhaupt ein Bug ist 🙂

> [@Jonas1](#):
>
> 1. Könnte man das Verhalten vielleicht so abwandeln, dass er z.B. bei jeder neuen RFID-Karte einmal zu kontaktieren versucht oder 3 Versuche macht oder nach einer Wartezeit erneut probiert?

Man könnte das konfigurierbar machen. Man muss aber immer im Hinterkopf behalten: Wird meiner Frau oder meinem Kind klar sein, warum der ESPuino sich ggf. 2s gönnt, ehe was passiert? Das ist halt der Grund, deswegen ich das minimalinvasiv vorgegeben habe.

> [@Jonas1](#):
>
> Gibt es die Möglichkeit eine integrierte Updatefunktion wie bei den Espuinos zu implemetieren?

Das ist viel zu aufwändig und macht keinen Sinn (ohne das jetzt weit auszuführen). Was man aber machen könnte: Aktuell muss man mittels `--build` das Image ja selbst bauen (aus dem Dockerfile). Dieses Image könnte ich auch von Github bauen lassen und veröffentlichen, so dass man nur noch aktualisieren und nicht mehr bauen muss. Das kann insofern ein Vorteil sein, weil die üblichen NAS-Verdächtigen wie Synology und QNAP haben ja Web-Oberflächen, über die man auch Container anlegen kann. Trägt man dort ein Compose-File ein, so kann man einen Container starten. Und ich nehme an, dass man ihn dort auch per Knopfdruck aktualisieren kann. Ansonsten können diejenigen, die ein solches Webinterface nicht haben, über sowas jedoch gerne Container administrieren möchten, sich mal [portainer](https://homeserverlab.de/blog/portainer-grundlagen-fuer-docker-einsteiger/) anschauen.

> [@Jonas1](#):
>
> Ich finde das Projekt wirklich super hilfreich, spätestens bei der zweiten Box. Bisher ist das aber ja wirklich nur was für erfahrene User. Ich gebe offen zu, dass ich das ohne Anfängeranleitung von Claude niemals gewagt hätte.

Also ich kann dazu nochmal ein Tutorial schreiben, welches vielleicht für Anfänger besser verständlich ist. Aber man muss dann schon auch willig sein, sich ein wenig mit Linux zu befassen und sich Dinge anzueignen. Also ich würde es mal Hilfe zu Selbsthilfe nennen.

[Nächste Seite](https://forum.espuino.de/t/espuino-mediahub-feature-requests/4779.md?page=2)
