Beiträge von dlueth

So, ich hab den bisherigen Branch meines Containers jetzt mal als 2.0.0 released. Build im Docker-Hub läuft.

Was das Fragen/Lernen angeht: Ich verstehe das viele Leute, wie ich selber bisher auch, in Sachen EPG eher als passive Konsumenten unterwegs waren und technisch entweder wenig affin sind oder wenig Lust hatten oder haben sich darum nun selber zu kümmern.

Ich für meinen Teil habe beschlossen mich einfach zu beteiligen und versuche zu helfen wo ich kann. Was ganz toll wäre, wäre wenn Andere sich ebenfalls beteiligen würden. Ich bin zwar Entwickler, extrem Technikaffin und kann tolles Zeugs mit allem möglichen bauen - habe aber keinerlei Talent abbekommen in Sachen README-Schreiben. Ich rechne @easy4me und @DeBaschdi ihre Bemühungen sehr hoch an und bin auch ein wenig Stolz darauf zu etwas gefühlt so gutem beitragen zu können

Vielleicht könnte jemand mit etwas mehr Talent versuchen z.B. in meinem Repo das README verständlicher zu machen und auch den Fall der NAS-User (der bisher nur rudimentär vorhanden ist) besser zu beschreiben. Resultat gern entweder als PR bei GitHub oder auch als PM hier - ist mir egal...

@effe.rnr Bei `docker ps` könntest Du übrigens evtl. auch noch nen Hinweis darauf finden, ob der alte Container da nicht doch noch irgendwo rumgeistert. So dem so wäre könnte er dort zumindest auftauchen

Zitat von effe.rnr

das hab ich mir auch gedacht. Ich werd heute Abend mal probieren, den Docker Dienst komplett neu zu starten. Momentan gib ich die Konfiguration über eine Oberfläche ein. Dabei trage ich den gemappten Ordner ein (also /easyepg), die PUID und PGID, die TZ und Mode = Cron.Starten funktioniert dann aber wie gesagt nicht.

Oder muss ich mich vorher über SSH aufs NAS einloggen und das machen?
curl -s https://raw.githubusercontent.com/dlueth/easyepg…as-support/eemd > /usr/local/sbin/eemdchmod +x /usr/local/sbin/eemd?

nimm mal mode = admin - Du musst wie auch @DeBaschdi easyepg einmal konfigurieren, danach läuft es automatisch. Dafür muss der container gestartet sein (so wie Du es oben beschrieben hast klingt es eigentlich OK) und dann kommt Du aus der Shell Deines NAS heraus via `docker exec -ti easyepg-admin /bin/bash` (easyepg-admin dabei mit dem Namen den Du oder Dein NAS vergeben hast ersetzen) in den Container rein.

Solltest Du nirgendwo einen Namen finden können, dann gib mal auf der Shell Deines NAS "docker ps" ein, dann bekommst Du eine Liste der laufenden Container ausgegeben. Da steht hinten welches image das ist (da müsste dann etwas mit easyepg stehe) und irgednwo weiter vorne ne ID. Die ID kannst Du bei dem `docker exec ...` oben auch anstelle des Namens verwenden.

Wenn Du im Container bist, dann musst du folgende 2 Befehle ausführen und das Setup von easyepg sollte starten.

su - easyepg
./epg.sh

Danach dann raus aus dem Container mit `exit` und in Deiner NAS-Oberfläche den Container wieder auf mode = cron umkonfigurieren

Was Dein Problem vorhin anging:
Es passiert wohl manchmal, das Container hängen bleiben. Neustarten des Docker-Daemons soll in den meisten Fällen wohl nicht helfen (trotzdem mal probieren) und ggf. mal nen Reboot des NAS machen wenn möglich.

@DeBaschdi

eemd (=easyepg minimal docker) ist ein kleines shell-script was beim starten (unter Linux) hilft für Leute die sich nicht so gut mit Docker auskennen oder keinen Bock haben Ich benutze es z.B. für meinen Cronjob

Ja, docker ist nicht so furchtbar schnell, aber darum geht es dabei auch nicht

Zitat von DeBaschdi

ok...
Funktioniert perfekt mit deinem docker unter windows @dlueth

Ich schreib bei gelegenheit ein howto.
Nich das @debutanker wieder mit mir schimpft da ich windowsuser vernachlässige

OK, super, woran lag's? Ich hab mich vor Jahren von Windows verabschiedet und arbeite nur noch mit OSX bzw. Linux auf Servern...

Ich bau gerade nochmal ne neue Version, hab das `eemd` script noch umgebaut so das die Parameter jetzt `named` sind (-v für das volume z.B.) und es ist ein neuer -r hinzugekommen der die Nutzung der CPU-Kerne limitiert nach Wunsch. Standardmäßig steht der Wert auf 0.5, würde also die Hälfte der vorhandenen Kerne benutzen.

@effe.rnr ich kenn die Oberfläche nicht es hört sich aber so an, als würde der alte Container noch laufen oder zumindest irgendwo noch ein "Rest" existieren.

Gibt es irgendeine Möglichkeit etwas zu clearen für einen Container?

Wie startest Du denn den Container bei dem NAS, Script oder musst Du das in der Oberfläche eintragen?

So, wer mag kann nochmal folgenden Branch testen, README ist angepasst und das im script verwendete docker-image ist im dockerHub hinterlegt:

https://github.com/dlueth/easyepg…ure/nas-support

Bei mir im Test eben funktionierte jetzt beides:

1. Der Container läuft dauerhaft und startet das EPG-Update intern via Cronjob (um 2:00 Uhr, IMDB-Mapper läuft bei mir auch durch)
2. Der Container wird vom Host-System via Cronjob gestartet, macht ein EPG-Update und beendet sich dann wieder

Bei jedem Start des Containers wird easyepg jetzt automatisch geupdatet - updates beim IMDB-Mapper erfordern aber weiterhin ein manuelles de- und wieder aktivieren. Anders ist es im Moment nicht möglich.

Im Moment wird im `eemd` script für die Docker-Container immer ein Limit von 2 CPUs gesetzt. Docker kann zwar nicht wirklich 2 konkrete CPUs garantieren, aber scheint die Last von 2 CPUs auf die Verfügbaren zu verteilen, die dann eben mit niedrigerer Auslastung laufen. In meinem Fall werden die 2 CPUs auf 4 reale CPUs verteilt und jede von denen hat eine Auslastung von ~55%. Ich würde das Script noch dahingehend ändern, dass es die Kerne ermittelt und das Limit auf `Kerne / 2` setzt.

Wenn keiner mehr was findet mach ich da ne Stable-Version draus - für mich fühlt sich das "komplett" an so weit

Zitat von DeBaschdi

@dlueth ja, ist durchaus denkbar das dein containter probleme mit der wait_for_worker() oder wait_for_thread() funktion hat hmm...

Idee?

Wäre wohl am einfachsten ich stelle das nach..
(Hab noch nie mit Dockern zutun gehabt) sollte ich nachholen, ist eine praktische sache...

Ja, ich teste gerade ein paar Ansätze weil auch mein cron-branch noch nicht sauber läuft - lass das sonst mal per PM klären damit wir hier den thread nicht so zumüllen

@DeBaschdi

Bräuchte glaube ich doch nochmal Deine Hilfe: Lasse ich den Container laufen, springe da rein und rufe epg.sh von hand auf (bei aktiviertem imdb-mapper, alles aktualisiert und richtig konfiguriert), dann läuft alles. Am Ende wird ein "modified.xml" erstellt, alles gut.

Lasse ich exakt das gleiche jetzt automatisch ablaufen, dann durchläuft er zwar noch den imdb-mapper scheint aber da auszusteigen, wo er dann das "modified.xml" eigentlich schreiben wollen würde. Idee meinerseits dazu wäre, dass docker aus irgendeinem Grund denkt, dass die Verarbeitung beendet wurde. Das kann aber eigentlich nur dann passieren, wenn irgendetwas im imdb-mapper quasi "extern" ausgeführt wird, also als extra task im Hintergrund o.ä. - kann das sein?

Nachtrag - ich hab gerade mal in den code vom imdb-mapper reingeschaut: Befürchtung wäre, dass die Verteilung auf mehrere CPUs das verursacht, wenn kein "Hauptprozess" parallel weiter läuft und den Container am Leben hält...

@DeBaschdi Irgendwas stimmt da doch noch nicht, ich glaub das ist aber ein Problem bei mir...

Und ne, keine statusbar Also doch, aber die sieht halt zerrockt aus

Was CPU-Schonung angeht: ja, am besten steuerbar über CLI parameter Ich probiere zwar parallel bei mir noch damit rum docker entsprechende Limits mitzugeben aber erfahrungsgemäß sind das mehr "wünsche" als harte Fakten. Braucht der Container mehr wird docker ihm imho auch mehr geben, also alle CPUs ggf. voll auslasten

@DeBaschdi Ich hab mir gerade eh im Büro fix nen neuen Container gebaut und den frisch konfiguriert und hab es gerade getestet: Sieht gut aus. Läuft durch und ich bekomme die angereicherte XML raus!

Zitat von DeBaschdi

Prima, ich hab das jetzt Global im git geändert, (scheiss aufs time benchmarking)

Heisst ich kann jetzt auch nochmal probieren, korrekt?

Zitat von DeBaschdi

klappt z.b auch time ping -c4 google.de ?

Jupp, klappt:

time ping -c4 google.de
PING google.de (172.217.19.67): 56 data bytes
64 bytes from 172.217.19.67: icmp_seq=0 ttl=37 time=19.370 ms
64 bytes from 172.217.19.67: icmp_seq=1 ttl=37 time=12.487 ms
64 bytes from 172.217.19.67: icmp_seq=2 ttl=37 time=17.657 ms
64 bytes from 172.217.19.67: icmp_seq=3 ttl=37 time=38.541 ms

Zitat von DeBaschdi

@dlueth ist es denn auch verfügbar, also der befehl "time" ?
command -v time

output davon ist:

time

Sieht also eigentlich gut aus

Ja, OK - gerade nochmal in das update.sh reingeschaut - das arbeitet etwas anders als ich das in meinem Container beim update tue. Es cloned das repo jedes mal neu (und das auch nicht im update.sh sondern in dem Schnipsel den Du oben gepostet hast - das war mir durchgerutscht) und kopiert dann Dinge rüber. Ich benutze bei mir direkt das bereits geclonte Verzeichnis und verwerfe Änderungen an Dateien die unter git-Kontrolle sind mit:

git checkout -- .
git pull

Da bleiben dann auch alle Einstellungen etc. erhalten, weil die eben nicht unter git-Kontrolle sind. Mal schauen, was ich da draus mache

Zitat von DeBaschdi

Ich glaube nicht, sogenau hab ich mir die Updatefunktion nicht angeschaut, da müsste @easy4me etwas dazu sagen.

Das wäre ja ganz cool für die leute die das im docker laufen lassen und das nicht unbedingt immer manuell machen wollen

Zitat von DeBaschdi

Du meinst bei jedem "startvorgang" ?Damit updatest du aber nicht bereits konfigurierte Instanzen. (zufinden in den jeweiligen länder unterverzeichnissen)

@dlueth ist es denn auch verfügbar, also der befehl "time" ?
command -v time

reicht für das update konfigurierter instanzen ein aufruf von `update.sh` oder kann man das einzeln machen?

in Bezug auf `time`: checke ich heute abend - hab gerade keinen Zugriff aus dem Büro...

@DeBaschdi Ich ziehe easyepg eigentlich bei jedem Durchlauf aktuell aus dem git - aber ja, ich hatte einmal ne Meldung auf dem Schirm wo irgendetwas mit "time not found" stand, war aber nicht reproduzierbar.

Evtl. Verschluckt das Deine progress-bar?

Zitat von Debaschdi

Im script steht vor den workern "time" ist das bei deinem minimalistischem docker integriert?

Was genau meinst du damit? Also das entsprechende Debian/Ubuntu package ist da, falls Du das meintest

Hm, irgendwie will jetzt wieder das imdb-mapping nicht mehr (im RC meines Containers zumindest, heute Nacht ging's aber noch). Er läuft zwar durch, erstellt aber das file nicht. Jemand ne Idee dazu?

Hier der letzte Output:

--------------------------------------------
 CREATING CUSTOMIZED XMLTV FILES             
 --------------------------------------------


Creating XML file: modified.xml ...


 --------------------------------------


Running addon: IMDB MAPPER for modified.xml ...


Helperscripts Found OK
Deleting all Cached Files older then 5 Days
Create Status Bar
Splitting XML in 49 Files


Creating Index for Splitted Files

Nach `Creating Index for Splitted Files` ist dann Feierabend, ohne irgend eine Meldung und die modified.xml wird auch nicht erstellt.

Ich teste momentan gerade eine kleine Erweiterung meines Containers der den dann auch unter den hier verwendeten NAS-Systemen lauffähig machen sollte. Sprich: der Cronjob läuft innerhalb des Containers und der Container beendet sich nicht nach einem Durchlauf.

Dazu hab ich im Moment einen Branch im Git (https://github.com/dlueth/easyepg…ure/nas-support) und der Container müsse für den Moment auf dem betreffenden System von Hand gebaut werden (z.B. via eemd build). Das README bei GitHub für diesen Branch ist schon entsprechend angepasst...

... könnte das vielleicht nochmal jemand gegentesten? Im Moment sieht es für mich so aus als würde das so weit laufen...

Nachtrag: Ich baue den Container gerade im docker hub als 1.0.6-rc.1 - dann müsste aber gedanklich das `eemd` shell script dahingehend angepasst werden und das manuelle Bauen könnte entfallen

Nachtrag 2: Ich hab den Feature-Branch gerade nochmal neu gepushed, so das er die Version automatisch verwendet für alle die testen wollen - ein bauen des Containers von Hand entfällt damit und es gilt das im Repo hinterlegte README.