Beiträge von Urig

Der Wert an Adresse 0x3E ist MIN_GNT, der an 0x3F ist MAX_LAT. MIN_GNT gibt an, mit wie langen Burst-Zugriffen der Karte auf den PCI-Bus das System rechnen muss, MAX_LAT gibt an, wie lange das Anfordern des Bus-Zugriffs maximal dauern darf. Diese Werte dienen dem PCI-System (PCI-Treiber?) dazu, die Zugriffsprivilegien auf den Bus an den Bedarf (Reaktionszeit, Durchsatz) anzupassen.

Der SAA7146-Chip liest diese Werte aus dem eeprom an den Adressen 0x04 (MAX_LAT) und 0x05 (MIN_GNT). Technotrend-Karten verwenden normalerweise die Default-Werte MAX_LAT=0x26, MIN_GNT=0x0F. Obwohl ich mit den falschen FF-Werten keine negativen Erfahrungen gemacht habe, könnte es abhängig von Betriebssystem oder Board durchaus Seiteneffekte geben.

Da diese 6 Werte aus der PCI-Konfiguration FF sind, tippe ich auch darauf, dass auch das restliche eeprom keine sinnvollen Daten enthält. (steht im Syslog die DVB MAC-Adresse FF:FF:FF:FF:FF:FF?) Zumindest unter Linux hat das glaube ich keine Auswirkungen.

Gruß,

Udo

Die Welt ist doch klein....

Wie genau ich meine Karten wieder in Betrieb genommen habe, ist hier im Board dokumentiert, unter Anderem hier:
http://www.vdrportal.de/board/thread.php?threadid=25462&page=2

Wie auf der Seite beschrieben, bekommt man die Subvendor-ID mit lspci -x -d 1131:7146 heraus. In dessen Ausgabe steht ab Adresse 2c die ID. Steht dort zb. c2 13 01 00, so korrespondiert das in den alten Treibern mit der folgenden Zeile der Datei driver/av7110/saa7146_core.c:

{ PHILIPS_SAA7146, 0x13c2, 0x0001, CARD_INFO tt_1_6 },

In den neueren Treibern befindet sich der gleiche Eintrag unter drivers/media/dvb/ttpci/av7110.c:

MAKE_EXTENSION_PCI(tt_1_6, 0x13c2, 0x0001),

Um die Sache nicht zu einfach zu machen, im eeprom selbst steht in diesem Fall die Bytefolge 00 01 13 c2.

Die einfachste Methode zum Ausprobieren besteht darin, die in der lspci-Ausgabe gefundene ID in den Treiber mit aufzunehmen. Wenn dann mit den modifizierten Treibern die Karte funktioniert, kann man über das Patchen des eeproms nachdenken.

Gruß,

Udo

Vorweg: Video-Streaming reagiert sehr empfindlich auf Netzwerkstörungen jeder Art. Kurze Stockungen im Datenverkehr, verlorengegangene Datenpakete - das alles bemerkt man bei normaler Netzwerkbenutzung kaum. Bei Videostreaming führt das sehr schnell zu Störungen.

Probier erst mal folgendes: Schreib die umkodierten Videodaten per access=file in eine Datei, und kopier diese auf den VDR-Rechner. Von dort aus kannst du dann mit einem weiteren VLC diese Datei zum streamplayer weiter streamen, ohne sie nochmals zu transkodieren. Wenn die Datei lokal sauber gestreamt wird, kannst du sicher von Netzwerkproblemen ausgehen.

Bei wackeligen Netzwerken hat man die Quahl der Wahl: HTTP wird häufig stocken, wenn die Verbindung nicht sauber ist, UDP dagegen wird mehr Störungen im Bild erzeugen.

Das Problem der Bild/Ton Asynchronität ist eins der DVB-Karten. So bald es zu Stockungen oder Ungleichmässigkeiten der Datenübertragung kommt, sind Bild und Ton schnell asynchron. Man kann das gelegentlich bei VDR-Aufnahmen beobachten, machmal sogar bei Live-TV. Beim Streaming kommt es am stärksten vor.

Für HTTP-Streaming kann eventuell ein größerer Puffer helfen: Einfach in der player.h die RCVBUFFERSIZE von 1024*1024 (1Mb) auf einen höheren Wert hochsetzen.

Zu 16:9: Wie ich in der Doku schon geschrieben hab, 16:9 ist noch problematisch, da das Video für streamplayer 4:3 sein muss, und VLC (noch) nicht in der Lage ist, die dafür notwendigen schwarzen Balken anzufügen.

Steuern des Servers geht wohl über rtsp-Protokoll. Irgendwann werd ich auch da noch ein wenig tiefer nachforschen.

UDP ist vollkommen blind, der Server weiss nicht mal, ob ein Client die Daten entgegen nimmt. Und http hat auch keinerlei Kontrollmöglichkeit über den Server.

Hi.

Hiermit veröffentliche ich die erste öffentliche Version meines Plugins 'Streamplayer':

Streamplayer ist ein Plugin, um Netzwerk-Streams mit VDR zu empfangen und anzuzeigen, wodurch VDR zum Streaming-Client wird. Das Plugin ist absichtlich auf DVB-Kompatible MPEG1/2-Streams beschränkt, die ohne große CPU-Last angezeigt werden können. Ein möglicher Stream Server ist der VLC media player, ein anderer ist der HTTP Server des Streamdev Plugins.
Streamplayer unterstützt UDP streaming und HTTP streaming, basierend auf dem MPEG Transport Stream (TS) Protokoll.

Streamplayer-0.0.1 sollte auf VDR Version 1.2.6 - 1.3.20 funktionieren, und steht auf meiner Homepage zur Verfügung:
http://urichter.cjb.net/vdr/index.html

Gruß,

Udo

Ihr schiesst hier wieder mit Spatzen auf Kanonen...

sed -n -e "s/^\(.*\) [a-zA-Z]* hddtemp.* \([0-9]*\) C$/\1 \2 C/p" /var/log/daemon.log | tail -n 5

Der Reihe nach erklärt:
^ - Zeilenanfang
\(.*\) - das Datum als \1
[a-zA-Z]* - der Rechnername 'mona' o.ä.
hddtemp - Filtert die benötigten Zeilen
.* - überspringt den unnötigen Teil
\([0-9]*\) - die Zahl als \2
C - das C
$ - Zeilenende.

Die Ausgabe \1 \2 C ist dann das, was wirklich ausgegeben wird. Mit leichten Variationen kann man so jeden Teil der Zeile einzeln fangen und alles neu zusammen setzen.

... und weiter zu 1.3.19:

mplayercluster-0.0.1a-Urig4.diff.gz
- Kompatibel zu 1.2.6 - 1.3.19

http://urichter.cjb.-net/vdr/

Gruß,

Udo

osdpip-0.0.7.1 für vdr-1.3.19.

Nochmal osdteletext, diesmal basierend auf 0.4.1, dem patch von LordJaxom, diesem threadsafe-Patch aus der ML und einer Anpassung an 1.3.19.

Als Anmerkung: Mit dem Patch kompilieren erst mal wieder folgende Plugins in den 1.3.18-Versionen:

osdteletext
femon
osdpip
mplayercluster

streamdev habe ich nicht getestet, ist aber auch ein heisser Kandidat.

Gruß,

Udo

Ich lasse das remote-Plugin selbst seine eigene key-Datei laden, und hatte bisher keine Probleme. Nur wer mehrere RC5-Adressen braucht (kein av7110_loadkeys -a #) muss glaube ich selbst laden. (oder den Treiber patchen, wie ich.)
(vdr-1.3.18, remote-0.3.3)

Und wieder mal ein kleines Update:
mplayercluster-0.0.1a-Urig3 ist nun voll kompatibel zu VDR-1.3.18:

FIX: Kompatibel zu VDR 1.3.17-Poison, thread-safe fix
FIX: Kompatibel zu VDR 1.3.18
FIX: Änderungen von Urig2-Patch durch Kompatibilitäts-Layer für VDR 1.2.6-1.3.18 ersetzt.
FIX: Einige Warnungen

Ab jetzt immer hier zu finden:
http://urichter.cjb.net/vdr

Gruß,

Udo

> das Laden scheitert halt mit Fehlermeldung. Aber ich krieg das schon noch hin...

Wie lädst du den Treiber? Mit dem übliche make rmmod und make insmod?
Was genau gibts denn an Fehlern? Eventuell noch was in /var/log/syslog?
Hast du deine Karten-ID in die driver/av7110/saa7146_core.c eingetragen, damit er den Treiber auch für deine Karte lädt?

Gruß,

Udo

Die DVB-Treiber sind in der 2.4er 2003-11-08 Version noch recht pflegeleicht zu übersetzen. Dauerhaft installieren brauchst du sie ja nicht mal, einmal das richtige Modul laden genügt schon.
Ohne diesen Aufwand wirst du keinen Erfolg haben, der DVB-Treiber lädt nur, wenn er eine bekannte ID in dem eeprom findet. (die muss auch in den gepatchten Treiben eingebaut werden.)

Die einzige Alternative wäre ein externes Schreiben des eeproms. Vermute, dazu ist mindestens das Auslöten nötig.

Gruß,

Udo

Danke!

Gleicher Patch, nur auf femon-0.1.7 ausgeweitet:

Ich enttäusche euch nur ungern...

Das Remote-Plugin greift über den DVB-Treiber zu, und der hat leider nur zwei Betriebsarten: Entweder er beachtet genau eine der 32 RC5-Adressen, oder er ignoriert die RC5-Adresse vollständig und vermischt so die Fernbedienungen zu einer gemeinsamen - mit überlappenden Tastenbelegungen.

Will man wirklich zwei Fernbedienungen nutzen, muss man an den Treibern rumpatchen. Für die Medion-Fernbedienung wurde das gemacht, da bei der nie alle Tasten zur gleichen RC5-Adresse gehören.

Ähnliches macht der settime-patch, siehe http://www.vdrportal.de/board/thread.php?threadid=4377
Die Version für 1.3.11 funktioniert auch unter 1.3.17 noch, nur mit den 'poison'-Patches gibt es eine (leicht zu behebende) Kollision.

Zum Beispiel könnte jemand auf die Idee kommen, vom Root-Verzeichnis aus dev/hda1 anzugeben, dann würde einfaches Verkürzen gleich wieder dev/hda1 ausgeben. Aus /././dev/hda1 wird /././dev. Oder sonst irgend ein harmloser Dateiname, der durch kürzen zu etwas kritischerem wird - ich weiss ja nicht, was du dann damit vor hast...

Etwas mehr Vorsicht ist vielleicht sinnvoll, wenn man schon mit Platten-Devices rumfummelt, da lohnt sich auch mal eine Namensprüfung:

if [ -z ${default_var[0]##/dev/[hs]d[a-z]*} ] ; then echo ${default_var[0]:0:8} ; fi

Diese Variante akzeptiert nur /dev/hd? und /dev/sd? mit mindestens einem weiteren Buchstaben.

prefect:
Deine Nachricht war bei mir per Mail angekommen, und die Antwort ging Donnerstag abend noch an deine hier hinterlegte gmx.li Mailadresse raus. In dem Postfach schon nachgeschaut?

Ok, die ersten Schritte sind ja schon gemacht. Wie schon gesagt, der obige Patch (rev. 0.2) für die 2003-11-08 Treiber tut genau das. Schreiben war mir damals zu brisant, um es per default an zu lassen. Schliesslich lädt der Treiber nicht mehr, wenn man eine falsche ID rein brennt. Durch entfernen des Kommentars um #define eeprom_write_allow wird er aber 'scharf'.

Auslesen geht so:
cat /proc/dvb-eeprom0 > /tmp/eeprom.bin

Schreiben geht so:
echo set base 0 > /proc/dvb-eeprom0
cat /tmp/eeprom.bin > /proc/dvb-eeprom0

Das "set base 0" ist eine weitere Sicherheitsmassnahme, ohne diese Zeile wird nur in den ungenutzten Bereich hinter 256 geschrieben.

In der eeprom.bin musst du dann die richtige ID per Hexeditor einbauen.
10 02 13 ff 26 0f ff ff müsste bei dir am Anfang stehen, 10 02 13 c2 26 0f ff ff klingt nach einer guten Änderung...

Gruß,

Udo