[docker] NEW easyepg

Schau' mal im Beitrag #374. Was mir bei deinem Compose auffällt, sind die abschliessenden Slashes. K.A., ob das so richtig ist.

Jep die Slashes sind zuviel, und die PUID und GUID gibt es beim Takealug Easyepg nicht:

es werden nur USER_ID & GROUP_ID vom Container gelesen.

- /srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/new-easyepg:/easyepg
- /srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/new-easyepg/xml:/xml

TVHeadend Docker Version kannst ganz einfach das Easyepg importieren und zwar über Internen EPGGrabber Webgrab Plus (tv_grab_wg). Dazu musst noch nichtmal irgendwas bearbeiten sondern die xml File wie folgt einbinden:

volumes:
 - /pfad/new-easyepg/xml:/config/data

Im TVHeadend Docker Compose

Thats it.

Ich hab auch erst lange rumgebastelt bis das funktioniert hat, aber das TVHeadend von Linuxserver.io hat bereits tv_grab_wg integriert und das verweist auf dem Pfad /config/data

Wenn du einfach dort hin mountest macht den Rest TVHeadend selbst.

Und falls du die URL zu der *.xml brauchst, bekommst du die so, wie auf dem Bild markiert.

Der sieht dann z.B. so aus: https://*url*/download/epg.xml

Lg

Lehmden1 las dich nicht verwirren. das einzige was falsch ist:

/srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/new-easyepg/xml/:/xml

die zeile weg und du hast zugriff auf deine xml wo du sie erwartest.

slash am ende oder nicht, ist voellig egal

ob da irgend welche ENV gesetzt sind die im container nicht verarbeitet werden, wurst.

Hi.

Ändert nichts, egal ob mit Slash oder ohne, mit Volume oder ohne, mit PUID oder ohne, spielt keine Rolle. Easyepg läuft immer dafür landet die XML Datei niemals da, wo sie landen soll. Sie ist zwar per HTTP Download problemlos erreichbar (und zwar immer), aber eben nicht als lokale Datei an einem Ort, auf den man irgendwie zugreifen könnte. Leider kann man ja auch nicht in das Dateisystem des Containers rein gucken. Dazu müsste sowas wie mc oder wenigstens eine SSH- Shell mit im Container laufen. Wenn ich nur eine Ahnung hätte wohin easyepg die Datei speichert, könnte ich vielleicht rausfinden, wie man das umgehen kann. Aber so weiß ich einfach nicht weiter. Im schlimmsten Fall muss ich ein Script basteln, das z.B. mit Wget die Datei herunter lädt und so speichert, das man dran kommen kann. Gibt es wget bei OMV? Eigentlich ja, würde ich denken. Hab ich aber noch nie getestet.

Auf jeden Fall vielen Dank für die Hilfe.

Der Pfad den du in deiner compose angibst, ist auch der, der real und im Container da ist. Du kannst also per ssh auf dein omv und in den docker-daten/easy-epg pfad und da siehst du auch alles.

Alles was nicht da drin ist, ist nur temporär im ram.

Zitat von noob_at_pc

Alles was nicht da drin ist, ist nur temporär im ram.

Ok, dann speichert easyepg seine Daten (bei mir) immer nur im RAM, doch warum? Die Standard- Pfade sind da und beschreibbar, auch das Umlenken per "volumes" verweist auf Orte, die problemlos beschreibbar sind. Aber egal was ich da versuche, das klappt nie. Nicht lustig, obwohl EPG Daten ja nur eine sehr kurze "Halbwertszeit" haben. Gibt Schlimmeres, was da nur temporär im RAM landen könnte.

Zitat von Lehmden1

Ändert nichts, egal ob mit Slash oder ohne, mit Volume oder ohne, mit PUID oder ohne, spielt keine Rolle.

Einen Restart/Neustart des Containers hast Du gemacht?

Zitat von PvD

Einen Restart/Neustart des Containers hast Du gemacht?

Natürlich, sogar mit "Down", nicht nur "Stop", damit der Container auf jeden Fall neu erzeugt wird. Nach jeder Änderung den Container neu starten, einen Moment warten und dann das Grabben wieder anstoßen. Ändert nur leider rein gar nichts. Die XML Datei bleibt im Dateisystem verschwunden, kann aber per HTTP geladen werden. Ist bestimmt nur eine ganz dumme Kleinigkeit, die ich aber einfach nicht finde.

Der Mountpfad ist auch ungewöhnlich.

Vielleicht solltest du probieren das ganze per /etc/fstab permamnent zu mounten.

/srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/ /mnt/meineplatte auto nosuid,nodev,nofail,noauto 0 0

Je nachdem was für Dateisystem das ist natürlich den Pfad /mnt/meineplatte kannste ändern wie du möchtest insofern das Verzeichnis existiert. /mnt/ ist aber der Linux Standard Mountpfad oder für USB Medien /media/

Das dann im Docker anpassen. z.b. /mnt/meineplatte/Docker ...

Was für ein Betriebssystem isses denn und was für ein Dateisystem auf der Festplatte ?

Ext4 ? NTFS, exfat ...

Zitat von Starfoxfs

Der Mountpfad ist auch ungewöhnlich.

Vielleicht solltest du probieren das ganze per /etc/fstab permamnent zu mounten.

Code

/srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/ /mnt/meineplatte auto nosuid,nodev,nofail,noauto 0 0

Je nachdem was für Dateisystem das ist natürlich den Pfad /mnt/meineplatte kannste ändern wie du möchtest insofern das Verzeichnis existiert. /mnt/ ist aber der Linux Standard Mountpfad oder für USB Medien /media/

Das dann im Docker anpassen. z.b. /mnt/meineplatte/Docker ...

Der mountpunkt ist so schon völlig richtig so.

Hi.

Als OS läuft OpenMediaVault 7, also Debian Sandworm. Hier kann man alles sehen:

Die Box hat 6 GB RAM, da das nicht angezeigt wird. /dev/sda2 ist das OMV Systemlaufwerk. /dev/sda4 ist eine zusätzliche Partition auf der 512 GB NVMe, auf der auch OMV installiert ist und dev/sdb1 ist die nur zum Testen angehängte USB Platte, die mit NTFS formatiert ist. Auf sda4 liegen die ganzen Docker Daten und auch z.B. der Download- Ordner von JDownloader oder der Aufnahme- Ordner von TVHeadend.

Das ist alles, bis auf die extra Partition auf der System NVMe absoluter OMV Standard. Ohne die extra Partition könnte ich die NVMe nicht für die Docker Sachen u.Ä nutzen, da sich OMV die komplette Bootplatte krallt, sofern man sie nicht vorher schon entsprechend partitioniert. Ist halt mal als OS für USB Sticks konzipiert gewesen. Alle Laufwerke und Partitionen wurden entweder direkt bei der Installation von OMV angelegt oder beim ersten Start bzw. beim ersten Anstöpseln von OMV automatisch so gemounted.

OMV ist es geworden, weil hier der Fernzugriff einfach am besten funktioniert. Klar, SSH geht immer, aber xRDP oder VNC habe ich nie brauchbar ans laufen bekommen, bei "normalen" Linux Distros. Und ich bin nun mal ein Mausschubser kein "sudo Dauertipper".

Hmm ja dann weiß ich auch nicht weiter, das Compose Script passt ja soweit.

Die XML sollte in Docker-Daten/new-easyepg/xml landen wenn auch die Dateien in Docker-Daten/new-easyepg/ liegen passt das ja eigentlich.

Möglich wäre noch ein Rechteproblem beim erstellen der epg.xml

Was sagen die Logs im Docker ?

Zitat von Starfoxfs

Die XML sollte in Docker-Daten/new-easyepg/xml landen wenn auch die Dateien in Docker-Daten/new-easyepg/ liegen

Sollte sie, tut sie aber nicht. Die Dateien sind da, wo sie hin sollen. Nur die XML ist nicht zu finden. Also wird sie vermutlich nur im RAM gespeichert...

Rechteproblem? Hmm, der XML Ordner wurde vom Docker selbst angelegt, genau wie der new-easyepg Ordner. Bei allen anderen Containern klappt das sonst immer. GGFS muss ich doch mal einen anderen User (root? die Sicherheit ist mir erst mal egal) im Compose Script eintragen. Das Log ist für mich nicht wirklich durchschaubar. Ich werde nachher mal versuchen, das Log zu löschen und dann einen neuen Grab- Vorgang durchführen, damit nicht so viel Müll im Log steht. Sonst fange ich noch mal ganz bei Null an und lösche den ganzen Container samt Image und mache alles neu.

Da ich es oben zu erwähnen vergessen habe, sda4 ist mit ext4 formatiert...

Vermutlich werde ich erst meine Erfahrungen sammeln müssen und dann das ganze System noch mal völlig neu aufsetzen und dabei dann nicht so viel herum probieren und nicht so viele Fehler machen wie bei diesem Mal. Auf jeden Fall werde ich alle funktionierenden Compose Files vorher speichern, damit ich das nicht alles noch mal von Vorne machen muss... Zum Glück ist ja das werksseitige Windows 10 weiterhin auf dem internen eMMC Speicher installiert (und bleibt dort auch). So kann ich die ganze NVMe problemlos neu formatieren (mit Paragon Partition Master CE, womit man auch Linux Partitionen unter Windows erstellen, formatieren oder löschen kann).

Im Docker sind die Rechte klar da muss auch nichts geändert werden.

Poste mal die Ausgabe von ls -la in diesem Verzeichnis: /srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/new-easyepg/

Hi.

Mit den Rechten war etwas tatsächlich komisch. Das XML Verzeichnis hatte root als Owner und Group. Hab ich mit chown auf den User und Group aller anderen Dateien/Ordner im Verzeichnis geändert, hilft aber trotzdem nichts. Dafür habe ich nun die xml Datei doch im Filesystem gefunden. Sie liegt unter

/var/lib/docker/volumes/{ganz lange GUID}/_data/

Also klappt da doch etwas nicht mit dem Erzeugen der Volumes des Containers. Nur was?

/var/lib/docker/volumes ist nur der Pfad im Container da liegt die klar auch aber da kommst von außen normal nicht dran ohne root.

In den Container Volumes sind die Rechte immer Root das soll auch so sein.

Der Mount zum Host System muss aber funktionieren also das was in /srv/dev-disk ... liegt das ist der Host System Mountpfad und da sollte auch was drin sein sonst passt da eben entweder mit dem Mount oder mit den Rechten was nicht.

Was sagt denn ls -la unter /srv/dev-disk.../new-easyepg

Nun hab ich es raus. Die Volumes Definition war doch falsch. Außerdem habe ich die USER_ID und GROUP_ID auskommentiert. Ist nicht nötig.

Bisher hatte ich das immer so (in der Art) definiert:

- /srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/easyepg/xml:/xml

Richtig ist aber

- /srv/dev-disk-by-uuid-e40da4a5-4f51-4642-8e7e-c67275cd485d/Docker-Daten/easyepg/xml:/easyepg/xml

Zumindest funktioniert es nun bei mir so wie erwartet.

Hier noch mal das ganze bei mir wirklich funktionierende Compose File, damit der Nächste nicht so viel rumbasteln muss.

Wie gesagt, USER_ID und GROUP_ID braucht man normalerweise hier nicht. Außerdem habe ich den Namen von new-easyepg auf easyepg geändert. Gefällt mir besser.

Zitat von Lehmden1

Nun hab ich es raus

#384