Beiträge von Joe_D

    Bringt leider nix.. und finde ich schon wieder endgeil, es wird was geändert, beschreibt was man tun soll - man macht es wie beschrieben... und es knallt trotzdem:

    Code
    bool cEPGHandler::SetDescription(cEvent* Event, const char* Description)
    {
        //cTimer *timer;
        char *timerdescr;
        if (!check4proc(Event,&timerdescr,NULL))
        {
            if (timerdescr) free(timerdescr);
            return false;
        }

    In check4proc habe ich das dann bilderbuchmäßig geändert:



    Und dennoch:

    :(

    "keiner braucht das Plugin mehr"

    Schade schade, auf meinem Produktiv-vdr mit Version 2.2.0 läuft es noch brav vor sich hin...


    Edit: Finde zwar etliche Stellen hier im Forum mit "invalid lock sequence" aber keine wo mal genau beschrieben wird was zu tun ist :( Also rufe GetChannelsRead/GetTimersRead nur hier und da oder so und so auf wie es früher mal üblich war bei API-Changes...

    Und hier auch:

    Äh, ich hab mal mein altehrwürdiges Plugin (ohne den PR) versucht auf 2.6.3 laufen zu lassen und bekomme "invalid lock sequence"...

    Und nun? Keine Ahnung was ich da machen soll...

    Na dann denk mal nach, woher dort die Informationen herkommen. Über ein struct im Treiber mit function pointers.

    Klingelts?

    Nein. Es sei denn Du meinst die Asbach-Uralt Funktion fe->ops.set_property. Jaja, damit wäre das gegangen in Zeiten von linux-kernel v4.8 und früher. Seitdem ist die Funktion aber rausgeflogen... Und vtuner unterstützt nur >= v4.16 ...


    "Damals" gingen tatsächlich so Sachen:

    Da war es möglich einen DTV_TUNE direkt im FE_SETPROPERTY ioctl mit -EINVAL abzuschmettern.. Ist aber seit kernel v4.9 auch mit rausgeflogen...


    Code
    fe->ops.tune

    tune wird nach dem FE_SETPROEPRTY ioctl über ein Event im Frontend-Thread aufgerufen, alles schonmal geschrieben. Liest Du überhaupt was ich schreibe?


    Also ich denke Du weisst nicht wie sowas geht oder spielst mit mir Oberlehrer vs. dummer Junge mit so knäpplichen "such die richtige Antwort".


    Wie dem auch sei, hier liegt meine Datei vtunerc_proxyfe.c - da kannste mir mal die Zeilennummer nennen oder einen Codeschnipsel zeigen wo ich mit einem einfach return -EINVAL dem vdr vor dem Tunen, also direkt im FE_SETPROPERTY ioctl rückmelden kann das der Kanal von diesem frontend nicht geliefert werden mag.... Bis dahin... Bitte keine weiteren Verwirrungsantworten. Danke!

    wirbel: Ja ok dann hast Du es nicht verstanden was ich meinte. FE_SET_PROPERTY wird im dvbcore abgehandelt. Ein dvb_adapter (wie vtuner es ist) bekommt davon nichts mit. Erst ein DTV_TUNE wird über einen Event ins frontend weitergereicht. Und dann funktioniert halt nur noch "kein Lock" innerhalb einer bestimmten Zeit zurückzugeben. Hat aber nix damit zu tun das (und genau das war meine Intenion!) z.B. auf DTV_FREQUENCY der vtuner mit EINVAL antworten könnte.


    Es geht schlicht nicht, denn DTV_FREQUENCY wird dvbcore-intern so abgehandelt:

    Code: dvb_frontend.c
        int r = 0;
    [...]
        case DTV_FREQUENCY:
            c->frequency = data;
            break;
    [...]
        return r;

    Da müsste es schon mit Zauberei zugehen das FE_SET_PROPERTY mit DTV_FREQUENCY ein EINVAL zurückgibt...

    wird es.

    setze errno auf den passenden dokumentierten Wert und gebe ungleich Null zurück.

    Ich kapiere mit diesen Wortfetzen leider gar nichts von dem was ich ziemlich ausführlich geschildert habe. Seit wann wird errno in einem Kerneltreiber gesetzt? IMHO kann das nur zurückgegeben werden (z.B. als Returnwert eines ioctls). Wo kann ich FE_SET_PROPERTY in einem Kerneltreiber bearbeiten? Bei dtv_property_process_set schonmal garnicht! Wo wird das im vdr honoriert (Sourcecodezeile?) cDvbTuner::SetFrontend liefert nur true oder false zurück, da gibt es kein "unavailable"...

    Indem du die frontend properties per FE_SET_PROPERTY setzt, aber kein DTV_TUNE sendest.

    Sehe für vtuner keine Möglichkeit mich beim DVBAPI5 FE_SET_PROPERTY einzuklinken.. Also kann ich einen Parametersatz auch nicht "ablehnen". Ist ja wie schon in meinem Beitrag #190 geschrieben nicht vorgesehen das ein Frontend zwar DVBS2 kann aber z.B. Transponder 11493 nicht ausliefern mag. Dazu müsste es sowas wie "ok", "temporary failure" und "not available" als Rückgabe zu FE_SET_PROPERTY geben. Zudem müsste das vom vdr dann auch noch honoriert werden, so wie ich das im vdr Source gelesen habe wird das Frontend auch bei einem Fehler immer wieder nach dem Kanal gefragt...

    Kannst du doch.

    Nur du bekommst 0 für Erfolg und ungleich 0 im erfolglosen Fall zurück.

    Also wenn ich mir dvb_frontend_thread im dvbcore anschaue dann wird da einfach fe->ops.tune oder dvb_frontend_swzigzag(fe) aufgerufen. Ein client-Programm wie der vdr muss dann "ewig" warten oder in einen Timeout reinlaufen... wo ist da sofort 0 oder ungleich 0?


    Im vtuner z.B. verwende ich fe->ops.tune:

    Code
    			if (fe->ops.tune)
    					fe->ops.tune(fe, re_tune, fepriv->tune_mode_flags, &fepriv->delay, &s);
    
    				if (s != fepriv->status && !(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT)) {
    					dev_dbg(fe->dvb->device, "%s: state changed, adding current state\n", __func__);
    					dvb_frontend_add_event(fe, s);
    					fepriv->status = s;
    				}

    Wie man sieht kann ich da nur einen "geänderten Status" zurückgeben. Und was soll ich da von FE_NONE aus zurückgeben um zu signalisieren das ich den Kanal nicht ausliefern mag? FE_TIMEDOUT? FE_REINIT? :/

    So, gab noch eine Ergänzung:


    Mit dem Parameter -D kann nun im satip-Programm das Frontend auf ein oder mehrere DeliverySystems festgelegt werden:

    Code
      -D    vtuner frontend delivery system, values: DVBS DVBS2 DVBT DVBT2 DVBC DVBC_B DVBC_C (defaults to all)


    Das ist nützlich wenn man unterschiedliche Quellen hat (z.B. DVBS/S2 und DVBC) dann kann man nun den jeweiligen Frontends "Ihre" DeliverySysteme zuweisen.


    Wird in dmesg protokolliert:

    Code
    [10914.269730] vtunerc: registered /dev/vtunerc0
    [10914.273918] vtunerc0: setting delsys to DVBS DVBS2


    Und erscheint auch im vdr:

    Code
    Jan  3 12:45:03 server vdr: [8553] frontend 0/0 provides DVB-S,DVB-S2 with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256,VSB8,VSB16,TURBO_FEC ("vTuner proxyFE DVB-Multi")


    Ich fände es ja toller wenn das DVBAPI eine Funktion hätte wie z.B. "CanTune" oder "IsTunable" bei der man einfach die Parameter übergibt und ein simples true/false zurückbekommt. Dann könnte ein Frontend sogar nur einzelne Kanäle oder Transponder liefern und man müsste nicht so dümmlich DeliverySystems oder die Modulation abfragen/einstellen um im Endeffekt immer noch nicht genau zu wissen ob der Kanal empfangen werden kann...

    Linux vdr 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

    Update auf 6.2.0-39 und es läuft.

    Das ist echt schräg. Bei mir läuft es unter:

    Code
    Linux server 5.15.0-odroid-arm64 #1 SMP PREEMPT Ubuntu 5.15.118-202306231801~jammy (2023-06-23) aarch64 aarch64 aarch64 GNU/Linux

    Sollte PREEMPT oder die Architektur einen Unterschied machen?

    Irgendwie wäre es einfach zu einfach

    Ich denke mal das ist so einfach (also in Zeile 265 TRUE auf FALSE setzen), damit wird nur ein optionaler Body gelesen und zurückgeliefert. Frage mich überhaupt warum das explizit unterdrückt werden muss? Es schadet nicht und hat IMHO bei reinen RTSP-Servern keine negative Auswirkung.


    Überhaupt gibt es bei keinem SAT>IP-Befehl außer DESCRIBE einen Body, dafür bei den Fehlern 400, 403 und 503 die bei allen SAT>IP-Befehlen außer DESCRIBE auftreten können..


    Das ist aber dann nur der Anfang des Problems im satip-Plugin. Dort wird z.B. der von mir erwähnte 503 mit Body "No-more: sessions" zwar ausgewertet:

    Code
     if (strstr(r, "No-More:")) {
               char *tmp = NULL;
               if (sscanf(r, "No-More:%m[^;]", &tmp) == 1) {
                  errorNoMoreM = skipspace(tmp);
                  debug3("%s No-More: %s [device %d]", __PRETTY_FUNCTION__, *errorNoMoreM, tunerM.GetId());
                  }
               FREE_POINTER(tmp);
               }

    Bei funktionierender CURL-Lib würde es sogar eine Fehlermeldung geben (anstatt dem total irreleitenden invalid status code)


    Leider leider führt das aber nicht dazu das der Tuner-Thread irgendwie damit umgeht:

    Es wird ein Disconnect gemacht und dann alle 250ms erneut drauf gehämmert. Das Log wird geflutet. Mein Satip-Receiver mag das nicht so dolle und kann dann schonmal den Dienst quittieren, was dann nur zu noch mehr Meldungen führt...


    Bei vtuner habe ich die "No-More: sessions" durch Zufall selbst erzeugt, in der alten Version des satip-Programms wurde kein Teardown gesendet, d.h. bei jedem Stop das satip-Programms verwaiste die Session. Das habe ich mittlerweile behoben.


    Aber: Zusätzlich sollte IMHO grundsätzlich immer bei jedem 503 Service unavailable mindestens 65 Sekunden gewartet werden bis erneut eine Aktion durchgeführt wird (habe ich so im satip Programm umgesetzt). Sollte es sich um eine verwaiste Session handeln wurde diese mittlerweile freigegeben und der neuerliche SETUP geht ohne Fehler durch. Ist einfach kein Tuner mehr verfügbar so wird dann im Endeffekt nur einmal pro Minute geprüft ob ein Tuner frei ist im Gegensatz zur jetzigen Lösung: 240 Mal.


    Das würde für das satip-Plugin bedeuten das jemand den Status in die Action-Funktion rausführt und entweder einfach die tsSet-Bearbeitung verzögert oder einen neunen State tsWaitForTuner oder sowas einfügt...

    Ich besitze ja einen EyeTV Netstream 4Sat SAT>IP Receiver der eigentlich ganz ordentlich läuft (SAT>IP zertifiziert) und z.B. die Möglichkeit bietet Streams zu transcodieren (nur per HLS).


    Die Kisten gibt es z.B. bei Kleinanzeigen für ca. 70€, das finde ich schon ein Schäppchen (habe für meine noch 110€ bezahlt).


    Leider ist der Auslieferungszustand sehr schweigsam über die "inneren Werte":



    Das Kistchen hat einen telnet-Zugang :angst (root/service).

    Auf der Kiste selber läuft ein arclinux (ARC700 / VIXS XCode 4A7222)


    Herz von allem ist eine ClosedSource-Applikation mit der alles erschlagen wird: Tombea
    Zudem noch ein ClosedSource-Kernelmodul xcode5drv inkl. ClosedSource Firmware..


    Die Tuner werden propietär von der Tombea-Applikation angesprochen.

    Bedeutet keine Standard DVB-Devices, sondern nur irgendwelche /dev/vixs/xcode... Treiber


    Zudem verwaltet die Tombea-Applikation sämtliche SAT>IP Verbindungen (SSDP/RTSP/RTCP/RTP/HLS) und stellt auch den Webserver zur Verfügung.


    Was ein bisschen problematisch ist, das sich die Tombea-Applikation bei zuvielen Anfragen oder speziellen Anfragen weghängen kann.

    Dabei bleibt das Kistchen ansprechbar nur die Tombea-Applikation (und damit SAT>IP und auch das Webinterface) ist tot.

    Wenn die hängengebliebene Tombea-Applikation abgeschossen wird erfolgt automatisch ein Reboot (scheint ein Hardware-Watchdog zu sein)

    Derzeit bin ich am Testen wie ich das mit wget und cron auf der Kiste überwachen kann.


    Kernelversion ist ein steinalter 2.6.30 :O ... IPv6 ist der Kiste leider ein Fremdwort.. (aber für den Preis!)


    Etwas versteckt hat Geniatech den GPL Sourcecode abgelegt:


    Index of /Netstream4X/1.1.0.402r1


    Habe mir mal die Mühe gemacht eine Buildumgebung zu basteln (ebenfalls mit einem steinalten Ubuntu 12.04.05) und folgende Veränderungen gemacht:


    telnet entsorgt

    dropbear ssh hinzugefügt

    sftp-server hinzugefügt

    Weboberfläche "erweitert" (um ausgeblendete Einträge)



    Bislang ist es mir nicht gelungen die Firmware-Version zu ändern, wird scheinbar irgendwo intern ausgelesen.


    Die Firmware ist 16MB groß, wer daran Interesse hat bitte melden (muss noch schauen wo ich das ablege)

    Also ich hab' was gepushed ... sieht nun so aus:

    Code
    220 server SVDRP VideoDiskRecorder 2.6.4; Sat Dec 30 12:29:31 2023; UTF-8
    900-CARD:0
    900-STRG:100
    900-QUAL:100
    900-TYPE:DVB-S
    900-NAME:vTuner proxyFE DVB-Multi
    900-STAT:001F
    900-SGNL:-18.54
    900 CHAN:RTL Television;RTL Deutschland:12188:HC34M2S0:S19.2E:27500:163=2:104=deu@3;106=deu@106:105;110=deu:0:12003:1:1089:0
    221 server closing connection

    Wenn ich einen Platzhalter für den cnr-Decibelwert anlege und den Relativwert auf stat[1] lege dann wird Quality plötzlich 0 :huh:

    Oha, das femon-Plugin ist ja ganz unschuldig :saint:


    Der gute vdr erwartet tatsächlich für Strength und CNR an Stelle "0" (stat[0]) einen Decibel-Wert:

    Code
          switch (Props[i].u.st.stat[0].scale) {
              case FE_SCALE_DECIBEL:  *Strength = double(Props[i].u.st.stat[0].svalue) / 1000;
                                      Valid |= DTV_STAT_VALID_STRENGTH;
                                      break;
              default: ;
              }
            }

    Obwohl ich in der DVB-API keinen Hinweis gefunden habe das das so sein muss....


    Fehlt mir noch die Umrechung von 0-15 auf Dezibel-Werte...