[gelöst] headless vdr mit live aufruf von einem anderen Rechner starten

xheinrich · 31. Mai 2015

Ich betreibe seit vielen Jahren einen headless Aufnahmeserver nur für Radiosendungen und bin z.Zt. dabei, die Hardware auf einen Raspeberry umzustellen. Trotz selbstkompilierten vdr 2.1.6 funktioniert das bisher ganz zufriedenstellend. Bisher war es mir egal, dass die Budget-USB-Karte dauernd lief. Nachdem die bisherige Karte ihren Geist nach 5 Jahren aufgegeben hat, probierte ich andere aus, die z.T. ordentlich heizen, auch die PCTV 461e wird gut handwarm. Die erste war mal von Anfang an kaputt und die zweite hält den Dauerbertieb scheinbar nicht durch. Das ist deswegen doof weil ich das Ganze auf dem Dachboden aufstellen möchte, wo es im Sommer mächtig warm wird. Deswegen hätte ich gerne folgendes:

Nach einer Aufnahme beendet sich der vdr von selbst und die Treiber für die Karte werden entladen.
Einmal täglich wird der vdr durch cronjob gestartet um das epg zu aktualisieren (vorher Treiber laden, danach wieder entladen)
rechtzeitig (damit der epg scan durch ist) vor der nächsten Aufnahme wird der vdr wieder gestartet (mit dem at Befehl)
wenn ich von einem remote computer das live plugin anspreche (Port 8008) soll der vdr starten und nach einem timeout sich beenden

Schätze mal, dass dafür ein script nicht reicht...

Das mit dem Beenden nach der Aufnahme uund Starten vor der nächsten Aufnahme ist wahrscheinlich noch die leichteste Übung, denn dafür müsste ich ein shutdown script überarbeiten, also z.B. das hier

Code

echo /usr/local/bin/runvdr | at `/usr/local/bin/amtime.pl -d $(($1 - 60)) +"%R %D"` > /video/atjob 2>&1

Die Aktualisierung des epg müsste ich auch noch hinbekommen, wenngleich dabei zu beachten ist, dass das ausfällt, wenn der vdr schon läuft wegen einer Aufnahme beispielsweise. Leider habe ich keine Ahnung wie ich das mit dem live Aufruf hinbekomme. Über Hinweise dazu würde ich mich sehr freuen, natürlich auch zu den anderen Punkten. Vielleicht hat da jemand schon was fertiges?

mini73 · 31. Mai 2015

Was das Aufwachen wegen EPG-Scan betrifft: sowohl epg2vdr (mit epgd) als auch xmltv2vdr (standalone) kann den vdr in regelmäßigen Intervallen wieder wecken. Das ist in meinen Augen die sinnvollste Alternative. Wobei dabei davon ausgegangen wird, dass der vdr komplett schlafen gelegt wird. Aber das kann man sicherlich durch Umschreiben des Shutdown-Scripts umbiegen auf vdr stoppen/starten.

Wenn es nacher auf dem warmen Dachboden liegen soll: Da stört doch sicherlich nicht ein entsprechender Lüfter, der muss ja nicht flüsterleise, sondern einfach nur leise sein. Ohne "Wind" kann sonst auch dein rpi irgendwann sterben.

Und da du selbstkompilierst: eine Alternative wäre noch dynamite mit entsprechendem Patch für den vdr. Das kann nach einer gewissen Zeit, die die DVB-Devices nicht genutzt werden, diese einfach schließen (ohne Treiber entladen, der vdr läuft weiter). Dadurch greifen meistens auch die Energiesparmaßnahmen in den Treibern und die DVB-Sticks werden "kalt". Vorteil hier ist dann auch, dass live ständig erreichbar ist. Es würde dann ein cronjob reichen, der regelmäßig mal einen EPG-Scan anstößt.

Hat vdr 2.1.6 einen bestimmten Grund oder warum nutzt du nicht vdr 2.2.0?

Lars.

xheinrich · 31. Mai 2015

Das mit dem Lüfter möchte ich vermeiden. Dafür brauchts wieder eine Stromquelle und regelmäßige Funktionskontrolle. Nicht dass Wespen-Hackepeter den Lüfter stoppt. Der Raspi muss nur beim Konvertieren der Aufnahmen in mp3 schwitzen, sonst hat der nicht viel zu überlegen.

Das dynamite plugin schaue ich mir mal an. Schätze aber, das es schwierig ist, das auf meinen Zweck zu adaptieren. Klingt schon so kompliziert, andererseits vielversprechend. Danke für den Hinweis mit epg2vdr!

2.1.6 verwende ich, weil ich mit dem Projekt im Januar angefangen habe, da war das das neueste. Nach dem Kompilieren kam was wichtiges, längerers dazwischen und ich kann das Projekt erst jetzt weiter verfolgen. Aber jetzt würde ich es gern weiter verfolgen und natürlich erfolgreich abschließen.

Nachtrag: dynamite schaut doch nicht so kompliziert aus und würde wohl alle Wünsche lösen, aber:
Nachfrage: Der neueste Patch bezieht sich auf vdr 2.0.2, geht der auch für 2.1.6 oder 2.2.0?

mini73 · 1. Juni 2015

Im Prinzip ja, ich wollte die Tage den allerdings mal für 2.2.0 nachreichen. Wird mal Zeit, dass ich das tue.
Wenn du dich auch nicht um andere Patches selbst kümmern möchtest, dann kann ich dir nur empfehlen, dir mal die Pakete im ppa:yavdr/unstable-vdr anzusehen. Wenn du Debian-Pakete lokal nachbauen kannst, hättest du da einen aktiv gepflegten vdr inkl. patchset. Die passenden Plugins findest du dort auch als Pakete.

Lars

sh4 · 1. Juni 2015

Zitat von xheinrich

Nachfrage: Der neueste Patch bezieht sich auf vdr 2.0.2, geht der auch für 2.1.6 oder 2.2.0?

Das wäre exakt meine Frage gewesen

xheinrich · 1. Juni 2015

Zitat von mini73

Im Prinzip ja, ich wollte die Tage den allerdings mal für 2.2.0 nachreichen. Wird mal Zeit, dass ich das tue.

Dann warte ich das mal lieber ab. Möchte kein Kuddelmuddel mit einem verpatchten vdr

xheinrich · 2. Juni 2015

Für 2.1.6 geht der für 2.0.2 vorgehsene Patch jedenfalls nicht

Code

root@raspivdr:/usr/local/src/vdr# patch < vdr-2.0.2-dynamite+externalci+extravideodirs+rotorng.patch
patching file ci.c
Hunk #1 FAILED at 1571.
1 out of 1 hunk FAILED -- saving rejects to file ci.c.rej
patching file ci.h
Hunk #2 FAILED at 116.
1 out of 2 hunks FAILED -- saving rejects to file ci.h.rej
patching file device.c
Hunk #3 FAILED at 132.
Hunk #4 succeeded at 172 (offset 2 lines).
Hunk #5 FAILED at 372.
Hunk #6 succeeded at 581 (offset -3 lines).
Hunk #7 succeeded at 596 (offset -3 lines).
Hunk #8 succeeded at 631 (offset -3 lines).
Hunk #9 succeeded at 811 (offset 5 lines).
Hunk #10 succeeded at 859 (offset 6 lines).
Hunk #11 succeeded at 1260 (offset 6 lines).
Hunk #12 succeeded at 1282 (offset 6 lines).
Hunk #13 succeeded at 1303 (offset 6 lines).
Hunk #14 succeeded at 1585 (offset 6 lines).
Hunk #15 succeeded at 1605 (offset 6 lines).
Hunk #16 succeeded at 1688 (offset 7 lines).
Hunk #17 succeeded at 1733 (offset 7 lines).
Hunk #18 succeeded at 1764 (offset 11 lines).
Hunk #19 succeeded at 1858 with fuzz 2 (offset 19 lines).
2 out of 19 hunks FAILED -- saving rejects to file device.c.rej
patching file device.h
Hunk #1 succeeded at 25 (offset 1 line).
Hunk #2 succeeded at 175 (offset 5 lines).
Hunk #3 FAILED at 196.
Hunk #4 succeeded at 348 (offset 10 lines).
Hunk #5 succeeded at 434 (offset 10 lines).
Hunk #6 succeeded at 602 (offset 18 lines).
Hunk #7 succeeded at 816 (offset 19 lines).
Hunk #8 succeeded at 858 (offset 19 lines).
Hunk #9 FAILED at 855.
usw. usf.

Alles anzeigen

In dem README wären noch Hinweise zur Installation ganz hilfreich.

Heinrich

mini73 · 3. Juni 2015

Jupp, ich setze mich heute Abend dran...

Lars

mini73 · 3. Juni 2015

Hier ist der dynamite-Patch für den vanilla vdr 2.2.0:
https://github.com/flensrocker…s/vdr-2.2.0-dynamite.diff

Lars.

xheinrich · 4. Juni 2015

Vielen Dank, Lars! Da muss ich mir erstmal den vdr 2.2.0 runterladen... wird aber die nächsten Tage dauern, da Kurzurlaub. Melde mich zurück, sobald ich das ausprobiert habe. Nochmals Danke für deine Mühe!

Heinrich

xheinrich · 7. Juni 2015

Der Pach für vdr 2.2.0 lief problemlos durch. Aber ich hab ein Problem beim kompilieren (make plugins):

Code

*** Plugin dynamite:
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"dynamite"' -I/usr/local/src/vdr-2.2.0/include  -o dynamite.o dynamite.c
In file included from dynamite.c:9:0:
/usr/local/src/vdr-2.2.0/include/vdr/device.h:703:16: error: ‘virtual void cDevice::TrickSpeed(int, bool)’ was hidden [-Werror=overloaded-virtual]
dynamicdevice.h:156:16: error:   by ‘virtual void cDynamicDevice::TrickSpeed(int)’ [-Werror=overloaded-virtual]
dynamite.c: In member function ‘virtual bool cDynamiteDvbDeviceProbe::Probe(int, int)’:
dynamite.c:26:8: error: ‘MAXDVBDEVICES’ was not declared in this scope
cc1plus: some warnings being treated as errors
Makefile:70: recipe for target 'dynamite.o' failed
make[1]: *** [dynamite.o] Error 1

Das übersteigt leider meine Fähigkeiten... kann jemand helfen?

Heinrich

xheinrich · 7. Juni 2015

Das mit den

Code

MAXDVBDEVICES

konnte ich direkt im Quelltext in MAXDEVICES

ändern, der Fehler war dann weg. Der Rest nicht

mini73 · 7. Juni 2015

Welche Version von dynamite nutzt du denn? Nimm am besten den aktuellen git snapshot.
https://github.com/flensrocker/vdr-plugin-dynamite

Lars

xheinrich · 7. Juni 2015

Antworte mal selber, auch wenn das nicht gern gesehen ist. Habe hier im Forum gesehen, dass das softhddevice plugin vor einiger Zeit ein ähnliches Problem hatte. Es hängt damit zusammen, dass TrickSpeed einen weiteren Parameter dazu bekommen hat: http://projects.vdr-developer.org/issues/1667

Habe dann in den Dateien dynamicdevice.c und dynamicdevice.h die entsprechenden Änderungen vorgenommen

Code

TrickSpeed(int Speed, bool Forward)

und das Plugin hat zumindest ohne weitere Fehler compiliert. Jetzt werde ich das ganze mal laufen lassen und beobachten.

Heinrich

xheinrich · 7. Juni 2015

Zitat von mini73

Welche Version von dynamite nutzt du denn? Nimm am besten den aktuellen git snapshot.
Welche Version von dynamite nutzt du denn? Nimm am besten den aktuellen git snapshot.
https://github.com/flensrocker/vdr-plugin-dynamite

Lars
Jo, das hatte ich mir gestern Abend per git gezogen.

Heinrich

xheinrich · 7. Juni 2015

nächstes Problem, wie gesagt der Compile lief ohne errors / warnings durch

Code

vdr: /usr/local/lib/vdr/libvdr-dynamite.so.2.2.0: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden

Beim Ziehen des git kam übrigens gestern der neue patch nicht durch?? Musste den von Hand kopieren... Steht im Verzeichnis auf git drin???

Heinrich

xheinrich · 7. Juni 2015

Sorry, dämlicher Fehler. Hatte vergessen, das Make.config zu erstellen
Melde mich morgen wieder, denn das Compilen läuft auf dem Raspi etwas langsam...

Heinrich

mini73 · 8. Juni 2015

Hm, irgendwie komme ich nicht von dem Gedanken weg, dass du eine alte Version von dynamite da liegen hast. Die TrickSpeed Änderung ist drin.
https://github.com/flensrocker…ster/dynamicdevice.h#L159

Sicher dir dein bisheriges Verzeichnis doch mal weg und mache einen frischen Klon:

Code

git clone https://github.com/flensrocker/vdr-plugin-dynamite.git

Lars

xheinrich · 8. Juni 2015

Tja, du hast recht. Ich hatte mir das Plugin mit dem Befehl

Code

git clone git://projects.vdr-developer.org/vdr-plugin-dynamite.git

geholt. Steht so im README auf deiner github Seite. Wenn ich es so mache, wie du empfohlen hast, stimmt das mit dem TrickSpee, die MAXDVBDEVICES ziemlich an Anfang von dynamite.c müssten aber noch ersetzt werden, damit es fehlerlos durchläuft. Ich lass für den Test mal alles beim alten, denn der Compiler lief ja durch.

Im Log sehe ich ziemlich viele Einträge wegen suspendoutput:

Code

...
Jun  8 09:51:19 raspivdr vdr: [2164] [live] ERROR: Unable to load cert/key (/var/lib/vdr/plugins/live/live.pem//var/lib/vdr/plugins/live/live-key.pem): Datei oder Verzeichnis nicht gefunden
Jun  8 09:51:19 raspivdr vdr: [2158] epg data reader thread ended (pid=2136, tid=2158)
Jun  8 09:51:20 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:54:07 raspivdr vdr: [2136] switching to channel 1 (1LIVE)
Jun  8 09:54:07 raspivdr vdr: [2136] retrying
Jun  8 09:54:07 raspivdr vdr: [2136] retrying
Jun  8 09:54:07 raspivdr vdr: [2136] retrying
Jun  8 09:54:07 raspivdr vdr: [2136] setting watchdog timer to 60 seconds
Jun  8 09:54:07 raspivdr vdr: [2136] OSD size changed to 720x480 @ 1
Jun  8 09:54:07 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:54:07 raspivdr vdr: [2163] EPGSearch: timer conflict check started
Jun  8 09:54:07 raspivdr vdr: [2163] EPGSearch: timer conflict check finished
Jun  8 09:54:08 raspivdr vdr: [2136] max. latency time 1 seconds
Jun  8 09:54:12 raspivdr vdr: [2136] dynamite: no devices within 60 seconds for receiving startup channel 1, giving up
Jun  8 09:55:08 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 09:55:08 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 09:55:08 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:55:08 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 09:55:10 raspivdr vdr: [2136] max. latency time 3 seconds
Jun  8 09:56:09 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 09:56:09 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 09:56:09 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:56:09 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 09:56:41 raspivdr vdr: [2136] dynamite: device /dev/dvb/adapter0/frontend0 unused for 5 minutes, set to idle
Jun  8 09:56:41 raspivdr vdr: [2136] dynamite: set device /dev/dvb/adapter0/frontend0 to idle
Jun  8 09:56:41 raspivdr vdr: [2161] device 1 section handler thread ended (pid=2136, tid=2161)
Jun  8 09:57:10 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 09:57:10 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 09:57:10 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:57:10 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 09:58:11 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 09:58:11 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 09:58:11 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:58:11 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 09:59:12 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 09:59:12 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 09:59:12 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 09:59:12 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 10:00:13 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 10:00:13 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 10:00:13 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 10:00:13 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 10:01:14 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 10:01:14 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 10:01:14 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 10:01:14 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 10:01:19 raspivdr vdr: [2174] epg data writer thread started (pid=2136, tid=2174, prio=low)
Jun  8 10:01:20 raspivdr vdr: [2174] epg data writer thread ended (pid=2136, tid=2174)
Jun  8 10:02:15 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 10:02:15 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 10:02:15 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 10:02:15 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 10:03:16 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 10:03:16 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
Jun  8 10:03:16 raspivdr vdr: [2136] ERROR: no OSD provider available - using dummy OSD!
Jun  8 10:03:16 raspivdr vdr: [2136] suspendoutput: output resumed by user action
Jun  8 10:04:17 raspivdr vdr: [2136] suspendoutput: output suspended by inactivity timer
Jun  8 10:04:17 raspivdr vdr: [2136] ERROR: Kanal blockiert (zeichnet auf)!
usw.

Alles anzeigen

Ist das Verhalten normal? (Natürlich wird nix aufgezeichnet) Brauche ich das suspendoutput wirklich?

Beim dummydevice plugin - was vielleicht eine Alternative wäre? - steht:

Zitat

Für vdr 1.4.x ist das Plugin zwar empfohlen aber nicht zwingend
notwendig. Ohne dummydevice wird einfach eine der Budget Karten zum
Ausgabegerät erklärt, auch wenn tatsächlich nichts ausgeben werden kann.

Heinrich

mini73 · 8. Juni 2015

Entweder dummydevice+suspendoutput oder ganz ohne die beiden. Das sollte eigentlich auch gehen.
dummydevice wird nur dann benötigt, wenn man den Server auch auf bestimmt Kanäle tunen möchte, weil man da irgendwas mit machen muss/möchte. Sollte für dich keine Rolle spielen.

Lars.

[gelöst] headless vdr mit live aufruf von einem anderen Rechner starten

Jetzt mitmachen!

Teilen