vdr-live @ vdr-2.3.1 ?

ein sinvolle schlanke Alternative wäre auch schön, gibt es aber meines Wissens auch nicht

Am ehesten würde es sich vielleicht anbieten, ein externes Programm zu schreiben, welches mit dem vdr über restfulapi kommuniziert.
Ich brauche da auch noch einen Ersatz (neben epgsearch).

Lars.

Quote from wirbel

Alles neu, wenn alles eigentlich schon existiert?
Und xml basiert Daten versenden um sie auf der Empfängerseite mühsam per dom parser zu entpacken? Hm..

Nö, das restfulapi plugin kann auch JSON. Als ich damit anfing sogar ausschließlich.

Gerald

Der Code von live (wie auch epgsearch) ist mir zu komplex und auch in einem anderen Stil programmiert, mit dem ich nicht so gut um kann. Ich hab bei beiden versucht, sie an 2.3.1 anzupassen, aber es fehlt halt der letzte Rest. Es läuft einfach nicht rund oder hängt mal hier oder mal da. Manchmal ist es auch nicht verkehrt, mit dem Gelernten von vorne zu beginnen.

Lars

Ich muss mal heute Abend nachsehen, ob ich das noch irgendwo habe.

Lars.

Quote from wirbel

Hat jemand schon vdr-live an 2.3.1 angepasst?

Ich würde es eigentlich gerne benutzen, aber alles was ich finde ist alt und
z.Z. scheitere ich an den extremen Änderungen zwischen vdr-2.2 und 2.3.1.

Einfach mal so nach Schema 'X' die Änderungen einzupflegen funktioniert bei diesem Plugin eher nicht,
und es wär schade Zeit zu verschwenden dafür, wenn jmd anders etwas fertig hat
Man kommt wegen tntnet, gleichzeitigem Zugriff auf EPG , Channels und Aufzeichnungen bei dem Plugin in Teufels Küche.

Ich hatte mich die letzten Tage mal daran gemacht, muss allerdings sagen dass ich von den Internas des VDR im Allgemeinen und von Live im Besonderen reichlich wenig verstehe. Wie dem auch sei, das Plugin lässt sich compilieren und läuft auch soweit ich das beurteilen kann. Ich verwende davon allerdings nicht viele Funktionen.

Drei Dinge haben sich leider nicht anpassen lassen, da die Methoden aus welchen Gründen auch immer nicht mehr vorhanden sind:

1. Timers: Timers->Modified gibt es nicht mehr, es wird halt immer true zurückgegeben

#if VDRVERSNUM >= 20301
                    	bool Modified() { return true; }
#else
                    	bool Modified() { return Timers.Modified(m_state); }
#endif

2. Timers: Timers->BeingEdited gibt es nicht mehr, diese Überprüfung finded halt nicht mehr statt

+#if VDRVERSNUM < 20301
            	if ( Timers.BeingEdited() ) {
                    	StoreError( timerData, tr("Timers are being edited - try again later") );
                    	return;
            	}
+#endif

3. Recordings: Recordings->StateChanged gibt es ebenfalls nicht mehr, es wird halt immer true angenommen

#if VDRVERSNUM >= 20301
            	bool stateChanged = true;
#else
            	bool stateChanged = Recordings.StateChanged(m_recordingsState);
#endif
            	if (stateChanged || (!m_recTree) || (!m_recList) || (!m_recDirs)) {

Bei meinen Tests mit maximal 3 Timern und 3 Recordings dürfte das sich nicht nachteilig auswirken, wie das allerdings ist wenn man viele Recordings hat kann ich nicht beurteilen, wenn ich mal 10 Aufnahmen habe dann ist das schon viel

Für Interessierte habe ich meinen Patch hier mit beigelegt.

Das sind auch ungefähr die Stellen, an denen ich dann aufgegeben habe. Zumindest bei Nummer 3 muss man sich dort irgendwo einen StateKey merken, und mit diesem die Recordings überprüfen, ob sie sich seit dem letzten mal geändert haben. Wenn man immer "true" annimmt, wird live ständig was tun und unnötig CPU verbrennen.

Ähnliches gilt für Timers.BeingEdited. Da muss man ggf. prüfen, ob jemand einen Write-Lock auf die Timer hat und dann entsprechend aussteigen.

Und das "Modified" der Timer fragt man auch über einen StateKey ab, den man vorhalten muss.

Lars.

Quote from mini73

Das sind auch ungefähr die Stellen, an denen ich dann aufgegeben habe. Zumindest bei Nummer 3 muss man sich dort irgendwo einen StateKey merken, und mit diesem die Recordings überprüfen, ob sie sich seit dem letzten mal geändert haben. Wenn man immer "true" annimmt, wird live ständig was tun und unnötig CPU verbrennen.

Davon ging ich auch aus, aber wenn die Funktionen von dem Erleuchteten (sorry für den Sarkasmus) wegoptimiert wurden, dann geht das halt eben nicht. Bei meinem Kurztest gestern abend konnte ich aber keine permanente CPU Last erkennen. Ich vermute mal, dass das nur zum Tragen kommt wenn man auf der Web-Oberfläche herumklickt.

Quote from mini73

Ähnliches gilt für Timers.BeingEdited. Da muss man ggf. prüfen, ob jemand einen Write-Lock auf die Timer hat und dann entsprechend aussteigen.

Das bringt aber auch nix, da man ja nicht zwangsläufig jeden Write-Lock mitbekommt. Sollte aber auch egal sein, da ein LOCK_TIMERS_WRITE ja solange wartet bis eventuell bereits vorhandene Write Locks wieder entfernt wurden.

Quote from mini73

Und das "Modified" der Timer fragt man auch über einen StateKey ab, den man vorhalten muss.

Völlig richtig. Aber was nicht vorhanden ist lässt sich halt auch nicht verwenden. Tolle Weiterentwicklung kann ich da nur sagen

Ich seh grad,

Timers.BeingEdited()

ist im Epgsearch Plugin auch nur deaktiviert worden

Blöde Frage: Könnte man die fehlenden Funktionen nicht einfach in einer Bibliothek oder so nachbauen?
Das müsste man dann nur einmal machen und die Änderungen in den Plugins wären gering.

Die Nummer 2 war irgendwie vom alten Lockningsystem.
Wenn ich es richtig sehe ist es durch das Makro LOCK_TIMERS_WRITE ersetzt. Es müsste also von Nachteule schon korrekt umgesetzt sein.
- Ich hab es eben aber nur kurz überflogen.

Bei den anderen keine Ahnung.

Quote from SHF

Die Nummer 2 war irgendwie vom alten Lockningsystem.
Wenn ich es richtig sehe ist es durch das Makro LOCK_TIMERS_WRITE ersetzt.

Das würde ich auch so sehen