Posts by SledgE

    an deiner stelle würde ich als nächstes doch die funktion des empfängers erstmal testen.
    wenn du einen windowsrechner verfügbar hast würde das mit winlirc am schnellsten gehen da hier praktisch nichts zu konfigurieren ist.
    funktioniert er dort würde ich am vdr angeschlossen nochmal mit einem multimeter checken ob der com-port betriebsspannung liefert (kommt erst nach dem lirc_serial.o geladen wurde) und ob beim beleuchten mit einer fernbedienung signalimpulse zurückkommen.


    softwaremäßig scheint mir alles i.o. aber ich habe eigendlich von der c't-distri auch keine ahnung.


    viel erfolg!

    vorschau des 8.41


    morone und all die anderen leidensgenossen dürfen deshalb schon diesen monat auf 3d hoffen wenn das release freigegeben wird.
    das da was nach der übernahme von amd im busch war haben haben die spatzen ja schon längerem von den dächern gesungen.


    wenn ati erst die spezifikationen für die entwicklung offener treiber freigibt und deren entwicklung auch noch supportet wird es meiner meinung nach recht schnell gehen und es gibt dann zwei treiberlinien.
    wenn der zug erstmal richtig fahrt aufgenommen hat wird nvidia unter druck geraten.

    das drm-zeugs wird das problem sein.


    hdmi gibts nur bei erfüllung der auflagen der contentindustrie für das integrierte hdcp.
    dazu gehört u.a. verschlüsseltes interface (pci-e),copyprotection an allen hochauflösenden ausgängen und broadcastflagfunktionalität.


    meiner meinung nach muß man erstmal abwarten ob da überhaupt was brauchbares für den vdr kommt oder ob es vielleicht doch nur vistahardware wird.

    sicherheit ist doch immer relativ und der aufwand sollte in angemessenem verhältnis zur bedrohung liegen.
    viel sicherheit bekommt man schonmal durch verschlüsselung des gesamten dateisystems was einem aber teuer zu stehen kommen kann wenn der datenträger beschädigt ist und daten gerettet werden sollen.
    die schredderprogramme muß man mit vorsicht genießen den gerade unter windows sind temporäre dateinen und die auslagerungsdatei ware fundbgruben für datensammler.
    empfindliche naturen lassen deshalb die swap bei jedem runterfahren des os löschen bzw. verwenden gar keine.
    bei der verschlüsselung muß man bedenken das sie immer nur so gut ist wie die sicherheit ihrer autentifizierung.
    wenn das os/cryptsoftware das password zwischenspeichern kann man nicht mehr von sicherheit reden.


    defekte konsumerfestplatten gehen meiner meinung nach direkt in den schredder und es besteht wohl kaum ein risiko das sich da irgendwelche leute zwecks datenmißbrauch daran vergreifen.
    wer datenträger verkauft sollte halt wissen das seine daten vom os nicht wirklich gelöscht werden und ein überschreiben notwendig ist damit ein simple wiederherstellung der fat keinen erfolg bringt.
    vorsicht auch bei usb-sticks mit drm.
    sony ist mit seinen rootkits gerade wiedermal auf die nase gefallen.
    bei vista braucht man erst garnicht an sicherheit zu denken denn dort sind (vor dem admin) versteckte datenbereiche fest integriert.
    mich graut jetzt schon davor wenn in deutschen amtsstuben damit gearbeitet wird.

    jedes bit muß laut meinung von heise und einigen leuten vom ccc mindestens drei mal gekippt werden um zuverlässig eine aufwändige datenrestaurierung zu verhindern.
    deshalb reicht einmaliges überschreiben nicht aus wenn der "gegner" interna der hd-technik beherscht und nutzen kann.
    die alten magnetfelder mit den daten werden beim überschreiben in die tiefe verdrängt und können deshalb durch modifizierten kopfabstand und/oder kopfkern trotzdem wieder ausgelesen werden.
    durch mehrmaliges überschreiben mit jeweils umgekehrter magnetischer polarität werden diese felder so stark abgebaut das kein auslesen mehr möglich ist.


    für den privaten gebrauch bin ich aber der meinung das einfaches sektorbasierendes überschreiben mit dd wie von thomas vorgeschlagen ausreicht damit die alten daten vor der restaurierung durch den neuen besitzer der gebrauchten platte sicher sind.


    ps: für eine platte mit 160gb muß man mit etwa 3h rechnen.

    falls alle takte aus einem oszilator generiert werden hat shf recht.
    an den 27 mhz kann man nicht drehen da aus diesem laut datenblatt u.a. die videosignale generiert werden.
    möglich wäre auch noch der pci-bus als zweite taktquelle.
    bedarf gibt es eigendlich nur bei der streamingwiedergabe über das mplayer-plugin weil bei hoher qualität die datenraten des mpg-layer1-streams vom lavc-encoder zu groß für eine ruckelfreie wiedergabe werden und layer2 nicht implementiert ist.
    woher genau das ruckeln bei zu großen datenraten des streams kommt ist aber strittig und die meinungen darüber gehen auseinander.
    ob ein übertakten des prozessors dabei irgend etwas bringen würde ist fraglich.
    auf jeden fall hängt die performance bei diesem problem von pci-takt ab denn wenn man diesen variiert so verändert sich auch die ruckelgrenze bei der wiedergabe.
    die beste lösung des ganzen wäre zweifelsfrei ein mpeg layer2-echtzeitencoder für mplayer aber darauf warte ich schon seit jahren vergebens.
    halbherzig angekündigt war es zumindest mal.

    evt. geht es doch.
    der prozessor hat soweit ich weiß einen eigenen takt,der streaming und signalteil einen anderen.
    90 mhz und 27 mhz glaub ich.
    ob es was bringt den prozessortakt zu steigern müßte man halt ausprobieren.

    früher haben sie halt den kleber zwischen platine und bauteil gemacht und heute wird das eben von oben mit einem dreipunktgurt "angeschnallt".
    ;)


    verrmutlich waren die tantalkondensatoren in der produktion ausgegangen und man hat halt auf einen radialelko zurückgegriffen.

    natürlich wird das nie gehen wie ein blick in das datenblatt des saa7146 verrät.
    wo es klemmt merkt man schnell wenn man an seinem takt dreht.
    ob die 12mbit/s eine angabe für den arm oder die bridge waren stand nicht dabei,vermutlich irgendwie beides.


    wenn man mehrere karten verwendet hängt vermutlich alles davon ab,wie geschickt der vdr die einzelnen jobs an den engpässen herum verteilt.


    komisch,früher haben wir uns immer über blockartefakte durch niedrige datenraten und lausige mpeg-encoder beim sender geärgert,heute über zu hohe datenraten.


    meiner meinung nach wird es zeit für eine neue kartengeneration.
    hoffendlich schafft es tt uns nochmal so einen knaller hinzustellen.

    seit dem die öffendlich rechtlichen ihre bildqualitätsoffensive laufen haben wird es eng wenn mehrere sender gleichzeitig über eine karte verarbeitet werden sollen.


    neue treiber werden da nicht helfen.
    das beste wird wohl definetiv einen zweite karte sein die man bestimmt auch heute noch per lnb-sharing (gibt es den patch noch für aktuelle vdr-versionen?) an einem einzigen satkabel betreiben kann.
    die dvb-s 1.3 ist für das verarbeiten von streams bis 12mbit/s spezifiziert.
    bei den nachfolgern dürfte sich nichts geändert haben denn das problem ist der pci-bridge-chip von phillips auf der karte welcher ja gleich geblieben ist.
    wenn neuerdings auch die dritten programme mit mittleren raten von 6 mbit/s verteilt werden kann man sich leicht ausrechnen das zwei "gute" sender schon das maximum der karte ausloten.


    livebild kostet genauso viel wie aufzeichnung würde ich meinen.
    ob die software den stream zu einer datei packt und auf hd ablegt oder in zu einem monitorbild verarbeitet ist der karte ja egal.

    falls tft schau in dir vorher genau an.
    mich hat noch kein einziges vorführgerät überzeugen können.
    ich setzte deshalb auch die nächsten jahre weiter hochwertige crt ein.
    vielleicht wird es ja mit sed-displays besser,mal abwarten.

    512mb sollten doch problemloos reichen da ein durschnittlicher sender so pi*daumen 500kb/s abwirft.


    du brauchst eigendlich nur einen ordner anlegen und auf /dev/shm verlinken wenn im kernel die dynamische ramdisk aktiv ist.
    der kernel zweigt dann automatisch nur so viel ram ab wie an datenaufkommen gespeichert wird.


    mit welchen optionen dein kernel läuft kannst du in deinem konfigurationsfile (.config) sehen so du in selber gebacken hast.
    ansonnsten steht zu den laufenden kerneltreibern auch einiges im systemlogfile( normalerweise /var/log/messages).


    so sieht es auf meiner hardware aus wobei mit meiner aktuellen kernelconfiguration keine hohen latencytimereinstellungen für vga und dvb aktiv sind und es auch so prima läuft.

    definetiv keine analogen einstreuungen.
    es sind schätzungsweise 2x2 pixel große rechteckige "griesel" in einem muster aus dem sich keine struktur erkennen läßt.
    es sind ungefähr 20-60 stück welche jeweils nur für einen sekundenbruchteil zu sehen sind.
    tritt bei mir sehr selten auf aber falls ich sie wiedermal in einer aufnahme finde versuche ich mal ein bild zu extrahieren.

    nene randy,vermutlich alles digital in dieser klasse obwohl ich noch keinen sony dieser art in den fingern hatte.
    üblicherweise sieht das in etwa so aus:


    signal(e) -> a/d -> signalprozessor für bildsignalmanipulationen und osd -> d/a -> röhre.
    dazu dann noch den impulsprozessor für hk/vk/df,entzerrmagneten und induktivitäten sowie der hauptprozessor welcher alles zusammen steuert.


    er reagiert ja nicht mehr auf irgendwelche einstellungen über das osd so ich das richtig verstanden habe.


    solche teile sind schon faszinierend und kein vergleich mit dem konsumerschrott von heute.

    falls ein neuer gebrauchter angeschafft werden soll wäre mein tip ein liyama 201ht.
    ist realtiv teuer aber technisch absolutes spitzenniveau.

    kommt darauf an ob du von deinem wissen und der vorhandenen technik in der lage bist den fehler zu finden und zu beheben.
    du sollstes generell die finger davon lassen wenn du dich mit der materie nicht ausreichend auskennst.


    den schaltplan besorgst du dir aus den einschlägigen quellen.
    prüfe ob alle versorgungsspannungen des nt vorhanden sind.
    teste die funktion der microcontroller.
    wenn technisch alles i.o. scheint kommt auch eine korrupte firmware in frage.
    du kannst bei dem alter des gerätes mit hoher warscheinlichkeit davon ausgehen das es auch mehrere kalte lötstellen gibt.
    die nicht vorhandene steuerung der betriebsparameter deuten zumindest in diese richtungen.


    einfach ist sowas nicht und lohnen tut es sich auch nicht denn ein vergleichbares oder besseres gerät bekommst du für weniger als 100 eur gebraucht hinterhergeschmissen.
    hobbybasteleien haben aber kein preisschild und in diesem rahmen macht das dann noch sinn so man über die notwendigen fähigkeiten und geduld verfügt.


    ich habe drei wochen gebraucht bis mein 901ht wieder einwandfrei arbeitette.
    der als ersatzteilspender bei egay ersteigerte gleiche typ hatte mich 70 eur gekostet und war sogar ebenfalls noch ganz brauchbar.
    allein das ausdrucken des schaltplans im din a1-format mit einem posterdruckprogramm auf 8 din a4-blätter hat mich einen tag gekostet.
    ;)

    habe ich auch manchmal.
    sie befinden sich wohl im stream und sind deshalb auch in den aufzeichnungen vorhanden.
    sie sehen wie blockartefakte aus,nur das sie sehr viel kleiner sind und jeweils nur für einen kurzen augenblick auftreten.
    die von femon attestierte empfangsqualität ist dabei ganz normal und ohne jede auffälligkeit.
    eigendlich dachte ich das meine schon recht alte dvb-s 1.3 so langsam defekte zeit und gelegendlich korrupte datenströme "kreiert" aber es könnte natürlich auch vom sender selber oder dem satelitenlink herkommen.
    auf jeden fall kann man es nicht nur einem speziellen sender zuzuordnen.


    wer auch erfahrungen damit hat möge doch bitte berichten und mich beruigen so das ich nicht mehr um meine karte fürchten muß.

    nein du hast recht.
    wenn es mit der bandbreite der datenübertragung eng wird wirkt sich das osd nur aus wenn irgendwelche veränderungen am bildinhalt des osd stattfinden,also beim ein/ausblenden und navigieren.
    im extrtemfall kann das schonmal zahlreiche sekunden dauern bis das osd reagiert.
    das ist bei mir mit 2-4 gleichzeitigen aufnahmen über die eizelne ff-dvb-s der fall,je nach datenrate der jeweiligen sender.


    ich glaube nicht so recht das es mit der hd zu tun hat.
    evt. hast du irgendeinen konfigurationsbedingten "klemmer" beim streamen zur/von der karte durch deine verwendette hardware in zusammenhang mit dem laufenden kernel.


    du könntest,genug ram vorrausgesetzt, ja mal mit einer ramdisk testen.
    soll heißen provisorisch das video0-verz. des vdr auf die ramdisk legen und schauen ob das einen unterschied zur aufzeichnung gegenüber der hd macht.
    wenn es da auch "klemmt" würde ich im bereich kernelkonfiguration weitersuchen.


    apic on/off im bios beeinflußt das irq-handling welches der kernel anwendet.
    das ist also auch ein indiz für dein problem.


    deine ausgaben von lspci sehen auf jeden fall komisch aus denn irgendwie steht da überall pci-latency=0.
    busteilnehmer wie grafikkarte oder auch die dvb-s mit hohem datentransfer benötigen aber hohe werte von üblicherweise 255 clcks wärend teilnehmer mit kleinem datenvolumen i.d.r. 32 clcks zugeteilt bekommen.
    check doch mal wenn mgl. ob die richtigen chipsatztreiber in deinem kernel aktiv sind.

    wenn es mit dem vdr-standard/nextgen-skin deutlich besser ist liegt es an bandbreite des pci-interface der dvb-karte.
    mit einer karte (so wie bei mir auch) wird es dann schnell eng wenn sender mit großer datenrate von der karte verarbeitet werden UND umfangreiche osd-skins zum einsatz kommen.
    hier müßte es dann aber auch mit ard vergleichbare probleme geben.

    bios nach anleitung des mainbaordherstellers von einem wechseldatenträger neu flashen (so möglich) oder eeprom-ic des mainbaords gegen ein fehlerfrei programmiertes austauschen.
    für solche programmierten ic gibt es einen ganzen markt.


    ansonnsten,es ist nie eine gute idee unter einem multitasking-os das boardbios zu flashen.