1

Allgemein [ General ] / Neuinstallation

« Last post by clausmuus on Today at 18:15:45 »

1) bei der MLD-6 werden sicherlich andere Verschlüsselungs-Verfahren verwendet als bei der MLD-5. Eventuell werden dadurch auch mehr ssh Keys durchgetestet. Beides kann für eine langsamere Anmeldung sorgen.
2) Ich weiß nicht sicher, ob wir den IPv6 Support durchgängig implementiert haben. Die IPv6 Adresse wird von Deinem DHCP Server vergeben, also z.B. von der Fritzbox. Du müsstest also dort einstellen dass diese nicht vergeben werden soll.

2

Allgemein [ General ] / Neuinstallation

« Last post by purzel on Today at 18:04:43 »

Hallo Claus!

Ich  habe nun immerhin "einige" Boots hinter mir, bisher waren alle MIT Ton; einer dauerte gefühlt etwas länger als sonst - vielleicht wartete er tatsächlich auf die Sound"karte". Ich beobachte weiter.

Nun sind mir ich aber noch zwei speziellere Fragen aufgekommen:
1. wenn ich von meinem Desktop-PC zum VDR via SSH verbinde, mache ich das üblicherweise in einem Shell-Fenster via "ssh root@vdr", natürlich unterschiedliche hostnames. Auffällig ist, dass diese Verbindung zum ALTEN unter MLD 5.3 deutlich schneller aufgebaut wird - und das, obwohl da noch ein Switch mehr auf dem Weg ist. Alles ist Gigabit-Verkabelt. Warum ist die SSH-Verbindung zum 6.5er verzögert (einige Sekunden)
2. wenn ich in der 6.5er Installation mein NAS mounten möchte (CIFS), shclägt das bei Verwenung von //nas/VDR mit der Fehlermeldung "No route to host" fehl, mit IP Adresse (v4) hingegen funktioniert es. Ein "nslookup nas" liefert als erste Adresse die IPv6, als Zweite die richtige IPv4 Adresse. Wie kann ich das fixen? Mit IPv6 habe ich bisher fast keine Erfahrungen sammeln können/müssen.

TIA
purzel

3

Allgemein [ General ] / MLD auf Raspi 5 herunterfahren dauert lange

« Last post by clausmuus on Today at 17:27:44 »

Du kannst die ESC Taste drücken, wehrend das Logo pulsiert, dann bekommst Du angezeigt wo drauf gewartet wird.
Ansonsten mal ein Debug-Log erstellen, damit wir schauen können was Du installiert hast. Eventuell haben wir auch dann schon einen Tipp.
Beim softhddevice Plugin gab es letzte Woche ein Update, dass eine Ursache für Probleme beim herunterfahren behebt.

4

Allgemein [ General ] / UHD1by Astra geht nicht

« Last post by rkp on Today at 17:07:25 »

Der Sender wird nicht angezeigt, obwohl er doch tagsüber frei anzuschauen ist.

Kann es sein, dass ich etwas falsch eingestellt habe?

Code: [Select]

Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] pes: Init: invalid video packet: 65529 232294 | 40
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] pes: Init: invalid video packet: 6949 232294 | 40
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: first valid video packet arrives 632ms after channel switch was triggered
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: first valid audio packet arrives 1070ms after channel switch was triggered
Sep 19 17:05:33 MLD vdr[19872]: [21625] [softhddevice] device: PlayAudio: new channel id 0xBD
Sep 19 17:05:33 MLD vdr[19872]: [19897] [softhddevice] videocodec: main: HEVC (High Efficiency Video Coding) (hevc) for codec "hevc" opened, using hardware decoding with 1 threads 🤩
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: rpivid_h265_start: (3840x2160)
Sep 19 17:05:33 MLD vdr[19872]: [19971] skindesigner: w 3840 h 2160 mode changed to 0
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: SPS changed
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: PPS changed
Sep 19 17:05:33 MLD kernel: rpivid 1000800000.codec: Missing DPB ent 0, timestamp=0
Sep 19 17:05:34 MLD kernel: rpivid 1000800000.codec: PPS changed
Sep 19 17:05:34 MLD vdr[19872]: [19897] [softhddevice] Add display mode change event to follow video mode 3840x2160@50,00
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] device: STATE MACHINE received DisplayChangeEvent
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] Set display mode: 3840x2160@50,00
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] ReInit requested display mode: 3840x2160@50,00
Sep 19 17:05:34 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:34 MLD vdr[19872]: [19878] [softhddevice] device: STATE MACHINE state change done in 107 ms
Sep 19 17:05:34 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:35 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:36 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:37 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:38 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:38 MLD vdr[19872]: [21626] animator thread thread ended (pid=19872, tid=21626)
Sep 19 17:05:38 MLD vdr[19872]: [19872] skindesigner: Osd deleted.
Sep 19 17:05:39 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:40 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] device: Clear:
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] videostream main: ClearVdrCoreToDecoderQueue: packets 0
Sep 19 17:05:41 MLD vdr[19872]: [21625] [softhddevice] device: FlushAudio:
Sep 19 17:05:41 MLD vdr[19872]: [21625] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Sep 19 17:05:41 MLD kernel: cma: cma_alloc: linux,cma: alloc failed, req-size: 1013 pages, ret: -12
root@MLD:~#


5

Allgemein [ General ] / MLD auf Raspi 5 herunterfahren dauert lange

« Last post by rkp on Today at 16:32:05 »

Wenn ich den VDR herunterfahre, bekomme ich ca. 70 Sekunden das MLD Emblem leicht pulsierend angezeigt. Kann mir jemand sagen, was da im Hintergrund abläuft?

6

Allgemein [ General ] / Neuinstallation

« Last post by clausmuus on September 18, 2026, 00:03:27 »

Der Schreibfehler sollte richtig "Trial" lauten, nicht "Try". Ich hab's korrigiert.

Normalerweise ist ein hartes Ausschalten kein Problem, da auf die Boot Partition nur beim Installation von Updates (bestimmter Pakete) oder beim Ändern einiger weniger Einstellungen, geschrieben wird. Also nur in solchen Situationen darf man nicht hart ausschalten. Sicher ist ein sauberes herunterfahren aber immer.

7

Allgemein [ General ] / Neuinstallation

« Last post by purzel on September 17, 2026, 19:12:43 »

Auf der "normalen" MLD Partition /dev/nvme0n1p2 lag noch eine plausibel aussehende syslinux.cfg - die habe ich in die /dev/nvme0n1p1 kopiert und er startet wieder. Puh.

8

Allgemein [ General ] / Neuinstallation

« Last post by franky on September 17, 2026, 19:09:17 »

Du könntest mal versuchen im WebIF des Install-Stick einen Snapshot auf dem installierten System der SSD, das nicht mehr bootet, wiederherzustellen.
Wenn du den MLD-Netinstall-Stick gebootet hast, kannst du im WebIF unter Einstellungen - Snapshots ein Laufwerk auswählen.
Wenn du da deine nvme auswählst, sollten du einen snapshot auf der ssd auswählen und zurückspielen können.
Wenn die SSD nicht komplett zerschossen ist.

9

Allgemein [ General ] / Neuinstallation

« Last post by purzel on September 17, 2026, 18:36:59 »

F1! F1!

Irgendwie habe ich jetzt irgendwas - vermutlich bzw. hoffentlich nur die EFI-Partition - kaputtgemacht. Möglicherweise, das weiß ich leider nicht genau, habe ich die Steckdosenleiste im vollen Betrieb ausgeschaltet weil ich was ändern wollte. Nun meldet er beim Einschalten "No Default or UI configuration directive found!" und ein Prompt "Boot:" da drunter.
Zwar habe ich auch probiert, über die BIOS-Boot-Wahl was zu erreichen aber ich kann keinen der beiden (nach meinem Verständnis gleichen) Einträge booten.
Der MLD-Installations-Stick startet das Setup (mit kleinem Fehler "Trail or Install" - das soll bestimmt "Try or Install" heißen) und ich komme per SSH drauf. "Eigentlich" sieht doch das nicht falsch aus:

Code: [Select]

root@MLD:~# mount /dev/nvme0n1p1 /media/
root@MLD:~# ls -l /media/
total 41308
-rwxr-xr-x 1 root root     4096 Jan  1  1980 FSCK0000.REC
-rwxr-xr-x 1 root root 11486208 Sep 11 17:22 bzImage
-rwxr-xr-x 1 root root 11486208 Mar 25  2025 bzImage-6.14.0-yoctodev-standard
drwxr-xr-x 3 root root     4096 Aug 15 13:52 efi
-rwxr-xr-x 1 root root 19305108 Aug 15 13:52 initrd
drwxr-xr-x 2 root root     4096 Aug 20 14:12 syslinux
root@MLD:~# ls -l /media/efi/
total 4
drwxr-xr-x 2 root root 4096 Sep 17 17:50 boot
root@MLD:~# ls -l /media/efi/boot/
total 908
-rwxr-xr-x 1 root root 196536 Aug 15 13:52 bootx64.efi
-rwxr-xr-x 1 root root 142104 Aug 15 13:52 ldlinux.e64
-rwxr-xr-x 1 root root 185848 Aug 15 13:52 libcom32.c32
-rwxr-xr-x 1 root root  24240 Aug 15 13:52 libutil.c32
-rwxr-xr-x 1 root root  13907 Aug 15 13:52 splash-1280x720.png
-rwxr-xr-x 1 root root  25296 Aug 15 13:52 splash-1920x1080.png
-rwxr-xr-x 1 root root  72258 Aug 15 13:52 splash-3840x2160.png
-rwxr-xr-x 1 root root   7419 Aug 15 13:52 splash-640x480.png
-rwxr-xr-x 1 root root   8784 Aug 15 13:52 splash-720x576.png
-rwxr-xr-x 1 root root   8153 Aug 15 13:52 splash-800x600.png
-rwxr-xr-x 1 root root      0 Sep 17 17:50 syslinux.cfg
-rwxr-xr-x 1 root root 196536 Aug 15 13:52 syslinux.efi
-rwxr-xr-x 1 root root  32584 Aug 15 13:52 vesamenu.c32
Bevor ich das nun total zerschieße: Habe ich eine Chance auf Rettung?

10

Allgemein [ General ] / Neuinstallation

« Last post by clausmuus on September 16, 2026, 21:26:58 »

Ich habe auch noch etwas dazugelernt. Das "systemctl reenable vdr" war in diesem Fall nicht notwendig.