[ANNOUNCE] VDR developer version 1.7.28

  • Schließe mich der Frage bezüglich der Skin-Plugins an.


    Ich nutze noch die Ausgabe über die "alte" Fullfeatured-Karte. Ich weiß ja nicht, was genau passiert, wenn ich auf dieser Karte den neuen Skin aktiviere, aber ich tippe mal drauf, dass dann eine kurze SSH-Sitzung fällig wird, um das wieder zu berichtigen. Wäre es ein eigenes Plugin, dann könnte man das für dieses bestimmte System problematische Skin-Plugin einfach "sicherheitshalber" weglöschen. Ist möglicherweise auch für die Übersichtlichkeit besser. Wenn z.B. jemand auf Basis des neuen Skins einen ähnlichen Skin anbieten will, dann könnte er einfach das Skin-Plugin als Basis nehmen und nach Wunsch ändern.

  • kls


    Warum baust Du die Skins eigentlich nicht als Plugin ein? Hat das einen bestimmten Grund? Ein Default-Skin im Code würde doch reichen, die anderen könnte man als Plugin anbieten?


    Weil dann die älteren Default-Skins "rausfallen" würden, und das würde bestehenden Anwendern sicher nicht gefallen.
    Mit anderen Worten: bisher war ST:TNG die Default-Skin, jetzt ist es LCARS. Wenn nur die Default-Skin fest im Code wäre, müsste jetzt also ST:TNG in ein Plugin wandern. Somit müssten Anwender, die bisher ohne Plugin auskamen, plötzlich ein Plugin für "ihre" Skin laden.


    Klaus


  • Weil dann die älteren Default-Skins "rausfallen" würden, und das würde bestehenden Anwendern sicher nicht gefallen.
    Mit anderen Worten: bisher war ST:TNG die Default-Skin, jetzt ist es LCARS. Wenn nur die Default-Skin fest im Code wäre, müsste jetzt also ST:TNG in ein Plugin wandern. Somit müssten Anwender, die bisher ohne Plugin auskamen, plötzlich ein Plugin für "ihre" Skin laden.


    Klaus


    Verstehe ich, aber dann hätte LCARS auch gleich in ein Plugin wandern können oder ist das Skin nicht neu?


    Mich stört ansich nicht, wollts nur mal wissen. Theoretisch wäre dann aber für jede Skinänderung eine neue VDR Version fällig.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hier mal das Menü mit den aktuellen patches

  • Verstehe ich, aber dann hätte LCARS auch gleich in ein Plugin wandern können oder ist das Skin nicht neu?


    Es ist die neue Default-Skin - und damit fest im VDR-Code.


    Zitat


    Theoretisch wäre dann aber für jede Skinänderung eine neue VDR Version fällig.


    Die Default-Skin ist nunmal integraler Bestandteil von VDR.
    Aber so sehr oft kommen solche Änderungen ja nun auch wieder nicht vor, daß das schlimm wäre ;)
    Klar, jetzt in der Anfangsphase gibt's einige Anpassungen, aber momentan kommen ja auch noch des öfteren neue Developer-Versionen...


    Klaus

  • ... beantwortet meine Frage aber nur am Rande. Klar ist die "alte Fullfeatured" im Zeitalter von HD so langsam etwas außen vor, aber solange der VDR noch das sdffdevice als Plugin mitbringt, gehe ich doch davon aus, dass sie auch noch offiziell unterstützt wird. Mit dem neuen "Default-Skin" gibt es da doch Probleme, oder nicht? Gibt es eine Sicherung, die bei "schwacher Ausgabe" eine Auswahl von "zu heftigen Skins" verhindert? Wenn der neue Default-Skin auch standardmäßig vorausgewählt ist, dann habe ich doch beim ersten Aufstarten vom VDR direkt ein Problem, oder liege ich da falsch?

  • Bei den Empfängern steht im Screenshot von jsffm eine 5, es werden aber nur drei Empfangsgeräte angezeigt - sollte man das nicht noch vereinheitlichen? Immerhin gibt es ja wenig Zusatzinfos durch das mitzählen weiterer nicht-empfangsfähiger Geräte.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ... beantwortet meine Frage aber nur am Rande. Klar ist die "alte Fullfeatured" im Zeitalter von HD so langsam etwas außen vor, aber solange der VDR noch das sdffdevice als Plugin mitbringt, gehe ich doch davon aus, dass sie auch noch offiziell unterstützt wird. Mit dem neuen "Default-Skin" gibt es da doch Probleme, oder nicht? Gibt es eine Sicherung, die bei "schwacher Ausgabe" eine Auswahl von "zu heftigen Skins" verhindert? Wenn der neue Default-Skin auch standardmäßig vorausgewählt ist, dann habe ich doch beim ersten Aufstarten vom VDR direkt ein Problem, oder liege ich da falsch?


    Die LCARS-Skin ist auch mit lediglich 1bpp (2 Farben) noch komplett bedienbar (und das schafft auch die alte FF-Karte).
    Somit kann man mit der Fernbedienung über Setup/OSD/Skin problemlos auf eine andere Skin wechseln.


    Klaus

  • Bei den Empfängern steht im Screenshot von jsffm eine 5, es werden aber nur drei Empfangsgeräte angezeigt - sollte man das nicht noch vereinheitlichen? Immerhin gibt es ja wenig Zusatzinfos durch das mitzählen weiterer nicht-empfangsfähiger Geräte.


    Ja, das hat sich durch den jüngsten Patch zur Nicht-Anzeige von Devices, die nicht empfangen können, so ergeben.
    Wird in der nächsten Version behoben.


    Edit: Patch anbei.


    Klaus

  • Hier mal das Menü mit den aktuellen patches


    find ich echt klasse so mit den geänderten Farben: komm ich wohl eher nicht mehr drum herum um das Skin...


    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



  • moin,


    wenn dann noch das 'Aufnehm' durch rec oder record ersetzt wird ..


    Das kannst du in der Datei po/de_DE.po entsprechend ändern (allerdings ist es dann halt nicht mehr "deutsch"), oder du kannst im Setup/OSD den "Small font" etwas kleiner machen (bis es halt reinpasst). MIt den Default-Einstellungen auf einem 1920x1080-OSD passte es rein (zumindest ohne die "Gap" in den Buttons).


    Klaus

  • Nochmal mit dem letzten Patch und kleinerer Schrift

  • Wird immer hübscher :)
    Warum wird da bei einigen Timern kein Titel angezeigt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wird immer hübscher :)
    Warum wird da bei einigen Timern kein Titel angezeigt?


    Ich vermute, das hängt mit aktiven bzw. inaktiven Timern zusammen.
    Mir wäre es lieber, wenn die inaktiven ausgeblendet würden.


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

  • 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 jedenfalls mein spontaner Eindruck.


    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.


    cu


  • Da die Timer wie die Empfänger im Hauptmenü nur informativ dargestellt werden, wäre es sicher sinnvoll, das Darstellungsverhalten beider zu vereinheitlichen.


    z.B.:
    unbenutzte Empfänger werden ausgeblendet -> inaktive Timer werden ausgeblendet
    oder
    unbenutzte Empfänger werden farblich markiert, z.B ausgegraut -> inaktive Timer werden farblich markiert
    (das hätte auch was, denn dann wüsste man z.B. welche Empfangsmöglichkeiten der VDR noch hat)


    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.


    Karl

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

Jetzt mitmachen!

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