@toab90 das ist wohl ein Kernel-Feature, was allerdings aktiviert werden muss, siehe: https://manpages.ubuntu.com/manpages/bioni…5/procfs.5.html
Ist aber komisch, weil Docker ja gar keinen eigenen Kernel hat?
@toab90 das ist wohl ein Kernel-Feature, was allerdings aktiviert werden muss, siehe: https://manpages.ubuntu.com/manpages/bioni…5/procfs.5.html
Ist aber komisch, weil Docker ja gar keinen eigenen Kernel hat?
Vielleicht kann man ja irgendwie verhindern, dass diese Daten in den Ordner "EASYEPG_STORAGE" geschrieben werden?
"Gepackt" im Docker-Image ist sie ja nur einen Bruchteil so groß.
@toab90 ich muss mir das in Ruhe anschauen, aber was mich irritiert ist, dass normalerweise /proc/**/* immer auf der Rootebene liegt, also nicht in einem Unterordner. Bist Du sicher, dass da nichts mit der Volume-Angabe schief gelaufen ist?
Ja das hat mich auch gewundert.
Ich werde morgen den Container nochmal neu aufzusetzen und dann nochmal berichten
Normalerweise brauche die Dateien im /proc-FS ja gar keinen (zusätzlichen) Platz auf dem Storage - selbst nicht wenn da eine Größe angezeigt wird, die sind nur virtuell da. Trotzdem kann man die Dateien teilweise kopieren, ansehen, etc. Nach dem Kopieren auf ein normales File brauchen die Platz ...
@toab90 ich checke das morgen nochmal bei mir gegen. Kann es theoretisch sein, dass Du dein storage auf / gemapped hast? Weil proc liegt halt da, und nirgendwo anders. Angenommen es wäre so, finde ich es irgendwie komisch, dass das überhaupt funktioniert
@toab90 Also, gerade geschaut. Bei mir gibt es diesen Pfad nicht und auch nichts, was im Ansatz so aussieht iwe das, was Du da bei Dir rumliegen hast. In dem Volume gibt es bei mir nur folgende Inhalte, die allesamt direkt zu Easyepg gehören:
Und wer's noch kleiner mag - und es mit den Parametern nutzen kann auf seinem System:
https://hub.docker.com/r/qoopido/easy…ge=1&name=alpha
9,12MB auf Basis von Scratch. Da Scratch aber ein komplett nacktes Linux ist gibt es kein /bin/bash, kein /bin/sh sondern einzig und allein easyepg das mit pyinstaller (und upx) sowie staticx zu einem statischen Binary kompiliert wurde. Daher müssen dann auch die Standardmechanismen von docker genutzt werden um einen user zu setzen (via --user) sowie timezone und localtime als Volume reinzugeben (läuft also vermutlich dann nur unter Linux und ähnlichen Systemen). Autoupdate geht dementsprechend nicht, dafür läuft der GitHub-Workflow jede Nacht und baut ein neues Image. Die Build-Zeit liegt bei ca. 2 Minuten für dieses Multiarch-Image. Jetzt wüsste ich auch nicht mehr wie es noch kleiner gehen sollte.
README dazu gibt es hier:
https://github.com/dlueth/easyepg…alpha/README.md
Works on my machine XD
@DeBaschdi schau Dir mal auch für deine Images "docker buildx" an. Keine Ahnung wie sie das hinbekommen aber Multiarch-Builds sind damit um ein vielfaches schneller.
Ja, das ist die nächste Baustelle, noch hab ich aber premium bei hub.docker, ich komm auf dich zu
@toab90 ich muss mir das in Ruhe anschauen, aber was mich irritiert ist, dass normalerweise /proc/**/* immer auf der Rootebene liegt, also nicht in einem Unterordner. Bist Du sicher, dass da nichts mit der Volume-Angabe schief gelaufen ist?
Konnte das Verhalten nachstellen. Hatte damals übersehen, dass sich die ENV REPO zwischen deinem und dem Container von DeBaschdi unterscheidet.
Hatte daher ursprünglich REPO=script.service.easyepg-lite i. V. m. deinem Image angegeben. In diesem Falle extrahiert sich scheinbar der ganze Container und die Dateien bleiben solange bestehen, bis man den ganzen Container löscht und unter Angabe der richtigen REPO neu erstellen lässt. Korrigiert man nur den REPO-Parameter, bleiben die Daten auf dem Server vorhanden.
Konnte das Verhalten nachstellen. Hatte damals übersehen, dass sich die ENV REPO zwischen deinem und dem Container von DeBaschdi unterscheidet.Hatte daher ursprünglich REPO=script.service.easyepg-lite i. V. m. deinem Image angegeben. In diesem Falle extrahiert sich scheinbar der ganze Container und die Dateien bleiben solange bestehen, bis man den ganzen Container löscht und unter Angabe der richtigen REPO neu erstellen lässt. Korrigiert man nur den REPO-Parameter, bleiben die Daten auf dem Server vorhanden.
Das ist mal wieder Strange, weil was da passiert ist nur ein simples git clone in ein temporäres Verzeichnis mit dem dann wiederum die "alte Version" überschrieben wird. Das hätte eigentlich einfach fehlschlagen müssen. Echt seltsam. Aber ja, grundsätzlich ist es so, dass Docker Volumes (natürlich) persistent sind.
Ich fand die Änderung aber sinnig irgendwie, denn am Ende nützt es vermutlich niemandem was, wenn man ein anderes Repo unterhalb von "sunsettrack4" angeben kann, man will ja im Normalfall einen Fork im eigenen Namespace verwenden. Oder sehe ich das falsch?
Anyway: Wir haben's ja gefunden XD
danke für die Arbeit, werde ich mal ausprobieren.
@DeBaschdi besteht die Möglichkeit ein docker-compose File bereitzustellen? Finde das cool, wenn man schnell den Container verschieben will
Finde das cool, wenn man schnell den Container verschieben will
Was genau meinst Du damit?
danke für die Arbeit, werde ich mal ausprobieren.
@DeBaschdi besteht die Möglichkeit ein docker-compose File bereitzustellen? Finde das cool, wenn man schnell den Container verschieben will
OK
https://github.com/DeBaschdi/dock…ker-compose.yml
Das kannst/musst du natürlich anpassen.
danke
Ich habe es mal probiert docker und docker-compose auf armbian zu installieren. Das hat schon geklappt.
Jedoch kann ich den Container nicht ausführen:
docker-compose up
Creating network "easyepg_default" with the default driver
Pulling new-easyepg (takealug/new-easyepg:latest)...
latest: Pulling from takealug/new-easyepg
ERROR: no matching manifest for linux/arm64/v8 in the manifest list entries
Aber auf dieser Seite hier gibt es die arm64/v8
Moin Ihr fleißigen Helfer,
auch ich bin hier seit Tagen fleißig am lernen und am ausprobieren und habe auf diesem Weg schon so manches geschafft.
Leider aber komme ich bei diesem Projekt nicht so richtig weiter.
Der Grund ist hier TVHeadend.
Versteht mich richtig. TVHeadend ist mega genial und funktioniert aller best.
Nur; es ist nicht immer (und für jeden) leicht zu durchschauen. Vieles konnte ich einfach (damals) nur durch euch "Helfer" hinbekommen und vor allem verstehen.
Und weil das so ist, dachte ich mir, schrieb ich für diese Dinge Tutorials, sodass jeder JEDEN SCHRITT nachvollziehen- und verstehen konnte.
Leider finde ich so ein Tutorial, welches Schritt für Schritt jeden einzelnen Punkt zeigt, hier im Forum nicht.
Ich würde ihn ja schreiben für UNS NERDS, doch leider weiss ich NOCH nicht wirklich, was ich hier tue.
TVHeadend läuft hier seit Monaten (im Docker), zusammen mit einem von (ich glaube) @don vorgestellten XBOX-USB-Tuner, der sich die EPG-Daten ON-AIR über das Cable besorgt.
Nun aber kommt Ihr hier mit der Telerising-Api, dem Easyepg und dann noch als Docker usw...
Dad janze verwirrt mich völlig und ich sehe mal wieder die Vielen anderen Stillen Leser, die gern auch möchten, aber nicht können, sich nicht trauen oder oder oder...
Ich weiß nur eines:
Was Ihr hier anbietet, ist genial und geil... Ich will das auch gern.
Woran ich hänge ist das automatische Zusammenspiel, der DREI.
D.h. TVHeadend, Telerising-Api sowie NEW-Easyepg.
Alle DREI laufen hier bereits im Docker unter OpenMediaVault und funktionieren auch.
Was ich noch nicht hin bekomme, ist; Das Verständnis, wie TVHeadend sich die fertige EPG.XML holt bzw. benutzt, wo sie liegen muss und wie ich das dann am Ende automatisiere.
Puhh, was braucht Ihr von mir?
Erstmal liebe Grüße,
DR
Dein tvheadend docker bekommt ja von außen ein Volume für seine Daten reingegeben. In diesem Volume findest dann auch einen Ordner data. In eben diesem Ordner erwartet tvheadend die XML epg Daten. Du musst also den absoluten Pfad zu diesem Data Ordner auch als Volume an easyepg übergeben, ich meine im Container ist das Ziel easyepg/xml
@DerRuhige: Prinzipiell kannst Du dir dieses HowTo mal durchlesen, auch wenn das eine oder andere nicht zutrifft: HOWTO: Easyepg im Docker unter LibreElec installieren
Ahh OK,
Du meinst diesen hier im EASYEPG-Docker, richtig?
OK, blöde Frage:
"darf/kann" ich den Ordner am Host/Volume auch auf den eh schon vorhandenen Home-User ".hts" legen.
Also /home/hts/.hts/easyepg/xml
Diesen Cryptischen Path nämlich, mag ich gar nicht.
Hmm, ich mach das einfach mal und schaue was passiert.
Hmm, wie aber weiß TVHeadend, dass die EPG.XML bzw. (umbenannte) GUIDE.XML dort liegt?
Wo genau steht es, wo TVHeadend diese Daten haben möchte, und wie sie aussehen müssen und wie auch die Datei heißen muss?
Hab ich gar im Docker von TVHeadend etwas übersehen?
Ich benutze diesen hier: lscr.io/linuxserver/tvheadend:latest
EDIT: Ich sehe grad, dass der User .hts offensichtlich noch von der VOR_DOCKER_INSTALL herrührt.
Richtiger Config-Path des TVHeadend-Docker, ist somit (bei mir) also dieser hier.
Also /yacht/AppData/Config/TVHeadend
Hier liegen folgende Ordner/Verzeichnisse:
In welches benötigt TVHeadend nun die EPG- bzw. GUIDE.XML?
Sprich, wohin muss ich diese kopieren?
schau mal hier, punkt 5
In der Containerbeschreibung von linuxserver/tvheadend steht unter
EPG XML file
wie mit einer .xml zu verfahren ist.
Die Anmerkung "The xml file has to be named guide.xml." ist falsch, hauptsache name.xml.
Unterm Strich :
Du hast ja irgentwo den tvheadend config pfad auf deiem host herausgeführt. Existiert dort ein unterordner "data" ? Nein ? Dann anlegen.
Und diesen Ordner benutzt du dann um /easyepg/xml darauf heraus zu führen.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!