Beiträge von SledgE

    mit relativ hoher warscheinlichkeit das netzteil.


    du kannst mal am morgen bevor der vdr gestartet wird mit einem heißluftfön in das netzteil blasen und so die elektronik vorwärmen.
    startet der rechner nun normal hast du es mit defekten elkos im nt zu tun.
    meistens sind es welche auf der sekundärseite.

    die tuner in den receivern sind meiner meinung nach auch nicht besser.
    beim rechner ist immer das problem das in seinem inneren enorme em-felder durch funkabstrahlungen aller leitungen mit hochfrequenten signalen bestehen.
    nur aus diesem grund haben die rechner bis heute ein geschlossenes blechgehäuse und kein deutlich billigeres aus plastik.
    die pci-karten sind deshalb zahlreichen störspannungen durch einstreuungen ausgesetzt und das problem wird mit zunehmenden taktfrequenzen des speicherbuses immer größer.


    hamuch: versuche es mal mit einer älterne firmware für die dvb-karte.
    warum auch immer,meinen erfahrungen nach bringt das teilweise deutliche unterschiede.
    die firmware ist eine einzelne binärdatei welche normalerweise unter /lib/firmware zu finden ist und beim initialisieren des treibers in die karte geladen wird.
    es gibt mitlerweile zahlreiche versionen davon.
    beachte das du die firmwaredatei auf den korrekten dateinamen umbenennst denn nur mit diesem kann sie auch vom treiber geladen werden.

    der aktuelle mplayer-1.0rc2 bringt integrierte versionen der libs für nav und read mit.
    damit funktioniert es ebenso wie mit den versionen welche fedora in die distribution einbaut.


    allerdings habe ich noch keine version gefunden welche das umschalten von unterschiedlichen kammerawinkeln wärend der wiedergabe ermöglicht.
    im plugin wird man beim drücken der entsprechenden taste in das menü zurückgeworfen.
    auch sämtliche freinen softwarevideoplayer mit dvd-unterstützung erlauben es nicht.
    einzig mit dem kostenpflichtigen lindvd soll es angeblich gehen.


    gibt es überhaupt eine version von libdvdnav+libdvdread mit der das funktioniert?

    mit dem seriellen lirc-empfänger ist einschalten des rechners nicht möglich weil bei ausgerschaltetten rechner im standby keine spannung am comport anliegt.
    du benötigst eine der verschiedenen extraschaltungen welche über die standbyspannung des netzteils im dauerbetrieb sind und beim empfang des richtigen ir-signals dann den powerknopf des rechners aktivieren.


    offt wird dabei ein pic-microprozessor verwendet welchen man beim eigenbau allerdings noch mit einem programmiergerät bearbeiten muß.
    schau dich mal nach "ir-einschalter" um.
    es gibt sicher auch fertige platinen zu kaufen.

    bei den nachfolgeversionen der 1.3 wurde die modifikation serienmäßig eingeführt weswegen diese karten weniger empfindlich für verseuchte betriebsspannungen des pci-busses sind.
    du hast folgende möglichkeiten:


    - die 1.3 wieder durch eine karte neuerer revision ersetzen
    - die 1.3 modifizieren (lassen)
    - einen anderen pci-slot nutzen (mgl. weit zur platinenmitte) und glück haben das dies schon ausreicht
    - das mainbaord tauschen und hoffen das sich das problem damit erledigt


    bei älteren mainbaords sind es offt gealterte elektrolytkondensatoren direkt beim den pci-slots.
    sie verlieren mit der zeit an kapazität und das sie chronisch unterdimensioniert sind und bei lowcost-boards auch schon gerne mal weggelassen werden kömmt es dann verstärkt zu schlechten versorgungsspannungen an den pci-slots.
    falls dies der fall ist kann man auch die kondensatoren wechseln oder zusätzliche von der rückseite auf das baord löten.

    cvs-version,so wie in der wiki beschrieben,downloaden und verwenden.
    1.0 ist veraltet.
    in der readme findest du hinweise welche weiteren softwarepakete benötigt werden.
    die skins müssen in das erste videoverzeichnis unter /plugins/text2skin entpackt werden.
    die skins mit 256 farben funktionieren nur mit einer gemodetten dvb-karte mit speichererweiterung.

    der tuner der 1.3 wird mit mehreren versorgungsspannungen betrieben wobei eine direkt vom pci-bus durchgeschleift wird und nur ungenügend gefiltert ist.
    das kann je nach stärke und frequenzspektrum der em-felder im rechner zu solchen datenfehlern im stream führen.
    es gibt eine modifikation der 1.3 mit welcher sich solche probleme beheben lassen.
    dabei wird die versorgungsspannung des tuners auf einen spannungsregler der dvb-karte umgelegt so das die verseuchte spannung vom pci-bus nicht mehr verwendet wird.
    die modifikation ist simpel und besteht nur aus dem entfernen einer filterdrossel und das anlöten einer drahtbrücke.
    idealerweise wird dabei auch noch der drahtwiderstand des betreffenden spannungsreglers durch ein größeres exemplar ausgetauscht weil dieser widerstand eine weitere schwachstelle ist und mit der zeit gerne mal verdampft.


    vermutlich verschwinden die störungen bei dir wenn du die taktfequenz der cpu und/oder des ram stark herabsetzt.
    die biosoption "spread spectrum" könnte,falls vorhanden,ebenfalls einen einfluß haben.

    wie shf schon geschrieben hat die widerstände an den signalleitungen der ethernetbuchse nachmessen.
    gerade kohleschichtwiderstände in smd-bauweise werden da gerne mal hochohmig ohne das man dies von außen erkennen kann.

    "Allerdings konnte ich mit "modprobe lirc_serial" das Modul laden, aber ohne Wirkung."


    der lirc-server muß nach dem laden des lirc-kernelmoduls gestartet werden damit er funktioniert.
    deshalb hattest du keine wirkung.


    wie lirc mit den empfangene signalen umgeht wird im konfigurationsfile des lirc-servers festgelegt.
    normalerweise ist das die lircd.conf unter /etc.
    hier wird neben der codeübersetzung u.a. auch das repeatingverhalten festgelegt.
    du solltest,wenn der autostart geschafft ist, dir ein neues file speziell für die von dir verwendette fernbedienung anlegen.
    lirc bietet dafür ein spezielles anlernprogramm welches dir dann auch das file generieren kann.
    alle infos dazu findest du ausführlich in der dokumentation.


    mit debianbasierenden systemen wie ubuntu kenne ich mich nicht aus.
    wenn es bei dir keine modprobe.conf gibt dann düfte diese datei bei deiner distribution einen anderen namen haben.
    evt. ist es modules.conf.


    auf jeden fall mußt du sicher stellen das zuerst der kernelteiber deaktiviert und das lirc-modul an seiner stelle geladen wird bevor der lirc-server startet.

    "FATAL: Error inserting lirc_serial (/lib/modules/2.6.22-14-generic/ubuntu/media/lirc/lirc_serial/lirc_serial.ko): Device or resource busy"


    modul ist da,kann aber nicht geladen werden weil bereits der kernel den comport mit seinem eigenen treiber kontrolliert.
    entweder du sorgst mit einem eintrag in /etc/modprobe.conf dafür das der kerneltreiber von lirc entladen werden kann oder du kompilierst den kernel so das der treiber für com als modul und nicht fest eingebaut verwendet wird.
    dann kann lirc den com-treiber automatisch auswechseln.


    der eintrag in die modprobe.conf kann etwa so aussehen:


    Code
    alias char-major-61 lirc_serial 
    install lirc_serial /bin/setserial /dev/ttyS0 uart none; /sbin/modprobe --ignore-install lirc_serial

    mal im laufenden betrieb mit einer intakten karte die temperatur am spannungsregler für die lnb-versorgungsspannungen fühlen.
    wird dieser ic so heiß das man sich die finger verbrennt liegt es am multiswitch der einen zu hohen strom über das satkabel zieht.
    braun verfärbter schutzlack in der umgebung des ic bei den defekten karten sowie der ausfall der lnb- versorgungsspannung am satkabel wäre ebenfalls ein sicherer hinweis dafür.

    von hersteller,welche lowcostplatinen in veredelte gehäuse stecken lassen um sie dann lukrativ im westlichen markt zu veredeln würde ich abstand nehmen.
    ich würde mich deshalb eher bei herstellern wie fortron,cwt oder auch seasonic umschauen.
    wenn man effizient fahren will ist es natürlich auch keine gute idee zwei hintereinander geschaltette schaltnetzteile zu verwenden

    das kann nicht stimmen.
    alle admins der heutigen zeit sind oder waren computergamer.
    alle waren schon auf lanpartys wo sie auch ihren berufswunsch konkretisierten.
    alle wissen was passiert wenn die spielergemeinde ihre rechner anstöpselt und nach der eröffnungsansprache gemeinschaftlich auf den powerknopf ihres jeweiligen rechners drückt.
    jeder erfahrene und verantwortungsvolle langamer führt mindestens einen neuen sicherungsautomaten mit.
    ;)

    unter X geht es mit "tvtime" sehr gut und dank hochwertiger deinterlacer auch in hoher bildqualität.
    tvtime verarbeitet allerdings nur das bild wärend der ton über alsa/oss ausgegeben wird.
    eine steuerung für den vdr ist nicht implementiert.
    zur steuerung kannst du entweder die tastatursteuerung von vdr nutzen oder du konfigurierst dir eine ir-fernbedienung über lirc.
    wenn du das volle potential von vdr nutzen willst kannst du dich gleich von fertigen paketen deiner distribution verabschieden.
    wenn du die software selber aus den sourcen kompilierst stehen dir alle möglichkeiten offen.

    das prb. mit den fehlerhaft wiedergegebenen videos hat sich erledigt.
    die konsolenausgabe von mplayer bringt bei den betreffenden videos die folgende fehlermeldung.


    [h264 @ 0x888dd50]MBAFF + spatial direct mode is not implemented


    offenbar gibt es da eine wechselwirkung zwischen den dekodierten bildern und den kodieren nach mpeg2 welche mit mpeg1 nicht auftritt.
    die ursache ist also ein von mir verwendetter parametert des .h264-ffdshow-codecs welcher von mplayer bisher noch nicht unterstützt wird.
    die einfache wiedergabe und das rekodieren nach mpeg1 klappt zwar schon fehlerfrei aber offenbar nicht das fehlerfreie komprimieren nach mpeg2.


    das prb. wird also auf einer anderen baustelle behoben.


    ich habe xvid,mpeg1+2,flv,real und x264-codes erfolgreich sowohl mit 25fps als auch mit 30fps fehlerfrei getestet.
    mit den optionen min und max stimmt aber entweder etwas noch nicht oder ich habe sie falsch verwendet.
    mit diesen parametern bekomme ich ein starkes ruckeln oder stottern in die wiedergabe weswegen ich meine optimierungsversuche erstmal abgebrochen habe.


    bei mir werkelt ein amd xp-mobile mit 2,4ghz mit einer dvb-s 1.3 im einzelbetrieb.
    der pci-takt ist 5% erhöht was sich positiv auf die ruckler auswirkt und einen nachweisbaren einfluß für die datenrate hat bis zu welcher noch ruckelfreies abspielen mit lavc möglich ist.
    auch bei mir ist mit lavcmpeg2 die cpu-last ungefähr 10% gegenüber lavc erhöht was erfreulich gering ist.
    der kritischste anwendungsfall liegt in der praxis immer dann vor wenn über die dvb-karte bereits aufnahmen mit hohem datentransfer laufen und wärenddessen dann noch eine wiedergabe von mplayer gestartet wird.
    bisher hatte ich dazu spezielle lowquality-configfiles für mplayer über das vdr-menü "befehle" einsatzbereit um auch unter diesen bedingungen ruckelfrei videos abspielen zu können.


    nun ist das praktisch überflüssig geworden da ich mit "lavcmpeg2=3100#mpeg=2#gopsize=26:25" selbst mit zwei laufenden aufnahmen immer noch eine sehr gute wiedergabequalität ruckelfrei hinbekomme.
    zum testen habe ich auf besonders kritische videoszenen mit vielen harten kontrastsprüngen im bildinhalt zurückgegriffen.
    mit zwei gleichzeitigen aufnahmen von sendern mit sehr hoher datenrate bleibt es bis etwa 2000kbit/s,ohne aufnahmen im hintergrund bis etwa 8000kbit/s ruckelfrei auf meinem system.
    das limit der dvb-karte liegt vermutlich irgendwo bei 13mbit/s stotterfreien gesamtdatentransfer.


    ein manko ist noch das stottern in den ersten sekunden zu beginn einer wiedergabe welches bei reinen i-frames nicht aufgetreten ist.
    vermutlich läßt sich das wohl auch nicht beheben.
    es läßt sich aber mit der größe der gops beeinflussen.

    mit bestimmten videos von mir gibt es ein problem mit lavcmpeg2 UND dem parameter "mpeg=2".
    dabei tritt eine art extremer motionblur-effekt auf wenn sich objekte horizontal durch das bild bewegen.
    mit "mpeg=1" ist die wiedergabe genau wie mit lavc ganz normal.


    bei den videos handelt es sich um tv-mitschnitte welche ich mit ffmpeg nach h.264 kodiert habe.
    andere videos vom selben sender und ähnlicher verarbeitung laufen wiederum normal.


    ich kann es mir nicht so richtig erklären aber der einzige unterschied zwischen den videos dürfte der verwendette deinterlacer bei der konvertierung oder evt. auch ein einzelner parameter des .264-codecs sein.

    vielen dank lava.
    seit jahren warte ich nun schon vergeblich darauf das sich jemand der sache annimmt zumal es ja auch schon ewig in der todo-liste von mplayer steht.


    ich habe in eingebaut und die ersten ergebnisse sind so ermutigend das ich in in meine mplayer-configfiles übernommen habe.
    bisher setzte ich all die jahre verschiedene optimierte mplayer.sh ein um je nach anforderungen die optimale qualität zu erreichen.


    ein fester quantisierungsfaktor scheint wenig effizient zu arbeiten wärend die angabe der datenrate deutliche vorteile bringt.
    lange gops verusachen zunehmend asynchronen ton weswegen man diesen wert wohl nicht zu groß wählen sollte.
    eine sekunde scheint ganz gut zu funktionieren.


    im anhang findet ihr ein angepaßten patch für den mplayer-1.0rc2.
    kopiert in nach /libmpcodecs und führt in dort aus da er keine pfadangaben enthällt.

    na zur performancesteigerung wurde die hardwareverschlüsselung der datenströme von pci-e und sata nicht entwickelt.
    sie soll natürlich das mitloggen der keys für das drm-handling von laufwerken und erweiterungskarten verhindern.


    warten wir mal ab wie es sich entwickeln wird und ob die geplanten restriktionen überhaupt auf breite akzeptanz stoßen werden.

    die ausgabe von hdmi mit hdcp erzwingt die sichere kontrolle des nutzerverhaltens mit hilfe der software über einen rechner mit vollständig verschlüsselten datenströmen um manipulationsmöglichkeiten durch den user vorzubeugen.
    das gleiche gilt für die ausgabe des bildes über den monitor.
    dvi und vga düfen nicht in voller bildqualität ausgegeben werden um hochwertige kopien zu verhindern.


    für diese art von kontrolle ist vista vorgesehen und entsprechend vorbereitet.
    die sogenannte "premiumsoftware" verfügt über höhere privilegien als der administratoruser und kann so die steuerung und kontrolle der applikation sicherstellen.


    es ist wohl klar das diese art von technologie nicht mit freien schaffen und treiben der computeruser vereinbar ist und solange die contentwirtschaft daran festhällt wird sich auch nichts ändern.