Posts by Der_Pit

  • [xmltv2vdr] invalid locking sequence

    Hi,


    mit xmltv2vdr (0.2.1/git + gcc fixes) bekomme ich bei VDR 2.4.0 invalid locking sequence reports wenn er die Daten in den vdr importieren will. Hat da schon wer 'nen Fix? Ich hab mir den code zwar angeguckt, steh da aber eher wie der Ochs vor dem Quantenmechanikbuch :o

  • dfatmo und vaapidevice / VDR 2.4.0

    Sorry, hab vergessen zu melden dass es auch einwandfrei läuft: Sowohl Anzeige selbst als auch Zusammenspiel mit DFAtmo sind problemos, lediglich (wie auch mit vaapidevice) gib't ein Audio-offset von ~100ms, und manchmal ist der beim Umschalten im Sekundenbereich und kann erst durch erneutes Schalten auf den Kanal zurückgesetzt werden.

  • DVBSky S952: Keine V-Sender auf einem Tuner

    So. Dummerweise hatte ich das Voltmeter vergessen, war also nix mit Spannung messen :P


    Gut, hab ich stattdessen ein anderes Kabel genommen. Leider damit auch kein V-Empfang X(


    Also gut, dachte ich - wenn ich eh schon da oben bin probiere ich halt auch noch den SCR Modus aus. Dafür hatte ich nämlich die Karte eigentlich geholt gehabt (und letzten Herbst den Inverto mit Unicable...). Also Kabel umgesteckt vom Legacy auf den Unicable Ausgang. Und was soll ich sagen - damit geht's. Alle Kanäle da, auf beiden Tunern....


    Insofern zwar nicht [Solved] da der Tuner wohl wirklich nicht ganz koscher ist, aber doch immerhin [WorksForMe] ;)

  • DVBSky S952: Keine V-Sender auf einem Tuner

    Hi,


    ich hab mir eine neue DVB-Karte geleistet, die DVKSky S952 v3 mit zwei Tunern.

    Leider kann ich damit auf einem Tuner keine vertikal polarisierten Kanäle empfangen :(


    Ich war schon am überlegen wie ich sie am besten umtauschen kann (ich habe sie, via Amazon.de, in/nach Schweden gekauft, bin jetzt aber ein halbes Jahr beruflich in Spanien). hab dann aber hier einen alten Thread gefunden der nahelegt es könne evtl. an der Kabellänge/-qualität liegen oder ein diseqc Problem sein. Der LNB selbst (Inverto Quad Black) scheint jedenfalls OK. Mit dem 2. Tuner oder einem Sundtek USB funktioniert ja alles einwandfrei mit guter Signalstärke.


    Kann es sein dass durch ein zu langes Kabel nicht genug Spannung zum Umschalten ankommt? Gibt's da 'ne einfache Möglichkeit 'nen Verstärker zwischenzuschalten? Oder kann man die Schaltspannungen evtl. irgendwo auf der Karte anpassen? Oder kann ein Eingriff via diseqc da was verbessern?


    Kann man alternativ einen Tuner in vdr irgendwie so konfigurieren dass darüber nur horizontale Sender eingestellt werden?


    (Sorry für die vielen, teilweise vielleicht blöden Fragen - ich hab nicht wirklich die Ahnung, aber immer das Bestreben viel neues zu lernen...)

  • dfatmo und vaapidevice / VDR 2.4.0

    Quote from rofafor

    FYI: vaapidevice doesn't support atmo grab service and therefore is using totally different code path in the dfatmo plugin than with softhddevice.

    Yes, I'm aware of that - this is what I tried/used when setting softHdPlugin to NULL in dfatmo code on the old machine. It then uses the GrabImage function, and on the old machine this did work.... Still no clue why it doesn't on the new one. The standard svdrp grab command does work on both at least.

    Quote from SurfaceCleanerZ

    Hi,

    Auch softhddevice kann mit VAAPI genutzt werden. Teste doch mal mit EasyVDR3.5 mit aktuellem nachträglich upgegradetem Ubuntu Kernel. Sollte laufen. Ist dann ein 2.2 aber mit softhddevice. Das kann auch VAAPI.

    MfG Stefan

    Ist das dann eine ältere Version von vaapidevice vor der Umbenennung? Welche? Oder komm ich irgendwo (einfach) an die Paketquellen vom der dort verwendeten Version von softhddevice?

  • dfatmo und vaapidevice / VDR 2.4.0

    So letzteres hab ich grad mal versucht auf dem alten VDR, in vdrplug_dfatmo.cpp cPlugin *softHdPlugin = NULL gesetzt.

    Damit bekomme ich im Log jede Menge Meldungen

    May 07 22:44:00 vdr vdr[8580]: [8624] [softhddev]GrabImage: 0, 0, 100, 128x72

    und Atmolight funktioniert. Da obige Meldung (trotzdem) von softhddev kommt heisst das wohl dass das Problem irgendwo bei vaapidevice liegt, oder zumindest am Zusammenspiel mit dfatmo.


    Gibt's denn noch andere Plugins, die GrabImage verwenden? Funktionieren die? Mal suchen gehen....

  • dfatmo und vaapidevice / VDR 2.4.0

    Hmm, das ist doch für vdpau? Wie krieg ich das auf dem Geminilake zum laufen?

    Oder meinst' nur wg. vdr 2.4.0? Da hast natürlich recht - an dem kanns eigentlich gar nicht liegen, weil es auf dem alten VDR ja läuft. Andererseits wird da ja dann gar nicht der GrabImage code verwendet :?

    Ich kann höchstens mal versuchen beim alten im dfatmo softhddevice abzuschalten....

  • 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 :)