darkside40 Danke Dir und sorry für das "spammen" im Release-Thread. Mea Culpa.
Ob das hier jemand findet, ist natürlich nochmal eine ganz andere Frage. Mir jedenfalls war der Thread bisher gar nicht bekannt.
In Ergänzung zu der Share / Freigaben-Thematik habe ich ein ganz interessantes Video gefunden, dass die neuen Regeln ganz gut erklärt. Leider nur in Englisch.
Habe ebenfalls problemlos auf die neue Version hochgezogen.
Es scheint sich aber eine ganze Menge getan zu haben.
Was mir am meisten gravierendsten auffällt, findet sich im Bereich Freigaben / Shares bzw. dort im Bereich des Caches / Cache-Pools.
Zuvor gab es die Möglichkeit von "cache preferred, cache only, …" Das Konzept wurde offensichtlich komplett geändert. Man gibt hier nun primäre und optional sekundäre Speicher an, um festzulegen, wo Dateien auf das Array gespeichert werden. Ich bin noch nicht ganz hinter die Funktionsweise gestiegen, bzw. welche Auswirkungen diese Änderungen im Detail bedeuten, wollte das aber mal angemerkt haben.
Vielleicht schaut Ihr Euch das ebenfalls einfach mal an.
Ebenfalls interessant: Das Plugin "Appdata / Backup Restore" (zum automatisierten Sichern diverser Dateien) ist mit 6.12 gestorben. Es gibt im AppCenter (Reiter "Apps") ein neues PlugIn "Appdata Backup". Dieses automatisiert das Backup von Docker-Einstellungen. Weitere Backup-Möglichkeiten, also die Sicherung anderer Dateien, bietet das Plugin hingegen nicht.
Ggf. sollte man sich vor dem Update auf 6.12 ebenfalls mal anschauen, ob man nicht noch eine alte Version des PlugIns "gpu-stats" installiert hat. Das ist ebenfalls hinfällig. Das neue PlugIn heisst "gpu-statistics" und ist ebenfalls im App-Center zu finden. Die Info bzw. das "neue" Plugin ist nicht mehr ganz taufrisch, das Alte wurde aber nicht automatisch durch das Neue ersetzt.
Mal so ein kurzer Zwischenstand: Stand heute ist nach wie vor nichts zu merken von einem erneuten "Aufblähen" des Docker-Containers.
Ich habe mir die in meinem obigen Kommentar verlinkte Version (mit 2 AAA) für zwei batteriebetriebene LED-Leuchten gegönnt und bin sehr zufrieden. In Kombination mit einer smarten Steckdose sind diese nun auch in die Heimautomation eingebunden.
Im Vergleich zu anderen Lösungen (die ca. 9 Euro kosten und per USB-Adapter angeschlossen werden) hat diese den Vorteil eines Flachbandkabels (Batteriedeckel lassen sich schließen), ein ausreichend langes Kabel (1,8m) plus mehr Variabilität durch den 2-Pin-Stecker, an den auch andere Netzteile angeschlossen werden könnten.
Die Verarbeitung ist ebenfalls um einiges besser als bei den USB-Varianten, die ich ebenfalls getestet hatte und die im Anschluss postwendend zurück gingen.
Am liebsten hätte ich eine komplett "flexible" Lösung gehabt. also inkl. variablem Netzteil mit Spannungsschalter. Das hätte aber die Bestellung von Einzelkomponenten bedeutet und wäre mir zu teuer geworden. Inkl. Dummy-Batterien, Netzteil, Kabel etc. wären ca. 40 Euro fällig geworden.
Was ich jetzt auf Anhieb nicht gesehen habe - woran lag es?
Hast Du nicht gesehen, weil ich es nicht weiß!
Fest steht, dass der Docker-Container sich zuvor dynamisch erweitert bzw. vergrößert hat. Die Daten (welche auch immer das waren) wurden dann in den Ordner "Proc" geschrieben.
Ich habe vor der Neuinstallation mal meine alten Einstellungen mit den Standard-Docker-Settings auf github verglichen und konnte absolut KEINEN Unterschied erkennen.
Für mich rangiert das in der Rubrik "IT-Mysterien", auf die ich leider keine Antwort gefunden habe.
Schön ist, dass mein Docker-Image jetzt keine Zicken mehr macht und es mir nicht mehr das komplette Cache-Drive so voll schreibt, dass sich erst alle Docker verabschieden und irgendwann das gesamte UnRaid mit sich reißen. Hat einen Moment gedauert, bis ich diesen "Fehler" lokalisieren konnte.
Tut mir leid, dass ich keine Infos mit mehr Substanz zum Thema beitragen kann.
Ich werfe mal das hier in den Raum …
bzw. bei 4 AA-Batterien / Akkus das hier:
https://www.amazon.de/dp/B08698RX6K/?tag=kodinerds04-21 [Anzeige]
Stipinho: Das stimmt imho so nicht. Mein Denon Receiver zeigt Atmos an, auch ohne installierte Speaker
Die Frage ist natürlich dennoch berechtigt.
Habe den Docker gekillt, also komplett gelöscht und über die oben verlinkten Docker-Settings für unraid neu installiert.
Nach der Installation dann beendet, die settings.json in den entsprechenden Ordner kopiert und neu gestartet.
Der ominöse Ordner "proc" ist jedenfalls verschwunden. Der Ordner benötigt aktuell 10 MB.
Ich beobachte das mal. Bin gespannt,
Danke jedenfalls für den (mal wieder) supernetten und hilfreichen Support! 
Danke für die Info und den Link zum Template. Ich kann nur einen Unterschied zu den Einstellungen meines Dockers erkennen: Während der Pfad unter dem Punkt easyepg* im Template /mnt/cache/docker/appdata/… ist, habe ich /mnt/user/appdata/…. angegeben. Bei mir liegen alle Docker-Einstellungen in einer Freigabe (appdata), dieses Verzeichnis ist aber kein Unterordner (wie wohl im Template). Das mache ich mit allen Dockern so und es läuft problemlos. Die Freigabe (appdata) ist dabei so eingestellt, dass sie ausschließlich auf das Cache (Cache: prefer) schreibt, daher spare ich mir den direkten (bzw. erzwungenen) Zugriff auf das Cache-Laufwerk, also mnt/cache/…
Exkurs:
Irgendwo im UnRaid-Forum bzw. dem Manual steht, dass man Laufwerke nicht direkt ansprechen soll sondern nur Benutzer (also nicht "/mnt/cache" sondern "mnt/user"). Soweit ich mich erinnern kann, hat das etwas mit der Art und Weise zu tun, wie UnRaid Dateien automatisch auf Laufwerke verteilt. Das spielt beim Cache vermutlich erstmal keine Rolle, zumindest solange kein Cache-Pool ins Spiel kommt. Die Methode mit Nutzerpfaden hat übrigens auch den Vorteil, dass (bei Freigabe auf "Cache: Prefer") Einstellungen automatisch ins Array geschoben geschoben werden, sobald das Cache voll ist und dorthin zurückgeholt werden, wenn wieder Platz verfügbar ist. Spricht man das Cache direkt über einen Pfad an und es läuft voll, machen alle (!) Docker die Grätsche, sprich: werden mit einem Fehler beendet. So zumindest die Theorie (Klick mich!).
Verständnisfrage: Warum legt man (laut Template) den Ordner "appdata" in ein übergeordnetes Verzeichnis "docker"? Da in "appdata" meines Wissens nach sowieso nichts anderes liegt als Docker-Einstellungen, könnte man sich "docker" doch sparen? Sollte das nur an persönlichen Präferenzen liegen, kann und soll das natürlich jeder so handhaben wie er mag - ich möchte nur sicher gehen, dass ich hier keinen Denkfehler mache, der zu meinem Fehler führt.
Wie dem auch sei:
Aus meiner Sicht sollte die Abweichung des Pfades zu den Einstellungen des Dockers dennoch keinen Unterschied machen und somit kein Grund für das merkwürdige Verhalten bzw. der Existenz überflüssiger Ordner ("proc" …) sein.
dlueth @DeBaschdi Was meint Ihr?
Momentan vermute ich, dass ich den easyepg-Docker komplett löschen und neu installieren muss. Gäbe es die Möglichkeit, die EPG-Einstellungen (welche Kanäle etc) irgendwo zu speichern, so dass ich sie in eine neue Installation einfach nur reinkopieren könnte und nicht alles neu aufsetzen müsste?
Danke Euch!
Aua! Da war ich mit meinen 200 GB ja noch gut bedient.
Aber auch 20 GB nach einer Neuinstallation ist nicht von schlechten Eltern.
Da gibt es dann ja eine Menge Möglichkeiten, warum sich das gegenseitig in die Quere kommen kann. Von Ports über Schreibrechte über Serviceblocking …
Nadel im Heuhaufen
Auch an Dich die Frage: Wie groß ist bei Dir appdata/easyepg/proc/1/taks/1/pagemap?
Dankeschön!
ich kann dich leider nicht aufklären. das ganze liess sich bei mir aber genau reproduzieren. startete der pihole und der easyepg container normal, dann kam es zum benannten problem, teils auch erst einen tag später. wurde der easyepg container vezögert gestartet, trat das problem nicht mehr auf. zwischenzeitlich wurden weder system- noch containerupdates durchgeführt.
Sehr dubios. Anhand Deiner Beschreibung nehme ich an, dass pihole und easyepg beide auf derselben Maschine laufen?
(Bei mir ist das nicht der Fall).
Der Fehler tritt bei mir auch nicht auf (Unraid, docker im Cache) sehr kurios, pihole nutze ich selbst auch.
Könntest Du mir mal einen Gefallen tun und Deine Docker-Settings für den easyepg Container posten (oder per PM)?
Und nur aus Interesse: Wie groß ist denn bei Dir appdata/easyepg/proc/1/taks/1/pagemap ?
Danke Dir!
horschte: Danke für den Hinweis aber inwieweit hat denn pihole etwas mit der Anlage einer riesigen Datei innerhalb eines Docker-Containters zu tun? Ich verstehe den Zusammenhang nicht.
Bei mir läuft zwar auch eine Instanz von pihole, diese läuft aber nicht unter UnRaid und es wird auch nichts bzgl. der Docker-Kommunikation geblockt.
Könntest Du mich aufklären? Merci
easy4me Ich habe das jetzt mal gelesen, um ehrlich zu sein aber nicht verstanden. Am Anfang geht es einige Posts zu dem Problem, dann ist TVHeadend Thema …
Soweit ich das verstanden habe, gehört die Datei pagemap, ja sogar das gesamte Verzeichnis da eigentlich gar nicht hin bzw. das sind Überreste (kernel-feautre), die im Docker-Container nicht unbedingt etwas zu suchen haben? Habe ich das so richtig verstanden?
Abhilfe schafft dann eine Neuinstallation des Dockers mit anderen Parametern? Oder aus einer andere Quelle?
Leider übersehe ich wohl die Lösung? Oder kommt die vielleicht später im Thread?
(Wie man das schlau unter Unraid macht ist nochmal etwas anderes.)
Ich bin zugegeben alles andere als ein Docker-Crack (ganz blöd eigentlich aber auch nicht, dachte ich jedenfalls).
Sorry, wenn ich mich hier total bescheuert anstelle.
Nebenbei: Bei mir ist die Datei aktuell 17 Gig groß (nach einer Neuinstallation. Wie erwähnt nahm sie am Ende 200 GB ein).
Danke für den Hinweis. Dann werde ich mich morgen Abend wohl mal daran machen müssen, den Thread hier zu durchforsten.
Über die Suche finde ich bisher nichts passendes.
Bei mir lief das seit Release auch problemlos. Heute dann der Fehler.
Ich kann auch nicht sagen, ob die Datei mit der Zeit anwächst. Wäre mir aber vermutlich aufgefallen, da ich den Füllstatus des Cache recht regelmäßig überprüfe und imho war da nichts.
Ich gehe also davon aus, dass irgendein Prozess dann ziemlich schnell in die Datei reingeschrieben hat. Die erste Warnung kam um 11:30 - da war der Cache schon zu 80% gefüllt. Um 12:00 war dann Ende.
Aber ist ja auch irgendwie müßig und Lesen im Kaffeesetz. Ich weiß ja nichtmal, was die Datei pagemap beherbergt bzw. was da reingeschrieben wird.
Hat jemand eine Idee und dann auch einen Ort, wo ich ggf. Logs finden kann, die Aufklärung bringen könnten?
Boogie2005 Verstehe Deine Aussage nicht. Natürlich liegt es am Docker, die Datei wurde doch in meinem Post eindeutig identifiziert. Da wird solange etwas in die config geschrieben, bis jedes Laufwerk voll wäre.
Mir ist heute mein gesamtes Unraid abgeschmiert, da das Cache komplett vollgeschrieben wurde. Die Recherche hat dann ergeben, dass der easyEPG-Docker der Verantwortliche ist. Im Verzeichnis /mnt/cache/appdata/new-easyepg/proc/1/task/1 hatte die Datei pagemap sage und schreibe 199 GB (siehe die beiden Screenshots im Anhang),
Wie ist das möglich? Mein Fehler? Bug? Habe ich etwas falsch konfiguriert?
Aus dem Protokoll konnte ich nichts lesen (ausser dem zu EIT-Fehler, der wohl zu vernachlässigen ist).
Muss ich damit erneut rechnen? Hatte das schonmal jemand?
Ich habe die Datei pagemap gelöscht und den Container nochmals neu initialisiert. Die Datei pagemap hat nun immer noch 17,1 GB (was mir persönlich ziemlich viel vorkommt aber weit entfernt ist von 199 GB).
Danke und Grüße
Ich habe keine Probleme mit dem Plugin aber kenne das verhalten.
Es müssen die Einstellungen des Plugins gelöscht und der Api Key neu vergeben werden.
Dann sollte es wieder laufen.
Ich habe bisher deinstalliert und dann neu installiert.
Auf die Idee mit einem neuen API-Key bin ich bisher noch nicht gekommen und werde das mal ausprobieren.
