Beiträge von Huberer

@Ruschi

es kann sein, dass du die Module die neu geladen werden, umdrehen musst. Also zuerst
(modprobe) ddbridge, dann cxd2099 und dann erst dvb_core. Ich glaube mir ist da oben ein Fehler passiert.

@Ruschi

Ich habe dir mal ein Script für /usr/local/bin zusammengestellt. Wie du das Script benennst bleibt dir überlassen, jedoch muss es gleich lauten wie das Script unter /etc/systemd/system. Natürlich musst du auch deine persönlichen Anpassungen im Script vornehmen. So weiß ich nicht, wie der Name von deinem tvheadend unter Docker heißt. Also bei mir lautet er, na net, "tvheadend" (beachte bitte auf jeden Fall die Groß- und Kleinschreibung!!!!)
Auch schau nach ob bei dir unter /dev/dvb/xxx die gleichen Einträge sind wie bei mir. Bei mir waren 4 Einträge, da ich zwei DVBSky S952v3 drinnen hatte.

#!/bin/sh


docker stop tvheadend
sleep 3
modprobe -r ddbridge
sleep 1
modprobe -r cxd2099
sleep 1
modprobe -r dvb_core
sleep 3
modprobe dvb_core
sleep 1
modprobe cxd2099
sleep 1
modprobe ddbridge
sleep 2
chown -R dockeruser:users /dev/dvb/adapter0
chown -R dockeruser:users /dev/dvb/adapter1
sleep 2
chmod -R 666 /dev/dvb/adapter0
chmod -R 666 /dev/dvb/adapter1
sleep 2
chown -R dockeruser:users /dev/dri/card0
chown -R dockeruser:users /dev/dri/renderD128
sleep 2
chmod -R 666 /dev/dri/card0
chmod -R 666 /dev/dri/renderD128
sleep 3
docker start tvheadend
sleep 3
exit 0

Am besten ist, du probierst dann einfach mal unter /etc/usr/lib das Script händisch aus. Also einfach Script-name.sh ausführen (Bsp. permissions.sh). Leider kann ich das Script nicht testen, da ich ja keine DD Cine habe. Wenn eine Fehlermeldung kommt, diese bitte posten.
Ansonsten schaust du dann unter /dev/dri bzw. /dev/dvb nach und (also cd /dev/dri bzw. cd /dev/dvb) und mittels

ls -l

siehst du dann die Rechte. So sieht es bei mir unter /dev/dri aus:

und so sieht das bei meinem Script aus

_@Ruschi

#!/bin/sh


docker stop tvheadend
sleep 3
chown -R wuzzi:users /dev/dri/card0
chown -R wuzzi:users /dev/dri/renderD128
sleep 2
chmod -R 666 /dev/dri/card0
chmod -R 666 /dev/dri/renderD128
sleep 3
docker start tvheadend
sleep 3
exit 0

und so sieht meine gpu-permissions.sh aus, welche unter /usr/local/bin liegt.
Da ich eine Digibit R1 verwende brauche ich die Module nicht entladen bzw. neu laden. Ich muss lediglich die Grafikkarten-Hardware auf den entsprechenden Benutzer "umbiegen". Also nicht bei root lassen.

Achtung: Im Docker musst du dann bei "Restart policy" auf "No" stellen.

Der Benutzer "wuzzi" habe ich unter OMV angelegt. Der ist als ganz normaler "User" angelegt und im Docker sieht es dann auch so aus:

Also der User PUID=1001 (ist der user "wuzzi") und PGID=100 (das ist die normale User-Gruppe"

Ist ja klar. Dein Script wird nur ausgeführt, wenn der Server in den Standby/Ruhezustand geht. Nach einem Neustart wird dein Script nicht ausgeführt, da der Befehl dazu nicht da ist.

Hier ist mein Systemd-Script, welches IMMER ausgeführt wird (nach Neustart, Ruhezustand, Sleep, usw.)

[Unit]
After=network.target


[Service]
ExecStart=/usr/local/bin/gpu-permissions.sh


[Install]
WantedBy=multi-user.target

Heißen tut das Script

gpu-permissons.service

und befindet sich unter

/etc/systemd/system

mittels

chmod 664 /etc/systemd/system/gpu-permissions.service
systemctl daemon-reload
systemctl enable gpu-permissions.service

das Script ausführbar machen.

wenn du dann nach

/etc/systemd/system/multi-user.target.wants

wechselt siehst du dort den Eintrag "gpu-permissons.service"

somit ist dir klar, dass das System-Script ausgeführt wird.
Probiere das einmal aus.

Aber Achtung: du musst vorher natürlich deine alten Einträge unter /etc/systemd/system/sleep.target.wants und wo sonst du dein Script ausführbar gemacht hast löschen. Danach den Server neu starten. Auch musst du das oben gepostete System-Script auf den Namen deines Scripts unter /etc/usr/lib anpassen (Bsp. permissions.sh)

wenn du meine Schritte befolgst und nicht abweichst, wie von dir bereits getan, dann muss es hinhauen. Bei mir geht es halt auf jeden Fall...

Am besten ist, du postest deine Skripte einmal hier. Mehr kann ich dann erst morgen am Abend dazu sagen

Ist schon klar. Ein Versuch ist es auf jeden Fall wert. Wenn es nicht geht, ist auch kein Problem. ich weiß ja, dass Embuary für Kodi in Verbindung mit Emby ist. Da brauche/darf ich dann nicht meckern wenn es mit einer anderen Kombi nicht geht.

Bezüglich der Cine kann ich dir nicht weiterhelfen, da ich so eine nie hatte (vor der Digibit hatte ich 2x DVBSky S952v3).
Aber schau dir diesen Beitrag hier an. Hier werden auch die Module für eine Cine v6.5 ent- und neu geladen. Ich schätze diese wirst du brauchen.
Auf jeden Fall sind es mehr als zwei. Wenn du nur eine oder nur die Hälfte ent- und neu ladest, bekommst du trotzdem die Fehlermeldung und es funktioniert nicht.

Zitat von Ruschi

ich habe aber eine Verständnisfrage: benötige ich nicht eigentlich 2 Scripte für tvh ?

Genau. Eines welches als "Service" bzw. Befehlshaber läuft (das unter systemd) und das zweite das ausgeführt wird (das unter /usr).
So läuft es am stabilsten unter OMV v4

@Peppi
So hat es bei mir unter OMV v3 funktioniert. Unter v4 keine Chance. Weiß nicht woran es lag. Wenn es bei dir unter OMV v4 läuft, finde ich es super.

Zitat von sualfred

...Es gibt auch eine Hand voll Plex User die den Skin nutzen.

Echt jetzt? Ich wollte schon fragen, ob ich deinen Skin in Verbindung mit PlexMediaServer (natürlich auf Kodi) verwenden kann. Zuerst wollte ich es testen, aber ich komme im Moment nicht dazu. Das wäre super, wenn dein Skin auch mit PMS läuft

@Ruschi

Schau dir das hier an. Mein aktuelles Script sieht aber jetzt so aus (wichtig ist dass du tvheadend vorher beendest und wieder neu startest nach den Laden der Module - das fehlte beim alten Script weswegen es auch Probleme gab). Der Benutzer, auf dem die Grafikkarte/TV-Karte angepasst wird muss natürlich im Docker auch angeführt sein (PUID/GUID). Da liegt der Hund begraben. Normalerweise hat die TV-Karte/GPU root-Rechte und ein "normaler" Benutzer kann darauf nicht zugreifen (daher werden sie in TVH nicht angezeigt bzw. kein HW-Transcoding). Somit werden die Benutzerrechte dafür "zurechtgebogen". Solltest du Emby auch noch verwenden (im Docker), gilt hier das gleiche (für HW-Transcoding). Musst dann nur docker stop emby (oder wie dein Container heißt) und docker start emby (am Ende) hinzufügen. Mein Tipp ist auch dass du zwischen den einzelnen docker stops und docker starts ein ein paar Sekunden zum Warten (Bsp. sleep 2) hinzufügst.

#!/bin/sh


docker stop tvheadend
sleep 3
chown -R wuzzi:users /dev/dri/card0
chown -R wuzzi:users /dev/dri/renderD128
sleep 2
chmod -R 666 /dev/dri/card0
chmod -R 666 /dev/dri/renderD128
sleep 3
docker start tvheadend
sleep 3
exit 0

Ich verwende in der Zwischenzeit einen Digibit R1 deswegen brauche ich auch keine Module der TV-Karte entladen bzw. neu laden. Im alten Script funktionierte das einwandfrei.
Wichtig ist natürlich dass du die beiden Scripte ( usr/local/bin und etc/systemd/system) ausführbar machst (chmod a+x scriptname)
Die systemd-Datei musst du natürlich auch "aktivieren". Wenn du nicht weißt wie das geht, schau dir das hier an.

Die Module für deine TV-Karte musst du natürlich auch dementsprechend anpassen.

Danke für die Info.

Mit range meinst du unterschiedliches IP-Netz, oder? also wie oben geschrieben 192.168.1.x für die erste und 192.168.2.x für die zweite Karte.

Ich glaube aber, dass ich vermutlich besser/sicherer dran bin mit einem Switch. Trotzdem danke für den Input

Vielen Dank. Also wird es ein Switch werden. Ich dürfte eh irgendwo einen TP-Link herumliegen haben. Dann lasse ich das mit den zwei Netzwerkkarten.

Danke nochmals

Hallo,

da ich am Router um einen Lan-Anschluss zu wenig habe und ich nicht unbedingt einen Switch kaufen möchte, stellt sich somit die Frage, ob es möglich ist, den Digibit R1 mit Axe-Firmware direkt am TVH-Server anzuschließen. Also ich würde den Server dann mit zwei Intel-Netzwerkkarten betreiben. Eine, mit der IP 192.168.1.x, die fürs Internet und interne Netzwerk ist und die zweite die nur dazu dient die Verbindung zum Digibit herzustellen.

Würde dies gehen und wenn ja, wie mache ich das am besten? Muss ich den Digibit in einem anderen Netzwerk (Bsp. 192.168.2.x) betreiben oder geht das auch im selben Netz, wie die "Haupt-Lan-Karte" (192.168.1.x)?

Soviel weiß ich schon, dass eine direkte Verbindung auf Gb-Lan mit einem "normalen" Netzwerkkabel möglich ist. Da brauche ich kein Crossover, was ich so gelesen habe.

Macht es überhaupt Sinn den Digibit direkt anzuschließen oder wäre es besser mit einem Switch?

Vielen Dank im Voraus

@debutanker

vielen Dank. Diesen Beitrag kenne ich, jedoch verbindet sich TVM direkt mit dem Oscam-Server über DVBJCAM. Bei mir ist Oscam schon mit dem Server verbunden, jedoch müsste ich nur TVM dazu bringen, den Oscam-Clienten zu verwenden.

Hallo,

da ich seit kurzem eine Synology zum Testen habe, habe ich auch TV Mosaic einmal darauf probiert. Es funktioniert alles einwandfrei, lediglich bekomme ich keine Verbindung zwischen TVMosaic und Oscam. Oscam läuft auf meiner Syno als Client und ist Oscam mit dem Oscam-Server verbunden.
Unter TVHeadend ging es ziemlich leicht TVH mit Oscam zu verbinden und das Bild hell zu bekommen. Unter TV Mosaic schaffe ich es nicht, dass TVM Oscam verwendet. Hat da jemand einen Tip oder Idee?

Danke im Voraus

Sorry, da bin ich selber überfragt. Ich lese das jetzt zum ersten Mal von dir. Muss ich mich selber schlau machen.

Soll ich dir zufällig auch meine Einträge von Tvheadend zeigen? Dann wirst du sehen, dass zwischen Plex und TVH Übereinstimmungen gibt.
Ob der Eintrag PUID oder UID heißt ist grundsätzlich egal. Ich verwende die Docker-Images von linuxserver.io und da wird es so mit PUID beschrieben. Es geht auch mit UID.
Diese Einträge sind Image übergreifend. Also egal ob Plex, Emby, TVH, usw.

Und der /dev/dri Eintrag ist die Verbindung zur GPU. Auch gleich unter TVH, Plex oder Emby.

Und das Gute an Docker ist, du kannst dein System nicht zerschießen. Also probiere es einfach aus. Und wie gesagt, die Rechte nicht vergessen

Gesendet von iPhone mit Tapatalk

@hylli

hast du schon
--device=/dev/dri

unter "extra args" beim Container gesetzt?

Und zusätzlich musst du noch die Rechte von /dev/dri anpassen wenn du im Container deinen Benutzer mittels PUID gesetzt hast. Root würde ich im Container nicht setzen.
Ich meinte du musst noch folgende Befehle über die Kommando-Zeile ausführen:

chown -R Benutzer:users /dev/dri


chmod -R 666 /dev/dri

Benutzer bitte durch den Namen deines angelegten Benutzer ersetzen. Root braust du nicht verwenden, da /dev/dri eh root-Rechte hat. Also ich würde im Container die Werte PUID und GUID. Über

id Benutzer

über die Kommandozeile findest du die PUID und GUID deines angelegten Benutzers heraus. Also bitte nicht "Benutzer" wie hier beschrieben verwenden. Es sei denn, du hast wirklich einen Benutzer mit dem Namen "Benutzer" angelegt.

Achtung: nach einem Neustart sind diese Änderungen wieder weg. Deswegen verwende ich unter OMV ein Script welches die Rechte wieder anpasst. Kann aber nur sein, dass du vorher den Container stoppen musst, die Rechte anpassst und dann wieder den Container startest.

Hier als Beispiel meiner Einstellungen (ist zwar für Plex Media Server, aber kannst es auf Emby übertragen - PUID und PGUID-Werte)

Nein, leider nicht. Ich bin da auch zufällig über einen Beitrag im hardwareluxx-Forum gestoßen. Bin ich froh darüber, denn mit dieser Aufgabenplanung läuft es perfekt.