Beiträge von hi2hello

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!

Zitat von horschte

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).

Zitat von DeBaschdi

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

Zitat von Cineologe

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.

Das Trakt PlugIn in Emby hat sein Monaten einen Fehler, daher auch die obige Meldung.

Bei Emby schiebt man es auf Trakt, bei Trakt auf Emby.

Soweit ich das einschätzen kann und drüben im Emby Forum gelesen habe, liegt es an zu häufigen Aufrufen von Emby an Trakt, so dass Trakt eine Sperrung durchführt. Es hilft wohl nur ein Kontakt zum Trakt-Support, der dann die Sperrung aufheben kann (API-Gedöns). Im Anschluss sollte man den Abgleich auf 1x wöchentlich stellen, keinesfalls täglich.

Ich habe das Problem ebenfalls seit Monaten, war bisher aber zu faul, mich darum zu kümmern und den Support zu kontaktieren.

Noch kurz zur Erklärung der beiden Optionen:

- Export Library to Trakt > Watchstates aus Emby an Trakt senden

- Import playstates from Trakt.tv > Watchstates aus Trakt in Emby übertragen (Achtung, dieser Import überschreibt ggf. bereits im Emby gesetzte Watchstates mit dem Status, der in Trakt vorhanden ist!)

Ist denn das Emby Plugin für Trakt installiert und aktiviert?

Falls ja, ist es in Emby mit dem entsprechenden Emby-Nutzer verknüpft?

Und gleichst Du emby über "geplante Aufgaben" mit trakt ab? Ggf. automatisiert?

Findet sich alles in den versch. Bereichen der Server-Einstellungen

Zu 1 unter dem Reiter Plugins
Zu 2 unter Benutzer

Zu 3 unter Geplante Aufgaben

Ich möchte nix an der Lampe anlöten. Soll keine Spuren daran hinterlassen.

Die Idee mit dem Rundholz ist aber interessant.

Ich denke mal weiter drüber nach, wie ich das am besten mache …

(Billig und schnell mit Ware von der China-Stange vs. Custom-perferkt-wie-ich-möchte-für-leider-eher-teurer)

Vielen Dank für Eure Anmerkungen und Inspirationen!

Das habe ich schon verstanden. Ich denke aber über pro / contra bzw. Möglichkeiten nach.

In den Rezensionen steht, dass ein Gleichspannungswandler für die korrekte Spannung im USB-Stecker verbaut ist (der nicht einstellbar ist).

Super an dem Produkt: Ich kann jedes beliebige USB-Netzteil mit 5V, 2A daran packen.

Nicht so gut: Kabel sieht ziemlich fragil aus, kein Flachband (Batteriedeckel muss also offen bleiben), Spannung nicht einstellbar (nicht so dramatisch)

Daher hatte ich obiges mal verlinkt. Aber auch das hat den Nachteile: globiges Netzteil (nicht einstellbar) und kostet schlank das doppelte.

Am liebsten wären mit die Einzelkomponenten, dann würde ich mir das selbst zusammenlöten:

- Batterie-Adapter (finde ich einzel nirgendwo) + Dummy-Batterie > Flachbandkabel 2 adrig > DC-Hohlsteckerbuchse > Universalnetzteil m. DC

Eigentlich sowas in der Art wie auf dem Bild. Das wäre flexibler, oder?

da_user und don: Dieses Teil auf amazon hatte ich ebenfalls gefunden, USB aber vorerst wieder verworfen.
Warum? USB liefert 5V, ich benötige 3V. Will mir die Lampe nicht grillen.

Nach meinem Verständnis komme ich mit einem 5V-USB-Netzeil also nicht weit, oder? Ich kenne kein USB 3V-Netzeil, daher die Idee, ein Universal-Netzteil zu nehmen. (Ich mag mich aber auch irren - dann gerne sagen )

Finde die verlinkten Batterie-Dummies generell gut, nur bräuchte ich dafür dann noch ein passendendes Netzteil mit 3V, dass ich an die USB-Buchse der Dummy-Batterie anschließen kann.

Mit anderen Worten: Ich bräuchte eine gesamte "Kette" (Batterie-Dummy, Anschlüsse und bestenfalls die Möglichkeit ein Flachbandkabel anzuklemmen, Netzteil)

Sowas hier habe ich gefunden. Da steht aber leider nichts auf dem Netzteil, d.h. ich kann nicht sicher sein, dass wirklich nur 3V kommen.
https://www.amazon.de/dp/B0BNQR88YL/?coliid=I2VLMJMQSHDVK5&colid=2225N2H1TQGMN&ref_=list_c_wl_lv_ov_lig_dp_it&th=1&tag=kodinerds04-21 [Anzeige]

Wäre dieses Netzteil was für oben genannten Zweck? (Klick)
Hat jemand eine Ahnung, wie man die Steckverbindung nennt? Dann müsste ich nur noch nach dem passenden Gegenstück suchen.

Flachband dran und an einen Batterie-Dummy gelötet …

Soviel jedenfalls in meiner Theorie