[live] Locking der einzelnen VDR Objekte

Puh, da hast du dir ja was vorgenommen…

Wenn du (im Sinn nicht mehr so häufiger und tiefgreifender Änderungen) einen halbwegs stabilen Stand hast, teste ich den gerne original bzw. mit meinen lokalen Patches on Top. Gibst du an dieser Stelle dann kurz Bescheid, wenn es soweit ist?

Weil mich die Neugier gepackt hat und ich etwas Zeit hatte, habe ich mit dem Stand auf dem Test-Branch ein wenig herumgespielt. Bislang konnte ich dabei kein spezifisches Problem sehen.

Ein Problem, das auch die 3.4.0 schon hat, ist nach wie vor, dass der VDR bei der Einstellung "Frei wählbare Kanalgruppen" mit einem leeren String reproduzierbar abstürzt. Wenn dort irgendein Zeichen – und sei es nur ein Leerzeichen – eingetragen ist, passiert das nicht. In diesem Fall werden dann aber erwartungsgemäß keine Kanäle, sondern nur die Zeitachse angezeigt.

Insofern sehe ich folgende sinnvolle Lösungsmöglichkeiten:

1. Einen leeren String von Kanalgruppen intern durch ein Leerzeichen ersetzen.
2. Einen leeren String von Kanalgruppen durch die Nummer des aktuellen Kanals (aus der Info-Box) ersetzen.
3. Die 5er-Gruppen als Fallback-Lösung verwenden.

Konsequent fände ich Nummer 1, der Patch ist (zusammen mit ein paar gefixten Typos) anbei.

Ich habe die Test-Version von Live um meine lokalen Erweiterung ergänzt und nach einem ersten groben Test auf die Produktivumgebung losgelassen. Abgesehen von den individuellen Kanalgruppen gibt es keine weiteren Probleme.

Eines ist mir zufällig aufgefallen: Wenn man eine Sendung oder eine Aufzeichnung im Browser abspielt und gleichzeitig die Liste der Aufzeichnungen aufruft, bleibt die Wiedergabe im Browser nach einiger Zeit stehen und setzt erst wieder ein, wenn die Aufzeichnungen geladen wurden. Ein zum Vergleich parallel gestartetes Streaming im Media-Player läuft hingegen ohne Unterbrechung weiter.

Dieser Effekt tritt vor allem beim erstmaligen Einlesen oder nach einem touch .../.update auf, also augenscheinlich solange der Recording-Manager seine Datenbank aufbaut bzw. aktualisiert. Während dieser Zeit ist der von stream.ecpp gestartete Thread aus stream_data.ecpp in Verbindung mit ffmpeg.cpp wohl blockiert.

Ich vermute, dass ist bei 3.4.0 auch schon so. Magst du dir vielleicht einmal anschauen, ob bzw. wie man das verbessern könnte?

PS: Sind die notwendigen Änderungen denn jetzt soweit abgeschlossen oder folgend noch weitere Teile?

Ich habe den Stand von fix3 übernommen und die Änderungen kurz durchgesehen. Dabei ist mir aufgefallen, dass in EpgInfo::CreateEpgInfo() (Zeile 365 ff.) die Elemente von m_contents initialisiert werden. Alle anderen Attribute werden im Konstruktor initialisiert. Wäre das aus systematischen Erwägungen also nicht auch besser dort aufgehoben?

      EpgInfo() {
        for (int i = 0; i < MaxEventContents; ++i) m_contents[i] = uchar(0);
      }

Bei Instantiierungen wie EpgInfo epgEvent; wäre das Array dann immer korrekt mit Nullen gefüllt.

Quote from MarkusE

Ich mach jetzt erst mal die Recordings LOCKs sauber, ev. können wir uns das danach nochmal anschauen.

Perfekt. Weil beim Wechsel in das Programm eines Senders die Aufzeichnungen zwecks Erkennung von Duplikaten ebenfalls eingelesen werden, passiert die Blockierung auch an dieser Stelle. Ob das reine Einlesen der Programmdaten auch schon zur Blockierung führt, müsste man vielleicht dann anhand des Codes entscheiden und entsprechende Maßnahmen ergreifen.

Ich habe auch die Übersetzungen ein wenig aufgeräumt und einen fehlenden String ergänzt:

• 0025 Fixed missing extra translations.zip

Damit diese Fehlermeldung den anderen diesbezüglichen Fehlermeldungen entspricht, habe ich aus Gründen der Konsistenz einen fehlenden Punkt am Satzende hinzugefügt.

Ansonsten verhält sich auch dieser Stand wie erwartet.

Quote from MarkusE

Wenn ich das übernehmen soll, brauche ich einen Patch für de_DE.po

Und genau deswegen haben die anderen Sprachen endlos lange Listen von mittlerweile nicht mehr benötigten Message-Strings. Aber die kannst du bei dieser Gelegenheit dann ja manuell löschen. Im Patch waren sie halt mit drin.

Anbei der Patch mit den essentiellen Änderungen.

Quote from MarkusE

Bist Du sicher? In pages/stream.ecpp wird bei live view doch nur ein EpgInfo epgEvent; angelegt und ausgegeben. Da wird nichts mit recordings gemacht.

Das hast du jetzt vielleicht falsch verstanden, vielleicht hatte ich das aber auch unglücklich formuliert. Ich bezog mich darauf, dass man im Menü "Programm" auswählt. In diesem Fall versucht Live doch, bereits vorhandene Aufzeichnungen zu identifizieren und nach einer gleichnamigen Sendung einzufügen. Muss dazu nicht der Recording-Manager erst die Liste der Aufzeichnungen erstellen bzw. gegebenenfalls aktualisieren und mit dem TVscraper-Daten verheiraten? Dieser Code jedenfalls ist nicht von mir.

Den VDR starten und ein Browser-Fenster mit "Was läuft" öffnen. Bei einem der Sender den Link von "Sender im Browser abspielen" in ein zweites Fenster öffnen:

Dort die Wiedergabe starten, sofern das (wie bei mir) nicht automatisch passiert. Danach im Menü des ersten Fensters auf "Aufnahmen" klicken. Wenn genügend viele Aufnahmen einzulesen sind, bleibt im zweiten Fenster nach kurzer Zeit (bei mir nach so 2–3 Sekunden) die Wiedergabe stehen. Das passiert dann, wenn die bis dahin gepufferten Daten gestreamt wurden und der Puffer leergelaufen ist.

Ich vermute, dass wenn du statt auf "Aufnahmen" auf "Programm" klickst, wird wohl (wegen der Duplikat-Ermittlung) die Wiedergabe ebenfalls nach kurzer Zeit stehen bleiben.

PS: Ich denke, man muss hier nochmals das Task-Gefüge genauer betrachten. Da kennst du dich eindeutig am besten aus.

PPS: Wichtig ist bei diesem Test, dass Live die Aufzeichnungen während des Streamings vollständig einliest und dafür ein paar (so um die 5) Sekunden benötigt. Man braucht also zunächst hinreichend viele Aufzeichnungen. Und man sollte den Test entweder gleich nach dem Start des VDR durchführen oder während des Streamings kurz vor dem Aufruf der Aufnahmen ein touch .../.update ausführen.

Kann aber trotzdem sein, dass das Timing bei dir deutlich günstiger ist. Hängt halt doch ein wenig vom konkreten Environment ab.

Danke für das Update. Die überarbeiteten Recordings habe ich – mit und ohne meine lokalen Patches – ebenfalls erfolgreich getestet.

Folgende Dinge sind mir aufgefallen:

• In recman.h werden Recording-Attribute als std::string deklariert, zugewiesen werden sie aber per cSv, was so unschöne Konstrukte wie bspw. m_shortText = cSv(info->ShortText()); oder m_shortText = std::string(cSv(event->ShortText())); mit sich bringt. Sollte man sie nicht gleich besser als cSv deklarieren?
• In recman.h werden alle Recording-Attribute in der Form m_camelCase benannt. Insofern müsste m_Folder eigentlich m_folder heißen.
• Für meine lokalen Patches wäre es hilfreich, wenn für die Recordings noch m_title und m_fileName ergänzt und m_folder gleich nach m_name_for_search platziert würde.
• Im Konstruktor von RecordingsItemRec sollte das Einlesen der Recording-Attribute meines Erachtens vor dem Einlesen der TvScraper-Daten platziert (sprich: interne VDR-Daten vor externen Begleitdaten gesetzt) werden. Andernfalls hat getScraperData(), die ich lokal etwas erweitert habe, diese Attribute nicht zur Verfügung.

Zudem habe ich herausgefunden, warum das Einlesen der Recording-Images so ewig lange dauert. Grund dafür ist, dass die symbolischen Links per system() erzeugt werden. Für die Masse von Aufzeichnungen kosten die vielen Aufrufe in Summe ewig Zeit. Nachdem ich das Erzeugen der Symlinks auf std::filesystem::create_symlink() umgestellt habe, geht das Setzen der Links rasend schnell und verbraucht kaum noch Zeit.

Im beigefügten Patch findest du alles mit Ausnahme des ersten Punktes (std::string zu cSv).

Ich weiß, dass du da ziemlich zurückhaltend bist. Ich hatte dennoch die Hoffnung, ein m_title sowie ein m_fileName als Ergänzung zu m_folder würdest du akzeptieren können. Ersteres braucht man für den Fall, dass der Titel nicht mit dem Verzeichnisnamen (m_name) übereinstimmt, was hierdurch:

cSv name(recording->Name());
...
cSv recName = name.substr(index, name.length() - index);
RecordingsItemRecPtr recPtr = std::make_shared<RecordingsItemRec>(recName, ...);

… durchaus der Fall sein kann. Letzteres benötigt man, wenn man auf in Aufzeichnungen hinterlegte Dateien wie etwa Poster, zugreifen möchte.

Zudem: Früher konnte man sich die fehlenden Attribute einfach über den Recording- bzw. RecInfo-Pointer holen, die es jetzt nicht mehr gibt. Deshalb wäre es schon schön, wenn man die gebräuchlichsten Attribute einfach im Zugriff haben würde. Aber wenn du das so streng sehen willst, komme ich damit natürlich auch klar.

Ich hoffe, du übernimmst wenigstens noch die anderen vorgeschlagenen Korrekturen. Denn sonst wird bei mir das Mergen nach neuen Commits von dir zu einer ziemlichen Qual…

Quote from MarkusE

Das ist korrekt und beabsichtigt, ich möchte ja Kopien speichern. cSv würde nur Referenzen speichern.

Das ist mir schon klar. Deshalb bitte nochmal für mich als Dummie: Warum geht die Zuweisung dann über cSv(...)? Warum also:

• m_shortText = cSv(info->ShortText());

anstatt einfacher:

• m_shortText = info->ShortText();

Quote from MarkusE

Nimm mal an, info->ShortText() == nullptr.

Danke… also nur eine elegante Alternative zu einem Ternary.

War letztens wohl zu oft Environments unterwegs, in denen man sich um so etwas meist nicht kümmern muss.