{2025} BM²LTS-v4.5.x - > DD-NET / EXIP / NetCeiver

Quote from cinfo

Ok, hier zum Testen

Mit der vdr Version läuft es.

Im in 1.583 zitierten post hatten wir das gleiche Prob

Im in 1.584 zitierten post ist vdr04 mit dem wieder Alles OK ist.

Fehler: wants statt Wants

systemd[1]: /etc/systemd/system/vdr.service:6: Unknown key name 'wants' in section 'Unit', ignoring

[Unit]
Description=Video Disk Recorder
#Before=lightdm.service
#After=network.target media-hd.mount media64.mount media-nas.mount rc-local.service
After=network-online.target nmbd.service media-hd.mount media-hd-recordings.mount rc-local.service nfs-mountd.service
wants=network-online.target nmbd.service media-hd-recordings.target nfs-mountd.service

Wants muss mit Grossbuchstaben starten. Dann ist es OK.

HI,

reset-kodi:

(
systemctl enable kodi.service
svdrpsend plug softhddrm DETA
sleep 5
kodi
#svdrpsend plug softhddrm ATTA
killall -9 vdr
killall -9 vdr
service vdr start
) > /dev/null 2>&1 &

1 Weshalb muss man eig. den vdr danach killen ? Ich möchte kills wegen der offenen Filehandles möglichst vermeiden.

2 Weshalb kommt danach kein vdr restart sondern start ?

3 Müsste nicht der kodi.service danach disabled werden ?

In usr/sbin/power steht

/usr/bin/killall -9 kodi-x11

4 müsste da nicht einfach nur kodi od. kodi.bin rein ?

5 reset-vdr

Was hältst du von dieser Variante den vdr per Tastendruck neu zu starten ?

(
systemctl disable kodi.service
killall -9 kodi.bin
killall -9 kodi.bin
timeout 10s service vdr stop || killall -9 vdr; sleep 1
service vdr restart
) > /dev/null 2>&1 &

Ich nutze das bei Problemen mit Kodi oder vdr ....

6 Sobald man aus dem vdr Kodi 1x gestartet hat, schleicht sich auch für zukünftige Boots der udisk MAnager ein und mounted sämtl. Partitonen, die man eig. nicht will (sda1,2 von der ext. HDD unter /media/root/UUID.

unit='udisks2.service' requested by ':1.31' (uid=0 pid=1569 comm="/usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalo")

Feb 25 06:23:36 BM2LTS-MC systemd[1556]: Started D-Bus User Message Bus.
Feb 25 06:23:36 BM2LTS-MC kodi[1569]: /usr/lib/x86_64-linux-gnu/kodi/kodi.bin: /usr/local/lib/libcurl.so.4: no version information available (required by /usr/lib/x86_64-linux-gnu/kodi/kodi.bin)
Feb 25 06:23:36 BM2LTS-MC dbus-daemon[598]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service' requested by ':1.31' (uid=0 pid=1569 comm="/usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalo")
Feb 25 06:23:36 BM2LTS-MC systemd[1]: Starting Disk Manager...
Feb 25 06:23:36 BM2LTS-MC udisksd[1575]: udisks daemon version 2.9.4 starting
Feb 25 06:23:44 BM2LTS-MC dbus-daemon[598]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Feb 25 06:23:44 BM2LTS-MC udisksd[1575]: Mounted /dev/sda1 at /media/root/dbfcd848-5a9e-43dd-bbf7-179679e21be7 on behalf of uid 0
Feb 25 06:23:44 BM2LTS-MC kernel: [   19.470152] EXT4-fs (sda1): mounted filesystem dbfcd848-5a9e-43dd-bbf7-179679e21be7 r/w with ordered data mode. Quota mode: none.
Feb 25 06:23:44 BM2LTS-MC kernel: [   19.592530] EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem
...

kein Problem ... ich bräuchte bitte nur eine Antwort auf 1-4, damit ich mein Problem weiter eingrenzen kann.

Ich häng mal hier meine Umbauten an. Wesentlich ist, dass der Ausststieg aus Kodi auf untersch. Arten passieren kann.

Z.B.: Menü Verlassen, PowerButton, per FBD mit reset-vdr od. kodi-stop.

Meine Version von reset-vdr dient auch als Ausstieg von Kodi. Damit benötigt man kodi-stop (als vdr Nutzer) eig. nicht mehr.

Beim Ausstieg aus Kodi muss der kodi.service disbaled werden, alle kodi processes gekillt u der vdr restartet werden.

Power enthält nicht nur die Kodi Anpassung, sondern auch das unmounten der Media Partition.

Danke, noch eine Verständnisfrage:

Wie verhält es sich mit den vdr Timeraufnahmen, wenn man MPV oder KODI aus dem vdr startet.

Bei KODI hatte ich gestern Folgendes beobachtet:

1 Wenn die Aufnahme bereits gestartet ist, läuft diese (verm. weil es ein eigener recording thread ist) weiter.

Wenn dem so ist, stellt sich die Frage, ob nach Ende des recordings

- markad gestartet , die Aufnahme in epgsearch.data eingetragen, etc wird

2 Während Kodi läuft wurde jedoch eine Timeraufnahme nicht gestartet.

3 Bei MPV hab ich das noch nicht getestet, würde aber annehmen, dass hier die vdr Timeraufnahmen wie immer laufen sollten ?!

Quote

Wie verhält es sich mit den vdr Timeraufnahmen, wenn man MPV oder KODI aus dem vdr startet.

Bei KODI hatte ich gestern Folgendes beobachtet:

1 Wenn die Aufnahme bereits gestartet ist, läuft diese (verm. weil es ein eigener recording thread ist) weiter.

Wenn dem so ist, stellt sich die Frage, ob nach Ende des recordings

- markad gestartet , die Aufnahme in epgsearch.data eingetragen, etc wird

2 Während Kodi läuft wurde jedoch eine Timeraufnahme nicht gestartet.

3 Bei MPV hab ich das noch nicht getestet, würde aber annehmen, dass hier die vdr Timeraufnahmen wie immer laufen sollten ?!

Display More

Ich spreche von vdr Timeraufnahmen nicht Aufnahmen aus KODI. D.h. ich verstehe nicht was das mit dem VNSI zu tun hat

Quote from gggggg

Wenn dem so ist, stellt sich die Frage, ob nach Ende des recordings

- markad gestartet

Da gibt es zwei Möglichkeiten das zu überprüfen:

1. VDR loglevel auf 3 -> dann gibt es eine Syslog Meldung "markad: cStatusMarkAd::Start(): executing "/usr/bin"/markad ..."

2. markad Plugin Einstellungen "Log ins Aufnahmeverzeichnis" auf ja -> dann gibt es im Aufnahmeverzeichnis eine markad.log

Ah OK, Danke. Dann funktioniert das mit dem VNSI in der .18 jedenfalls nicht. Wäre es ein Workaround, wenn ich den VNSI disable (weil TV in Kodi brauch ich nicht).

Und bei MPV: MPV sollte den vdr nicht beeinflussen oder ?