Beiträge von wirbel

    Hmm, ich denke wir werden definitiv keine Freunde mehr. @ Joe_D

    Du sägst mir den letzten Nerv ab. Lass mich mich bitte in Ruhe..

    Mach du deins, ich mach meins. Ich geh dir aus dem Weg.


    Falls ich irgendwann mal den Fehler machen sollte, dir aus VERSEHEN zu antworten, bitte ignorier mich.






    Zum Thema zurück..........


    class cDeviceHook : public cListObject {

    public:

    cDeviceHook(void);

    ///< Creates a new device hook object.

    ///< Do not delete this object - it will be automatically deleted when the

    ///< program ends.

    virtual bool DeviceProvidesTransponder(const cDevice *Device, const cChannel *Channel) const;

    ///< Returns true if the given Device can provide the given Channel's transponder.

    virtual bool DeviceProvidesEIT(const cDevice *Device) const;

    ///< Returns true if the given Device can provide EIT data.

    };







    Du kannst jedem device erlauben, EPG zu empfangen oder eben auch nicht.




    Probier es oder halt bitte die Klappe.

    Hmm. Aus irgendeinem Grund gibt es Probleme mit Speicher für diesen thread: sowas wie new(), malloc(), delete(), free(), double free,...


    - die logischste Erklärung sind mehrere Prozesse(threads) die parallel lesend (oder noch schlimmer schreibend..) parallel auf Variablen zugreifen.

    - alternativ auch loops, die 'out-of-bounds' sind und danach Speicherbereiche überschreiben



    malloc() und free() stolpern dann erst später über die pösen Übeltäter, nur dann ist ja alles viel zu spät.


    Irgendwas mit mehreren threads, wie seahawk in #22 bereits vermutet hat.

    Na ja, wer denn dringend Bedarf hat, kann die passenden Schnittstellen in VDR verwenden.

    Code
    DeviceProvidesEIT


    Einfach das Plugin erstellen, was dem persönlichen Gusto entspricht und fertig.

    Danke. :)


    Das sagt dein log übersetzt.. Vielleicht liest ja jemand den entscheidenden Tip heraus, mir fällt nichts schlimmes auf.

    Ich vermute mal da fehlt dir shell quoting, sonst bekommt nicht das Plugin die nachfolgenden Args, sondern vdr selbst.


    Code
    gdb --args /usr/local/bin/vdr --cachedir=/tmp -c /etc/vdr -E /tmp -l 3 -L /usr/local/lib/vdr --localedir /usr/local/share/locale -P "vnsiserver -t 14 -d" -P "satip -d 8 -r 20971520 -s 192.168.20.245;192.168.20.183" -P dvbapi -P live -u vdr -v /pool/vdr-video -w 60

    wäre da ein &p nicht besser?


    'for (auto& p : s_Pool)' arbeitet mit dem object selbst und erspart in jedem Fall eine Kopie des members von s_Pool.

    Ich denke das wäre hier angebrachter, aber dann könnte man eben im loop auch p selbst ändern.


    Mich wundert auch die Zeile 467

    auto recv = p.lock();


    p ist vom Typ std::weak_ptr, dessen Beschreibung sagt


    std::weak_ptr is a smart pointer that holds a non-owning ("weak") reference to an object that is managed by std::shared_ptr. It must be converted to std::shared_ptr in order to access the referenced object.


    std::weak_ptr models temporary ownership: when an object needs to be accessed only if it exists, and it may be deleted at any time by someone else, std::weak_ptr is used to track the object, and it is converted to std::shared_ptr to assume temporary ownership. If the original std::shared_ptr is destroyed at this time, the object's lifetime is extended until the temporary std::shared_ptr is destroyed as well.

    Die Zeile macht wohl eine implizite Konversation zu einem std::shared_pointer innerhalb des loops.

    Ich mach das meist in gdb. Sowas wie


    Code
    ulimit -c unlimited
    gdb --args <deine normale vdr befehlszeile hier mit allen Plugins>


    Danach mit der Taste r den Prozess starten und auf den Crash warten.


    Die letzten Zeilen vor dem crash bekommst du dann im gdb Fenster mit


    bt full

    Scheint was schwierigeres zu sein. Vielleicht hilft es, stückweise Infos zu sammeln. Mit gcc 11.1 gibt es diese Warnungen nicht.



    Der Compiler sagt, soweit ich lesen kann ..


    - es gibt in videoinput.c eine Klasse cDummyReceiver

    - diese Klasse hat eine member Funktion bool BeenDetached() in videoinput.c Zeile 428, welches den private member std::atomic<bool> m_BeenDetached zurückgibt. Also ist diese Funktion wohl shared zwischen mehreren threads.

    Der compiler inlined das wegen Optimisation, so dass der private member std::atomic<bool> m_BeenDetached direkt zurück gegeben wird.

    - mit diesem member m_BeenDetached gibt es wohl ein Problem in cDummyReceiver::Create(cDevice *), damit wäre man dann wohl bei Zeile 468

    Code
        if (!recv->BeenDetached() && recv->Device() == device)


    Zwei Fragen wären interessant, der loop geht über alle cDummyReceiver in s_Pool:


    Code
    for (auto p : s_Pool)


    aber evtl wäre auch möglich um Kopien der member von s_Pool zu vermeiden


    Code
    for (auto& p : s_Pool)


    Ich habs nicht ausprobiert, ich nutze vnsi nicht.


    Irgendwie endet der lesbare code in Zeile 467

    Code
    auto recv = p.lock();

    Ich verstehe nicht, woher der member lock() kommt.

    Einen solchen Eintrag braucht es eigentlich auch nicht.

    Das wäre für mich ja unendlich viel Arbeit, jeden einzelnen geänderten oder neuen Transponder 'einzutragen', das ist ein nur Programm, kein Lexikon. :D


    So sieht die Liste aus, die das Plugin intern aufbaut, zumindest bei meinem scan von jetzt.

    Kann immer sein, dass mal einer oder zwei fehlen, je nachdem wo man gerade wenig Glück hatte, zumindest bei einer schwachen Antenne wie meiner.


    Das ist der Eintrag, der 'fehlt':

    Code
    {6 , 11523, 0, 22000, 2 , 0, 9 },              // NID = 1, TID = 1021

    DVB-S2, 11523MHz H 8PSK 22000 2/3 0.35


    Der Sender wird dann als 'WDR HD Essen' gefunden, nicht 'WDR Essen HD'.

    Just some hints..


    Wenn Dämpfung nicht hilft, dann verstärkst du entweder ein Signal, was zu schwach ist, oder aber schon am Eingang eines Verstärkers verrauscht ist, oder der Verstärker selbst ist nicht geeignet (Verstärker Rauschzahl zu hoch). Gute Verstärker sollten eine Rauschzahl kleiner 1.5dB aufweisen, besser unter 1dB.


    Auch möglich: (Eingangs-)Pegel oberhalb des 1dB Kompression Points des Verstärkers - die Eingangsstufe arbeitet im nichtlinearen Bereich des Amps als Frequenzverdoppler und -mischer. Dann gibt es nur noch Probleme.


    Irgendwo in der Kette passt etwas nicht.