Jump to content

Umschaltzeiten - An welcher Stelle optimieren? (XBMC)


Recommended Posts

Hallo,

 

ich beschäftige mich nun seit ca. 2 Monaten mit dem Thema "Fernsehen per LAN im ganzen Haus".

Nun hat mir vor ein paar Wochen meine Liebste ein Digital Devices Octopus Net mit 4 Sat receivern geschenkt.

Nachdem ich dann noch einen unicable + generic LNB beschafft und installiert habe (damit die anderen TVs im Haus normal funktionieren und ich keine neuen Kabel legen muss), funktioniert das ganze System schon mal ganz gut.

 

Mit dem Einsatz des DVBViewers kann ich dazu noch den im DD Octopus verbauten CI Slot nutzen (was wirklich der Wahnsinn ist).

Mein nächster Schritt wäre jetzt eigentlich, dass ich nicht nur am PC die Sender empfangen kann, sondern auch am TV.

Deshalb verwende ich den Recording Service am DVBViewer-Server und XBMC am Client.

Das funktioniert prinzipiell ja auch, jedoch bin ich mit den Umschaltzeiten sehr unzufrieden und würde jetzt gerne herausfinden, warum diese so langsam sind (je nach Client... an einem Raspberry Pi, auf welchem ich nachträglich XMBC installiert habe, sind die bei etwa 8 Sekunden. Beim Umschalten auf/von HD-Sendern eher noch mehr...)

 

Zuest mal ein paar Infos zu meinem momentanen Setup (befindet sich wohl eher noch im Teststadium):

- Digital Devices Octopus Net mit 4 SAT-Tunern (werden per Unicable versorgt)

- DVBViewer & RecordingService auf einem "echten" Server in einer virtualisierten Windows 7 VM (Virtualisiert per Virtualbox, da der Server selbst CentOS verwendet).

Der Server hat einen Xeon E31220L, aber keine GPU.

- 1 Client-PC mit Core i5 der ersten Generation (hier wird auch die onboard GPU verwendet)

- 1 Client-PC mit Core i7 (ich glaube der dritten Generation; hier kommt eine Nvidia Grafikkarte zum Einsatz)

- 1 Raspberry-Pi mit XMBC und aktivierter MPEG2-Lizenz

 

Jetzt habe ich schon folgendes probiert:

- Nutzung des Clients mit i7 und Nvidia über den RecordingService und XMBC. Hier erreiche ich immer Umschaltzeiten von ca. 2 bis 3 Sekunden (das würde mir fast schon ausreichen).

Testweise habe ich hier auch mal den DVBViewer Pro installiert. Die Umschaltzeiten sinken dann nochmals um ca. eine halbe Sekunde (mehr aber auch nicht).

- Nutzung des Clients mit i5 und IntelGPU der ersten Generation über RecordingService und XBMC. Die Umschaltzeiten sind hier schlechter - irgendwo bei 3 bis 5 Sekunden (HD braucht natülich etwas mehr).

- Nutzung des Raspberry Pi mit XMBC (keine eigene Raspberry Distribution... XBMC mit DVBViewer Plugin wurden nachträglich auf einem raspbian installiert. Die Umschaltzeiten sind hier nicht zu gebrauchen. Die liegen bei mehr als 5 Sekunden - bei HD-Sendern manchmal bei mehr als 10 Sekunden.

 

Wie kann ich denn hier die Umschaltzeiten besser in den Griff bekommen?

Ich habe bis jetzt an folgendes gedacht, habe aber keinen Ahnung, was hier wirklich helfen könnte (da habe ich einfach noch zu wenig Erfahrung bzw. keinen 100% Durchblick wie die Software funktioniert):

- Einbau einer minimalistischen GPU in den Server. Vielleicht hilft das ja beim schnelleren Umschalten. An den Clients konnte man erkennen, dass die Umschaltzeit vermutlich auch von der GPU abhängt und deshalb dachte ich mir, dass das helfen könnte. Auf der anderen Seite habe ich mal gelesen, dass das beim RecordingService nichts bringt, weil der das Signal nicht angreift (stimmt das)?

- Nutzung einer dedizierten XBMC-Distribution am RaspberryPi. Bringt vermutlich was, aber bringt das wirklich die Umschaltzeiten von (worst case) über 10sec auf 2sec??

- Aufbau eines dedizierten Netzwerkes zwischen Server und DigitalDevices Octopus Net. Könnte auch was bringen, aber warum schaltet dann der Client mit i7 ausreichend schnell?

- Einbau der Komponenten aus dem DigitalDevices in den Server. Würde ich gerne vermeiden bzw. bin ich mir nichtmal sicher, dass im Server noch genügend Steckplätze frei sind.

 

GIbt's denn noch andere Möglichkeiten, das besser hinzubekommen?

Ich habe im Forum schon einiges gefunden, aber nichts davon (zumindest nichts was ich gefunden habe) beschäftigt sich wirklich mit dem RecordingService, sondern nur mit dem DVBViewer selbst.

 

Sollte ich hier die Umschaltzeiten mal besser hinbekommen haben, dann bleibt noch abzuwarten, ob das Umschalten mit verschlüsselten Sendern ähnlich schnell funktioniert. Sonst müsste ich auch hier nochmal Hand anlegen (das ist aber wohl eine andere Geschichte :))

 

LG,

Niko

Link to comment

 

 

- Einbau einer minimalistischen GPU in den Server. Vielleicht hilft das ja beim schnelleren Umschalten. An den Clients konnte man erkennen, dass die Umschaltzeit vermutlich auch von der GPU abhängt und deshalb dachte ich mir, dass das helfen könnte. Auf der anderen Seite habe ich mal gelesen, dass das beim RecordingService nichts bringt, weil der das Signal nicht angreift (stimmt das)?

Nützt dir im Server nichts, der RS greibt nur das Signal ab und leitet es weiter, ihm ist es egal welche GPU im Server arbeitet.

 

Der link von nuts sagt eigentlich schon alles, aber hier trotzdem noch ein paar Tipps :) villeicht hilft es dir ein wenig

 

Da du XBMC als Client nutzt würde ich mal bei xbmcnerds.com ein wenig lesen, dort gibst gute Tipps zu LiveTV mit RS.

http://www.xbmcnerds.com/index.php?page=Board&boardID=23&pageNo=1

Dort findest du auch links zu XBMC -Versionen mit schnelleren Umschaltzeiten :)

z.B. diese hier

https://www.scintilla.utwente.nl/~marcelg/xbmc/prebuild.html

Ob die wirklich schnellere Umschaltzeiten haben, kann ich auch mangelnder Erfahrung nicht sagen.

 

XBMC als LiveTV Cliente habe ich vor längerer Zeit aufgegeben, der Grund waren eben die langen Umschaltzeiten :)

Aber in der Zwischenzeit scheint es besser geworden zu sein.

 

Was den Raspi angeht, würde ich dir raten Openelec zu testen

http://openelec.tv/get-openelec/download/viewcategory/10-raspberry-pi-builds

http://www.xbmcnerds.com/index.php?page=Thread&postID=154034#post154034

 

Gruß

Reiset

 

 

 

 

Link to comment

Hmm... habe gerade einen Test mit OpenELEC hinter mir (mit der letzten Beta-Version).

Damit funktioniert XMBC durchaus ein wenig besser, als wenn man es selbst unter raspberian installiert.

Aber leider auch nicht sooo viel besser. Je nach Signal liegen die Umschaltzeiten bei etwa 4-5 sec im best case (SD auf SD Sender) und bei 30sec im Worst Case (FullHD auf FullHD Sender -> hatte ich vorher noch nie getestet). Im Normalfall (HD auf HD bzw. SD auf HD) liegen die Umschaltzeiten bei immer noch knapp 10sec (geschätzt würde ich sagen, dass das etwa 1sec besser ist als bei respbian mit XBMC).

 

Die Idee mit einer Grafikkarte im Server kann ich dann wohl auch ruhen lassen :-)

 

Dann bleiben mir noch zwei Fragen:

- Gibt es eine gute und halbwegs günstige Alternative für einen rapsberry als RS Client (mit Bedienung über HDMI)? Kann das bspw. ein cubieboard (und ist es überhaupt schneller)?

- @Reiset: Du sagtest, dass du XMBC wegen der Umschaltzeiten nicht mehr einsetzt. Was verwendest du seither (oder wurde das ersatzlos gestrichen)?

 

LG,

Niko

Link to comment

Bei mir wurde XBMC komplett gestrichen, benutze auf meinen Clients DVBViewer Pro (siehe Signatur)

Meine Clients (Win 8.1) booten direkt mit DVBViewer, also kein Desktop/Metro-Oberfläche zu sehen.

Das booten dauert (Dank SSD) so um die 20 Sekunden bis zum Bild.

Bin mit den Umschaltzeiten recht zufrieden, siehe meinen link oben (Diskussion zu den Umschaltzeiten).

 

Auch für die Wiedergabe von Filme/Serien übers LAN wird DVBV benutzt (siehe Plugins Myseries und Myvideos)

ist zwar nicht so schön wie XBMC, aber für meine Bedürfnisse reicht es vollkommen.

 

Für den Preis vom Raspi wirst du nichts "Besseres" finden, eventuell einen kleinen Client auf Basis eines MB mit integrierten Prozessor

Preislich aber weit entfernt vom Raspi.

 

Bespiel:

Asrock Q1900-ITX - 64 Euro

http://geizhals.de/asrock-q1900-itx-90-mxgrs0-a0uayz-a1102397.html

oder Asrock D1800B-ITX - 47 Euro

http://geizhals.de/asrock-d1800b-itx-a1089504.html

 

dazu:

Kingston 4GB Value Ram - 40 Euro

http://geizhals.de/kingston-valueram-so-dimm-4gb-kvr16s11-4-a783537.html

SSD Sandisk Ultra Plus 64GB - 40 Euro

http://geizhals.de/sandisk-ultra-plus-notebook-64gb-sdssdhp-064g-g25-a890678.html

MS-Tech CI-70 Gehäuse inbegriffen 120 Watt externes Netzteil. - 65 Euro

http://geizhals.de/ms-tech-ci-70-a1045474.html

zusammen circa 190 - 210 Euro

 

Ansonsten:

Zotac ID 18 - circa 120 Euro + Ram + SSD

http://www.technikaffe.de/anleitung-19-zotac_zbox_id18_mit_xbmc_unter_openelec

Intel NUC DN2820FYKH circa 130 Euro + Ram + SSD

http://www.technikaffe.de/anleitung-114-test_der_intel_nuc_dn2820fyk_unter_openelec_xbmc_und_win_7

und noch so einige Fertigsysteme, aber preislich kommen die nicht an den Raspi ran.

 

Habe auch einige Zeit mit den Raspi rumgespielt, aber glücklich und zufrieden bin ich damit nicht geworden, aber das ist nur meine persönliche Erfahrung,

es gibt eine Menge Leute (siehe XBMCnerds.com) die damit zufrieden sind.

Mit Cubiebord und Co. wird es auch nicht viel besser sein.

 

Gruß

Reiset

 

 

 

Link to comment

Hmm.. dann überlege ich mal weiter und lese ein wenig bei den xbmc nerds nach :-)

Gibt es denn ansonsten bei den Clients Erfahrungen, ob AMD oder Intel besser funktioniert. Momentan gilt ja die Richtlinie, dass Intel deutlich besser CPUs verbaut, AMD aber noch immer bessere GPUs in den APUs verbaut. Was ist denn hier wichtiger (CPU oder GPU)?

 

Bei den Clients brauche ich wohl auch noch ne Windoofs Lizenz.... alleine das macht die Teile schon deutlich teurer als einen Raspi ;-(

Link to comment

 

 

Gibt es denn ansonsten bei den Clients Erfahrungen, ob AMD oder Intel besser funktioniert.

Habe beide, und bin mit beiden zufrieden.

Aber würde eher zu Intel für einen HTPC greifen, ist stromsparender und einfacher zu kühlen

 

 

Was ist denn hier wichtiger (CPU oder GPU)?

Auf den Clients die GPU, also theoretisch AMD ist besser,

aber auch die Intel HD Graphics funktioniert gut, auch in "schwächeren" Versionen.

In meinen Celerons werkelt die "kleine" INTEL HD Graphics 2500, habe damit keine Probleme auch bei den HD+ Sendern also 1080i.

 

Du kriegst eine Windows 7 Home Version für unter 30 Euro über Ebay.

 

Gruß

Reiset

Link to comment

Momentan denke ich an die neuen Zotac ZBox Nano Boxen:

http://geizhals.at/zotac-zbox-ci320-nano-zbox-ci320nano-be-a1123321.html

Wenn hier die GPU zu schwach sein sollte, dann könnte ich den PC immer noch als Office PC verwenden (und damit meinen alten Core i3 der ersten Generation ablösen).

 

Es gibt von den Zotac Nano Boxen auch noch Variaten mit i3 und i5, welche dann aber statt 7.5Watt schon etwas mehr verbrauchen (11.5 Watt).

Anscheinend gab es bei den ersten i3 Probleme mit der Kühlung, welche mittlerweile aber behoben sind.

 

Eine Alternative wären auch noch die ZA320 Varianten von Zotac. Die verwenden dann keinen Celeron, sondern eine AMD A6 APU (allerdings knappe 40€ teurer).

Da hat dann die CPU nur mehr ein Ghz (als Quad-Core), dafür wäre eine gute GPU mit an Board (Radeon HD 8250).

 

Ich würde momentan mal auf diesen System openElec ausprobieren (vermutlich in Kombination mit einem externen HDMI CEC Adapter... damit komme ich - ohne Windows - wohl gesamt auf knappe 250€)
Wenns dann mit den Umschaltzeiten nicht klappt, bleibt immer noch der Kauf einer Windows Lizenz.

Edited by Niko_K
Link to comment

Das klingt doch schon mal gar nicht soo schlecht.

Die Temperaturprobleme werden weniger, die Treiber sind vorerst auch kein Thema (da kein Windows drauf kommt) und die werden wohl auch mit der Zeit stabiler.

 

Jetzt würde ich OpenELEC per NetBoot (PXE) zur Verfügung stellen (dann spar ich mir die SSD und nochmals 50€) und gut is :-)

 

Alles in allem werde ich mir wohl (sobald wieder lieferbar) so ein Teil besorgen und dann mal testen. Wenns denn dann klappt wird noch eine zweite besorgt :)

 

Auch wenn sicher noch die eine oder andere Frage auftauchen wird: vorerst mal vielen Dank!

 

Glaubt ihr denn, dass das mit dem Netboot eine gute Idee ist?

Link to comment

 

Das ist genau das AddOn (auch in der neuesten Version), das ich verwende.

Leider sind die Umschaltzeiten auf dem Raspi damit nicht wirklich bei 1-2 Sekunden (sondern wie oben angegeben im Worst Case bei 30sec)

Link to comment

Also 30 Sekunden bekomme ich nicht hin, egal welche Auflösung oder verschlüsselt unverschlüsselt. max 3-4 Sekunden und ich hab immer Bild.

 

raspi+openelec. Gotham 13.2

 

Ohne RTSP sogar noch schneller....

Link to comment

Und das mit dem RecorderService und LiveTV?

Was für Software, welche Versionen und was für DVB-Hardware verwendest du denn da genau?

Worin liegt denn hier dann genau der Unterschied zu meinem Setup? (ist ja interessant, dass es da so einen Unterschied gibt :))

Link to comment

Ja RecordingService, als Hardware kommen 4 DD Tuner zum Einsatz, wie ich entschlüssle darf ich hier aber nicht sagen ;-)

Link to comment

Moin Jungs,

 

ich kann die Aussage von VinoRosso bzgl Umschaltzeiten zum Großteil bestätigen.

 

Bei mir werkelt ein HP Microserver N54L mit 4 DD DVB-C-Tunern und CI-Modul (Sky und Kabel Deutschland Pay-TV-Abo) unter dem RS.

Die Umschaltzeiten auf den DVBViewer-Clients und den XMBC mit DVBViewer Addon 1.9.15 unterscheiden sich nicht großartig.

Sie liegen bei 1-4 Sekunden.

 

Einzige Ausnahme sind die Raspis (habe 3 Stück mit OpenELEC 4.0.7 und DVBViewer 1.9.15 im Einsatz):

 

Hier kann es klappen, dass ein Sender innerhalb von 1-3 Sekunden da ist, öfter aber auch streikt mal der einen oder andere Sky-HD-Sender.

 

Das verwirrende ist hierbei, dass dann ein Neustart des Servers Abhilfe schafft, nicht der eines der Raspis.

Link to comment

Timeshift ist bei mir auf den raspis jedenfalls deaktiviert, das wirkt sich auch negativ auf die Umschaltzeiten aus, inwieweit das in letzter Zeit verbessert wurde kann ich mangels test nicht sagen, vllt ist das inzwischen auch gefixed.....

Link to comment

Timeshift ist bei mir auf den raspis jedenfalls deaktiviert, das wirkt sich auch negativ auf die Umschaltzeiten aus, inwieweit das in letzter Zeit verbessert wurde kann ich mangels test nicht sagen, vllt ist das inzwischen auch gefixed.....

Ich habe auf einem Timeshift aktiviert und auf einem anderen deaktiviert.

Die Umschaltzeiten sind ohne Timeshift besser, aber mein Problem tritt bei beiden auf.

Link to comment

Hmm... dass der Neustart des Servers hier Abhilfe schafft, wundert mich nun aber doch sehr.

 

Ich konnte übrigens beobachten, dass direkt beim Start von OpenELEC die Umschaltzeiten gut waren (ARD SD auf ZDF SD), aber dann immer schlechter wurden (und schließlich bei ServusTV DE auf ServusTV AT bei 30sec lagen).

Liegt es vielleicht doch virtualisierten Server (der dann auch noch ohne GPU auskommt)?

Ich werde am Wochenende evtl. mal einen RS auf meinem besseren Client installieren und dann mit dem OpenELEC am Raspi verbinden.

Link to comment

Hmm... dass der Neustart des Servers hier Abhilfe schafft, wundert mich nun aber doch sehr.

 

Das wundert mich genauso.

Bestimmt hängt das mit dem Zugriff auf die Tuner und deren Entschlüsselung durch das CI zusammen.

 

 

 

 

Ich konnte übrigens beobachten, dass direkt beim Start von OpenELEC die Umschaltzeiten gut waren (ARD SD auf ZDF SD), aber dann immer schlechter wurden (und schließlich bei ServusTV DE auf ServusTV AT bei 30sec lagen).

Liegt es vielleicht doch virtualisierten Server (der dann auch noch ohne GPU auskommt)?

Ich werde am Wochenende evtl. mal einen RS auf meinem besseren Client installieren und dann mit dem OpenELEC am Raspi verbinden.

 

Die GPU des RS ist vollkommen nebensächlich.

Mein Server ist ein HP Microserver. Die Grafikeinheit dieses Geräts verdient den Namen kaum.

Link to comment

Hallo, Leute!

 

Ich habe auch ein Umschaltzeitenproblem, allerdings habe ich an meinem DVBV RS Server einen Windows Client mit XBMC Gotham 13.1. Kann man da auch was optimieren? Die Zeiten nerven tierisch, sind auch um die 30 Sekunden herum. Client ist ein Turion64X2 HP-Laptop 2GHz mit Win7, 2GB RAM und ist per LAN am RS Server dran. Das Bild ist nach dem Umschalten sehr flüssig (bei SD) und hat keine Aussetzer. HD bekomme ich an diesem Client mit XBMC nicht hin (ruckelt sehr), aber das ist glaube ich ein Thema für die XBMCNerds ;-).

 

Umschaltzeiten sind am selben Client mit DVBViewer Client zwar besser, aber das Bild ist bei SD bedeutend ruckeliger, HD geht eigentlich. Ein weiterer Client mit DVBViewer hat ebenfalls keine Umschaltprobleme.

 

Zoli

Link to comment

Hi,

 

auf so einer hardware wuerde ich an HD nicht denken. Der DVBViewer ist da der bessere client. Deine besten Chancen hast du wenn du mit dem renderer und den codecs im DVBViewer experiementierts. LAV ist immer eine gute Idee wenn DXVA tut. Sonst den von Microsoft versuchen. Neben codec und renderer kannst du noch Aero mal abschalten. Die transparenten Fensterrahmen von Win7 verbrauchen sehr viel Grafikleistung.

 

Ich hatte eine ganze Weile einen Atom mit GMA950 Grafik und SD ist damit sehr gut moeglich. Ich habe sogar noch ein IBM T20 mit Win2000 und selbst dort laeuft SD problemlos. Allerdings nur weil ein auf den S3 chip optimierter MPEG2 decoder dabei ist.

Edited by mague
Link to comment

Hi,

 

auf so einer hardware wuerde ich an HD nicht denken.

 

Das sehe ich komplette anders.

 

HD-Material kann von viel schwächeren Geräten abgespielt werden.

Entscheidend ist, ob diese Grafikbeschleunigung per Hardware unterstützen.

Ich habe 2 Atom Tablets mit Windows 8 (Wetab und HP Elitepad 900G1).

Auf beiden läuft sowohl der DVBViewer als auch XBMC (13.2).

Beide sind in der Lage, HD-Material abzuspielen. Einzig die BD-Rips machen auf dem älteren der beiden ein wenig Probleme.

Beide werden oft zum Fernsehen via DVBViewer genutzt. Die Programme kommen von einem TV-Server.

 

Seit Gotham 13.2 Beta ist auf dem Tablet mit Intel HD-Grafik auch das Abspielen von HD-TV und HD-Filmen via XBMC möglich (vorher klappte das nur mit dem DVBViewer, der aber nicht sehr gut mit dem Patschehändchen zu bedienen ist).

 

Das Problem mit den Umschaltzeiten kenne ich auch nicht.

Die Programme werden bei mir zwischen 1 und 5 Sekunden gewechselt.

Ausnahme sind die 3 Raspis, wie von mir oben schon geschrieben.

Edited by goscho
Link to comment

 

Das sehe ich komplette anders.

 

HD-Material kann von viel schwächeren Geräten abgespielt werden.

Entscheidend ist, ob diese Grafikbeschleunigung per Hardware unterstützen.

 

Richtig.

 

Ich kann mich jetzt taeuschen, aber das schnellste Turion hatte einen NVidia 6150 Go. Die kann HD schon darstellen, vor allem mit dem Pure codec.

 

Aus eigener Erfahrung mit einer Intel 3650 weiss ich das die GPU bzw. der Bus eng wird wenn mit der GPU decodiert wird und gleichzeitig beschleunigt dargestellt wird. Es ging immer nur hardware decoding oder hardware beschleunigte Darstellung (custom EVR). Und die 3650 ist deutlich flotter als die 6150.

 

Wenn HD auf dem HP laeuft, dann freue ich mich. Die Luft wuerde ich dafuer aber nicht anhalten :)

Link to comment
  • 2 weeks later...

Also ich habe vorerst meine Versuche mit dem Raspi aufgegeben.

Auch nach mehrern Versuchen konnte ich die Ursache nicht finden, könnte mir aber vorstellen, dass es an Überhitzung lag. Ich konnte nämlich beobachten, dass OpenElec für die ersten paar Senderwechsel ausreichend schnell (<5sec) war und dann langsamer wurde (im Extramfall auf die angesprochenen 30sec).

Mein momentaner Client ist eine Zotac ZBOX CI520.

Damit funktioniert alles ohne Probleme. Alle Umschaltzeiten (egal welcher Sender) bei 2-3sec. Damit kann ich leben :-)

Weitere Optimierungen könnte man jetzt wohl am Netzwerk selbst und am OctopusNet vornehmen (evtl. Karten direkt in den Server einbauen).

Da ich momentan aber zufrieden bin, werde ich daran wohl nichts ändern.

Wenn es noch von interesse sein sollte, habe ich meinen RS-Server auf Windows 8.1 umgestellt (da die Windows7-Lizenz eine Uni-Lizenz ist und diese alle paar Monate ins Uni-Netz will... das ist mit meinem RS-Server schwierig, also musste Windows 8.1 gekauft werden). Wenn die Lizenzkosten für Windows nicht immer wären, dann würde ich mich auch mit DVBViewer als Client spielen, aber so ist mir das ein wenig zu kostspielig und da bleibe ich lieber bei OpenELEC :-)

Link to comment

Also ich habe vorerst meine Versuche mit dem Raspi aufgegeben.

Auch nach mehrern Versuchen konnte ich die Ursache nicht finden, könnte mir aber vorstellen, dass es an Überhitzung lag. Ich konnte nämlich beobachten, dass OpenElec für die ersten paar Senderwechsel ausreichend schnell (<5sec) war und dann langsamer wurde (im Extramfall auf die angesprochenen 30sec).

Mein momentaner Client ist eine Zotac ZBOX CI520.

Damit funktioniert alles ohne Probleme. Alle Umschaltzeiten (egal welcher Sender) bei 2-3sec. Damit kann ich leben :-)

Das sind aber gewaltige Preissprünge, vom Raspi ( ca. 50,- €) zur ZBOX (über 200,- €). Klar, das da auch mehr Power erwartet werden darf.

 

Bei mir sind 3 Raspis im Einsatz.

Einer auf der Terrasse mit aktivem Lüfter (wurde auch mal richtig heiß, als wir noch Sommer hatten, war glaube ich Ende Mai / Anfang Juni)

Zwei bei Kindern mit Passiv-Kühlern (einer zusätzlich im Alu-Gehäuse).

 

Es stimmt, dass man kein nervöser Zapper sein darf, wenn man einen Raspi zum Fernsehen nutzt. Auch kommt es bei mir öfter mal vor, dass das Umschalten zu einem HD-Sender nicht klappt. Dann wird die SD-Variante genutzt.

 

Ansonsten ist es schon nutzbar.

 

Was ich allerdings zuletzt häufiger hatte, waren nicht mehr nutzbare USB-Sticks (alles Kingston), die auch an Raspis als Device für die Daten hingen. Das muss aber nichts mit den Raspis zu tun haben, denn es betraf auch ein paar "mobil" genutzte USB-Sticks.

Link to comment
  • 1 month later...

Hallo zusammen,

 

ich hab ein Problem. Bin gerade dabei meinen HTPC als Server mit dem Recording Service einzurichten. Ich empfange über SAT mit einer Hauppauge Nova HD-S2 Karte und habe ein Problem mit Umschaltzeiten, die definitiv vom RS kommen.

Egal ob ich als Frontend XBMC (ohne Timeshift) oder das Webinterface vom RS im Browser nutze, ich habe Umschaltzeiten selbst bei SD auf SD von ca. 7-8 Sekunden, sowohl lokal auf dem Rechner als auch auf einem entfernten Notebook (Netzwerk somit als Fehlerquelle ausgeschlossen).

Dabei zeigt das Log, dass RS bereits 6 Sekunden mit sich selbst beschäftigt ist, bevor der Stream rausgereicht werden kann:

 

14.10.14 00:51:24.941 SetStandbyblock TStreamClient

14.10.14 00:51:24.941 TRecordingEngine AddReference TStreamClient: 1
14.10.14 00:51:29.872 TBDAHauppauge Opendevice bvHauppauge
14.10.14 00:51:29.872 tStreamClient AllocateHardware Hauppauge WinTV 88x DVB-S/S2 Tuner/Demod (5)
14.10.14 00:51:29.872 TBDAHauppauge SetTuner TType: 1, Freq: 11954, Symrate: 27500, LOF: 10600, Tone: 1, Pol: 0, DiseqC: 3, FEC: 3, APID: 120, VPID: 110, PMT: 100, SID: 28006, SatMod: 1, DiseqCVal: 0, NID: 1, Flags: 24
14.10.14 00:51:30.292 AllocateHardware Hauppauge WinTV 88x DVB-S/S2 Tuner/Demod (5)
14.10.14 00:51:33.209 Release Hauppauge WinTV 88x DVB-S/S2 Tuner/Demod (5)

 

An der Hardware kann es nicht liegen, denn mit DVBLink habe ich nach 2-3 Sek. im XBMC ein Bild und im DVBViewer selbst sind die Umschaltzeiten wie immer spitze (1-2 Sek.).

Ich konnte beobachten, dass der DVBViewer Pro Recording Service im Gerätemanager beim Umschalten auf 50% Last geht (somit einen Core komplett auslastet). Nachdem der Stream angelaufen ist, geht die Last runter auf 2-6%. Beim nächsten Umschalten wieder das gleiche. DVBLink im Vergleich bleibt immer bei konstanter CPU-Last von 3-7%, auch beim Umschalten.

 

Ich hatte schon versucht alles Überflüssige im RS abzuschalten (DVB Server, Upnp, RTSP und selbst EPG), aber die Last beim Umschalten bleibt.

Woran könnte das liegen und hat jemand einen guten Tipp für mich? Möchte gerne den RS als Backend einsetzen können.

 

Viele Grüße

 

buddy101

Link to comment

Ich lese jedoch immer, dass manche mit XBMC und dem RS Umschaltzeiten von 1-2 Sek haben. Wie ist das möglich, wenn alleine der RS bei mir schon 6 Sek braucht?

Sicher, dass es kein Bug ist? Was macht der RS, dass ein CPUS Kern über 5-6 Sek voll ausgelastet ist? Wie ist das bei anderen Konfigs? Steigt dort die CPU Last auch erheblich beim Umschalten?

 

Fragen über Fragen :)

Link to comment

Da XBMC wohl bei jedem Sendewechsel die TV Karte komplett frei gibt und neu initialisiert. Ist wohl die TV Karte bzw. deren Treiber sehr entscheidend für die Umschaltzeit mit RS und XBMC .

 

Hier wird das ganze deutlich besser aber auf englisch erklärt:

http://www.DVBViewer.tv/forum/topic/54998-slow-channel-switching-in-xbmc/?p=411407

 

Beim Streamen über das Webinterface werden die Video Daten neu encodiert. Das sorgt insgesamt für eine Verzögerung bei der wiedergab. Und das sieht man dann bei jedem Sendewechsel.

 

Und auch bei der Playlist Geschichte sind die Umschaltzeiten länger. Als im DVBViewer da bei jedem Sender Wechsel die Verbindung komplett ab und wieder neu auf gebaut wird. Und natürlich auch die TV Karte freigegeben und neu initialisiert wird.

Link to comment

Da XBMC wohl bei jedem Sendewechsel die TV Karte komplett frei gibt und neu initialisiert. Ist wohl die TV Karte bzw. deren Treiber sehr entscheidend für die Umschaltzeit mit RS und XBMC .

 

Hier wird das ganze deutlich besser aber auf englisch erklärt:

http://www.DVBViewer.tv/forum/topic/54998-slow-channel-switching-in-xbmc/?p=411407

 

Beim Streamen über das Webinterface werden die Video Daten neu encodiert. Das sorgt insgesamt für eine Verzögerung bei der wiedergab. Und das sieht man dann bei jedem Sendewechsel.

 

Und auch bei der Playlist Geschichte sind die Umschaltzeiten länger. Als im DVBViewer da bei jedem Sender Wechsel die Verbindung komplett ab und wieder neu auf gebaut wird. Und natürlich auch die TV Karte freigegeben und neu initialisiert wird.

Hmm... ist das hier XBMC oder das DVBViewer-Plugin im XBMC?

 

Die letzte Frage aus dem (englischen) Link ist aber auch noch nicht beantwortet: Könnte man das Command im RS nicht einfach ignorieren (etwa nach der Art, wenn eine Verbindung zur TV-Karte freigegeben wird tue das 5 Sekunden verspätet, aber nur dann, wenn nicht die selbe wieder initialisiert werden sollte - ka... sowas in der Art halt :-))

Link to comment

Die letzte Frage da solltest du im Kontext der Antwort von Griga da sehen.

Das heißt es kann sehr leicht zu Problemen führen (wenn die ganze wiedergebe Struktur da nicht auf fehlerhafte Daten am Anfang nach einem Spielerwechsel eingestellt ist). Ich glaube nicht das der RS da irgendwelche Kommandos herausfiltern wird.

 

Wenn wäre das was für das XBMC-Plugin was die Verbindung zu RS herstellt. Ich habe aber keine Ahnung ob das von der strukturiert her so was leisten könnte.

 

Und so weit ich weiß geht die XBMC RS Verbindung nur mit dem DVBViewer-Plugin in XBMC (OK auch noch per UPnP aber das ist eigentlich für die Datei wiedergebe gedacht und LiveTV läuft da nur mit ein paar Tricks)

  • Like 1
Link to comment

Hmm... wird denn das DVBViewer-Plugin in XBMC nicht auch vom DVBViewer-Team entwickelt? Oder macht das Plugin das XBMC Team?

Die Antwort von Griga lässt doch vermuten, dass das Neuinitialisieren eher eine Art "Symptombehebung" als Ursachenforschung ist (we learned by experience...).
Aber im Prinzip hat Griga da schon recht... immer noch besser mit langsamen Umschaltzeiten leben als da schwerwiegendere Probleme zu bekommen (nur könnte das auch dazu führen, dass XBMC-User vermehrt zu DVBLink wechseln, oder?)

Link to comment

Portisch hatte mal mit der Hilfe von Lars_MQ versucht einiges zu überarbeiten.

http://forum.xbmc.org/showthread.php?tid=140645&pid=1514502#pid1514502

wie viel davon angekommen ist oder übrig ist kann ich nicht sagen.

 

Aber die Entwicklung erfolgt seit dem ausschließlich auf der XBMC Seite.

Das heißt das Topic da ist die deutlich bessere Anlaufstelle.

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

Link to comment

XMBC hat 2 Probleme:

1. Setup/Teardown bei jedem Kanalwechsel.

Sehe auch nicht wie der RS darauf intelligent reagieren sollte. Er kann ja nicht wissen was der Client vor hat!

Also das muss im Plugin oder in XMBC selbst geändert werden.

http://forum.xbmc.org/showthread.php?tid=197237

 

2. Der Demuxer (dvbsource im DVBViewer) verlangsamt den Kanalwechsel zusätzlich.

Bestimmte Plugins haben daher eigene Demuxer eingebaut.

Der Punkt muss auch von XBMC oder den Plugin angegangen werden.

 

Imho solltet ihr für Verbesserungen dort aktiv werden.

Edited by nuts
Link to comment

OK... das sind sehr interessante Details.

Im Bestfall sollte man das wirklich bei XBMC lösen (habt mit überzeugt *fg).

Ich werde mal sehen, ob man da wieder einen Thread reaktvieren kann (gibt ja doch schon den ein oder anderen Beitrag).

 

Das Einzige was mir etwas Sorgen bereitet, ist dass eben andere Softwareprodukte schneller Umschalten (evtl. weil sie einen eigenen Demuxer implementiert haben... keine Ahnung wieso genau).

Das könnte eben dazu führen, dass XBMC-Nutzer diese anderen Produkte als besser empfinden (auch wenn das Problem eigentlich in XBMC liegt).

Link to comment

Hier war mal ein Ansatz für das Problem: https://github.com/xbmc/xbmc/pull/3590
Die wichtigen Stellen:

 

I really dislike this. Please fix ffmpeg :(.

 

 

A new mpegts demuxer would be a very good thing anyway since ffmpegs is rather bad.

 

Es tut sich aber in diese Richtung mal wieder was: https://github.com/xbmc/xbmc/pull/5487

 

Bezüglich Setup/Teardown gab auch schon Vorstöße von uns:

http://forum.xbmc.org/showthread.php?tid=166995&page=2

Leider kriegt man @XBMC überhaupt keine Diskussion hin. Mich nervt das und ich werde da keine Zeit mehr investieren.

Wer Verbesserungen auf den Weg bringen will sollte dort darauf hinweisen!

Link to comment

Habe mal im XBMC Forum ein Upvote gemacht. Vielleicht ruft man das damit ja wieder in die Köpfe der Entwickler (oder zumindest an die Spitze der Forumseinträge... naja... die Hoffnung stirbt zum Schluss).

Dass es hier einen nur 3 Tage alte (!!) PR gibt bzgl. dem demuxing, finde ich allerdings sehr erfreulich... vielleicht tut sich hier ja doch noch was :-)

Link to comment
×
×
  • Create New...