Beiträge von Saman

    Here we go again, but this time epg2vdr and his timer service is involved, too :(

    I doesn't see this kind of errors on my main vdr, only on the raspberries ...


    And some minutes later I got this:

    Sad but true, skindesigner isn't usable with my raspberry anymore.

    Moin,

    Dass EPGsearch den Timer auch während der Aufzeichnung aktualisiert, ist beabsichtigt. Bei aufzeichnenden Timern wird, wie in diesem Fall, aber nur die Endzeit geändert (23:10->23:15).


    Auf die Reaktion vom VDR kann ich mir momentan keinen Reim machen, eigentlich sollte das so nicht passieren.

    ...

    Das der geänderte Timer jeweils eine Woche später startet hast du gesehen?

    Für den PowerBtn via ACPI solltest du:

    - in /etc/systemd/logind.conf HandlePowerKey=ignore setzen.

    - schauen, das /etc/acpi/events/powerbtn existiert

    Code
    1. event=button[ /]power
    2. action=/etc/acpi/powerbtn.sh

    - ein /etc/acpi/powerbtn.sh etwa so erstellen

    - ein vdr-acpiwakeup.service anlegen und aktivieren

    - das passende Skript dazu erstellen

    - einen shutdown hook erstellen (/usr/share/vdr/shutdown-hooks/S95.acpiwakeup)

    - die passende Konfig dazu anlegen

    - hoffen das ich jetzt nichts vergessen habe und min. 5 Euro an eine gemeinnützige Organisation deiner Wahl spenden ;)


    Anmerkung: Manche Intel Systeme mögen es gar nicht, wenn im laufenden Betrieb der RTC beschrieben wird, darum besser per Service und kurz vor dem Shutdown.


    MfG

    Hallo Klaus,

    ich kann bestätigen, das die CPU-Last bei geöffneter Fortschrittsanzeige deutlich ansteigt und das der Patch das abmildert.


    Ohne Patch: 14-16% -> 26-28%

    Mit Patch 14-16% -> 18-20%


    (Das die Last bei mir generell höher als normal ist, liegt an meinem Setup mit EPGd, vaapidevice, vnsi, streamdev-server etc).


    MfG

    Moin,

    auffällig ist, das du da zwei Timer (0+2) am laufen hast und einer (0) VPS benutzt.

    Timer 2 wird zugunsten von Timer 0 deaktiviert.

    Dann scheint epgsearch nicht mehr zu wissen, welchen VPS Termin (13.4., 20.4 oder 27.4.) es nehmen soll.

    Entweder das ZDF hat da Mist gesendet oder das ist ein Bug im epgsearch.

    Ich hatte mit SkinFlatPlus auch den einen oder anderen Deadlock. Das Problem war da das gleiche, dass die aktiven Timer irgendwo in SetChannel abgerufen wurden. Ich habe das Timer-Holen dann einfach in einem seperaten Thread ausgelagert.


    Für Skindesigner würde das dann so ausssehen (Achtung, das ist ein völlig ungetesteter Patch, der nur zeigt, wie ich das ungefair bei SkinFlatPlus gemacht habe)


    locking-fix.diff


    Da die Holzhammer Variante bei mir gut läuft, habe ich deine Lösung jetzt nicht mehr getestet. Trotzdem danke für den konstruktiven Beitrag!

    ...

    Das Feature des Setup-Plugins im OSD eine channels.conf aus einem definierten Ordner zu wählen wäre echt toll, da das Setup-Plugin ja endgülzig tot ist leider!

    ...

    Du kannst auch das channellists Plugin dafür nehmen.



    VNSI macht noch ein paar Sachen für die es keine Alternative gibt. Zum Beispiel das Übertragen des VDR OSD an die Clients um Einstellungen ändern zu können.


    Wobei genau das mit dem OSD und vdr-2.3.9 nicht mehr funktioniert:


    Code
    1. Apr 11 08:49:03 vdr vdr: [6792] loading /var/lib/vdr/plugins/vnsiserver/allowed_hosts.conf
    2. Apr 11 08:49:03 vdr vdr: [6792] VNSI: Client with ID 40 connected: 127.0.0.1:43678
    3. Apr 11 08:49:03 vdr vdr: [6975] VNSI Client 40->127.0.0.1:43678 thread started (pid=6758, tid=6975, prio=high)
    4. Apr 11 08:49:03 vdr vdr: [6975] VNSI: Welcome client 'XBMC osd client' with protocol version '12'
    5. Apr 11 08:49:03 vdr vdr: [6975] VNSI: new osd provider
    6. Apr 11 08:49:03 vdr vdr: [6758] ERROR: cOsd::SetAreas returned 7 (wrong area size)

    So, ich glaube, ich hab es jetzt und das von oben ist zum Teil Blödsinn :)

    Es fehlte einfach das  == 0 Mit dieser Änderung kann ich jetzt alle Verzeichnisse sortieren.

    Moin, ich habe mir mal ein paar Debug Ausgaben in menu.c eingebaut.


    Das Problem liegt wohl in cMenuRecordings::DirectoryName()

    Code
    1. if (cVideoDirectory::HideFirstRecordingLevel()) {
    2. LOCK_RECORDINGS_READ;
    3. cRecordings::cFolderInfos::cFolderInfo* info = Recordings->GetFolderInfo(base);
    4. if (info) {
    5. if (info->FirstFolderNames.Size() > 0)
    6. d = AddDirectory(d, info->FirstFolderNames.At(0));
    7. delete info;
    8. }
    9. }

    Beim öffnen des Aufnahmen-Menüs gibt die Funktion '/srv/vdr/video' zurück.

    Öffnet man dann ein Verzeichnis, das in 'local' liegt, kommt zB '/srv/vdr/video/local//TEST'.

    Öffnet man stattdessen ein externes Verzeichnis, kommt zB '/srv/vdr/video/local//Spielfilme'.


    Merkwürdig an dieser Stelle finde ich, das 'FirstFolderNames' nur 'local/' enthält.

    Sollte das nicht auch die anderen Verzeichnisse aus '/srv/vdr/video' beinhalten?

    Dann könnte in einem Loop geprüft werden, ob/bis das Verzeichnis existiert...

    Ich denke, das wäre die allgemein gültigste Variante.


    Wer die Aufnahmen ausschließlich auf einem Server liegen hat, kann es auch hart kodieren:

    Code
    1. if (cVideoDirectory::HideFirstRecordingLevel()) {
    2. d = AddDirectory(d, "vdrserver");
    3. }

    This is fixing the problem for me:

    Ten month later but the problem is still present:

    I only get this with my clients.

    Die Ursache für das Problem konnte ich ausmachen:

    Der VDR sucht im 'local' Verzeichnis nach der '.sort' Datei, findet sie aber nicht und kann auch keine anlegen, da das zu sortierende Verzeichnis dort nicht existiert.


    Als Test oder workaround könnt ihr einfach ein leeres Verzeichnis (mit dem selben Namen wie das zu sortierende) im 'local' Verzeichnis erstellen.

    Darin legt der VDR dann beim drücken auf '0' eine eigene '.sort' Datei ab. (Bedenkt aber, das leere Verzeichnisse beim Aufräumen entfernt werden!)


    Jetzt stellt sich die Frage, ob alle Clients die selbe Sortierung nutzen wollen/sollen oder nicht.

    Je nachdem, wäre das dann ein Bug oder ein Feature ;)

    ...

    Einfach mal http ://vdr:8002/recordings/ im Browser deiner Wahl und weg ist der VDR.

    Mit Dateiendung .html .xml oder .json funktioniert es aber wie es soll.

    Anbei ein Patch, der speziell diesen Fehler beseitigt (also zusätzlich zu dem restfulapi-fix.diff anwenden).

    Danke für die Rückmeldung.

    Habe es bei mir über den Tag auch so laufen lassen.

    Kein Absturz mehr und das Sortieren funktioniert auch noch.

    Deswegen hier noch der komplette Patch gegen vanilla vdr-2.3.9


    Edit: Basierend auf dem Patch aus dem ppa von seahawk1986 und mit den Änderungen von oben.