You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Tuesday, November 29th 2011, 5:18pm

[XBMC Addon] Powersave für VDR

Ich habe dieser Tage, beim "basteln" verblüfft festgestellt dass das ION-330 Board meines Media-Rechners einwandfrei in den S3 Suspend-Mode ging und auch wieder daraus aufwachte. Da ich VDR sehr gerne mit Suchtimern als Backend, und XBMC als Frontend nutze lag nahe Powersave einzurichten. Allerdings gab es da so einige Hindernisse, die Features von VDR fallen diesbezüglich flach, die von XBMC sind noch nicht wirklich befriedigend. Im XVDR Client gibt es wohl Ansätze, die mit meiner persönlichen Nutzung aber nicht wirklich gut zusammenpassen. Also habe ich mich entschlossen selbst ein XBMC-Addon zu schreiben. Es ist nicht nur mein erstes Addon, es ist auch mein erstes umfassendes Python-Projekt.

Das Addon findet sich im Dateianhang, frei zum Download, und natürlich darf sich nach belieben an Code und Ideen bedient werden. Dafür ist es ja Open Source ;D

Es läuft nicht völlig "Out of the Box", natürlich muss aufwachen nach Alarmzeit bei euch bereits Funktionieren, und über ein Script ansprechbar sein. Infos zu Funktion und Einrichtung finden sich im "Änderungen"-Bereich des Addons. Dafür läuft es unabhängig vom PVR-Client, es ist also egal ob ihr XVDR oder noch VNSI einsetzt, und in welcher Version.

Die Kommunikation zu VDR erfolgt über SVDRP. Es harmoniert mit anderen Programmen wie vdradmin-am, denn die Zugriffe auf SVDRP sind immer sehr kurz. Eine Einschränkung ist, das ich keinen Weg gefunden habe das VDR-Backend auf externes Streaming zu prüfen. Jegliches abspielen von Medien an XBMC wird natürlich erkannt, streamt man sein TV-Programm stattdessen an den Rechner, ist das nicht von Leerlauf zu unterscheiden. Vielleicht kennt ja von euch jemand einen Weg über SVDRP an die Anzahl der aktiven Clients zu kommen.

Ich veröffentliche dieses Addon erst mal exklusiv hier, und falls es sich bewährt vielleicht auch im XBMC-Forum. Anregungen und Bug-Meldungen werden natürlich immer gerne genommen. Viel Spaß!
Telperiar has attached the following file:
Hardware: Point of View ION/ATOM330, 2GB, 160GB (Lokal), 2TB über NFS, Hauppauge Nova-T Stick (2040:7070), SoundGraph IMON (15c2:0036 VFD)
System: Debian Squeeze, Kernel 3.1.2 (self build), Nvidia 285.05.09, lcdproc 0.5.5, lirc 0.9.0
VDR: vdr 1.7.21 (etobi) + xvdr (git), xineliboutput, markad
XBMC: opdenkamp PVR branch (git)

gda

Im Forum Zuhause

Posts: 13,180

Location: HH

  • Send private message

2

Tuesday, November 29th 2011, 5:51pm

Sehr interessant!

Gerald

HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 12.04.2, Plex Media Server
Zbox HD-ID40, OpenELEC 4.0.2, PLEXBMC

BJ1

Master

Posts: 2,070

Location: Sachsen

  • Send private message

3

Tuesday, November 29th 2011, 9:10pm

:tup

Ich finde es sehr gut, dass für die 'XBMC-Frontend-User' mal was in der Richtung entwickelt wird. So gibt's endlich mal eine vernünftige Trennung zwischen Back- und Frontend und dazu noch "Best of both worlds".

BJ1

meine Hardware

Produktiv/Testsystem/Datengrab (AZi): XBMCBuntu auf 14.04 LTS, TVHeadend | Asrock H61, Intel Celeron, HDMI über Asus GT610 | 2 GB 1066 RAM | 2,5" 100GB (System + Aufnahme), 3xWD EARX 2 TB SATA II + 1x Samsung 2 TB SATA II, mhddfs | Triple DVB-C (Digital Devices Cine CT + Satelco Easywatch DVB-C) | Atric IR Rev.5 | Silverstone LC10
Produktiv (WoZi): XBMCBuntu auf 14.04 LTS, TVHeadend | MSI C847MS-E33 | 1GB 1333 RAM | 8 GB CF-Card System + WD 1TB Daten | DD DVB-C/T Dualtuner | Atric IR Rev.5 + Logitech Harmony 300

4

Sunday, April 7th 2013, 6:57pm

ich grabe diesen Thread mal wieder aus, da ich mich aktuell genau mit dieser Thematik - powersaveing in XBMC+VDR - beschäftige; wurde im XBMC Forum auf diesen Thread "geschubst".

Das Addon funktioniert bei mir bestens, auch noch unter dem aktuellen Frodo XBMC 12.1.

Zwei Fragen / Anregungen hätte ich da noch:
-> Wenn ich mir die Funktionsweise des Addons so ansehe, gehe ich richtig in der Annahme, dass es hiermit nicht möglich ist, ein über die "S" Taste ausgelöstet "PowerOff" des Systems abzubrechen, wenn eine Aufnahme in VDR läuft? Zur Zeit fährt XBMC in dem Fall gnadenlos herunter, auch wenn gerade eine Aufnahme aktiv ist....

-> Bzgl. des Netzwerk Idles: Ich benutze in VDR den streamdev-server und auf diversen Androiden AndroVDR, um Live-TV übers Netz auf eben diesen zu schauen, was bestens funktioniert. Könnte man nun nicht per "einfachem" netstat ermitteln, dass auf den Streamdev-Server Ports (3000 / 2004) zur Zeit Geräte verbunden (CONNECTED) sind und aufgrund dessen den Idle TImer "anhalten?

5

Sunday, April 7th 2013, 7:04pm

Könnte man nun nicht per "einfachem" netstat ermitteln, dass auf den Streamdev-Server Ports (3000 / 2004) zur Zeit Geräte verbunden (CONNECTED) sind und aufgrund dessen den Idle TImer "anhalten?

Das ist halt unpraktisch, weil man ständig pollen muss...
Meine Addon-Lösung für yaVDR (ich hab mir einiges von Telperiars Addon abgeschaut) kann den Shutdown abfangen, wenn XBMC beendet wird - es bietet sich an den Shutdown nicht direkt von XBMC durchführen zu lassen (stattdessen den Exit-Code auswerten, dann den VDR zu fragen, ob gerade ein Plugin oder eine Aufnahme aktiv ist) und dem VDR das Ausschalten zu überlassen.
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

6

Monday, April 8th 2013, 3:31pm

Könnte man nun nicht per "einfachem" netstat ermitteln, dass auf den Streamdev-Server Ports (3000 / 2004) zur Zeit Geräte verbunden (CONNECTED) sind und aufgrund dessen den Idle TImer "anhalten?

Das ist halt unpraktisch, weil man ständig pollen muss...
Meine Addon-Lösung für yaVDR (ich hab mir einiges von Telperiars Addon abgeschaut) kann den Shutdown abfangen, wenn XBMC beendet wird - es bietet sich an den Shutdown nicht direkt von XBMC durchführen zu lassen (stattdessen den Exit-Code auswerten, dann den VDR zu fragen, ob gerade ein Plugin oder eine Aufnahme aktiv ist) und dem VDR das Ausschalten zu überlassen.

Das Addon von Telperiar pollt ja sowieso ständig (zu sehen an den "Mark" Einträgen im xbmc.log), unter anderem, um Timer-Updates mitzubekommen.
Der Vorteil der netstat Lösung wäre halt, dass der PowerOff nicht nur dann nicht durchgeführt wird, wenn VDR "was dagegen hat", sondern ganz allgemein gerade per Netz auf den HTPC zugegriffen wird (z.B. SMB/NFS Kopieren etc...)
Ich habe das vorhin mal "ganz dreckig" und rudimentär direkt im installierten AddOn implementiert, quasi als "Machbarkeitsstudie" und das scheint zu funzen...

Sollte man wirklich nur XBMC und VDR (zum Zugriff übers Netz) benutzen ist deine Addon-Lösung für VDR definitiv eleganter, diese kann das PowerOff vom XBMC auch dann "verhindern", wenn man im XBMC per "S"-Menü ein PowerOff auslöst, obwohl gerade eine Aufnahme läuft. Aktuell fährt XBMC dann nämlich gnadenlos runter (s.a. mein Post im XBMC Forum, über den ich überhaupt erst auf dieses Addon gestoßen bin ;) : http://forum.xbmc.org/showthread.php?tid=161780)

7

Monday, April 8th 2013, 3:48pm

Der Vorteil der netstat Lösung wäre halt, dass der PowerOff nicht nur dann nicht durchgeführt wird, wenn VDR "was dagegen hat", sondern ganz allgemein gerade per Netz auf den HTPC zugegriffen wird (z.B. SMB/NFS Kopieren etc...)

Wobei ich da einfach die bei den yaVDR bzw. e-Tobi Paketen bestehenden Shutdown-Hooks mit dem Lifeguard-Addon nutze - die machen da letztendlich auch nichts anderes als per netstat nachzufragen (aber eben nur, wenn der VDR selbst keinen Hinderungsgrund für den Shutdown kennt).
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

8

Monday, April 8th 2013, 4:13pm

Der Vorteil der netstat Lösung wäre halt, dass der PowerOff nicht nur dann nicht durchgeführt wird, wenn VDR "was dagegen hat", sondern ganz allgemein gerade per Netz auf den HTPC zugegriffen wird (z.B. SMB/NFS Kopieren etc...)

Wobei ich da einfach die bei den yaVDR bzw. e-Tobi Paketen bestehenden Shutdown-Hooks mit dem Lifeguard-Addon nutze - die machen da letztendlich auch nichts anderes als per netstat nachzufragen (aber eben nur, wenn der VDR selbst keinen Hinderungsgrund für den Shutdown kennt).

hmm... hört sich auch interessant an, werde ich mir mal anschauen... das funzt auch dann, wenn ich in XBMC per "S" menü den PowerOff auslöse? Sprich, maximal beendet sich XBMC, der HTPC aber läuft weiter? (Nutze keine Fernbedienung sondern ne kleine HTPC Tastatur ;) )

9

Monday, April 8th 2013, 4:38pm

Genau - maximal sollte XBMC beendet werden, wenn der VDR noch etwas zu tun hat.
Abgesehen davon, dass du frei wählen kannst, was beim Druck auf die Taste "s" passiert (also z.B. auch ein Addon/Skript aufrufen) ist es in yaVDR so gelöst, dass der Shutdown-Code von XBMC abgefragt wird (0 = Normales Beenden, 990 = Shutdown, 250 = Reboot) und man dann in einem Skript dementsprechend Aktionen anstoßen kann: In yaVDR 0.5 ist das als Upstart-Job umgesetzt, der aufgerufen wird, wenn der Upstart-Job für XBMC beendet wird: http://paste.ubuntu.com/5689564/
Man kann das aber auch in einem normalen Shell-Skript oder einem eigenen Programm aus dem heraus XBMC aufgerufen wird auswerten.
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

10

Monday, April 8th 2013, 6:00pm

hab gerade angefangen, das ganze bei mir umzubauen. Wenn ich das richtig hab, benötigt das yavdr-tools Addon im XBMC das aktuellste dbus2vdr Plugin im VDR, richtig? Habe das aus dem unstable-ppa installiert, was einige VDR Updates nach sich zog (war auf 1.7.41), das Ganze sieht jetzt so aus:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
vdr (2.0.0/2.0.0) - The Video Disk Recorder
conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu
femon (2.0.0) - DVB Signal Information Monitor (OSD)
streamdev-server (0.6.0-git) - VDR Streaming Server
dbus2vdr (8) - control vdr via D-Bus
quickepgsearch (0.0.1) - Quick search for broadcasts
wirbelscan (0.0.7) - DVB and pvrinput channel scan for VDR
live (0.2.0) - Live Interactive VDR Environment
xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin
epgsearch (1.0.1.beta5) - search the EPG for repeats and more
epgsearchonly (0.0.1) - Direct access to epgsearch's search menu
xvdr (0.9.9) - XVDR Server


Wenn ich VDR jetzt starte, ist als letzter Eintrag im Syslog das hier:

vdr: [19405] dbus2vdr: raise SIGSTOP for Upstart

gefällt mir irgendwie nicht ;) VDR macht danach auch nix mehr. Kenne mich noch nicht wirklich mit Upstart aus, bin ein alter init-hase ;)

Wenn ich in der orders.conf das dbus2vdr Plugin deaktivier, funktioniert VDR ohne Probleme

???

11

Monday, April 8th 2013, 6:09pm

vdr: [19405] dbus2vdr: raise SIGSTOP for Upstart

gefällt mir irgendwie nicht VDR macht danach auch nix mehr. Kenne mich noch nicht wirklich mit Upstart aus, bin ein alter init-hase

Das macht nur in der yaVDR-Konstellation Sinn, wenn du den VDR über einen Upstart-Job startet (btw: unstable-vdr ist eine schlechte Idee, testing bringt auch einen VDR 2.0.0 mit und funktioniert zuverlässiger - unstable ist die Spielwiese wo auch mal ein Paket kaputt sein kann).
Die Upstart-Aktvierung kannst du in der /etc/vdr/plugin/plugin.dbus2vdr.conf rausnehmen, Shutdown-Hooks und Shutdown-Wrapper brauchst du aber:

Source code

1
2
3
4
5
6
7
8
9
10
#
# Command line parameters for vdr-plugin-dbus2vdr
#
# For more details see:
#   - /usr/share/doc/vdr-plugin-dbus2vdr/README
#   - `vdr --help -Pdbus2vdr`
--shutdown-hooks=/usr/share/vdr/shutdown-hooks
--shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
#--network
#--upstart

Der Upstart-Job für XBMC sieht übrigens so aus: http://paste.ubuntu.com/5689814/
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

12

Tuesday, April 9th 2013, 1:40pm

Top, das hat geholfen.

Da mein VDR unter einem anderen User als "vdr" läuft (derselbe, der auch per autologin am LXDE incl. Autostart vom XBMC angemeldet wird), mußte ich in der DBUS Config den User ändern, damit VDR auf den Bus zugreifen konnte; nun scheint alles zu klappen, XBMC kommt per DBUS an VDR ran (laut debug out im xbmc.log).

Zur Upstart geschichte:
Ich benutze für den VDR ja "euer" ppa, so dass VDR schon per Upstart gestartet wird:

Source code

1
lrwxrwxrwx 1 root root 21 Apr 5 22:50 vdr -> /lib/init/upstart-job

was fehlt dann noch?

13

Tuesday, April 9th 2013, 1:51pm

Ich benutze für den VDR ja "euer" ppa, so dass VDR schon per Upstart gestartet wird:

Bis du mit testing oder unstable unterwegs?
Der vdr-upstart Job kommt in stable und testing noch nicht aus dem VDR-Paket, sondern aus yavdr-base: https://github.com/yavdr/yavdr-base/blob…c/init/vdr.conf
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

14

Tuesday, April 9th 2013, 1:53pm

Wenn du im dbus2vdr --upstart gesetzt hast, muss du im upstart job expect stop haben, wenn du es nicht gesetzt hast, darfst du kein "expect-stop" drin haben.

Angenommen, du hast --upstart gesetzt:
echo "expect stop" > /etc/init/vdr.override

Das unser Paket in Ubuntu ein Upstart-Job hat, welcher funktioniert ist aber nur ein paar Tage alt :)
VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

15

Tuesday, April 9th 2013, 2:33pm

ok, der eintrag im vdr.override funktioniert, die Meldung

dbus2vdr: raise SIGSTOP for Upstart

taucht zwar immer noch auf, aber daraufhin startet vdr zumindest komplett ... muß mich mal mehr mit DBUS und Upstart beschäftigen, scheint mir...

werde mir in den kommenden tagen auf jeden fall noch eure "komplette" yaVDR distri anschauen; hab leider nur einen einzigen HTPC mit DVB-Karten zum rumprobieren und der wird produktiv im WoZi benutzt... WAF läßt grüßen ;)
Der läuft zur Zeit auf Ubuntu 12.04.2 Minimal/LXDE, VDR aus Euren Repos und XBMC 12.1 aus den offiziellen XBMC Repos ... ach und als Spielerei ist boblight noch dabei *g*

16

Tuesday, April 9th 2013, 2:35pm

axo, vergessen: bin gerade bei euch auf "unstable" und hab dafür schon was auf die finger bekommen ;)

17

Tuesday, April 9th 2013, 3:33pm

Wenn es interessiert:
Dieses --upstart und "expect stop" ist nur ein Mittel um besser zu tracken, wann der VDR fertig ist. "expect stop" sagt upstart, das der Prozess ein "kill SIGSTOP" sendet wenn er soweit fertig ist. dbus2vdr ist das letzte Plugin im VDR und führt dann dieses SIGSTOP aus - damit ist zu 99% sicher das der VDR soweit durch ist mit seiner Initialisierung. Vorher gab es Fälle das Verbindungen auf SVDRP fehlgeschlagen sind, da es noch nicht fertig ist. Nun machen wir solche Befehle zum einen über dbus2vdr und zum anderen erst wenn der VDR wirklich fertig ist. Die Meldung im Log ist ja korrekt - und ein guter Indikator ob es ausgeführt wird.

In Ubuntu sollte dbus2vdr dies aber nicht als default setzen (tut es nicht soll das heissen) - und eine Abhängigkeit zwischen dbus2vdr und vdr möchte man auch nicht, also muss es dort manuell angepasst werden, wenn man es möchte.

Zumindest ein erstes Feedback das unser upstart Job in unstable auf "plain ubuntu" funktioniert :) Gut zu wissen.
VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

18

Tuesday, April 9th 2013, 4:23pm

axo, verstehe... also hat "--upstart" ansonsten keine weiteren funktionaliäten...

falls es interessant für euch ist, hier ist die komplette cmdline, die von eurem Upstart unter Ubuntu mit den von mir benutzten Plugins gebaut wird:

Source code

1
/usr/bin/vdr -v /home/media/rec -c /var/lib/vdr -L /usr/lib/vdr/plugins -r /usr/lib/vdr/vdr-recordingaction -s /usr/lib/vdr/vdr-shutdown.wrapper -E /var/cache/vdr/epg.data -u media -g /tmp --port 2001 --resdir=/usr/share/vdr --cachedir=/var/cache/vdr --dirnames=,,1 -w 60 -P conflictcheckonly -P femon -P streamdev-server -P dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper --upstart -P quickepgsearch -P wirbelscan -P live --port=8008 --ip=0.0.0.0 --log=INFO --epgimages=/var/cache/vdr/epgimages -P xineliboutput --local=none --primary --remote=0.0.0.0:37890 -P epgsearch -P epgsearchonly -P xvdr

19

Tuesday, April 9th 2013, 4:25pm

--port 2001

Wirklich? Das wäre aber nicht im Sinne des Erfinders :schiel
yaVDR-Doku

Meine VDRs

VDR 1: Point of View Ion-330-1 (Intel Atom 330@1,6 GHz). 2GB, 4TB HDD, KNC One DVB-C, Sundtek MediaTV Pro (DVB-C), Atric IR-Einschalter Rev.5, yaVDR 0.5 testing
VDR 2: Acer Revo 3610, 4GB Ram, 1x HDD 320 GB, Pinnacle PCTV SAT 452e, Medion X10, YaVDR 0.5
VDR 3: Intel DH67BL, Celeron 540, 4 GB Ram, POV Geforce 210 512 MB, 500 GB, DD Duo-flex CT, Arch LInux, VDR 2.1.6, CIR-Empfänger
Client 1: Raspberry Pi Model B, Arch Linux ARM, VDR 2.1.6
vdr-epg-daemon + MariaDB auf Cubietruck mit 32 GB SSD, Arch Linux ARM, optional Sundtek MediaTV Pro III + VDR 2.1.6
Ceterum censeo enchiridia esse lectitanda.

20

Tuesday, April 9th 2013, 4:36pm

I know ;) Das ist noch ein Relikt ... mein HTPC ist historisch gewachsen, hab vor ca. 10 Jahren mal mit nem reinen VDR angefangen und bin seit ca. 2-3 Jahren bei der Kombi VDR+XBMC gelandet (anfänglich eig. nur, weil ich das Design vom XBMC ganz schick fand ;) ), hab also quasi die ganze Entwicklung angefangen von XBMC mit Hilfe von streamdev-server über VNSI bis XVDR mitgemacht *g*