Danke, das ist schon mal gut zu wissen, dass das satip-Plugin das prinzipiell kann.
Ich frage mal bei DD nach, ob die dazu was sagen können.
Posts by kls
-
-
Weiß jemand, wie man bei einer Octopus NET-M4 (https://digitaldevices.de/prod…k-tv-tuner/octopus-net-m4) das DVB-T-Signal mit VDR empfangen kann?
Geht das mit dem satip-Plugin, oder braucht man dazu was Anderes?
-
Schau ich mir an, wenn ich vom Urlaub zurück bin.
-
Also erstmal müsste das das Ausgabeplugin können, dann kann VDR es entsprechend ansteuern.
Ob und welche Plugins das prinzipell könnten, weiß ich nicht.
-
Bei LCARS ist es so, das da das OSD selbst der "Arbeitsbereich" ist, also direkt in das OSD gezeichnet wird (es wird also nicht mit Pixmaps gearbeitet).
Hier muss der Renderer also selbst herausfinden, was sich im Gesamt-OSD geändert hat.
Siehe dazu osd.h:
Display MoreCode- cPixmap *RenderPixmaps(void);
- ///< Renders the dirty part of all pixmaps into a resulting pixmap that
- ///< shall be displayed on the OSD. The returned pixmap's view port is
- ///< set to the location of the rectangle on the OSD that needs to be
- ///< refreshed; its draw port's origin is at (0, 0), and it has the same
- ///< size as the view port.
- ///< Only pixmaps with a non-negative layer value are rendered.
- ///< If there are several non-overlapping dirty rectangles from different pixmap
- ///< they are returned separately in order to avoid re-rendering large parts
- ///< of the OSD that haven't changed at all. The caller must therefore call
- ///< RenderPixmaps() repeatedly until it returns NULL, and display the returned
- ///< parts of the OSD at their appropriate locations. During this entire
- ///< operation the caller must hold a lock on the cPixmap mutex (for instance
- ///< by putting a LOCK_PIXMAPS into the scope of the operation).
- ///< If there are no dirty pixmaps, or if this is not a true color OSD,
- ///< this function returns NULL.
- ///< The caller must call DestroyPixmap() for the returned pixmap after use.
- virtual void Flush(void);
- ///< Actually commits all data to the OSD hardware.
- ///< Flush() should return as soon as possible.
- ///< For a true color OSD using the default implementation with in memory
- ///< pixmaps, the Flush() function should basically do something like this:
- ///<
- ///< LOCK_PIXMAPS;
- ///< while (cPixmapMemory *pm = dynamic_cast<cPixmapMemory *>(RenderPixmaps()))
- ///< int w = pm->ViewPort().Width();
- ///< int h = pm->ViewPort().Height();
- ///< int d = w * sizeof(tColor);
- ///< MyOsdDrawPixmap(Left() + pm->ViewPort().X(), Top() + pm->ViewPort().
- ///< DestroyPixmap(pm);
- ///< }
- ///<
- ///< If a plugin uses a derived cPixmap implementation, it needs to use that
- ///< type instead of cPixmapMemory.
Die OSD-Implementierung bekommt also über RenderPixmaps() nur den Bereich, der sich verändert hat.
-
Hab's noch auf dem Schirm.
-
wirbel : Ich habe das Problem dadurch gelöst, dass ich auf dem PC2 auch Leap 15.3 installiert habe. Damit klappt es jetzt in beide Richtungen, und beide Rechner kommen ans Netzwerk.
Jetzt habe ich nur noch das Problem, den sendmail zu stoppen bevor ich das System von PC1 auf PC2 "umziehe". Es sollen ja während des rsync keine Emails auf PC1 mehr angenommen werden, da diese ja u.U. nicht mehr auf PC2 kopiert würden.
Display MoreCode- root@eagle:/etc > ps axf | grep sendmail
- 1496 ? Ss 0:00 sendmail: accepting connections
- 11349 pts/2 S+ 0:00 | \_ grep --color=auto sendmail
- 9952 ? Ss 0:00 sendmail: Queue control
- 9953 ? S 0:00 \_ sendmail: running queue: /var/spool/clientmqueue
- root@eagle:/etc > systemctl stop sendmail.service
- Job for sendmail.service canceled.
- root@eagle:/etc > ps axf | grep sendmail
- 1496 ? Ss 0:00 sendmail: accepting connections
- 11403 pts/2 S+ 0:00 | \_ grep --color=auto sendmail
- 11392 ? Ss 0:00 sendmail: Queue control
- 11393 ? S 0:00 \_ sendmail: running queue: /var/spool/clientmqueue
- root@eagle:/etc > systemctl stop sendmail-client.service
- Warning: Stopping sendmail-client.service, but it can still be activated by:
- sendmail-client.path
- root@eagle:/etc > ps axf | grep sendmail
- 1496 ? Ss 0:00 sendmail: accepting connections
- 11555 pts/2 S+ 0:00 | \_ grep --color=auto sendmail
- 11534 ? Ss 0:00 sendmail: Queue control
- 11535 ? S 0:00 \_ sendmail: running queue: /var/spool/clientmqueue
Wie man sieht wird sendmail immer wieder sofort neu gestartet, obwohl ich dem systemctl explizit sage, dass er stoppen soll.
Was mache ich falsch?
-
Das "Hin" hat mit der gestrigen Version des Skripts schon gut geklappt, aber des "Her" (--back) noch nicht. Ich musste noch auf dem lokalen Rechner "mkinitrd" und "update-bootloader" aufrufen, damit das root-Volume erkannt wurde.
Hier eine neue Version, mit einigen weiteren Verbesserungen/Fixes.
Das --back dient dazu, die beiden Rechner "auszutauschen", d.h. jeder übernimmt die Rolle des anderen.
Was bei --back noch nicht funktioniert ist der Netzwerk-Adapter. Für "Hin" reichte ein
cp /etc/udev/rules.d/70-persistent-net.rules /mnt/etc/udev/rules.d
für das "Her" leider nicht. Da bin ich noch am Debuggen... -
Zum Abschluss noch die Erklärung, wozu ich das brauche.
Ich möchte meinen Haupt-Rechner dahingegend absichern, dass ich im Falle eines Hardwaredefekts so schnell wie möglich auf einen Backup-Rechner umsteigen kann. Das beiliegende Skript erledigt diese Aufgabe vollständig und automatisch, so dass im Fall der Fälle nichts übersehen werden kann. Ich lasse das jede Nacht laufen und kann so maximal einen Tag zurückfallen. Konkret muss ich momentan den Hauptrechner einem längeren Speichertest unterziehen, da er sich schon mehrmals urplötzlich aufgehängt hat, was vermutlich an einem defekten RAM liegt. Mit dem Skript kann ich alles schnell auf einen zweiten Rechner "umziehen", den ersten runter- und den zweiten mit dem kopierten System hochfahren und fertig.
Ich poste es nur der Vollständigkeit halber und für den Fall, dass sich jemand auch für sowas interessiert. Ich habe versucht, es so allgemein wie möglich zu gestalten, die Kommandos unter "Stop processes on HOST1" sind evtl. den lokalen Gegebenheiten entsprechend anzupassen.
Falls jemand einen Fehler entdeckt oder ich irgend etwas übersehen habe, bin ich natürlich für Rückmeldungen dankbar.
(Die ".txt" Extension ist nur wegen der Portal-Software)
Benutzung natürlich auf eigene Gefahr!
<edit>
Achtung: Neue Version im nächsten Post!
</edit>
-
Hab's gefunden: es fehlte noch der Aufruf von update-bootloader.
Jetzt bootet er das 15.3 System.
-
Die UUIDs müssten noch in der grub.cfg stehen und werden von mkinitrd angepast. Ich würde folgendes probieren...
Das hab ich jetzt gemacht und damit stehen die richtigen UUIDs in der /mnt/boot/grub2/grub.cfg.
Allerdings stehen in dieser Datei keine 'menuentry' Zeilen für Leap 15.3, sondern nur die für 15.0.
Beim Reboot wird mir aber 15.0 und 15.3 angeboten. Wähle ich dann 15.3, verhält es sich immer noch so wie oben beschrieben (Timeout und Not-Shell). Wie bekomme ich denn die menuentrys-Zeilen für 15.3 in die grub.cfg?
Nächster Stolperstein ist dann vermutlich die Datei /etc/udev/rules.d/70-persistent-net.rules wo der Netzwerkadapter per MAC Adresse gemappt wird
Da kann ich ja einfach diese Datei kopieren.
-
Ich mounte die Devices immer über Namen (/dev/sda1 etc.), nie über UUIDs. Von daher sollte es also schon passen.
Aber wer weiß, wo sonst noch UUIDs verwendet werden?
-
Ich habe einen PC ("PC1") mit openSUSE Leap 15.3, dessen System ich auf einen anderen PC ("PC2") (mit fast identischer Hardware) kopieren möchte. Auf dem anderen Rechner läuft openSUSE Leap 15.0.
PC1 hat das System in /dev/sda1, PC2 in /dev/sda2. /dev/sda3 ist auf beiden PCs als /boot/efi gemountet.
Auf PC2 ist /dev/sda1 als /sys1 gemountet.
Wenn ich auf PC1 folgendes mache
rsync -aHSx --numeric-ids --delete --force / PC2:/sys1
ssh PC2 update-bootloader
und dann PC2 boote, dann kann ich im Boot-Menü zwar das System in /dev/sda1 auswählen und es startet auch, kommt aber nicht weit. Irgendwann, nach längerem Timeout, kommt dann ein Prompt, das root-Passwort einzugeben und ich lande in einer Not-Shell.
Kann es sein, dass ich ausser update-bootloader noch etwas machen muss? Ramdisk neu generieren oder so? Die Devices haben natürlich andere UUIDs, kann es vielleicht daran liegen?
Ich möchte das Ganze per Script machen, um es im Falle eines Falles automatisch ablaufen lassen zu können.
-
Gibt es eigentlich einen Grund warum man das nicht im VDR bzw. in einer *.conf konfigurieren kann.
Es schien mir nicht notwendig. 1GB ist ja doch eine ganze Menge ;-).
Ich glaube der VDR prüft/löscht nur Aufnahmen wenn eine Aufnahme gestartet wird oder läuft.
Das ist richtig.
Wenn keine Aufnahme ansteht und die Festplatte läuft wie bei mir mit Non-VDR Daten unter das MinDISKSPACE dann kann die Platte voll sein bevor Aufnahmen gelöscht werden.
Ich finde es besser, wenn VDR seine eigene Platte bzw. Partition hat. Videos und andere Daten zu mischen ist keine gute Idee.
-
Sorry, falscher Parameter (mea culpa).
Du musst in recording.c das hier ändern:
#define MINDISKSPACE 1024 // MB
-
In der Datei recorder.c folgendes entsprechen erhöhen:
#define MINFREEDISKSPACE (512) // MB
-
Hab ich jetzt gemacht. Falls derjenige das hier liest kann er sich ja mit mir in Verbindung setzen.
-
Seit mindestens 15. April findet von der IP-Nummer 91.64.90.61 alle paar Minuten ein Download von git.tvdr.de statt:
Gut, kann man machen, muss man aber nicht.
Die IP-Nummer gehört zu Vodafone und ist in der Gegend Otterndorf in Niedersachsten beheimatet.
Hat vielleicht zufällig irgend jemand hier einen Job aufgesetzt, der das alle drei Minuten macht und irgendwie aus dem Ruder gelaufen ist?
-
Bitte testet mal beigefügten Patch. Ich hatte nur Zeit zu testen, ob er übersetzt, aber nicht, ob er auch funktioniert (würde es aber erwarten ;-).
Damit sollte jetzt auch zeitversetzte Wiedergabe wieder funktionieren.
-
@lnj: I think you're on to something here.
As a quick test, please apply this:
Display MoreDiff- --- recording.c 2022/01/24 10:44:21 5.14
- +++ recording.c 2022/04/23 09:38:22
- @@ -66,7 +66,7 @@
- #define DISKCHECKDELTA 100 // seconds between checks for free disk space
- #define REMOVELATENCY 10 // seconds to wait until next check after removing a file
- #define MARKSUPDATEDELTA 10 // seconds between checks for updating editing marks
- -#define MININDEXAGE 3600 // seconds before an index file is considered no longer to be written
- +#define MININDEXAGE 0 // seconds before an index file is considered no longer to be written
- #define MAXREMOVETIME 10 // seconds after which to return from removing deleted recordings
- #define MAX_LINK_LEVEL 6
This will prevent VDR from waiting for more index data in case a recording is still active.
If this solves the problem, I'll see how I can use the ".timer" file for this, which tells exactly whether or not a recording is still active.
