Posts by MarkusE

    Hi,


    You can omit unneeded commands, and repeat needed commands. You can also increase waiting times.

    For my system (external multiswitch),

    Quote

    S13E 11700 V 9750 t v [E0 10 38 F4]

    S13E 99999 V 10600 t v [E0 10 38 F5]

    S13E 11700 H 9750 t V [E0 10 38 F6]

    S13E 99999 H 10600 t V [E0 10 38 F7]

    works fine. But this does not mean that it also works for you ...

    I always have t (tone off) because my multiswitch does not need the tone.


    ~ Markus

    v1.2.3 ist im git verfügbar.

    Damit wird ein Index in der Datenbank korrigiert -> Performanceverbesserung bei der Anzeige von Detaildaten von Spielfilmen.


    Bei Client - Server Systemen:

    1.) Server updaten und restarten. Danach auf Update von /var/cache/vdr/plugins/tvscraper/tvscraper2.db warten oder erzwingen (durch Start einer Aufnahme). Der fertige Update wird im Syslog mit "tvscraper: access to /var/cache/vdr/plugins/tvscraper/tvscraper2.db finished" protokolliert.

    2.) Client updaten und restarten.


    ~ Markus

    Super!


    Könntest Du noch eine Performance-Optimierung machen? Zur Zeit wird "GetMovie" bei der Navigation zum Detailbild 2 mal aufgerufen. Könntest Du das ändern, so dass "GetMovie" nur noch 1 mal gerufen wird?



    ~Markus

    Es sieht so aus, als würde zwischen 00:45 und 00:48 ein Zustand vorliegen, in dem

    • Der Prozess, der entscheidet, ob eine VPS Aufnahme gestartet werden muss, zum Ergebniss "ja" kommt
    • Der Prozess, der entscheidet, ob eine VPS Aufnahme beendet werden muss, auch zum Ergebniss "ja" kommt

    Dadurch wird die Aufnahme gestartet, beendet, wieder gestartet, ...


    Die beiden oben genannten Prozesse sollten identische Kriterien verwenden, um das zu vermeiden


    ~ Markus

    Hallo kls ,


    Kannst Du Dir das bitte mal ansehen? Also den syslog, den ich am 2. Juli 2023 gepostet habe?


    Es fehlt das VPS Startevent, was dann zu wiederholtem Aufnahme -start und -stop führt.

    kfb77 hat das ja schon analysiert.


    ~ Markus

    Falls "GetEventType"

    Code
    call.type == tSeries

    zurückgibt, dann ist es eine Serie (definitiv) und

    Code
    pScraper->Service("GetSeries", &series)

    liefert Detailinformationen. Eine weitere Prüfung auf seriesId ist nicht notwendig und sollte eigentlich auch nicht erfolgen. Weche seriesId s verwendet werden, ist ein Implementierungsdetail von tvscraper, auf das sich Verwender nicht verlassen können.


    Analog bei

    Code
    call.type == tMovie

    Hi,


    es hängt an

    Code
    if (seriesId > 0)


    seriesId kann auch kleiner 0 sein. Sauberer wäre

    Code
    if (call.type == tSeries) {
    ...
    }
    else if (call.type == tMovie) {
    ...
    }

    so ist das auch in skindesigner implementiert, dashab habe ich den Fehler auch nicht bemerkt.

    Könntet ihr das in SkinNopacity und skinflatplus ändern?

    Notfalls auch "seriesId != 0" testen, anstelle den call.type zu prüfen.


    ~ Markus

    VDR kann manchmal auf eine Datei im Netzwerk zugreifen, und manchmal kann VDR auf diese Datei nicht zugreifen.

    Also ich würde hier nicht nach ~, Umlauten, Verlinkungen, Berechtigungen, ... suchen. Da wäre der Fehler bei einer bestimmten Datei doch reproduzierbar.


    Ich würde prüfen:

    • Stabilität des Netzwerks
    • Timeouts wenn Festplatten schlafen und geweckt werden müssen
    • Im Code von VDR prüfen, mit welchem Befehl VDR versucht auf die Datei zuzugreifen. Den exakten Fehlercode im syslog ausgeben, und nach möglichen Ursachen für diesen Fehlercode suchen

    ~ Markus

    Hi,


    Bin jetzt erst zum Testen gekommen, zu viele Baustellen :( .

    Es ist bisher nicht mehr abgestürzt :)

    Einträge im Syslog:

    ~ Markus