[ANNOUNCE] yaepghd 0.0.4

    Hallo,


    manche wissen's ja, der Thread yaepghd - bild skaliert nicht hat dazu geführt, hier ist sie, die Version 0.0.4, der Code auf Github und das Release-Archiv auf SF. Das sind die Änderungen die ich auch in der HISTORY-Datei zusammengefasst habe:



    Grobe Fehler und sinnvolle Patches werden sehr wahrscheinlich zu Folgeversionen führen...


    Viel Spaß damit!


    Lucian

    Zitat

    @ zoolook


    muss dafuer der vdr noch gepatcht werden?


    Nein, diese Version kann nur skalieren, wenn der VDR neuer oder zumindest 1.7.33 ist, und mit dem alten Patch kann sie sogar absichtlich nichts mehr anfangen, dafür kann man ältere Versionen nehmen wenn man das unbedingt will.
    EDIT: Natürlich gilt noch als Voraussetzung (bloß fürs Skalieren) ein Ausgabe-Device welches diese ScaleVideo-API unterstützt (aktuelles Softhddevice, gepatchtes vdr-xine oder die TT6400).
    Sent from my Nexus 4 using Tapatalk 2

    Hallo Lucian,


    Zitat von Zoolook

    Grobe Fehler und sinnvolle Patches werden sehr wahrscheinlich zu Folgeversionen führen...



    Danke für deinen Einsatz


    Gruß S.

    Dateien

    yaepghd-0.4_margin-stop.diff 527 Byte – 136 Downloads

    Habe aktuell bei Aufruf ein abschmieren des VDR

    Code
    kernel: [16740.292026] vdr[6657]: segfault at c0 ip 00007f91a1f38f0f sp 00007fff752edc00 error 6 in libvdr-yaepghd.so.2.0.0[7f91a1f22000+22000]


    konnte aber bisher nicht mehr dazu rausfinden (es fehlt die Zeit).

    Gruß utiltiy



    VDR Projekte VDR Projects

    Den von utiltiy berichteten segfault kann ich bestätigen, finde den Grund dafür aber auch nicht, hatte den Post zu spät gesehen ...


    Wir hatten bisher einen github checkout vom 06.04.2013 verwendet, der History nach hatte sich zw. 01.04. (letzter commit) und 06.04. nix geändert. Danach kamen noch zwei commits, der vom 13.04. "version 0.0.4" und der vom 14.04 "bugfix event input end time margin (thanks to Saman)" (inkl. 0.0.5_pre1). Der github checkout von heute verursacht beim Aufruf den Segfault, auch wenn ich testweise die Änderungen der letzten commits rausnehme. Kann es Änderungen geben, die nicht in der github History auftauchen?


    Kleine Warnung an die yaVDR Nutzer (testing), das Paket funktioniert grad nicht, sorry, die paar wenigen Änderungen, primäre Version-Strings, schienen mir nicht sonderlich gefährlich ...


    Regards
    fnu

    HowTo: APT pinning

    Könnte es das sein:


    Zitat

    Leider hat yaEpgHD wohl Probleme mit langen Theme-Namen.
    Wenn der VDR neugestartet wird und dann direkt das yaEPG aufgerufen wird, stürtzt der VDR ab.
    Das Betrifft auch PearlHD_1920_xxx Themes!


    Darum habe ich das Paket nochmal hochgeladen und den Theme in 'nOpacity_1920.theme' umbenannt.

    Saman


    Hmm, ja das habe ich allerdings nicht geprüft, nur heute irgendwann mal einen "git clone ..." gemacht und die commits in github untersucht, da waren keine Themes dabei ... ;)


    Ich schau mir das eh grad an, danke für den Hinweis ...


    Regards
    fnu

    HowTo: APT pinning

    Also ich habe auch die Git-Version im Einsatz, nutze sie zwar selten, aber definitiv kracht's nicht beim Laden, Saman's letzter Patch hat damit nichts zu tun. Auch kam in der Vergangenheit die Thematik mit zu langen Dateinamen beim Theme, daraufhin habe ich die von 16, wie Klaus sie definiert hat, auf 64 angehoben (zugegeben, leider nicht in einem gesondertem commit und nicht in der HISTORY dokumentiert, ich war wohl wegen der Argumentation und dem Thread-Hijacking auf der ML-Liste wo ich einen Patch vorgeschlagen hatte, abgelenkt.


    Hat da jemand noch andere Themes als die aus den Sourcen, haben die noch laengere Namen? Wenn ja, kann derjenige testen, ob es tatsaechlich daran liegt, durch Kuerzen des Namens?


    Ciao, Lucian

    Zoolook


    Ja, mir war eigentlich auch klar das die letzten sichtbaren Änderungen nicht das Problem sein konnten, hatte ich ja eigentlich auch geschrieben und aussortiert. Dennoch produzierte yaepghd hier einen segfault ...8)


    Die Namen der Themes sind es nicht, habe eben das vergangene Source Paket und das neu ausgecheckte verglichen. Daher verfolge ich mal den anderen Hinweis mit dem Resource-Pfad.


    Wie immer spannend warum der vorhergehende Checkout (0.0.4 ...) gegen die gleiche VDR Version problemlos mit der alten Definition lief ... 8o


    [EDIT] Es scheint als ob das der Ursache Übel war, das die Themes im falschen Resource-Pfad landeten, der mit 0.0.4 von vor ein paar Tagen noch funktionierte, mal weiter beobachten ... [/EDIT]


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Hallo,


    schön das sich jemand dieses Plugins annimmt. Mein yaepghd von heute Morgen aus yaVDR/testing funktioniert soweit.


    Den Ordner /var/lib/vdr/plugins/yaepghd habe ich gelöscht und ein Link nach /usr/share/vdr-plugin-yaepghd angelegt. Sonst waren da noch Links auf das alte /usr/share/vdr-plugin-yaepghd-themes drin.


    Das sollte vielleicht mit in das Paket rein.


    EPG-Images funktionieren wie folgt:
    In /etc/vdr/plugins habe ich noch eine Datei plugin.yaepghd.conf mit folgendem dem Inhalt erstellt:

    Code
    --epgimages=/var/cache/vdr/epgimages


    und in /usr/share/vdr-plugin-yaepghd/nOpacity_1920.theme folgende Zeile eingefügt:

    Code
    eventEpgImageGeom=1080,40,790,444


    Leider werden die EPG-Images auf 255 Farben runtergerechnet.
    Ich denke ab Zeile 1885 könnte man bei True Color Displays auf folgendes verzichten:

    Code
    image.quantizeColorSpace(RGBColorspace);
      image.quantizeColors(255);
      image.quantize();


    [Blockierte Grafik: http://www.jepsennet.de/foren/yaepghd.png]


    Kann es sein, das unten ein bisschen Platz verschenkt wird?


    Als letztes noch der Wunsch das komplette EPG eines Eintrags anzeigen zu können. Da Aufnehmen und Umschalten eh durch Farbtasten abgedeckt sind wäre Ok am logischsten.


    Tschüß Frank

    FrankJepsen


    Bzgl. Paket in yaVDR testing-vdr: yavdr 0.5 testing yaepgHD funktioniert nicht mehr nach update

    HowTo: APT pinning

    Zitat von FrankJepsen

    Kann es sein, das unten ein bisschen Platz verschenkt wird?


    Eigentlich nicht. Das Hintergrundbild hat 1920x1080 und wird normalerweise auch im Vollbild angezeigt.

    Zitat von Saman

    Eigentlich nicht. Das Hintergrundbild hat 1920x1080 und wird normalerweise auch im Vollbild angezeigt.


    Gut, dass wir mal drüber gesprochen haben. Der Grund lag hier:

    Code
    Apr 15 14:41:09 yavdr kernel: [    5.554648] HDMI: detected monitor W240D DVI
Apr 15 14:41:09 yavdr kernel: [    5.554649]     at connection type HDMI
Apr 15 14:41:09 yavdr kernel: [    5.554651] HDMI: available speakers: FL/FR
Apr 15 14:41:09 yavdr kernel: [    5.554654] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24


Apr 15 14:41:11 yavdr vdr: [1106] OSD size changed to 1920x1200 @ 1,11111

    Den Monitor hatte ich anfangs zum Testen dran. Im Fernsehbild und in den Menüs hatte ich auch schmale schwarze Streifen oben und unten. Da war es mir nie so aufgefallen. :dösen


    Ich musste nur in den yaVDR Einstellungen erneut nach vorhandenen Bildschirmen suchen. Jetzt sieht es so aus:

    Code
    Apr 16 09:39:17 yavdr kernel: [ 2314.691039] HDMI: detected monitor LG TV
Apr 16 09:39:17 yavdr kernel: [ 2314.691041]         at connection type HDMI
Apr 16 09:39:17 yavdr kernel: [ 2314.691043] HDMI: available speakers: FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
Apr 16 09:39:17 yavdr kernel: [ 2314.691046] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000
Apr 16 09:39:17 yavdr kernel: [ 2314.691049] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 192000, bits = 16 20 24


Apr 16 09:39:16 yavdr vdr: [1222] OSD size changed to 1920x1080 @ 1


    Die Packaging Probleme sind wohl im anderen Thread gelöst worden.


    Aber könntest du dir die Farbquantisierung nochmal anschauen. yaEPGHD ohne True Color Ausgabe macht eh kaum Sinn.


    Tschüß Frank

    Zitat von utiltiy

    Habe aktuell bei Aufruf ein abschmieren des VDR

    Code
    kernel: [16740.292026] vdr[6657]: segfault at c0 ip 00007f91a1f38f0f sp 00007fff752edc00 error 6 in libvdr-yaepghd.so.2.0.0[7f91a1f22000+22000]


    konnte aber bisher nicht mehr dazu rausfinden (es fehlt die Zeit).


    Problem:
    Ich hatte für yaepghd ein eigenes Theme benutzt welches durch Update / Änderungen und Wegfall des Theme Paket noch in der setup.conf stand aber nicht mehr vorhanden war. Nachdem ich dies durch speichern eines "vorhanden" Theme-Files in den Einstellungen korrigiert habe startet das Plugin wieder.


    Eventueller Lösungsansatz:
    Wäre es möglich dass das Plugin bei sowas, auf das Default Theme zurückgreift und keine Segfaults produziert (wo man sich durchaus einen absuchen kann....)

    Gruß utiltiy



    VDR Projekte VDR Projects

    Ja, sollte eigentlich gehen. Ich möchte eh die Ressourcenverwaltung etwas aufbohren.


    Sent from my Nexus 4 using Tapatalk 2

    Das wäre Klasse +1 :tup


    Das ist nämlich schon eine Waffe was dieser "Eintrag" dadurch für Möglichkeiten bekommt.

    Gruß utiltiy



    VDR Projekte VDR Projects

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden