XBMC Plugin für Recording Service veröffentlicht

[v!rus]

Dem schliesse ich mich an.

Ich bin, sowohl Portisch als auch Lars für die Weiterentwicklung des XBMC-Addons und die Anpassung des RS´, sehr, sehr dankbar!

 

Gibt es denn seitens der XBMC Entwickler schon irgendwelche Äusserungen, bezüglich der FFMPEG Sache? Wird es da in absehbarer Zeit ein Update geben?

 

 

EDIT: Hängt das im Link stehende Thema nicht sogar damit zusammen?

 

http://forum.xbmc.org/showthread.php?tid=156303&page=12

Edited March 20, 2013 by v!rus

[Portisch]

Direkt nicht aber vielleicht mit etwas Glück:

 

.

..

...

0016-Speed-up-mpegts-av_find_stream_info.patch

...

..

.

 

Genau diese av_find_stream_info Funktion braucht beim RTSP Stream 5 Sekunden.

Mal schauen ob ich das mal mit der ffmpeg v1.2 hinbekomme!

[GBWebmaster]

Ich verfolge diesen Threat sehr interessiert.

 

Momentan ist XBMC für LiveTV noch keine Alternative - aber da scheinen ja gute Leute am Werk zu sein.

Vielen Dank Euch beiden für Eure Investition (natürlich vor allem zeitlich) für das XBMC-Projekt.

 

Und vielleicht hat man Dank Euch künftig eine interessante Auswahlmöglichkeit mehr für seine mediale Welt.

 

 

Nochmals vielen Dank an Portisch und Lars

GBWebmaster

[Jaral]

Da das Mediaportal PVR Addon auch RTSP benutzt werde ich mir noch ansehen ob dies mit dem DVBV RS auch umsetzbar wäre.

Dort wird der TS-Reader verwendet.

 

 

Verstehe ich das richtig, dass Du überlegst, auch ein Backend für MP zu erstellen?

Bin gerade von MP zu XBMC, weil ich unbedingt den RS als Backend haben wollte und es da für MP nix gibt...

Aber so richtig glücklich bin ich damit nicht...

 

Grüße

Jaral

[nuts]

Nein mit MP hat das wenig tun, sondern eher wie das MP Plugin für XBMC den ankommenden Datenstrom verarbeitet.

 

Mir ist immernoch nicht ganz klar wieso "av_find_stream_info" überhaupt verwendet werden muss.

Das ist wohl eine XBMC Besonderheit.

[Jaral]

Verstehe, jetzt wirkts auch logischer...

Naja, schade, muss ich mich wohl auf einen längeren Verbleib in XBMC einstellen...

 

Grüße

Jaral

[stargate2k]

Hi,

 

haben Lars und Portisch jetzt ein neues Addon für XBMC geschrieben oder entwickeln sie das bestehende von A600 weiter ? Wo kann man denn den aktuellen Stand runterladen ?

 

Das Plugin von A600 funktioniert eigentlich einwandfrei auch die Umschaltzeiten sind sehr kurz, das einzig negative ist, das keine HD-Sender funktionieren wenn man das noch in den Griff bekommen könnte..

 

mfg stargate

[Portisch]

Der aktuelle Source kann hier geladen werden:

https://github.com/Portisch/xbmc-pvr-addons

 

Anbei noch das Addon fertig für XBMC. Man muss aber ein Nightly Build von XBMC verwenden!!

Den Inhalt vom ZIP-File einfach in den Ordner von pvr.DVBViewer kopieren. PVR Database zurücksetzen nicht vergessen.

pvr.DVBViewer.1.7.6.zip

[Lars_MQ]

haben Lars und Portisch jetzt ein neues Addon für XBMC geschrieben oder entwickeln sie das bestehende von A600 weiter ?

Wir haben es weiterentwickelt. Und zwar auf beiden Seiten. Bei RS WebAPI und auf der XBMC Plugin Seite.

Mein ziel war dabei, dass der RS die Daten sinnvoller und vollständiger (logos/thumbnails/diverser krimskrams) zur verfügung stellt und dass damit eine schneller erfassung/verarbeitung der Daten im XBMC erfolgen kann.

 

Letztendlich wurde der grossteil der relevanten funktionen im Plugin um oder neugeschrieben mit hinblick auf eine noch engere und bessere Verzahnung mit dem RS und dessen datenstrukturen.

[erwin]

Ich wollte mal fragen ob da an Timeshiftsupport gearbeitet wird. Ich hab da so ein par Ideen, wollte Doppelarbeit aber auf jeden Fall vermeiden.

 

Ich stell mir einen RS-Proxy vor, d.h. einen eigenständigen Modul (als exe oder Service) der zwischen RS und XBMC sitzt und RS-WebApi-Komminikation 1 zu 1 weiter leitet,. die speziellen XBMC-Timeshift-Kommandos aber bedient. Er puffert dazu den Stream und gibt ihn je nach Anforderung an XBMC weiter.

 

Idealerweise würde ich dazu mein TimeshiftPlus-Plugin mit seinen speziellen Features (Ringpuffer, RAM-Basiert, etc) als Muster verwenden. Dummerweise wird darin ausgiebig von der DVBV-COM-Schnittstelle Gebrauch gemacht, die es nun im RS nicht gibt. D.h.die Anpassung wäre ein Stück Arbeit.

 

Also die Frage: Ist wer dran? Dann würde ich um die Prioritäten wissen.

 

 

erwin.

[Portisch]

Momentan bin ich nicht daran Timeshift einzubauen.

Mir ist noch nicht der richtige Geistesblitz gekommen wie man das am besten Umsetzt.

 

manül aus dem XBMC Forum hat schon eine Version mit Timeshift umgesetzt.

Ich will hier die Arbeit von ihm nicht kritisieren, aber es geht halt mehr schlecht als recht.

Es funktioniert im Prinzip aber mit erhöten Umschaltzeiten.

 

Auch wird das Timeshift lokal am Client gemacht was mir nicht sehr gefällt. Sicher, es ist der normale weg sowas so zu machen, aber bei Clients auf Android Basis oder ähnlichen Embedded Devices kann man sich da schnell den Speicher sprengen.

 

Eine Lösung das Timeshift auf dem Server durchzuführen wäre ein Traum. Auch würde eine große Timeshiftdatei dann auch kein Problem sein mehr da man ja eine große Festplatte verwenden kann.

 

Soweit es die Zeit zulässt bin ich auf jeden Fall dabei hier mitzuhelfen. Wenn's wirklich was wird könnte es ja als Vorlage für eine RS Erweiterung dienen

 

Zum XBMC Addon Ablauf:

Im Moment wird bei "GetChannels" eine Stream URL für jeden Sender übergeben.

Wenn dies nicht gemacht wird fragt XBMC mit "OpenLiveStream" im Addon nach.

Hier müsste dann der "Remote" Buffer reingehängt werden.

 

 

/** @name PVR live stream methods, used to open and close a stream to a channel, and optionally perform read operations on the stream */
 
 
//@{
 
 
/*!
* Open a live stream on the backend.
* @param channel The channel to stream.
* @return True if the stream has been opened successfully, false otherwise.
* @remarks Required if bHandlesInputStream or bHandlesDemuxing is set to true. Return false if this add-on won't provide this function.
*/
 
 
bool OpenLiveStream(const PVR_CHANNEL& channel);
 
 
/*!
* Close an open live stream.
* @remarks Required if bHandlesInputStream or bHandlesDemuxing is set to true.
*/
 
 
void CloseLiveStream(void);
 
 
/*!
* Read from an open live stream.
* @param pBuffer The buffer to store the data in.
* @param iBufferSize The amount of bytes to read.
* @return The amount of bytes that were actually read from the stream.
* @remarks Required if bHandlesInputStream is set to true. Return -1 if this add-on won't provide this function.
*/
 
 
int ReadLiveStream(unsigned char* pBuffer, unsigned int iBufferSize);
 
 
/*!
* Seek in a live stream on a backend that supports timeshifting.
* @param iPosition The position to seek to.
* @param iWhence ?
* @return The new position.
* @remarks Optional, and only used if bHandlesInputStream is set to true. Return -1 if this add-on won't provide this function.
*/
 
 
long long SeekLiveStream(long long iPosition, int iWhence = SEEK_SET);
 
 
/*!
* @return The position in the stream that's currently being read.
* @remarks Optional, and only used if bHandlesInputStream is set to true. Return -1 if this add-on won't provide this function.
*/
 
 
long long PositionLiveStream(void);
 
 
/*!
* @return The total length of the stream that's currently being read.
* @remarks Optional, and only used if bHandlesInputStream is set to true. Return -1 if this add-on won't provide this function.
*/
 
 
long long LengthLiveStream(void);

[erwin]

Eine Lösung das Timeshift auf dem Server durchzuführen wäre ein Traum.

 

Hm? Verschiedene Clients timeshiften verschieden. Man bräuchte mehrere Readpointer. Ist nicht unmöglich das umzusetzen. In einer frühen TimeshiftPlus-Version hatte ich das sogar schon mal (1. Read-Client normales Timeshift, 2. Read-Client - rückwirkendes Instant Recordimg aus dem Timeshiftpuffer heraus - habs dann rauskommentiert als DVBV dieses Feature gebracht hat). Also eine fixe Anzahl/Obergrenze von Clients wäre denkbar. Größere Umstellungen wären bei eine dynamischen Anzahl/keine Obergrenze von Clients notwendig.

 

Hier müsste dann der "Remote" Buffer reingehängt werden.

 

Hatte mir diese Stelle schon mal rausgesucht. Danke trotzdem. Du stehst in den XBMC-Sourcen tiefer drin, so dass ich weiss an wen ich mich im Falle der Fälle wenden könnte.

 

 

Zur Beachtung an die Mitleser: Nicht dass hier ein falscher Eindruck entsteht, da könnte in Kürze von mir was kommen. Momentan alles nur Gedankenspiele. Vielleicht hab ich später im Urlaub das Programmierer-Kribbeln in den Fingern.

 

erwin

[nuts]

Wollt ihr echt X Timeshiftpunkte im Server selbst behandeln?

Gibt das nicht schnell einen Flaschenhals?

Am Client ist das doch wesentlich einfacher.

 

@Portisch: Wie funktioniert das timeshift von manül? Ist das eine Art pem. timeshift?

[erwin]

Wollt ihr echt X Timeshiftpunkte im Server selbst behandeln?

Gibt das nicht schnell einen Flaschenhals?

 

Naja X vielleicht nicht, aber 4 denke ich reichen für eine Wohnung. Und nach Bauchgefühl durchaus im Rahmen, schnellen Server vorausgesetzt. Einerseits die Performancevorteile eines RAM-basierten Puffer nutzend (da ist dann nur ein wenig Pointerarithmetik und memcopy im Spiel) und dann vielleicht noch einen schnellen 4 Kerner. Ich denke schon. Eher unsicher bin ich beim Erzeugen mehrerer Streams für XMBC, da hab ich jetzt kein Bauchgefühl. Vielleicht sagt ja Lars was dazu.

 

erwin

[Portisch]

Das Timeshift von manül erzeugt ein lokales File (tsbuffer.ts).

Danach wird dieses File einmal für Write und einmal für Read geöffnet.

Die empfangen Daten vom RS werden in einer Endloschleife ins File geschrieben.

XBMC fragt dann häppchenweise mit Read das File ab.

 

Momentan ist permanent oder gar kein Timeshift möglich.

Edited March 27, 2013 by Portisch

[nuts]

Und das bei jedem Senderwechsel?

Kaum verwunderlich das so das zappen länger dauert.

Nicht das ich wüsste wie es besser geht, aber das ist keine gute Idee (nicht nur wegen den höheren Umschaltzeiten).

 

 

@Erwin: Mehrere Streams erzeugen ist denke ich kein Problem.

4 Clients (DVBV) kann ich hier über RTSP locker versorgen.

Ob die für den DVBV oder XBMC erzeugt werden dürfte doch keinen Unterschied machen?

Aber mit 4 Timeshift-Files auf der Festplatte des Servers muss eine Menge Daten hin und her kopiert werden.

Keine Ahnung ob das noch im Rahmen ist.

RAM basierend wird doch kaum gehen? Wieviel Speicher soll der Server für 4 HD Kanäle denn dafür abstellen?

Selbst mit Ringbuffer ist das knapp.

Edited March 27, 2013 by nuts

[nuts]

Hat eigentlich schon jemand den "zapping fix" ausprobiert?

http://forum.xbmc.org/showthread.php?tid=140645&page=54

 

Gibt da sehr unterschiedliche Aussagen im XBMC Forum.

Leider ist meist unklar welche Version des Plugins verwendet wird.

[erwin]

Aber mit 4 Timeshift-Files auf der Festplatte des Servers muss eine Menge Daten hin und her kopiert werden.

 

Nein, es bleibt ein File. Die gesendeten Daten sind doch für alle gleich (verschiedene Kanäle für die Clienten sind eine andere Chose). Nur die Leseposition hat jeder für sich. Sind halt 4 ReadPointer und EIN WritePointer

 

 

BYTE * WriteStream;

 

BYTE * ReadClient1Stream;

BYTE * ReadClient2Stream;

BYTE * ReadClient3Stream;

BYTE * ReadClient4Stream;

 

Da muss dann auch nix hin und her kopiert werden.

 

Und auch mit RAM allein kommt schon weit. 16GB reichen um die meisten HD-Filme an deren Ende wieder von vorn schauen zu können. Und wer einen _Server_ aufsetzt, der sollte bei RAM nicht geizen.

 

 

erwin

 

[Portisch]

Ich habe es nur kurz angetestet. Aussagekräftig ist nur ein Log von XBMC.

Da sieht man genau wann der Stream geöffnet wird und wann die Wiedergabe startet.

 

Bei meinen letzten Versuchen mit der Originalen XBMC Version dauerte es halt ca. 5 Sekunden bis ffmpeg mit der Header Analyse fertig war.

Bei dem "zaaping fix" sollte die "av_find_stream_info" von ffmpeg ausgelassen werden. Dann sollten die Umschlatzeiten auf 1-2 Sekunden runtergehen.

 

Was ich aber auch beobachtet habe: Wenn ein Stream bereits vom DVBViewer geöffnet war ging es um ~50% schneller mit XBMC wenn man den gleichen Stream einstellte. Der Grund dafür wird halt der bereits geöffnete Tuner sein, da ansonsten ja erst getuned werden muss.

[nuts]

Nein, es bleibt ein File. Die gesendeten Daten sind doch für alle gleich (verschiedene Kanäle für die Clienten sind eine andere Chose)

Nur wenn die Clients auch unabhängig voneinander funktionieren macht das Sinn.

 

P.S, Mein "TV Server" hat 2GB RAM und das reicht für alles (!) aus.

[erwin]

Nur wenn die Clients auch unabhängig voneinander funktionieren macht das Sinn.

 

Gut, wenn für jeden ein Tuner zur Verfügung steht.... Wenns für soviel gereicht hat, sollte auch für jeden entsprechender RAM oder eine separate Platte drin sein ;-)

 

Darin sehe ich nicht wirklich einen Pflaschenhals.

 

erwin

[nuts]

Der Recordingservice hat ja schon eine Hardwareverwaltung.

Über das "Server-Timeshift" eine Abhängigkeit zwischen den Clients herzustellen halte ich für ungünstig.

 

Bsp: Client1 aktiviert timeshift auf ARD, Client2 schaut LiveTV auf ZDF

Mit nur einem Buffer für alle Clients kann Client2 jetzt gar kein timeshift mehr aktivieren.

 

Also wenn schon müsste jeder Client seinen eigenen Timeshift-Buffer bekommen.

Ist zumindest meine Meinung zu dem Thema.

[erwin]

Richtig!

 

Meine Vorstellung:

 

Pro Tuner GENAU EINEN Puffer.

 

Hier müsste der gesamte Transportstream gepuffert werden.

 

contra: evt. Speicherplatzverschwendung bei ungenutzten Kanälen

pro: es können auch bisher nicht genutzte Kanäle auf dem selben Transponder rückwirkend "timegeshifted" werden

 

oder:

 

Pro getunetem Kanal GENAU EINEN Puffer.

 

 

In beiden Fällen teilen sich Clienten auf dem selben Kanal EINEN Puffer.

 

also

 

NICHT: Pro Client GENAU EINEN Puffer.

 

 

erwin

[nuts]

Wird jetzt stark offtopic, aber den ganzen "Transportstream" zu "timeshiften" geht nicht wegen den verschlüsselten Kanälen.

Also Variante 2.

 

Und den möglichst auch nur bei Bedarf zuschalten, was dann quasi aufs selbe rausläuft wie Pro Client ein Puffer.

Edited March 27, 2013 by nuts

[Portisch]

Ich möchte nur noch kurz dies von Lars zum Kanalwechsel von XBMC anbringen damit es nicht verloren geht:

 

Die sequenz ist
- DESCRIBE mit parametern (dieser aufruf ist fehlerhaft, da XBMC in der Antwort keine relative URL akzeptiert, sondern immer eine vollständige URL. VLC macht das richtig).
- SETUP mit der URL aus dem Describe aufruf
- PLAY
- TEARDOWN

Reichen würde
SETUP mit parameter, das format ist ja schon garantiert -> TS
PLAY
PLAY mit anderen Parameter (->Senderwechsel)
[...]
TEARDOWN

 

Das XBMC könnte auf jeden Fall bei einem Senderwechsel immer die ganze URL an den Timeshift Puffer weitergeben.

Dieser Zwischenpuffer sollte dann so intelegent sein einfach die Parameter an den RS weiterzugeben und nicht den ganzen Streamaufbau wie XBMC neu machen. Es ist dann halt RTSP für LiveTV zwingend erforderlich - aber das ist sowieso die Zukunft.

 

Dadurch sollte es möglich sein die Verzögerung eines solchen Puffers zwischen RS und XBMC so gering als möglich zu halten.

[Lars_MQ]

Also von der Verwaltungseite macht es nur sinn, pro Client eine Timeshiftdatei mit nur den benötigten Streams.

 

Ein ganz anderer gesichtspunkt, der das ganze viel schwieriger macht: Die übertragungrate der Daten muss exakt reguliert werden.

LiveTV macht das automatisch, da die Daten gesendet werden, wenn sie ankommen.

Eine Datei wird mit maximaler Festplatten Lesegeschwindigkeit bzw. Netzwerkdatenrate gesendet.

Bei TCP besteht noch die möglichkeit, dass der Empfänger "blockt" und somit die Datenrate reguliert, bei RTSP (=UDP Stream) geht das nicht.

Das bedeutet, ich müsste irgendwie die LiveTV datenrate sehr exakt simulieren, was sehr aufwendig wird.

[erwin]

Danke für die aufgezeigten Problemaspekte.

 

erwin

[Griga]

Das bedeutet, ich müsste irgendwie die LiveTV datenrate sehr exakt simulieren, was sehr aufwendig wird.

 

Das in TransEdit integrierte File Device macht das anhand der PCR mit dem AsyncReader, einem Multimedia-Timer und einem Event-Objekt. Wenn man den Analyzer auf eine Datei ansetzt, erhält man so eine recht gute Live-Simulation. Das zeigt auch die Preview-Wiedergabe, die in diesem Fall den DVBViewer Filter im Live-Modus verwendet, also ohne Renderer-Konsumraten-Bremse. Eine Code-Vorlage könnte ich liefern.

 

Allerdings beinhaltet das Verfahren in der existierenden Form keine Navigation (vor/zurückspringen usw.), und wenn es aus irgendeinem Grund keine PCR gibt oder sie Diskontinuitäten aufweist, ist Hängen im Schacht

[Lars_MQ]

Also ich bin grade die aktuelle nightly vom XBMC durchgegangen mit der portisch version des plugins und wireshark und sorry ich muss sagen: WTF, was machen die da???

Das anfängliche laden der Daten könnte mit sicherheit um ein vielfaches beschleunigt werden, wenn die nicht in im sekunden takt die timer und aufnahmen liste runterladen würden. Was relativ sinnlos ist, weil das durch das EPG normalerweise auf Minuten beschränkt ist.

 

Ich muss ehrlich sagen, dass mir zu sowas nichts mehr einfällt und ich sehe keine notwenigkeit, für noch irgendwelche optimierungen vorzunehmen, bzw, mich mit dem kram zu involvieren, solange die host app so ein inkompetentes verhalten an den tag legt... es lohnt sich einfach nicht.

[Portisch]

+1

Habe es am Wochenende gar nicht zum Laufen bekommen. Da ist auch mir die Lust darauf vergangen...

Da ich sowieso immer weniger Zeit habe finde ich es zu schade erst wieder Zeit zu investieren damit es überhaupt wieder läuft!

[Mister]

https://dl.dropbox.com/u/7249985/xbmc/xbmc-12.1-Frodo-margro.exe

Hi

mit dem Windows 12.1 build hab ich umschaltzeiten unter 2 sekunden bei free tv

 

[Portisch]

Genau mit diesem Build habe ich es probiert. Dort war es nicht möglich das Addon zu starten. Muss ich dann vielleicht doch nochmal testen.

Umschaltzeiten von 2 Sekunden bei UPnP oder RTSP?

[dhjgv]

Brauchte dein Plugin nicht die aktuelle PVR API aus den Nightlies???

Dann ist's doch kein Wunder, das es nicht geht, denn da ist sie nicht drin

 

Bei mir sind es mit dem 1.6.5 Addon ebenfalls 2 Sek., logischerweise dann mit UPNP.

Edited April 3, 2013 by dhjgv

[Portisch]

 

Brauchte dein Plugin nicht die aktuelle PVR API aus den Nightlies???

 

Ja, das war es! Mit derXBMC v13 geht es, mit der v12.1 natürlich nicht.

Dann werde ich mal warten bis die "Zapping-Fixes" im aktuelle Build drinnen sind...

[nuts]

Man kann da wirklich schnell durcheinander kommen.

Was mich noch interessieren würde:

 

Der Zapping-Fix bewirkt jetzt was genau?

Ein anderer Demuxer für "alle" PVR-Addons?

edit\ Ah hier stehts ja: http://forum.xbmc.org/showthread.php?tid=150887&page=4

 

Die von Lars angesprochenen Aufrufe im Sekundentakt werden vom PVR-Hauptprogramm getriggert?

Oder ist das im PVR DVBViewer Plugin enthalten?

Das so ein XBMC Client den TV-Server derart lahmlegt finde ich nämlich auch nicht schön.

Edited April 3, 2013 by nuts

[Portisch]

Die Anfragen an den Server werden von XBMC getriggert. Z.b wenn man in die Recordings bei XBMC reingeht werden immer wieder alle Recordings vom Server abgefragt. Das mit dem EPG habe ich nicht überprüft. Das könnte aber das Addon über die Startzeit abfangen. Wieviel Abstand macht hier Sinn?

[Lars_MQ]

Das mit dem EPG abfangen ist nicht unbedingt so gut.

Fall:

Sender nur mit now/next EPG, war länger nicht eingeschaltet. Dann sollte kurz nach dem tunen das aktuelle EPG schon abgerufen werden. Im normalfall sollte XBMC von sich aus nach dem tunen etwa 5 bis 10 sekunden warten und dann erst das EPG abrufen, damit der Parser im RS das EPG erstmal erfassen kann.

 

Und um das nochmal klar zu stellen: Mein rant ging nicht gegen Portisch und seine Arbeit. Das unsinnige Abrufen wird direkt in XBMC veranlasst. Mich hat das gestern nur nach stundenlanger Suche genervt und ich musste etwas dampf ablassen.

Die Timer und Aufnahmenliste sind bei mir über 2 MB, wenn per webAPI abgerufen wird. Wenn XBMC die abruft, werden die auch verarbeitet und das kostet zeit. Das während des initialisierens im Sekundentakt zu machen ist unsinnig, da sich die dateien gar nicht so schnell verändern können.

Das initialisieren dauert bei meinem System schon mehrere minuten, da ist sowas sehr ärgerlich... Übrigens mit dem "vor Portisch" plugin dauerte es gut 3 mal so lange...

[sw4y]

Die von Lars angesprochenen Aufrufe im Sekundentakt werden vom PVR-Hauptprogramm getriggert?

Oder ist das im PVR DVBViewer Plugin enthalten?

Das so ein XBMC Client den TV-Server derart lahmlegt finde ich nämlich auch nicht schön.

 

Hat vielleicht etwas mit dem Thema zu tun:

 

Seitdem in meinem Netzwerk ein Raspberry PI als Client werkelt, fährt mein Server (WHS 2011) nicht mehr richtig (bzw. gar nicht) in den Standby.

Trenne ich den PI vom Netz, läuft alles wie es soll.

 

Irgendwas in XBMC verhindert also den Standby, es wird aber auch aus den Server Logs nicht ersichtlich, was genau es ist.

 

Von der XBMC Materie hab ich allerdings zuwenig Ahnung um da im Detail suchen zu können.

 

Deswegen kam mir jetzt halt die Idee, es könnte etwas damit zu tun haben!?

[nuts]

Ich würde da jetzt eher vermuten, dass XBMC auf dem PI dauerhaft "aktiv" ist und so den Standby verhindert.

Muss gar nicht das PVR Addon selbst sein, könnten auch eine UPnP Verbindung oder sowas sein.

http://de.DVBViewer.tv/wiki/Optionen_Service_-_Web/UPnP#Verhindere_Stromsparmodus.2FRuhezustand..._2

[sw4y]

Ich meine, dass ich die Optionen im Recording Service alle richtig gesetzt hatte und trotzdem kein Standby ging. Ich werd mir das aber nochmal näher anschauen.