Beiträge von Juergen.K

    Hi,


    daß der maximale Wert für "engine.buffers.video_num_frames" 30 ist, war mir nicht bekannt und ich muß ehrlich zugeben, dass zu zu bequem zum Nachlesen war. Das Ändern der Werte war eh nur "als Experiment" gedacht. :] Aber Danke für die Info, werde dies dann ändern.


    Wie bereits erwähnt, werde ich dies noch weiter beobachten. Da momentan ein grauenhaftes Konzert auf ARD HD läuft, werde ich die Kontrolle etwas aufschieben. Man, das Programm grenzt ja schon an Körperverletzung... :D



    Gruß
    Jürgen

    Hi,


    ich habe nun den Decoder in der xine config auf den vdpau_h264 und vdpau_h264_alter abgeändert. Leider zeigt das Bild bei mir immer noch kurze Aussetzer (bei ARD HD ist es besonders schlimm).


    Beim Stöbern in der xine-config unter yaVDR 0.4 bin ich auf die Parameter engine.buffers.audio_num_buffers, engine.buffers.video_num_buffers und engine.buffers.video_num_frames gestossen. Allen drei sind grössere Werte zugeordnet, als per Standard vorgesehen ist.


    Um es nun kurz zu machen, eine weitere Erhöhung der ersten beiden Puffer brachte nichts, jedoch wenn ich den dritten Puffer (...num_frames) auf 44 erhöhe, sind die Aussetzer weg. Zumindest habe ich in den letzten 20 Minuten keinen mehr entdeckt, mit dem kleineren Wert von num_frames steht das Bild so ca. alle 10 bis 20 Sekunden mal kurz still. Ich werde das ganze nun mal weiter im Auge behalten und vielleicht hilft es ja auch jemand...



    Gruß
    Jürgen

    Hallo,


    das passt ja sozusagen wieder wie die Faust aufs Auge. Ich habe heute Mittag einen yaVDR 0.4 aufgesetzt mit einer SkyStar USB HD und wundere mich, warum nur die HD-Kanäle der ARD immer wieder kurze Aussetzer haben. Ich bin schon seit heute Mittag am suchen und hatte schon vom Treiber bis hin zur USB-Box alles mögliche im Verdacht gehabt und dementsprechend auch schon neue Treiber installiert usw. Naja, nun werde ich mich lieber mal in Geduld üben und hoffen, dass es wirklich von den Sendeanstalten kommt und die das Problem lösen werden.


    @macmat: Danke noch für den Link, ich hatte das Thema wohl irgendwie überlesen.


    Gruß
    Jürgen

    Hallo durchflieger,


    ich habe die neue Version des atmo plugins nun rund eine Stunde lang getestet, sprich gequält. Mir ist es in dieser Zeit nicht mehr gelungen, auch nur einen der beiden Fehler zu reproduzieren. In den Aufnahmen springen bzw. Starten des playbacks auf einer Markierung usw. scheinen nun perfekt zu laufen. Werde es aber noch etwas weiter testen und Dich auf dem Laufenden halten.


    Gruß
    Jürgen

    Hallo durchflieger,


    ich habe die neue Version gezogen, installiert und die letzte halbe Stunde getestet. Vor- und Zurückspringen in den Aufnahmen funktioniert ohne Probleme, ebenso das Verschieben von Schnittmarken.


    Jedoch ist mir noch eine Kleinigkeit aufgefallen. Man nehme eine "frische" Aufnahme und lasse noad über die selbige laufen zwecks Markieren der Werbeblöcke. Wenn Du nun in die Aufnahme gehst und der VDR versucht diese von der ersten Markierung an abzuspielen passiert zuerst einmal nicht viel. Das Playback wird gestartet und aus deinem vorherigen Live Bild wird ein Standbild. Drückst Du keine Taste an der FB, bleibt die Kiste in dem beschriebenen Zustand (4 Minuten gewartet). Andernfalls kannst Du nach ca. 5 bis 10 Sekunden versuchen die Pause Taste zu drücken und dann läuft das Playback ab. Frage mich bitte nicht womit das zusammenhängt, ich habe nicht den blassesten Hauches eines Schimmers einer Ahnung.... Die Version des atmo-Plugins von gestern zeigt das gleiche Verhalten und ohne atmo-Plugin tritt dieser Effekt nicht auf.


    Im übrigen hier dann noch die Meldungen der Konsole:


    atmo: DF10CH[5,23]: device opened
    atmo: output driver opened
    atmo: configure channels top 2, bottom 0, left 2, right 2, center 0, topLeft 1, topRight 1, bottomLeft 1, bottomRight 1
    atmo: max/avg transmit latency: 7329/3664 [us]
    atmo: grab thread running
    atmo: output thread running
    prebuffer=14400 pts
    atmo: output thread waiting for new ticket
    atmo: grab thread waiting for new ticket
    prebuffer=14400 pts
    atmo: output thread got new ticket
    atmo: grab thread got new ticket
    atmo: output thread terminated
    atmo: grab thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: max/avg transmit latency: 8001/5832 [us]
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    prebuffer=14400 pts
    atmo: grab thread terminated
    atmo: max/avg transmit latency: 10547/8825 [us]
    atmo: output thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 14006/10650 [us]
    atmo: max/avg transmit latency: 14505/11378 [us]
    atmo: max/avg transmit latency: 17021/12466 [us]
    atmo: max/avg transmit latency: 19036/13283 [us]
    200 Bilder angezeigt, 0 Bilder übersprungen, 3 Bilder verworfen
    video_out: Verwerfe Bild mit pts 4141227, weil es zu alt ist (Unterschied: 4147).
    200 Bilder angezeigt, 0 Bilder übersprungen, 1 Bilder verworfen
    prebuffer=14400 pts
    atmo: output thread terminated
    atmo: timeout while waiting for thread stop!
    atmo: grab thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17



    Gruß
    Jürgen

    Hallo durchflieger,


    das neue commit des xine-lib-atmolight Post-Plugins scheint zu funktionieren. Ich habe es nun innerhalb 20 Minuten andauernder Versuche nicht mehr geschafft den Fehler zu reproduzieren. Mit der alten Version konnte ich den Fehler jedes mal binnen höchstens 10 Sekunden provozieren.


    Ich muß ehrlich zugeben, Hut ab vor Deiner Leistung. Du konntest den Fehler lokal bei Dir nicht nachvollziehen und hast mit dem Fix, so wie es momentan aussieht, auf Anhieb einen Volltreffer gelandet. Danke!



    Gruß
    Jürgen

    Hallo durchflieger,


    wie bereits angedroht eine Fehlermeldung. Wenn Du minutenweise in einer Aufnahme schnell hin und her springst, friert der komplette VDR nach spätestens 15 bis 20 Sprüngen ein. Das gleiche passiert fast immer, wenn du auf eine Schnittmarke springst und diese versuchst etwas nach links oder rechts zu verschieben.


    Im "Normalbetrieb" - egal ob live oder playback - läuft das Atmolight stundenlang ohne Probleme. Die oben geschilderte Problematik tritt nur auf, wenn der vdr mit xineliboutput wie folgt gestartet wird: "xineliboutput --local=sxfe --video=xv --remote=37890 --post atmo:driver=df10ch". Ohne den "--post atmo..." Parameter tritt der Fehler nicht auf. Die eingesetzte xine-lib habe ich heute Mittag aus dem git repo gezogen. Der Controller hängt an einem Hub, welches mit externer Spannungsquelle versorgt wird.


    Auf der Konsole wird u. a. das folgende protokolliert(ich war minutenweise in einer Aufnahme am Springen):
    atmo: output driver opened
    atmo: configure channels top 2, bottom 0, left 2, right 2, center 0, topLeft 1, topRight 1, bottomLeft 1, bottomRight 1
    atmo: max/avg transmit latency: 7147/3573 [us]
    atmo: grab thread running
    atmo: output thread running
    prebuffer=14400 pts
    atmo: output thread waiting for new ticket
    atmo: grab thread waiting for new ticket
    prebuffer=14400 pts
    atmo: output thread got new ticket
    atmo: grab thread got new ticket
    atmo: output thread terminated
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: grab thread terminated
    atmo: max/avg transmit latency: 7328/5450 [us]
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 7843/6646 [us]
    prebuffer=14400 pts
    prebuffer=2000 pts
    prebuffer=14400 pts
    prebuffer=14400 pts
    atmo: max/avg transmit latency: 8150/7398 [us]
    atmo: output thread terminated
    atmo: grab thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: max/avg transmit latency: 8261/7916 [us]
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: max/avg transmit latency: 9217/8271 [us]
    atmo: max/avg transmit latency: 9314/8351 [us]
    atmo: max/avg transmit latency: 13644/10719 [us]
    atmo: max/avg transmit latency: 17861/12757 [us]
    atmo: max/avg transmit latency: 19189/13223 [us]
    200 Bilder angezeigt, 5 Bilder übersprungen, 0 Bilder verworfen
    video_out: Verwerfe Bild mit pts 2579434, weil es zu alt ist (Unterschied: 3775).
    video_out: Verwerfe Bild mit pts 2874634, weil es zu alt ist (Unterschied: 3931).
    200 Bilder angezeigt, 0 Bilder übersprungen, 2 Bilder verworfen
    atmo: output thread terminated
    atmo: grab thread terminated
    prebuffer=14400 pts
    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: output thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: grab thread terminated
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: DF10CH[5,22]: submitting USB control transfer message failed: Resource busy
    atmo: output thread terminated
    atmo: grab thread running
    atmo: output thread running
    atmo: grab thread terminated
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: grab thread terminated


    ---> eingefroren



    Gruß
    Jürgen

    Hallo durchflieger,


    ich habe mir heute Nachmittag die neue xine-lib mit dem df-xine-lib-extensions-patch herunter geladen und installiert. Das grabben funktioniert ebenfalls sehr gut. Die von Dir angesprochenen Versuche werde ich leider erst am Wochenende durchführen können.


    Soeben ist mir allerdings etwas aufgefallen. Wenn Du minutenweise in einer Aufnahme schnell hin und her springst, friert der komplette VDR nach ca. 15 bis 20 Sprüngen ein. "Verschluckt" sich da u. U. das post-Plugin?? Auf der Konsole wird dann folgendes ausgegeben:


    atmo: grab thread running
    atmo: output thread running
    atmo: analyze size 128x102, grab 678x542@21,17
    atmo: DF10CH[3,3]: submitting USB control transfer message failed: Resource busy
    atmo: output thread terminated


    Die Hardware hängt im übrigen an einem USB-Hub, welches mit Strom versorgt wird.



    Gruß
    Jürgen

    Hallo,


    wenn ich einmal ganz kurz die Diskussion unterbrechen darf...


    Ich habe den neuen xineliboutput-df-xine-lib-extensions.patch.gz Patch von durchflieger gestern Abend getestet und bin mit dem Resultat sehr zufrieden. Das grabben der Bilder und die Aufbereitung für den DF10CH Atmolight Controller funktionieren bei mir mit dem xv output driver sehr gut.


    Ein dickes Lob an durchflieger und herzlichen Dank.



    Gruß
    Jürgen

    Hi,


    über die weitere Vorgehensweise da muss ich mir noch ein paar Gedanken machen. Vom Prinzip sehe ich drei Möglichkeiten:


    1.) Den vorhanden VDR auf auf HD aufrüsten (die passende Hardware liegt schon seit 6 Monaten im Schrank).
    2.) Dem atmo-plugin den DF10CH Controller beibringen.
    3.) Dem nativen Plugin VDPAU "austreiben" und notfalls via XShmGetImage() o. ä. versuchen zu grabben.


    Die Punkte zwei und drei werden wohl bei meinen rudimentären C-Kenntnissen die Herausforderung des Jahrhunderts. :lol2


    Ich werde einmal eine Nacht darüber schlafen, mal sehen wie ich das gerade biege.



    Gruß
    Jürgen

    Hallo allerseits,


    jetzt muss ich doch mal ganz dumm fragen. Mit welchen Plugins bekomme ich den DF10CH Atmolight Controller angesteuert? Gefunden habe ich das Native Xine Atmolight plugin (xine-lib-atmolight), welches aber wohl zwingend eine NVidia Grafikkarte mit VDPAU Unterstützung benötigt. Mit letzterem kann ich nicht dienen, da ich einen Intel i945 im VGA 2 Scart Betrieb in Kombination mit dem vdr-xineliboutput Plugin nutze.


    Gibt es noch ein anderes Plugin mit dem die Hardware angesteuert werden kann? Falls nicht, sollte man vielleicht noch einen Hinweis im Wiki verfassen, dass VDPAU zwingend erforderlich ist(wobei ich dann mit Sicherheit nicht in den letzten drei Tagen die Hardware komplett aufgebaut hätte) :schiel


    Gruß und Danke
    Jürgen

    Hallo allerseits,


    ich habe mir beide Thread's durchgelesen und muss ehrlich zugeben, ich bin vor Wut leicht am Kochen. Ich benutze schon seit etlichen Jahren den VDR und bin auch hier, zumindest als Gast, seit vielen Jahren lesenderweise unterwegs. Ebenso wie oben bereits von mav_ erwähnt, kann auch ich mich noch an die Zeiten von LinVDR & Co. erinnern.


    Ohne auf mein "Köcheln" näher eingehen zu wollen, möchte ich das yaVDR-Team bitten auf jeden Fall hier zu bleiben.



    Gruß
    Jürgen

    Hallo allerseits,


    mal eine bescheidene Frage. Wenn ich an das Mainboard mit einem DVI2HDMI Adapter einen Fernseher anschließe, wird dann auch der Ton über das HDMI-Kabel durchgereicht? Ich weiß nämlich nicht, ob dies die Hardware des DVI Anschlußes überhaupt mitmacht und ehe ich mir nun einen Wolf suche...


    Ich habe gerade eine etwas ältere VDR-Installation basierend auf Ubuntu 9.10(Karmic Koala) wie oben beschrieben angeschlossen und was soll ich sagen, Bild okay aber kein Ton...



    Danke und Gruß
    Jürgen

    Hi sewn4,


    das Problem kenne ich zur Genüge. Die Nummer hat mich einige Stunden gekostet und ich bin mir alles andere als sicher, dass ich dies jemals wieder zusammenkriege. :evil:


    Fahr die Kiste doch mal hoch, beende den X-Server und logge Dich auf der Konsole ein. Wechsle dann per sudo bash auf "Root - Ebene" und tippe mal lsmod | grep nouveau ein. Ist das besage Modul geladen? Falls ja scheitert genau da dran die Installation des NVidia Treibers. Bei mir lies sich das Modul noch nicht einmal mit einem rmmod --force nouveau entladen, obwohl der X-Server und alles drum und dran down war.


    Falls dies auch bei Dir zutrifft, boote mal im Wiederherstellungsmodus und teste nochmal auf das Modul. Wenn Du Glück hast, kannst Du es wenigstens dann per rmmod rauswerfen und das NVidia Setup durchlaufen lassen.


    Die weiterführende "Brutalo Methode" (nicht wirklich zu empfehlen, dabei kannst Du Dir die Installation abschießen) besteht darin, das nouveau.ko aus /lib/modules/22.6... zu "entfernen". Nun depmod -a durchlaufen lassen und eine neue initfamfs erstellen. Dies hat bei mir ausgereicht, dass nouveau.ko nicht mehr in der initial ramdisk vorhaden ist. :schiel (Zumindest bis zum nächsten Kernel update)


    Da meine Zeit stark begrenzt ist und ich nicht unbedingt an jedem Problemchen etliche Stunden verbringen will, kannst Du dir meine Vorgehensweise ja vorstellen. Lass die Einträge in der blacklist.conf ruhig drin.


    Vermutlich gibt es noch viel einfachere Wege - aber zuerst einmal einen kennen....



    Gruß
    Jürgen

    Hi allerseits,


    der Film und die 3D-Effekte waren ja soweit recht nett. Bezüglich der Fokussierung stimme ich netvista-fan zu, es war manchmal recht schwierig.
    Avatar ist mittlerweile mein dritter Film, welcher ich mir in 3D angesehen habe. Faierweise muss ich jedoch sagen, dass mir die Effekte in Final Destination 4 wesentlich besser gefallen haben. Sie waren "ausgeprägter" und man zuckte das ein oder andere mal mehr zusammen.(z. B. das Auto welches plötzlich auf dich zukommt usw.)
    Unter dem Strich betrachtet wird Kino nun wieder viel interessanter, es ist einfach ein Erlebnis. Bleibt nur zu hoffen, dass die Filmindustrie mehr Filme in 3D produzieren wird.


    Gruß
    Juergen