Beiträge von dlueth

    ich meine diesen einen Befehl

    sh -c "$(curl -s -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/dlueth/easyepg.minimal/master/init)"

    Dann nur noch

    docker start easyepg.admin
    docker exec -ti -u easyepg -w /easyepg easyepg.admin /bin/bash ./epg.sh

    Und man war in denn Einstellungen.
    Jetzt, bei dem neuem geht es natürlich alles über Webinterface. Es wäre halt perfekt, wenn man die alpha auch mit nur einem befehl aufsetzen könnte.

    So, der Branch in meinem Repo heißt jetzt "lite-scratch" (und nicht mehr "alpha"), ebenso das Tag dazu im docker hub. GitHub Workflow läuft wie gewohnt jede Nacht und erstellt und pushed ein aktuelles Image. Es gibt dafür dann auch wieder ein init-script mit allen Optionen. Vielleicht magst Du @Kampfader das auch nochmal gegentesten. Bei mir lief es so weit ;)

    @easy4me Du weißt ja schon, dass ich gerne docker container bau, möglichst klein und minimal. Nachdem das beim "neuen" easyepg ziemlich gut hingehauen hat versuche ich mich gerade an der telerising-api und scheitere ;)

    Die Basis scheint, wie auch beim neuen easyepg, Python zu sein? Du stellst (aus Gründen die bei GitHub nachlesbar sind) nur dynamische Binaries bereit, Du hast also valide Gründe dafür die ich ausdrücklich respektiere. Was ich bisher geschafft habe ist, aus Deinen dynamischen Binaries statische zu erzeugen die sich auf ein scratch docker-image (also ein komplett nacktes Linux) kopieren und ausführen lassen.

    Die GUI ist dann auch erreichbar, zeigt aber nach dem Login auf der folgenden Seite "Your setup" die Fehlermeldung "Connection error: Please check your internet connection.". Die exceptions.txt innerhalb des Containers bleibt aber leer. Hast Du eine Idee woran das liegen könnte?

    Ich vermute irgendetwas fehlt. Nehme ich statt scratch alpine bleibt auch dort das Problem bestehen.

    Vielleicht, ganz vermessene Frage, wäre es ja sogar möglich, dass Du neben den bisherigen Binaries auch statische für amd64, arm32/v7 und arm64 zur Verfügung stellen könntest? Beim neuen easyepg mache ich das bereits selber und das klappt sehr gut und schnell, könnte dabei also auch helfen ggf.


    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.

    Stimme in beiden Punkten zu ;)

    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

    Was ich richtig gut bei der master finde ist, das man die per eine zeile aufsetzen kann.

    Das fehlt leider bei alpha version.

    Was genau meinst Du damit?

    Im Moment würde ich persönlich master erstmal unverändert weiter laufen lassen, da das neue easyepg ja noch poc/wip Status hat. Ich hab alpha bei mir selber jetzt schon ein paar Tage sauber am Laufen. Was ich nicht sicher weiß ist ob bei allen Leuten und unter allen Systemen die meine beta einsetzen auch die alpha verwendet werden könnte aufgrund der verwendeten Volumes (tzdata & localtime) und des "--user".

    Ich könnte nun das neue easyEPG als PC Version nutzen

    Was genau meinst Du damit? Also ja, das ist ein Python-Script und das kannst Du sowohl als Kodi-Addon als auch standalone laufen lassen, ganz grundsätzlich gesprochen.

    Was das neue easyepg angeht müsstest Du in Deinem Fall dann (ohne docker) das angelegte xml dorthin kopieren wo es von TVHeadend erwartet wird oder Du könntest es auch selber auf den xmltv.sock kopieren. Das ginge mit einem package namens "socat" beispielhaft so (z.B. als cronjob):

    Code
    cat easyepg.xml | socat - UNIX-CONNECT:/home/hts/.hts/tvheadend/epggrab/xmltv.sock

    Pfade etc müssten natürlich noch angepasst werden.

    Ich habe einen TV Server auf dem ich TVHeadend laufen habe. Hier brauche ich natürlich EPG Daten. Auf diesem TV Server lasse ich auch Kodi laufen. Ich nutze diesen PC jedoch nicht als Abspielgerät. Ich habe Kodi auf diesem PC nur installiert, um einige Addons von Kodi nutzen zu können (unter Anderem Takealug EPG Grabber). Aktuell liest Takealug EPG Grabber den EPG ein und schreibt dann den EPG nach TVHeadend. Somit steht das EPG allen CLients zur Verfügung. Wenn ich nun dieses neue easyEPG nutze, wäre es dann besser, die PC Version oder die Version als Kodi Addon zu nutzen auf diesem TV Server?

    ähnliche Konstellation bei mir: kleiner Rechner stellt tvheadend, dafür telerising (Zattoo) und easyepg bereit. Alles jeweils als docker Container... Läuft wunderbar. KODi brauchste da dann nicht mehr. Im Docker läuft, was easyepg betrifft, im Prinzip auch nur das KODi addon, aber halt standalone.

    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

    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.

    @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:

    @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 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?