Device Bonding und Polarisation -> vertikale Sender nicht möglich

kls · 6. April 2013

Zitat von 447377

- In VDR's Make.config:
DVBDIR = /usr/local/src/media_build_experimental/linux/include/

Da musst du noch "uapi" dranhängen, also:

DVBDIR = /usr/local/src/media_build_experimental/linux/include/uapi

Zitat

Und die runvdr sieht wie folgt aus:
...
# Load all DVB driver modules needed for your hardware:
function LoadDriver()
{
/sbin/modprobe dvb_ttpci # S2300 ff
/sbin/modprobe ddbridge
}

# Unload all DVB driver modules loaded in LoadDriver():
function UnloadDriver()
{
/sbin/modprobe -r dvb_ttpci
/sbin/modprobe -r stv0299
/sbin/modprobe -r ddbridge
/sbin/modprobe -r lnbp21
}
...

Alles anzeigen

Du hast den Treiber schon auch *installiert*, oder?

Klaus

447377 · 6. April 2013

Hänge ich uapi hinten dran, dann kompiliert er die Ausgabe-Plugins nicht - siehe unten.
Dann könnte ich zwar ein ln -s /usr/src/linux/include/linux/compiler.h linux/compiler.h im uapi-Verzeichnis setzen, damit es kompiliert, aber mein Problem löst das trotzdem nicht.

Die Original Suse-Module habe ich entfernt und dann neu kompiliert UND installiert.

Gruß,
Stefan

*** Plugin dvbhddevice:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbhddevice.o dvbhddevice.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbhddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbhdffdevice.o dvbhdffdevice.c
In file included from dvbhdffdevice.c:13:0:
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:62:28: fatal error: linux/compiler.h: No such file or directory
compilation terminated.
make[1]: *** [dvbhdffdevice.o] Error 1

*** Plugin dvbsddevice:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbsddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbsddevice.o dvbsddevice.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbsddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbsdffdevice.o dvbsdffdevice.c
In file included from dvbsdffdevice.c:12:0:
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:62:28: fatal error: linux/compiler.h: No such file or directory
compilation terminated.
make[1]: *** [dvbsdffdevice.o] Error 1

UFO · 6. April 2013

Zitat von 447377

Hänge ich uapi hinten dran, dann kompiliert er die Ausgabe-Plugins nicht - siehe unten.

Ohne "uapi" kompilierst Du VDR nicht gegen media_build_experimental, sondern gegen den Kernel. D.h. VDR geht von einem anderen Treiber aus als später geladen wird. Keine gute Idee...

Um festzustellen, ob gegen die Header des Kernels kompiliert wird, kann man z.B.

Code

#error Versuch, gegen Kernel zu kompilieren

in /usr/include/linux/dvb/frontend.h einfügen.

Zitat

Dann könnte ich zwar ein ln -s /usr/src/linux/include/linux/compiler.h linux/compiler.h im uapi-Verzeichnis setzen, damit es kompiliert, aber mein Problem löst das trotzdem nicht.

Versuche es mit

Code

touch .../media_build_experimental/linux/include/uapi/linux/compiler.h

Dies erzeugt eine entsprechende Dummydatei.

Zitat

Die Original Suse-Module habe ich entfernt und dann neu kompiliert UND installiert.

Ok.

CU
Oliver

447377 · 6. April 2013

Irre, frontend.h habe ich ergänzt und es hagelte Fehler...

Also habe ich Make.config um uapi angepasst:
DVBDIR = /usr/local/src/DVB/linux/include/uapi

cd /usr/local/src/DVB/linux/include/uapi/linux
touch compiler.h -> Fehler, siehe unten

ln -s /usr/src/linux/include/linux/compiler.h compiler.h
-> VDR wird gebaut und läuft, jedoch mein Bonding-Problem besteht weiterhin, wenn Tuner 0 der Cine der Master ist, dann gehen die Sender vertikal high nicht.

Gruß,
Stefan

*** Plugin dvbsddevice:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbsddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbsddevice.o dvbsddevice.c
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/local/src/DVB/linux/include/uapi -c -DPLUGIN_NAME_I18N='"dvbsddevice"' -I/usr/local/src/vdr-2.0.0/include -o dvbsdffdevice.o dvbsdffdevice.c
In file included from dvbsdffdevice.c:12:0:
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:767:19: error: field ‘__user’ has incomplete type
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:767:19: error: expected ‘;’ at end of member declaration
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:767:27: error: ISO C++ forbids declaration of ‘next’ with no type [-fpermissive]
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:774:19: error: expected ‘;’ at end of member declaration
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:774:27: error: ISO C++ forbids declaration of ‘clips’ with no type [-fpermissive]
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:776:9: error: variable or field ‘__user’ declared void
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:776:9: error: expected ‘;’ at end of member declaration
/usr/local/src/DVB/linux/include/uapi/linux/videodev2.h:776:17: error: ISO C++ forbids declaration of ‘bitmap’ with no type [-fpermissive]
In file included from dvbsdffdevice.c:15:0:
/usr/local/src/DVB/linux/include/uapi/linux/dvb/video.h:157:7: error: expected ‘;’ at end of member declaration
/usr/local/src/DVB/linux/include/uapi/linux/dvb/video.h:157:15: error: ISO C++ forbids declaration of ‘iFrame’ with no type [-fpermissive]
/usr/local/src/DVB/linux/include/uapi/linux/dvb/video.h:190:7: error: expected ‘;’ at end of member declaration
/usr/local/src/DVB/linux/include/uapi/linux/dvb/video.h:190:15: error: ISO C++ forbids declaration of ‘palette’ with no type [-fpermissive]
dvbsdffdevice.c: In member function ‘virtual void cDvbSdFfDevice::StillPicture(const uchar*, int)’:
dvbsdffdevice.c:724:43: error: invalid conversion from ‘char*’ to ‘char’ [-fpermissive]
dvbsdffdevice.c:724:43: error: invalid conversion from ‘int’ to ‘int*’ [-fpermissive]
dvbsdffdevice.c:730:54: error: invalid conversion from ‘char*’ to ‘char’ [-fpermissive]
dvbsdffdevice.c:730:54: error: invalid conversion from ‘int’ to ‘int*’ [-fpermissive]
make[1]: *** [dvbsdffdevice.o] Error 1

UFO · 6. April 2013

Zitat von 447377

Irre, frontend.h habe ich ergänzt und es hagelte Fehler...

Also habe ich Make.config um uapi angepasst:
DVBDIR = /usr/local/src/DVB/linux/include/uapi

cd /usr/local/src/DVB/linux/include/uapi/linux
touch compiler.h -> Fehler, siehe unten

Bei leerer compiler.h hilft i.d.R. folgendes in Make.config:

Code

CFLAGS  += -D__user= -D__u8=uint8_t
CXXFLAGS += -D__user= -D__u8=uint8_t

Deine Alternative geht auch (und ist die bessere Variante - sofern die Kompilierung durchläuft):

Zitat

ln -s /usr/src/linux/include/linux/compiler.h compiler.h
-> VDR wird gebaut und läuft,

Zitat

jedoch mein Bonding-Problem besteht weiterhin, wenn Tuner 0 der Cine der Master ist, dann gehen die Sender vertikal high nicht.

Dafür habe ich keine Erklärung. -> Signale mit dem Oszi anschauen.

Ein Vertauschen der beiden Kabel direkt an der Cine läßt den Fehler nicht wandern? Ein Defekt des Verteilers oder des Kabels wäre für mich die plausibelste Erklärung. Hattest Du jedoch iirc schon getestet.

CU
Oliver

447377 · 7. April 2013

Wenn Tuner 0 der Master ist, dann geht's nicht. Also habe ich die Reihenfolge der Tuner beim Laden des Moduls geändert - siehe unten. Leider wird beim Betrieb der Master gewechselt. Mir fiel im Log dabei folgender Eintrag auf:

Code

ERROR: TS packet not accepted in Transfer Mode

Was ist hier los?

Gruß,
Stefan

vi /etc/modprobe.d/dvb-load.conf

Zitat

# TT FF Karte
options dvb_ttpci adapter_nr=0

# DD cine S2 V6 Dual
options ddbridge adapter_nr=2,1

447377 · 7. April 2013

Korrektur zum Beitrag eben:
Ich hatte versehentlich das Device-Bonding im VDR-Menü nicht korrekt nachgezogen. Jetzt klappt alles wunderbar!

Klaus und Oliver: Euch vielen Dank für Eure geopferte Zeit und Euren Beistand!

Die Ergebnisse der Messung mit dem Oszilloskop werde ich Ende kommender Woche nachreichen - seit meinem Studium hatte ich kein Oszi mehr in den Händen...

Grüße,
Stefan

447377 · 21. April 2013

Nun zum Ergebnis der Messung:
- Bei 13 V lieferte der eine Tuner kein sauberes 22 kHz-Signal. Die Frequenz war entweder zu niedrig oder durch weitere Signale überlagert.
- War der andere Tuner der Master, dann klappte es, da der kritische Tuner MEISTENS keine Frequenz bzw. kein Signal erzeugte. Doch immer mal wieder kam eine "Welle", dann wurde alles gestört, der VDR änderte den Master-Tuner (auf den krit.) und die bestimmten Sender konnten nicht mehr eingestellt werden.

Also Mail an linux4media, RMA-Nummer erhalten, die Karte am Do. hingeschickt und eine neue bereits am Sa. erhalten (wahnsinn, die sind schnell).
Die Karte eingebaut und: Es läuft...

Klaus und Oliver: Vielen Dank für Eure Unterstützung und Eure für mich geopferte Zeit!!!

Was mir im Log noch aufgefallen ist:
ERROR: TS packet not accepted in Transfer Mode
Aufnahmen scheinen i.O. zu sein, also kommt die Meldung vermutlich von der SD full-feature-Karte. Aufgefallen ist mir das bei Sat1, Pro7 und Kabel1. Die anderen Kanäle sind fehlerfrei. Was ist das noch?

Gruß,
Stefan

UFO · 21. April 2013

Zitat von 447377

Nun zum Ergebnis der Messung:
- Bei 13 V lieferte der eine Tuner kein sauberes 22 kHz-Signal. Die Frequenz war entweder zu niedrig oder durch weitere Signale überlagert.
- War der andere Tuner der Master, dann klappte es, da der kritische Tuner MEISTENS keine Frequenz bzw. kein Signal erzeugte. Doch immer mal wieder kam eine "Welle", dann wurde alles gestört, der VDR änderte den Master-Tuner (auf den krit.) und die bestimmten Sender konnten nicht mehr eingestellt werden.

Also Mail an linux4media, RMA-Nummer erhalten, die Karte am Do. hingeschickt und eine neue bereits am Sa. erhalten (wahnsinn, die sind schnell).
Die Karte eingebaut und: Es läuft...

Interessanter Defekt.

Zitat

Was mir im Log noch aufgefallen ist:
ERROR: TS packet not accepted in Transfer Mode
Aufnahmen scheinen i.O. zu sein, also kommt die Meldung vermutlich von der SD full-feature-Karte. Aufgefallen ist mir das bei Sat1, Pro7 und Kabel1. Die anderen Kanäle sind fehlerfrei. Was ist das noch?

VDR versucht, Daten an die FF-Karte zu senden, die sie nicht aufnehmen kann.

Falls es nur beim Kanalwechsel auftritt, kann man es ignorieren.

CU
Oliver

447377 · 21. April 2013

Leider treten die Fehler nicht nur beim Kanalwechsel auf. Manchmal fällt es gar nicht auf, manchmal flackert das Bild kurz und der Ton pausiert. Oft 15 Minuten nichts, dann im Minutentakt.
Lässt sich das irgendwie verbessern?
Die ff-Karte habe ich auch schon getauscht.

Gruß,
Stefan

kls · 27. April 2013

Versuch doch bitte mal folgendes:

Diff

--- dvbdevice.c 2013/04/09 13:22:24     3.1
+++ dvbdevice.c 2013/04/27 10:40:59
@@ -697,7 +697,7 @@
 
 void cDvbTuner::ResetToneAndVoltage(void)
 {
-  CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13));
+  CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, bondedTuner ? SEC_VOLTAGE_OFF : SEC_VOLTAGE_13));
   CHECK(ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF));
 }

Klaus

447377 · 28. April 2013

Hallo Klaus,

danke für Deinen Vorschlag, der leider nichts geändert hat.
Mein VDR nimmt übrigens alles korrekt auf. Das betrifft nur die Live-Wiedergabe von Sendern der ProSiebenSat.1-Gruppe (12544 MHz), die so keinen Spaß machen.
Aufnahmen dieser Sender werden übrigens korrekt wiedergegeben. Mit Timeshift und minimalem Versatz geht auch alles.
Sender höherer Frequenzen gehen übrigens auch.

Und dann wieder: mit easyVDR 1.0 und gleicher Kanalliste werden diese Sender ohne Fehler wiedergegeben. Alles mit gleicher Hardware. Was läuft hier anders?
Mit dem Laden der Module bzw. der Reihenfolge und der Parameter konnte ich leider keine Erfolge erzielen.

Schließe ich einen Technisat Mini Router an - SCR statt Bonding - verursachen die Sender von ProSiebenSat.1 auch Probleme.

Was ist hier nur los?

Grüße,
Stefan

447377 · 22. Mai 2013

Mittlerweile geht's. Nur ob das wohl so i.O. ist?
Auf der Suche nach der Quelle der Ausgabe von "ERROR: TS packet not accepted in Transfer Mode" fand ich die Datei transfer.c - dort war eingetragen:
#define MAXRETRIES 5 // max. number of retries for a single TS packet
#define RETRYWAIT 5 // time (in ms) between two retries

Die MAXRETRIES setzte ich auf 20 hoch und siehe da, keine Störungen mehr.

Dann fiel mir meine alte vdr 1.7.31-Installation auf. Hier war 100 und 10 eingetragen.
- Wieso wurde das so drastisch reduziert?
- Hat das Hochsetzen irgendwelche negativen Folgen?
Gehe ich richtig der Annahme, dass das eine Art Puffer für die Ausgabe ist, die nach einer bestimmten Anzahl alles verwirft (-> Bild- und Tonstörungen als Ergebnis) und dann wieder von vorne beginnt?
Weshalb habe ich das fast nur bei Sendern der Pro7-Gruppe? Bei Sat.1 ist es besonders auffällig. Senden die nicht ganz korrekte Audio-Daten? Aber: Aufnahmen sind alle i.O.

Vielleicht kann mich hier jemand aufklären und mich nicht mehr in der Unwissenheit belassen.

Grüße,
Stefan

avjui · 22. Mai 2013

Zitat von 447377

Dann fiel mir meine alte vdr 1.7.31-Installation auf. Hier war 100 und 10 eingetragen.
- Wieso wurde das so drastisch reduziert?
- Hat das Hochsetzen irgendwelche negativen Folgen?
Gehe ich richtig der Annahme, dass das eine Art Puffer für die Ausgabe ist, die nach einer bestimmten Anzahl alles verwirft (-> Bild- und Tonstörungen als Ergebnis) und dann wieder von vorne beginnt?
Weshalb habe ich das fast nur bei Sendern der Pro7-Gruppe? Bei Sat.1 ist es besonders auffällig. Senden die nicht ganz korrekte Audio-Daten? Aber: Aufnahmen sind alle i.O.

Scheint wohl in der 1.7.36 eingeflossen zu sein.
Als Grund steht in der History

Zitat

- Reduced the number of retries in cTransfer::Receive() to avoid blocking recordings
in case the primary device can't handle the current live signal.

Ob das jetzt dich betrifft weiß ich nicht.

mfg

Device Bonding und Polarisation -> vertikale Sender nicht möglich

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema