Posts by schmirl

Habe die drei Patches von Jasmin eingecheckt. Vielen Dank dafür.

Tut mir leid, dass ich mich so lange nicht gemeldet habe. Bin aus dem Thema VDR leider mittlerweile komplett draußen. Wäre wohl nicht verkehrt, wenn sich zukünftig jemand anders um das Repository kümmern könnte.

Viele Grüße,

Frank

Quote from hd.brummy

gcc-4.9.2 / gcc-4.9.3 wirft hier ein paar warnings raus:
-std=c++11 ist standard mässig enabled bei diesen gcc Versionen

Ja, liegt an der -std-Option. Danke für den Hinweis. Kls hat das in VDR 2.1.3 behoben. Anbei der Patch um das in remotetimers zu beseitigen.

Die Patches sind alle noch aktuell. Stehen im Namen des Patches zwei VDR-Versionsnummern ist das der Versionsbereich für den der Patch geeignet ist (z.B. vdr-1.6.0-2.0.3-MainMenuHooks-v1_0_2.diff), steht nur eine Version drin ist der Patch ab dieser Version bis dato geeignet (z.B. vdr-1.7.28-remote_instant_recordings.patch).

It's only required on client side

All you need is the instant recording patch. The setup option shows up when the define "REMOTEINSTANTVERSION" is found in VDR's config.h. Either something went wrong while applying the patch or the compiler found an unpatched copy of config.h somewhere in your system's include directories with higher precedence.

Hallo zusammen,

auf http://vdr.schmirler.de/ habe ich soeben remotetimers-1.0.2 bereitgestellt. Es gibt keine großen Neuerungen. In erster Linie geht es darum, dass das Plugin mit VDR 2.2.0 kompiliert.

Changelog:

Quote

- Added compatibility for VDR 2.1.2 (thanks to Christopher Reimer and Lars Hanisch)
- Added support for graphtft. Use -DUSE_GRAPHTFT when compiling to enable. (thanks to Jörg Wendel)
- Updated MainMenuHooks patch for VDR 2.0.4

Viel Freude damit,
Frank

Sieht so aus als ob zu diesem Zeitpunkt über SVDRP das EPG heruntergeladen wird und der VDR dabei auf den Watchdog-Timer läuft. Bitte den Timeout für den VDR-Watchdog erhöhen oder - falls das EPG via epgsync-Plugin geholt wird - im Plugin auf kanalweise Synchronisation und Jetzt/Nächste zuerst umstellen (siehe Plugin README).

Sehr schön. Dann betrachte ich das Problem als erledigt

Vielen Dank für Testen und Feedback.

In VDR 2.1.7 hat kls einen Bug im neuen CAM-Code gefixt. Hatte schon jemand die Möglichkeit, das Problem mit 2.1.7 oder 2.1.8 zu testen (ohne den Patch)?

Leider kann ich das CAM-Zeug selber nicht testen und habe momentan auch keine Zeit für VDR. Interessant wäre aber, ob es sich um das gleiche Problem handelt, wegen dem ich kls schon angeschrieben habe. Kann mal jemand testen, ob das Problem verschwindet, wenn man diese Änderung aus VDR 2.1.4 rückgängig macht: Tester gesucht: Streamdev-Server mit VDR 2.1.4+ Funktion ChannelChange?

tecfreak: Du schreibt im Ticket

Quote

Would be nice if streamdev could handle the cams like it was suggested by kls for vdr 2.1.x

Worauf beziehst Du Dich da?

Danke für's Testen. Ist jetzt im GIT...

Aha - große Einzeldateien sind das Problem. Da wäre ich nicht draufgekommen. Zwei 32-Bit Variablen habe ich beseitigt. Den nicht geeigneten ftell-Aufruf hat der Entwickler von LazyBones beigesteuert. Könntest Du nochmal testen ob nun alles passt?

Quote from hannemann

Die selbe Aufnahme vom selben Streamdev zu einer VDR Instanz auf meinem Desktop gestreamt läuft übrigens einwandfrei.

Wenn ich mal einen Schuß ins Blaue wagen darf: Die magische Grenze liegt bei 4GB. Die VDR-Instanz bei der es funktioniert ist ein 64-bit System, der Client mit dem Problem hingegen 32-bit, so dass es dort einen Überlauf gibt?

Habe hier mal einen 5 GB Film mit über zwei Stunden mit VLC als TS-Stream getestet - keine Probleme. Oder tritt das Problem bei Dir nur mit externremux auf?

Ja, Version 0.6.1 vom 28.11.2013

Danke, dass Du das mit soviel Engagement vorantreibst. Bin zeitlich leider sehr eingespannt, so dass ich im Moment keine Hilfe sein kann.

Quote

Wenn ich an eine Stelle springen möchte würde ich gerne ein Bild aus dem Video an dem timestamp via externremux generieren und als poster in das video Tag stopfen, damit man einigermaßen sehen kann wo man hingesprungen ist. Das funktioniert auch schon sehr gut, nur leider beendet sich der Streamer nicht wenn ich mit exit 0 das Script beende. Sollte das nicht so sein?

Ohne es jetzt getestet zu haben, müsste es mit folgender Änderung klappen:

diff --git a/remux/extern.c b/remux/extern.c
index 7786852..fc8eefd 100644
--- a/remux/extern.c
+++ b/remux/extern.c
@@ -325,6 +325,7 @@ void cTSExt::Put(const uchar *Data, int Count)
 {
        if (safe_write(m_Inpipe, Data, Count) == -1) {
                LOG_ERROR_STR("write failed");
+               m_Active = false;
                return;
        }
 }

Quote from hannemann

Mir kommt es so vor, als würde er Streams nach zwei Stunden neu starten. Kann das sein?

Was heißt neu starten? Fängt er von vorne an? Dann könnte es ein Überlauf sein. Gibt es Meldungen im Log?

Den Patch für die anfänglichen Abbrüche kann ich dann aber wohl einchecken?

decembersoul: für die Wiedergabe von Aufzeichnungen nutzt Streamdev den gleichen Code wie bei Live-TV. Streamdev ändert die VPID nicht.

hannemann: Freut mich, dass es im großen und ganzen funktioniert. Folgende Änderung könnte Dein Problem lösen:

diff --git a/remux/extern.c b/remux/extern.c
index c3e6ad6..7786852 100644
--- a/remux/extern.c
+++ b/remux/extern.c
@@ -303,7 +303,7 @@ void cTSExt::Action(void)
                                        dsyslog("streamdev-server: buffer full while reading from externremux");
 
                                if (result == -1) {
-                                       if (errno != EINTR) {
+                                       if (errno != EINTR && errno != EAGAIN) {
                                                LOG_ERROR_STR("read failed");
                                                m_Active = false;
                                        }

Ja, transkodieren ist gemeint.

Hallo zusammen,

habe am Wochenende das Remuxen von Aufnahmen eingecheckt. Bitte testen.

Remuxen ist nur für TS-Aufnahmen möglich. Mit alten PES-Aufnahmen funktioniert es nicht, auch wenn das Streamdev Web-Menü derzeit noch etwas anderes suggeriert.
Spulen in Remux-Aufnahmen ist leider nicht möglich. Angeblich kann VLC das (siehe http://projects.vdr-developer.org/issues/1880), ich muss mir das aber erst mal in Ruhe anschauen. Bin sehr skeptisch, dass das mit streamdev jemals möglich werden wird.
Um die Wiedergabe an einer bestimmten Position zu beginnen, kann der Parameter "pos=" an die URL angehängt werden (also z.B. http://127.0.0.1:3000/ext/1.rec?pos=...), der folgende Werte kennt (# steht jeweils für eine Zahl):

• resume: Wiedergabe an der Stelle fortsetzen, an der sie mit VDR beendet wurde. Streamdev aktualisiert die resume-Position nicht!
• resume.#: Wie vor. # steht für die Wiedergabe-ID laut VDR Setup. Interessant z.B. wenn die Multiuser-Funktion des Remotetimers-Plugins genutzt wird.
• mark.#: Ab Markierung #
• time.#: Ab Sekunde #
• frame.#: Ab Frame #
• #: Startposition in Prozent der gesamten Aufnahme (# muss zwischen 0 und 100 liegen)

Auf der TODO-Liste steht nun, all diese Möglichkeiten auch komfortabel im Streamdev Web-Menü anzubieten.

Das timersync-Plugin bedient sich eines nicht ganz sauberen Tricks. Es sperrt die lokale Timer-Liste durch den Aufruf von "Timers.IncBeingEdited()". Das Problem mit epgsearch dürfte sein, dass es abfrägt, ob die Timer-Liste gerade gesperrt ist und falls ja, wartet bis diese wieder freigegeben wird. Schau Dir in epgsearch die Stellen mit "Timers.BeingEdited()" an und patch diese Stellen ggf. raus.