Beiträge von steini

Hi,
ich möchte nur noch kurz erwähnen dass es wie vermutet an meiner Konfiguration liegt. Wenn ich udev für die Treiber- und Devicekonfiguration nehme klappt Avards auch mit den aktuellen Treibern.
Zur Info: Ich hab schon seit langer Zeit keine konventionelle Distri sondern eine Minimalinstallation so in etwa wie die Struktur von Linvdr und auf der Basis von Debian lenny und auf einer 512MB CF-Disk. Da sind die Devices fest angelegt, also z.B mit "mknod /dev/vbi0 c 81 224". Bei den aktuellen Treibern geht das bzg. dem vbi-Device so offenbar nicht.
Nachdem ich udev testweise eingebunden habe funktioniert allles wie geschmiert
Ich muss jetzt nur noch schauen wie ich udev sauber integriere.....ohne dass da permanent Schreibzugriffe auf die CF stattfinden. Ich denke aber das da nichts geschrieben wird außer auf tmpfs, also ins RAM.
Vielen Dank für Eure Unterstützung.
Gruß
Steini

FireFly,
nochmal kurz zu meinem Problem.
vbi-Devices legt man doch selbst an...oder täusche ich mich da? Ich hab da ne ganze Menge von....mehr als 10.
Das Problem liegt woanders. Ich werde das weiter untersuchen wenn ich dafür mehr Zeit habe. Die Tools wie dvb-aspect und dvb-wss-overdrive funktionieren auch nicht mit den gleichen Fehlermeldungen.
Es würde mir dabei nur sehr helfen wenn mir jemand bestätigen würde dass avards mit den ganz aktuellen Treibern funktioniert.
Die letzten Treiber von Oliver (UFO) vom September 2008 funktionieren bei mir damit noch, die ganz aktuellen jedoch nicht.
Vielen Dank
Gruß
Steini

Zitat

Original von FireFly
steini: was gibt ein "ls -l /dev/vbi*" aus?

Hier'n Ausschnitt:

lrwxrwxrwx    1 root     root            9 Nov 27  2007 /dev/vbi -> /dev/vbi0
crw-rw-rw-    1 root     root      81, 224 Jul  1  2003 /dev/vbi0
crw-rw-rw-    1 root     root      81, 225 Jul  1  2003 /dev/vbi1

sieht für mich normal aus

Zitat

Original von FireFly
Innerhalb Avards hat sich am vbi-Device nix geändert, aber das ist ja auch nicht der Thread zur aktuellen Version

Nee, ich meinte ja ob sich da im Treiber was geändert hat. Ich hab auch die 0.1.5 von Avards.....ändert auch nix;)
Der Treiber wurde auch nicht neu geladen, ich hab da glaub ich alles gelesen was geht...zuerst natürlich deine README.
Dieses Problem tritt reproduzierbar immer auf und nur bei diesen neueren Treibern, beim "alten" Treiber nie, auch nicht wenn der Treiber neu geladen wird.
Ich denke das liegt am Treiber oder an meiner Konfiguration. Vielleicht hat ja jemand da ne Idee.
Gruß
Steini

e9hack,
danke für den Hinweis. Hab den Kernel jetzt mal neu mit

CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_V4L1=m

Avards startet jetzt, gibt aber trotzdem folgendes aus

Mar 22 19:15:05 activy user.err vdr: [1759] avards: switching WSS to 16:9
Mar 22 19:15:05 activy user.err vdr: [1759] avards: Error: Can't open vbi device '/dev/vbi0' (No such device or address)

oder

Mar 22 19:20:32 activy user.err vdr: [1759] avards: switching WSS to L16:9
Mar 22 19:20:32 activy user.err vdr: [1759] avards: Error: write to vbi device failed (Bad file descriptor)
Mar 22 19:20:32 activy user.err vdr: [1759] avards: closing vbi device

vbi ist als Link auf vbi0 vorhanden und vbi0 wird auch angelegt. Also stimmt da was noch nicht. Hat sich da vielleicht an den Devices was geändert?
Gruß
Steini

FireFly,
vielen Dank für dieses super Plugin
Ich möchte das nicht mehr missen.
Da ich meiner FF-Karte einen Full-TS Mod verpasst habe musste ich auch die Treiber upgraden. Seither funktioniert Avards leider nicht mehr.
VDR-Version ist 1.6
Treiber sind die Kerneltreiber aus dem 2.6.28.8er (hab aber auch die letzten v4l-dvb Treiber getestet....ohne Erfolg).
Das Plugin wird geladen, startet aber nicht. Im Log steht:

Mar 22 16:50:53 activy user.err vdr: [2079] avards-detector thread started (pid=2054, tid=2079)
Mar 22 16:50:53 activy user.err vdr: [2079] avards: Error: Can't open video buffer on device '/dev/video0' (Invalid argument)
Mar 22 16:50:53 activy user.err vdr: [2079] avards-detector thread ended (pid=2054, tid=2079)

dmesg zeigt:

saa7146: register extension 'dvb'.
saa7146: found saa7146 @ mem d2576400 (revision 1, irq 11) (0x13c2,0x0000).
dvb-ttpci: full-ts mode enabled for saa7146 port B
saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]

Was kann das sein? Mit älteren Treibern (2.6.13.12er Kernel mit den Refactoring-Treibern vom Oliver) funktioniert alles super.
Vielen Dank
Gruß
Steini

Hi,
hab's endlich auch geschafft ne Karte umzurüsten (eine 1.5er). Hat gut geklappt und funktioniert super (mit den Treibern vom 2.6.28.7er Kernel). Vielen Dank für den Mod, UFO
Ich hab dafür das kleine Platinchen verwendet das Klaus hier angeboten hat. Das geht damit sehr gut. Allerdings ist auf dem Layout die Bezeichnung für die Stromversorgung der CMOS-Chips vertauscht (also + und -). Ich weiß nicht ob das schon mal erwähnt wurde....hab jetzt nicht nochmal den ganzen Thread durchgeschaut....vielleicht sollte man das ändern. Die Chips haben das nicht so gerne
Gruß und Dank
steini

@Frankmann,
ich hab seit 2Jahren den TH-42PX62E von Panasonic.
Damals stand ich auch vor der Entscheidung ob Plasma oder LCD. Ich wollte zunächst keinesfalls einen Plasma wegen der ganzen bereits genannten Nachteile. Allerdings waren die LCD's zumindest vor 2Jahren im Vergleich so schlecht dass ich dann eben den o.g. Plasma genommen habe. Besonders bei PAL-Signalen waren die Unterschiede wirklich erheblich. Ich weiß aber nicht wie sich das in den letzten 2 Jahren entwickelt hat.
Ich hab damals übrigens eine mittels VDR erstellte DVD mit in den Laden genommen und in den zentralen DVD-Player einlegen lassen. Damit kann man sehr gut vergleichen und hat sicher die gleichen Bedingungen wie zu Hause (was die Qualität anbetrifft).
Wicky,
ich hab nen Testrechner mit Blu-Ray Laufwerk und einer XT2400Pro GRAKA. Den hab ich problemlos mittels HDMI an den Plasma angeschlossen. Das Bild ist bei Blu-Ray-Disks absolut hammermäßig. Wenn man dann aber den gleichen Film im Vergleich auf einer PAL-DVD über z.B. den YUV-Eingang anschaut sieht man aber auch wie gut der Pana mit dem PAL-Bild umgeht, denn der Unterschied ist meiner Meinung nach nicht so groß wie vermutet.
Gruß
Steini

Hi,
UFO.....einfach unglaublich
Ich werde das mal in Angriff nehmen.
Kurze Frage zu den Leitungen:
Wie dick sollten / müssen die sein? Oder ist das egal?
Vielen Dank mal wieder für deinen Einsatz!!
Gruß
steini

Hi,
welche vdr-Version ist denn das und ist evtl. das PIN-Plugin mit dem entsprechenden Patch integriert? Ich habe nämlich festgestellt dass dieser Patch Probleme beim mlcd Plugin verursacht.
Gruß
steini

Hallo sewn4,
das mit der Genauigkeit von noad ist bei mir auch so. Ich denke diese ganzen Animationen und anderen Spielchen mit den Logos machen da Probleme.
Ich hatte übrigens unter Debian Lenny auch Probleme mit dem Compilieren von noad. Nachdem ich dann die ffmpeg-Pakete deinstalliert und ffmpeg in einer älten Version selbst compiliert habe ging's dann problemlos.
Gruß
steini

Hi,
es liegt definitiv am PIN-Patch. Wenn der raus ist geht auch mlcd. In beiden Versionen, also 1.4.7 und 1.5.2.
Mlcd ist bislang immer absolut unproblematisch gewesen und immer gelaufen. Ich bin noch nicht dahinter gekommen was da genau passiert.
Macht ja auch nix....Hauptsache es geht
Gruß
steini

Hi,
ich glaub ich hab das Problem gefunden. Ich habe mit den Sourcen aus DIESEM Thread ne ziemliche Debugorgie gemacht und rausgefunden dass mlcd nicht läuft wenn der PIN-Plugin-Patch aktiviert ist. Warum das so ist kann ich noch nicht sagen. Könntest du das mal testen. Ich hab leider keine Entwicklungsumgebung unter Woody mehr. Bitte doch mal Toxic ob er für dich eine vdr-Version ohne diesen Patch compilieren kann um das zu verifizieren.
Jetzt schaue ich mal ob sowas auch für meine 1.5.2 zutrifft.
Gruß
steini

Hi vdrdream,
ich kenn jetzt die Mahlzeit 4.0b nicht. Dazu mal ne Frage: Welche Patche sind da drin? Ich hatte nämlich bei 1.4.x nie Probleme mit mlcd. Gibt es ggf. ein Source-Paket der darin verwndeten vdr-Version?
Da ich jetzt nochmal schauen will wo das Problem liegt kann ich das für euer Problem gleich mitprüfen.
Gruß
steini

Hallo Dominik,
bei mir ist eine 300GB Samsung drin. Geht problemlos. Hab allerdings als primäre "Festplatte" eine CF.
Gruß
steini

Hi,
ich schieb das mal hoch
Ich weiß ja dass nicht mehr so viele Multitainer in Verwendung sind und dass ich nicht sehr viele Angaben machen kann aber ich komme nicht weiter.
Vielleicht findet sich ja doch noch jemand der mir da helfen kann.
Ich hänge mal den Sourcecode an.
Vielen Dank
Gruß
Steini

Hi,
also unter vdr-1.4.x funktioniert das mlcd-Plugin pröblemlos (Version 0.4a incl. mlcd-0.0.4a-vdr-1.3.38.diff).
Natürlich muß das Plugin geladen werden. also z.B. bei Linvdr über das Setup aktivieren oder in die sysconfig eintragen.
Außerdem braucht das Plugin zur korrekten Datstellung der Zeichen die char.dat die im Sourcepaket des Plugins enthalten ist. Normalerweise muß diese Datei nach /etc kopiert werden.
Dann sollte alles funktionieren.
Ich hänge mal eine funktionierende Version als Sourcepaket an. Der Patch ist bereits angewendet und die char.dat wird in /etc erwartet.
Guß
Steini

Hi,
hab nach längerer Zeit mal meinen VDR aufgefrischt.
Dabei bin ich beim Multitainer auf folgendes Problem gestoßen:
Das Plugin mlcd läßt sich ohne Fehler compilieren. Bei Aktivierung startet vdr zwar, ich bekomme aber kein Bild und es passiert nix mehr bis der Wachhund zuschlägt. Eine Fehlermeldung gibt es merkwürdigerweise auch nicht; also ist das log auch nicht hilfreich. Getestet hab ich das unter 1.5.2, 1.5.4 und 1.5.5, immer mit der Pluginversion 0.4a.
Meine Konfiguration steht ja in der Signatur.
Hat jemand das Plugin denn unter 1.5.x laufen? Dann muß ich das Problem bei meiner Konfiguration suchen.
Falls nicht....könnte sich mal jemand den Sourcecode anschauen und prüfen ob da das Problem liegt?
Vielen Dank
Gruß
Steini

@ kanotixer,
danke, hatte übersehen das es sich dabei schon um den modifizierten Code handelt. Die Balken-LED-Geschichte brauch ich auch nicht. Ich finde das mit dem Timer übrigens auch besser

@ riva,
in diesem Fall ist Assembler der Programmcode. Was du wahrscheinlich meinst ist ein entsprechender Code in einer höheren Programmiersprache (z.B. C oder Basic). Das geht prinzipiell auch. Den wirst du aber für diesen Anwendungsfall wahrscheinlich selbst schreiben müssen. Hab zumindest keinen gesehen.
Ach, ja....den Assemblercode mußt du natürlich vor dem flashen assemblieren. Die Software dafür kannst du unter www.atmel.com runterladen.

Gruß
steini

Hi,
ich finde es super dass Ihr euch damit beschäftigt und diese unabhängige Lüftersteuerung nochmal anpackt.
Da ich bei meinem VDR (Multitainer) kein Sensors o.ä verwenden kann mußte ich mich auch mal damit beschäftigen.
Als ich das hier gelesen habe mußte ich erstmal meinen Rechner aufmachen und nachsehen ob da noch alles läuft
Ich hab nämlich vo ca. 2Jahren einfach so eine Steuerung gebaut ohne mir über diese von Euch angesprochenen Probleme überhaupt Gedanken zu machen.
Ich hab einfach einen Transistor (2N2222), einen Basisvorwiderstand und eine Rücklaufdiode genommen und das direkt an den PWM-Ausgang des AVR angeschlossen. Temperaturmessung erfolgt am CPU-Kühler mittels LM75 (also I2C-Sensor).
Angesteuert wird damit lediglich der CPU-Lüfter.
Tatsächlich funktioniert aber noch alles.....möglicherweise hab ich aber auch nur Glück mit dem Lüfter gehabt.
Diese Schaltung von Uwe Freese ist aber deutlich besser und ich werde diese wenn ich mal wieder Zeit habe nachbauen.
Was den Programmcode für den Tiny2313 anbetrifft könnt es sein dass da nur sehr wenige Änderungen notwendig sind und man nur die entsprechenden Fuse-Bit's im Controller setzen muß.
Möglicherweise habe ich kommende Woche mal etwas Zeit. Dann schaue ich mir den Code mal an......muß mich aber erst wieder einlesen
Gruß
steini

Hi,
na ersatzlos kann man doch nicht sagen. Für die Funktion wird doch das epgsearch-Plugin integriert.
Gruß
steini