Beiträge von hi2hello

m3u8 oder m3u? 4.1.1.0?
Scheint ein Emby Bug mit m3u8 zu sein.

https://emby.media/community/inde…stream-looping/

Früher gab es mal eine Einstellung für das Looping. Entweder ist die nicht mehr da oder ich finde sie nicht mehr.

Zitat von dlueth

@hi2hello hm, das ist seltsam, bei mir klappt das. Hast du den imdb Mapper an?

Bei mir ist die 2.0.1 heute Nacht ordentlich durchgelaufen - Quelle Magenta, 21 Sender, 14 Tage mit IMDB Mapper in 20 Minuten

Ja, Imdb und Rater. Ebenfalls 2.0.1. 111 Manifests aus horizon und 1 aus swisscom.
Manuell brauchen 4 Tage ca. 1 Stunde. Dabei geht die Erstellung der XMLs superflott (ca. 3 Minuten). imdb dann knapp eine Stunde.

Ich schaue mir das morgen früh nochmals an, ob es dann durchgelaufen ist. Nur, um sicher zu sein.

Der Cronjob des minimal dockers hat um 2:00 Uhr wie geplant 2 channellists abgearbeitet und daraus 2 xml files erstellt (horizon_de.xml und swisscom_ch.xml). Was allerdings nicht über das cron zu laufen scheint, ist die Anwendung der combine.sh bzw. beide channellisten zu einer zusammenzuführen.
Über "modify xml files" wurde alles entsprechend eingestellt (channels, addons) und funktioniert auch manuell über "run combine script" und "run in grabber mode".

Mache ich etwas falsch?

Leute, das ist echt ganz großes Tennis hier!
Danke für Eure Mühe!!!

In die Container des Dockers komme ich. Wie das funktioniert, ist mir klar. Aber wie komme ich in das „Dateiverzeichniss“ des Images?
Mich würde interessieren, was da noch so rumliegt. Außerhalb der Container. Wo liegen z.B. die Reste von zuvor installierten Containern, die mittlerweile wieder gelöscht wurden?

Würde mir gerne die einzelnen Dateien anschauen, die in dem Image liegen. Oder mache ich einen Denkfehler?
Ich kenne das von Unix/Mac und eigentlich auch Linux. Da ist ja ein Image quasi ein geschlossener Container. Den kann man mounten und hat dann Zugriff auf die einzelnen Dateien. Quasi wie eine Festplatte. Funktioniert das bei einem Docker-Image anders? So weit bin ich bisher bei Docker noch nicht vorgestoßen. Anfängerkram, den ich bisher nie gebraucht habe
Oder mit anderen Worten: Ich habe eigentlich wenig bis keine Ahnung, wie Docker genau funktioniert. Erwischt!

Die Templates werden ein paar k ausmachen. Dabei werden nur Cotainereinsstellungen gespeichert. Für die Übersicht sicher eine gute Idee, die nicht benötigten zu löschen. Ob das wirklich relevant für den Speicherverbrauch ist, wage ich zu bezweifeln.
Ich würde ja gerne mal in das Docker.img schauen. Ich weiß nur leider nicht wie.

Ich kann gerne schauen, bin mir aber nicht sicher, ob das mit dem vergrößerten docker.img vom easyepg-Container kommt. Hordesprime hat ja geschrieben, dass er easyepg gar nicht verwendet, das Problem aber trotzdem auftritt. Bei mir werden zudem die cache-Dateien, bzw. alles in Zusammenhang mit easyepg gar nicht im Docker-Image, sondern extern gespeichert -zumindest sollte das so sein denn so ist der container konfiguriert.

Ich musste heute meine Docker-Container zum Großteil neu aufsetzten wegen einem dummen Fehler, den ich bei der Recherche zum Speicherproblem gemacht habe, daher habe ich auch alle cache-files verloren. Sieht also so aus, als ob das dann einen Moment dauert, bis ich da etwas rückmelden kann,

Hilfreich wäre, an welcher Stelle der cron-job eingestellt werden kann und ggf. wo sich der Schnipsel aus Deinem Quellcode befindet, so dass ich das mal auf 1 Tag oder so runterschrauben kann. Danach können wir sicher sein, dass die temp-Dteien gelöscht werden oder eben nicht.

docker.ps -s aus der Konsole gibt für die beiden easyepg-Container nach der (identischen) Konfiguration übrigens folgendes zurück:

Nebenbei: Im Container von mod242 taucht der OLDPWD-Fehler beim Konfigurieren einer Channellist auf, nachdem man "Run XML" ausgewählt hat. Im easyepg-minimal-Container taucht dieser Fehler bei mir nicht mehr auf.
Dafür funktioniert im Docker von mod242 der Status-Bar, hat aber im minimal-Docker eine Macke (die nicht schlimm ist - bleibt am Ende eben stehen).

Hallo zusammen,

ich bin gerade über die Tatsache gestolpert, dass mein Emby Server zwei unterschiedliche Ablageorte für die Metadaten der Schauspieler (people), genauer gesagt -deren Bilder, zu haben scheint. Finde ich etwas seltsam, daher wollte ich mal hören, ob das normal oder bei Euch ebenfalls so ist.

Der Standard scheint (/mnt/user/Media)/metadata zu sein; das ist auch im Server-Dashboard unter Bibliothek > Erweitert > Metadata-Pfad eingestellt.
Hier liegen alle Images zu artists, channels, library, livetv, people, studio und views. Der Ordner wird auch von Emby beschrieben, das kann ich an den Datumsangaben der Files sehen - das letzte ist von gestern.

Nun habe ich aber unter (mnt/user/Meta)/metadata noch einen weiteren Ordner entdeckt, wo Emby Metadaten zu Schauspielern abzulegen scheint. Dieser enthält nur People und scheint auch benutzt zu werden denn der letzte File-Eintrag ist ebenfalls von gestern.

Ist das bei Euch auch so? Kann man die Metadaten von Schauspielern nicht an einem Ort zusammenfassen? Ich habe überall in Emby gesucht, finde aber nirgendwo eine Angabe zu dem zweiten Pfad, der nur Schauspieler (People) enthält oder eine abweichende config oder Einstellung, die auf diesen zweiten Ordner verweist.

Danke und Grüße,
hi2hello

@DeBaschdi: So, habe jetzt doch mal die Zeit gefunden.
Dabei ist mir eingefallen, dass ich noch keinen der Container länger als 5 Tage laufen habe. Somit kann ich Dir auf die Frage, ob ältere Files gelöscht werden, leider (noch) keine Antwort geben.

Status Quo

Für den easy-epg-minimal:
Im Cache-Folder IMDB (easyepg/imdb/cache) liegen knapp 1.000 files, allerdings keines älter als von gestern Abend. Ich hatte den Minimal-Docker erst gestern Abend installiert, daher passt das an dieser Stelle.

Für den easyepg:
Hier liegen 850 Objekte, das älteste vom 11.6., ebenfalls der Tag, an dem ich das installiert hatte.

Soll ich das weiter beobachtgen und Dir berichten, was in 4–5 Tagen Stand der DInge ist? Oder könnten wir das über z.B. Einstellungen am Serverdatum simulieren?

Grüße,
hi2hello

NO TOfu

Zitat von DeBaschdi

Ich hab das hier gerade aus zufall entdeckt,
@hi2hello kannst du mal checken wieso der docker so groß ist ?
ich befürchte das die cachefiles des imdbmappers welche älter als 5tage sind nicht gelöscht werden.
zufinden unter easyepg/imdb/cache.
@dlueth @mod24 werden die dateiänderungsdaten bei jedem run neu geschrieben ?
(sonst funktioniert das automatische löschen der cached files > = 5tage alt nicht.

schnipsel aus meinem code zum verständniss :

Code

# Max Cachetime in Days
my $cachetime = 5;


my $cachefolder = "$path/cache/" ;


if ( !-d $cachefolder ) {
    mkdir $cachefolder or die "Failed to create path: $cachefolder";
}


opendir(my $cache, $cachefolder);
while (readdir($cache)) {
    my $cachefiles = "$cachefolder/$_";
    if (-f $cachefiles and -M $cachefiles > $cachetime) {
        unlink $cachefiles;
    }
}

Alles anzeigen

schaue ich mir heute Abend, spätestens morgen an. Komme da gerade nicht dran.

Zur Lösung der Warnmeldung habe ich das docker.img von 20 GB auf 30 GB vergrößert.

Settings > Docker > Enable Docker > No > Apply
Advanced View > anschalten
Docker vDisk size > ändern auf höheren Wert
Enable Docker > Yes > Apply

Mir ist nun auch klar, warum ich im Filesystem 20 GB sehe und über den Button "Container Size" im unter dem Docker Tab nur etwa 12 GB habe: Im Filesystem wird die zugewiesene Größe des Images angezeigt, "Container Size" zeigt den tatsächlichen Inhalt.

Was dennoch merkwürdig ist und was ich nicht verstehe:
12 GB "Container-Size" bei 20 GB Image-Größe sind 60%, nie im Leben 74 oder 77%
Die Warnung hätte imho nicht auftauchen dürfen.

Bin nun bei 49% Image-Nutzung. 12 GB von 30 GB sind ebenfalls nur 40%, nicht knapp 50%.
Scheint, als würde das falsch berechnet.

Egal, das sollte so erst mal passen. Die Warnung ist weg.

Link zum Topic im unRaid-Forum

Bin jetzt bei 77%. Bei Dir @hordesprime? Welche unRaid Version hast Du? Bei mir läuft 6.7.0
Hast Du zufällig easyEPG im Docker laufen?

Das ist auch eine Idee!
Werde ich mal machen …

Danke übrigens für den Hinweis zu den easyEPG-Einstellungen. Der einzige Unterschied zwischen Deiner und meiner Config war die Tatsache, dass bei mir "Console Shell Command" auf "shell" und nicht auf "bash" stand. Das habe ich jetzt geändert. Mal gespannt, ob der Cronjob morgen jetzt dann automatisch anspringt oder nach wie vor streikt.

Der easyEPG scheint nicht das Problem zu sein. Der kommt bei mir auf 894 MB. Habe zum Test auch mal den easyEPG minimal installiert. der kommt auf noch weniger: 504 MB.

Keine Ahnung, ob da noch irgendetwas im Docker-Image ist, das da nicht rein gehört oder nicht gelöscht wurde, falsch installiert etc.
10 GB Differenz zwischen Anzeige in unRaid und der Größe des docker.img sind schon eine Hausnummer.

Leieder habe ich keine Ahnung, wie ich die Inhalte des Images prüfen kann. "docker ps" in der Konsole gibt jedenfalls auch nichts ungewöhnliches von sich.

Top. Danke.
Wenn ich die Werte dort zusammen rechne komme ich aber max auf 11,6 GB.
Woher kommt denn dann die Dockergröße von über 21 GB?

Die dicksten Brocken sind binhex-krusader (2,23 GB) und filebot (1,74 GB). Unglaublich, dass die kleinsten Aufgaben das größte Volumen benötigen.

Hallo zusammen,

ich bekomme seit heute Abend von unRaid den Hinweis, das mein docker.img kurz vor dem "exceeden" sei. Liegt wohl bei 74%.
Die docker.img hat 21GB. Ich frage mich, woher diese Menge an Daten kommt?

Wie kann ich denn prüfen, was da so im img liegt?
Das PlugIn "Clear Appdata" gibt es ja nicht mehr.

Herzlichen Dank!

@BJ1 Danke für Deine Antwort

Habe das exakt wie auf Deinen Screens gezeigt eingerichtet. Hatte nur unter "Console shell command" den Container auf "shell" und nicht auf "bash". Ansonsten sieht das so aus wie bei Dir.

Die ee-cron sieht aus wie auf dem zweiten Screenshot …
Habe auch mal die Rechte der Dateien aus der Konsole des Containers angehängt.