Beiträge von dlueth

@easy4me kann ich denn trotzdem schon wieder auf den master zurück stellen bei mir? Grund für den Umstieg auf Testing war die Umbenennung von Sendern...

@easy4me Wie ist eigentlich der Status vom TESTING-branch? Ist der mittlerweile in Master überführt?

@Simaryp
Bei mir ist die Konstellation die, dass tvheadend direkt auf dem Host läuft. Dann kann man den Socket direkt reingeben in den easyepg Container, ja

@Simaryp Im Kern tun beide das gleiche und sind sich relativ/sehr ähnlich, da halt easyepg. Meiner ist ungefähr um den Faktor 2,5 kleiner was das Image angeht und dürfte etwas flexibler in der Verwendung sein.

Meinen kannst Du so laufen lassen wie den von mod242, musst Du aber nicht. Bei mir unter Ubuntu z.B. lasse ich den Container nicht die ganze Zeit laufen (und der Cronjob läuft dann innerhalb des Containers), sondern starte den Container selbst via Cronjob vom Host aus und er beendet sich dann nach erfolgreichem Durchlauf.

Das macht zwar vom Ergebnis her keinen Unterschied, ich hab aber auf dem Host auch nicht immer einen Container laufen, der sich zu 99% im Idle befindet.

Was noch hinzukommt, meiner hat mit dem CLI-Script (siehe Readme bei Github) mehr Konfigurationsmöglichkeiten in Bezug auf easyepg update/branch etc.

Zitat von Simaryp

Habe mich für das image entschieden, weil das ganze irgendwann auf nen Server umziehen soll und ich nicht weiß, wie libreELEC spezifisch der Container von dlueth ist.

Meiner ist eigentlich überhaupt nicht libreELEC-spezifisch. Um die Kompatibilität dazu hinzubekommen musste nur einiges angepasst werden und das hat hier einige Beiträge verursacht, daher vermutlich der Eindruck

Ich habe den Container ursprünglich für Debian/Ubuntu entwickelt und nutze ihn auch da derunter. Mittlerweile sollte er aber eigentlich so gut wie überall laufen

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

@easy4me Heute mal geschaut: Ist alles sauber durchgelaufen. Ich musste lediglich (kommend vom vorigen TESTING-stand) nochmal die Channel-Zuordnung ändern, was aber nicht verwunderlich sein dürfte.

@easy4me Asche auf mein Haupt, ich hab vergessen am Montag zu schauen und bin jetzt bis Morgen nicht zu Hause... Hole ich nach sobald ich wieder da bin

Zitat von easy4me

Ich habe nun alle Regeln eingebaut (zunächst für Horizon und Telekom), im TESTING-Branch werden Änderungen bzgl. der Kanalnamen sowie Duplikate berücksichtigt.

Ich benötige nun Tester, die mir bestätigen können, dass alle o.g. Fälle korrekt im Skript geregelt werden.

Ich hab gerade nochmal den TESTING-Branch geupdatet und werde Telekom dann heute Nacht testen. Lief bisher ja aber auch schon gut... Ich geb morgen Rückmeldung.

@Cris__

Also in meiner Crontab steht folgendes

0 2 * * * /usr/bin/docker start easyepg.run > /dev/null 2>&1

Deine Zeile sieht aber grundsätzlich richtig aus.

Wenn die Meldung `Cannot connect to the docker daemon` kommt läuft entweder docker nicht (richtig) oder der aktuelle Benutzer gehört nicht zur docker Gruppe und darf ergo docker nicht benutzen.

Nach dem Neustart dürfte da eigentlich gar kein Container laufen, denn der wird ja nur über den Cronjob zu bestimmten Zeiten überhaupt gestartet und beendet sich dann selbständig wieder. Die Ausgabe von `docker ps` müsste leer sein nach dem Starten des Pi.

@Cris__ siehe hier: https://github.com/dlueth/easyepg…job-on-the-host

Vorher dann ggf. den easyepg.cron mit `docker stop easyepg.cron` stoppen

Achso, und @Cris__ noch etwas: du kannst statt easyepg.cron auch easyepg.run nehmen und den via docker start als cronjob direkt auf deinem Pi starten. Dann läuft der docker nicht permanent im idle...

Zitat von easy4me

@dlueth Ich bin weiterhin dabei, die Regeln bzgl. Kanalnamen-Änderungen und -Duplikate in das Skript einzubauen (zurzeit bei Telekom + Horizon). Für die User sollte weiterhin ausschließlich nur das Basis-Skript (update.sh) als Möglichkeit zur Aktualisierung bestehen bleiben. Da es regelmäßige und ggf. auch fehlerbehaftete Updates im TESTING-Branch geben kann, bin ich eher gegen eine automatische Update-Funktion für Test-User - daher sollte man testing.sh auch nur manuell ausführen können.

Alles klar, ich habe das jetzt (für die, die es benutzen können und wollen) in meinem init-Script dahingehend angepasst, dass sofern bei "easyepg branch" "master" drin steht der default für "autoupdate" "yes" ist, ansonsten "no" und für alle anderen Branches auch gar nicht nach "autoupdate" gefragt wird. Kann Deine Argumentation durchaus nachvollziehen.

Und @Cris__ Wenn Du meinen Container via `docker start easyepg.cron` startest dann sollte er von Docker aus immer dann neu gestartet werden, solange Du ihn nicht bewusst mit `docker stop easyepg.cron` stoppst. Nach einem Reboot des Pi z.B. sollte er automatisch neu starten.

Hab dann auch gleich mal mein Image auf die 2.1.4 hochgezogen. Es hat sich außer dem neuen Patch-Stand des zugrundeliegenden OS (Debian) nichts geändert.

Zitat von easy4me

Im Testing-Branch habe ich eine abgewandelte Form des Telekom-Grabbers eingesetzt - hier sollten nun Änderungen der Kanalnamen berücksichtigt werden. Dabei bleiben die alten Kanalnamen in der XML bestehen, damit die Rytec-IDs weiterhin funktionieren und nicht sofort aktualisiert werden müssen.

So, gestern mal den Testing-Branch installiert und ausprobiert, Folge:
Heute wieder ein EPG für RTLZWEI für Magenta im TVHeadend Sieht für mich so weit gut aus

Was mir aufgefallen ist in Bezug auf meinen Docker-Container:
Ich habe zwar bei meinem init-Script die Möglichkeit eingebaut sowohl das git-Repo als auch den Branch umzustellen, allerdings müssten die sich dann natürlich trotzdem exakt gleich verhalten, was hier insbesondere das Update-Script Deines Repos angeht. Im Moment ist es so, dass der Master die update.sh, der Testing hingegen die testing.sh fürs update benutzt. Bin ich auf dem Testing-Branch und führe das update.sh aus, bekomme ich wieder "nur" Master. Zum Testen habe ich also in meinem init-script beim Setup auto-update auf aus schalten müssen.

Meinste nicht es wäre besser auch für den Testing-Branch die update.sh zu benutzen? Musst Du halt beim Merge nur aufpassen, dass das nicht aus versehen direkt so im Master landet.

Zur Not könnte ich auch noch den Namen des update-scripts konfigurierbar machen, aber besser fände ich hier eine allgemeingültige Lösung.

Alternativ (was dann aber Einschränkungen bei den Branch-Namen mit sich bringen würde) könnte man auch auf die Idee kommen die update.sh als Fallback zu benutzen und vorher zu schauen, ob es ein Script mit dem Namen des aktuellen Branches in Kleinbuchstaben gibt z.B.

@sualfred 2.1.3 ist als latest im DockerHub hinterlegt - da ist dann "file" auch mit drin

@sualfred docker build läuft...

@sualfred welche Abhängigkeit genau? Dann füge ich die gerne hinzu

@sualfred da muss ich gerade Mal passen gedanklich. Scheint eher was mit easyepg zu tun zu haben auf den ersten Blick. Zumindest kenne ich bisher keinen vergleichbaren Fehler

Was nicht heißt, dass es keiner ist...

Top, issue solved @bennySB

@bennySB und, läuft?