QuoteOriginal von UFO
Es wäre schön, wenn möglichst viele diesen Treiber in unterschiedlichen Konfigurationen testen würden.
Ich habe den Patch mit dem heutigen HG Treiber installiert und werde das Verhalten mal
beobachten.
QuoteOriginal von UFO
Es wäre schön, wenn möglichst viele diesen Treiber in unterschiedlichen Konfigurationen testen würden.
Ich habe den Patch mit dem heutigen HG Treiber installiert und werde das Verhalten mal
beobachten.
QuoteOriginal von UFO
Hi Leute:
1. Das gehört das alles nicht in diesen Thread. Worum es hier geht, steht im ersten Post.
CU
Oliver
hast Recht, deswegen nur kurz als Klarstellung und ab jetzt bin ich auch ruhig
QuoteOriginal von woppr
geerdete sat anlage? was soll das werden? ein blitzableiter ?
einfach weils Vorschrift ist --> http://www.kathrein.de/include/faq/faq.cfm?nr1=01&nr2=02&nr3=06
Gruß Fr@nk
Hi!
Ich hab zum ersten Mal hg benutzt und eine kleine Auffälligkeit bemerkt. Ich hab 2.6.16.20 und wenn ich "make kernel-links" aufrufe, dann bekomm ich einen Reject gemeldet.
linux/include/linux/videodev.h.rej:
***************
*** 1,6 ****
#ifndef __LINUX_VIDEODEV_H
#define __LINUX_VIDEODEV_H
#include <linux/types.h>
#define HAVE_V4L1 1
--- 1,7 ----
#ifndef __LINUX_VIDEODEV_H
#define __LINUX_VIDEODEV_H
+ #include "compat.h"
#include <linux/types.h>
#define HAVE_V4L1 1
Display More
Problem ist, daß
in linux/include/linux/videodev.h fehlt. Hab ich da irgendwas vergessen?
MfG
mic
P.S.: Ist jetzt ja nicht schlimm; ich hab einfach
händisch eingefügt und dann bei "make kernel-links" auf die "diff -R" Frage mit "y" geantwortet. Der Treiber läuft jetzt bei mir. Aber ich wüßte trotzdem gerne wissen was falsch gelaufen ist.
mic
QuoteDisplay MoreOriginal von micmac
Hi!
Ich hab zum ersten Mal hg benutzt und eine kleine Auffälligkeit bemerkt. Ich hab 2.6.16.20 und wenn ich "make kernel-links" aufrufe, dann bekomm ich einen Reject gemeldet.
linux/include/linux/videodev.h.rej:
CodeDisplay More*************** *** 1,6 **** #ifndef __LINUX_VIDEODEV_H #define __LINUX_VIDEODEV_H #include <linux/types.h> #define HAVE_V4L1 1 --- 1,7 ---- #ifndef __LINUX_VIDEODEV_H #define __LINUX_VIDEODEV_H + #include "compat.h" #include <linux/types.h> #define HAVE_V4L1 1
Problem ist, daß
in linux/include/linux/videodev.h fehlt. Hab ich da irgendwas vergessen?
MfG
mic
P.S.: Ist jetzt ja nicht schlimm; ich hab einfach
händisch eingefügt und dann bei "make kernel-links" auf die "diff -R" Frage mit "y" geantwortet. Der Treiber läuft jetzt bei mir. Aber ich wüßte trotzdem gerne wissen was falsch gelaufen ist.
Dazu kann ich nicht viel sagen. Mit der makelinks-Patcherei habe ich mich nie beschäftigt. Ich mag keine gepatchten Kernel-Sourcen und kompiliere den Treiber immer außerhalb des Kernels.
Der Patch hier hat nichts damit zu tun. Tritt sicher auch mit dem normalen HG-Treiber auf.
Ursache ist v4l/scripts/makelinks.sh. Ganz unten wird dort videodev.h gepatcht...
Offenbar steht im File nicht so ganz das drin, was erwartet wurde.
CU
Oliver
QuoteOriginal von UFO
Es wäre schön, wenn möglichst viele diesen Treiber in unterschiedlichen Konfigurationen testen würden.
dewegen habe ich ihn auch mal in meinen LinVDR-Kernel 2.6.15 eingebaut
http://drseltsam.device.name/vdr/kernel2615.html
Habs jetzt unter Gentoo 2.6.14 laufen.
Macht einen doch flüssigeren Eindruck als vorher.
Bin bis jetzt recht zufrieden
Ach eins noch:
Habe die Treiber frisch aus mercurial gezogen und dann den Patch ausgeführt und kompiliert. Dabei sind bei mir 2 Probleme aufgetreten, die ich wie folgt gelöst habe:
1. "undefined symbols" nach starten der Treiber
-> ein reboot hat geholfen
2. Treiber zwar geladen, aber vdr 1.4 sagt, "no primary device found"
-> "rmmod stradis" ausgeführt. Der stradis Treiber ist wohl noch sehr experimentell und wird zumindest bei FF Karten automatisch mit geladen. Jedoch nicht wirklich benötigt.
Hoffe das hilft dem ein oder anderen
Hey Dr. Seltsam,
toll von Dir das in den Kernel einzubauen.... Hatte gerade mit meinen rudimentären linuxkentnissen überlegt, wie ich das in mein linvdr reinbekomme
Danke für Deine Arbeit! Werd wohl bald mal einbauen (weil das Geruckel nervt!
Gruß Micha
@Dr.Seltsam
Auch von mir ein herzliches Dankeschön, werde das heute Abend mal einspielen in der Halbzeitpause *g* Wollte beim Lesen gerade nachfragen, ob das jemand mal kompilieren kann, denn ohne Entwicklungsumgebung bekomme ich das ja nicht hin unter LinVDR - und schon warst Du wieder einmal helfen dzur Stelle! Vielen Dank!
Werde dann berichten, ob es endlich besser wird...
Gruß,
Sascha
sorry!
Hi Oliver,
ich hab' den Patch bei mir eingespielt und allet löppt
Edit:
Konkreter: diverses Ruckeln bei gleichzeitiger Aufnahme und Live Anschauen sind mit dem gepatchten Treiber nicht aufgetreten. Buffer usage Meldungen in syslog kommen z.Z. so gut wie nicht vor.
Danke, ollo
Hi UFO,
habs jetzt nach längerer Odysee geschafft, den hg-Treiber mit patch zu kompilieren.
Ergebnis: Ist noch nicht perfekt, läuft aber um Welten besser als ohne patch (ich habe nach reboot mit rename mal direkt verglichen). Die Ton- und Bildstörungen sind bei hohen Datenraten und mehreren paralellen Aufnahmen zwar noch nicht vollständig weg, aber man kann wieder zuschauen.
Ausserdem bleibt der VDR weiterhin bedienbar, das OSD erscheint nach akzeptabler Zeit. Nach Umschalten auf DD geht allerdings nicht mehr viel...
Vielen Dank dafür !
Grüße, Peter
QuoteOriginal von klausstgt
wenn ihr meint, daß er nur zur weiteren verwirrung beitägt.
um ehrlich zu sein befürchte ich genau das, denn in diesem Thread und bei UFOs Treiberoptimierung geht es wirklich nur um das "Flaschenhalsproblem" (buffer usage).
Das verursacht definitiv auch Tonstörungen, die man im Log aber gut identifizieren kann (buffer usage läuft hoch, ringbuffer wird gecleart, cVideoRepacker springt an)
Das Stotterproblem von 2003 hat damit nichts zu tun.
Hi,
Kann man den Patch auch bei den Kernelintegrierten Dvb-Treibern (in meinem Fall 2.6.13)
anwenden, oder geht der Patch nur bei den Treibern von Hg Mercury?
Gruss , Bert
QuoteOriginal von Bert
Kann man den Patch auch bei den Kernelintegrierten Dvb-Treibern (in meinem Fall 2.6.13)
anwenden, oder geht der Patch nur bei den Treibern von Hg Mercury?
Mußt Du halt ausprobieren. "patch --dry-run" ist Dein Freund.
CU
Oliver
Hi,
QuoteMußt Du halt ausprobieren. "patch --dry-run" ist Dein Freund.
Thanks, na dann werd ich das bei Gelegenheit mal tun.
Gruss Bert
Moin,
hatte bislang auf meinem Athlon64 das Problem, dass ich bei niedrigster Taktung (800MHz) bei der Wiedergabe von Aufnahmen Aussetzer hatte. Das scheint verschwunden zu sein
Bislang läuft der Treiber bei mir bislang perfekt.
Auch bei mir ohne negative Nebenwirkungen. Fühlt sich durchaus etwas flüssiger an.
Thomas
Bin auch hochzufrieden
Ist alles ne Ecke flüssiger geworden. Vorallem bei ARD und ZDF
ich hatte bei den wm spielen auf ard/zdf ab und zu das phänomen, dass es ruckte so im sekunden abstand. einmal hin und herzappen hat geholfen. aber ist in der ganzen zeit nur zweimal aufgetreten. ansonsten funktioniert das teil echt besser als die 'normale' version.
in den logs konnte ich zu dem geruckle leider nichts finden. sah alles ganz normal aus. aber vielleicht beschwert sich der treiber ja auch nur nicht.
fen.
Don’t have an account yet? Register yourself now and be a part of our community!