Beiträge von Nano

cinfo:

guck doch mal, ob es schon etwas bringt, wenn Du "compat.h" aus meinem Paket austauscht gegen die Version hier:

http://linuxtv.org/hg/v4l-dvb/log/tip/v4l/compat.h

Ich sehe dort nämlich einige"Compilation fixes" für neuere Kernel.

Zitat

Original von Razorblade
Wie wäre denn ein diff mit Deinen Änderungen gegenüber dem "vanilla" dvbloop mit dem Du angefangen hast?
Dann läßt sich das evtl leichter auf neuere Versionen anpassen...

Das Problem ist, dass ich mich mit dem Bauen von Kernel-Modulen nicht so gut auskenne. Ich muss z.B. sicherstellen, dass dvbloop nur die includes aus "meinem" S2API-dvbcore sieht und nicht die des Kernels.

Darum habe ich quasi nur die Quellen von dvbloop genommen, aber das gesamte Build-System (Makefiles, etc.) der S2API-Quellen. Fand ich besser.

Ich werde es wohl so machen, dass vor dem Kompilieren die nötigen Sachen aus dem Repo geholt werden (können). So hat man immer das aktuelle dvbcore Modul, um das es ja hauptsächlich geht und mit dem dvbloop harmonieren muss.

Also kurz: ein einfaches Diff macht eigentlich keinen Sinn.

Ich sehe gerade, dass die linuxtv-Jungs auch das von KLS vorgeschlagene Flag "FE_CAN_2G_MODULATION" aufgenommen, leicht umbenannt. Von daher mache ich mal ein neues dvbloop-s2api Paket fertig.

Vielleicht sollte ich das mal irgendwie automatisieren. Mal schauen.

Zitat

Original von cinfo
Hallo,

hat jemand eine dvbloop Quellen für de Kernel 2.6.28 [S2API] der sich
auch übersetzen letzt?

Nano
leider bekomme ich den dvbloop auf dem Kernel 2.6.28 mit Deinen Quellen
nicht erstellt.
Hast Du schon einmal Deine Quellen unter dem Kernel 2.6.28 getestet?

Alles anzeigen

Nope. Ich habe hier "nur" 2.6.24. Der Standard-Kernel von Ubuntu 8.04 (hardy). Ich schaue mir mal die aktuellen S2API Quellen an und gucke, was die da geändert haben.
Was bekommst Du denn für einen Fehler?

Razorblade:
Ja, hab noch 4 Stecker inkl. Crimpkontakte übrig. Schreib mir eine PN mit Deiner Adresse.

Zitat

Original von real_schorsch
"Gibt es irgendwo noch ein ChangeLog, was sich in der Netceiver-Firmware geändert hat?"

Jedesmal vor lauter Hektik total vergessen... Die 8AV hat im wesentlichen nur SW-Änderungen. Hauptsächlich den GotoX-Rotor-Support und das (noch nicht ganz vollständige) Poweroff der Tuner nach einiger Zeit der Nichtbenutzung. Desweiteren läuft jetzt ein HW-Watchdog, der beim Absturz der Firmware einen Neuboot macht. Und dann blinken die beiden Tunerleds auch im Betrieb, um die Diagnose zu erleichtern.

Ok, ich hab's mal in Kurzform auf die erste Seite gepackt.

Zitat

Original von kris
UPDATE
Nano, kannst Du auf der ersten Seite noch die Updatequelle für die Netceiver-Firmware legen?

folgender Befehl legt im derzeitgen Ordner einen Ordner "netcv" an mit der aktuellen Stable

Code

svn co svn://reelbox.org/stable/packages/netceiver-firmware/ROOT/usr/share/reel/netcv/update netcv

Hi,

jo, mache ich gleich.

real_schorsch:
Gibt es irgendwo noch ein ChangeLog, was sich in der Netceiver-Firmware geändert hat?
Im Reel-Forum wird die Liste leider wohl nicht mehr gepflegt.

Gruß
Nano

Kurzes Update von meiner Seite:

Ich habe momentan den VDR-1.7.2 mit dem aktuellen H.264 Patch von R.Nissl, streamdev-cvs und meiner dvbloop-s2api-Anpassung mit meiner PS3 laufen. Die PS3-UPnP Geschichte mit Mediatomb habe ich so eingerichtet, wie es in einem aktuellen Thread hier im Forum beschrieben wird.

Ich hätte nie gedacht, dass das so gut läuft mit der PS3.
Ein sehr sehr gutes Bild. HD (anixeHD, arteHD, astraHD, etc.) kein Problem.
Klar, das Zappen dauert natürlich recht lang. Aber zum gezielten Angucken ist es okay, finde ich.

giga-san

Ist eine spezielle Firmware-Version auf der PS3 von Nöten bzw. welche nutzt Du?

Moin,

hat das jemand mal getestet inzwischen?

Bitte nochmal herunterladen.

Ich hatte das Paket doch nicht aus den ganz aktuellen v4l-dvb Quellen geschnürrt.

Jetzt ist wirklich alles auf dem aktuellen Stand.
SYS_DSS ist in den aktuellen Quellen doch drin und somit auch kein Bug an der Stelle im VDR.

So.

Es ist vollbracht.

Hier könnt ihr die S2API Version des dvbloop-Moduls herunterladen.
Ich habe vor zwei Tagen die aktuellen S2API -Quellen aus dem hg Repo ausgecheckt und das dvbloop-Modul hierfür angepasst.

Ich habe quasi alles rausgeschmissen bis auf dvb-core und dvbloop.

Einfach auspacken und "make" sollte genügen. Zumindestens die Kernel-Header sollten installiert sein.

Dann einfach "make load" bzw. "make debug" oder "make unload".
"make debug" schraubt den Debug-Level der beiden Kernel-Module hoch.

Leider musste ich es extern hochladen, da es mehr als 50k sind.
http://www.file-upload.net/dow…vbloop-s2api.tar.bz2.html

Ich hatte es gerade kurz getestet. Sowohl von arte HD als auch von anixe HD bekomme ich jeweils das EPG.

Am VDR muss nichts geändert werden!
Die von Klaus erwähnte Modifikation " FE_CAN_2ND_GEN_MODULATION 0x10000000" ist in diesem Paket schon eingebaut.

Viel Spass!

Na klar.

Ich habe die angepassten Quellen einfach mit in den v4l-dvb Baum eingehängt und siehe da: es klappt.

Ich konnte den VDR-1.7.2 ohne Anpassungen kompilieren und starten.
Auf der Konsole sah ich auch gerade schon EPG, scheint also zu klappen.

Jetzt muss ich nur noch zusehen, dass DVB-S2 funzt.
Dazu werde ich im dvbloop vermutlich nochmal etwas anpassen müssen.

Demnächst mehr....

N8!

Okay. Erledigt.

Habe jetzt einen anderen Weg gewählt. Jetzt klappt es.

Jetzt teste ich, ob es auch noch funzt.

Sooo....

Das ist das dvb-core Modul, was ich aus dem v4l-dvb tree gebaut habe:

server:/vdr/netcv/test/dvbloop# cat /proc/kallsyms |grep dvb_dmxdev_init
fa31fa20 r __ksymtab_dvb_dmxdev_init    [dvb_core]
fa31fd20 r __kstrtab_dvb_dmxdev_init    [dvb_core]
fa31fb40 r __kcrctab_dvb_dmxdev_init    [dvb_core]
fa312830 T dvb_dmxdev_init      [dvb_core]
97897fe2 a __crc_dvb_dmxdev_init        [dvb_core]

Und das ist die Symbol-Info zu meinem dvbloop Modul:

server:/vdr/netcv/test/dvbloop# cat dvbloop.mod.c |grep dvb_dmxdev_init
        { 0x4536246c, "dvb_dmxdev_init" },
root@sleepless:/vdr/netcv/test/dvbloop#

Irgendwie passt das von den Prüfsummen her so gar nicht.

Ich habe die Funktionen verglichen. Gleicher Aufruf, gleiche Strukturen.

Hilfe!

Tach!

Ich habe mal aus Spass angefangen, das dvbloop Modul für den aktuellen v4l-dvb tree anzupassen (wegen S2API).

Ich habe bisher folgendes gemacht:
1) aktuellen tip.at.bz2 aus dem v4l-dvb git tree geholt.
2) kompiliert auf meinem Standard Ubuntu Kernel 2.6.24-22-generic.
3) insmod ./dvb-core.ko -> ohne Probleme
4) ein paar Anpassungen an den dvbloop Quellen und am Makefile, so dass nur
die entsprechenden Header Dateien aus dem v4l-dvb Verz. gefunden werden.
Vorsichtshalber habe ich die "dvb" Verz. in meinem Kernel umbenannt in "dvb-blah". Nicht gut, ich weiß. Aber so meckert er halt sofort.

EXTRA_CFLAGS = \
        -I/vdr/dvb-s2api/linux/drivers/media/dvb \
        -I/vdr/dvb-s2api/linux/include \
        -I/lib/modules/2.6.24-22-generic/build/include/linux
#       -I/usr/src/linux/drivers/media/dvb \
#       -Idrivers/media/dvb -I$(@D)/../linux

5) Modul kompileren klappt.
6) Jetzt das ABER: insmod ./dvbloop.ko

[493001.980829] dvbloop: disagrees about version of symbol dvb_dmxdev_init
[493001.980839] dvbloop: Unknown symbol dvb_dmxdev_init
[493001.980995] dvbloop: disagrees about version of symbol dvb_register_adapter
[493001.980998] dvbloop: Unknown symbol dvb_register_adapter
[493001.981199] dvbloop: disagrees about version of symbol dvb_ringbuffer_read
[493001.981201] dvbloop: Unknown symbol dvb_ringbuffer_read
[493001.981408] dvbloop: disagrees about version of symbol dvb_dmxdev_release
[493001.981411] dvbloop: Unknown symbol dvb_dmxdev_release
[493001.981559] dvbloop: disagrees about version of symbol dvb_unregister_frontend
[493001.981561] dvbloop: Unknown symbol dvb_unregister_frontend
[493001.981664] dvbloop: disagrees about version of symbol dvb_register_frontend
[493001.981666] dvbloop: Unknown symbol dvb_register_frontend

Ich verstehe es nicht. Es kann doch nicht an einem falschen Kernel liegen.
Das dvb-core Modul lässt sich ja auch laden und wurde als externes Modul kompiliert. Die anderen v4l-dvb Treiber auch. Nur mein dvbloop Modul nicht.

Kann es sein, dass der Kernel noch irgendwelche Symbol-Infos zu seinen DVB Modulen geladen hat oder so?

Hat einer ne Idee?

Tach!

Ich habe mal aus Spass angefangen, das dvbloop Modul für den aktuellen v4l-dvb tree anzupassen.

Ich habe bisher folgendes gemacht:
1) aktuellen tip.at.bz2 aus dem v4l-dvb git tree geholt.
2) kompiliert auf meinem Standard Ubuntu Kernel 2.6.24-22-generic.
3) insmod dvb-core.ko -> ohne Probleme
4) ein paar Anpassungen an den dvbloop Quellen und am Makefile, so dass nur
die entsprechenden Header Dateien aus dem v4l-dvb Verz. gefunden werden.
Vorsichtshalber habe ich die "dvb" Verz. in meinem Kernel umbenannt in "dvb-blah". Nicht gut, ich weiß. Aber so meckert er halt sofort.

EXTRA_CFLAGS = \
        -I/vdr/dvb-s2api/linux/drivers/media/dvb \
        -I/vdr/dvb-s2api/linux/include
#       -I/usr/src/linux/drivers/media/dvb \
#       -Idrivers/media/dvb -I$(@D)/../linux

5) Modul kompileren klappt.
6) Jetzt das ABER: insmod ./dvbloop.ko

[493001.980829] dvbloop: disagrees about version of symbol dvb_dmxdev_init
[493001.980839] dvbloop: Unknown symbol dvb_dmxdev_init
[493001.980995] dvbloop: disagrees about version of symbol dvb_register_adapter
[493001.980998] dvbloop: Unknown symbol dvb_register_adapter
[493001.981199] dvbloop: disagrees about version of symbol dvb_ringbuffer_read
[493001.981201] dvbloop: Unknown symbol dvb_ringbuffer_read
[493001.981408] dvbloop: disagrees about version of symbol dvb_dmxdev_release
[493001.981411] dvbloop: Unknown symbol dvb_dmxdev_release
[493001.981559] dvbloop: disagrees about version of symbol dvb_unregister_frontend
[493001.981561] dvbloop: Unknown symbol dvb_unregister_frontend
[493001.981664] dvbloop: disagrees about version of symbol dvb_register_frontend
[493001.981666] dvbloop: Unknown symbol dvb_register_frontend

Ich verstehe es nicht. Es kann doch nicht an einem falschen Kernel liegen.
Das dvb-core Modul lässt sich ja auch laden und wurde als externes Modul kompiliert. Die anderen v4l-dvb Treiber auch. Nur mein dvbloop Modul nicht.

Hat einer ne Idee?

Hallo!

Kurze Frage:
Hat hier jemand zufällig den reelvdr mit xineliboutput schon irgendwie zum Laufen gebracht? Wenn ja, wie?

Gruß
Nano

Zitat

Original von Konni__
Irgendwie könnte ich verstehen wenn Klaus die lust am weiterentwicklen vergehen würde.

Den Input über Plugins abzuwicklen wäre sicher eine gute Entscheidung.

Meine volle Zustimmung. Er ist ja gerade dabei, auf die S2API umzurüsten.
Dort gibt es aber auch wieder Dinge, die er benötigt, die die API aber nicht liefert. Zufrieden ist er bestimmt nicht mit der API Situation.

Gerade darum wäre es ja so wichtig, VDR unabhängig zu machen. Dann kann jeder das nehmen, was er will/benötigt und VDR bzw. Klaus muss sich nicht mehr direkt um so einen Kram kümmern und den Daumen darauf haben.

So, ich möchte die Diskussion zu diesem Thema aber lieber wieder beenden. Zumindestens in diesem Thread hier.

Also Themenwechsel:

Meint Ihr ich bekomme Probleme mit der Abwärme des Netceivers, wenn ich den in ein IP65 Gehäuse packe und dann ab nach draußen in den Schatten?
Was gibt es für Kühlmöglichkeiten bei solchen wetterfesten Gehäusen?
Metallische Verbindung von innen nach außen und die dann gut abdichten?

Hallo!

Zwei Fragen:

1)
Hat jemand von Euch den Netceiver evtl. schon in ein wetterfestes Gehäuse (IP65) eingebaut und betreibt ihn draußen?

Meint Ihr, dass das klappt?

2)
Weiß jemand, wie KLS Einstellung zu Input-Plugins ist?
Ich finde, dass es höchste Zeit wird, den VDR so weit wie möglich von der alten DVB-Hardware bzw. irgendwelchen APIs zu entkoppeln. Ebenso bei der Ausgabe.
Ich weiß, dass das Thema schon einmal auf der Mailing-Liste behandelt wurde. Ich halte den aktuellen Zustand für traurig aus Sicht eines VDR-Begeisterten. Vor allem, weil es jedes Mal Modifikationen am VDR selbst gibt. Auch, wenn es vielleicht nur dvbdevice.c ist.

Der Netceiver zeigt deutlich, dass auch hier Bedarf bestünde. Es bräuchte dann nicht mehr diesen Weg von hinten durch das Auge mit dem dvbloop-Modul.

Weg mit dem API-Zwang für VDR!
Dann lieber ein Input-Plugin für jede API.
Ich finde, dass man mal eine Umfrage starten sollte.

Gruß
Nano