Unter unRaid beendet sich der Admin-Modus mitten während des Setups (Grabber Config). Der Container läuft dann nicht mehr und muss neu gestartet werden. Dann beginnt das Spiel nach wenigen Sekunden von vorn. Ein Setup ist damit quasi unmöglich.
Installiert ist der Container von docker.hub (qoopido/easyepg.minimal).
hast Du Mal logs? Kommt mir komisch vor, weil @DeBaschdi gerade unter unraid auch testet...
Ja, Der Anfang ist schwierig, aber hey: bei mir läuft das nun seit deutlich mehreren Monaten sehr stabil. Wenn ich nicht gerade Mal so aktiv rumbastel, dass sich doofe Fehler wie gestern einschleichen...
Alles gut, ich bemüh mich zu helfen wo ich kann 
Kommst Du auf Deinem NAS auf die Shell? Dann mach mal ein "docker images" - das zeigt Dir die images an die Du auf der Kiste hast. "docker ps" zeigt laufende Container, da müssen ggf. vorhandene easyepg.minimal Container gestoppt werden. Im Anschluss dann ein "docker rmi IMAGENAME", wobe IMAGENAME das Image ist, was Du bei "docker images" rausbekommen hast und was qoopido/easyepg.minimal:irgendwas heißt.
"docker rmi" löscht die heruntergeladenen images so das sie beim nächsten mal neu gezogen werden. Docker ist leider manchmal etwas hartnäckig...
Die erste Zeile ist exakt der Fehler, den ich heute morgen behoben habe. Ich glaube Dir ja, dass du ein Update gemacht hast. Geklappt hat es indes aber wohl eher nicht.
Bitte mit logs Posten ich vermute auch, dass er nicht ordentlich geupdated ist. Und ja, völlig richtig: Run und Cron sind die benannten Modi des Containers. Alles andere lässt ihn idle laufen, was gewünscht ist um in den Admin Modus zu kommen...
Ich hatte in der Vergangenheit schonmal nen slack channel aufgemacht
@DeBaschdi machte mich gerade darauf aufmerksam, dass in meinen Änderungen von gestern an meinem Container ein dicker Bug drin ist für die Cron-Benutzer. Der fix baut gerade und sollte binnen 60 Minuten als neues Image verfügbar sein.
Der Container startete nicht richtig, ein Update hilft dann
@harryharz wenn ich es noch richtig im Kopf habe habe ich das genau so gemacht, ja
Wenn du "docker ps" eingibst während der Container läuft müsste er dir anzeigen welcher es ist. Der minimal ist meiner.
@DeBaschdi kann es sein, dass das Update nur dann ohne Fehler geht, wenn man vorher nen install via clone aus dem aktuellen repo-Stand gemacht hat? Mit war auch schon aufgefallen, dass das nicht ganz unproblematisch ist...
Also ich verwende auch die neuen Stream, aber ohne ffmpeg-pipe. Quelle ist bei mir aber nicht eine m3u, sondern ich pflege die von Hand über die TVH-GUI ein. Brauche aber auch nur 21 Sender... Dort steht dann drin, z.B.
rtp://87.141.215.251@232.0.20.35:10000
Was sich in meinem Container noch geändert hat:
Das Autoupdate von easyepg geschah vorher nur beim Starten des Containers. Wenn also jemand den Container im cron-modus laufen hatte vermutlich eher selten.
Mit der neuen Version macht er ein Update auch vor jedem Durchlauf (vorausgesetzt natürlich, dass autoupdate aktiviert ist)
Mein Container baut gerade - dauert ca. eine Stunde, dann ist er fertig
@DeBaschdi Du hast Post in Bezug auf Alpine...
@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...
@DeBaschdi sind das schon Debian Paketnamen? Müsste mod242 dann wohl auch reinpacken, oder?
@Kampfader ja, kann aber sein, dass sie noch nicht richtig funktionierte.
Das init-script würde sowohl den container neu holen als beim darauf folgenden Neustart ( im Zweifel Manuel) auch easyepg.
@Kampfader Hast Du das Setup über mein init-script aus dem Repo gemacht? Da kannst Du angeben, welchen branch von easyepg du im Container benutzen willst und auch ob, er das automatisch updaten soll oder nicht. Default ist "master" und "yes" (bei autoupdate). Das Update wird aber tatsächlich nur beim starten des Containers durchgeführt. Wenn Du also den "cron"-Modus benutzt eigentlich nur dann, wenn entweder der Container oder der umgebende Host abkackt / neu gestartet wird.
Ein Update des kompletten Containers ist für ein update des internen easyepg nicht nötig. Sowohl Installation als auch das update innerhalb des Containers geschehen via Git, sind dann also immer aktuell.
@easy4me Gerade nochmal den master-branch getestet: Läuft. Ergo brauche ich TESTING für mich nicht mehr...
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...
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...
@easy4me Sollte sie jetzt schon auf dem Master funktionieren? Dann hättest Du ja zumindest Teile aus dem TESTING-Branch bereits übernommen oder neu bzw. anders implementiert... So oder so läuft der TESTING-Branch bei mir seit Wochen fehlerfrei
