Unvollständige Aufnahmen mit VDR 2.3

    Hallo zusammen,


    ich habe hier ein total ätzendes Problem, das wohl nur im Zusammenspiel von VDR-2.3.8, epg2vdr und epgsearch auftritt: ich habe regelmässig unvollständige Aufnahmen. Das Problem ist zum ersten mal vor einigen Wochen nach der Migration von VDR 2.2 auf VDR 2.3 in einen Docker-Container aufgetreten.

    Testweise hatte ich danach epg2vdr deaktiviert, was scheinbar das Problem behoben hat.


    In den Release-Notes zu 2.3.9 habe ich folgendes gefunden:

    - Fixed handling VPS events outside the LingerLimit, which could cause recordings to stop prematurely (thanks to Johann Friedrichs).


    Ein Update auf 2.3.9 hat aber nichts gebracht.


    Wenn man das Log anschaut fällt auf, das einige EPG-Change-Events für die laufende Aufnahme gefeuert werden und dann versucht wird eine zusätzliche Aufnahme zu starten. Der VDR merkt dann aber, dass die Aufnahme schon läuft und beendet dann wohl alle Timer.


    EIT-SCan ist bei mir abgeschaltet, das EPG-Update wird alle 4 h via cronjob getriggert.


    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

    Einmal editiert, zuletzt von glotzipapa ()

    Mit dem Problem kämpfe ich auch schon seit Version 2.2., habe aber leider noch keinen Workaround gefunden. Es ist wirklich mehr als ätzend, wenn die Frau mal wieder ihren Lieblingsfilm zur Aufnahme markiert hat und dann das Ende fehlt. Falls du irgendwas finden kannst, würde ich mich sehr freuen.:thumbup:

    Es scheinen 2 Timer unterwegs zu sein 0235-0334 und 0238-0332, die dem gleichen event zugeordnet werden. Möglicherweise ist der eine aus epg2vdr und der andere aus dem Sender-EPG erzeugt.

    vdr-2.6.7

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    hre1: das kann ich so nicht bestätigen, VDR-2.2 lief rock-stable. Ein paar Infos zu deiner Konfig und Logs wären auch hilfreich.

    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

    Zitat von TomJoad

    Es scheinen 2 Timer unterwegs zu sein 0235-0334 und 0238-0332, die dem gleichen event zugeordnet werden. Möglicherweise ist der eine aus epg2vdr und der andere aus dem Sender-EPG erzeugt.

    Oder eine Aktualisierung im EPG?


    Irgendwie erinnert mich das etwas an die Arte-EPG-Geschichte.

    Eine Änderung / Unstimmigkeit im EPG führt dazu, dass EPGSearch den Timer löscht, weil es annimmt, er sei korrekt aufgezeichnet worden.

    Gruss
    SHF


    Wenn EPGSearch die Timer löscht kann man das aber doch im Log sehen.


    EIT-SCan ist übrigens bei mir abgeschaltet, das EPG-Update wird alle 4 h via cronjob getriggert.

    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

    Zitat von glotzipapa

    EIT-SCan ist übrigens bei mir abgeschaltet, das EPG-Update wird alle 4 h via cronjob getriggert.

    Macht das einen Unterschied? Ist doch der gleiche Code, der dann ausgeführt wird, nur nicht so oft.


    Lars.

    Zitat von glotzipapa

    Wenn EPGSearch die Timer löscht kann man das aber doch im Log sehen.

    Von EPGSearch direkt sehe ich merkwürdiger Weise überhaupt nichts.

    Nur die "Timer 0" Meldungen deuten darauf hin, dass im Hintergrund ein SuchtimerUpdate läuft.


    Und irgendwer hat per svdrp am Timer rum gefummelt.

    Wenn nicht EPGSearch, wer dann?

    Code
    Mar 21 02:42:06 server fe7cae6cfa19[11402]: vdr: [32] SVDRP server < 127.0.0.1:28024 connection closed
Mar 21 02:42:06 server fe7cae6cfa19[11402]: vdr: [32] SVDRP server < 127.0.0.1:28024 server destroyed                
Mar 21 02:42:06 server fe7cae6cfa19[11402]: vdr: [23] timer 0 (16 0323-0415 'The Flash') set to event Mi. 21.03.2018 03:25-04:05 'The Flash'

    Gruss
    SHF


    epg2vdr "fummelt" doch genauso an den Timern rum. Bei epgsearch kannst du das logging mit -l "logdatei" und -v3 einschalten, dann solltest du was zeitlich passendes finden, wenn epgsearch was macht.

    vdr-2.6.7

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden