đź“— ESPuino Mediahub

Ursprung

Dieses Thema wurde hier im Forum schon ausgiebig diskutiert: Cloud-Anbindung. Aufgrund der Komplexität jedoch nie in der Form umgesetzt, wie es (aus meiner Sicht) für ESPuino Sinn macht. Das habe ich nun übernommen.

Git-Repository:

Mediahub: ESPuino-Mediahub
Konzept: ESPuino-Mediahub/docs/mediahub-konzept.md at 69822ceeca88543fd3ca2bcf49f76c240fe87cce · biologist79/ESPuino-Mediahub · GitHub

Dokumentation

Findet sich jetzt hier: 11 · MediaHub - ESPuino-Handbuch.

Hi,

Ich habe zwar wenig Ahnung aber viel Interesse und Bastlermotivation.

Bei uns steht dem nächst ESPuino Nr. 2 auf der Liste und das Karten inkl. Inhalt verwalten ist mir persönlich etwas lästig.

Ich habe mir die Tage mal die vorhandenen Repositories geladen und ein wenig rumgespielt.

Das ganze hat dann dank Codex eine gewisse Eigendynamik entwickelt.

Meine Änderung lädt jetzt nicht mehr in ein verstecktes Verzeichnis sondern spiegelt den benötigten Inhalt des Hub sichtbar.

Es gibt zusätzlich eine Option in den ESPuino Mediahubeinstellungen, um das zuweisen der Karten als MediaHub Karte auf dem ESPuino überflüssig zu machen.

Gibt es auf dem Hub einen zugewiesen Inhalt wird dieser synchronisiert. Auf dem ESPuino wird die Karte dann so zugewiesen, also ob die Zuweisung manuell erfolgt wäre. Der Abgleich mit dem MediaHub erfolgt dann weiterhin. Bei auf dem Hub nicht zugewiesenen Karten wird die lokale Zuordnung verwendet. Die hinterlegten Hubs können im Rang sortiert werden, um beim Autosync den Hub zu definieren, der primär synchronisiert.

Es mag hier und da von deinem ursprĂĽnglichen Gedanken abweichen, aber fĂĽr mich war es so komfortabler.

Aktuelle arbeite ich komplett lokal und es gibt keinen Fork oder der gleichen. Sollte also Interesse am Code bestehen mĂĽsste ich den Zugriff noch organisieren.

wie gesagt hab ich selber wenig Ahnung von den Sprachen und kann nicht jede Codezeile verifizieren. Ich habe aber versucht drauf zu achten, dass keine unnötigen Änderungen in anderen Modulen erfolgt sind.

Falls garnicht gewünscht gehe auch gerne wieder zurück auf Los und teste nur die bestehenden Codezeilen, wenn es die Zeit ermöglicht. :slight_smile:

Beste GrĂĽĂźe

Genau das will ich extra so nicht haben, weil sonst User anfangen, da drin ggf. Kram zu löschen bzw. zu verschieben und am Ende stimmt das vorne und hinten nicht mehr. Es ergibt sich daraus einfach zu viel zusätzliche Komplexität. Die Komplexität ist so schon sau hoch.

In wiefern? Du musst doch die Karten-ID auf den Mediahub kriegen. Ich lerne die auf dem ESPuino als Mediahub-Typ an und dann wird das auf den Mediahub gepusht. Und andere Kartentypen halt nicht. Und du könntest auch mit mehreren Mediahubs arbeiten. Ich will nicht mit einem zweiten Kartenleser am Mediahub anfangen.

Das ist mir ehrlich gesagt zu kompliziert.

Mir ist bewusst, dass es da verschiedene Möglichkeiten gibt, das Ganze anzugehen. Ich sag’s nur ganz ehrlich: Ich habe nicht vor, das hier mit unendlich vielen Optionen ausufern zu lassen. Wer das anders möchte, der forkt sich das einfach, wie du das jetzt gemacht hat - dafür machen wir das ja mit Open Source :slight_smile:.

Du kannst das für dich ja gerne nutzen, wie du das magst/brauchst - das ist ja völlig in Ordnung. Und du kannst natürlich auch gerne deinen Code publizieren und es anderen Usern zur Verfügung stellen. Aber ich sage direkt, dass ich hier nicht verschiedene Mechanismen umsetzen mag. Weil das testet am End wieder niemand und dann muss ich mich final wieder hinsetzen. Und aus den bisherigen Diskussionen zu dem Thema hat sich ergeben, dass mehrere Leute unterschiedliche Vorstellungen hatten - im Endeffekt hat es zu keinem Ergebnis geführt. Insofern nehme ich mir jetzt raus, die grobe Architektur vorzugeben. Wer das so nicht möchte, der forkt das halt.

Leider habe ich das Projekt mangels Zeit und dann wegen Urlaub nicht fertig abschließen können. Also grundsätzlich laufen tut es schon, es ist aber noch nicht fertig getestet. Mal schauen, wann ich mich wieder dazu aufraffen kann.

Ich muss gestehen die Gefahr sehe ich nur bedingt. Wer den ESPUino verwaltet, verwaltet auch den MediaHub. Warum sollte die Person plötzlich auf dem ESPuino anfangen die Daten hin und her zu schieben, genau weil sie das nicht will, kommt ja der MediaHub ins Spiel, oder verstehe ich die Motivation der Leute falsch?

Da ich prinzipiell aber ein fauler Mensch bin, habe ich keine Lust eine Karte zweimal zuzuweisen.
Einmal im ESPuino und dann nochmal im MediaHub, ist mir einmal zu viel :wink:
Daher der Gedanke eines Autosyncs.
Im AutoSync wird jede Karte direkt an den Hub gepusht. Karten ohne Match behalten ihre lokale Zuordnung, Karten mit Match werden ĂĽberschrieben.
Das spammt den Hub zwar zu, allerdings könnte man das mit einem Filter oder einer separaten Zuweisung im Hub, als bspw. ignore lösen.
Und da ich gedanklich dabei war den Inhalt evtl noch anderen Karten zuzuweisen oder sie zu kombinieren, wurden die Dateien eben nicht mehr versteckt. Prinzipiell sollte es auch mit versteckten Dateien gehen. Im Zweifelsfall sehe ich aber gerne welche Inhalte auf meiner Karte sind.

Ich behaupte so weit sind die Ansätze garnicht auseinander, ich bin nur fauler und mag Transparentz auf meiner SD-Karte :wink:

Das Angebot den Basis-Code zu testen erneuere ich nochmal. Die Tests sind in dem Zuge leider etwas ausgeufert und für deinen Code nicht mehr repräsentativ.

So, mein Gemotze von gestern habe ich wieder gelöscht - zweiter Versuch. Sorry an der Stelle.

Unwissen und/oder Sorglosigkeit. Also von mir aus bauen wir einen Schalter ein, der es ermöglicht, den Ordner anzuzeigen. Aber mir ist eigentlich jetzt schon klar, dass das früher oder später zu Problemen führen wird. Die Ordnerstruktur ist auch eh nicht so wirklich prädestiniert von Menschen manuell benutzt zu werden, weil an oberster Stelle die Karten-ID steht.

Das bringt aus meiner Sicht nur unnötige Komplexität in’s System. Mit einem Mediaserver geht das ja noch, aber mit zweien kannst die dann nacheinander abfragen. Da kommen Timeouts in’s Spiel, die der Nächste dann konfigurierbar haben will. Und ggf auch, ob das seriell oder parallel abgefragt wird. Es wird einfach wieder ausarten.
Es fällt einem kein Zacken aus der Krone, wenn man das auf dem ESPuino anlernen muss: Der Kartentyp bleibt im Webfrontend bestehen wenn man mehrere Karten anlernt - insofern braucht man nach jedem Auflegen nur auf Absenden klicken. Dafür hat man eine eindeutige Zuweisung, wo es kein Vertun gibt.

Dieser ganze Komfortkram und dass es jeder sich genau so konfigurieren kann, wie er/sie es gerne hätte, speziell auch die ganze Kombinatorik daraus, zieht einfach immer wieder Analyse- und Test-Aufwand nach sich. Es kommen User und melden Probleme und wenn es dann darum geht, das zu analysieren / fixen / testen, hört man von den Leuten, die das initial eingebaut haben wollten nix mehr oder „sie haben gerade wenig Zeit“ - was übersetzt so viel heißt wie „Nicht mein Problem - guck selbst!“. Mit KI kann ich das zwar inzwischen einfach analysieren und fixen, aber ich habe keine Lust mehr, dass ständig solche Arbeit an mir hängenbleibt. Insofern trete ich da jetzt ein bisschen auf die Bremse. Das muss nicht jedem gefallen, aber dafür gibt’s ja Forks.

Claude hatte noch folgende Tests genannt, wobei ich mitunter (wenn ich ehrlich bin) selbst nicht genau weiĂź, was da im Detail gefordert war:

  • Nested-subfolder / recursive-folder playback after the root-folder fix
  • Restart/shutdown requested while a download is in progress
  • SD full during download/re-sync (old content should stay untouched, error surfaced)
  • Hub unreachable at tap-time (should fall back to local cache or a short error, never hang)
  • Change on the hub → background staleness detection → re-sync on next tap → plays on the tap after that
  • DELETE /rfid cascade for a MediaHub card, including retry behavior after a simulated cleanup failure

https stand auf der Liste auch drauf. Das funktioniert, aber da rate ich von ab, da es zu einem deutlichen Geschwindigkeitsnachteil fĂĽhrt.

Ich bin von Berufswegen kummer gewohnt und kann denke ich sehr gut den sachlichen Inhalt bei solchen Dingen herausfiltern. FĂĽr mich stellt so etwas kein Problem dar.
Vielmehr empfinde ich es bemerkenswert, mit wieviel Herzblut du hinter der ganzen Sache steckst und an vielen Stellen den extra Meter eines anderen Gegangen bist.
Daher ist es fĂĽr mich durchaus nachvolziehbar, dein gutes Recht und auch in unserem Interesse, dass du bestimmte Entscheidungen triffst, die fĂĽr dich richtig sind.
Ich wollte hier eigentlich auch nicht aktiv Änderungen in deinen Code einbringen, sondern eigentlich nur sagen: so hab ich das wahrgenommen und so ist das jetzt bei mir. War alles ein kleinwenig unglücklich ausgedrückt, das ist der Nachteil am Schreiben und Lesen.

Aber kommen wir zum Test.

  • Nested-subfolder / recursive-folder playback after the root-folder fix
  • Die Rekursion funktioniert nach meiner Einschätzung identisch zum lokalen Betrieb
  • Ich bin bisher kein Nutzer der Rekursion, daher weis ich nicht, ob die nachfolgende Beobachtung ein Fehler, oder wirklich so gewollt ist.
    Wenn Die Ordnerbezeichnung eines Subfolders im Alphabet vor der Bezeichnung der enthalten Tracks des Mainfolders ist, wird sich erst durch den Subfolder iteriert, statt die enthaltenen Mediendateien und anschlieĂźend den Subfolder wiederzugeben.
    Auszug aus dem Manifest:
    „path“: „Rekursion/U1/Track03.mp3“,
    „path“: „Rekursion/U1/U2/E3/Track01.mp3“,
    „path“: „Rekursion/U1/U2/Track01.mp3“,
  • Restart/shutdown requested while a download is in progress
  • Beide Requests werden ĂĽber das Webinterface angenommen und umgesetzt, danach muss der Download neu gestartet/fortgesetzt werden
  • Tasten und Drehencoder werden komplett geblockt
  • Ăśber das Webinterface wird jede Aktion bestätigt, aber nur Laut und Leiser auch wirklich umgesetzt, allerdings ohne LED feedback
  • SD full during download/re-sync (old content should stay untouched, error surfaced)
  • Im Log wird die volle SD-Karte angezeigt, es geschieht keine Aktualisierung des Inhalts
  • Der vorhandene lokale Inhalt wird abgespielt
  • Hub unreachable at tap-time (should fall back to local cache or a short error, never hang)
  • Gibt es auf der SD-Karte noch kein Manifest, bzw. keinen Inhalt, wird die Karte wie eine nichtzugewiesene Karte behandelt
  • gibt es ein Manifest, wird dieses abgespielt
  • Change on the hub → background staleness detection → re-sync on next tap → plays on the tap after that
  • Playmode: Pause wenn RFID-Tag entfernt = true:
    die Änderung wird erkannt, mit dem nächsten auflegen der Karte wird der Download gestartet, dazu muss erst nochmal eine andere Karte aufgelegt werden, sonst wird es nur als pause und fortzsetzen erkannt
    Nach dem Download muss die Karte erneut heruntergenommen und neu aufgelegt werden, damit abgespeilt wird (entspricht plays on the tap after that)
  • Playmode Pause wenn RFID-Tag entfernt = false:
    Die Ändeurng wird erkannt, mit dem nächsten auflegen der Karte wird der Download gestartet, der aktuelle Titel läuft dann noch weiter, während der Download startet, stoppt dann aber irgend wann. Nach dem Download erneutes auflegen, um abzuspielen.
  • es werden keine ergänzten Inhalte heruntergeladen, sondern das gesamte Manifest wird erneut geladen
  • DELETE /rfid cascade for a MediaHub card, including retry behavior after a simulated cleanup failure
  • „Secure Delete: Der ESPuino (…) hat das Löschen nicht bestätigt. Die Karte wurde beibehalten, bitte erneut versuchen.“
    Zurodnung und Abspielen bleibt wie gehabt
    Ich wĂĽsste nicht, dass ich auf dem ESPuino machen mĂĽsste.

Beobachtungen:

  • Ist der Playmode Pause wenn RFID-Tag entfernt = true
    wird beim Auflegen einer Karte, die im MediaHub den Status wartend hat, die aktuelle/letzte Wiedergabe fortgesetzt/pausiert/fortgesetzt usw.
    Das zuweisen im MediaHub behebt das Verhalten nicht, erst nachdem eine andere Karte aufgelegt wurde, wird bei erneutem Auflegen der nun zugewiesenen Karte der Download gestartet.
  • Nach dem Zuweisen der Karte im ESPuino Webinterface zum Abspielmodus MediHub, muss diese erneut aufgelegt werden, um sie an den MediaHub zu pushen. (Erwähnt ich bereits, dass ich faul bin? :wink:)

Ich hoffe ich habe nichts vergessen und du wirst aus dem geschriebenen schlau.

Ich habe mir auch den Mediahub nun aufgesetzt, aber er findet den Espuino nicht und ich finde nicht wo ich die Mediahub IP im Espuino eintragen kann… Wo finde ich die denn?

Das ist aktuell noch nicht in dev oder master angecheckt. Wenn du das testen willst, dann musst du entweder den PR-Branch kompilieren oder die nachfolgende Firmware verwenden:

– Link entfernt —

Achtung, diese ist nur für die Complete. Werde die Datei in Kürze hier auch wieder löschen.

So, ich habe eben den Mediahub in dev gemergt. Die Doku oben habe ich eingefĂĽgt.

Ich habe den MediaHub heute mal mit unserem ESPuino testen können und bin begeistert. Für uns erleichtert das die Verwaltung ganz erheblich, selbst mit nur einem Gerät. Es ist einfach deutlich komfortabler, als die Dateien händisch auf die SD-Karte zu bekommen (sei es per FTP oder per Browser-Upload oder manuell). Mal wieder einen herzlichen Dank an dieser Stelle!

Mit dem bisherigen Funktionsumfang sind wir so auch weitestgehend zufrieden. Einzig die auch von harle umgesetzte Idee des Senden unbekannter Tag-IDs an den/die MediaHub(s) würde das anlernen neuer Tags vereinfachen, da man nicht in zwei unterschiedlichen Verwaltungsoberflächen herumspringen muss. Hilft sicherlich auch sehr, wenn man mehrere ESPuinos hat und die Tags im MediaHub dann klont. Aber ansonsten: Klasse!

Wir hatten das Thema nochmal „nebenan“: ESPuino Mediahub - Feature Requests und es ist in der Umsetzung.

So, ich habe das jetzt umgesetzt: Merge branch 'feature-mediahub-unknown-card' into dev · biologist79/ESPuino@2b653de · GitHub

@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 nachgeladen. Aber z.B. irgendwelche Dateien zusätzlich reinkopieren, die der Mediahub nicht kennt, ist eine schlechte Idee!

b) Man kann nun in der Mediahub-Kladde per Option aktivieren, dass alle Requests sofort (ohne Anlernen) pauschal an die Mediahubs geschickt werden. Das wird einfach gemäß fire and forget gemacht. D.h. der ESPuino kennt die Karte nicht und solange der Mediahub nicht mit einem Manifest antwortet, ist die Karte immer wieder für ESPuino unbekannt und er stellt die Anfrage immer wieder. Kommt jedoch ein Manifest zurück, dann lernt ESPuino implizit (im Hintergrund) die Karte als Typ Mediahub an und startet den Download. Der Vorteil ggü. sofortigem Anlernen ist, dass es keine Karteileichen auf dem ESPuino gibt für Karten, die der Mediahub nie beantwortet hat.
Mediahubs, die nicht erreichbar sind, werden bis zum Neustart nicht mehr befragt,

Vorteile: Man spart sich einen Karten-Auflegevorgang bei ESPuino A. Lernt man auf dem Mediahub gleich mehrere ESPuinos an, so spart man sich auf allen weiteren ESPuinos sogar zwei Karten-Auflegevorgänge - der Download startet dann direkt beim ersten Auflegen.
Nachteile: Will man eine Karte lokal nur anlernen und tut das auch, dann entstehen Leichen auf dem Mediahub. Weiterhin: Legt man mehrere unbekannte Karten nacheinander auf und fĂĽhrt keine sofortige Zuweisung auf dem Mediahub durch, dann wird man schnell den Ăśberblick verlieren, was welche Karte ist.

c) In der Liste der Kartenzuweisungen im ESPuino-Webinterface standen bei Mediahub bisher keine Details. Das ist nun anders, da das auf Dauer unübersichtlich wird. Es werden nun auch Details angezeigt. Allerdings müssen dafür pro Karte Lookups in die Manifest-Dateien der Karten gemacht werden. Man muss mal schauen, ob das in der Form skaliert, wenn man viele Mediahub-Karten zugewiesen hat. Also es ist nicht ausgeschlossen, dass wenn ein Abspielvorgang läuft, das Anzeigen diese Liste zu „abgehackter“ Wiedergabe führt.

Der Mediahub muss jetzt noch von mir angepasst werden.

Habe es eben ausprobieren können und es funktioniert ganz wunderbar. Vielen Dank! :slight_smile:

Ui, das ging ja fix.

So, die Anpassungen am Mediahub sind auch online. Drei Dinge:

a) Man kann in den allg. Einstellungen des Mediahubs festlegen, ob per Default beim Anlernen alle ESPuinos angehakt sein sollen:

b) Beim Anlernen einer Karte kann man nun mehrere ESPuinos angeben. Und genau hier wirkt sich (a) aus: Ist es aktiv, dann werden immer alle per Default angehakt. NatĂĽrlich kann man den Haken da manuell wegnehmen.

c) Neue Karten erscheinen im Webfrontend jetzt automatisch, da der Client am Mediahub im Hintergrund pollt. Zuvor musste man manuell die Seite aktualisieren.

Zum Test der neuen Mediahub-Version:
git pull
docker compose up -d --build

Moin,

ich habe gestern den MediaHub entdeckt und bin begeistert. Ein Punkt ist mir aufgefallen als ich eine größere Playlist von 150 MB geändert habe.

Der erste Download dauert natĂĽrlich recht lange, was auch ok ist. Wenn ich auf dem MediaHub allerdings eine Datei hinzufĂĽge oder rausnehme, wird ALLES erneut heruntergeladen.

Da das alte Manifest noch vorhanden ist, wäre es dann nicht möglich das alte und neue Manifest abzugleichen? Die Dateien, die sich nach Hashwert nicht geändert haben, kann man lokal aus dem alten Ordner kopieren und den Rest runterladen (falls noch was fehlt). Sonst dauert ein re-sync mit großen Playlists ewig wenn man nur Kleinigkeiten geändert hat.

Ich habe das mit dem inkrementellen Re-Sync jetzt mal erweitert.
DafĂĽr ist es notwendig, die ESPuino-Firmware aus dev neu zu flashen und zudem den Mediahub zu aktualisieren.

An der Stelle weise ich auf eine Sache hin: Wenn man an einem bestehenden Hörspiel etwas ändert, d.h. irgendwelche Titel löscht oder neue hinzufügt, dann kann es sein, dass der zuletzt gespeicherte Abspielpunkt nicht mehr dorthin zeigt, wo man es erwartet. Das kann man auch nicht beheben.

Erstmal besten Dank fĂĽrs Aufnehmen und Umsetzten. Bei uns war die letzten Wochen der Nachwuchs zentraler Tagesinhalt.
Langsam entwickelt sich wieder etwas, was einem Rhythmus gleich kommt, mal schauen wann ich die nächsten Tage zum Testen komme.
Melde mich dann auf jeden Fall mit Feedback.

Danke! Ich habe es eben probiert und es funktioniert gut.

Ist es eigentlich Absicht, dass bei Veränderung der Karte ich die Box einmal aus- und wieder einschalten muss damit er das merkt?

Es ist eigentlich irgendwie möglich, dass man im Mediahub die Reihenfolge der Dateien in der Playlist per Drag’n’Drop ändern kann? Oder muss ich die Dateien zwingend umbenennen?

Es ist Absicht, ja. Ich habe mich allerdings auch schon gefragt, ob das wirklich Sinn macht.

Die musst du umbenennen. Das liegt nicht am Mediahub sondern an ESPuino. Dort speichern wir nur einen Pfad oder eine Datei im NVS und dazu eben der Playlist-Mode. Playlists mit mehreren Titeln, mal abgesehen von m3u, ergeben sich einfach nur dadurch, dass sie sich in einem Ordner halt befinden. Das ist auch der Grund, weswegen ich oben geschrieben habe:

Denn wir speichern im NVS einfach nur z. B. ab: Spiele aus Ordner xyz den Titel 6 ab Abspielposition 500. Wie der Titel heißt, weiß ESPuino vom Speichern gar nicht. Wenn du jetzt einen zusätzlichen Titel reinkopierst und sich dieser an Position 1-6 einsortiert, dann wird ESPuino ggf. den falschen Titel abspielen.

Das kann man auch nicht so einfach ändern.

Also die Idee war folgende: Es könnte sein, dass der Mediahub nicht erreichbar ist. Legt man eine Karte auf, die vom Typ Mediahub ist, dann können bis zu 2 Sekunden vergehen, bis der Mediahub-Timeout greift und der Abspielvorgang startet. Dies allerdings (bis zum Neustart) nur einmalig.
Insofern war die Idee: Immer, wenn eine Mediahub-Karte aufgelegt wird, startet der Abspielvorgang und erst danach wird im Hintergrund geprĂĽft, ob es Updates gibt. Gibt es welche, so muss man die Karte erneut auflegen, um diese runterzuladen.

Das Ganze folgt der Strategie „local first“. Man könnte natürlich auch sagen, dass man den Abspielvorgang weiterhin startet und ihn dann stoppt, wenn man Updates erkennt.

Es gibt fĂĽr alles PRO und CONTRA.