[ANNOUNCE] VDR developer version 1.7.28

  • Das was IMHO extrem aus dem Rahmen fällt sind die Farbbuttons, die wirken dort wie nen Fremdkörper. Vom Konzept her müssten das eigentlich (passend eingefärbte) Abschnitte des darunter liegenden Balkens (oder Rechts gibts die selbe hochgzogene Seite wie links und die Buttons sind dort drin) sein und keine in der Luft hängenden Flächen.


    Das ist aber bei LCARS genau so.
    Siehe z.B. http://en.wikipedia.org/wiki/File:Lcars_wallpaper.gif.
    Und mit den neuen Farben sieht das, finde ich, recht gut aus.


    Quote


    Ansonsten, das hat was wenn man sich erst mal dran gewöhnt hat. Irgendwie doch schick und elegant. Bleibt nur das alte Problem das es extrem bastelig wirkt wenn dann femon/weatherng/radio (die habe ich bei mir extra auf skinenigma DarkBlue umgepatcht damits einheitlich wird) wieder mit nem anderen Layout kommen.


    Da bin ich auch noch am überlegen.
    Ich hatte ja schon länger mal vor, eine Möglichkeit zu schaffen, daß ein Plugin ein Menü öffnen kann, bei dem nur der äußere Rahmen von der Skin stammt, und der innere Bereich vom Plugin vollkommen selber gestaltet werden kann. Etwa indem die Skin noch eine Funktion SetBitmap() bekommt, über die ein Teil der inneren Fläche (oder auch die gesamte) mit einer vom Plugin erzeugten cBitmap "bemalt" werden kann (für cPixmap natürlich entsprechend).
    Einziges Problem dabei wäre, daß das Plugin nicht "weiß", welche Farben es verwenden soll, um sich "einzufügen". Aber da könnte eine Skin ja auch eine Funktion haben, über die man sich einen Satz von Farben holen kann, mit zugehörigen Bedeutungen. Also z.B. sowas in der Art, wie ich es in skinlcars.c jetzt gemacht habe:



    Wäre das was? Oder wollen die Plugins gar keine OSDs mit von der aktuellen Skin vorgegebenem Rahmen?


    Klaus

  • Ich setze gerade einen neuen headless VDR Server auf und hätte gerne ein per ssh/telnet/VNC/VLC nutzbares Remote OSD. Bisher nutze ich skincurses, aber das bekomme ich nicht per ssh zu sehen. Das alte control Plugin (für OSD via telnet) zickte bei mir auch öfter mal daher suche ich eine Alternative. Also wollte ich ffnetdev + VNC Viewer als Remote OSD nutzen. Aber ich sehe nur einen schwarzen Bildschirm nach dem Start des VNC Viewers. Da ich vorher ffnetdev nicht benutzt habe stellt sich natürlich die Frage: "Liegt es an einer Konfiguration oder ist ffnetdev nicht kompatibel mit 1.7.28?". Im Log ist leider nichts zu sehen. Es würde schon helfen wenn jemand bestätigen könnte das ffnetdev noch kompatibel mit 1.7.28 ist. Oder falls es noch eine Remote OSD (möglichst VNC/VLC) Möglichkeit (ohne VDR Client) wäre ich für Tipps dankbar.


  • Wenn ein Timer gerade aufzeichnet, dann wird das durch ein kleines Rechteck rechts neben dem Timer-Rechteck angezeigt.
    Das Device, welches diesen Timer versorgt, hat dann links neben seinem Rechteck ebenfalls einen kleinen Indikator.
    Wenn ein Device mehrere Timer versorgt, dann stehen diese untereinander und ihre Indikatoren sind verbunden.
    Damit kann man sehr schön sehen, welche Timer aktiv, welche Devices belegt und welche noch frei sind.


    Quote


    Eine unvollständige Anzeige inaktiver Timer halte ich für unglücklich dargestellt.
    Unstimmige Timer zu markieren ist durchaus hilfreich, hier wäre aber auch eine farbliche Markierung denkbar, ein Weglassen von Informationen erschwert dagegen eher das Analysieren.


    Völlig inaktive Timer (bei denen also "active: no" gesetzt ist) hier wegzulassen wäre für mich OK (werde ich wohl auch so machen).
    Es kann aber auch vorkommen, daß es für einen Timer momentan (noch) keinen EPG-Event gibt und deshalb diese Zeile leer ist. In dem Fall halte ich nichts davon, ihn wegzulassen.


    Klaus

  • Quote

    hätte gerne ein per ssh/telnet/VNC/VLC nutzbares Remote OSD


    Ich verwende zwar noch den vdr1.7.27, nutze dort aber das Remote-Plugin und steuere den VDR damit über ssh via tcp.


    //edit:
    Übrigens wenn ich schon in diesem Thread schreibe möchte erwähnen, dass mir LCARS sehr gut gefält. Ist mal was ganz anderes - danke Klaus für deine unermüdliche Arbeit.


    Viele Grüße skippy

  • Wenn ein Timer gerade aufzeichnet, dann wird das durch ein kleines Rechteck rechts neben dem Timer-Rechteck angezeigt.
    Das Device, welches diesen Timer versorgt, hat dann links neben seinem Rechteck ebenfalls einen kleinen Indikator.
    Wenn ein Device mehrere Timer versorgt, dann stehen diese untereinander und ihre Indikatoren sind verbunden.
    Damit kann man sehr schön sehen, welche Timer aktiv, welche Devices belegt und welche noch frei sind.

    Diese logische Verknüpfung finde ich gut. Das erklärt aber auch, ich hatte mich darüber schon gewundert, warum bei einer laufenden Aufnahme das letzte Device, bei mir Device 3, dann oben steht.


    Völlig inaktive Timer (bei denen also "active: no" gesetzt ist) hier wegzulassen wäre für mich OK (werde ich wohl auch so machen).

    Hier meinte ich genau die mit "active: no" gekennzeichneten Timer, ein weglassen ist vernünftig


    Es kann aber auch vorkommen, daß es für einen Timer momentan (noch) keinen EPG-Event gibt und deshalb diese Zeile leer ist. In dem Fall halte ich nichts davon, ihn wegzulassen.

    Diese Timer darf man natürlich nicht weglassen.


    Wie kann es eigentlich zu solchen Timern kommen? Sind das händisch angelegte, die noch nicht als event vorliegen?
    Wenn ja, heißt das, ich kann eine Sendung die irgendwann später liegt, aber noch kein EPG hat, händisch anlegen und der VDR verknüpft dann automatisch ein dazu passendes später auftretendes event (alles jetzt mal ohne plugins). Wonach schaut er dann, nur nach der Startzeit und welche Toleranzen werden hier ggfs. berücksichtigt?


    Karl

    VDR 2.6.1: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 36 Kernel 6.0 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • cjhbabel


    Ich habe eben ffnetdev getestet, es funktioniert. Ich pers. ziehe aber telnet mit remote-plugin vor.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • kls


    In dvbdevice.c fehlt in DeliverySystemNames ein Eintrag:

    Code
    1. Jun 7 19:38:05 vdr vdr: [2664] (dvbdevice.c:1209) frontend 0/0 provides DVB-C,(null),DVB-T with QAM16,QAM32,QAM64,QAM128,QAM256 ("DRXK DVB-C DVB-T")


    Bei DVB-C gibts drei Varianten:


    Gruß
    e9hack

  • Wäre das was? Oder wollen die Plugins gar keine OSDs mit von der aktuellen Skin vorgegebenem Rahmen?


    Da wäre ich sehr für. Man könnte dann z.B. das extrecmenu, das die normalen Skin-Funktionen benutzt, um eine Anzeige für EPG-Bilder erweitern. Dann sollten die normalen Skin-Funktionen aber trotzdem noch auf derselben Fläche funktionieren.


    LG
    Joachim

    Mein VDR: Digitainer II Gehäuse, Asus M85M-US2H, AMD Sempron 140, 2 GB RAM, 1 TB WD Festplatte, Satelco Easywatch / Terratec Cinergy DVB-C, IR- Fernbedienung mit Atric-Einschalter, yavdr-0.5.0a


  • Da wäre ich sehr für. Man könnte dann z.B. das extrecmenu, das die normalen Skin-Funktionen benutzt, um eine Anzeige für EPG-Bilder erweitern. Dann sollten die normalen Skin-Funktionen aber trotzdem noch auf derselben Fläche funktionieren.


    LG
    Joachim


    Hier OT aber in der Eventbeschreibung meines extrecmenu werden sehr wohl epgbildchen mit t2s anthra angezeigt.


    Christian

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    CKthree: yavdr-ansible/22.04 LTS/2.6.1/kodi19.3 auf Intel NUC, Celeron J4005, UHD Graphics 600, 4GB Crucial DDR4, Ocz Vertex2 50 GB, Harmony 350

    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5



  • Hier mal ein Beispiel im laufenden Betrieb mit mehreren Recordings.

  • Wir können da jetzt entweder noch weiter runtergehen (und landen evtl. irgendwann wieder bei den ursprünglichen 7), oder wir lassen es so wie es jetzt ist. Oder vielleicht hast du ja noch eine ganz andere Idee?


    Klaus

    Beim Ausprobieren, wie die Anzeige reagiert, hatte ich die längeren Sendernamen editiert und verkürzt. Mein Vorschlag: Breite auf Basis des längsten Sendernamens setzen. EPG ist evt auch wichtig genug für nen Parameter.
    seiniplatte

    HW1: Asus M3N78-EM|AMD 235e 1xDVB-S2 HD-Nova, 1xDVB-S1 TT-Budget, OpenSuse 11.2 64bit vdpau
    per xinelib1.2
    HW2: Asus Pundit-P1-AH1 AMD3600X1 TT Rev1.3FF, DVB-S1TT Budget, OpenSuse11.1 64bit


    Weitere HW: SMT7020s zen2mms1.3, MacMini VirtualBox mit Ubuntu 9.10 und TT-s3200 USB

  • Hi,


    Quote

    Breite auf Basis des längsten Sendernamens setzen. EPG ist evt auch wichtig genug für nen Parameter


    Hach, wenn man das konfigurieren könnte?! ;) *zaunpfahl*


    mfg
    kris

  • Moin!


    Das ist aber bei LCARS genau so.
    Siehe z.B. http://en.wikipedia.org/wiki/File:Lcars_wallpaper.gif.
    Und mit den neuen Farben sieht das, finde ich, recht gut aus.


    Es würde wahrscheinlich noch schicker aussehen, wenn die Buttons etwas weniger Höhe und drum rum etwas mehr Platz hätten, wie in dem von dir geposteten Bild.
    Und was vermutlich auch noch "fremd" wirkt, ist, dass sie über den Trenner zwischen Timer und Geräte hinausragen. Das durchbricht das Gesamtbild etwas.


    Und insgesamt eventuell eine schmalere Schrift. Gibt's keinen LCARS-Font? :)


    Geiles Teil!


    Lars.

  • Hier OT aber in der Eventbeschreibung meines extrecmenu werden sehr wohl epgbildchen mit t2s anthra angezeigt.


    Christian


    Aber wäre es nicht viel besser, wenn die Anzeige nicht von einem bestimmten skin abhängt? Es war ja eh nur als Beispiel gedacht. Ich halte es generel für sinnvoll, wenn Plugins die Möglichkeit haben das osd frei zu gestalten ohne das gleich das ganze skin umgangen wird.


    Lg


    Joachim

    Mein VDR: Digitainer II Gehäuse, Asus M85M-US2H, AMD Sempron 140, 2 GB RAM, 1 TB WD Festplatte, Satelco Easywatch / Terratec Cinergy DVB-C, IR- Fernbedienung mit Atric-Einschalter, yavdr-0.5.0a

  • Beim Ausprobieren, wie die Anzeige reagiert, hatte ich die längeren Sendernamen editiert und verkürzt. Mein Vorschlag: Breite auf Basis des längsten Sendernamens setzen.


    Das ist bereits der Fall:



    Dumm ist halt nur, wenn ein Kanal, der keinen kurzen Namen anbietet, einen recht langen Namen hat.


    Klaus

  • @ Kls
    Wie wehre es ab VDR ver. 2 keine Rücksicht mehr auf alte FF. Die meisten Haushalte haben schon Flachbildfernseher und somit HDTV, und die VDR user sowieso. :versteck

  • Moin!



    Es würde wahrscheinlich noch schicker aussehen, wenn die Buttons etwas weniger Höhe und drum rum etwas mehr Platz hätten, wie in dem von dir geposteten Bild.


    Bei den Proportionen habe ich mich hauptsächlich hieran orientiert: http://www.bracercom.com/tutor…ical_relational_large.jpg
    Die abgerundeten Buttons im Hauptmenü haben demnach die gleiche Höhe wie die rechteckigen Flächen links.
    Sicher, das muß man nicht alles "sklavisch" einhalten, aber die Zeichnug im o.g. URL erschien mir doch relativ schlüssig, so daß ich mich im Wesentlichen danach gerichtet habe.


    Quote


    Und was vermutlich auch noch "fremd" wirkt, ist, dass sie über den Trenner zwischen Timer und Geräte hinausragen. Das durchbricht das Gesamtbild etwas.


    Die Breite der Buttons hängt von der gewählten Fontgröße ab und ist somit nicht korreliert mit der Position dieses Trenners.
    Daß es hier einen kleinen "Bruch" gibt ist mir auch schon aufgefallen, nur sehe ich nicht, wie man das am besten ändern soll.


    Quote


    Und insgesamt eventuell eine schmalere Schrift. Gibt's keinen LCARS-Font? :)


    Ich habe diverse "sogenannte" LCARS-Fonts ausprobiert, aber die waren durch die Bank extrem schlecht lesbar.
    Falls du einen brauchbaren findest, laß es mich wissen und benutze ihn einfach. Das hat mit der Skin selber ja nicht unmittelbar was zu tun.


    Klaus

  • @ Kls
    Wie wehre es ab VDR ver. 2 keine Rücksicht mehr auf alte FF.


    Wie bereits weiter vorne geschrieben: die LCARS-Skin ist vollständig bedienbar selbst mit nur einem Bit Farbtiefe. Lediglich die Fortschritts- und Signalanzeige ist nicht erkennbar, aber das tut der Bedienbarkeit ja keinen Abbruch. Es kann also jemand, dessen OSD extrem limitiert ist, problemlos mittels der Fernbedienung auf eine andere Skin umschalten.


    Klaus


  • Aber wäre es nicht viel besser, wenn die Anzeige nicht von einem bestimmten skin abhängt? Es war ja eh nur als Beispiel gedacht. Ich halte es generel für sinnvoll, wenn Plugins die Möglichkeit haben das osd frei zu gestalten ohne das gleich das ganze skin umgangen wird.


    Ich werde auf jeden Fall diese Bitmap-Setz-Schnittstelle noch einbauen (wollte ich eh schon lange).


    Klaus

  • Okay - nachdem aktive Timer mit dem device verknüpft werden, macht ein Abrunden keinen Sinn.


    Mir fällt nur noch das grelle rot der Platte auf - das stört noch etwas. Da würde ich auch ein Pastell nehmen.


    Andy