[patch] RGB/PAL ueber VGA mit variabler Framerate

    Zitat

    Original von JoeCool25
    gibt es eigentlich irgendwelche Neuigkeiten in Bezug auf Nvidia- und i830M-Unterstützung?


    Nvidia:
    VGA2SCART funktioniert ohne Frame-Rate-Control Funktionalitaet auf den meisten nVidia Chipsaetzen. Sogar neuerdings auch mit dem OS Xorg-Xserver-DDX. Die Portierung der Frame-Rate-Control Patches auf nVidia habe ich wegen fehlender Hardware-Docs erst mal gestrichen.


    i830M:
    VGA2SCART hardwarebedingt nicht moeglich. Siehe auch:
    http://www.easy-vdr.de/forum/i…ic=6071.msg48409#msg48409

    Hallo.


    Leider weiss ich nicht ob ich hier richtig bin, also nicht gleich schimpfen^^
    Hab mir neulig einen MediaPC zusammengebaut. P4 2,8, 512MB ram, Radeon 9200SE. Am Compositausgang hängt ein Röhrentv. Die Auflösung ist auf 640x480 mit overscan. Alle anderen Auflösungen waren entweder zu verzerrt, oder der obere bildschirmrand fängt an zu zucken. Wiederholrate 60MHz.
    Nun zum Problem. Leider hab ich bei jeglicher Videowiedergabe das Gefühl, dass die Videos mit Microrucklern wiedergegeben werden. Dachte zuerst, dass die Graka zu schwach wäre, doch die Übertaktun hat nichts gebracht.
    Hat jemand eine Idee? Habe das gefühl bekommen, dass hier ähnliche Probleme bearbeitet werden.

    Hallo,


    ganz richtig :) Die Lösung hier ist ein Kabel von der VGA-Buchse auf RGB-SCART. Mit den Patches wird das Video-Signal dann mit dem Stream synchronisiert. Das behebt die Ruckler. Lese am besten den kompletten Thread. Das ist sehr sehr lehrreich.


    Viele Grüße
    HTPC-Fan

    :welcome

    Zitat

    Originally posted by Maser
    Leider weiss ich nicht ob ich hier richtig bin, also nicht gleich schimpfen^^


    wir schimpfen nicht - wir hauen gleich:)


    Zitat

    Die Auflösung ist auf 640x480 mit overscan. Alle anderen Auflösungen waren entweder zu verzerrt, oder der obere bildschirmrand fängt an zu zucken. Wiederholrate 60MHz.


    wie HTPC-Fan richtig schreibt, nutzen wir den Compositausgang gar nicht, da dessen Qualitaet einfach zu schlecht ist.
    Deine Radeon 9200SE kannst du sehr gut mit VGA2SCART nutzen. Am besten in 2 Schritten:


    1. einfache Version:
    VGA2SCART ohne Patches fuer Synchronisation. Deinterlacing ist hier nach wie vor per Software erforderlich. Ansonsten ist die Bildqualitaet aber bereits optimal. Fuer diese Variante war bis vor kurzem noch ein winziger Fix im Xserver noetig. Ich glaube aber, der Bug wurde aber inzwischen sogar offiziell gefixt.


    2. Vollversion:
    VGA2SCART mit Synchronisationspatches (im Forum auch FrameRateControl - FRC) genannt. Hier wird das Deinterlacing per Software komplett ueberfluessig, da eine 100% Synchronisation zwischen Decoder und VGA-Ausgang gewaehrleistet ist und deswegen auch keine Fields mehr verloren gehen koennen.
    Ist aber noch in keiner VDR Distribution enthalten => deswegen im Moment eher was fuer 'Fortgeschrittene' (was auch immer das heissen mag:) ).


    vielleicht noch ganz interessant:
    http://www.easy-vdr.de/forum/i…ic=5712.msg46032#msg46032
    http://www.easy-vdr.de/forum/index.php?board=63.0
    http://www.vdr-wiki.de/wiki/index.php/CheapBudget


    - sparkie

    Danke für die schnelle Antwort. Da sind aber mehrere Probleme. Ich bezweifele, dass mein Fernseher RGB unterstützt, zumindest steht im Handbuch nichts davon. Außerdem gucke ich kein normales Fernsehen, also sind schon entweder deinterlaced streams oder ganz normale divx oder mpeg4 Sachen. Und ich habe keine Ahnung was ein Xserver ist. Habe nämlich ein Win XP laufen.

    Und wir haben Linux und VDR :)

    Grüße, Dieter :)

    Maser
    Bei der Suche nach dem vga2scart-Kabel Schaltplan bin ich damals auch auf ein Windows-Forum gestoßen. Glaube es war dieses hier: Forum.
    Wenn du ein ordentliches Bild haben möchtest ist die PAL-Auflösung erstmal Pflicht, ansonsten hast du immer unschöne Skalierungsartefakte im Bild.
    Ob man mit Windows auch eine exakte framesynchrone Ausgabe hinbekommt weiss ich nicht. Da müsste ja auch jemand einen Player speziell angepasst haben, ähnlich wie die FRC-Patche.
    Darauf wirst du hier im Forum wahrscheinlich keine Antworten finden/bekommen. Hier gehts nur um Linux und VDR.
    Gruß
    Jarny

    MLD 3.0.3 Server. Aufnahmen schaue ich mit einem separaten XBMC (OpenElec Distribution) im Wohnzimmer am 47 Zoll HD Fernseher

    Hallo zusammen,


    ich hab mich jetzt nach langem lesen des ganzen Beitrags jetzt auch mal angemeldet.
    Ich muss allerdings gestehen, so recht werde ich aus der ganzen Sache nicht schlau.


    Ich kämpfe immer mal wieder mit diesem blöden Juddering und hab schon mit Powerstrip und allem möglich Blödsinn versucht, die Wiedergabe von DVD über einen HTCP an meinem Plasma HD Ready hinzubekommen.
    Wie zu erwarten...... kein Erfolg.
    Nun dachte ich, hier evtl. eine neue Möglichkeit gefunden zu haben, aber ich kapier nicht allzuviel.
    Braucht man denn nun wirklich ein spez. VGA->SCART Kabel, welches man sich selbst zusammenlöten muss ??


    Bzw. mir ist der Einstieg in die Materie noch völlig schleierhaft.


    Zitat

    1. einfache Version: VGA2SCART ohne Patches fuer Synchronisation. Deinterlacing ist hier nach wie vor per Software erforderlich. Ansonsten ist die Bildqualitaet aber bereits optimal. Fuer diese Variante war bis vor kurzem noch ein winziger Fix im Xserver noetig. Ich glaube aber, der Bug wurde aber inzwischen sogar offiziell gefixt.


    Ist denn jetzt dieses VGA2SCART eine Software und wenn ja, woher bekomme ich sie und was brauche ich sonst noch für weitere Software (Patches ?) ?


    Sorry das ich mich in den Augen des einen oder anderen vielleicht blöd anstelle, aber wenn ich's wüsste, würde ich nicht fragen.


    Besten Dank schon mal....


    Gruß


    Mike

    Danke für die neue Patch-Version vga-sync-fields-0.0.10.
    Jetzt kommt er bis zum compilieren bricht dabei aber mit einer anderen Meldung ab:

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    Einmal editiert, zuletzt von avanix ()

    Zitat

    Originally posted by avanix
    Danke für die neue Patch-Version vga-sync-fields-0.0.10.
    Jetzt kommt er bis zum compilieren bricht dabei aber mit einer anderen Meldung ab:
    [code]...


    ok, meine Patches vom 23.09.2008 passen wohl nicht mehr so ganz zu den inzwischen aktualisierten Debian Lenny Packages. Ich muss wohl mal einen Upgrade auf den aktuellen Lenny Stand machen...
    Ich schau mal, ob ich das heut noch gebacken bekomme.


    - sparkie

    Hi avanix,


    in den letzten 4 Monaten hat sich doch einiges in Lenny geaendert. Und ich habe selber ebenfalls
    einige neue Features in meine Patches eingebaut. Insbesondere war die Intellinie bislang ueberhaupt
    noch nicht in den 'vga-sync-fields' Patches beruecksichtigt. Die geistert nur als Attachment in diversen
    Forenbeitraegen herum:) Ich habe die 'vga-sync'fields' seit September 2008 ja auch nicht mehr
    offiziell aktualisiert.


    Ich versuche, dass ich einen neuen Komplett-Patch am Wochenende baue. Vorher schaffe ich
    es sicher nicht die vielen notwendigen Anpassungen/Erweiterungen in die offizielle 'vga-sync-fields' Version zu uebernehmen und zu testen.


    - sparkie

    Hi sparkie,


    wie wäre es denn, wenn du dir stattdessen doch die Patches von durchflieger mit ubuntu in Hinblick auf die X300 ansiehst? die FRC dort basiert ja auf deiner Vorarbeit, sollte also für dich machbar sein.
    Vielleicht ist das einfacher als die vga-sync-fields jetzt wieder an lenny anzupassen, das sich bis zu seinem release evtl. nochmals ändert.
    Prinzipiell wäre zu überlegen, ob es nicht Sinn macht, die radeon Linie in den durchflieger-Versionen zu pflegen und die Intel Sachen in den vga-sync-fields einzupflegen.


    Von der Usability her würde das sicher Sinn machen, da es für die Intel-Linie wohl bei easy-vdr über Skripte schon Richtung out-of-the-box Lösung geht und für durchflieger hat (ich meine mahlzeit) schon mal angefangen ein repository mit binaries aufzusetzen.


    Das wären für beide Linien Wege, die einer stärkeren Verbreitung des ganzen sicher nicht abträglich sind.


    Waren nur so meine Gedanken dazu, liegt natürlich bei dir.
    Wenn ich irgendetwas beitragen kann (das wäre wahrscheinlich hauptsächlich testen), dann bitte bei mir melden.


    grüße


    avanix

    VDR: Mainboard: MSI B85M-G43; CPU: Pentium G3250 (Haswell); NVIDIA GT630 (GK208 Kepler); SanDisk SSD 64GB SDSSDP-064G-G25 + 500 GB HD; TV: DD Cine CT V6 - Twin Tuner Karte DVB-C (PCI Express Karte); atric USB eco Einschalter

    Hi avanix


    die Sache ist ja im anderen Thread schon weiter gediehen :)


    deswegen hier nur der Vollstaendigkeit haber:


    Zitat

    Originally posted by avanix
    wie wäre es denn, wenn du dir stattdessen doch die Patches von durchflieger mit ubuntu in Hinblick auf die X300 ansiehst? die FRC dort basiert ja auf deiner Vorarbeit, sollte also für dich machbar sein.


    da ich kein Ubuntu habe, passte ich 'durchfliegers' Original README an debian lenny an. Antwort siehe hier


    Zitat

    Vielleicht ist das einfacher als die vga-sync-fields jetzt wieder an lenny anzupassen, das sich bis zu seinem release evtl. nochmals ändert.


    Anpassung ist weitgehend durch. Aber ich muss das alles noch eingehend testen.


    Zitat


    Prinzipiell wäre zu überlegen, ob es nicht Sinn macht, die radeon Linie in den durchflieger-Versionen zu pflegen und die Intel Sachen in den vga-sync-fields einzupflegen.


    richtig. Das ware sicher eine gute Moeglichkeit.


    Zitat


    Von der Usability her würde das sicher Sinn machen, da es für die Intel-Linie wohl bei easy-vdr über Skripte schon Richtung out-of-the-box Lösung geht und für durchflieger hat (ich meine mahlzeit) schon mal angefangen ein repository mit binaries aufzusetzen.


    Das wären für beide Linien Wege, die einer stärkeren Verbreitung des ganzen sicher nicht abträglich sind.


    sagen wir mal so: wenn es ueberhaupt das Ziel ist, das Ganze staerker zu verbreiten, dann ist IMHO
    die einzige Moeglichkeit die Integration in eine bestehende VDR-Distribution.
    Deswegen habe ich ja die Portierung der Patches fuer die Intel-Linie auf easy-vdr etwas ge'push't.
    Vielleicht wird das fuer die Radeons auch noch mal passieren. Aber da sind die Patches bekanntlich noch
    etwas aufwaendiger...


    Es sind einfach zu viele Aenderungen queerbeet im System erforderlich.


    Das macht zwar einerseits den Reiz des Verfahrens aus, naemlich dass die Hardware endlich mal
    vernuenftig genutzt wird. Und nicht wie bei einer FF nur dumme Steuerfunktion hat.


    Andererseits setzt das Verfahren genau abgestimmte Software-Komponenten voraus.
    Und die kann man eigentlich nur in einer Komplett-Distri sinnvoll 'verbreiten'. Da sich ja
    nicht jeder gleich in die Software-Details einarbeiten moechte...


    Zitat


    Wenn ich irgendetwas beitragen kann (das wäre wahrscheinlich hauptsächlich testen), dann bitte bei mir melden.


    klar, danke fuer das Angebot! Du hast eh schon sehr lange durchgehalten:tup
    Leider gibt es fuer Radeon noch keine Fertig-Distri und deswegen ist der Weg manchmal noch steinig:)


    - sparkie

    Hallo Leute,


    Zitat

    Originally posted by sparkie
    Ich versuche, dass ich einen neuen Komplett-Patch am Wochenende baue. Vorher schaffe ich
    es sicher nicht die vielen notwendigen Anpassungen/Erweiterungen in die offizielle 'vga-sync-fields' Version zu uebernehmen und zu testen.


    meine Tests fuer ATI und Intel sind jetzt durch. Den aktuellen Softwarestand habe ich in 'vga-sync-fields-0.0.11.tgz' zusammengefasst. Download siehe erster Post im Thread. Die Dokumentation habe ich aus Zeitgruenden noch nicht wesentlich verbessern koennen.


    Ich habe meine zur Verfuegung stehende Zeit lieber in den Support von easy-vdr gesteckt:


    Zitat

    Originally posted by sparkie
    sagen wir mal so: wenn es ueberhaupt das Ziel ist, das Ganze staerker zu verbreiten, dann ist IMHO
    die einzige Moeglichkeit die Integration in eine bestehende VDR-Distribution.
    Deswegen habe ich ja die Portierung der Patches fuer die Intel-Linie auf easy-vdr etwas ge'push't.


    eine neue out-of-the-box Version fuer easy-vdr (derzeit nur fuer Intel i9xx Chips, typischerweise wie in D945GCLF[2] oder Pundit P1-P5945GC) gibt's seit seit ein paar Tagen hier:


    1. Runde - intel - i945-X-vga2scart-0.6.02-1.4.7.sh


    viel Spass
    sparkie

    Hi,


    ich habe nun den letzten Patch von durchflieger (radeon-frc-v0.10) und sparkies
    vga-sync-fields-0.0.11 auf dem Pundit-R (IGP9100) getestet.
    Als erstes möchte ich anmerken, dass Beide problemlos funktionieren (archlinux; 2.6.28-ARCH).
    Allerdings kompiliert vga-sync-fields-patch nicht mit xv86-video-ati-6.11.0
    Der Patch geht mit ein paar hunks durch, aber:


    Code
    gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm -I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -march=i686 -mtune=generic -O2 -pipe -MT radeon_video.lo -MD -MP -MF .deps/radeon_video.Tpo -c radeon_video.c  -fPIC -DPIC -o .libs/radeon_video.o
radeon_video.c: In function 'RADEONPutImage':
radeon_video.c:2877: error: 'struct <anonymous>' has no member named 'drmFD'
radeon_video.c: In function 'vga_sync_fields':
radeon_video.c:4193: warning: suggest parentheses around arithmetic in operand of |


    Daher kann ich hier nicht direkt vergleichen; es kommt also wie vorgesehen
    xf86-video-ati-6.9.0 zum Einsatz.


    Durchfliegers Patch scheint mit den Standardeinstellungen nicht so aggressiv zu
    regeln. In den Logs sind die Nachregelungen träger, als bei sparkies Patch.
    Subjektiv gesehen, gefällt mir sparkies vga-sync-fields-Patch besser.


    Weiter Auffälligkeiten, die nicht Patch-spezifisch sind:
    Wenn ich auf Das Erste fernsehe, scheint es viel genauer zu regeln, als z.B. auf DSF. Scaling ist
    in vdr-xineliboutput-1.0.4 deaktiviert, soweit ich das beurteilen kann.
    Was kann das verursachen oder ist doch etwas in den Konfigurationsdateien (im Anhang) falsch?


    Auszug aus Xorg.0.log vga-sync-fields; Das Erste:


    Gegenbeispiel zu Obigem bei DSF (vermutlich niedrigere Auflösung)


    Zum Testen finde ich Trickfilme (ich sehe dazu Family Guy) ganz praktisch, da dort große Kontrastflächen
    vorhanden sind, die Streifen (Kammeffekt) und Umrisse offenbaren, wenn nicht nachgeregelt wird.
    Diese sind subjektiv gesehen praktisch nicht vorhanden, wenn ich den vga-sync-fields-Patch einsetze,
    beim FRC-Patch meine ich aber gelegentlich einen feinen Kammeffekt gesehen zu haben.
    Das ist natürlich eine sehr subjektive Sicht der Dinge.



    So long.

    Dateien

    configs.tar.gz 5,52 kB – 256 Downloads

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Einmal editiert, zuletzt von Hitman47 ()

    Hi Hitman47


    vielen Dank fuer deinen ausfuehrlichen Testbericht!


    Zitat

    Originally posted by Hitman47
    Allerdings kompiliert vga-sync-fields-patch nicht mit xv86-video-ati-6.11.0
    Der Patch geht mit ein paar hunks durch, aber:


    ok, ich habe 6.11.0 noch nicht im Einsatz. Aber es sollte fuer unsere Zwecke sowieso keinen Unterschied zur alten Version ausmachen.


    Zitat

    Weiter Auffälligkeiten, die nicht Patch-spezifisch sind:
    Wenn ich auf Das Erste fernsehe, scheint es viel genauer zu regeln, als z.B. auf DSF. Scaling ist
    in vdr-xineliboutput-1.0.4 deaktiviert, soweit ich das beurteilen kann.
    Was kann das verursachen oder ist doch etwas in den Konfigurationsdateien (im Anhang) falsch?


    das ARD-Log sieht wirklich gut aus. Ein fehlender Patch in xinelibout wuerde Folgen haben wie im DSF-Log zu sehen. Aber du hast (wie aus 'config_xineliboutput' zu sehen) die neuesten Sourcen im Einsatz. Deine Konfigurationsfiles sind praktisch gleich zu meinen. Daran kann es nicht liegen.


    Ich habe extra mit einem Athlon XP1700+ und einer Radeon 9200 nachgetestet. Diese Kiste duerfte sogar noch etwas schwaecher als dein Pundit sein. Zwischen ARD und DSF kann ich absolut keinen Unterschied feststellen. Beide Logs sehen bei mir so aus wie bei dir das ARD-Log. Die rechte Spalte zeigt, wie (un)regelmaessig die Frames von xine angeliefert werden.


    Solche Effekte wie in deinem DSF-Log habe ich teilweise, wenn ich das OSD offen habe, da xine hier offenbar noch einen Bug hat. Die schicken dann z.T. Frames voellig ausser der Reihe an den Xserver. Animiertes OSD tut dann noch ein uebriges:)


    Das wuerde aber den Unterschied zum ARD wiederum nicht erklaeren. Ich nehme an OSD war in beiden Faellen nicht aktiv? Auch die kurze EInblendung der Kanalanzeige? Die Test-Randbedingungen sind fuer beide Sender genau gleich? Zum Testen deaktiviere ich sicherheitshalber immer alle Plugins, ausser xinelibout.


    Noch eine Frage: den xine-lib.patch aus vga-sync-fields-0.0.11 hast du auch eingespielt?


    Die andere horizontale Aufloesung bei DSF darf nichts ausmachen.


    - sparkie

    Hi sparkie,


    Die Patches habe ich soweit alle aus dem vga-sync-fields-Patch eingespielt. Bei xine-lib ist im Log auch eine Meldung "STRAY" mehrfach vorhanden; die sollte, soweit ich weiß, erst nach dem Patchen vorhanden sein.
    Bei vdr-xineliboutput muss man ja immer etwas aufpassen, dass man auch mit " make install " die Bibliotheken für xine-lib installiert und nicht die alten verwendet. Auch das habe ich beachtet.


    Ich habe, um den Test zwischen Das Erste und DSF darzustellen, nur den Kanal gewechselt. Solange die Kanalinfo eingeblendet wird, wird scheinbar auch noch nicht geregelt:

    Code
    |<- -20ms                               0                              +20ms ->|      R                    248896
|<- -20ms                               0                              +20ms ->|      R                   1410106
|<- -20ms                               0                              +20ms ->|


    Das Bedeutet wohl, dass das OSD nicht das Problem verursacht.


    Ich habe heute noch einmal den Test wiederholt:
    Das Erste:



    Hier sind die Sprünge nicht mehr so groß wie im vorigen Test, allerdings bleibt das Verhalten gleich. Wenn ich nun wieder auf Das Erste zurückschalte, sind die Sprünge wieder wie im vorherigen Log zu Das Erste; also wohl reproduzierbar.


    Noch eine Auffälligkeit:
    Ich nutze inittab um mit init den VDR inkl. X zu starten und zu beenden. Nun ist es so, dass der Rechner gelegentlich komplett abschmiert. Debugmeldungen kann ich dabei nicht auswerten. Ich weiß nicht, ob der DRM-Patch daran Schuld sein kann. Es ist aber subjektiv so, dass das bei durchfliegers Variante seltener passiert. Es ist dabei auch scheinbar unerheblich, in welcher Reihenfolge VDR und Xserver beendet werden.
    Ich kann im Moment auch nicht ausschließen, ob vdr-xineliboutput dass verursacht. In der ungepatchten Variante ist es vielleicht auch schon einmal vorkommen. Das sind dementsprechend vage Vermutungen und ich schreibe das nur in der Hoffnung, dass sich darauf jemand etwas zusammenreimen kann.



    So long.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

    Hi Hitman47


    Zitat

    Originally posted by Hitman47
    Die Patches habe ich soweit alle aus dem vga-sync-fields-Patch eingespielt. Bei xine-lib ist im Log auch eine Meldung "STRAY" mehrfach vorhanden; die sollte, soweit ich weiß, erst nach dem Patchen vorhanden sein.


    ok Patch ist aktiv. Im xine-log erscheint ebenfalls ganz rechts eine Spalte mit der summierten Zeitdauer von 25 Frames.


    Koenntest du hier bitte einen Vergleich zwischen ARD und DSF vornehmen? Du kannst die Logs von xine und Xserver auch nebeneinander legen und die rechten Spalten vergleichen.


    Da hier die Zeitmessung noch innerhalb der xine-lib erfolgt muss ein Wert nahe 1s erreicht werden. Ansonsten haben wir ein Problem im Datenpfad xine oder davor.


    Zitat

    Ich habe heute noch einmal den Test wiederholt:
    Das Erste:


    dein ARD Log sieht ja aus wie aus dem Bilderbuch:tup Besser geht's nicht:)


    Das DSF Log ist noch verbesserungswuerdig, obwohl noch keine auf dem TV sichtbaren Probleme auftreten duerften. Es wird noch alles ausgeregelt.


    Den Effekt, dass sich unterschiedliche Sender verschieden verhalten, hatte ich allerdings noch nicht.
    Um es naeher einzugrenzen, vielleicht folgende Vorschlaege:


    - wie gesagt rechte Spalte xine-Log bei DSF kontrollieren.


    - du koenntest mal parallel eine AUfzeichnung von DSF machen und diese anschliessend abspielen. Wie sehen die DSF-Logs Live-TV verglichen mit Replay aus?


    Zitat

    Ich nutze inittab um mit init den VDR inkl. X zu starten und zu beenden. Nun ist es so, dass der Rechner gelegentlich komplett abschmiert. Debugmeldungen kann ich dabei nicht auswerten. Ich


    du meinst, alleine das Beenden von VDR (Xserver laeuft noch) verursacht das Problem?


    ich nehme an, du hast die Alpha-Console ebenfalls auf RGB/PAL umgepatcht.


    Ich hatte da mal aehnliche Probleme wenn ich den Xserver beendet habe und er dann auf die Framebuffer-Console zurueckgeschaltet hat.


    Koenntest du evtl. mal eine normale VGA Konsole (z.B. mit vga=0x301) verwenden und den Test wiederholen?


    Zitat

    weiß nicht, ob der DRM-Patch daran Schuld sein kann. Es ist aber subjektiv so, dass das bei durchfliegers Variante seltener passiert. Es ist dabei auch scheinbar unerheblich, in welcher Reihenfolge VDR und Xserver beendet werden.


    gegen ein DRM Problem spricht, dass das Beenden von VDR anscheinend ebenfalls das Problem verursacht?


    - sparkie

    Hi sparkie,


    ich kann mittlerweile praktisch keine Unterschiede zwischen DSF und Das Erste erkennen. Woran es nun
    gelegen hat kann ich gar nicht sagen, da ich nun mehrere Sachen verändert habe.
    Ich habe auf vdr-xineliboutput-cvs aktualisiert (der scr-Patch ist dort bereits integriert, verwendet wohl
    aber eine Defaulteinstellung von 5000). Daraufhin habe ich eine separate config_xineliboutput angelegt und
    per Pluginparameter mitgeteilt, wo diese liegt. Den scr-Wert habe ich dann wieder auf 200 gesetzt.
    Daraufhin konnte ich dem xine-lib-Log diese recht guten Werte entnehmen, wie ich finde:


    DSF:


    Xorg.0.log zum gleichen Zeitpunkt:


    Die Logs sehen auf Das Erste sehr ähnlich aus, allerdings nicht mehr so perfekt, wie ich es in vorigen Logs gesehen habe.
    Es sind aber auch keine Langzeittests, sondern nur kurze Abläufe, die ich gemacht habe.



    Das nächste Problem ist das Beenden von VDR und Xserver. Die Reihenfolge des Beendens scheint dabei gleichgültig zu sein.
    Der Rechner schmiert dabei, wie schon erwähnt, komplett ab. Auch die Magickeys funktionieren nicht.
    Nun habe ich die Originalmodule (drm.ko, radeon.ko) zurückkopiert und xf86-video-ati installiert. Damit bringe
    ich den Rechner nicht zum Absturz; wenigstens bis jetzt
    Weißt du Rat, wie ich das weiter eingrenzen kann bzw. wie ich den Rechnerabsturz verhindern kann. Mein Dateisystem
    scheint das nicht so gut zu verkraften, da die vdrconfigs nach dem Neustart meistens leer sind (channels.conf timers.conf)



    So long.

    Mein VDR
    vdr4arch mit softhddevice, VDR-2.2.0; KODI Mainboard: MSI 785GM-E51, CPU: iAMD Athlon II, GPU: GeForce GTX 550 Ti; nvidia:364.19, DVB1-2: DD Cine S2; DVB3-4: DD DuoFlex S2;, RAM: 1*2G DDR3, AV-Receiver Pioneer VSX-923K

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden