Beiträge von dad401

    Hallo,


    das mit der Abstufung der Helligkeit muss ich mal im VDR (graphlcd Plugin) testen. Mal sehen ob die dort genauso ist. Dort wird ja dann auch auf diesselbe Funktion zugegriffen, wie es das Kodi-Plugin tut. Display ist ein Megtron SDC (siehe Sig).


    Für die Abdunklung müsste man nur die entsprechenden Status ergänzen:

    Derzeit:

    Code
    1. if xbmc.getCondVisibility('System.ScreenSaverActive'):

    Gemäß Kodi-Wiki müsste es "Player.Playing" sein. Im alten XBMC-GraphLCD Plugin gab es sowas aber mal...könnte man dort abgucken.

    Ich bin seit längerem mal wieder zum Kodi anschauen gekommen. Auch nach einem Update auf Kodi 17.6 läuft das Plugin gut.


    Allerdings wird das Display bei der Filmwiedergabe nicht gedimmt. Ist das so normal, oder müsste es gedimmt werden? Das Dimmen beim Bildschirmschoner funktioniert. Wobei hier die Einstellung der Helligkeit des Displays nicht sehr linear ist. 50% ist von 100% kaum zu unterscheiden. Für eine Abdunklung, die z.B. bei Filmwiedergabe sinnvoll ist, habe ich 2% eingestellt. Bei 1% ist das Display schon aus.

    Super - funktioniert perfekt und reicht mir! :]:thumbup::thumbup:


    EasyVDR 3.5 hatte die V1.7.4pre1, mein Ubuntu ist bei 1.7.0 (habe das Intel Graphics Update Tool wieder deinstalliert, dort war die V1.7.1).

    Ich habe zwar mal versucht, dass Ganze hochzuziehen (war bei V1.8.x, aber dann hatte ich nur noch ein schwarzes Bild mit SHDD).


    Für mein Zwecke passt es nun. SHDD sowie Xineliboutput funktionieren. DVB-T2 mit HEVC kann ich nun problemlos mit dem Celeron schauen.

    Das bringt wieder einige Erfahrungen, falls ich mal meine "alten" VDRs upgraden muss - noch reicht es bei SAT mit H.264 und den alten Nvidias.

    Neuer Stand mit easyvdr (USB Live-System):


    Nach langer Konfigurationsorgie steht fest, dass softhddevice funktioniert. Die dortigen Defaulteinstellungen sind sehr gut. Wenn ich die OSD Größe ändere, dann bekomme ich Pixelgrafik. Sehr interessant ist aber, dass wenn ich in die Konfiguration des Plugins softhddevice gehe und wieder raus, dann habe ich sofort ein quasi farblich-invertiertes Bild, die Farben sind cyan-gelb/rosa - eher so als ob der Farbraum falsch eingestellt ist?!

    Nur nach einem Neustart des easyvdr (stopvdr/startvdr) sieht wieder alles normal aus. Also setup-Einstellung des Plugins ist verboten.


    Bei meinem Ubuntu-System ist die Pixelgrafik nun weg. Es lag wie oben beschrieben an der OSD-Größeneinstellung.

    Allerdings wird das Fernsehbild sehr frequent von grün/schwarz/roten?! Kammlinien überlagert. Diese überlagern aber nicht das OSD. Wenn ich in die Einstellungen des Plugins gehe, kommt derselbe Effekt wie bei easyVDR.


    Fazit: die Überlagerung des Fernsehbildes bleibt als Restproblem. Dies könnte dann evtl. am Softwarestand/Kernel/Treiber/??? liegen....mhhh


    Hiermal ein paar Logauszüge (irgendwie darf ich nur 10.000 Zeichen schreiben?!) beim Start des VDR, wo er dann mit dem Kammeffekt läuft:


    Aus Neugier, welches softhddevice Paket hast Du genutzt?

    Ähmm, dass aus Deinen Paketen ;-)

    ii vdr-plugin-softhddevice-vpp-hevc 0.6.1rc1+git20171210-rofa-0fnu0~xenial


    wichtig war damals in softhddevice das OSD fest auf 1920x1080 einzustellen und 60 HZ mode, sonst sah es so aus wie in deinen Bildern,

    Na das klingt doch schonmal vielversprechend. Werde ich testen :-) Danke!

    Dein VDR ist HEVC gepatcht bzw. v2.3.8?

    Ja, der VDR ist aus den Paketquellen von fnu (vdr 2.3.8-6fnu0~xenial) und damit mit HEVC Unterstützung.


    Das mit der LiveCD (bzw. Stick) ist eine gute Idee. Das teste ich mal.


    Im übrigen funktioniert VA-API nach weiteres Tests mit xineliboutput. Aufnahmen mit H.264, H.265 und MPEG2 werden abgespielt. Bei HEVC liegt die CPU-Last bei ca. 5%. Ganz perfekt geht es nicht, Deinterlacing nicht das beste, paar kleine Ruckler sind zu sehen, aber zum Gelegenheitsschauen kann ich damit leben. Wenn aber softhddevice ginge, wäre das toll, da ich es auch sonst einsetze.


    Ich nehme an, dass ist die richtige Version (easyvdr-3.5.02-64-stable.iso  NEU !!! ) von EasyVDR 3.5.

    Hallo,


    ich habe hier ein Acer Aspire ES 11 Netbook (es geht diesmal nicht um die VDRs in der Signatur), welches ich bisher immer auf Reisen und einem DVB-T Empfänger (mit-)genutzt habe. Installiert ist Ubuntu 16.04 (Xenial). Nunmehr benötigt man ja DVB-T2 und damit auch HEVC Unterstützung. Soweit ich verstanden habe, sollte die CPU dies können:


    Das Streamen von HEVC-Sendern von einem anderen VDR funktioniert mit KODI, die CPU läuft dabei mit ca. 20%. Ob das Bild flüssig ist, konnte ich noch nicht länger testen. Der erste Eindruck ist ok. In jedem Fall habe ich ein Stocken des Sounds mit 5.1 - ähnlich wie hier beschrieben - die Stereoaudiospur funktioniert.


    Für den VDR auf dem Rechner habe ich zum Testen die Pakete von fnu (testing-vdr) genommen. Ich habe aber auch selbst softhddevice mit HEVC-Unterstützung sowie ffmpeg 3.3.4 und 3.4.x kompiliert. Das Ergebnis ist - egal bei welchem Versuch - dassselbe:


    Verwende ich softhddevice mit VDPAU-APIs (VDPAU-VA-API-Wrapper?) - "softhddevice -v vdpau" funktioniert das OSD einwandfrei, aber das Bild einer Aufnahme wechselt jede Sekunde zu grün und zurück zum Bild:




    Der Test direkt mit VA-API "softhddevice -v va-api" führt zu einem völlig verzerrten OSD - zum Abspielen einer Aufnahme komme ich gar nicht:


    Kennt jemand ggf. das Problem und eine Lösung?


    Soweit ich bisher testen konnte, scheint xineliboutput-sxfe mit VA-API zu funktionieren. Hier muss ich jedoch noch etwas länger testen.


    Einige Versionsstände:


    Gruss

    Marcus

    Ich kann eine Lösung über ESP8266 auch empfehlen - wenn kein Raspi zufällig vorhanden ist, kann man sich diesen sparen und dennoch per WLAN schalten.


    Folgende Schaltlösung fürs Wohnzimmer (Fensterbeleuchtung ;-) ) habe ich über Weihnachten umgesetzt:


    Die ersten beiden Dinge sind über Chinahändler noch günstiger. Die Links sollen nur als Beispiel dienen.

    Die NodeMCU kann man ganz einfach mit der Arduinoentwicklungsumgebung flashen.

    Habe mir dafür ne simple Weboberfläche gebastelt - Programm kann ich auf Anfrage schicken - dazu noch einen Temp/Hygro/Barosensor:




    Zum Auslesen der Fernbedienungscodes ist vorher die NodeMCU mit einer Empfängersoftware zu flashen - die aber auch schon vorhanden ist.

    Im Gegensatz zu Homematic z.B. hat man hier aber keinen Rückkanal. Falls Du also richtig "sicher" schalten willst, wären die Lösungen mit den Baumarktsteckdosen nicht gut.


    Nur so als Ergänzung...

    Ja, das mit dem Treiber wäre noch eine Idee. Werde ich bei Gelegenheit mal ausprobieren.


    Ohne GPU-Beschleunigung ruckelt es dann doch nicht (natürlich nur auf System 2) - hier mal die CPU-Werte beider Cores:
    1080p50 (1920x1080): 70-80%
    1080p25 (1920x1080): 40-50%
    1080p50 (1280x720): ca. 30%
    BigBuckBunny: ca. 10-20%


    Wenn der alte Treiber nichts bringt, belasse ich es mit dem Fazit:
    zu wenig GPU/CPU-Leistung für System 3 und zu wenig GPU-Leistung für System 2 für 1080p50 (1920x1080). Danke für die Tipps.

    CPU Last ist um die 1-5% - das (aus meiner Sicht) Übliche, wenn das Video per HW-Beschleunigung abgespielt wird.
    Also auch wenn die GPU es nicht schafft, wird die CPU anscheinend nicht als Unterstützung genutzt. Ich werde mal die HW-Beschleunigung in Kodi abschalten und die CPU-Auslastung prüfen - der ältere AMD wird es aber sicher nicht schaffen.


    Ich gehe jetzt mal davon aus, dass die HW (GPU) zu sehr am Limit ist. Ich werde die Videos für meine VDRs wohl dann auf 25 fps runterrechnen.

    Noch als Ergänzung:
    - das Ruckeln wird weniger wenn ich die Tonspur entferne
    - das Ruckeln ist weg, wenn ich statt 50fps mit 25fps encode


    Zu vdpauinfo (also die Unterstützung ist nicht das Problem, obwohl ich hier nur die Auflösungen sehen, nicht die Frameraten (25, 50, etc.). Encodiert habe ich mit Profil High 4.1, nachdem ich dies mit vdpauinfo geprüft habe, was die Karten können):


    Die Ausgabe von qvdpautest ist hier zu finden (letzter Eintrag, der mit cpufreq-set --min 2GHz).
    Oder hier reinkopiert:

    Hallo,


    ich teste gerade verschiedene Encoding-Einstellungen für meine Filme. Ich habe hier Material mit 1080p und 50 fps. Die Filme möchte ich natürlich am TV ansehen und habe diese dann auf meinen VDRs getestet. Als ich diese heute mit Kodi abspielen wollte, wird VDPAU genutzt, aber es gibt dennoch dropped und skipped frames. Das Video ruckelt beim Ansehen.
    Dies habe wurde gestestet auf System 2 und 3.


    Hier die Ausgabe von Kodi (System 2):


    Die Infoanzeige gibt z.B. folgendes aus (gekürzt abgetippt):

    Code
    1. D(Video: h264(High) (avc1...), yuv420p(tv, bt709), 1920x1080[..], 4219 kb/s)
    2. P(fr:50.000, vq:99%, dc:ff-h264-vdpau, Mb/s: 2.39, drop: 517, skip 441, pc:none)


    Ein anderes Video 1280x720 hat nur skipped frames, keine dropped frames und ruckelt beim Anschauen nicht:

    Code
    1. D(Video: h264(High), yuv420p(tv, bt709), 1280x720[..])
    2. P(fr:50.000, vq:99%, dc:ff-h264-vdpau, Mb/s: 1.55, drop: 0, skip 384 pc:none)


    Die Höhe drop/skip ist nur so wenig, weil ich nur wenige Sekunden das Video abspiele.


    Und noch BigBuckBunny zum Vergleich:

    Code
    1. D(Video: mpeg4(Simple Profile) (FMP4 / ...), yuv420p(tv, bt709), 1920x1080[..], 12001 kb/s)
    2. P(fr:24.000, vq:99%, dc:ff-mpeg4, Mb/s: 22.64, drop: 0, skip 1 pc:1)


    Sollte die Hardware das nicht eigentlich schaffen?
    Ich habe hier zum Download mal ein Testvideo hochgeladen (ca. 15 MB). Wäre toll wenn es jemand auf einem ähnlichen System testen könnte. Evtl. liegt es ja doch nur an irgendeiner Konfiguarationssache oder an Kodi?!

    So ich bin weiter gekommen - das Plugin funktioniert endlich - evtl. lag es doch am Backlight-Parameter in der graphlcd.conf, denn gestern habe ich Kodi auch als root gestartet und getestet?!
    Ich habe meine graphlcd.conf nun auch angepasst, inkl. der Parameter für die anderen Aufrufe (showpic, vdr-graphlcd):


    Zum Plugin (addon.py) hätte ich folgende Anregungen:
    - Error-Ausgaben strigent an jeder Stelle mit dem Name des Plugins am Anfang versehen, dann weiss man auch im kodi.log woher die Meldung kommt
    - einige Meldungen laufen noch als stderr, obwohl es INFO Meldungen sind - das verwirrt dann beim Debuggen, da es im kodi.log als ERROR ausgegeben wird


    Folgendes Grunsatzproblem habe ich erst einmal:
    Der VDR läuft als root - Kodi starte ich jedoch als User. Somit erhalte ich folgendes im syslog:

    Gibt es eine Möglichkeit dem User die Rechte für den Zugriff auf das LCD einzuräumen/zu setzen?


    Starte ich Kodi als root, klappt alles. Die Ausgabe am LCD gefällt mir :-) - viel besser als das was ich bisher von LCDproc kenne.
    Die Umschaltung zwischen VDR und Kodi klappt auch einwandfrei (wenn beides als root läuft).


    Kodi wird gestartet - 2x SVDRP für Fernbedienung abschalten und VDR graphlcd abschalten:


    Kodi wurde beendet, Umschalten auf VDR (softhddevice wird attached):


    Fazit: Ich hoffe ich bekomme noch den Start als User hin, sonst muss ich Kodi doch als root starten. Das Problem ist wohl lösbar - muss es nur umsetzen.
    Nun funktioniert es auch ohne root. Folgende udev-Regel funktioniert hier bei mir:

    Code
    1. root@vdr:~# cat /etc/udev/rules.d/40-sdcmegtron.rules
    2. SUBSYSTEM=="usb", ATTR{idVendor}=="152a", ATTR{idProduct}=="8380", GROUP="plugdev", MODE="0660"


    Das Plugin funktioniert nun und wartet auf den Alltagstest. Danke!

    Ja, make lief fehlerfrei durch. Muss ich ggf. (außer make install) noch etwas wo hinkopieren?
    Das Plugin mit Fonts etc. liegt unter "/usr/share/kodi/addons/script.service.graphlcd"
    Im HOME Verzeichnis (.kodi/userdata/... [hab es gerade nicht parat]) liegen nur die Einstellungen des Plugins - ich glaube settings.xml war der Name - mehr nicht. Ist das korrekt?


    Ist das Kodi-Log die einzige Stelle wo man Meldungen sieht? Starte ich Kodi im Terminal sehe ich dort keine Ausgaben.
    Evtl. baue ich paar mehr Ausgaben in addon.py ein - solange diese ins kodi.log gehen, kann ich evtl. etwas herausfinden.


    Sollte das LCD direkt etwas anzeigen nach dem Start von Kodi oder muss ich noch etwas einstellen (früher gab es mal bei XBMC eine Einstellung so ähnlich wie "LCD aktivieren").


    Wie gesagt, wenn ich LCDproc vor Kodi starte und das Kodi-LCDProc-Plugin verwende, klappt alles. Auch die Umschaltung mit dem VDR und dem DIS/CONNECT. Somit hoffe ich, wenn ich Dein Plugin zum Laufen bekomme, sollte es eigentlich auch klappen. Den u.g. CONNECT Fehler beim VDR habe ich nicht.
    Verwendet werden Pakete des yavdr-PPA. Einzig lcdproc habe ich wegen der serdisp-Unterstützung selber kompiliert - ist hier aber nicht von Bedeutung, da es nicht eingesetzt wird.

    Ich bin jetzt auch einmal dazu gekommen, das Plugin zu testen.


    1. Der Treiber "sdcmegtron" verwundert mich etwas - gibt es etwa einen glcddriver der dies direkt unterstützt (ich mein nicht über serdisp)?
    => ok verstanden


    2. Nach Umstellen des Treibers von "sdcmegtron" auf "serdisp" ist eine Fehlermeldung schon mal weg, die wegen des unbekannten Treibers ausgeworfen wird, aber trotzdem kann er den Treiber nicht laden:

    Code
    1. 00:11:26 T:140012578404096 ERROR: Loading config
    2. 00:11:26 T:140012578404096 ERROR: Loading driver
    3. 00:11:26 T:140012578404096 ERROR: Loading skin


    (ich nehme an, das kommt vom Plugin?)


    Da ich auch von VDR zu Kodi switche und zurück (mit dem GraphLCD-Plugin), habe ich dieses mal im VDR deaktiviert, um eine Beeinflussung des Kodi-Plugins auszuschalten.
    Mit lcdproc (LCDd und dem Kodi-Plugin für lcdproc) sowie svdrpsend PLUG graphlcd CONN / DISCONN klappt der Wechsel übrigens.


    Aber auch ohne das VDR GraphLCD-Plugin bekomme ich keine Anzeige auf dem LCD und ebenfalls die o.g. ERRORs :-(


    Wie kann ich hier weiter debuggen? Das Kodi-Log ist irgendwie ungenügend. Es muss ja einen Grund für die Fehler geben.


    Hier ist alles was ich zum LCD-Plugin finden konnte mit Loglevel=3 (Kodi):


    Code
    1. <settings>
    2. <setting id="brightness" value="100" />
    3. <setting id="brightness_screensave" value="70" />
    4. <setting id="driver" value="serdisp" />
    5. <setting id="scrollmode" value="2" />
    6. <setting id="scrollspeed" value="2" />
    7. <setting id="scrolltime" value="500" />
    8. <setting id="skin" value="default" />
    9. </settings>


    EDIT:
    graphlcd:

    Code
    1. [serdisp]
    2. Driver=serdisp
    3. Device=USB:152a/8380
    4. Controller=sdcmegtron


    Ideen?

    Hallo,


    ich habe meinen VDR (System 3) mit Atom N330 auf Xubuntu 14.04 geupdatet und mit den yavdr-PPA neu eingerichtet (VDR 2.0.4 auf VDR 2.2.0). Für die Fernbedienung kommt der serielle ATRIC-Empfänger (müsste die Rev5 sein) zum Einsatz. und LIRC (lirc_serial).


    Vor dem Update war die Fernbedienung zwar schon etwas träge, aber nun ist diese gefühlt noch träger geworden, d.h. der VDR reagiert manchmal sehr verzögert auf einen Tastendruck oder es gibt keine Reaktion.
    Unter Kodi geht die Fernbedienung viel flüssiger (Kodi wird mit einem Script vom VDR aus gestartet und schaltet beim Beenden wieder auf den VDR).
    Dazu kommen Ausgaben wie

    Code
    1. Jan 12 16:24:03 vdr kernel: [ 3449.963748] lirc_serial: ignoring spike: 1 1 58779f93 58779f92 81c76 a7f84


    im Log, welche meiner Meinung nach vor dem Update nicht oder nicht in der Menge da waren.


    System 2 hat auch den gleichen Atric-Empfänger und diesselbe OS/VDR-Konfiguration (vom LCD mal abgesehen). System 2 funktioniert auch viel flüssiger mit der Fernbedienung und LIRC. Aber auch dort gibt es die "ignoring spike" Meldungen.


    Würde es etwas bringen, wenn man den USB-Atric-Empfänger verwenden würde. Dieser dekodiert ja die IR-Signale selber und könnte das System ggf. entlasten? Oder liegt das Problem mehr beim VDR, da Kodi, ebenfalls mit LIRC, ja anscheinend besser läuft.
    Oder gibt es evtl. Tipps zu den IR-Delayeinstellungen im VDR-Setup - können diese eine Verbesserung bringen?