[Announce] Streamdev CVS auf dem aktuellen Stand

Endlich kommt mal wieder etwas Bewegung da rein. Bisher hab ich jedenfalls keine Probleme bemerkt.

Wie wär's denn, mal ein paar von den Compiler-Warnings aufzulösen? Mich stört diese Unordnung immer, weil man so die echten Fehler nicht sieht.

Gruß,

Udo

Hallo Thomas,

ich freue mich sehr zu hören, daß es mit der Entwicklung weitergeht. Wirst Du auch längerfristig an dem Plugin weiterarbeiten?
Über eine "Wiederbelebung" der Remote-Timer würde ich mich sehr freuen.

Gruß Jörg

Hallo Thomas,

Würde mich ebenfalls sehr über die Belebung der Remotetimer freuen.
Was allerdings wirklich fehlt ist die Tatsache, dass ein Streamdev-Client die Kanäle nicht verlinkt. Wird für das Director-Plugin benötigt.

Viele Grüße und vielen Dank
Peter

Klingt Prima! Kann mir noch jemand sagen, wo ich den CVS finde (oder besser wie er heißt)?

Danke und Gruß

Toxic

Zitat

Original von Toxic-Tonic
Klingt Prima! Kann mir noch jemand sagen, wo ich den CVS finde (oder besser wie er heißt)?

Danke und Gruß

Toxic

Hi,
Das findet man unter anderen im VDR-Wiki unter dem Punkt Streamdev-plugin --> Snapshot.

OK, in der Wiki war ich und bin dann stumpf auf die Homepage des Plugins gegangen....

Man bin ich manchmal blöd!!

Danke!!

Toxic

Blitz2 und pixelpeter
Die remote timer (und EPG-Sync als Hintergrund-Thread) sind bei mir als separates Plugin bereits in Arbeit (Plugin-Name bislang clienttools). Bis dahin sollte das remoteosd-Plugin einen ausreichenden Ersatz bieten. Hat das schon jemand probiert? Bislang wenig Downloads und keinerlei Feedback erhalten.

Ab dem Zeitpunkt als remoteosd fertig war, habe ich die die remote timer aus dem gepatchten streamdev für 1.3.34-1.3.37 gar nicht mehr verwendet, da das Arbeiten mit dem Timer-Menü des Servers schon so seine Vorteile hat (Sortiert, Anzeige welcher Timer gerade aufzeichnet, Server EPG mit Anzeige der programmierten Timer, ...). Eben so als würde man direkt am Server sitzen. Ist halt nur ein wenig langsamer (nur ca. 2 Tastendrücke pro Sekunde werden verarbeitet).

Zu meinem remote timer Nachfolger: Die Struktur wird natürlich ähnlich sein wie bei den Original Remote-Timers. Sprich: Das Timer-Menü wird auf dem Client nachprogrammiert und kommuniziert via SVDRP bzw. VTP mit dem Server. Ein paar Dinge möchte ich hier allerdings zur Diskussion stellen:

1. Integration in streamdev
Ich werde das ganze in jedem Fall zunächst als eigenes Plugin realisieren. Die Funktionalität wieder in das streamdev-Plugin zu integrieren sollte aufgrund ähnlicher Strukturen nicht allzu komplex sein, ich persönlich sehe allerdings nicht allzuviel Sinn darin. Das streamdev-Plugin ist zum streamen da und das tut es hervorragend (An dieser Stelle ein dickes :respekt). Wenn es im nächsten Developer-Strang wieder rund geht in den Menü-, Timer- und Schedule-Klassen, heisst es wieder laufend nachbasteln damit sich streamdev noch übersetzen lässt. Unnötiger Ärger für die (sicher nicht wenigen) Benutzer, die nur HTTP-Streaming verwenden und für die Menü-Funktionen ohnehin keinerlei Verwendung haben. Und wenn's zuviel wird, bleiben die Menü-Klassen am Ende wieder ganz auskommentiert so wie jetzt...

2. Remote Schedule
Timer-Programmieren ohne EPG macht keinen Spaß. Das original streamdev remote schedule Menü ist eigentlich ein ganz normales lokales Schedule Menü. Insbesondere werden auch nur die lokalen EPG-Daten gelesen. Einziger Punkt der etwas mit "remote" zu tun hat: Aufnehmen erstellt keinen lokalen Timer sondern einen der von den remote timers Klassen verarbeitet wird. Mir stellt sich nun die Frage wie ich das ganze implementiere:

• Genauso (Implementierung etwas oversized. Durch EPG-Sync im Hintergrund aber nicht unkomfortabel)
• Die dargestellten EPG Info's nicht aus dem lokalen EPG sondern via SVDRP vom Server beziehen (EPG Sync entfällt, möglicherweise aber langsam)
• Patch für die Aufnahmen-Funktion des Original VDR Schedule-Menü (Programmieren lokaler Timer aus EPG dann nicht mehr möglich)

Was in welcher der Varianten alles möglich sein wird muss ich mir aber erst noch zu Gemüte führen.

3. Umstellen auf SVDRP
Vielleicht wird die SVDRP-Schnittstelle des VDR irgendwann mal so erweitert, dass mehrere Verbindungen gleichzeitig möglich sind. Streamdev ließe sich dann (evtl.) auf SVDRP umstellen. Im streamdev-Server könnten dann die threadsafe nachprogrammierten SVDRP-Befehle entfallen. Der streamdev-client ließe sich auf das svdrpservice Plugin umstellen. Damit wäre eine weitere Modularisierung erreicht.

Auf schmirl hab ich doch nur gewartet, um meinen Senf beizusteuern

zu 1.
Halte eine Trennung für sinnvoll, nicht zuletzt da jedes Plugin nur einen Hauptmenüeintrag hat. Ausserdem kann sich so jeder zusammensetzen, was er braucht und hat nicht massenhaft ungenutzten Code im Speicher.

zu 2.
ist die Frage, wie zuverlässig Section Streaming implementiert werden kann (wenn es denn soweit ist dass am Streaming selber wieder gearbeitet wird, wobei ich offenlasse ob ich allein das tun werde ) und ob dadurch das EPG-Sync wegfallen kann. Dann hätte man dieselben Daten zur Verfügung wie der Server (Nebeneffekt: Linked Channels würden funktionieren) und könnte wirklich die Timererstellung aus dem originalen EPG-Menü umleiten (evtl. über einen Switch im Setup).

zu 3.
Sehe ich genauso, hatte ich auch exakt so vor wenn SVDRP das irgendwann mal hergibt.

Hallo schmirl, LordJaxom,

äh, kleine Frage bzgl. EPG, weil ich anscheinend etwas übersehe:
Bei mir wird das EPG per NFS vom Server bereitgestellt. Der Client greift drauf zu und kann so wunderbar Timer programmieren. Was genau ist der Haken (ich habe bisher keinen nachteiligen Effekt bemerkt), dass ihr das EPG "extra" synchronisieren wollt?
Als weitere Info: Die channels.conf wird ebenso über NFS bereitgestellt und vom Client benutzt. Der Server verwaltet so alles. Änderungen sollen/dürfen nicht durch/über den Client vorgenommen werden, der "einfach dumm ist und nimmt, was ihm vorgeworfen wird". So halte zumindest ich es für sinnvoll.

Viele Grüße
Chriss

Hallo Chriss,

der entscheidende Punkt ist weniger wie der Client an's EPG ran kommt sondern wie der Client aus dem EPG heraus einen Timer auf dem Server programmieren kann:

• lokale EPG-Daten, eigenes Schedules-Menü
• Server EPG-Daten, eigenes Schedules-Menü
• lokale EPG-Daten, gepatchtes Schedules-Menü des VDR

Zu Deiner NFS-Lösung:
Korrigiere mich, aber ich denke wenn Dein Client das Server-EPG beim Starten eingelesen hat aktualisiert er das EPG danach nicht mehr. Ist also irgendwann nicht mehr aktuell. Zudem muss mit dem vdr-Start auf dem Client gewartet werden, bis NFS da ist (wenn der Server per WOL geweckt wird). Das wären wieder ein paar Sekunden die den WAF reduzieren...

Die "dummer Client"-Variante hat sicherlich seine Daseinsberechtigung, passt aber nicht überall. Bei reinen Streaming-Servern wie bei mir gibt's nur Clients - und damit nur Dumme ;D.

Zu den Remote Timern.
Waere es eine Idee das ueber Mysql zu machen? Durch XXV ist eine DB ja bereits vorhanden.
Der VDR-Client schreibt die Timer einfach in die Timer Tabelle, der VDR-Server liest sie von da.

Das Selbe koennte man mit EPG machen? VDR verwaltet EPG komplett ueber SQL Tabelle. Damit wuerde der Sync bei den Clients weg fallen.

Und damits dann komplett ist, koennte man das mit der channels.conf auch machen.
Der Client braeuchte dann nichts mehr "scannen", die Eintraege sind einfach da, da sie ja vom Server immer aktuell gehalten werden.

Dadurch koennten auch externe Programme/Scripte dort leicht zugreifen.

Gegen eine Datenbank bin ich auch ganz entschieden, habe bei meinem VDR MySQL und XXV wieder deinstalliert, weil das ständige rattern nervte... Ausserdem ist das für die nötige Aufgabe Overkill und drittens hat ein Plugin vollen Zugriff auf die Daten die VDR verwaltet, wieso sollte man die im gleichen Prozess doppelt speichern?

Hi schmirl,

ok, bei Dir herrscht ein anderes Einsatzszenario als bei mir. Daher habe ich "Deine Probleme" nicht verstanden.
Bei mir bootet der Client ja vom Server, also ist NFS "sowieso da".

Zitat

Korrigiere mich, aber ich denke wenn Dein Client das Server-EPG beim Starten eingelesen hat aktualisiert er das EPG danach nicht mehr. Ist also irgendwann nicht mehr aktuell.

Öhm, bei mir läuft der Client für max. 6 Stunden und ich hole das EPG (auf'm Server natürlich) täglich per tvmovie2vdr. Habe noch nicht bemerkt, dass da was nicht aktuell ist. Wenn nur die VDR-internen Mittel für's EPG genutzt werden, sieht das bestimmt anders aus.

Viele Grüße
Chriss

Zitat

Nicht jeder nutzt XXV oder hat ne MySQL Datenbank auf seinem VDR

Dito. Ich bin froh, dass der VDR gerade nicht ein Overkill-Rechner sein muss.
Wenn in irgendeiner Form eine DB Sinn gibt, dann plädiere ich für SQLite. Die frisst wenigstens nicht permanent Ressourcen ab und ist auch recht fix.

Zitat

Original von Thomas
Solange also die Bandbreite von SVDRP nicht beschränkt werden kann ist das nicht wirklich eine Option...

Oder eben Section Streaming, dann trudeln die Daten beim Client in derselben Frequenz ein wie beim Server auch, nämlich so wie sie ausm Orbit kommen

Zitat

Dennoch hab ich Bedenken bei einer Synchronisation über SVDRP, als diese nämlich noch im Plugin möglich war hat die entstehende Netzlast den Stream zum Ruckeln gebracht

Kann ich nicht bestätigen - selbst wenn zwei Clients streamen. Der Server nur ein PII/350 - vielleicht ist er einfach zu langsam um das Netz zu überlasten :D.

Mich hat gestört, dass während des EPG-Sync der Client nicht mehr angesteuert werden konnte. Daher nun meine neue Lösung mit dem Sync als Hintergrund-Thread. Funktioniert bei mir zuhause auch schon fast perfekt: EPG-Sync läuft automatisch beim Starten an und holt erst "now" und "next", danach den Rest. Die Events sind quasi sofort in der Kanal-Info enthalten (und die standen nicht schon vorher in der epg.data, da die im tmpfs liegt). Irgendwo habe ich nur noch ein Problem, dass zum aktuellen Kanal im OSD nix kommt, wohl aber im graphlcd