Beiträge von Snoopy_1978

OK, zu früh gefreut.....

S91.lifeguard bei geöffneter Datei im smb-share per Hand (als VDR) ausgeführt ergibt das korrekte Ergebnis:

vdr@medix:/usr/share/vdr/shutdown-hooks$ ./S91.lifeguard 
ABORT_MESSAGE="Files open on SMB share."

VDR mag aber immer noch herunterfahren:

root@medix:/usr/share/vdr/shutdown-hooks# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown boolean:true
method return sender=:1.28 -> dest=:1.62 reply_serial=2
   int32 990
   string "stop vdr ; /sbin/halt -p"
   int32 0
   string ""

Habe daraufhin ein wenig Logging nach /tmp in die S91.lifeguard eingebaut (zu Beginn ein env, dann ein date und ein paar echo's und smbstatus -L mit Umlenkung ins log aufgerufen ....), das ist das Ergebnis vom vdr-dbus-send:

SHELL=/bin/bash
TERM=linux
LC_ALL=de_DE.UTF-8
USER=vdr
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
_=/usr/bin/env
JOB=networking
PWD=/
RESULT=ok
VDR_CHARSET_OVERRIDE=ISO-8859-9
LANG=de_DE.UTF-8
SHLVL=3
HOME=/var/lib/vdr
LANGUAGE=de_DE
UPSTART_INSTANCE=
LOGNAME=vdr
UPSTART_EVENTS=started started stopped
INSTANCE=
UPSTART_JOB=vdr
Mi 17. Apr 11:23:35 CEST 2013
STARTED LIFEGUARD
IN SMB BRANCH
IN LOCK SUB-BRANCH, this is smbstatus -L
smbstatus should not be run setuid
FINISHD. THIS IS REASON:

smbstatus mag es wohl nicht, wenn es von einem Prozess gestartet wird, der den User gewechselt hat ("setuid - läuft").

Das brachte mich auf die Spur eines Thread aus 2007, wo jmd. schon mal ähnliches probiert hat incl. Lösung:

http://www.vdr-portal.de/board/thread.php?postid=611210

Dies ist dann jetzt die endgültige Lösung:

1.) Im S91.lifeguard ein "sudo" vor smbstatus -L voranstellen
2.) in der sudoers diese Zeile am Ende einfügen:
vdr ALL=NOPASSWD: /usr/bin/smbstatus

Nun macht vdr-dbus-send alles richtig:

root@medix:/usr/share/vdr/shutdown-hooks# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown boolean:true
method return sender=:1.28 -> dest=:1.40 reply_serial=2
   int32 992
   string "Files open on SMB share."
   int32 224
   string ""

Zitat von Snoopy_1978

Zitat von »seahawk1986«
Zum lifeguard-Addon gab es schon einige Threads, die eine Verbesserung des Verhaltens bei Samba-Freigaben beschrieben haben - die Abfrage scheint wohl nicht allzu zuverlässig zu sein - evtl. kannst du ja mal den lifeguard-Shutdown-Hook (/usr/share/vdr/shutdown-hooks/S91.lifeguard) einzeln nach einem "set -x" in der Shell laufen lassen und schauen weshalb der bei dir das Herunterfahren nicht verhindert.

OK, werde ich moren probieren, gerade läuft ne Aufnahme

Habs gefunden.... da ist ein Fehler im S91.lifeguard Script:

Das steht im "Auslieferungszustand" drin:

smb)
            	# samba locks or shares
            	case "$TYPE" in
              	lock*)
                    	if [ $(smbstatus -L | wc -l) -gt 2 ]; then
                            	REASON=${DESCRIPTION:-"Samba locks"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
              	share*)
                    	if [ $(smbstatus -S | wc -l) -gt 4 ]; then
                            	REASON=${DESCRIPTION:-"Samba shares"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
              	*)
                    	if [ $(smbstatus -S | grep -cE "$PATTERN\b") -gt 0 ]; then
                            	REASON=${DESCRIPTION:-"$PATTERN"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
            	esac
            	continue
            	;;

Da $TYPE für die betr. Zeile ja "smb" ist, geht er immer in den Default Zweig; und "$(smbstatus -S | grep -cE "locks\b")" ist immer == 0

Das sollte also wohl eigentlich richtig heißen:

smb)
            	# samba locks or shares
            	case "$PATTERN" in
              	lock*)
                    	if [ $(smbstatus -L | wc -l) -gt 2 ]; then
                            	REASON=${DESCRIPTION:-"Samba locks"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
              	share*)
                    	if [ $(smbstatus -S | wc -l) -gt 4 ]; then
                            	REASON=${DESCRIPTION:-"Samba shares"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
              	*)
                    	if [ $(smbstatus -S | grep -cE "$PATTERN\b") -gt 0 ]; then
                            	REASON=${DESCRIPTION:-"$PATTERN"}
                            	break 2
                    	fi
                    	continue 2
                    	;;
            	esac
            	continue
            	;;

So funzt es auf jeden Fall....

Zitat von seahawk1986

Zitat von »Snoopy_1978«

Quellcode

1
2
3
4
5
6

root@medix:/etc/vdr# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown
method return sender=:1.35 -> dest=:1.36 reply_serial=2
int32 901
string "user is active"
int32 0
string ""

obwohl doch gar nicht nach aktiven Benutzern gesucht werden soll....

Damit fragst du ja nur den VDR (und nicht das System selbst), ob er denkt, dass ein User aktiv ist - und die PVR-Addons verursachen z.B. immer Useraktivität (bzw. setzen die Inaktivitätsdauer auf 0), solange sie verbunden sind.
Daher fragt das Addon ja auch ohne Berücksichtigung dieser VDR-Benutzeraktivität nach (siehe https://github.com/yavdr/vdr-plugin-dbus…r/README#L254):

Alles anzeigen

Das ich VDR direkt abfrage ist mir klar... aber da es ja auch für lifeguard eine "usr" Konfiguration gibt, habe ich die Meldung "User active" darauf bezogen. Das damit das PVR-Addon vom XBMC gemeint ist, wird da nicht wirklich klar *find* . Wobei ... ich mein, XBMC wäre zu dem Zeitpunkt gar nicht aktiv gewesen... hmm... morgen noch mal genau drauf achten.

Zitat von seahawk1986

Zum lifeguard-Addon gab es schon einige Threads, die eine Verbesserung des Verhaltens bei Samba-Freigaben beschrieben haben - die Abfrage scheint wohl nicht allzu zuverlässig zu sein - evtl. kannst du ja mal den lifeguard-Shutdown-Hook (/usr/share/vdr/shutdown-hooks/S91.lifeguard) einzeln nach einem "set -x" in der Shell laufen lassen und schauen weshalb der bei dir das Herunterfahren nicht verhindert.

OK, werde ich moren probieren, gerade läuft ne Aufnahme

Zitat von seahawk1986

Zum WFE kann ich leider nichts sagen, das ist nicht mein Gebiet. Am besten mal im Bugtracker melden.

Mach ich...

Bin seit dem WE nun auf yaVDR 0.5 + XBMC 12.1 aus dem testing ppa; primäres Frontend ist XBMC.
Das Ganze funzt ootb bestens.

Nun experimentiere ich erneut mit dem Konstrukt yaVDR-Tools <-> vdr-plugin-dbus2vdr <-> vdr-addon-lifeguard <-> yaVDR-WebFrontend und irgendwie ist da noch der Wurm drin oder ich hab da noch n Verständnisproblem:

1) Habe im Webfrontend im Abschnitt "lifeguard" Probehalber nur die Punkte "NFS" und "SMB" aktiviert. Dementsprechend sieht die lifeguard.conf nun so aus:

#################################################################################
#                                                                           	#
#   The following configuration file is generated automatically by the yaVDR	#
# 	system. Don't change this file as every update of yaVDR will overwrite	#
#     	the local changes. Instead put your required customizations       	#
#   	into /etc/yavdr/templates_custom/ based on the original templates   	#
#                  	under /usr/share/yavdr/templates.                    	#
#                                                                           	#
#        	http://www.yavdr.org/developer-zone/template-overview/         	#
#                                                                           	#
#                                                                           	#
#################################################################################
#
# /etc/vdr/lifeguard.conf - configuration file for VDR lifeguard
#
# See manpage for vdr-addon-lifeguard (`man vdr-addon-lifeguard`)
#






tcp 	nfs         	NFS\ Mount\ is\ still\ active
smb 	locks       	Files\ open\ on\ SMB\ share.

=> keine "usr" Zeile, trotzdem bekomme ich bei einer dbus - Anfrage:

root@medix:/etc/vdr# vdr-dbus-send /Shutdown shutdown.ConfirmShutdown
method return sender=:1.35 -> dest=:1.36 reply_serial=2
   int32 901
   string "user is active"
   int32 0
   string ""

obwohl doch gar nicht nach aktiven Benutzern gesucht werden soll....

2) Da scheints noch einen Bug im yaVDR - WebFrontend zu geben, denn nach einem Reload desselben sieht der lifeguard Abschnitt so aus, wie im Anhang "lifeguard.jpg"

Firebug sieht man im Anhang "firebug.jpg"
(Die lifeguard.conf ist korrekt, scheint also nur ein Anzeigeproblem zu sein....)

3) Die SMB "Überwachung" scheint auch noch fehlerhaft zu sein, denn wenn ich auf nem anderen Rechner eine Aufnahme über SMB laufen habe, sieht smbstatus erwartungsgemäß so aus:

root@medix:~# smbstatus -L
Locked files:
Pid      	Uid    	DenyMode   Access  	R/W    	Oplock       	SharePath   Name   Time
--------------------------------------------------------------------------------------------------
17260    	666    	DENY_NONE  0x100081	RDONLY 	NONE         	/srv/vdr/video.00   X-Men_Origins#3A_Wolverine/2011-11-06.20.05.6-0.rec   Tue Apr 16 13:37:30 2013
17260    	666    	DENY_NONE  0x20089 	RDONLY 	EXCLUSIVE+BATCH  /srv/vdr/video.00   X-Men_Origins#3A_Wolverine/2011-11-06.20.05.6-0.rec/00001.ts   Tue Apr 16 13:37:35 2013

Trotzdem fährt VDR runter, das sind die Einträge im syslog:

Apr 16 13:48:05 medix vdr: [22245] dbus2vdr: new message, object /Shutdown, interface org.freedesktop.DBus.Introspectable, member Introspect
Apr 16 13:48:05 medix vdr: [22245] dbus2vdr: introspect object /Shutdown with Introspect
Apr 16 13:48:05 medix vdr: [22245] dbus2vdr: new message, object /Shutdown, interface de.tvdr.vdr.shutdown, member ConfirmShutdown
Apr 16 13:48:05 medix vdr: [22245] dbus2vdr: 1 idle message handler, reusing 0x7f87c40047c0
Apr 16 13:48:05 medix vdr: [23235] dbus2vdr message handler thread started (pid=22137, tid=23235, prio=high)
Apr 16 13:48:05 medix vdr: [23235] dbus2vdr: calling shutdown-hook-wrapper /usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper /usr/share/vdr/shutdown-hooks
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S90.acpiwakeup
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = (null)
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S90.custom
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = (null)
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S90.nvram-wakeup
Apr 16 13:48:05 medix vdr-nvram-wakeup: nvram-wakeup functionality is disabled
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = (null)
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S91.lifeguard
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = (null)
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S92.xbmcactivity
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = XBMC INACTIVE
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: asking shutdown-hook /usr/share/vdr/shutdown-hooks/S99.shutdown
Apr 16 13:48:05 medix shutdown-wrapper: [23236] dbus2vdr-shutdown-wrapper: result(0) = SHUTDOWNCMD="stop vdr ; /sbin/halt -p"
Apr 16 13:48:05 medix vdr: [23235] dbus2vdr: result(0) = SHUTDOWNCMD="stop vdr ; /sbin/halt -p"

???

OK, habs gerade gefunden... in /etc/init/xbmc-exit.conf die Zeile

/sbin/initctl emit --no-wait vdr-frontend-restart

auskommentiert... danach blieb xbmc aus... vllt. ein wenig dreckig, aber geht erst mal

Hi zusammen,

wenn ich im yaVDR-Webfrontend als Frontend "XBMC@vdr-plugin-xvdr" ausgewählt habe, funktioniert das gewollte Beenden von XBMC (z.B. zum händischen Editieren von advancedsettings.xml o.ä.) nicht mehr. Ein "stop xbmc" auf der Konsole führt zu einem sofortigen Restart von XBMC. Auch wenn ich per yaVDR-Webfrontend unter "System" die Funktion "XBMC Notstop" verwende, startet XBMC sofort neu. "Verlassen" im "S" - Menü vom XBMC führt zum selben Ergebnis.

Im XBMC - Upstart Job kann ich kein "respawn" finden. Wodurch wird der Neustart ausgelöst?

Vielen Dank und viele Grüße
Snoopy

hmm... da muß ich vorhin an irgendeiner stelle krumme finger gehabt haben.. das PowerOff funzt jetzt mit deaktivierter "use" Zeile in der lifeguard.conf trotz angemeldetem Benutzer.... danke schon mal sehr bis hierhin für die tolle unterstützung

Zitat von seahawk1986

Das funktioniert so: dbus2vdr hat einen Shutdown-Wrapper, der in der Voreinstellung die ganzen Shutdown-Hooks des VDR aufruft, wenn der VDR meldet, dass er herunterfahren könnte (damit vermeidet man es unnötigerweise den User inaktiv zu setzen und kann einfach zwischendrin mal den Status abfragen)
Dass ein User angemeldet ist, ist ein mögliches Kriterium für das Lifeguard-Addon, man kann das aber durchaus abschalten, wenn man will.

War auch meine erste Vermutung, daher habe ich in der lifeguard.conf die "usr" Zeile auskommentiert. Das hat aber nix geändert... deswegen dachte ich, dbus2vdr läuft unabhängig vom lifeguard. Wenn dbus aber die Shutdown Hooks abfragt, spielt das ja doch ne rolle..

Zitat von seahawk1986

Es hat niemand gesagt, dass es einfach ist - aber bislang ist uns nichts besseres eingefallen...

*g* das hab ich auch nie gedacht, zeigt ja auch, wieviel Zeit und Energie in eurer Distri steckt, Kompliment dafür
Der ehrgeiz, das doch noch hinzufriemeln ist ja irgendwie doch noch da

Hab das ganze Konstrukt yavdr-tools für XBMC <-> dbus2vdr nun grundsätzlich am laufen, technisch funzt es, ABER:

Jetzt wird der PowerOff verhindert, weil dbus2vdr einen aktiven Benutzer vermutet... klar, der automatisch in LXDE angemeldete, der XBMC per Autostart startet.
(Ich hab richtig verstanden, dass die Anfrage vom XBMC and VDR, ob heruntergefahren werden kann, nur von dbus2vdr unabhängig vom lifeguard - Plugin behandelt wird?)

Fazit bisher:
Das Konstrukt per Hand in einem Standard - Minimal Ubuntu mit einem Desktop Environment (wenns auch nur ein minimales LXDE ist) nachzubauen, ist schon recht aufwendig. Da ists fast einfacher, sich eure Distri am WE (wenn kein Timer läuft und man ein wenig Zeit hat ) mal testweise auf den HTPC im WoZi zu packen...

wenn man halt zu faul ist, diverse skripte oder PHP's anzupassen, die per SVDRP Daten vom VDR gezogen haben, macht mans halt "dreckig"

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*

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:

/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

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

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*

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:

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

was fehlt dann noch?

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:

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

???

Zitat von seahawk1986

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 )

Zitat von seahawk1986

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)

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?

verdammt, dachte mir so was schon *g*

eher in der horizontalen oder eher in der vertikalen daneben?

Was ich auch komisch fand:
1.) Habe 2 identische DVB-S Karten in meiner Kiste, beide an zwei Anschlüssen des Quattro LNB der Schüssel angeschlossen. Wenn ich mit w_scan explizit mal auf der einen Karte, mal auf der anderen Karte (-a 0 bzw. -a 1) scannen lasse, bekomme ich auf der ersten Karte geringfügig andere Sender, als auf der zweiten. ProSieben / SAT.1 z.B. empfange ich nur auf der zweiten Karte, auf der ersten tauchen die bei nem Scan nicht auf.... auch wegen "daneben"?

2.) Wenn ich mit w_scan auf Astra 23.5E (-s S23E5) anstelle auf Astra 19.2E (-s S19E2) scanne, bekomme ich auch massig Kanäle... also würde ich vermuten, dass ich gerade genau "zwischen" den beiden liege?