Beiträge von dlueth

Zitat von JackOn

Das Admintool muss ich aber via SSH ausführen. Das bleibt in der DOCKER Oberfläche von Syno im Terminal wohl hängen.
Keine Ahnung warum. Via SSH geht alles.

Ich vermute das die Syno das nicht im interaktiven Modus startet (bzw. starten kann), den brauchst Du aber (logischerweise) um das Setup überhaupt machen zu können. Insofern ergibt das für mich Sinn.

Zitat von JackOn

Müssen die Laufwerke XML_STORAGE und EASYEPG_STORAGE im Docker heissen, oder anders?
An diesen Punkt steig ich nicht wirklich durch.

Das sind nur die Namen der Parameter wie sie an Docker übergeben werden müssen, die Werte müssen absolute Dateisystempfade zu Verzeichnissen auf dem Hostsystem (also Deiner Syno) sein die auch existieren müssen(!). Docker mappt das dann intern um, so das das, was Du außen als EASYEPG_STORAGE definiert hast intern (also innerhalb des Containers) immer unter /easyepg erreichbar ist und das was Du als XML_STORAGE angibst unter /easyepg/xml. Das nennt sich dann bei Docker "Volumes". Wenn Du ein Volume nicht übergibst (oder das Zielverzeichnis nicht existiert, oder die Rechte nicht passen), dann wird Docker das Vermutlich in ein "eigenes" Volume-File packen und persistieren. Heißt: Es würde (wie es bei Dir scheinbar auch geschieht) funktionieren, aber der eigentliche Ordner den Du haben wolltest bleibt halt leer.

XML_STORAGE ist übrigens deswegen optional, weil der Zielordner (innerhalb) /easyepg/xml ja schon Bestandteil des EASYEPG_STORAGE ist. Allerdings ist es wohl bei diversen (NAS)-Konstellationen so, dass es nötig ist XML-STORAGE extra zu setzen auf einen Ordner der in den TVH-Container reingegeben wird.

@JackON

@JackON

Lass uns mal ganz der Reihe nach versuchen uns durch Deinen Stand durchzuarbeiten Also, Du lässt sowohl easyepg als auch TVH auf Deiner Syno als einzelne Docker-Container laufen. Das bedeutet dann (so weit ich das weiß), dass der XMLTV_SOCKET bei Dir nicht benutzt werden kann, da der vom TVH-Docker nicht nach außen freigegeben wird so das man ihn verwenden könnte. Dein Log-Ouput oben sagt mir, dass Du die Verwendung von Socket freigegeben hast - was Du aber nicht brauchst bzw, was bei Dir nicht funktionieren wird.

Das EASYEPG_STORAGE ist das Daten-Verzeichnis, in dem easyepg als "Programm" inkl. seiner Konfiguration abgelegt wird und dient der Persistierung (denn Docker-Container sind ja ansich "flüchtig"). Das solltest Du aber setzen können wie Du willst, es darf nur keine Probleme mit zugriffsrechten geben.

XML_STORAGE ist das, was Du richtig setzen musst. denn dort legt der easyepg-Container am Ende die generierten EPX-XML Dateien ab die Du dann aus dem TVH-Container heraus importieren willst. Letzterer muss das Verzeichnis also auch übergeben bekommen.

Was die TVH-Konfiguration angeht können Dir sicherlich andere hier besser helfen wie das auf ner Syno dann genau funktioniert und was in TVH eingestellt werden muss.

Hm, irgendwie ist das komisch... Ich meine neulich auch mal den Fall gehabt zu haben, dass die Kanalliste bei "Modify Channel List" in den "Grabber Settings" leer war wenn ich das setup über den easyepg.admin container gestartet habe (deswegen hatte ich diesbezüglich bei Euch nochmal nachgehakt). Trotzdem erstellt er bei mir das EPG seit Monaten stabil und völlig korrekt.

Ich hab's jetzt gerade nochmal wie eben beschrieben aufgerufen und die Channel-Liste ist da und vollständig, alle Einstellungen sind da und korrekt.

So, ich hab gerade auch nochmal ein Update auf den Container gemacht, ihn in easyepg.admin gestartet und die Einstellungen kontrolliert: Alles fein

Was bei mir sicherlich ein wenig anders ist als bei Euch:
Ich starte den Container mit einem dedizierten Nutzer, sowohl für das Update des Containers ansich als auch für den normalen EPG-Durchlauf. Ergo dürfte ich eigentlich nie irgendwelche Probleme mit Rechten bekommen.

Könntet Ihr da vielleicht nochmal schauen ob das bei Euch alles passt?

Randnotiz: Ein Update auf easyepg macht der Container übrigens selbständig bei jedem Start des Containers und auch bei jedem Lauf des Cronjobs, sofern Ihr das aktiviert habt.

Grabben tut er, aber die Liste im Menü ist leer? @M4tt0 und @BJ1

Ich mach bei mir die Tage auch nochmal ein Update und prüfe das Mal gegen...

@BJ1 ist das schon länger so oder erst jetzt ganz aktuell? Ich hab bei mir irgendwann letzte Woche Mal ein Update des docker gemacht, benutze auch Magenta, aber es läuft alles.

@Kampfader ja, kannst du genau so schreiben wie du es gepostet hast. Ich meine aber es muss vom host-System unterstützt werden und failed Sonst beim Start. Evtl muss es auch unter die -v Zeilen, weil 2 der Verzeichnisse ja da drin sind

@Kampfader probier dich sonst auch Mal beim docker run folgendes zu ergänzen:

--tmpfs /openhab/userdata/tmp --tmpfs /openhab/userdata/cache --tmpfs /tmp --tmpfs /var/[definition='1','0']log[/definition]

Die Pfadangabe bei den ersten beiden sollte dem Pfad innerhalb des Containers entsprechen, Check also ob die so stimmen...

@Kampfader wenn dein ist das unterstützt kannst du das auch bei docker run mit angeben, Beispiel siehe https://github.com/dlueth/easyepg…6de30/init#L186

Du vergisst dabei neue Versionen der Images, das ist der Denkfehler, zumindest so denn Updates gemacht werden. Klar "wächst" auch der Container, je länger der läuft. Daher habe ich z.b. bei meinem Container wenn er über das init-Script eingerichtet wird /tmp als TMPFS reingegeben, was das Problem bei meinem Container verringern oder eliminieren sollte.

Meiner Erfahrung nach sind es aber - zumindest aus der Sicht eines Entwicklers - in 99% der Fälle eher die Images, die viel Platz wegnehmen.

@Kampfader ich kenne das Problem als Softwareentwickler schon lange. Bei mir tritt es häufiger auf, da ich auch viel mit npm mache. Docker und npm sind beides ziemliche Speicherfresser, npm sicherlich noch deutlich mehr.

Docker hat Lösungen dafür, aber warum sie keinen Automatismus zur Bereinigung einbauen hab ich ehrlich gesagt auch nie verstanden.

Ich tippe darauf, dass dein Problem nicht so sehr die Images der Container sind die Du verwendest sondern die Fragmente von alten Images davon und von deren Baseimages. Die bleiben nämlich liegen seitens docker.

Hattest du vorher Mal "docker images" eingegeben?

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

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?

Möglich... Ich schau trotzdem heute Abend nochmal bei mir Lokal nach ob es bei mir sauber läuft.

Hm, aber wieso wurde dann offensichtlich easyepg upgedatet? @DeBaschdi

@thefan0815 Also, gerade mal nachgechaut, DateTime::Format::Strptime ist und war schon drin - ich schaue mal weiter...

Edit: Build bei GitHub hat auch geklappt und laut den Oogs da ist strptime auch ordentlich installiert. Ich muss Dich auf heute Abend vertösten und schau mal, was bei mir lokal passiert ist in Sachen EPG...

@thefan0815 du hast vermutlich, wie ich auch, easyepg auf Autoupdate stehen und ich vermute, das das eine neue Abhängigkeit hinzugekommen ist. Ich schau mir das gleich Mal an und schieb ein Update hoch...

Zumindest hab ich im Zuge meines Dockers für easyepg schon lernen müssen, dass die ganzen nas-Systeme gerne Mal irgendeine Art caching dazwischen haben wo es auch Mal etwas dauern kann, bis eine Aktualisierung ankommt

Zu den Shell-Befehlen von @DeBaschdi noch der Hinweis, dass der Container natürlich nicht laufen darf wenn ihr Container und Images hart löschen wollt...

@DeBaschdi stimmt, über die Variante hatte ich gar nicht nachgedacht

Wenn's mein docker ist dann geht das so nicht, und auch crontab direkt wird nicht gehen, da die überschrieben wird. Ließe sich aber einbauen