Hi,
ich möchte noch anmerken das der NetCeiver einen IPv6 Multicast-Stream ausgibt, somit müsstest Du ihn, je nach Netzwerk, in ein VLAN einsperren damit er Dir nicht das ganze Netzwerk flutet. Ein WLAN-Stream ist damit auch nicht wirklich möglich.
Ich finde die Lösung mit dem NetCeiver somit doch recht unflexibel, und würde jederzeit einen richtigen VDR-Server bevorzugen.
Gruß,
Knallbert
ZitatOriginal von Knallbert
ich möchte noch anmerken das der NetCeiver einen IPv6 Multicast-Stream ausgibt, somit müsstest Du ihn, je nach Netzwerk, in ein VLAN einsperren damit er Dir nicht das ganze Netzwerk flutet.
Ich klinke mich hier mal ein, da ich auch grad für die Sanierung meines Altbaus die Netzwerkverkabelung plane:
Eigentlich ist Multicast ja genau das richtige zur Streamverteilung, aber weiß jemand, ob aktuelle Switches das noch wie früher als Broadcast implementieren? Bei mir in den Keller-Serverraum werde ich wohl eínen 16- bis 20-Port-Switch stellen, der sollte eigentlich Multicast-fähig sein...
Grüße,
Carsten
ZitatOriginal von hsteinhaus
Das hilft sicher, das Haus vor dem Abbrennen zu bewahren, allerdings wage ich zu behaupten, dass bei einem direkten Treffer der Schüssel trotzdem etliche 100 (wenn nicht gar 1000V) direkt im Server anliegen. Weiters habe ich noch keinen mehrstufigen Blitzschutz für SAT-Kabel gesehen. Absicherung des elektrischen Hausanschlusses ist sicher nicht verkehrt, aber in der Zeit von unterirdischen Stromanschlüssen m.E. das weit kleinere Problem.
Aber den Wert seines Servers und dessen Daten muss jeder selbst beurteilen. Sofern dort nur ein VDR drauf läuft, kann man sicher auch mit einem solchen Risiko gut leben.
Hi,
Also bei mir war das bisher kein Problem, Server läuft seit gut 4,5 Jahren, hatte bishre noch keinen dierekten Blitz in der SAT-Schüssel - hatte aber schon 2x Überspannungsschäden, da der Blitz in die Überland-Leitung einschlug.
.........
Aber unter den Gesichtspunkten wäre auch ein LAN mit Kabel nix - dann wie o.g. Server über LWL isolieren...........
Grüße
Hey das teil ist genial als vdr
endlich mal ein großes display für graph-tft, mit touchscreen,
vdpau, gigabitlan, hdmi-out,
nur die festplatte ist ein bischen klein 
Wenn mein Auto etwas grösser wäre würde ich den glatt in die Mittelkonsole einbauen. Landrover Defender mit VDR-HDTV das wär doch geil!
Sorry fürs 
musste sein...
ZitatOriginal von sk8ter
Schau dir mal den an
So als Terminal? Etwas grosser Bildschirm vielleicht, aber wenn das Haus auch gross ist...
Das ist ja mal ein geniales Teil - und genau der richtige PC (ION+Atom) ist auch integriert. Einziges Manko: etwas unzweckgemäße Auflösung.
Das gibt doch mal nen schönen Küchenfernseher ab...
Zitat
Aber unter den Gesichtspunkten wäre auch ein LAN mit Kabel nix - dann wie o.g. Server über LWL isolieren...........
Eben - aber LWL ist nun wirklich kein Luxusartikel mehr. Ich hab einen kleinen 4-Port-Switch mit SFP neben dem VDR stehen und das andere Ende läuft im regulären Switch auf (ebenfalls per SFP). Kosten: < 100 EUR dank E-Bucht (Gigabit).
Zum Netceiver: ich war schon mal ganz kurz davor, einen zu kaufen. Leider waren meine Terminvorstellungen mit den Lieferzeiten von Reel leicht inkompatibel 
Weiterhin gibts noch einen Schönheitsfehler in der Zusammenarbeit von VDR und Netceiver (laut Reel): Der Netceiver unterstützt im Gegensatz zum VDR keine Tuner-Priorisierung. Wenn man nun mehr Clients als Emfpangskarten hat, kann es passieren, das Live-Clients dem VDR den letzten Tuner belegen und damit Aufnahmetimer ins Leere laufen. Ein streamdev-VDR hat in dem Fall m.E. ein deutlich sinnvolleres Verhalten, er beschränkt das Live-TV auf die aktuell verfügbaren Transponder, zieht aber in jedem Fall die Aufnahmen durch.
Grüße,
Holger
ZitatOriginal von hsteinhaus
.
.
Zum Netceiver: ich war schon mal ganz kurz davor, einen zu kaufen. Leider waren meine Terminvorstellungen mit den Lieferzeiten von Reel leicht inkompatibel
Grüße,
Holger
Wie wäre es mit einem Server, der den Netceiver bedient und die Clients ??
Dann könnte man doch das Problem lößen ??
ATX-Board, 4x DVB-S(2) (je nach experimentierfreude auch dual dvb-s2-karten) und gut ist...
streams per xine oder xineliboutput ausliefern und den/die vdr(s) am server lassen. am touch braucht dann wirklich nur decodiert werden.. im prinzip können das dann diskless systeme sein...
so würd ich das machen... bzw so rennt das bei mir.. übrigends fast störungsfrei.. die usv ist zu klein/alt.. da kommt was richtiges jetzt her... server wird auch neu.. aber nur weil die alten boards zu wenig sata anschlüsse haben und mir port multiplier zu teuer sind...
virtualisieren wär mir zu blöd.. hab das sowieso noch nicht verstanden warum man den heim(!) ftp und http vom vdr trennen will... naja andere geschichte.. möglich ists auf jeden fall.. würde aber dann doch richtig virtualisieren ala vmware.. dann kann man wenigstens ohne probs auf einen anderen rechner migrieren ohne xen-versions-kopfweh...
73
Zitat
Wie wäre es mit einem Server, der den Netceiver bedient und die Clients ??
Dann könnte man doch das Problem lößen ??
Im Prinzip ja. Nur dann könnte man in den Server ja gleich die Karten stecken. Das faszinierende am Netceiver ist ja, dass man keinen aus Server braucht bzw. dass man wirklich einen Aufnahmeserver einfach als VM realisieren kann, die nichts weiter als einen Netzwerkzugang braucht.
xine-Only-Clients:
Das muss ich irgendwann unbedingt auch mal ausprobieren. Hast Du die Lösung mal mit einer "echten" streamdev-Lösung verglichen, bei der je ein VDR auf dem Client läuft (z.B. hinsichtlich Umschaltzeiten)?
Grüße,
Holger
nachdem du ja am client die decodiererei machst könnte im server problemlos auch ein atom rennen.. vorausgesetzt du hast dort nicht noad im hintergrund rennen oder tust den stream on-fly für schwachbrüstige clients runterrechnen...
ein paar zahlen:
produktiv-VDRserver1
2:24pm an 29 Tage 21:27, 4 Benutzer, Durchschnittslast: 0,17, 0,33, 0,35
test-vdrserver:
14:25:22 up 28 days, 19:07, 2 users, load average: 0.00, 0.00, 0.00
der produktive ist gleichzeitig surf-station, nas, boot-sever, ... der test-vdr tut bis auf mark-ad eigentlich nix
der test-vdr ist eine Sempron LE-1620@2.4ghz, der produktive ein 4850e@1000mhz
anscheinend rennt der sempron ohne powernow... werd' ich gleich ändern
man sieht also, das man für einen server eigentlich keine übertriebene cpu-leistung braucht...
wichtig ist eigentlich nur der plattendurchsatz und der ram (viel hilft hier viel)...
hd kann nur ein client kann daher nicht von multi-stream load berichten
im prinzip ists wurscht weil nur daten weitergeschaufelt werden und sonst nix passiert...
64bit ist mit den atoms kein prob.. bei mir rennt überall slackware64
einsfestival hd am server (der sempron 1620@1Ghz)
<code>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28046 root 20 0 408m 77m 6808 S 3.0 4.1 40:04.50 vdr.Test_vdr17
</code>
am client (atom 330 mit ion)
<code>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5566 root 20 0 339m 27m 8920 S 11 1.6 0:30.57 vdr-sxfe
</code>
mit dem bösen plugin bin ich mit orf1hd irgendwo bei 40% last(@2,4ghz)...
ich würd mir da also nicht so viele sorgen machen.. notfalls so einen 45W quadcore.. so 605e oder so.. kostet auch nicht die welt und du hast garantiert genug power für alles was in naher zukunft daherfliegt...
brauchen tust ihn imho nicht...
73
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
