Beiträge von msv

    Hi,


    das Problem kenne ich. Auf meinem Desktop VDR zum Nachbearbeiten habe ich das Gleiche (manchmal - momentan wieder immer). Wenn ich das Aufzeichnungsmenu aufmache gibts einen Crash. Bin hier inzwischen wieder auf LCARS gegangen. Hatte das immer auf meine Xineliboutput Ausgabe geschoben (wegen der anderen Probleme damit allerdings nur ein Bauchgefühl...). Aber da fragte Louis sich ja schon selber, ob er da Lust hat zu debuggen. Scheint aber wohl nicht nur mein Problem zu sein...


    Gruß
    msv

    Hallo,


    hat schon jemand das mailbox-plugin unter GCC6 zum laifen gebracht? Ich bekomme immer Fehler, wie diese:


    Code
    ...
    AxPluginSetup.cpp: In Elementfunktion »bool AxPluginSettings::parseSetup(const char*, const char*)«:
    ./AxLib/include/Ax/Tools/Trace.h:44:37: Fehler: literaler Operator für Zeichenketten »operator""Y« mit Argumenten »const char [10]«, »long unsigned int« konnte nicht gefunden werden
     #define wswarnsyslog(Y...)  isyslog("mailbox: "Y)
    ...                                     ^


    oder, wenn ich das durch einen per google gefundenen Tipp in dem File AxLib/include/Ax/Tools/Trace.h von


    Code
    ...
    //-----------------------------------------------------------------------------
    //     define macros for users
    //-----------------------------------------------------------------------------
    #define wsdebugsyslog(Y...) dsyslog("mailbox: "Y)
    #define wswarnsyslog(Y...)  isyslog("mailbox: "Y)
    #define wserrorsyslog(Y...) esyslog("mailbox: "Y)
    ...


    nach

    Code
    ...
    //-----------------------------------------------------------------------------
    //     define macros for users
    //-----------------------------------------------------------------------------
    #define wsdebugsyslog(Y...) dsyslog("mailbox: " Y)
    #define wswarnsyslog(Y...)  isyslog("mailbox: " Y)
    #define wserrorsyslog(Y...) esyslog("mailbox: " Y)
    ...


    geändert habe kommt dann dies hier:



    ... und hier reicht mein rudimentäres Verständnis für C++ nicht aus....


    Gruß
    msv

    Das hört sich doch gut an. Werde ich mal nächstes Jahr ausprobieren.


    Ich hatte bisher Quicksteuer am Start in einer Virtualbox mit Win7. Hab schon mal ein verordnetes Update durch Lexware von Win2000 auf Win7 gemacht. Aber den Blödsinn will ich nicht wiederholen, wenn die auf die Idee kommen sollten, das Ganze nur noch auf Win10 laufen zu lassen. Und das kommt bestimmt... $$$


    Danke und Gruß
    msv

    ... ich antworte mir mal selber (nachdem ich jetzt (gefühlt) das halbe Internet durchsucht habe.


    wenn ich die Optionen (rot )in der Section "Screen" meiner xorg.conf zufüge gehts



    vielleicht hilfts ja jemandem
    msv

    Hi,


    hab ein kleines Problem mit meiner neuen Konfiguration VDR (ZOTA -> DENON AVR1912 -> Samsung TV (alles über HDMI). Bisher hatte ich immer VDR per HDMI direkt am TV und Ton dann über TOS an den AVR gegeben. Dabei gibt mein Samsung TV aber anscheinend nur Stereo an den AVR ab. Ich hab das ganze jetzt neu aufgesetzt eben so wie in ersten Satz. Der Sound ist auch wirklich toll jetzt. Dolby scheint jetzt wirklich Dolby zu sein. Und der AVR schaltet auch die Audio-Modes entsprechend dem Eingangssignal um. So soll es wohl sein.


    Nun zu meinem Problem. Mein VDR läuft immer durch (24x7). Wenn ich jetzt den TV und AVR einschalte habe ich keinen Ton mehr vom VDR zum AVR. Bild ist da. Im AVR habe ich das ganze HDMI Steurungsgedöhns abgeschaltet. Also einfach HDMI3 (SAT/CBL) rein und über den TV Ausgang dann zum TV HDMI(1) Eingang. Trotzdem scheint der AVR beim Abschalten den Ton wohl im VDR irgendwie zu "verriegeln".


    Im VDR habe ich die letzte Version des Softhdhevice Plugins laufen:


    Code
    root@stereo2:/usr/local/src/VDR/PLUGINS/src/softhddevice# git status
    Auf Branch master
    Ihr Branch ist auf dem selben Stand wie 'origin/master'.
    nichts zu committen, Arbeitsverzeichnis unverändert


    der letzte logeintrag ist dieser:

    Code
    root@stereo2:/usr/local/src/VDR/PLUGINS/src/softhddevice# git log
    commit 6dfa88aecf1b5a4c5932ba278209d9f22676547f
    Author: Johns <johns98@gmx.net>
    Date:   Tue Nov 3 11:39:41 2015 +0100
    
    
        Preparations for new ffmpeg VDPAU API.


    Hier noch alle setup.conf Einträge für das Plugin:




    Als workaround habe ich mir ein kleinen HDMI Resetscript auf eine meiner fernbedienungstasten gelegt:


    Code
    # cat resethdmi.sh 
    xrandr -display :0.0 --output HDMI-0 --off
    xrandr -display :0.0 --output HDMI-0 --auto


    Es funktioniert so zwar, aber ist doch sicherlich nicht im Sinne des Erfinders (johns98 ???). Hat jemand das gleiche gehabt und eine bessere Lösung dafür gefunden?


    VDR Hardware ist ein "Motherboard by ZOTAC Motherboard D2550ITXS-B-E/D2550ITXS-B-E, BIOS A212P010 09/21/2012"


    gruß
    msv

    Hi,


    Schade, dann wohl erstmal ohne Skindesigner. Sieht zwar toll aus, aber ich habe schon zu viele Plugins den Jordan runter gehen gesehen um jetzt mein Plugin von der geänderten Funktionalität eines anderen Plugins abhängig zu machen.


    Für mich ist hier das Standard API des VDR die Messlatte und da wurden TABS in Menuitems wie in einer Textverarbeitung implementiert, d.h. ich kann mit einem "\t" zur nächsten Spalte springen, aber ich kann den Text auch einfach bis zum Zeilenende laufen lassen. Diese Funktionalität hast du ja nun leider gegen ein anderes Construct getauscht, ohne die alte Funktionsweise alternativ bestehen zu lassen. Ebenso hast du die Formatierung und das Tab-handling von nicht selektierbaren Menuitems so verändert, daß sie eigentlich nicht mehr für normalen Text in solch einem Menu zu gebrauchen sind. Auch hier wieder alternativ los zum "klassischen VDR". Vielleicht fällt dir hierzu ja noch irgendwann eine Lösung ein...


    Aber wie gesagt, ich glaube, daß du den richtigen Weg eingeschlagen hast, dem VDR ein schöneres Gesicht zu geben. Denn die neuen Skins sehen einfach klasse aus. Aber der Hauptzweck des VDRs ist es, Live-TV und Aufnahmen wiederzugeben. Und wenn ich mir überlege, wie das zeitliche Verhältnis zwischen dem Anschauen von TV Inhalten und dem Erfreuen an schönen OSD Skins ist, schlägt das Pendel doch zu Gunsten des TV-Inhaltes aus. Also irgend ein Skin ( und wenn es LCARS ist) wirds schon tun.


    Trotzdem Danke für die Tipps
    msv

    Das hat nichts geändert.


    Ich mache das so:


    Code
    myFilmeDetailMenu::myFilmeDetailMenu() :
            cOsdMenu(tr("Details")) {
            SetMenuCategory(mcPlugin);
            SetCols(25);
            Display();
            Set();
    }



    Hier fülle ich dann z.B. eine Zeile mit Inhalt:


    Ich halte mich nicht für den großen C++ Programmierer aber es funktionierte bisher gut


    gruß
    msv

    Das hat nichts geändert.


    Ich mache das so:


    Code
    myFilmeDetailMenu::myFilmeDetailMenu() :
            cOsdMenu(tr("Details")) {
            SetMenuCategory(mcPlugin);
            SetCols(25);
            Display();
            Set();
    }



    Hier fülle ich dann z.B. eine Zeile mit Inhalt:


    Ich halte mich nicht für den großen C++ Programmierer aber es funktionierte bisher gut


    gruß
    msv

    Nach dem Lesen des ganzen threads bin ich der Ansicht, dass der eigentliche Fehler in skindesigner liegt.
    Das Plugin sollte eben nicht mehr Infos verwenden als vdr selbst mit seinen mitgelieferten Skins benutzt und sich 100% kompatibel verhalten.


    Andrerseits ist der patch trivial und tut nicht weh, also warum nicht einfach in wirbelscan ergänzen.
    Das ändert aber nichts daran, dass dieses skindesigner Plugin dann beim nächsten Plugin wieder auf die Nase fällt.



    Hallo Louis,


    mich hats auch getroffen.
    Ich habe für eine kleine Datenbankapplikation ein Plugin zur Anzeige über Infos zu meinen Aufnahmen geschrieben. Dabei habe ich noch das klassische (Basis) Erzeugen von Menus und Menuitems nach den Methoden abgeleitet

    Code
    class myFilmeDetailListMenu: public cOsdMenu {
    ...


    Code
    class myFilmeDetailListItem: public cOsdItem {
    ...


    Menuitems werden dabei mit Text gefüllt und orientieren sich an den gesetzten Tabs und sind entweder "selectable" oder "nonSelectable".
    Das funktioniert auch hevorragend unter den klassischen Skins des VDR (Klassik, LCARS) und gib ein gut lesbares formatiertes Bild wieder.


    Wenn ich jetzt allerdings deine Skins "metrixhd" (M) oder "estuary4vdr" (E) nehme, passieren hier Dinge, die zu dem "VDR-Standard" nicht kompatibel sind und mir das Menu total "verhauen".


    1. NonSelectable Zeilen:
    (M) linksbündig, aber nur der Inhalt bis "\t"
    (E) mittiger Text des Inhaltes bis "\t"
    erwartetes Verhalten: Darstellung Spaltenweise (evtl anderer Background oder Schriftfarbe).


    2. Selectable Zeilen:
    Darstellung ist Spaltenweise aber immer nur bis zum nächsten TAB
    erwartetes Verhalten: Wenn Text z.B. nur im ersten TAB ausgegeben wird sollte dieser, wenn kein weiterer Text in anderen Spalten steht, weitergeschrieben werden bis Zeilenende. D.h. Die TABs geben nur den Textbegin an aber nicht das Textende der vorhergehenden Spalte wieder.


    Denk doch mal darüber nach ob du nicht für die Menucategorien "mcUnkown" und "mcUndefined" versuchen kannst, hier wieder das "VDR-Standard"-Verhalten herzustellen. Andere Pluginentwickler werden's dir eventuell danken.


    Gruß
    msv

    Hallo Louis,


    hab immer noch Probleme im Zusammenhang mit dem xinelibout Plugin:


    1. wenn man ein paarmal irgendwelche Menu Aktionen durchgeführ hat bleibt irgendwann der Hintergrund als Standbild des zuletzt laufenden Bildes stehen und die verkleinerte Ausgabe des laufenden Bildes läuft weiter. Dabei sind dann die Menuitems meist, je nach diesem Hintergrund schlecht zu sehen.Vollbild läuft dann wieder aber der Effekt wird dann stabil wiederholt, d.h. bei verkleinerter Ansicht des Bildes bleibt das gerade ausgegebene Livebild als Hintergrund stehen.


    2. wenn ich das Fenster auf meinem Desktop von der Größe her verändere (zB Umschalten vom ursprünglichen Vollbild auf Fenster) scheint der Skin nicht neu zu skalieren und wird dann nicht mehr angezeigt. Evtl fehlt hier ein erkennen der neuen Bildschirmgröße.


    Wenn du noch mehr Infos braucht, don't hestitate to....


    Gruß
    msv

    Hallo Louis,


    Hey, der Tip mit der Einfahrzeit=0 hats gebracht. Es geht damit tadellos.


    Danke!
    msv


    (Als Entwicklerteam hatte ich Dich inkl aller Patchlieferanten und Ideengeber gemeint. Die Diskussion ist hier ja recht lebhaft)

    Ich kann problemlos, wenn ich den VDR mit OSD Skin LCARS starte, auf den "estuary" umschalten und auch alle Menupunkte anfahren.


    Hab noch mal ein bischen probiert. Es passiert auch direkt nach dem umschalten auf "estuary" wenn man den Kanalwechsel anzeigt, bzw auf OK drückt im leeren screen. Muß wohl an diesem Kanalwechsel screen liegen. Der erscheint ja auch immer am Anfang beim Starten des VDR. Und dabei stürtzt das Dingens dann immer gleich ab.


    Gruß
    msv

    Hallo liebes Entwickleram,


    ich bin gerade dabei mal das Skindesignerplugin auf meinem Desktop-VDR (Streamdevclient, wird nur zum Schneiden und verwalten der Aufnahmen benutzt) auszuprobieren. Sehen ja schon beeindruckend aus, diese neuen Skins. Respekt!!!


    Leider habe ich aber ein Problem mit dem Zusammenspiel des Skindesigner- und dem xineliboutput-Plugin. Ich kann problemlos, wenn ich den VDR mit OSD Skin LCARS starte, auf den "estuary" umschalten und auch alle Menupunkte anfahren. Das Bild sieht dann auch gut aus. Wenn ich den VDR dann beende und dann wieder neu starte gibts allerdings dann einen Segfault. Ich muß dann jedesmal in der setup.conf wieder den OSD Skin auf LCARS zurückstellen, damit der VDR wieder startet. Ich bin bei den Plugins immer auf den letzten GIT Versionen:


    Code
    ./vdr -V
    vdr (2.2.0/2.2.0) - The Video Disk Recorder
    tvguideng (0.3.0) - TV Guide for Skindesigner Skins
    streamdev-client (0.6.1) - VTP Streaming Client
    skindesigner (1.1.2) - Skin Designer
    xineliboutput (2.0.0-cvs) - X11/xine-lib output plugin


    ich hab hier noch den backtrace vom Absturz und die Logs vom ersten und dem zweiten Lauf angehängt


    Vielleicht fällt ja jemandem von Euch etwas dazu ein.
    Danke
    msv

    Hallo Leute,


    hat jemand von Euch schon mal diese USB-Kamera unter Linux (Debian) ans Laufen gebracht? Hintergrund ist, daß ab 2.Juni ja die Skype Applikation auf den Samsungs dieser Welt "stirbt". Nun suche ich Verwendung für diese (schweineteure) Kamera. Am liebsten dann Skype auf dem VDR-System mit installieren und damit dann weiterhin das Setup am Ferseher benutzen, nur eben dann die Kamera am USB Eingang des PCs. Wenn ich die Kamera jetzt einfach mal anschließe liefert dmesg nur:


    Code
    [ 7189.628281] uvcvideo: Found UVC 1.00 device USB2.0 UVC HQ WebCam (04e8:205c)
    [ 7189.628666] uvcvideo 3-8:1.0: Entity type for entity Extension 2 was not initialized!
    [ 7189.628670] uvcvideo 3-8:1.0: Entity type for entity Extension 6 was not initialized!
    [ 7189.628672] uvcvideo 3-8:1.0: Entity type for entity Extension 5 was not initialized!
    [ 7189.628674] uvcvideo 3-8:1.0: Entity type for entity Processing 3 was not initialized!
    [ 7189.628677] uvcvideo 3-8:1.0: Entity type for entity Camera 1 was not initialized!
    [ 7189.628817] input: USB2.0 UVC HQ WebCam as /devices/pci0000:00/0000:00:14.0/usb3/3-8/3-8:1.0/input/input25


    Ich kenne mich hier nicht mit den Driver-Internas aus, so daß ich nicht weiß, was mir diese Extensions sagen wollen


    Gruß
    msv

    Also ich kann nur die Vivanco UR2 wärmstens empfehlen. Hab davon mehrere im Einsatz. Ist billig und tut genau, was sie soll.


    Hier meine lircd.conf für die Ebene TV (Codenummer 069).



    ... und hier der entsprechende Teil aus der remote.conf




    Gruß
    msv