Beiträge von wtor

Ich habe meinen vdr von 2.6.1 auf 2.6.3 aktualisiert. Seit dem habe ich folgendes reproduzierbares Problem:

Ich halte das Live-Signal an (Pause-Taste), später will ich weiter schauen (Play). Dann kommt immer die Meldung "Soll die zeitversetzte Aufnahme gelöscht werden?". Das erwarte ich erst beim Stopp der Aufnahme. Mit 2.6.1 funktionierte das noch korrekt. Nebenbei: drücke ich Pause anstatt Play zum weiter schauen kommt die Meldung "Keine DVB Karte mehr frei". Ist auch falsch.

Kann es sein, das sich hier ein Fehler eingeschlichen hat?

Frohe Festtage!

Ok. But at least after the configured inactivity it should shutdown right? It doesn't here.

Das glaube ich nicht, der VDR lief die früh noch obwohl die Inaktivität auf 100 Minuten steht...

Dr. Seltsam: Nein, so meinte ich das nicht. Ich schaue fern und ein Aufnahme läuft. Dann schalte ich aus. Der VDR bleibt an wegen der Aufnahme (schaltet später aus). Das passiert aber nicht, wenn ich nach ausschalten das softhddevice detache (also noch lange vor Aufnahmeende).

Nach der Umstellung auf den neuen vdr hatte ich den Stromverbrauch tatsächlich durchgemessen und mit detachtem Plugin wirds weniger

Ohne Detach gehts, klar, aber es geht auch beim aufwachen für einen Timer + Aufnahme und da wird das softhddevice nie attached und es funktioniert trotzdem. Deshalb die Frage warum im anderen Fall nicht.

Ich habe da ein merkwürdiges Problem (vdr aus der Signatur). Mein vdr schaltet sich unter diesen Bedingungen nie aus:

- Ich schaue TV und eine Aufnahme läuft

- ich schalte aus (Meldung "vdr schaltet später aus" kommt wegen der Aufnahme)

- TV geht aus und softhddevice wird detached (per Skript)

Weder nach Aufnahmeende noch nach der eingestellten Inaktivitätszeit geht der vdr aus. Kein Eintrag im Log außer "vdr schaltet später aus". 100% reproduzierbar.

Ausschalten geht bei:

- Inaktivität und softhddevice attached

- Aufnahmeende (PowerOff zuvor) wenn der vdr automatisch für die Aufnahme gestartet ist (softhddevice wurde nie attached)

- Aufnahmeende (PowerOff zuvor) und softhddevice ist noch attached. Wurde einmal detached und wieder attached geht es auch nicht mehr.

Der Fall oben ist mein Normalfall, da ich den vdr mit softhddevice detatched starte und nur attache wenn der TV eingeschaltet wird. Beim ausschalten des TV wird wieder detached.

Mir ist der Zusammenhang zwischen Ausgabeplugin und vdr hier nicht klar. Das sollte doch schon aufgefallen sein, falls das kein Feature ist Kennt das jemand / ist das ein Bug?

Many thanks, it's working.

Hab den Log im ersten Beitrag vergessen hab ihn oben noch angehängt.

Ich glaube nicht. Ich habe die besagten Patche aus dem verlinktem Thread drin (was Klaus dann in die 2.6.2 packen will). Außerdem geht es ja mit xinelibout oder vaapi. Sieht für mich nach etwas anderem aus.

Wegen eines Buffer-Overflow-Problems mit VAAPI nutze ich zur Zeit eine Nvidia GT730 (Treiber nvidia 470.161) mit vdpau. Ich habe das Problem bei allen Aufnahmen, das diese am Ende nicht sofort beendet werden sondern Bild und Ton ca. 10-20 Sekunden hängt oder zittert bevor die Wiedergabe beendet wird. vdr 2.6.1 unter ubuntu 22.04 mit softhddevice / vdpau von Inj (test branch oder main oder 1.9.2). Den Patch von hier Abspielen der letzten 25 Sekunden der Aufnahme habe ich drin.

Das Problem tritt mit mit xinelibout und vdpau oder dem gleichem softhddevice nur mit vaapi (1.14, Core i3 10100, UHD-Grafik 630) bei mir nicht auf. Kann das ein Problem von softhddevice sein oder ist die Kombination mit vdpau hier das Problem. Ich komme hier nicht weiter und habe auch nichts vergleichbares gefunden. Den Log dazu habe ich mal angehängt. Der Hänger (hier 18 Sekunden) beginnt und endet immer an dieser Stelle:

Dec  3 22:06:41 vdr vdr: audio: wait on start condition
Dec  3 22:06:59 vdr vdr: [22380] non blocking file reader thread ended (pid=22020, tid=22380)

Der vdr ist während des Hängers bedienbar, d.h. drücke ich Stop wird die Wiedergabe sofort beendet.

Vielleicht kennt ja jemand das Problem oder hat sogar eine Lösung dafür

Viele Grüße

Torsten

Ja, ich habe das zum Bootparameter GRUB_CMDLINE_LINUX hinzugefügt + grub update. Dann läuft das System nur mit IPV4 (problemlos) nur osd2web will nicht mehr.

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?

Besten Dank. Sieht so aus als ob nur der IPV6-Port genutzt wird. Wäre natürlich ungünstig für IPV4-Only-Systeme

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

netstat -tulpn | grep 4444

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

Zitat von lnj

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:

Nov 20 21:36:03 vdr vdr: [22173] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Nov 20 21:36:09 vdr vdr: [22175] i/o throttle activated, count = 1 (tid=22175)
Nov 20 21:36:17 vdr vdr: [22175] ERROR: driver buffer overflow on device 1
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:

Nov 20 17:40:12 vdr vdr: [7115] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Nov 20 17:40:17 vdr vdr: [7118] i/o throttle activated, count = 1 (tid=7118)
Nov 20 17:40:23 vdr vdr: [7118] buffer usage: 100% (tid=7115)
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?

I have done some short tests and it's also working here. I will have a look next days, to see if there are any problems left.

Thanks for your work!

Torsten

Ok, den kannte ich noch nicht. Dann schaue ich mir den Patch mal an.

Nachtrag: Hab gerade gesehen, das ich den Patch ja schon drin habe da ich die quellen von seahawk1968 für yavdr nutze. Geht perfekt. Danke für den Tipp.

Torsten

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):

bool cViewMenu::SetItemRecording(const cRecording *recording, int index, bool current, bool selectable, int level, int total, int New) {
    if (!menuRecordings)
        return false;
    if (recording->Deleted())
        return false; // return false im Fall einer gelöschten Aufnahme
    menuRecordings->SetItem(recording, index, current, selectable, level, total, New);
    listChange = true;
    return true;
}

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