Beiträge von Zabrimus

  • Video Treiber für Odroid-N2+ (softhdodroid)

    Der Include wird zum Bau gar nicht benötigt. Nachdem ich den rausgeworfen hatte, compiliert alles. Allerdings startet das Plugin nicht mehr :(

    Code
    Dez 23 11:52:57 odroid2 vdr[5994]: [5994] ERROR: /usr/local/lib/vdr/libvdr-softhdodroid.so.2.6.3: undefined symbol: XParseGeometry
Dez 23 11:52:57 odroid2 systemd[1]: vdropt.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Dez 23 11:52:57 odroid2 systemd[1]: vdropt.service: Failed with result 'exit-code'.

    Es gibt eine weitere Abhängigkeit zu X11 oder zumindest der Lib?

  • [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

    Ich bin auf die Suche gegangen. Bis zu "connecting..." kommt satip gar nicht.

    Code
    void  satip_rtsp_check_update(struct satip_rtsp*  rtsp, int abort)
{
  if (abort) rtsp->status = RTSP_ABORTING;
  switch ( rtsp->status )
    {
    case RTSP_NOCONFIG:
       if ( satip_valid_config(rtsp->satip_config) &&
             rtsp->timer == NULL )
    {

    Das Problem ist, daß satip_valid_config(rtsp->satip_config) immer 0 liefert und damit wird der case-Block nie aufgerufen. Wenn ich die Bedingung rausnehme und auf rtsp->timer kürze, dann wird ein Connect ausgeführt, aber es wird immer nur OPTIONS ausgeführt und die Antwort empfangen.



    Ich werde vtuner jetzt mal auf dem Entwicklungsrechner probieren. Weil es ja eigentlich funktionieren soll, wenn man die Meldungen hier im Thread alle liest. Vielleicht werde ich dann erleuchtet.

  • [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

    Zitat von cinfo

    dann sollte auch mal ein Logfile in /tmp liegen

    Ob ich die Ausgabe umleite oder auf der Konsole ausgebe, sollte eigentlich keinen Unterschied machen.

    Mit debug=1 erhalte ich zumindest mehr Lebenszeichen


    und

    und weiterhin

    Code
    odroid4:~ # cat /tmp/satip.log 
[1305 satip_rtp.c:295]  info: rtp/rtcp port 45385/45386

    Bei einem Kanalwechsel per svdrp kommt das

    Zitat von Joe_D

    Und was versprichst Du Dir dann von vtuner-ng? ;)

    Nur weil es bei mir funktioniert, könnte eine Alternative trotzdem sinnvoll sein. Und natürlich ist es auch Neugier und ein Bastelzwang ;)

  • [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

    Ich versuche, den vtuner unter LibreELEC/amlgx zum laufen zu bringen - bisher ohne Erfolg.

    Der Kernel ist 6.6.0, arm64

    Code
    odroid4:~ # uname -a
Linux odroid4 6.6.0 #1 SMP PREEMPT Fri Dec 22 13:38:17 CET 2023 aarch64 GNU/Linux

    Folgende Versuche habe ich unternommen:

    Code
    odroid4:~ # /usr/sbin/modprobe vtunerc devices=1
[   51.546782] vtunerc: loading out-of-tree module taints kernel.
[   51.548341] virtual DVB adapter driver, version 2.0, (c) 2021 Honza Petrous, SmartImp.cz
[   51.552923] dvbdev: DVB: registering new adapter (vTuner proxy)
[   51.556219] (NULL device *): DVB: registering adapter 0 frontend 0 (vTuner proxyFE DVB-Multi)...
[   51.557587] vtunerc: registered /dev/vtunerc0


odroid4:~ # /usr/local/bin/satip -h 192.168.178.236 -d /dev/vtunerc0 -m 2 -l 4
[1353 satip_rtp.c:295]  info: rtp/rtcp port 45791/45792

    Ich habe 2 verschiedene SAT/IP Server (beide DVB-C) getestet: Minitsatip und OctopusNet.


    VDR gibt folgendes aus:

    Und dann gibt es noch

    Code
    odroid4:~ # cat /proc/vtunerc0 
[vtunerc driver, version 2.0]
 vtunerc0 used by : 1
 adapter0 in use  : yes
 status           : FE_NONE
 last change      : 985
 ts data          : 0
 internal filler  : 0
 external filler  : 0


    Mehr Ausgaben gibt es nicht und ich komme nicht weiter und bin ein wenig ratlos. Mit dem satip-Plugin funktioniert alles soweit einwandfrei.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Die Patches um die es geht, befinden sich in packages/vdr/_vdr/patches und werden vom CE/LE Build selbst angewandt, wenn sie vorhanden sind.


    Das Log bei

    Code
    ./build.sh -config CoreELEC-20-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools -package _vdr

    müsste so aussehen:

    Und das sind genau die 9 Patches, die ich meinte. Gerade der Patch packages/vdr/_vdr/patches/0001-implement-DrawScaledImage.patch ist für das web-Plugin wichtig und der Patch packages/vdr/_vdr/patches/vdr-2.6.3-dynamite.patch wird für das dynamite-Plugin benötigt.


    Mit dem Parameter -package wird nur das eine Paket (+ evt. Abhängigkeiten) gebaut. Das geht schneller, als der komplette Build, erzeugt aber kein Image. Es geht aktuell nur um die Frage, warum die Patches für den VDR nicht greifen, obwohl sie (hoffentlich) im Verzeichnis vorhanden sind.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Meine Güte. Ist das lang her. Jetzt weiß ich auch wieder, warum ich das DummyOSD im web-Plugin eingeführt hatte. Das weiß ich jetzt wieder, nach langem suchen und testen :(


    Wenn das web-Plugin mit dem Parameter

    -o oder --dummyosd

    gestartet wird, dann funktioniert alles so wie gewünscht.


    Also falls jemand das Problem hat...An den Parameter denken. Gibt es Situationen, in denen das DummyOSD nicht gebraucht wird? Ansonsten würde ich das per Default einschalten und den Parameter entfernen bzw. unbrauchbar machen.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Mit dem dynamite-Patch sollten 9 Patches angewandt werden, aber nur 6 tauchen im Log auf. Das ist überaus seltsam.

    Ich versuche mal die Schritte nachzuvollziehen.


    Edit:

    Code
    ./clean-package.sh _vdr 
./build.sh -config CoreELEC-20-ng -extra dynamite,channellogos -addon dvb-latest,dvb-tools,network-tools,system-tools -package _vdr

    Und es werden alle 9 Patches angewandt.


    Was gibt denn bash --version aus?

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Ich bin sehr unzufrieden :(


    Es gibt einen Unterschied im Verhalten der Menutaste zwischen der Entwicklungsmaschine und dem N2+ (VDR*ELEC). Die Plugins bekommen die Menutaste nicht, also kann es meines Erachtens nur an einem Patch liegen. Auf jeden Fall ist das unterschiedliche Verhalten alles andere als erwünscht und richtig ätzend.


    Enwicklungsmaschine:

    - Film in der Mediathek wird abgespielt

    - Menu-Taste und das web-Plugin wird beendet, das TV-Bild kommt


    N2+:

    - Film in der Mediathek wird abgespielt

    - Menu-Taste, aber das web-Plugin läuft weiter. Das Video (im Skindesigner) wird skaliert weiter abgespielt und ich habe dann den Menu-Eintrag "Aufzeichnung beeenden" oder ähnlich.

    - Das Problem zieht sich dann sogar durch. Z.B. Tagesschau auf ARD. Dann sind plötzlich beide OSD (web + VDR) flackernd sichtbar und es schwer, da wieder raus zu kommen.


    Auf der Entwicklungsmaschine kommt bei der Menu-Taste das:

    Code
    Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Destruct WebOSDPage, osdMode 1
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Delete Player...
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Activate video player: Nein
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Detaching HbbTV ait filter from device 2
Dez 17 11:17:23 odroid1 vdr[4531]: [4531] [vdrweb] Attached HbbTV ait filter to device 2, vdrDev=1 actDev=2, Sid=0x283d

    Und damit wird das web-Plugin beendet und dem VDR wieder die Kontrolle übergeben. So wie es sein sollte. Auf dem N2+ kommt die Ausgabe nicht, so gar nicht, es gibt einfach nix. Das web-Plugin läuft weiter - in Konkurrenz zum VDR.


    Edit:

    Das Problem tritt auch ohne alle Patches auf. Die Plugins wurden auch auf ein Minimum reduziert, aber das brachte auch nichts.

    Was kann denn noch das unterschiedliche Verhalten provizieren?

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Es gibt da ein sehr interessantes Projekt [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16. Für CE wird allerdings noch der Kernel 4.9 verwendet. Ich habe da mal ein wenig gebastelt:

    Allerdings scheint sich satip zu nichts zu verbinden. Ich weiß nicht, woran es liegt. Bisher ist mir noch keine Fehlermeldung untergekommen, die einen Hinweis gibt, oder ich bin nicht in der Lage das erkennen.


    Also sollte man die Hoffnung noch stark runterschrauben. Falls das jemand auch probieren will: Es ist der vtuner-Branch von VDR*ELEC. Der Patch packages/vdr/vdr-depends/_vtuner-ng/patches/4.9.patch ist nur für CE (Kernel 4.9). Für LE muss der wahrscheinlich gelöscht werden.

    Aufräumarbeiten wollte ich erst machen, wenn es läuft, falls es zum rennen gebracht werden kann ;)

    Ich denke, ich werde mal zum Cross-Check das Original-vtuner ausprobieren. Irgendwas muss ja falsch sein.

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Ich versuche noch zu verstehen, warum der Build fehlschlägt. Ich musste aufgrund von Hardwareproblemen u.a. auch einen komplett neuen Build machen und der ging durch.


    Die Fehlermeldung sieht so aus, als ob der VDR Patch nicht angewandt wurde. Darin befinden sich genau die Prozeduren, die als nicht-existent bemängelt werden.


    Ist das ein ganz neuer Build oder ein Update?


    Kannst du mal versuchen, erstmal nur den VDR neu zu bauen und dann das Komplettbuild anzustossen?

    ./build.sh -config CoreELEC-20-ng -package _vdr


    Vielleicht auch mal schauen, ob osd.h auch die neuen Prozeduren hat:

    Code
    grep "DrawScaledImage"  CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/build/_vdr-2.6.4/osd.h

    Es sollten 6 Fundstellen sein:

    Code
      virtual void DrawScaledImage(const cPoint &Point, const cImage &Image, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false) = 0;
  virtual void DrawScaledImage(const cPoint &Point, int ImageHandle, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false) = 0;
  virtual void DrawScaledImage(const cPoint &Point, const cImage &Image, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false);
  virtual void DrawScaledImage(const cPoint &Point, int ImageHandle, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false);
  virtual void DrawScaledImage(const cPoint &Point, const cImage &Image, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false);
  virtual void DrawScaledImage(const cPoint &Point, int ImageHandle, double FactorX = 1.0f, double FactorY = 1.0f, bool AntiAlias = false);
r

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Faszinierend. Es gab einen Deadlock über alle 3 Komponenten, der nur durch einen Timeout aufgelöst wurde.

    Das Plugin und der Transcoder wurden aktualisiert und jetzt schwuppt das. Den fehlenden Browser habe ich seitdem nicht mehr produzieren können. Ich hoffe, das Problem wurde "nebenbei" gefixed.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Mittlerweile weiß ich, wo die Bremse liegt, wenn man das Menu aufruft: Im Transcoder.

    Noch habe ich keine Idee, woran das liegt und wie das umgegangen werden kann, aber der kill von ffmpeg dauert so lange bzw. funktioniert nicht.

    Und wieder ein Mysterium....


    Achja. Das der Browser nicht mehr erreichbar ist, habe ich auch. Ich hoffe dafür eine Lösung zu finden.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Zitat von jojo61

    Ich habe das nun mal mit dem softhdodroid ausprobiert und hatte noch ein paar segfaults. Deswegen habe ich den patch für das softhdodroid noch etwas überarbeitet und nun scheint es zu laufen. Wirklich flott nun.

    Ich habe mal die Patches verglichen um herauszufinden, ob es evt. Auswirkungen für die anderen Ausgabe-Plugins gibt. Mal abgesehen davon, daß statt den Default-Parametern für die Skalierungsfaktoren nun explizite Werte gesetzt werden finde ich dieses interessant:

    Code
    +    if (x + width * scaleX > VideoWindowWidth) {
+    printf("Scaling over the Width edge %f\n",x + width * scaleX);
+         scaleX = 1.0;
+    }
+    if (y + height * scaleY > VideoWindowHeight) {
+    printf("Scaling over the Height edge %f\n",x + height * scaleY);
+         scaleY = 1.0;
+    }

    Ist das tatsächlich passiert? Das durch die Skalierung eine zu hohe Breite/Höhe entstanden ist? Zumindest im web-Plugin wird der Skalierungsfaktor genau an den Videogrenzen ausgerichtet. Ich kann mir nur vorstellen, daß durch Rundungen ein zu hoher Wert entsteht. Aber wird dann nicht einfach ein Crop gemacht?

    Zitat von jojo61

    Allerdings gibt es noch andere Probleme:

    - wenn ich ein laufendes Video mit Menü abbreche dann dauert es sehr lange bis das Menü kommt und TV wieder erscheint. Ich vermute das das web plugin im PlayPacket hängt und versucht noch restliche Daten los zu werden (bis zum timeout).

    Nicht ganz. Der Browser wartet so lange, weil ich erkennen muss ob in der Seite ein StopVideo/StartVideo unmittelbar (oder eben in einer bestimmten Zeit) hintereinander kommen. Dann darf ich beides nicht ausführen, sondern muss ein Reset machen. Ansonsten gibt es eine Race-Condition im Plugin mit Konstruktor/Destructor/Attach/Detach.


    Das ist auch noch auf meiner TODO-Liste, daß ich im Plugin erkennen muss, daß das Menu aufgerufen wird. Der Key selbst wird nicht an das Plugin durchgereicht, also muss ich etwas anderes finden.


    Zitat von jojo61

    PS: man sollte noch Erwähnen das man alle plugins mit OSD neu compilieren muss wenn man den VDR patched. (z.b. Teletext)

    Ja stimmt. Ich bin da wohl mittlerweile von VDR*ELEC verwöhnt, weil der Build die Abhängigkeiten automatisch erkennt und dann auch alles passende dazu neu baut.


    Also:
    Nach Anwenden des VDR Patches müssen alle Plugins mit einem OSD neu gebaut werden.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Zitat von rell

    Fehlt da evtl. der Patch fürs plugin selbst?

    Mist.


    rell ich habe deine Patches für die Output-Devices und den VDR mit in das Repository zu dem web-Plugin gepackt um das Ganze noch "offizieller" zu machen und nicht nur in VDR*ELEC zu verstecken.


    Allerdings habe ich vergessen, das Plugin selbst zu patchen.

    Da gibt es jetzt einen Mismatch. Das muss ich korrigieren.


    Edit: Dein Patch für das Plugin ist nun offiziel im Git eingecheckt. Jetzt passt alles wieder. Nur muss VDR*ELEC noch angepasst werden, bei einem Update.

  • web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    jojo61 Das war wieder ein Schubs in die richtige Richtung.


    Ich habe den Video-Wechsel überarbeitet: Nach dem Super-UHD-Werbevideo startet das eigentlich gewünschte Video auf S1P7. Die Auflösungen in den Mediatheken der Privaten sind eher bescheiden und grenzwertig.


    Die Pause wurde auch überarbeitet. Der Transcoder hat schon beim Resume auf Seek auf die letzte Position gemacht, aber statt im Plugin zu versuchen, möglichst viel an Alt-Daten zu retten, wird ein DeviceClear gemacht und mit den frischen TS-Paketen gearbeitet.


    Das Verhalten der langen Pause eines Videos muss ich noch untersuchen bzw. erstmal nachstellen.


    Edit:

    Ich weiß gar nicht, ob du da was machen kannst, aber bei meinen Tests ist mit der VDR einmal abgeschmiert mit dem folgenden Backtrace