Posts by Der_Pit

  • dfatmo und vaapidevice / VDR 2.4.0

    Hi,

    ich versuch gerade mein Atmolight mit dem neuen, vaapi-basierten VDR und dfatmo zum laufen zu bekommen. softhddevice hatte da ja eine eigene Funktion eingebaut, ich bin mir nur nicht ganz im klaren ob die optional war/ist, oder ob es auch ohne gehen sollte (die wurde ja bei vaapidevice entfernt).

    Kompilieren von dfatmo ging problemlos, aber wenn ich es tatsächlich aktivieren will kommt

    Code
    May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo grab thread started (pid=12080, tid=12183, prio=high)
May 06 20:56:28 vdr2 vdr[12080]: [12184] DFAtmo output thread started (pid=12080, tid=12184, prio=high)
May 06 20:56:28 vdr2 vdr[12080]: [12182] animator thread thread ended (pid=12080, tid=12182)
May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo: grab function returned wrong image size (24798,27648)!
May 06 20:56:28 vdr2 vdr[12080]: [12183] DFAtmo grab thread ended (pid=12080, tid=12183)
May 06 20:56:54 vdr2 vdr[12080]: [12084] frontend 0/0 lost lock on channel 2 (ZDF HD), tp 111361

    Geht so bei jedem Startversuch, lediglich die tatsächliche Grösse (24798 im obigen) ist jedesmal etwas anders. Wenn ich im Code danach suche seh ich dass dfatmo ohne softhddevice ein normales GrabImage macht,

    uint8_t *grabImg = cDevice::PrimaryDevice()->GrabImage(grabSize, false, 100, grabWidth, grabHeight);

    Hat sich da was im neuen VDR geändert, und es geht deswegen schief, oder kollidiert da eher was mit vaapidevice?

    Nutzt wer so ein (altes) Atmolight erfolgreich mit vdr 2.4.0/vaapidevice?

  • vaapidevice unter openSUSE 42.3 compilieren

    FireFly Ich hab noch explizit ffmpeg >= 3.2 drin.

    kls: Check auf jeden Fall nochmal welche libva Du jetzt hast. Das normale 'zypper up' bleibt beim vorhandenen Repo wenn was schon installietr ist, da brauchst Du ein --force oder (wie vorgeschlagen) die Angabe der zu installierenden Version.

    Vermutlich wäre auch ein zypper dup -r X11:Xorg keine schlechte Idee um das X-Zeugs konsistent zu haben. Aber ich weiss nicht genau, was dort alles drin ist. Also wenn, dann die Update-Liste gut anschauen...

  • vaapidevice unter openSUSE 42.3 compilieren

    der xcb Fehler brauch die Installation von xcb-util-wm-devel.

    Wahrscheinlich hat Leap 15 (Name kommt übrigens durch die Angleichung an die Business Version SLES 15) eine höhere Version von libprocps (42.3 hatte noch die 3, TW ist schon bei 6). Ich würde in dem Fall '2' wählen (ignore dependency) und auf backward compatibility hoffen, oder halt die gpu-tools nicht installieren (sie werden IIRC nicht benötigt)

  • [skinnopacity] compilieren mit neuem ImageMagick

    Nachdem skin-nopacity auf meinem alten VDR danke der Info hier wieder läuft wollte ich es auch auf dem neuen installieren. Leider ist Tumbleweed da aber zu modern und hat schon ImageMagick 7 drauf, was zu Fehlern im Zusammenhang mit den Änderungen rund um PixelPacket führt,

    Code
    imagemagickwrapper.c: In member function cImage* cImageMagickWrapper::CreateImage(int, int, bool):
imagemagickwrapper.c:30:19: error: PixelPacket does not name a type
     const PixelPacket *pixels = buffer.getConstPixels(0, 0, w, h);
                   ^~~~~~~~~~~
imagemagickwrapper.c:36:40: error: pixels was not declared in this scope
         for (const void *pixels_end = &pixels[w*h]; pixels < pixels_end; ++pixels)
....
imagemagickwrapper.c:37:52: error: MaxRGB was not declared in this scope
             scaler.PutSourcePixel(pixels->blue / ((MaxRGB + 1) / 256),
                                                    ^~~~~~

    Ist da sonst noch wer drübergestolpert und hat 'nen passenden Patch parat? Meine eigenen Versuche waren, ehm, niederschmetternd :o

  • vaapidevice unter openSUSE 42.3 compilieren

    Also ich hab's hier gerade mal auf meinem 42.3 desktop probiert (der hat aber keine TV-Hardare und 'ne nvidia karte...)

    Hab mir die source rpm von libva2 geholt, compiliert, und (mit dem ffmpeg 3.4 aus packman, sowie den entsprechenden libs wie libavcodec und libswscale auch von dort) compilieren dann vdr und vaapidevice.

    Wenn Du die libva2 schon hast aus der obigen Quelle sollte es nur am ffmpeg hängen - vaapidevice will ja mindestens 3.2.

    (3.4 ist zwar auch in den opensuse repos, die sind aber immer beschnitten - packman war da ja schon immer Pflicht).

    Oder eben gleich auf die 15.0 gehen - die ist ziemlich kurz vor dem Release...

  • vaapidevice unter openSUSE 42.3 compilieren

    Hmm, ich befürchte da wirst Du suchen müssen. Packman hast Du aber aktiv, oder?

    Ich hole mir in solchen Fällen meist die srpms von factory/tumbleweed/packman und bau mir Pakete selbst mit rpmbuild.

    (Meinen Neuen hab ich lieber gleich mit TW aufgesetzt, vor allem allerdings wg. Geminilake Prozessor...)

  • DVBSky S952 Fernbedienung: Nicht alle Tasten aktiv

    Hi Leuts,

    für meinen 'Neuen' hab ich mir eine S952 (V3) gekauft. Die kommt ja mit einer Fernbedienung, was ganz praktisch ist. Die wird anscheinend auch gut erkannt,

    Code
    Apr 30 09:59:48 vdr2 kernel: rc_core: IR Remote Control driver registered, major 244
Apr 30 09:59:48 vdr2 kernel: SMI PCIe driver 0000:01:00.0: card detected: DVBSky S952 V3
Apr 30 09:59:49 vdr2 kernel: Registered IR keymap rc-dvbsky
Apr 30 09:59:49 vdr2 kernel: rc rc0: IR (DVBSky S952 V3) as /devices/pci0000:00/0000:00:13.0/0000:01:00.0/rc/rc0
Apr 30 09:59:49 vdr2 kernel: input: IR (DVBSky S952 V3) as /devices/pci0000:00/0000:00:13.0/0000:01:00.0/rc/rc0/input16
Apr 30 09:59:49 vdr2 kernel: rc rc0: lirc_dev: driver SMI_PCIe registered at minor = 0

    Allerdings funktionieren damit nicht alle Tasten :(

    Ich hatte das mit xev probiert (da es ja in /dev/input auftaucht kriegt X die Tasten ja mit...), und für Dinge wie Zahlen. Power und Multimedia funktioniert das auch, die Tastendrücke werden angezeigt. Andere wichtige Tasten wie Cursor, Menu oder die Farbtasten geben aber kein Ergebnis.

    Dem VDR geht's genauso, ich hatte ihn (mit remote plugin) gestartet, da geht er ja in den Lern-Modus und will als erstes die 'Up' Taste. Kann ich aber drücken so viel ich will - da kommt nix an :(

    Seh' ich das richtig dass die Übersetzung (unveränderbar) aus dem Kernel kommt, /lib/modules/4.16.3-1-default/kernel/drivers/media/rc/keymaps/rc-dvbsky.ko?

    Oder gibt's da noch eine zusätzliche Konfiguration?

    Nutzt wer diese FB direkt via /dev/input? Oder brauche ich da doch LIRC dafür? (Hab ich nicht installiert, k.A. wo der lirc_dev Eintrag im Log genau herkommt....)

  • Neuer VDR für UHD

    So, ich bin endlich dazu gekommen mir auch mein J4105-ITX mal genauer anzusehen. Haben tu ich es schon 'ne Weile, aber die Arbeit liess mir keine Zeit :( Allerdings ist es bei mir nur ein 'normaler' HD, da ich keinen UHD Fernseher/Monitor hab...

    Gestern war erstmal OS installieren, kompilieren und Pakete bauen dran. Spät abends lief dann alles soweit dass ich den vdr starten konnte, der spuckte aber Massen von

    Code
    VAAPI-ERROR: video/vaapi: vaPutSurface failed 20
VAAPI-ERROR: video: display buffer empty, duping frame (1/0) 0

    aus. Ich vermute/hoffe dass das nur daran lag dass das SAT Kabel noch nicht dran war...

    Zum Glück ist ja morgen wieder Feiertag :)

  • tvscraper in 2.4.0

    Sorry fnu - war etwas von der Arbeit eingespannt und hatte keine Zeit für's Forum...

    Am Skin selbst kann es nicht liegen, denn es tritt mit allen auf (zumindest original n0pacity und die skindesigner skins - IIRC auch mit metric, definitiv mit den beiden Shady). Auf tvscraper hatte ich vor allem getippt weil ich es das erste mal bemerkt hatte nachdem ich den installiert hatte (das war aber noch auf dem alten 2.2 System, wo es immer nur während des Schneidens auftrat). Aber hast natürlich recht, ich muss das verifizieren und auch mal ohne den Scraper probieren und/oder sonstige Plugins auch mal abschalten. Mal sehen ob ich das heute abend noch hinkrieg - sonst eher erst Sonntag oder Montag...

  • tvscraper in 2.4.0

    Hi,

    ich hab gerade meinen VDR auf 2.4.0 aktualisiert, und mit einigen Veränderungen läuft jetzt das meiste wieder. Probleme hab ich jedoch mit tvscraper:

    Ich dachte erst es liegt am neuen Skin (shady/kiss), denn in der Info-Ansicht für Aufgezeichnete Filme ging gar nichts: Kein Wechsel des Anzeigetabs (Filminfo/Aufzeichnungsinfo etc) mit den vor/zurücktasten, noch nichtmal scrollen des (zu langen) Infotextes mit hoch/runter....

    Einziger Hinweis im log (level 3) war das permanent die marks-Datei der Aufnahme gelesen wurde,

    Code
    Apr 22 23:04:14 vdr vdr[7767]: [7767] loading /video0/Die_Logan_Verschwörung/2018-01-13.23.15.7-0.rec/marks
Apr 22 23:04:15 vdr vdr[7767]: [7767] loading /video0/Die_Logan_Verschwörung/2018-01-13.23.15.7-0.rec/marks
Apr 22 23:04:16 vdr vdr[7767]: [7767] loading /video0/Die_Logan_Verschwörung/2018-01-13.23.15.7-0.rec/marks
Apr 22 23:04:17 vdr vdr[7767]: [7767] loading /video0/Die_Logan_Verschwörung/2018-01-13.23.15.7-0.rec/marks
Apr 22 23:04:18 vdr vdr[7767]: [7767] loading /video0/Die_Logan_Verschwörung/2018-01-13.23.15.7-0.rec/marks

    Ich hab dann (nachdem ich die Patches zum kompilieren gefunden hatte...) wieder zurück auf n0pacity gewechselt (ohne skindesigner), und dort wurde dann die Seite im Sekundentakt neu aufgebaut.

    Das ist ein Verhalten das ich schon kannte, beim alten VDR (2.2.0) ist das immer aufgetreten während ich eine Aufnahme geschnitten hab (bei allen Info-Anzeigen, nicht nur da wo gerade geschnitten wird). Jetzt mit 2.4.0 scheint das permanent der Fall zu sein. Bei Skindesigner-Skins tritt das Flackern nicht auf weil meine Kiste dafür viel zu lahm ist. Stattdessen reagiert sie einfach gar nicht :o

    Ist da schonmal jemand anders drüber gestolpert und hat 'ne Idee wie man das los wird? Oder muss ich den Scraper beerdigen?

  • Updatequellen Suse 12.1 ?

    12.1 hat schon ewig EOL erreicht. Den letzten Paketstand findest Du bei der GWDG:

    http://ftp.gwdg.de/pub/opensuse/discontinued/

    Alternativ gab's das Evergreenprojekt, https://en.opensuse.org/openSUSE:Evergreen,

    aber nicht für 12.1, selbst 13.1 ist dort quasi scheintot.

    Also ist wohl schon Update/Neuinstallation angesagt. Meinen VDR hab ich letztens auf 42.3 hochgezogen, da läuft aber nur der 'stable' VDR drauf. Developer hab ich noch nicht getestet...