Beiträge von hi2hello

Sprechen wir vom Verzeichnis addons/skin.embuary-leia/xml? (habe den skin unter coreelec laufen)
Falls ja, bewirkt diese Änderung bei mir nichts. Nach einen Reboot bekomme ich bei Auswahl von "Live TV" in der Sidebar nach wie vor das Programm ("TV-Kanäle" angezeigt.

Hätte mal eine Frage zur Konfiguration des seitlichen Menüs:
Aktuell gibt es die Option "PVR anzeigen". Leider zeigt diese bei Auswahl dann immer das Programm.
Gibt es eine Möglichkeit, das so zu konfigurieren, dass man direkt den EPG angezeigt bekommt?

Danke und Grüße

@effe.rnr: Genau das ist mir zu viel Arbeit
@DeBaschdi: Der Mapper entspricht ja eigentlich der Einstellung im easyEPG "convert to Rytec", oder? Scheint auch alles zu laufen soweit, außer ein paar "doppelten" Kanälen, die ich nun eben aus der Abfrage im easyEPG löschen werde (was ja durchaus vorteilhaft ist; aus 113 Channels wurden nun 61).

"Probleme" gemäß [definition='1','0']log[/definition] gibt es wohl aktuell nur mit Servus TV HD
[ EPG Warning ] Rytec ID not matched for ServusTV HD
Da scheint dann aber ServusTV > Servus HD zu funktionieren

Danke für den Tipp. Ich probiere das mal mit den Rytec IDs im EPG Skript. Falls das immer noch nicht klappen sollte, mache ich einen neuen Thread auf …

Kann Dir leider nur sagen, dass bei mir unter 4.1.1 mit der m3u hier aus dem Forum hier alles so läuft, wie es soll.
Dein Problem wird aber öfter drüben im Emby-Forum behandelt.

Mal was "ganz anderes" zum Thema Zusammenspiel EPG (xml) und Kanalliste (m3u) unter IPTV Simple Client:
Ich nutze den IPTV Simple Client unter Kodi und darin die .m3u-Liste deutscher Hauptkanäle, die hier im Forum zu finden ist. Den EPG beziehe ich seit kurzem über den Docker EPG-minimal und dort über die Anbieter horizon.TV_de und swisscom_ch. Klappt auch soweit.

Aber:
Leider mappen die Kanäle aus dem EPG nicht automatisch mit dem IPTV Simple Client, da dieser den EPG für den entsprechenden Kanal wohl nur dann anzeigt, wenn der Kanalname in der XML identisch ist zum Kanalnamen der m3u. Das ist leider nicht der Fall. Ergo: Für manche Kanäle wird in Kodi kein EPG angezeigt.

Für zdfneo habe ich daher z.B. den swisscom EPG verwendet, da hier der Name identisch ist (horizon leider nicht). Für arte bekomme ich es leider gar nicht hin (da es keinen Kananl im EPG gibt, der namentlich identisch ist zur m3u).

Was kann ich da machen? Die m3u jedes Mal umschreiben wenn sie neu geladen wird ist ziemlich umständlich.
Gibt es vielleicht eine Alternative zum IPTV Simple Client, der channel mapping beherrscht? Mir ist leider kein PVR-Client für Kodi bekannt.
Extra auf TVH umsteigen? Hier könnte man den Kanälen Namen geben. Die bittere Pille dabei: Keine Programmicons und Bilder mehr in Emby. Also auch nicht das Gelbe vom Ei und irgendwie auch mit Kanonen auf Spatzen geschossen.

Ein mapping-script per Cron für die XML oder die m3u? Klingt gut! Das hätte auch den Vorteil, dass ich keine Kanäle mehr doppelt aus dem EPG laden müsste, nur weil der Name im PVR IPTV Simple Client nicht passt bzw. passen könnte und würde die Ladezeiten für das EPG sicher dramatisch reduzieren. Wüsste nur leider nicht, wie ich das anstellen sollte.

Bin momentan ein wenig ratlos. Vielleicht hat ja jemand einen Tipp …
Mache auch gerne einen neuen Thread auf wenn das hier zu viel wird.

Besten Dank!

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