Beiträge von UweHeinritz

    Hallo,
    gestern Abend konnte ich nun auch SkyGo richtig testen. Die komplette Serie (The Strain 3x4) lief ohne einen einzigen Ruckler durch :]. Das hatte ich bisher auf meinem VDR noch nicht geschafft.
    Da zur Zeit alles funktioniert (ruckelfreie Wiedergabe aller MKV, SkyGo, Amazon VOD, DVD, Aeon MQ 5 Skin), kann ich das Kapitel Kodi Update bis zum finalen Krypton Release abschließen.


    Tschau, Uwe.

    Perlbo:
    Hast du mal eine Version >= Beta2 probiert?
    Ich habe heute auf meinen VDR das Nightly vom 19.09 (und die dazu passenden InputStreams) installiert. Beim Probeschauen kam mir das Video wieder schön flüssig vor (gleiches Video wie zuvor 25FPS MKV, vom NAS).
    Ich konnte auch 25min schauen ohne das es ein mal mit Ruckeln angefangen hat. Eventuell wurde das Problem mit NVidia Karte ja behoben.
    Heute Abend teste ich mal noch einen Stream von Amazon oder SKY Go (die prinzipielle Wiedergabe funktioniert, hab ich vorhin schon probiert). Bei beiden hat es in den bisherigen Krypton Versionen reproduzierbar aller paar Minuten geruckelt.


    Tschau, Uwe.

    Perlbo:
    Ja das Ruckeln hab ich auch (NVidia GT 620). Am häufigsten tritt es bei 25FPS MKV und Serien von Amazon VOD auf. Bei 24FPS konnte ich das starke Ruckeln nicht beobachten. Wenn es anfängt stark zu ruckeln (nach 1-10 min) spule ich kurz 10s hin und her und dann läuft es wieder eine Weile.
    Generell scheint mir aber auch bei 24 und 30FPS die Ausgabe nicht so sauber/flüssig wie mit Kodi 16 zu sein. Das Umschalten der Bildschirmfrequenz klappt zwar, jedoch scheint es dennoch Microruckler zu geben.


    Es ist sehr schade das es zwar im Kodi 17 so viele schöne neue Features gibt, jedoch so etwas essentielles wie die ruckelfreie Wiedergabe (was ja schon mal funktioniert hat) nicht mehr möglich ist.


    Tschau, Uwe.

    Hallo,
    auch ich habe gestern auf Kodi 17 (Team Kodi Nightly build für ubuntu trusty unter Debian Jessie installiert) aktualisiert.
    Dabei habe ich mich an die Anleitung von nc17 gehalten (vielen Dank dafür).
    Sowohl skygo als auch Amazon prime funktionieren gut (habe beim Testen zumindest bis auf die engl. Standardtonspur keine Probleme bisher bemerkt).


    Jedoch ruckelte Kodi 17 mit meiner nvidia Grafikkarte ziemlich stark, egal welche Auflösung oder FPS die Videos hatten. Ist auch kein Wunder wenn eine CPU auf Volllast geht.
    Mit "Bildrate an Bildschirm" (genauen Name der Option habe ich nicht mehr im Kopf) wurde es zwar etwas besser, aber immer noch nicht zufriedenstellend.


    Als Fehler wurde ein Problem im nvidia-Treiber ausgemacht. Leider gibt es innerhalb von Kodi aber noch keine Lösung dafür.
    Damit das Problem aber nicht mehr auftritt, kann man Kodi mit folgendem Parameter starten (z.B. einfach eine .sh damit erzeugen):

    Code
    __GL_YIELD=USLEEP /usr/bin/kodi


    Da ich zwischen Softhddevice, Kodi und VM-Ware mit einem Init-Script umschalte (und darin start-stop-daemon verwende), habe ich einfach in meinem Script folgende Zeile eingefügt (einfach irgendwo bevor kodi als daemon gestartet wird):

    Code
    Export __GL_YIELD="USLEEP"


    Nach der Änderung ist die CPU-Last vergleichbar mit Kodi 16 und die Videos laufen alle wieder schön sauber.


    Tschau, Uwe.

    Hallo,
    scraper2vdr funktioniert nur mit epg2vdr zusammen.
    Wenn du kein epg2vdr verwendest, dann passen die EventIDs deiner VDR-EPG-Datenbank nicht zu denen welche scraper2vdr verwendet. Darum wird dann auch nichts angezeigt.
    epg2vdr alleine geht (da hast du dann aber keine zusätzlichen scrap-Infos/Bilder), aber scraper2vdr alleine geht nicht.


    Tschau, Uwe.

    Komisch dass das bei dir nicht geht. In meiner VM habe ich das mit % in den Aufnahmen extra getestet.
    Am besten wäre es wenn jemand vom epgd-Team den Quelltext (die Funktion für das Bereinigen der Aufnahmen hat ja nur 10 Zeilen) mal anschaut. Die haben wesentlich mehr Erfahrung mit den Strings in Verbindung mit der DB-API als ich (zumal die Funktion von mir auch gar nicht verändert/angefasst wurde).


    Tschau, Uwe.

    Hallo,
    die Spaltennamen stimmen aber schon, oder? Nicht das sich diese beim http-Branch geändert haben.
    In der Funktion werden nicht die Spaltennamen welche in der der db-dict eingetragenen sind verwendet, sondern Louis hat die dort von Hand rein geschrieben ("uuid", "rec_path" und "rec_start").
    Das kann ich bei Gelegenheit mal noch ändern.


    Tschau, Uwe.

    Hallo,
    ich hab mir das mal angesehen. Der Quelltext sieht für mich in Ordnung aus.
    Ich habe in meine Test-DB auch mal einen Eintrag in der recordings-Tabelle einen Eintrag erzeugt der bei dir scheinbar einen Fehler verursacht (uuid=87AF3AF6-4859-4149-B6CF-96D82E132C4C, rec_path=/srv/vdr/video.00/Abenteuerfilm/) und die verwendete uuid in der Setup.conf angepasst (das der scraper2vdr auch die Zeile mit deiner uuid berücksichtigt).
    "Leider" funktioniert das bei mir aber problemlos. Der Eintrag wurde beim Aufräumen der recordings berücksichtigt und in der Datenbank gelöscht. Warum das bei dir nicht funktioniert kann ich mir nicht erklären.
    Was mich aber doch verwundert sind folgende Dinge:
    -warum hast du einen rec_path ohne richtige Aufnahme (eigentlich sollten die doch immer mit Aufnahmezeitpunkt.rec aufhören, bei dir ist aber nach dem / einfach schluss)?
    -wieso fehlt in dem delete from ein Stück vom where? Eigentlich sollte da das hier verwendet werden: where uuid='xxx' and rec_path='xxx' and rec_start=xxx


    Ich habe bei mir auch mal einen Eintrag mit % im rec_patch erzeugt. Auch dieser wurde erfolgreich gelöscht.


    Vielleicht wäre es das günstigste du löscht diese Einträge von Hand aus der DB.


    Tschau, Uwe.

    Hallo,
    habe eine neue Version (0.1.12) hoch geladen.
    Mit dieser werden die Posterthumbs wieder korrekt angezeigt und es gibt auch keine Poster mehr bei denen die Größe um +-1px abweicht.
    Beides waren Rundungsfehler (C rechnet eben bei gleicher Syntax doch etwas anders als Delphi) .
    Zusätzlich habe ich die Option und auch den kompletten alten Quelltext des alten Datenbankparsers entfernt. Es gibt jetzt nur noch den neuen Parser.


    Frodo:
    Ich habe mir den skindesigner noch nicht angesehen, gehe aber davon aus das es so ist wie du beschreibst. Meine Änderung dient dazu das man jetzt genau definieren kann wie groß die Poster gespeichert werden und so der Skindesigner immer nur von einer Postergröße/Seitenverhältnis ausgehen muss.
    Dadurch kann wesentlich schöner um ein Poster drum rum gezeichnet (wie z.B. das DVD-Cover im Vectra Skin) werden. Außerdem lässt sich so wesentlich besser der für ein Poster vorgesehene Platz planen (alle Poster sehen ja immer gleich aus).


    Tschau, Uwe.

    Hallo,
    habe gerade gesehen das dies bei mir auch so ist. In meiner VM wo ich teste hab ich das nicht bemerkt (mangels Aufnahmen).
    Ich schau mal ob ich die Ursache finde. Die Bilder auf der Festplatte sind aber scheinbar in Ordnung.


    Tschau, Uwe.

    Huch, wo kommen denn die mit 500x734px und 499x735 her :wow
    Könntest du mir per PN mal die Film/Seriennamen, welche Bilder mit der falschen Größe haben, senden.
    Wenn ich die auch in meiner DB habe, könnte ich mal nachschauen warum dir 1px in der Höhe fehlt.


    Tschau, Uwe.

    Hallo,
    es gibt eine neue Version im git (0.1.11).


    Im Setup kann nun eine feste Größe für die Poster aktiviert werden. Dadurch werden alle Poster in der gleichen Bildgröße auf die Festplatte gespeichert. Dies ist vor allem für die Verwendung von Skins interessant, da nun eine feste Bildgröße für die Poster eingeplant werden kann (z.B. für ein DVD-Cover um das Poster).
    Bisher unterschieden sich alle Poster in ihrer Größe und auch im Seitenverhältnis. Die Filmposter waren auch alle unterschiedlich groß (von 500x550 bis 500x850).


    Für die Staffelposter kann eine extra Größe definiert werden, da diese etwas kleiner sind als die anderen.
    Die Standardwerte für beide Poster entsprechen dem Seitenverhältnis der Serienposter (denke davon gibt es am meisten Bilder). Dadurch werden die Staffel und Filmposter etwas gestaucht/gestreckt (2-3%).
    Für die Serien/Filmposter wurde die Breite der Filmposter als Standard gewählt.


    Die Poster werden damit auf folgende Auflösungen geändert:
    Serienposter: 680x1000 -> 500x735
    Staffelposter: 400x578 -> 400x588
    Filmposter: 500x750 -> 500x735


    Damit die Bilder nicht zu sehr verzerrt werden, kann die maximale Verzerrung in % im Setup eingestellt werden (Default = 5%). Sollte eine größere Verzerrung notwendig werden um auf die Zielauflösung zu kommen, wird das Bild mit der maximal erlaubten Verzerrung skaliert und dann der zu verwendende Bildbereich ausgeschnitten.
    Dadurch wird bei wirklich ungünstigen Quellbilder (betrifft eigentlich nur Filmposter mit komplett falscher Auflösung) ein Teil des Bildes abgeschnitten (dafür wird das Bild aber eben nicht zu sehr verzerrt).


    Ich habe bei mir die Option aktiviert und kann sagen dass mit den maximal 5% Verzerrung die Anpassungen der Bilder so gut wie nicht auffallen. Dafür eröffnet es aber gerade bei den Skins eine bessere Behandlung der Poster.


    Mir wäre es übrigens am liebsten wenn die Option als Standard aktiviert wird, da bis auf eine höhere Prozessorlast (liegt in meiner VM bei ca. 1-1.5) nichts dagegen spricht die Bilder auf Einheitsgröße zu bringen.
    Wenn dies als Standard aktiviert ist, könnten die Skin-Designer dann davon ausgehen das alle Poster gleich groß sind (sollte ich da eventuell die Breiten und Höhen gar nicht im Setup einstellbar machen???).


    Nachdem die Option aktiviert/deaktiviert wurde, müssen alle Bilder lokal aktualisiert werden. Dies kann über den Eintrag im Setup "Alle Daten (Serien, Filme und Bilder) neu laden" erfolgen.


    Ich habe ziemlich viel an dem Speichern der Bilder geändert, wäre schön eine Ruckmeldung zu erhalten ob es so funktioniert.


    Tschau, Uwe.

    Hallo,
    und was sollte ich da in deiner Posting-Historie gefunden haben? Du meinst doch sicher der Thread "Wiedergabe einer Aufzeichnung...", oder?
    Der hilft aber leider nicht weiter, Da ich bereits 50Hz verwende und die Einträge auch nicht so häufig wie in deinen Postings dort auftreten.


    Ich habe gerade noch mal auf den 2 anderen VDRs geschaut welche noch den alten Softwarestand (VDR 2.0.4) haben.
    Dort erscheinen auch aller 1min solche Einträge im Log. Ist also doch kein neues Problem und dürfte auch auf meinem VDR schon vor der Neuinstallation so gewesen sein (die 3 haben identische Hard und Software gehabt).
    Stellt sich nun die Frage woher kommt das? Ich kann mir vorstellen das die 50Hz vom Bildschirm eventuell doch nicht ganz exakt 50Hz sind, sondern 50.06Hz. Das würde genau aller 1min 1 Zwischenbild erfordern.
    Aber die modeline verwenden doch sehr viele so, oder (hab die damals aus einer alten Anleitung von wbreu).


    Tschau, Uwe.

    War ja klar das ich was vergesse.
    60hz ist deaktiviert.


    Hier die Einstellungen vom Softhddevice (Auszug):


    Tschau, Uwe.

    Hallo,
    ich habe gestern meinen Produktiv-VDR komplett neu installiert. Dazu habe ich ein Debian jessie und die vdr/plugin-Sourcen von Frodo verwendet.
    Ich habe so gut wie alle alten Konfigurationsdaten (xorg.conf, softhddevice-Teile der Setup.conf vom vdr...) wieder verwendet, da die alte Konfiguration sehr gut lief.


    Leider habe ich aber nun jede Minute folgenden Eintrag im Log:

    Code
    Mar  8 11:22:56 myvdr vdr: video: slow down video, duping frame
    Mar  8 11:22:56 myvdr vdr: video: 13:56:49.932  +45 1475   0/\ms 105+6 v-buf
    Mar  8 11:23:56 myvdr vdr: video: slow down video, duping frame
    Mar  8 11:23:56 myvdr vdr: video: 13:57:49.872  +51 1510   0/\ms  98+7 v-buf
    Mar  8 11:24:56 myvdr vdr: video: slow down video, duping frame
    Mar  8 11:24:56 myvdr vdr: video: 13:58:49.812  +58 1641   0/\ms 112+6 v-buf
    Mar  8 11:25:56 myvdr vdr: video: slow down video, duping frame
    Mar  8 11:25:56 myvdr vdr: video: 13:59:49.752  +64 1643   0/\ms 105+7 v-buf


    Für Empfangsprobleme sieht das doch eher zu regelmäßig aus, oder? Ist ja immer beim Zeitstempel xx:xx:49:8xx. Der jeweils zweite Eintrag dürfte ja vom Sync für das Audiosignal zum Video kommen und sollte normal sein. Aber der verdoppelte Frame gehört doch nicht so.
    Woran könnte das denn liegen? Ich habe auch schon mal alle Plugins außer softhddevice, femon und remote deinstalliert. Das hat aber nichts am Verhalten geändert.


    Meine Hardware steht ja in der Signatur, und als Software verwende ich das hier:


    Als Meine xorg.conf sieht so hier aus (nur Auszüge):


    Was könnte denn die Ursache für den verdoppelten Frame sein?


    Tschau, Uwe.

    Ich habe mal den Autodelete-Teil des ursprünglichen Patches extrahiert und an den vdr 2.2.0 angepasst.
    Damit gibt es nun die Option eine Aufnahme nach dem Schneiden automatisch löschen zu lassen.


    Den Patch habe ich mit frodos vdr-2.2.0 geschrieben und getestet. Damit funktioniert er prima. Es gibt auch keine Probleme mit der im VDR eingebauten CutterQueue. Es werden sauber alle Aufnahmen nach dem Schneiden zum Löschen markiert.


    Tschau, Uwe.