Posts by gnapheus

    Ersteinmal ein dickes Dankeschön an alle die dieses Portal möglich machen und ihre Freizeit hier investieren.


    Leider muss ich auch sagen, dass ich das neue Design schlechter finde als das alte. Die Gruende dafür wurden bereits alle genannt. Ich bin wohl auch einer der ewig gestrigen. Mir hätte eine bessere Suchfunktion vollkommen gereicht. Mal sehen wie man sich an das neue Design gewöhnen kann. Momentan ist das Portal aber noch schrecklich langsam.


    LG


    Joachim

    Aus der ML:


    Ja, das sagte ich bereits

    Quote

    Original von gnapheus
    Dein Motherboard hat anscheinend keinen internen SPDIF Ausgang. Vielleicht kannst du einer der Klinkenbuchsen ein SPDIF Signal entlocken (im Treiber umstellen ..). Das SPDIF-Signal kannst du dann wieder ins Gehäuse auf deine Karte führen.
    Alternativ könntest du eine günstige, kleine PCIe Soundkarte mit internen SPDIF Sockel einbauen.


    Wo ein Wille ist, ist auch ein Weg ...

    Quote

    Original von helau


    Aber ein Bug ists trotzdem ;)


    Ehrlich gesagt ist es nicht wirklich ein Bug von text2skin. Das Problem ist nur das vdr die Livebuffer-Aufnahme keinen Namen zuweist. Normalerweise gibt es im vdr eine Fallbackroutine, die sicherstellt, dass die Aufnahme einen Namen bekommt. Diese funktioniert aber nur, wenn die Aufnahme in der Verzeichnisstruktur vom vdr gespeichert wird. Genau das ist meine Anpassung für den Liverbufferpatch gewesen. Ich würde also sagen es ist eher ein bug im livebuffer patch.


    LG


    Joachim

    Ich persönlich möchte einfach nicht die "Bürde" des Maintainers übernehmen, da ich nicht gewährleisten kann, dass ich mich dauerhaft um das Plugin kümmern will. Wenn ich dann das Plugin bei vdr-projects übernehmen würde, dann läuft das am Ende so wie beim "aktuellen" Maintainer. Von mir aus kann jeder yaepghd-ce als yaepghd auf vdr-projects fortführen.


    LG


    Joachim

    Etwas googlen zeigt, dass der untere Anschluss für einen Lüfter ist. Der zweite Anschluss wird sehr wahrscheinlich für SPDIF pass through sein. Bei Amazon schreibt einer für ein Model mit Lüfter, dass das Kabel leider nicht dabei war. Mit etwas suchen findest du bestimmt eine Bestätigung für meine Annahme.
    Dein Motherboard hat anscheinend keinen internen SPDIF Ausgang. Vielleicht kannst du einer der Klinkenbuchsen ein SPDIF Signal entlocken (im Treiber umstellen ..). Das SPDIF-Signal kannst du dann wieder ins Gehäuse auf deine Karte führen.
    Alternativ könntest du eine günstige, kleine PCIe Soundkarte mit internen SPDIF Sockel einbauen.


    Alle Angaben ohne Gewähr und auf eigene Gefahr!


    LG


    Joachim

    Quote

    Original von Mreimer
    Die aktuell übliche VDR Client/Server Lösung basiert auf einer kleinen Auswahl an Plugins. Die Clients haben dann auch VDR laufen. Soweit ich weiß kann man dann vom Client aus entweder den Server aufnehmen lassen (Timer auf dem Server setzen) oder der Client nimmt auf. Alle Clients haben Zugriff auf die Server-Aufnahmen, ....


    Gerade die mittlerweile sehr guten Möglichkeiten für Client-Server-Betrieb aus mehreren VDR-Installationen wurden in der Vergangenheit immer mal wieder als Vorteil von VDR genannt.


    Dessen bin ich sehr wohl bewusst. Das ändert aber nichts daran, dass vdr laut kls nicht dafür konzipiert wurde.


    LG


    Joachim

    +1 für Plugin


    Vdr ist von der Basis her sowieso nicht als Backend oder Streaming Lösung gedacht. Ich denke, dass für alle, die den vdr "nur" als lokalen video disc recorder einsetzen, eine Pluginlösung ala Softdevice am einfachsten ist. Ich frage mich sowieso, wie viele vdr user wirklich eine client server Struktur haben. Ich weiß, dass viele, die hier im Forum aktiv sind, sowas haben, aber es gibt ja auch noch die passiven vdr nutzer. Ich würde annehmen, dass es dort weit weniger sind.


    Aber vielleicht lässt sich ja, wenn erstmal ein plugin bzw. client für vaapi da ist, das jeweils fehlende ergänzen.


    LG


    Joachim

    Vorsicht OT ;)


    Quote

    Original von Torsten73
    Denn bisher muß die CPU beim OSD einfach zu viel Arbeit übernehmen, was auf den ATOM Systemen und anderen leistungsschwachen Lösungen zu den bekannten Bildstörungen führt, sobald das FullHD OSD genutzt wird und der Theme etwas aufwendiger ist.


    Das Problem erlebe ich auch gerade. Hast du ein paar Thread Links zur Hand, wo das diskutiert wird ?


    LG


    Joachim

    steffen_b

    Quote

    - Pufferort müsste noch verbessert werden


    Könntest du, dass genauer ausführen. Als ich den Parameter getestet habe, hat er die ts Datei dort im Verzeichnis ./Livebuffer/..[datum]../ abgelegt.



    Bei Cleanup habe ich sowieso, wie gda bemerkt hat, noch Klammern vergessen


    Code
    +bool cLiveRecorder::Cleanup(bool RemoveDir) {
    +	if(FileName()) 
    +	    if (RemoveDir)
    +			if(-1 == system(cString::sprintf("rm -r %s/%s/*", BufferDirectory,"LiveBuffer")))
    +				return false;
    +		else
    +			if(-1 == system(cString::sprintf("rm %s/*", FileName())))
    +				return false;


    sollte so sein aussehen


    Code
    +bool cLiveRecorder::Cleanup(bool RemoveDir) {
    +	if(FileName()) 
    +	    if (RemoveDir)
    +          {
    +			if(-1 == system(cString::sprintf("rm -r %s/%s/*", BufferDirectory,"LiveBuffer")))
    +				return false;
    +          }
    +	    else
    +			if(-1 == system(cString::sprintf("rm %s/*", FileName())))
    +				return false;

    Hi ,


    ich habe mal wieder den livebuffer patch aus den rmm sourcen neu gebaut. Im Anhang ist einmal ein Patch, in dem nur die rmm Änderungen enthalten sind (vdr-1.7.16-livebuffer-rmm9.diff), und eine Version mit den Änderungen aus diesem thread (vdr-1.7.16-livebuffer9.diff). Nach meiner Ansicht ist das Problem mit den wachsenden buffer files noch nicht gelöst. Außerdem will vdr-1.7.16-livebuffer9.diff bei nicht mit text2skin zusammen laufen. Beim starten kommt ./PLUGINS/lib/libvdr-text2skin.so.1.7.16: undefined symbol: _ZN6cTimerC1EbbP8cChannel (Text2skin ist neu gebaut gegen gepatchten vdrt). Vielleicht kann ja mal jemand herausfinden woran das liegt.


    LG


    Joachim

    Ich habe hier noch ein altes Gehäuse von einen FS Scenic 600 rumliegen. Die Front habe ich schon soweit geglättet um eine eigene Blende anzubringen und innen Platz für ein ATX-Board geschaffen. Sollte am Ende so aussehen Mein VDR-Gehäuse . Ich bin über eine Pappblende mit Tesafilm befestigt aber nicht hinausgekommen :versteck.


    Du kannst das Gehäuse gerne bei mir abholen oder gegen Versandkosten haben.


    LG


    Joachim

    Quote

    Original von halbfertiger


    Das erledigt man prima mit CSS und Userstyles. Dann merkst du nicht dass du einen Firefox vor dir hast.


    Könnte man damit auch die Erweiterungen von ce-html implementieren ? Mich wundert, dass außer Opera noch kein html-renderer (Webkit / Gecko) offiziell ce-html unterstützt.


    LG


    Joachim

    Quote

    Original von warp10
    Vielen Dank für das Plugin!


    Hätte eine Frage: Gibt es eine Möglichkeit, das Plugin sozusagen als Standard zu definieren? D.h. wenn ich im normalen TV-Betrieb auf 'hoch' oder 'runter' drücke, soll nicht der Sender gewechselt werden sondern die EPG-Info des nächsten/vorherigen Senders angezeigt werden. Im Moment muss ja immer das Plugin auf irgendeine Weise gestartet werden, sei es über das Hauptmenü oder auf einer der Farbtasten (z.B. blau).


    Danke und Gruß
    Thorsten


    Ich denke nicht, das das im Rahmen des Plugins möglich ist. Dafür müsste die Funktionalität des Plugins direkt in den vdr gepatched werden. Bei mir liegt der ZapPilot auf Gelb ;) .


    LG


    Joachim

    Hallo Leute,


    da ich das hbbtv Thema sehr spannend finde, beschäftige ich mich zurzeit ein wenig mit der Umsetzung für einen vdr. Es braucht erst einmal zwei Dinge:
    1. einen Browser der die ce-html Seiten mit hbbtv-extensions anzeigen kann (rudimentärer Ansatz siehe hier Internetbrowser für hbbtv ),
    2. einen Plugin, dass die URLs aus dem DVB Datenstrom filtert.
    Im Prinzip ist es recht einfach an die URLs z.B. mit dvbsnoop zu kommen, siehe z.B. hier http://www.i-have-a-dreambox.c…ostid=1424203#post1424203
    Beispiel mit dvbsnoop:


    Eine komplette Ausgabe für den entsprechenden application_signalling_descriptor vom Ersten ist im Anhang. Es sollte doch also relativ einfach sein, einen entsprechenden Filter für den vdr zu programmieren, der nichts anderes macht als die URL und den application_control_code auszugeben / speichern. Im Anhang ist ein erster Versuch von mir dies in ein Plugin zu packen (für vdr-1.7.16). Da ich leider nicht wirklich Ahnung von der Struktur des DVB-Streams habe und wie man damit umgeht, konnte ich eigentlich nur Teile aus anderen Plugins (z.B. Premiereepg) zusammen kopieren und die Descriptoren und Streams anpassen. Und welch ein Wunder, es ist doch nicht so einfach, zumindest für einen Laien. Das Plugin kommt zwar bis zum Stream 5 Datenpacket (für hbbtv), dann kommt aber ein Fehler beim Parsen des Datenpakets mit SI:cAIT .


    Lange Rede kurzer sind: Gibt es hier einen Profi, der mir sagen kann, wo das Problem liegt ?


    LG


    Joachim


    PS: Die Leute vom i-have-a-dreambox Forum haben schon mal ein standalone tool hbbtvscan:
    http://www.i-have-a-dreambox.c…ostid=1429853#post1429853


    Das sollte der Browser von alleine machen und hängt von der Webseite ab. Das Beispiel ist die ARD epg Ansicht, wenn ich mich recht erinnere.


    LG


    Joachim