Beiträge von sg75

Hallo kauli,

ich nutze die Karte seit 1 1/2 Wochen erfolgreich mit DVB-C.
Firmware ist die von pbg4 vorgeschlagene.

Super, vielen Dank, funktioniert prima!

Ich habe doch mal einen Patch erstellt. Nur auskommentieren war dann doch auf die Dauer zu unbefriedigend ...

--- ../vdr-plugin-softhddevice.orig/openglosd.cpp	2017-03-05 10:50:23.219194449 +0100
+++ openglosd.cpp	2017-03-05 13:57:46.825618259 +0100
@@ -1703,7 +1703,11 @@
 }
 
 void cOglPixmap::DrawPixel(const cPoint &Point, tColor Color) {
-    esyslog("[softhddev] DrawPixel %d %d color %x not implemented in OpenGl OSD", Point.X(), Point.X(), Color);
+    cRect r(Point.X(), Point.Y(), 1, 1);
+    oglThread->DoCmd(new cOglCmdDrawRectangle(fb, r.X(), r.Y(), r.Width(), r.Height(), Color));
+    
+    SetDirty();
+    MarkDrawPortDirty(r);
 }
 
 void cOglPixmap::DrawBitmap(const cPoint &Point, const cBitmap &Bitmap, tColor ColorFg, tColor ColorBg, bool Overlay) {

rell: Saubere Arbeit!
Läd auf jeden Fall zum Experimentieren ein. Danke.

Aktuell läuft vdr4arch nicht auf meinem raspberry. Läuft nicht bedeutet konkret, schwarzes Bild - weder live noch Aufnahme - teilweise mit viel zu kleinem OSD.

Das Debuggen hat mich ein paar Stunden gekostet, hier der Patch für vdr/PKGBUILD:

--- PKGBUILD   2017-02-12 16:45:04.299923104 +0100
+++ ../../vdr4arch.org/vdr/PKGBUILD   2017-02-12 15:06:33.705360368 +0100
@@ -47,7 +47,7 @@
          '3565ca5ad9be5c75f66478f0796b120d'
          'dd20f932b846b5f50ac455b65e9432ad'
          '7cad811b4ac5ee6c0b5496d006f1e0ee'
-         '6c021358f299dca9ef7bbeb163312690'
+         '64979737d26758a75dda488b323c293c'
          '59ce04d1d01bf92bf6cfc0b74223191c')
 
 prepare() {
@@ -64,7 +64,7 @@
   sed -i 's/NULL, 0, true/NULL, 0, OpenSubMenus/g' "$srcdir/MainMenuHooks-v1_0_2.diff"
   patch -p1 -i "$srcdir/MainMenuHooks-v1_0_2.diff"
 
-#  sed -i '/define DEPRECATED_VIDEOSYSTEM/d' device.h
+  sed -i '/define DEPRECATED_VIDEOSYSTEM/d' device.h
   sed -i '/define DEPRECATED_VDR_CHARSET_OVERRIDE/d' vdr.c
   sed -i 's/libsystemd-daemon/libsystemd/g' Makefile
 }

DEPRECATED_VIDEOSYSTEM existiert seit vdr-2.2.0:
"The function cDevice::GetVideoSystem() has been deprecated and will be removed in a future version. In order to check whether a particular plugin needs to be modified if this function is removed, you can comment out the line #define DEPRECATED_VIDEOSYSTEM in device.h."

cDevice::GetVideoSystem() findet sich omxdevice.o

[sg75@rasp3 rpihddevice]$ nm omxdevice.o | grep GetVideoSystem
00000000 W _ZN7cDevice14GetVideoSystemEv

allerdings nicht in omxdevice.c

[sg75@rasp3 rpihddevice]$ cat omxdevice.[hc] | grep "GetVideoSystem" 
[sg75@rasp3 rpihddevice]$

Für einem rpihddevice-Patch hat es also aus Mangel an C++-Kenntnissen nicht gereicht ...

Hallo Bernd,

ich habe das Board vier Jahre lang produktiv als Haupt-VDR zusammen mit einer TT S2 6400 betrieben.
Zur Kompatibilität mit der DD Cine kann ich nichts sagen, aber drei DVB-S2-Tuner waren für die CPU kein Problem.
Zu xinelibout kann ich auch nichts sagen, aber softhddevice habe ich getestet - ging so.

VDPAU wird vom Radeon 6310 unterstützt - allerdings hatte ich dreieckige Tearing-Artefakte im oberen Drittel des Bildes.
Und die Reaktionszeit vom VDR war im Vergleich zur TT S2 6400 viel schlechter und zäher, wahrscheinlich weil die CPU viel mehr zu tun hatte.

Ich habe das Board noch im Keller rumliegen. Falls Du selbst testen willst, würde ich es Dir für 5€ plus Versand überlassen.

Viele Grüße
Christian

Danke für den Hinweis, sieht echt gut aus!

Leider steht nicht dabei, über welche Schnittstelle die Festplatte angebunden wird.
Wahrscheinlich wieder nur mäßig schnell über USB.

Wenn Du nur Programme starten und nichts an die neu gestarteten Programme streamen musst, schau dir mal die exec() Funktionenfamilie an:
https://linux.die.net/man/3/execvp

Damit kannst Du die Environment-Variablen sehr detailiert steuern.

Viel Erfolg
Christian

Klar, Du hast vollkommen recht. VDR kann nichts dafür, war aber in diesem Fall die einfachste Komponente, um das Problem zu fixen.

Der Atric-USB-Einschalter lässt sich nur am Windows-PC konfigurieren und ohne passenden Adapter auch nur an einer internen USB-Sockelleiste.

Nach fünf fehlgeschlagenen Versuchen, dass Teil richtig zu konfigurieren, die jedesmal mit einem Umbau vom VDR in den Windows-PC und zurück einhergingen, habe ich lieber die paar Zeilen in lirc.c gepatched....

Also, um den Patch richtig einzuordnen ...
Der soll auf keinen Fall in VDR aufgenommen werden, sondern nur den paar Benutzern des Atric-USB-IR-Einschalters helfen, die das gleiche "Konfigurationsproblem" haben

Hallo,

hier ist ein kleiner Patch für VDR 2.2.0, der das Problem bei mir behebt, dass der Atric-USB-IR-Einschalter den Eventzähler bei gedrückter Taste nicht hochsetzt.

Das Symptom äußert sich in irw so:

[sg75@vdr ~]$ irw
ffffd70200000000 00 KEY_ok Atric_IR-WakeupUSB
ffffd70200000000 00 KEY_ok Atric_IR-WakeupUSB
ffffd70200000000 00 KEY_ok Atric_IR-WakeupUSB
ffffd70200000000 00 KEY_ok Atric_IR-WakeupUSB
ffffd70200000000 00 KEY_ok Atric_IR-WakeupUSB

Korrekt wäre wenn die zweite Spalte immer um eins hochgezählt werden würde.
Im VDR leidet darunter die Bedienbarkeit sehr. Die Navigation durch die Menüs ist lahm und ruckelig.

Der folgende kleine Patch behebt das Problem, indem intern ein Zähler mitgeführt wird, wenn innerhalb von 150ms wiederholt gleiche Events mit count==0 ankommen.
Vielleicht hilft es ja dem einen oder anderen (bei mir hatte der WAF gelitten )

vdr-2.2.0_attric_usb_fakeCount.diff

Die aktuelle Version lirc-1:0.9.4.a-1-armv7h geht schon wieder nicht.
Nicht mal mode2 läuft diesmal.

Downgrade auf 0.9.3a hilft.

Kürzlich hat nach einem Systemupdate mit pacman -Syu mein vdr gestreikt.
Die Fehlermeldung war

Jul 05 19:10:56 rasp3 vdr[373]: [373] ERROR: libbcm_host.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden

libbcm_host.so liegt in /opt/vc/lib und irgendein Update hat diesen Pfad in /etc/ld.so.conf.d/00-raspberrypi-firmware.conf auskommentiert.

Die Lösung ist deswegen recht nahe liegend:
Das Kommentarzeichen vor /opt/vc/lib in /etc/ld.so.conf.d/00-raspberrypi-firmware.conf entfernen und

sudo ldconfig -v

nicht vergessen.

Ich melde auch Interesse an!

Zitat von louis

Ich würde dir raten, einfach einen modernen Skin zu benutzen. Dafür ist das OpenGL OSD eigentlich gedacht. Falls dich die Logmeldungen stören, kannst du alternativ auch einfach diese Zeile auskommentieren.

Dass wir immer noch SkinEnigmaNG nehmen, liegt eher nicht so an mir, als vielmehr an der besseren Hälfte
Sobald ich was anderes einstelle, sinkt der WA-Faktor O-Ton "neumodischer Kram ..."

Ich kommentiere erstmal die Zeile aus. Danke --- auch übrigens für das hardwarebeschleunigte OSD. Damit wird softhddevice richtig rund!

Hallo,
ich bin kürzlich von dvbhddevice (Technotrend S2-6400) auf softhddevice + lois' opengl patch (Geforce GT 710) umgestiegen.
Funktioniert soweit, allerdings wird das syslog überflutet mit:

Mai 13 12:24:45 vdr vdr[4440]: [4440] [softhddev] DrawPixel x y color z not implemented in OpenGl OSD...x, y und z variieren

Distribution: VDR4ARCH mit SkinEngimaNG.

SkinEngimaNG sieht minimal anders aus als mit softhddevice, deswegen gehe ich davon aus, dass die Meldung harmlos ist?

Weiß von euch vielleicht jemand, ob dieses über 10 Jahre altes Schätzchen USALS aka Goto X beherrscht?

[Blockierte Grafik: https://jab.ath.cx/Rotor.JPG]

Im Netz finde ich nicht wirklich was, außer dass es evtl. ein umgelabelter Stab sein könnte.
Und bevor ich die Tage mit Notebook+USB-DVB aufs Dach kraxel, würde ich schon gerne wissen, ob USALS geht.
"Nur" DiSEqC 1.2 wäre mir zu mühsam ...

Hast Du schon mit den Modulparametern vom Kernel-Treiber saa716x_ff gespielt?

modinfo saa716x_ff
filename:       /lib/modules/4.2.5-1-ARCH/extramodules/media-build-experimental-dkms/saa716x_ff.ko
license:        GPLauthor:         Manu Abraham
description:    SAA716x FF driver
alias:          pci:v00001131d00007160sv000013C2sd0000300Abc*sc*i*
alias:          pci:v00001131d00007160sv000013C2sd00003009bc*sc*i*
depends:        dvb-core,saa716x_corever
magic:       4.2.5-1-ARCH SMP preempt mod_unload modversions
parm:           phi_mode:phi access mode: 0 - default, slow single word accesses; 1 - faster phi clock; 2 - fastest mode, use write-combining (int)
parm:           verbose:verbose startup messages, default is 1 (yes) (int)
parm:           int_type:force Interrupt Handler type: 0=INT-A, 1=MSI, 2=MSI-X. default INT-A mode (int)
parm:           int_count_enable:enable counting of interrupts (int)
parm:           video_capture:capture digital video coming from STi7109: 0=off, 1=one-shot. default off (int)

Meine 6400 läuft zufriedenstellend mit:
modprobe saa716x_ff phi_mode=0 int_type=1 verbose=1 video_capture=0

Der Parameter int_type könnte der Entscheidende sein.

Die neuste LIRC version "lirc 1:0.9.3.a-1" behebt das Problem bei mir.

Hallo gehlhajo,

evtl. bist du auch von diesem Bug im aktuellen lirc in archlinux betroffen:
archlinux lirc bug in version 0.9.3

Viele Grüße
sg75

Einfach CodecID in AVCodecID umbenennen, dann sollte es wieder mit ffmpeg komplilieren.
Ich hab allerdings nur erfolgreich kompliliert (auf ARCH Linux mit ffmpeg version 2.8.1), aber noch nicht auf Funktionsfähigkeit getestet.

--- omxtx.c~    2015-10-28 14:48:26.000000000 +0100
+++ omxtx.c     2015-10-28 14:51:02.865771144 +0100
@@ -278,7 +278,7 @@






-static int mapcodec(enum CodecID id)
+static int mapcodec(enum AVCodecID id)
 {
        printf("Mapping codec ID %d (%x)\n", id, id);
        switch (id) {