Installation eines VDR+Plugins nativ auf CoreELEC Boxen

Zabrimus Ich habe das build script etwas erweitert, dass die Images in ein release Verzeichnis verschoben werden und dass alles so hergerichtet wird, dass man VDR*ELEC über einen eigenen Update-Kanal aus Kodi heraus updaten kann.

Das Ganze liegt bei mir auf einem Apache im Netz und ich kann von da weg nun per Kodi GUI updaten

Wäre sowas evtl. interessant, um deine Releases auf githubüber den "originalen" Update-Mechanismus zur Verfügung zu stellen? Alles was man bräuchte wäre ein öffentlicher Webspace und Traffic... Gibts sowas noch für umsonst?

Erledigt. Wie CoreELEC das macht, weiß ich nicht. Evtl. klappts ja auch mit dem Script von LE.

Ich hab noch 2 commits nachgeschossen...

Wirklich? Ich hab nochmal einen PR gemacht...

Alles gut, ich war mit meiner Antwort zu schnell oder github zu langsam.

Allerdings funktioniert das wohl nur mit LibreELEC. So wie ich das sehe, müsste man die releases.py für CoreELEC patchen. Oder CoreELEC hat selbst so ein script? Da kenne ich mich nicht aus.

Klasse Projekt und super Beschreibung.

Vielen Dank an alle Beteiligten.

Ein Odroid N2+ (4GB RAM, 64GB) läuft nun als zweiter Client an unserem zentralen VDR-Server.

Ein Punkt ist für uns noch offen:

Der Server sowie der x86-Client basieren auf yavdr-ansible (jammy mit vdr-2.6.4) und verwenden einen dedizierten vdr Nutzer (User- und GruppenID 666). Alle Aufnahmen erfolgen auf dem Server. SVDR-Peering ist dazu bei allen Clients eingerichtet. Auch wird das Aufnahmeverzeichnis per NFS bei den Clients eingebunden. Damit können Aufnahmen beliebig programmiert und Aufnahmen auf jedem Client abgespielt werden.

Um nun Aufnahmen auch auf dem Odroid Client bearbeiten zu können, müssten nach meinem Wissen die Benutzerrechte des Servers sowie aller Clients identisch sein. Da beim Odroid mit VDR*ELEC alles unter root-Rechten läuft passen hier die Rechte nicht.

Um nicht den Server und Clients mit root-Rechten laufen lassen zu müssen, suchen wir Möglichkeiten den Odroid Client ebenfalls mit vdr user-/group-ID 666 laufen zu lassen oder die per NFS geteilten Dateien entsprechend aufzubereiten.

Hat jemand dazu eine Idee?

Auch stelle ich mir die Frage, ob es bei Verwendung eines Ausgabedevices wie softhdodroid (und vergleichbaren Plugins) überhaupt möglich ist, diese mit Nicht-root-Rechten laufen zu lassen.

Bitte um Erhellung hierzu und ggf. den Hintergründen.

Vielen Dank

Bernhard

Ich glaube bei NFS kann man auf dem server irgendwo einstellen auf welchen user die Clients gemappt werden sollen. Damit sollte es dann gehen.

Da musst du mal googlen.

Stichwort für die Suche dürfte "root_squash" + "anonuid"/"anongid" sein. Siehe manpage von exports:

Here's the complete list of mapping options:

Zitat

root_squash

Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as

user bin or group staff.

no_root_squash

Turn off root squashing. This option is mainly useful for diskless clients.

all_squash

Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is

no_all_squash, which is the default setting.

anonuid and anongid

These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all re‐

quests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150

(which is supposedly that of user joe).

Alles anzeigen

Schöne Grüße, Space

Danke, das war die Lösung.

Mit root_squash oder besser noch all_squash und anonuid=666 und anongid=666 kann auch der Odroid jetzt schreibend auf den NFS share zugreifen.

Danke

Bernhard

Zitat von jojo61

Um das leidige Thema mit den Audio Devices mal zu erledigen habe ich nun Default Devices eingerichtet und man braucht die Parameter -a und -p nicht mehr zu setzen. Weil der Treiber nur für amlogic Hardware ist und dort Audio immer gleich ist, kann man das so machen.

Zabrimus bitte nochmal /storage/.config/vdropt/conf.d/softhdodroid.conf

ändern und nur folgendes eintragen:

Code

[softhdodroid]

jojo61: Ich habe das ja in chroot laufen. Beim Starten übergebe ich nun keine Parameter für das Plugin. Ton funktioniert, auch 5.1 kommt richtig beim Verstärker an. Aber: Wenn ich dann kodi aufrufe und wieder zurück auf den vdr wechsle, ruckeln 5.1-Sendungen ganz fürchterlich. Um das wegzukriegen, muss ich dann erst über Menü-Einstellungen einen vdr-Neustart machen. Ich vermute, dass da nach einem ATTA und DETA Einstellungen nochmal neu gesetzt werden müssen. Ob das jetzt nur amlSetMixer ist oder noch mehr überblicke ich aber nicht.

Dr. Seltsam Ich habe für die Audiodevice nur defaults eingeführt. D.h. wenn du -a und -p mitgibst dann werden sie auch genutzt.

Nun meine Frage. Funktioniert es mit der Kodi umschaltung wenn du die Audiodevices wieder mitgibst ?

Zitat von jojo61

Dr. Seltsam Ich habe für die Audiodevice nur defaults eingeführt. D.h. wenn du -a und -p mitgibst dann werden sie auch genutzt.

Nun meine Frage. Funktioniert es mit der Kodi umschaltung wenn du die Audiodevices wieder mitgibst ?

Moin,

wenn ich beide Optionen wieder übergebe, funktioniert 5.1-Ton mit passthough auch nach Rückkehr von Kodi wieder.

Wenn ich allerdings im Plugin-Menü passthrough deaktiviere, ruckelt es bei 5.1-Streams - auch schon ohne Kodi vorher zu benutzen. Ob das auch vorher schon so war, kann ich nicht sagen. Ich meine, dass das Plugin die -p Option ignorieren sollte, wenn passthough in den Plugin-Einstellungen abgewählt ist.

Zitat von Dr. Seltsam

Ich meine, dass das Plugin die -p Option ignorieren sollte, wenn passthough in den Plugin-Einstellungen abgewählt ist

Das ist auch so. Das -p Device wird nur bei passthrough genutzt.

Zitat von Dr. Seltsam

Wenn ich allerdings im Plugin-Menü passthrough deaktiviere, ruckelt es bei 5.1-Streams

Bei deaktiviertem Passtrough und 5.1 Ton wird Multiple PCM ausgegeben. Also 6 PCM Kanäle. Kann das dein TV/Receiver? Ansonsten musst du AC-3 Downmix aktivieren.

PS:

bei einem ATTA initialisiere ich das Audio komplett neu. Wenn du ohne -a und -p startest dann nutze ich die HW Devices hw:0,0 für passthrough und hw:0,3 für PCM Audio. Könnte sein das Kodi hier querschlägt weil es andere devices nutzt und da Seiteneffekte zurück bleiben.

Zitat von jojo61

Das ist auch so. Das -p Device wird nur bei passthrough genutzt.

Bei deaktiviertem Passtrough und 5.1 Ton wird Multiple PCM ausgegeben. Also 6 PCM Kanäle. Kann das dein TV/Receiver? Ansonsten musst du AC-3 Downmix aktivieren.

Das sollte dem Plugin doch egal sein, ob das Endgerät es dekodieren kann. Für mich sieht das Ruckeln eher danach aus, als wenn das Plugin die PCM-Audiodaten nicht los wird, weil es sie an ein device übergeben will, dass diese nicht annimmt.

Ich verwende für -a und -p gleichermaßen hw:CARD=AMLAUGESOUND,DEV=0

CoreELECTanixTX3:~ # aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=AMLAUGESOUND
    AML-AUGESOUND, 
    Default Audio Device
sysdefault:CARD=AMLAUGESOUND
    AML-AUGESOUND, 
    Default Audio Device
surround71:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    IEC958 (S/PDIF) Digital Audio Output
hdmi:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    HDMI Audio Output


CoreELECTanixTX3:~ # aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
default:CARD=AMLAUGESOUND
    AML-AUGESOUND, 
    Default Audio Device
sysdefault:CARD=AMLAUGESOUND
    AML-AUGESOUND, 
    Default Audio Device
surround71:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    IEC958 (S/PDIF) Digital Audio Output
hdmi:CARD=AMLAUGESOUND,DEV=0
    AML-AUGESOUND, 
    HDMI Audio Output

Ich muss gestehen, dass mir die Numerierung und Bezeichnung der alsa-devices in Linux bis heute ein Buch mit 7 Siegeln ist...

Zitat von Dr. Seltsam

Ich muss gestehen, dass mir die Numerierung und Bezeichnung der alsa-devices in Linux bis heute ein Buch mit 7 Siegeln ist...

Da bist du nicht alleine. Und unter chroot heissen sie wieder anders.

Allerdings würde ich hier für das -p Device ein

iec958:CARD=AMLAUGESOUND,DEV=0

setzen. Letztlich sieht man nur im Log ob das "richtige" Device genutzt wird. Im Kernel sollte dabei audiobus:i2s2hdmi für das -a Device geloggt werden und für das -p Device wäre ein audiobus:spdif_b richtig.

Zitat von jojo61

Allerdings würde ich hier für das -p Device ein

Code

iec958:CARD=AMLAUGESOUND,DEV=0

setzen. Letztlich sieht man nur im Log ob das "richtige" Device genutzt wird. Im Kernel sollte dabei audiobus:i2s2hdmi für das -a Device geloggt werden und für das -p Device wäre ein audiobus:spdif_b richtig.

Sehr verwirrend. Die Tanix TX3 verfügt über einen separaten Ausgang (Klinkenstecker)? für ein SPDIF-Signal. Ich hätte gedacht, das ist dafür.

Mit -p iec958:CARD=AMLAUGESOUND,DEV=0 kriege ich wieder nur Geruckel und im Log steht gar nichts von audiobus. Bei mir geht der Ton über HDMi raus (oder soll es zumindest - mit hw:CARD=AMLAUGESOUND,DEV=0 geht es)

Brauchen wir eigentlich eine Konfigurationsmöglichkeit für HBR, so wie hier in softhddevice?

Added HBR control for audio passthrough. Version 1.11.0. · ua0lnj/vdr-plugin-softhddevice@6b69ef0

github.com

Zitat von Dr. Seltsam

im Log steht gar nichts von audiobus

Das ist im Kernellog und sollte da auch zu finden sein.

Zitat von Dr. Seltsam

Brauchen wir eigentlich eine Konfigurationsmöglichkeit für HBR, so wie hier in softhddevice?

Ja ich habe gesehen das es da konfigurierbar ist. Aber so lange es ohne HBR nun geht wollte ich es nicht einbauen. Ist dann nur noch ein Parameter der nur für Experten etwas bedeutet.