GIT-Archiv für VDR auf http://git.tvdr.de

  • Bitte ausgiebig testen.

    Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.5-patches habe ich gestern Abend Pakete bauen lassen (die Pakete für autostart, pvrinput und externalplayer lasse ich gleich noch gegen den neuen VDR bauen).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • plugin.c:235 -> falls destroy == nullptr, ist das kein Fehler und cDll::~cDll() abgefangen.


    destroy = (destroy_t *)dlsym(handle, "VDRPluginDestroyer");

    --error = dlerror();

  • wirbel stimmt.


  • Alternativ:

  • ch würde gerne mein Veto einlegen. Seit diesem Commit


    http://git.tvdr.de/?p=vdr.git;…1139b7b842b6de56bf88d8b1c

    kannst du dazu was sagen?

    Etwas schwierig zu sagen. ich habe derzeit auch keinen 32-Bit VDR um es zu vergleichen.

    Es könnte sich um einen Bufferüberlauf handeln. Was mir dazu - aber nur sehr theoretisch - einfällt:

    Seit dem Patch gibt es inExtendedEventDescriptors::getTexteinen neuen Zwischenbuffer "tmpbuf".

    Kann es vorkommen, dass das DescriptorGroup array[] nur NULL-Pointer enthält? Falls ja, und 'tmpbuf' ist nicht zufälligerweise 0-Terminiert, wird das nachfolgende strlen(tmpbuf) unerwartete Ergebnisse liefern (hätte aber nichts mit 32/64-bit zu tun)


    Als ersten Versuch würde ich hier einmal ansetzten. Ein Patch dazu im Anhang.

    LG Helmut

  • Etwas schwierig zu sagen. ich habe derzeit auch keinen 32-Bit VDR um es zu vergleichen.

    Es könnte sich um einen Bufferüberlauf handeln. Was mir dazu - aber nur sehr theoretisch - einfällt:

    Seit dem Patch gibt es inExtendedEventDescriptors::getTexteinen neuen Zwischenbuffer "tmpbuf".


    Als ersten Versuch würde ich hier einmal ansetzten. Ein Patch dazu im Anhang.

    Danke für die schnelle Reaktion, leider kein Erfolg.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Eine vorhanden 64-Bit Installation läuft ohne den Patch problemlos. Kann sein, dass hier ein 32/64Bit Problem vorliegt? Hat jemand anderes die aktuelle git-Version erfolgreich auf einem Raspi laufen?

    Habe die GIT Version auf einem RPi2 (V1.1) laufen. Schien mir soweit problemlos.


    Das ist aber ein VDR-Streamdev Slave:

    EPG, der epg2vdr/scraper2vdr-Cache und Channels.conf werden beim Start per rsync vom Hauptsystem gezogen (die 5k Aufnahmen brauchen ja schon 15 Min...)


    Edit:

    Habe allerdings Kernel 5.4.51 (meine ich) laufen, da der Aktuelle mit rpihddevice nicht vernünftig läuft (kein Bild nach umschalten - EPG ist aber da und ok)


    Stefan

  • Habe die GIT Version auf einem RPi2 (V1.1) laufen. Schien mir soweit problemlos.

    Super, danke für die Info. Welche Distri verwendest du?


    Jetzt wirds richtig ätzend, weil das Problem anscheinend Distri abhängig ist. Das erklärt auch warum es bisher keine Beschwerden gab. In diesem Sonnensystem bin ich wohl der einzige der seine VDR-Distri selbst baut.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org



  • Allerdings mit eigenen VDR-Paketen und SysV Init.
    Ursprünglich per unattended-net-installer installiert (o.s.ä.).

    channels.conf und epg.data sind ganz ...


    Stefan

  • Hi,


    in libsi/descriptor.c, Zeile 104:

    Code
    1. tmpsize -= len;

    Könnte = 0 werden. getText schreibt dann

    Code
    1. buffer[size-1] = 0;


    Also entweder in getText überprüfen, ob size > 0. Oder vor dem Aufruf von getText prüfen.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Auch bei mehrmaligen Betrachtung des EPG Codes fällt mir nichts Verdächtiges auf.

    Um unerwartete Ergebnisse zu erkennen, habe ich einen Patch der in GetText() die Zwischenwerte von "len", "Index" und ""size" bzw. "tmpsize" ausgibt. Das sieht dann bei mir im syslog so aus:

    MarkusE : in der Zeile "ExtEvent Done" sieht man, das der Buffer nie voll ausgenutzt wird, die verbleibende "size" ist sogar größer als die tatsächlich im Descriptor vorhandenen Daten. Der "Item"-Loop war bei meinem Test immer ohne Information.

    glotzipapa : Falls du es testest, vielleicht erkennst du unpassende Werte (nicht zu lange laufen lassen, es wird viel ins syslog geschrieben).

    LG Helmut

  • Vielleicht eher etwas für 2.5, eine harmlose Warnung von gcc:


    vdr/dvbspu.c: In Elementfunktion »bool cDvbSpuBitmap::getMinSize(const sDvbSpuPalDescr*, sDvbSpuRect&) const«:

    vdr/dvbspu.c:148:50: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

    size.x1, size.y1, size.x2, size.y2);


    vdr/dvbspu.c:146+, anstelle von


    if (ret)

    DEBUG(...);


    if (ret) {

    DEBUG(...);

    }

  • weil der leere Befehl nach einem if oder else kommt, warnt der compiler.


    Man könnte auch einfach das DEBUG macro falls unbenutzt zu {} definieren.


    PS: dito


    vdr/pat.c: In Elementfunktion »bool cPatFilter::PmtVersionChanged(int, int, int, bool)«:

    vdr/pat.c:398:110: Warnung: geschweifte Klammern um leeren Körper in einer »else«-Anweisung empfohlen [-Wempty-body]

    DBGLOG("PMT %d %2d %5d/%d %2d -> %2d", Transponder(), i, PmtPid, Sid, se->Version(), Version);

    ^

    vdr/pat.c: In Elementfunktion »virtual void cPatFilter::Process(u_short, u_char, const u_char*, int)«:

    vdr/pat.c:431:96: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

    DBGLOG(" PAT %d: %d sections", Transponder(), pat.getLastSectionNumber() + 1);

    ^

    vdr/pat.c:462:68: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

    DBGLOG(" PAT %d: shared PMT PIDs", Transponder());

    ^

    vdr/pat.c:732:55: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

    DBGLOG("PMT timeout Pid %d", activePmt->Pid());

  • Nichts neues, nur -Wall -Wextra in meinen Flags.


    void() funktioniert.

    do {} while(0) würde auch gehn, nicht getestet.

    Danke und Gruß