[Announce] Permashift Version 1.0.1

CKone · 10. Februar 2015

ich hab jetzt den aktuellen Permashift Patch in yavdr mit vdr 2.1.9 integriert und das Verhalten ist genauso wie schon in vdr 2.0.6 mit dem alten Patch geschildert:

Funktion einwandfrei aber ~80 CPU, also quasi nicht wirklich praktisch zu benutzen. Das Ganze auf zwei VDR auch bei einem anderen User nachvollziehbar, mit oder ohne plugins.

Hast du hier noch eine Idee zu?

Christian

Ein Eike · 10. Februar 2015

Ok, du bist hartnäckig.

Ich hab es gerade noch einmal ausprobiert auf meinem Desktop-Rechner und auf dem Wohnzimmer-Celeron (2% Last!), und auf beiden ist die Last sehr friedlich, sobald der RAM-Buffer fertig gespeichert ist. Beschreib mal, was genau du testest, mit welchen Permashift-Einstellungen und auf welcher Hardware. Und bitte Tests nur mit Vanilla-VDR- Permashift und ggf. Plugins, die unbedingt notwendig sind (xineoutput o. ä.)

CKone · 10. Februar 2015

eingestellt sind 2Gb Ram, ich warte 10 min damit ich was im Cache hab und spule dann zurück. Dann bin ich in der Wiedergabe einer ganz gewöhnlichen Aufnahme mit besagtem Verhalten.

In yavdr mit 2.1.9 ist ja gar nicht mehr viel drin mit patchen, Mini sei Dank. Plugins hab ich alle rausgeworfen ausser softhddev.`- ~~wenn ich nicht mit Rücklauf sondern mit Pause einsteige ist auch alles gut.~~ Korrigiere, ist genau dasselbe Verhalten...

HW: beide VDR aus der Signature intel celeron und auch athlon X2, Test mit vanilla vdr ist nicht so einfach auf die Schelle.

Willst du evtl ein paar Log,meldungen einbauen zu sehen welcher deiner Prozesse das macht?

Ein Eike · 10. Februar 2015

Zitat von CKone

eingestellt sind 2Gb Ram, ich warte 10 min damit ich was im Cache hab

Vor den 10 Minuten umschalten (oder VDR frisch gestartet haben, aber umschalten reicht) könnte gut sein. Dann ist der Puffer sicher nicht zu groß.

Zitat von CKone

Dann bin ich in der Wiedergabe einer ganz gewöhnlichen Aufnahme mit besagtem Verhalten.

Und der Puffer ist dann fertig geespeichert (=> Syslog)?

Zitat von CKone

Willst du evtl ein paar Log,meldungen einbauen zu sehen welcher deiner Prozesse das macht?

Ich weiß noch gar nicht, was ich da ausgeben könnte, aber ich denk mal drüber nach...

CKone · 12. Februar 2015

Also unter gen2vdr gibt es das Problem nicht wir mir berichtet wurde: was die anders machen ist das die nicht wie yavdr precise libav nutzen sondern ffmpeg. Mit was testest du hier?

Ich werde das die nächsten Tage genau testen, ohne Patche und ohne Plugins würde dann ja nur noch livbav bleiben...

Christian

mini73 · 12. Februar 2015

Ein Eike hat eine PVR350 für die Ausgabe, d.h. weder ffmpeg noch libav.

Lars.

Ein Eike · 12. Februar 2015

... und auf dem Desktoprechner läuft xineliboutput.

CKone · 13. Februar 2015

Zitat von Ein Eike

Und der Puffer ist dann fertig geespeichert (=> Syslog)?

also das Problem tritt auch mit dem yavdr quasi ungepatched auf, nur mit permashift und softhddev Plugins aktiv - gerade mit 2.1.10 nachvollzogen auf "Das Erste HD"

Was mir hier auffällt: im Syslog find ich da nix, nach was kann ich genau greppen?

Christian

Ein Eike · 13. Februar 2015

Zitat von CKone

Was mir hier auffällt: im Syslog find ich da nix, nach was kann ich genau greppen?

Das sieht so aus.

Code

vdr: [5890] writing... video/@zibb_zuhause_in_berlin_&_brandenburg/2015-02-10.18.58.12-0.rec/00002.ts
vdr: [5890] writing... video/@zibb_zuhause_in_berlin_&_brandenburg/2015-02-10.18.58.12-0.rec/00001.ts

Wenn die Datei 00001.ts der jeweiligen Sendung geschrieben wurde, sollte es (kurz darauf) fertig sein.

CKone · 13. Februar 2015

aber während er das wegschreibt macht er bei dirtrotzdem nicht son Alarm und läuft entspannt weiter?

ich probiere das dann später oder morgen noch mal

Ein Eike · 13. Februar 2015

Zitat von CKone

aber während er das wegschreibt macht er bei dirtrotzdem nicht son Alarm und läuft entspannt weiter?l

Während des Wegschreibens kann schon mehr Alarm sein. Das macht er so schnell wie möglich.

Ein Eike · 14. Februar 2015

Ich habe übrigens auf Github einen Patch für VDR Version 2.2 bereitgelegt: https://github.com/eikesauer/Permashift

Die nächsten Wochen werde ich nicht allzuviel Zeit haben, mich um Permashift zu kümmern.
Ich würde mich aber freuen, wenn wir das mit der CPU-Belastung geklärt kriegen.

CKone · 3. März 2015

noch mal zurück:

Code

Mar  3 19:50:04 CKone vdr: [1248] loading plugin: /usr/lib/vdr/plugins/libvdr-permashift.so.2.2.0
Mar  3 19:50:05 CKone vdr: [1248] initializing plugin: permashift (1.0.1): Live-TV automatisch aufnehmen
Mar  3 19:50:05 CKone vdr: [1248] starting plugin: permashift
Mar  3 19:52:18 CKone vdr: [1844] permashift: 100 MB live video data in buffer
Mar  3 19:53:55 CKone vdr: [1844] permashift: 200 MB live video data in buffer
Mar  3 19:56:00 CKone vdr: [1844] permashift: 300 MB live video data in buffer
Mar  3 19:57:22 CKone vdr: [1844] permashift: 400 MB live video data in buffer
Mar  3 19:58:44 CKone vdr: [1844] permashift: 500 MB live video data in buffer
Mar  3 20:00:12 CKone vdr: [1844] permashift: 600 MB live video data in buffer
Mar  3 20:01:20 CKone vdr: [1844] permashift: 700 MB live video data in buffer
Mar  3 20:02:28 CKone vdr: [1844] permashift: 800 MB live video data in buffer
Mar  3 20:03:36 CKone vdr: [1844] permashift: 900 MB live video data in buffer
Mar  3 20:03:40 CKone vdr: [1844] permashift: starting file recording


Mar  3 20:03:40 CKone vdr: [1844] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00018.ts
Mar  3 20:03:40 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00017.ts
Mar  3 20:03:41 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00016.ts
Mar  3 20:03:41 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00015.ts
Mar  3 20:03:42 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00014.ts
Mar  3 20:03:43 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00013.ts
Mar  3 20:03:43 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00012.ts
Mar  3 20:03:44 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00011.ts
Mar  3 20:03:45 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00010.ts
Mar  3 20:03:45 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00009.ts
Mar  3 20:03:46 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00008.ts
Mar  3 20:03:46 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00007.ts
Mar  3 20:03:47 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00006.ts
Mar  3 20:03:47 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00005.ts
Mar  3 20:03:48 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00004.ts
Mar  3 20:03:49 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00003.ts
Mar  3 20:03:49 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00002.ts
Mar  3 20:03:50 CKone vdr: [2634] writing... /srv/vdr/video.00/local/@Tagesschau_Nachrichten_(D_2015)/2015-03-03.20.03.1-0.rec/00001.ts

Alles anzeigen

er schreibt das in der Tat in 10s auf die SSD, das Load geht dann auch von 100 auf 70 zurück - da bleibt es leider für immre stehen

Funktionieren tut es wirklich tadellos, ansonsten.

Einen plain vdr zu testen ist leider nicht so trivial auf ner Distri.

Christian

theblackraven · 15. März 2015

Hi,

benutze zur Zeit gen2vdr v5 und das neuste Permashift Plugin.

Bekomme gelegentlich folgende Fehlermeldung in den /var/log/messages

Mar 15 18:27:49 [vdr] [3132] confirmed
Mar 15 18:27:49 [vdr] [3132] executing '/_config/bin/vdrshutdown 0 0 0 "" 1'
Mar 15 18:27:49 [vdr] [3132] ERROR (thread.c,564): Nicht genügend Hauptspeicher verfügbar

Auf Grund diesem Fehlers beendet sich das Shutdownscript und der Rechner fährt nicht runter...

Laut top ist aber noch genug Hauptspeicher verfügbar.

KiB Mem: 8100952 total, 6175700 used, 1925252 free, 171948 buffers

KiB Swap: 0 total, 0 used, 0 free. 247472 cached Mem

Ich weiß leider nicht, ob dies an deinem Plugin liegt oder am shutdown script, da der Fehler wirklich nur sporadisch auftritt. Hat noch jemand anderes dieses Problem?

Ein Eike · 17. März 2015

Das scheint von hier zu kommen:

559 int SystemExec(const char *Command, bool Detached)
560 {
561 pid_t pid;
562
563 if ((pid = fork()) < 0) { // fork failed
564 LOG_ERROR;
565 return -1;
566 }

Da will etwas einen Systemaufruf absetzen und das gelingt nicht.
Wenn du an der Stelle das Kommando ausgeben würdest (wäre wohl auch eine sinnvolle VDR-Änderung), könnte man mehr erfahren:

Code

dsyslog("%s", Command);

... vor dem LOG_ERROR sollte das tun.

Und ich sach' schon mal: Permashift ist unschuldig! :o)

Ein Eike · 5. April 2015

Zitat von CKone

er schreibt das in der Tat in 10s auf die SSD, das Load geht dann auch von 100 auf 70 zurück - da bleibt es leider für immre stehen

Kannst du mal folgendes probieren?

In bufferreceiver.c, etwa Zeile 350, kommt eine Logzeile dazu:

Code

if (m_bufferWriter->Finished())
{
	dsyslog("Permashift live buffer fully saved.");
	delete m_ringBuffer;
	m_ringBuffer = NULL;
}

Wenn du zurückspulst, und genug Video im RAM ist für mindestens zwei TS-Teilstücke, bekommst du dann die Meldung "fully saved"?

blau-sls · 25. April 2015

Zitat von Ein Eike
Da will etwas einen Systemaufruf absetzen und das gelingt nicht.
Wenn du an der Stelle das Kommando ausgeben würdest (wäre wohl auch eine sinnvolle VDR-Änderung), könnte man mehr erfahren:
Code
dsyslog("%s", Command);
... vor dem LOG_ERROR sollte das tun.

Und ich sach' schon mal: Permashift ist unschuldig! :o)

Hallo Eike,

zunächst mal vielen Dank für Dein tolles Plugin! Ist bei uns seit einigen Monaten im täglichen Einsatz und wir möchten es nicht mehr missen.

Allerdings hatte ich in der Vergangenheit auch öfter Mal das Problem, dass sich der VDR wegen Speichermangel nicht mehr ausschalten ließ. Diese Woche hab ich die Ursache herausgefunden und muss Dir leider mitteilen, dass - zumindest bei mir - da doch ein Fehler in Permashift die Ursache war.

Da ich keine Signatur habe: Ich benutze ein 32-Bit Ubuntu-Precise und baue meinen VDR aus den yavdr-Quellpaketen selbst. Darin eingebaut habe ich Dein Permashift-1.0.0. Mein System hat 3 DVB-Receiver.

Der Fehler passiert bei mir folgendermaßen:

Ich schaue Live. Dabei benutzt VDR device 3 und im receiver thread ist ein Ringbuffer eingehängt, auf den m_bufferReceiver zeigt.
Dann benutze ich permashift, um live zurückzuspoolen, und gehe irgendwann aus dem Abspielen dieser Aufnahme wieder raus, ohne die Aufnahme zu beenden
Wenn ich anschließend, während die Aufnahme noch läuft, live auf ein Programm auf einem anderen Transponder schalte, startet VDR einen receiver thread auf device 1 (device 3 braucht er ja für die Aufnahme) und permashift legt einen neuen Ringbuffer an, auf den m_bufferReceiver zeigt.
Irgendwann endet die oben gestartete Aufnahme. Dabei ruft das darin eingehängte bufferReceiver-Objekt die Funktion BufferDeleted auf.
Damit wird m_bufferReceiver auf NULL gesetzt. Und das ist falsch, denn m_bufferReciever ist ja inzwischen eigentlich für den Ringbuffer in device 1 zuständig
Schalte ich nun wieder auf einen anderen Transponder, benutzt VDR wieder einen receiver thread auf device 3 und würde normalerweise den receiver thread für device 1 beenden.
Da jedoch m_bufferReceiver auf NULL gesetzt wurde, wird der Ringbuffer für device 1 nicht angehalten und deshalb beendet sich der receiver thread auf device 1 auch nicht.

Langer Rede kurzer Sinn: BufferDeleted darf m_bufferReceiver nur dann auf NULL setzen, wenn die Funktion von dem Objekt aufgerufen wurde, auf die m_bufferReceiver auch zeigt. Das kann man mit folgendem kleinen Patch erreichen:

Diff

diff -rupN permashift-1.0.0.org/bufferreceiver.c permashift-1.0.0/bufferreceiver.c
--- permashift-1.0.0.org/bufferreceiver.c   	2014-07-30 13:48:39.000000000 +0200
+++ permashift-1.0.0/bufferreceiver.c   2015-04-25 12:37:42.000000000 +0200
@@ -38,7 +38,7 @@ cBufferReceiver::~cBufferReceiver()


    	if (m_owner != NULL)
    	{
-           	m_owner->BufferDeleted();
+           	m_owner->BufferDeleted(this);
    	}
    	if (m_bufferWriter != NULL)
    	{
diff -rupN permashift-1.0.0.org/permashift.c permashift-1.0.0/permashift.c
--- permashift-1.0.0.org/permashift.c   2014-08-16 13:25:00.000000000 +0200
+++ permashift-1.0.0/permashift.c   	2015-04-25 12:47:39.000000000 +0200
@@ -170,10 +170,13 @@ bool cPluginPermashift::StopLiveRecordin
    	return true;
 }


-void cPluginPermashift::BufferDeleted()
+void cPluginPermashift::BufferDeleted(cBufferReceiver* callingReceiver)
 {
    	// our buffer is about to be deleted by other means
-   	m_bufferReceiver = NULL;
+   	if (m_bufferReceiver == callingReceiver)
+   	{
+           	m_bufferReceiver = NULL;
+   	}
 }


 cMenuSetupPage *cPluginPermashift::SetupMenu(void)
diff -rupN permashift-1.0.0.org/permashift.h permashift-1.0.0/permashift.h
--- permashift-1.0.0.org/permashift.h   2014-05-24 17:44:06.000000000 +0200
+++ permashift-1.0.0/permashift.h   	2015-04-25 12:35:41.000000000 +0200
@@ -75,7 +75,7 @@ public:
    	bool StopLiveRecording(void);


    	/// our buffer tells us that it's gone
-   	void BufferDeleted();
+   	void BufferDeleted(cBufferReceiver* callingReceiver);


    	/// status callback
    	void ChannelSwitch(const cDevice *device, int channelNumber, bool liveView);

Alles anzeigen

Damit läufts bei mir nun seit 3 Tagen intensiven Testens, ohne dass nochmal Speichermangel gemeldet wurde.

Gruß
Rainer

mini73 · 25. April 2015

Bester erster Beitrag, den ich je gelesen hab!

Lars

Ein Eike · 25. April 2015

Was soll ich da sagen...

Erstmal, ich nehme das zurück - und behaupte vorsorglich das Gegenteil. ;o)

Zitat von ein eike

Und ich sach' schon mal: Permashift ist unschuldig! :o)

... und dann...

Zitat von blau-sls

Langer Rede kurzer Sinn: BufferDeleted darf m_bufferReceiver nur dann auf NULL setzen, wenn die Funktion von dem Objekt aufgerufen wurde, auf die m_bufferReceiver auch zeigt. Das kann man mit folgendem kleinen Patch erreichen:

Vielen Dank für die präzise Fehlermeldung, für die Analyse und für die Korrektur.

Ich werd das wohl direkt in eine neue Version münden lassen.

Ein Eike · 25. April 2015

Ich habe die korrigierte Version auf Git gelegt und bei mir installiert.
Wenn nicht bald was abstürzt, wird es so veröffentlicht.
Das war die perfekte Fehlermeldung...

[Announce] Permashift Version 1.0.1

Jetzt mitmachen!

Teilen

Tags