Permashift und VDR 2.3.4 => blockiert wenn graphtftng aktiv!

CKone · 4. Mai 2017

Hallo

wenn ich Pause oder Rücklauf drücke kommt die Meldung: "Live Signal wird angehalten", das Bild läuft jedoch weiter und die Fernbedienung reagiert nicht, vermute die Hauptschleife blockiert

Im Log wird er irgendwann fertig aber der vdr kommt nicht mehr in nen normalen Modus. Wenn ich ihn manuell neu starte hab ich dann aber die Aufnahme aus dem Timeshift auf der Platte

Code

May  3 20:30:54 CKone vdr: [3816] Permashift saving live buffer: count 19740, processed 14852
May  3 20:30:54 CKone vdr: [3816] Permashift saving live buffer: count 101708, processed 76328
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 25380, processed 19176
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 126336, processed 94752
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 31584, processed 23688
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 80088, processed 60160
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 19928, processed 15040
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 124644, processed 93624
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 31020, processed 23500
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 79712, processed 59972
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 19740, processed 14852
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 100956, processed 75952
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 25004, processed 18800
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 78020, processed 58656
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 43240, processed 32712
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 82156, processed 61852
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 20304, processed 15228
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 100956, processed 75952
May  3 20:30:55 CKone vdr: [3816] Permashift saving live buffer: count 25004, processed 18800
May  3 20:30:55 CKone vdr: [3816] Permashift live buffer fully saved.

Alles anzeigen

Jemand ne Idee, funktionierts bei euch?

Der Patch ist so in den vdr "reingerutscht", daher vermute ich eher das mit dem Plugin was nciht stimmt?

Christian

SurfaceCleanerZ · 4. Mai 2017

Hi,
Geht die Aufnahme denn auch abzuspielen?

Da hat sich ja was an der Aufnahmenummerierung zu 2.3.4 geändert...

Wird der Timer denn korrekt angelegt? Da wurde in 2.3.1 die Nummerierung angepasst.
S.zu beidem auch den aktuellen epgsearch Thread.
Nur eine Idee...
Was sagen denn die logs und der Debugger?
Ging es denn mit 2.3.3?
MfG Stefan

CKone · 4. Mai 2017

> Geht die Aufnahme denn auch abzuspielen?
yep, ist super

> Da hat sich ja was an der Aufnahmenummerierung zu 2.3.4 geändert...
wäre ne Möglichkeit

> Wird der Timer denn korrekt angelegt? Da wurde in 2.3.1 die Nummerierung angepasst.
die Version ist ja für 2.3.1 ausgelegt, daher sollte es kein Problem sein

> Was sagen denn die logs und der Debugger?
keine Fehler soweit ich das sehe

> Ging es denn mit 2.3.3?
keine Ahnung

Christian

seahawk1986 · 4. Mai 2017

Zitat von CKone

> Ging es denn mit 2.3.3?
keine Ahnung

Die VDR 2.3.3 Pakete gäbe es ja noch in meinem vdr-experimental PPA

Ein Eike · 5. Mai 2017

Hallo,

ich kuck mal, ob ich am Wochenende Zeit dafür finde.
Werd erstmal wieder meinen eigenen Code verstehen müssen...

Mit welcher Version lief es bei dir noch richtig?

Ciao,
Eike

CKone · 5. Mai 2017

oh das wäre prima, vielen Dank.

Ich komm direkt von der 2.2.0 auf die 2.3.4, hatte für n Abend 2.3.3 drauf aber da hab ich ehrlich gesagt nicht getestet

In der 2.2.0 lief es in jedem Fall die letzten Monate super!

Es ist auch nicht so das gar nichts funktioniert, kann auch sehen das der RAM vollläuft (hab ihm 2 von 4Gb zugewiesen). - Nur wenn du ihn mit Pause/Rücklauf aktivierst dann kommt die Meldung "Live TV wird angehalten", Bild läuft weiter, Einlendung bleibt stehen und vdr blockiert. Da der Patch da so einfach in den code ohne rejects reingerutscht ist vermute ich eher ein Problem mit dem Plugin.

Christian

nc17 · 5. Mai 2017

Also bei mir funktionierts mit 2.3.4, nur mal zur Info, ist natürlich für Eike jetzt nicht einfacher dadurch nen Fehler zu finden
Ich benutze die Pakete von Alexander unter Xenial. (danke übrigens dafür)

seahawk1986 · 5. Mai 2017

Das ist schon mal interessant, weil die Pakete von CKone auf meinen Paketen basieren, aber er noch ein paar zusätzliche VDR-Patches und Plugins nutzt, die es nicht in meinem PPA gibt. Und CKone nutzt den VDR 2.3.4 soweit ich es mitbekommen habe unter trusty (auf Basis einer yaVDR 0.6 Installation), nicht unter xenial.

nc17 · 5. Mai 2017

Also je länger bei der aktuellen Sendung schon "gepermashifted" wurde, desto länger dauert es bei Drücken der Pausetaste bis man dann im Wiedergabemodus landet, da bleibt bei mir das "LiveTV-Signal wird angehalten" aber dann auch max. 5 / 6 Sekunden stehen, denke, dass das normal ist, jedenfalls läuft nichts weiter.

Ein Eike · 5. Mai 2017

Zitat von nc17

Also je länger bei der aktuellen Sendung schon "gepermashifted" wurde, desto länger dauert es bei Drücken der Pausetaste bis man dann im Wiedergabemodus landet, da bleibt bei mir das "LiveTV-Signal wird angehalten" aber dann auch max. 5 / 6 Sekunden stehen, denke, dass das normal ist, jedenfalls läuft nichts weiter.

Hast du in den Optionen "Puffer Speichern blockiert Rückspulen" aktiviert?

nc17 · 5. Mai 2017

Nein, ist deaktiviert, was soll das eigentlich bezwecken? Hab das Plugin schon länger nicht mehr genutzt.

Ein Eike · 5. Mai 2017

Zitat von nc17

Nein, ist deaktiviert, was soll das eigentlich bezwecken? Hab das Plugin schon länger nicht mehr genutzt.

Wenn man es deaktiviert, wird nur ein Stückchen gespeichert und dann parallel zum Zurückspulen, das die Daten einliest, weiter gespeichert.
Also eine Art Wettrennen zwischen Speichern und Laden.
Wenn man es aktiviert, wird sicherheitshalber der komplette genutzte Puffer, sagen wir 2 GB, auf Platte geschrieben und der VDR pausiert solange.

Wenn es aktiviert ist, ist also zu erwarten, dass es je nach Größe und "Füllstand" des Buffers ein bisschen dauern kann, bis gespult wird.

nc17 · 5. Mai 2017

Achso, naja, ich hab eigentlich mit beiden Varianten kein Problem gehabt, die paar Sekunden Zeit hab ich.
Wenn ich aber statt "Rewind" "Pause" drücke, wird nicht gespult, sondern die Wiedergabeansicht der Aufnahme wird angezeigt und steht am Anfang der Aufnahme, ist das gewolltes Verhalten ? Ich finde es sinnvoller, dass wenn ich Pause drücke auch der aktuelle Zeitpunkt beibehalten wird, momentan kann ich mich damit behelfen gleich nach Pause mit der 9 zum Ende zu springen, was aber auch nur funktioniert, solange keine Schnittmarken enthalten sind.

Ein Eike · 5. Mai 2017

Zitat von nc17

Achso, naja, ich hab eigentlich mit beiden Varianten kein Problem gehabt, die paar Sekunden Zeit hab ich.
Wenn ich aber statt "Rewind" "Pause" drücke, wird nicht gespult, sondern die Wiedergabeansicht der Aufnahme wird angezeigt und steht am Anfang der Aufnahme, ist das gewolltes Verhalten ? Ich finde es sinnvoller, dass wenn ich Pause drücke auch der aktuelle Zeitpunkt beibehalten wird, momentan kann ich mich damit behelfen gleich nach Pause mit der 9 zum Ende zu springen, was aber auch nur funktioniert, solange keine Schnittmarken enthalten sind.

Eigentlich war der Plan, dass er beim aktuellen Stand bleibt.

Ein Eike · 7. Mai 2017

Zwischenstand: Bei mir läuft's mit VDR 2.3.4.
Ich werd mal ein paar mehr Meldungen zur "Übergabe" zwischen Timeshift, Speichern und Abspielen der Aufnahme einbauen.

CKone · 7. Mai 2017

also hier nicht - gleiches Verhalten wie geschildert. Danke schon mal für den Test.

Werde dann als nächstes mit nem minimalen Pluginset arbeiten und gegentesten.

Christian

Ein Eike · 8. Mai 2017

Ich hab jetzt mal ein paar mehr Syslog-Ausgaben eingebaut.
Der aktuelle Code liegt unter https://github.com/eikesauer/Permashift .

Die Ausgaben sehen bei mir so aus (zum Glück gibt es noch ein paar DVB-T-Zombie-Sender!)...

Code

May  8 20:16:09 track vdr: [25633] permashift: live video buffer (100 MB) full, overwriting started
[...]
May  8 20:30:08 track vdr: [25618] [vdr-fe]    Keypress: XKeySym b
May  8 20:30:08 track vdr: [25609] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
May  8 20:30:08 track vdr: [25609] switching device 1 to channel 3 (JuweloSK)
May  8 20:30:08 track vdr: [25609] timer 3 (3 2030-2100 '@TITLE EPISODE') start
May  8 20:30:08 track vdr: [25609] waiting for EPG info...
May  8 20:30:12 track vdr: [25609] no EPG info available
May  8 20:30:12 track vdr: [25609] record video/@JuweloSK/2017-05-08.20.30.3-0.rec
May  8 20:30:12 track vdr: [25609] creating directory video/@JuweloSK
May  8 20:30:12 track vdr: [25609] creating directory video/@JuweloSK/2017-05-08.20.30.3-0.rec
May  8 20:30:12 track vdr: [25609] permashift: usage of preliminary RAM recording activated
May  8 20:30:12 track vdr: [25609] permashift: starting disk recording of live video to come
May  8 20:30:12 track vdr: [25609] recording to 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00020.ts'
May  8 20:30:12 track vdr: [25609] permashift: starting synchronization phase
May  8 20:30:13 track vdr: [25633] permashift: ending synchronization phase
May  8 20:30:13 track vdr: [25633] Permashift: new file for backwards saving of past video data 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00019.ts'
May  8 20:30:13 track vdr: [25633] permashift: signaling end of synchronization phase
May  8 20:30:13 track vdr: [25760] recording thread started (pid=25609, tid=25760, prio=high)
May  8 20:30:13 track vdr: [25609] permashift: end of synchronization phase acknowledged
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 19928, processed 15040
May  8 20:30:13 track vdr: [25760] Permashift: new file for backwards saving of past video data 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00018.ts'
May  8 20:30:13 track vdr: [25609] replay video/@JuweloSK/2017-05-08.20.30.3-0.rec
May  8 20:30:13 track vdr: [25609] playing 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00001.ts'
May  8 20:30:13 track vdr: [25609] [input_vdr] vdr_flush_engine: stream_start, flush skipped
May  8 20:30:13 track vdr: [25761] dvbplayer thread started (pid=25609, tid=25761, prio=high)
May  8 20:30:13 track vdr: [25762] non blocking file reader thread started (pid=25609, tid=25762, prio=high)
May  8 20:30:13 track vdr: [25761] playing 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00019.ts'
May  8 20:30:13 track vdr: [25761] [xine..put] Detected video size 720x576
May  8 20:30:13 track vdr: [25631] [demux_vdr] PMT changed, resetting demuxer
May  8 20:30:13 track vdr: [25631] [demux_vdr] Skipping new pts 7041172107 (still=1 trickspeed=0)
May  8 20:30:13 track vdr: [25631] [demux_vdr] Skipping new pts 7041172107 (still=1 trickspeed=0)
May  8 20:30:13 track vdr: [25631] [demux_vdr] Skipping new pts 7041172107 (still=1 trickspeed=0)
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 40608, processed 30456
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 112988, processed 84788
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 28200, processed 21244
May  8 20:30:13 track vdr: [25631] [demux_vdr] PMT changed, resetting demuxer
May  8 20:30:13 track vdr: [25761] [xine..put] Detected video size 720x576
May  8 20:30:13 track vdr: [25761] playing 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00018.ts'
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 68244, processed 51324
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 64296, processed 48316
May  8 20:30:13 track vdr: [25760] Permashift saving live buffer: count 105280, processed 78960
May  8 20:30:14 track vdr: [25760] Permashift saving live buffer: count 26320, processed 19740
May  8 20:30:14 track vdr: [25760] Permashift: new file for backwards saving of past video data 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00017.ts'
May  8 20:30:14 track vdr: [25761] playing 'video/@JuweloSK/2017-05-08.20.30.3-0.rec/00017.ts'
May  8 20:30:14 track vdr: [25760] Permashift saving live buffer: count 69748, processed 52452

Alles anzeigen

CKone · 9. Mai 2017

danke für die Meldung mit den Logmeldungen - Hab sie noch gar nicht drin aber wie es scheint das Problem isoliert.

Wenn ich das graphtftng ausmache tritt das geschilderte Verhalten nicht auf, wenn ich auf Pause drücke bleibt das Bild sofort stehen und alles funktioniert wie gewünscht.

Sorry for noise Eike

Christian

Ein Eike · 10. Mai 2017

Kein Problem!

Ich wollte schon länger mal wieder ins Plugin reinschauen.
Seit ich auf EasyVDR und DVB-C/HD umgestellt habe, läuft es bei mir selbst nicht ganz rund.

Bei der Arbeit verwende ich Windows, Visual Studio, ClearCase, ... da ist die Hürde zu Linux, Eclipse CDT, GitHub und co groß.
Vor allem, wenn man's länger nicht gemacht hat.

horchi · 10. Mai 2017

! OFF-Topic !

Zum graphtft-Plugin, das Problem mit den Deadlocks tritt leider an verschiedenen Stellen auf - die Weiterentwicklung nebst portieren zu neuen VDR Versionen habe ich inzwischen eingestellt! Fehler im Zusammenhang mit VDR 2.2.0 sehe ich mir soweit es die Zeit zulässt noch an.

Es wird bald ein Nachfolger geben welchen wir, Dirk (rechner) und ich entwickelt haben. Wenn alles wie geplant läuft gibt es in den nächsten 2-3 Wochen den ersten Release - dann sind die Theme-Entwickler gefragt ;). Das Plugin wird neben dem Ablösen des graphtft -Plugins auch die Anzeige und Bedienung des OSD im WEB ermöglichen, die restlichen Details gibt es dann im Announce Thread beim erscheinen

Viele Grüße Jörg

Permashift und VDR 2.3.4 => blockiert wenn graphtftng aktiv!

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema