Posts by wtor

    In der Tat merkwürdig. Vielleicht wird telnet trotz -4 intern auf IPV6 gemappt? jedenfalls werden alle anderen vom vdr genutzten Ports an IPV4 gebunden. Nur osd2web nicht, und das will ja auch mit nur IPV4 nicht... Vielleicht ein websocket-Thema?

    Da ich nicht glaube, das ich der einzige bin der osd2web nutzt, mal folgende Frage: kann mal bitte jemand dies aufrufen:

    Code
    1. netstat -tulpn | grep 4444

    Ich würde gern wissen, ob osd2web + vdr generell auch den IPV4 Port nutzt. Danke.

    Va-api confirmed, I'll look it.

    Vdpau and cuvid no problems, I'll test yet.

    I can confirm this problem for vdpau on you test branch. I use your test branch because of 720p problem with vaapi. So vaapi runs fine here, but as there are some buffer full problems (va-api-glx-und-720p-kein-bild) which block me to use vaapi daily, i added an nvidia GT730 card (with driver 470) and used your softhddevice in test branch. In that configuration i got the same problem if switching to ZDF HD.

    I retested with debug enabled. VDR was started at Nov 20 17:48, and it hangs at 21:36 for about a minute. Here the start and the end of the problem in short:


    Code
    1. Nov 20 21:36:03 vdr vdr: [22173] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    2. Nov 20 21:36:09 vdr vdr: [22175] i/o throttle activated, count = 1 (tid=22175)
    3. Nov 20 21:36:17 vdr vdr: [22175] ERROR: driver buffer overflow on device 1
    4. Nov 20 21:36:54 vdr vdr: [22175] i/o throttle released, count = 0 (tid=22175)

    So, the vdr runs fine without problems for about 4 hours, then the problem occured. This happens in different time ranges (today afternoon it happend about 20 minutes after vdr start). I attached the full log for further analyzing.

    Very short Test :( i got the same problem like said some posts before with -w no-hw-decoder, but here i tested with HW decoder (va-api-egl). Means randomly the picture hangs about a minute with these log entries:

    Code
    1. Nov 20 17:40:12 vdr vdr: [7115] ERROR: 1 TS packet(s) not accepted in Transfer Mode
    2. Nov 20 17:40:17 vdr vdr: [7118] i/o throttle activated, count = 1 (tid=7118)
    3. Nov 20 17:40:23 vdr vdr: [7118] buffer usage: 100% (tid=7115)
    4. Nov 20 17:40:24 vdr vdr: [7118] ERROR: driver buffer overflow on device 1

    I will recompile with debug enabled. Any ideas about that problem?

    Im skindesigner Plugin werden gelöschte Aufnahmen nicht angezeigt, in anderen nicht skindesigner Plugins schon. Nach einer Suche im Forum habe ich das Problem hier auch gefunden, leider ohne Lösung. Ich habe mich mal durch den Code gewühlt und hier im skindesigner etwas gefunden (coreengine/viewdisplaymenu.c):


    Code
    1. bool cViewMenu::SetItemRecording(const cRecording *recording, int index, bool current, bool selectable, int level, int total, int New) {
    2.     if (!menuRecordings)
    3.         return false;
    4.     if (recording->Deleted())
    5.         return false; // return false im Fall einer gelöschten Aufnahme
    6.     menuRecordings->SetItem(recording, index, current, selectable, level, total, New);
    7.     listChange = true;
    8.     return true;
    9. }


    Die Zeilen 4 + 5 habe ich ergänzt um zu prüfen, ob es sich um eine gelöschte Aufnahme handelt. Damit zeigt das undelete Plugin die Aufnahmen auch wieder an. Ich denke im Fall einer gelöschten Aufnahme ist der Rest auch nicht nötig - korrigiert mich bitte wenn ich falsch liege. Kann das irgendwer mal gegenprüfen und evtl. im Code / git einbringen, ich bin da leider nicht so im Bilde :)

    Ich nutze ein externes TFT per OSD zu Anzeige. Das es nun schon mehrfach passiert ist, das das System nicht mehr bedienbar war, habe ich das mal analysiert. Ergebnis: sporadisch läuft der für osd2web genutzte Browser amok und zieht sich den kompletten Speicher inkl. Swap rein. getestet mit firefox im Kiosk-Mode und Palemoon (Vollbild). Scheint irgendwie unabhängig vom Browser zu sein. Da dann auch der vdr blockiert wird (inkl. Bild) beendet ich den Browser aktuell per earlyoom als Workarround.


    Kennt jemand dieses Problem oder hat eine Lösung dafür?


    Danke & Gruß

    Torsten

    Richtig, natürlich nicht gelesen :S aber das Problem bleibt auch bei diesem Eintrag bestehen:

    Code
    1. <drawtext condition="isset{customstring1}" y="0" align="center" fontsize="40%" font="{light}" color="{clrText}" text="{tr(vdrdlna)}: {customstring1}" />

    "invalid text token" im Log und keine Anzeige im Skin. Packe ich die condition in die übergeordnete "area", bleibt das Problem das Gleiche.

    Irgendwie funktioniert das hier nch nicht. Das ist die Zeile:


    Code
    1. <drawtext condition="{customstring1}" x="0" y="0" fontsize="40%" font="{light}" color="{clrText}" text="{tr(vdrdlna)}: {customstring1}" />


    Setze ich einen festen Wert anstatt "{customstring1}" am Ende, kommt eine Anzeige. Setze ich den Wert per:


    Code
    1. svdrpsend PLUG skindesigner SCST 1 = aktiv

    Ist die Anzeige trotzdem leer obwohl der Wert gesetzt ist:


    Code
    1. svdrpsend PLUG skindesigner LCTK
    2. Nov 13 17:56:07 vdr vdr: [1345] skindesigner: custom string token 1 = "aktiv"

    Und auch mit der condition kommt der Fehler im Log. Irgendwie unklar...

    Ich möchte mir in einen skindesigner Skin einen eigenen Wert (Status bestimmter Prozesse) als String im Skin ausgegeben. Da sollte ähnlich zu CPU, Load... sein. Ich habe das vdrstats-Skript dazu erweitert, das nun parallel zu vdrpcpu/men noch eine weitere Datei unter /tmp/skindesigner anlegt (mit dem anzuzeigenden Inhalt).


    Wie bekomme ich das nun in das Skin? Bei der Suche bin ich auf customstring1..10 gestossen. Allerdings finde ich keine Beschreibung, wie das einzubauen wäre. Baue ich so etwas:


    Code
    1. text="Test: {customstring1}"

    kommt im Log immer:


    Code
    1. skindesigner: invalid text token {customstring1} in expression


    Ich glaube ich bin hier mangels Anleitung komplett auf dem Holzweg. Geht das überhaupt / wie?


    Danke schonmal!

    In /etc/default/grub habe ich zu GRUB_CMDLINE_LINUX "ipv6.disable=1" hinzugefügt und "udate-grub" ausgeführt. Der normale Weg halt. Das Sytem läuft problemlos mit IPV4, nur osd2web nicht.

    Hatte die Frage zwar schon hier gestellt (Port 4444 nur IPV6), ich glaube hier passt es besser :)


    Bei mir horcht das Plugin nur auf Port 4444 von IPV6. D.h. nach dem Versuch der Umstellung des Systems unter ubuntu 22.04 auf nur IPV4-Adessen ist der Port nicht mehr erreichbar. localhost:4444 geht hier nur per IPV6. Soll das so sein oder wo liegt das Problem?