HOWTO: Easyepg im Docker unter LibreElec installieren

Bei mir läuft gerade auf einem RPi4 2Gb LibreElec Leia 9.2 Beta 2.
Kann ich die Anleitung im op so übernehmen auch wenn ich nicht TvHeadend benutze? Mir reicht der PVR IPTV Simple Client.
Macht es Sinn von der Power her EasyEPG auf dem RPi4 laufen zu lassen?

So hab mal die installation durchlaufen lassen mit angepasster EPG Quelle. Nur wie kann ich jetzt den Ausgabe der guide.xml anpassen z.B. nach storage/userdata?

Edit: Ok, external_oa.xml gefunden in /storage/easyepg/xml

Startet der cron job jetzt immer automatisch (docker start easyepg.cron hatte ich schon 1x gestartet) z.B. nach einem Neustart?

Durch docker dauert der Neustart auf'm RPi4 um einiges länger (nach den unmounts und reboot initialisieren bleibt er erstmal ne Weile hängen.
Ist das Normal?

Ps: Dickes DANKE @BJ1 für das Tool und an die devs von dem docker Addon!

Kann mir wer helfen eine Lösung zu finden? Mein easyEPG aktualisiert das EPG nicht.
LibreElec v9.1.502 auf'm RPi4, Docker Addon v9.2.0.126 (v18.09.7, API v1.39, Go v.go1.12.6, Git 18.09.7).

Irgendwie scheint docker nicht zu laufen docker ps oder docker -H 0.0.0.0:2375 run hello-world :

docker: Cannot connect to the Docker daemon at tcp://0.0.0.0:2375. Is the docker daemon running?

Manuelles starten mit dockerd https://paste.kodi.tv/ejusatakep.kodi

UPDATE: Sieht so aus als ob docker daemon ab und an nach einem reboot nicht starten möchte. Nach ein paar reboots eben noch einmal docker ps ausgeführt und läuft.

Hier mal mein [definition=12,0]debug[/definition] [definition='1','0']log[/definition]: https://paste.kodi.tv/zupajukode.kodi

Wenn er dann doch scheinbar läuft bekomme ich error's bei bestimmten Befehlen: https://paste.kodi.tv/raw/epeyeyehay

Sollte ich mal easyepg/docker deinstallieren und neu installieren?

Ganz blöde Rückfrage: Der User mit dem Du den Container starten willst ist in der Gruppe docker? @Cris__

Is doch alles root bei LibreElec oder? Hab auch nie bei den user Berechtigungen was verändert.
Hab noch nicht so den Durchblick bei Linux.

So, gibt bei meinem Container nun auch mal wieder eine Änderung:

Da die letzten Monate nun keine Fehler/Probleme mehr gefunden und keine neuen Features mehr meinerseits hinzugekommen sind oder auch von Anderen angefragt wurden betrachte ich den Container mittlerweile als "Feature-Complete". Dies hat sich mindestens die letzten 2 Monate schon dadurch gezeigt, dass ich das Image nur dann neu gebaut und gepublished habe, wenn ich der Meinung war, dass die im Betriebssystem verwendeten Packages mal wieder ein Update bekommen sollten.

Der Prozess des Bauens ist auf meiner lokalen Maschine eine relativ langwierige Sache, da insbesondere das Bauen für andere Architekturen (also die beiden Arm-Varianten) aufgrund der dafür nötigen Emulation sehr sehr lange dauert.

Da das Repo für den Container eh bei GitHub liegt und GitHub mittlerweile mit "GitHub actions" auch direkt in der Lage ist derlei Dinge zu bauen und zur Docker registry zu schieben habe ich die letzten paar Abende dort hinein investiert.

Im Ergebnis bedeutet dies, dass in Zukunft mein Container bei jedem Push auf den Master-Branch automatisch gebaut und in die registry gepublished wird. darüber hinaus wird "GitHub actions" in Zukunft auch einmal die Woche automatisch eine neue Version erzeugen (Startzeit Sonntag, 00:00 Uhr) und bereitstellen, die dann jeweils aktuelle Pakete beinhaltet was das darunter liegende Debian Stretch angeht.

Was bedeutet das jetzt für Euch?

Vermutlich rein gar nichts. Es wird auch weiterhin immer ein mit "latest" getaggtes Image in der registry geben. Wer dies verwendet ist sich entweder eh schon bewusst, dass er ein Update dafür forcieren muss oder er verwendet ein System/Tool was selbständig ein Update macht.

Was sich ändert ist, dass es in Zukunft keine Releases mit Semver-Versionen und zugehörigem Tag in der registry mehr geben wird. Stattdessen werden die Images in Zukunft getagged mit "[Commit hash bei GitHub]-[YYYMMDD]-[HHiiss]" weil sich dies auf einfachste Weise automatisiert erzeugen lässt und auch eine klare Nachvollziehbarkeit und einen klaren Bezug erlaubt.

Was ist der aktuelle Status?

Im Moment gibt es in der Docker registry bereits die Version "qoopido/easyepg.minimal:b5b321cedd9bb2fc89dace96abfecd5124899a81-20191218-132355" (Tag ist also "b5b321cedd9bb2fc89dace96abfecd5124899a81-20191218-132355"). Es wäre schön, wenn den ein paar Leute mal durchtesten könnten bevor ich dazu übergehe auch die über GitHub actions erzeugten Images mit "latest" zu taggen (was im Moment noch nicht der Fall ist). Ich selber habe es (zugegebenermaßen) auch noch nicht praktisch ausprobiert, werde das aber heute Abend nachholen

Wie geht es weiter?
Ich werde vermutlich entweder zwischen den Jahren oder spätestens im Laufe des Januars das Baseimage meiner Container von Debian Stretch Slim auf Debian Buster Slim ändern, da Stretch ab 2020 in den LTS-Modus geht und somit nicht mehr so aktuell mit Patches versorgt werden wird (und auch jetzt gibt es schon einige "Merkwürdigkeiten" an anderen Stellen). Ich erwarte dabei eigentlich keine Probleme, denn ich hatte Buster vorher schonmal erfolgreich getestet. Letztlich hatte ich bisher nicht umgestellt, weil meine Images auf Basis des neuen Debian Buster Slim deutlich größer wurden, ohne erkennbaren Grund. Am Ende darf das aber, hoffentlich verständlicherweise, kein Argument sein um auf einer "alten" Softwarebasis zu bleiben.

Was sich nicht ändert:
Wann immer jemand ein neues Feature haben will oder braucht was irgendwie Sinn ergibt, dann werde ich es implementieren und natürlich auch weiterhin bei Probleme Sachen fixen oder unterstützen...

So gerade nochmal durchgetestet: Bei mir läuft das automatisch erstellte Image völlig problemlos. Sollte es bis morgen keine gegenteilige Rückmeldung von jemand anderem geben aktiviere ich das latest-tagging...

@DeBaschdi sind das schon Debian Paketnamen? Müsste mod242 dann wohl auch reinpacken, oder?

@DeBaschdi Hintergrund der Frage: ich prüfe gerade ob ich auf alpine umschwenke. Die Pakete sind i.d.r. aktueller als Debian/Ubuntu und das baseimage ist auch nochmal schlanker. Magenta läuft schon, aber ein paar Dinge muss ich noch herausfinden...

Hallo zusammen,

easyepg (und telerising) funktionieren sehr gut -> vielen Dank!

Nur ... der cronjob will bei mir nicht. Wenn ich mich mit "docker exec -it easyepg.cron /bin/bash/" eindocke kann ich nicht einfach "nano easyepg.cron" ausführen, denn ich finde auf Anhieb keine easyepg.cron.

Ich sehe aber mit crontab -l:

0 2 * * * su -s /bin/bash -c "TERM=xterm /bin/bash /usr/local/bin/easyepg.process" easyepg > /proc/1/fd/1 2> /proc/1/fd/2

Sieht ja gut aus, es tut sich aber nix. Der Rechner läuft übrigens durch.

docker start easyepg.run ohne cron funktioniert.

docker exec -it easyepg.cron /bin/bash antwortet einfach nur mit "easyepg.cron".

Also, crontab editieren tust Du mit "crontab -e", allerdings wird das keinen restart des Containers überstehen.

Was genau möchtest Du denn tun?
Wie startest Du den Container?

ich möchte einfach nur das epg täglich aktualisieren
Klar, mit crontab -e kann ich editieren, aber das was in der crontab drin steht scheint ja schon gut zu sein, daher habe ich nichts geändert. Trotzdem wird das grabbing nicht (nach Plan) ausgeführt.

Das "nano easyepg.cron" von die oben hat mich ziemlich irritiert... Was sagt denn auf dem Host "docker ps"?

nach jedem Neustart von Libreelec 9.2.1 mit tvheadend 4.2 wird die socket verhunzt, das heißt ich habe im korrekten Verzeichnis nicht eine Datei/Socket xmltv.sock sondern ein directory xmltv.sock.

Dann funktioniert natürlich easyepg nicht mehr.

Wenn ich das directory lösche und entweder tvheadend deaktiviere und wieder aktiviere oder das external grabber modul aus und wieder anschalte wird die socket wieder korrekt aufgebaut und bis zum nächsten Neustart ist alles gut.

Auch wenn ich Libreelec bei deaktiviertem tvheadend neu starte wird das directory xmltv.sock angelegt, d. h. irgend ein Start-Script mischt sich hier ein.

Die Docker können das Problem nicht verursachen, die sind nach einem Neustart inaktiv (docker -ps -> leer).

Hat jemand eine Idee woran das liegen könnte?

Update: ich habe mein System jetzt einfach ohne sock (statt dessen mit tv_grab_file) aufgesetzt, ist ja eigentlich nicht unbedingt ein Nachteil ...

Zitat von dlueth

Das "nano easyepg.cron" von die oben hat mich ziemlich irritiert... Was sagt denn auf dem Host "docker ps"?

"nano easyepg.cron" steht in der Anleitung in diesem thread auf Seite 1, diese Datei gibt es aber bei mir nicht.

crontab -e kann man ausführen, macht aber langfristig keine Sinn weil irgendwann (Neustart wahrscheinlich) wieder das Cron-Pattern aktiviert wird welches man dem easyepg-Script mitgegeben hat.

Fazit: wenn Cron-Timing geändert werden soll -> Script neu starten und dort das korrekte Pattern eingeben.

Zitat von austiiin

nach jedem Neustart von Libreelec 9.2.1 mit tvheadend 4.2 wird die socket verhunzt, das heißt ich habe im korrekten Verzeichnis nicht eine Datei/Socket xmltv.sock sondern ein directory xmltv.sock.

Dann funktioniert natürlich easyepg nicht mehr.

Wenn ich das directory lösche und entweder tvheadend deaktiviere und wieder aktiviere oder das external grabber modul aus und wieder anschalte wird die socket wieder korrekt aufgebaut und bis zum nächsten Neustart ist alles gut.

Auch wenn ich Libreelec bei deaktiviertem tvheadend neu starte wird das directory xmltv.sock angelegt, d. h. irgend ein Start-Script mischt sich hier ein.

Die Docker können das Problem nicht verursachen, die sind nach einem Neustart inaktiv (docker -ps -> leer).

Hat jemand eine Idee woran das liegen könnte?

Update: ich habe mein System jetzt einfach ohne sock (statt dessen mit tv_grab_file) aufgesetzt, ist ja eigentlich nicht unbedingt ein Nachteil ...

Alles anzeigen

Gleiches Problem hab ich bei mir auch...eine Lösung dazu habe ich noch nicht gefunden. easyepg hab ich bereits frisch installiert, aber das hat nicht geholfen. Aber es scheint doch dadurch zu kommen: Zumindest wenn man das Docker Add-on deaktiviert wird auch nicht mehr das Verzeichnis erstellt. Sobald ich ihn wieder enable, ist die socket-Datei wieder verhunzt.

In den perl-Skripten habe ich etwas von touch /xmltv.sock gefunden...das könnte gefährlich sein, aber normalerweise müsste er dann eine Datei erstellen und kein Verzeichnis. Mal schaun...

Ich habe das Gefühl, dass es sich um ein Timing-Problem handelt, nämlich genau dann, wenn das Docker-Addon vor tvheadend gestartet wird. Dann ist die socket-Datei noch nicht erzeugt und die Skripte von easyepg legen - warum auch immer - dieses Directory an. Ich hab eben auch noch mal probiert den Docker-Container erst später zu starten. Sobald man die xmltv.sock direkt vorm Starten von "docker start easyepg.run" löscht, dann wird sofort der nicht gewünschte Ordner erstellt.

Man müsste eigentlich im easyepg prüfen, ob tvheaded schon gestartet ist und erst dann die Skripte (bzw. vermutlich socat) ausführen.