mit DVB-S2 Tunern für USB sieht es auch eher Mau aus,
Alternativ zu den wirklich sehr guten Sundtek USB Sticks gäbe es noch diverse SAT>IP Server, wobei aus den Erfahrungen hier offensichtlich nur ein Produkt wirklich problemlos und stabil läuft, Digital Devices Octopus NET ...
Wer billig kauft, kauft leider meist zweimal.
Man gibt 313 Euro für so eine schlechte Kiste aus.
Man fragt sich was hier wirklich der Edel-Raspberry ist, der VU+ oder ein Intel NUC ... 
Regards
fnu
- Meist propitäre Hardware.
sehr guten Sundtek USB Sticks
johns schreibt erst noch, dass proprietäre Hardware nix ist und dann kommst du mit Sundtek...
Wenn man so will ist jede Hardware proprietär nur weil sie Treiber benötigt.
Ich weiß nun nicht was man Dir zum Thema proprietär beigebracht hat, aber Dein Weltbild ist zu einfach. Nur weil die Sundtek Sticks ein anderes einfach portierbares Treibermodell benutzen sind diese nicht proprietär.
Treiber im Linux-Kernel ist kein Qualitätsmerkmal oder ein Zeichen von offener Hardware und als klassisch proprietär bezeichnete Hardware läuft durchaus auch mit Linux, siehe IBM Mainframes ...
Regards
fnu
Nur weil die Sundtek Sticks ein anderes einfach portierbares Treibermodell benutzen sind diese nicht proprietär.
Ansichtssache. Will ich aber lieber nicht weiter ausbreiten.
Treiber im Linux-Kernel ist kein Qualitätsmerkmal oder ein Zeichen von offener Hardware und als klassisch proprietär bezeichnete Hardware läuft durchaus auch mit Linux
Es läuft, ja. Aber Open-Source Treiber sind ein Qualitätsmerkmal. Mal davon abgesehen, dass ich schon vor einem Jahr das defekte systemd Service File für den Sundtek Daemon kritisiert habe. Bisher hat sich da null getan.
Sollte jemand von Sundtek mitlesen: Euer Service File ist Type=oneshot. Das ist unbrauchbar, weil man dann nicht auf eure Devices warten kann.
Ich kenne euren Daemon nicht, aber mir scheint Type=forking und "--wait-for-devices" für den mediasrv deutlich sinnvoller.
wenn ich mir die VU+ Duo2 so anschaue ist sie mit über 400.- für die Quad-Version vom materiellen Gegenwert her mit Sicherheit überteuert,
aber deutlich billiger und mit ihren 2 Displays
und deutlich schmucker als die Intel-NUC-Kiste mit externer Hardware, sieht einfach aus wie'n Rasperry, da kann ich mir nicht helfen.
So was auch noch ins Wohnzimmer zu stellen
dazu gehört eine deutliche Liebe zu Intel,
und dafür ist die Kiste bestimmt auch nicht gemacht und gedacht.
aber deutlich billiger und mit ihren 2 Displays
und deutlich schmucker als die Intel-NUC-Kiste mit externer Hardware, sieht einfach aus wie'n Rasperry, da kann ich mir nicht helfen.
Na ja, für mich sind Displays so was von gestern. Ich steuere die NUCs mit Tablet/Smartphone und bekomme die Infos von dort, oder vom OSD des TVs.
Würde mir der NUC nicht gefallen, dann würde ich ihn einfach hinter dem AVR verstecken.
Aber das kann ja jeder halten wie er will.
Gerald
So was auch noch ins Wohnzimmer zu stellen
dazu gehört eine deutliche Liebe zu Intel,
und dafür ist die Kiste bestimmt auch nicht gemacht und gedacht.
Keine Ahnung, warum man sowas überhaupt sichtbar platzieren muss - das kommt einfach hinter die Blende eines Lowboards oder eines Schrank-Kranzes und fertig. Ich will Technik, die unauffällig ihren Job erledigt und keine nervös blinkenden Lichter und Status-Displays im Wohnzimmer.
wenn der NUC Dir zu klein ist , dann nutze doch ein MOI PROmit div. Tunern
[Blocked Image: http://www.tbsdtv.com/products/images/tbs2951/tbs2951_4.jpg]
Grüße
cinfo
Es läuft, ja. Aber Open-Source Treiber sind ein Qualitätsmerkmal. Mal davon abgesehen, dass ich schon vor einem Jahr das defekte systemd Service File für den Sundtek Daemon kritisiert habe. Bisher hat sich da null getan.
Es läuft, ja. Aber Open-Source Treiber sind ein Qualitätsmerkmal. Mal davon abgesehen, dass ich schon vor einem Jahr das defekte systemd Service File für den Sundtek Daemon kritisiert habe. Bisher hat sich da null getan.
Sollte jemand von Sundtek mitlesen: Euer Service File ist Type=oneshot. Das ist unbrauchbar, weil man dann nicht auf eure Devices warten kann.
Ich kenne euren Daemon nicht, aber mir scheint Type=forking und "--wait-for-devices" für den mediasrv deutlich sinnvoller.
Hallo,
nein das kannst du vergessen. Das System ist Hotplug orientiert. Wer irgendetwas über die USB Tuner laufen lassen will sollte am Besten /etc/sundtek.conf device_attach=shellscript DEVID oder device_detach=shellscript DEVID benutzen (DEVID wird ersetzt durch die Device ID).
Das läuft generisch von Linux 2.6.15 an. Auf Systemd, UDEV, HAL und co wollen wir uns nicht verlassen (die Konfigurationen haben sich über die verschiedenen Releases auch geändert und wir wollen das nicht maintainen...) Ich erinnere mich an einen ATI Treiber Bug welcher UDEV durch diverse Callbacks auf 100% CPU gebracht hat sobald man die Videoausgabe benutzt hat .. unser Treiber überprüft das in dem Fehlerfall und stoppt UDEV während TV benutzt wird.. das war irgendwann bei einer Linux Version zwischen 2.6.30-40 der Fall.
Um da noch unabhängiger zu werden kommt demnächst dann auch noch ein Streamingserver für XBMC / Kodi hinzu. Treiber starten und der konfiguriert sich automatisch - da unsere Geräte seit 2014 alle Blindscan unterstützen (und auch unsere API das ordentlich hergibt). Das Kodi Plugin an sich wird klarerweise Opensource, da es an dieser Stelle keinen Sinn macht für alle Versionen eine eigene Version zu pflegen.
http://support.sundtek.com/index.php/topic,1940.0.html
Opensource bei den Treibern kannst Du absolut vergessen, wir arbeiten so eng mit den Chipsatzfirmen & Kunden zusammen das klappt mit Opensource nicht. Wir können es uns einfach nicht leisten diese Arbeit für andere Unternehmen kostenlos bereitzustellen. Ausserdem wollen wir nicht das irgendjemand modifizierte Treiber mit unseren Tunern verwendet - man kann mit uns über jedes Feature sprechen und wir haben auch über alle Geräte hinweg gesehen die meisten Optionen unter Linux und MacOSX, es gibt zusätzlich zu den regulären DVB API Befehlen über 70-80 zugängliche API Befehle welche von diversen Kunden verwendet werden.
Zudem gibt es 0 Streitereien mit anderen Opensource Fricklern welche die Datenblätter maximal von diversen Design Häusern klauen können (Mauro und die Bande halt).
Das Ganze spielt derzeit auf ein neues Produkt ab wo wir wieder sehr viel Arbeit in die Firmware stecken müssen da das Chipdesign Haus natürlich auch keine dementsprechenden Feldtests machen konnte.
VU+ Duo² 1x DVB-S2, festplattenvorbereitet ab €313,01
Man gibt 313 Euro für so eine schlechte Kiste aus.
- Meist propitäre Hardware.
- Meist schlechte CPU Performance
- Meist 100Mbit Netzwerk
- Meist keine Anschlüsse
- Meist wenig RAM
Das ist eine Doppelkern Settopbox, mit (nahezu nicht existierendem) Support aus Korea / Marusys und nur nem Händler in Deutschland (hier wird diesbezüglich überhaupt nichts gemacht).
Mittelfristig sollte man sich so etwas als Quad holen (aber eher nicht von der Firma, da die wirklich so gut wie keinen Support bieten). Der deutsche Händler an sich dreht hier schon krumme Dinger. Dream Multimedia ist hier zwar wirklich teuer aber vom Support her kann ich nur sagen -- wenn wir ein Problem haben reparieren die das über die Nacht. Von irgendwas müssen die Entwickler halt auch leben.
wenn ich das alles über Vuplus und DMM gewusst hätte was ich jetzt über die Firmen weis hätte ich mich wahrscheinlich für eine Dreambox wegen des besseren Supportes entschieden.
Es gibt bei Vuplus keinen Hersteller der sich selbst so nennt, die Vertriebsfirma in Deutschland antwortet nicht auf emails wenn sie die Antwort auf eine Frage nicht weis
statt sich schlau zu machen,
es gibt offenbar auch keine Garantie sondern nur die Gewährleistung.
Ich hatte vorsichtshalber die Box über Amazon gekauft um einen kompetenten Ansprechpartner zu haben.
Von der Hardware her bietet sie offenbar das was in dieser Receiverklasse auch bei anderen Anbietern geboten wird,
*** die Speicher ist sogar doppelt so gross wie bei vergleichbaren Geräten mit bis zu 4 Tunern
*** und man kann eine 3,5" Festplatte einbauen,
was letztlich für meine Entscheidung für die VU+ Duo2 ausschlaggebend war.
WLAN ist bereits eingebaut, die 100 MBit Schnittstelle ist sicherlich ausreichend schnell
denn die Box muss die Daten ja "nebenher" auch wegschaffen, was nützt da eine Gigabit-Schnittstelle ?
Wieso meint ihr eigentlich der verbaute Prozessor der VU+ sei für seine Anforderungen zu schwach auf der Brust?
Ich hatte vorher eine AVG2, deren meiner Ansicht nach leistungsschwächere Prozessor hatte es auch getan.
Was kann die Intelbox was die VU+ nicht kann?
Was habe ich da wieder losgetreten 
Zum Opensource / Closesource sage ich nichts, daß ist wie über Religion diskutieren.
Ich will dir deine VU nicht schlecht reden. Ich dachte du stehst vor der Kaufentscheidung, wenn du sie bereits hast, viel Glück.
Was ich geschrieben habe, gilt für alle diese Receiver (die meisten). Deshalb habe ich "meist" geschrieben.
WLAN ist bereits eingebaut, die 100 MBit Schnittstelle ist sicherlich ausreichend schnell
denn die Box muss die Daten ja "nebenher" auch wegschaffen, was nützt da eine Gigabit-Schnittstelle ?
100Mbit sollten für einen Stream reichen, aber Aufnahmen kopieren usw. geht alles sehr langsam.
Wieso meint ihr eigentlich der verbaute Prozessor der VU+ sei für seine Anforderungen zu schwach auf der Brust?
Ich hatte vorher eine AVG2, deren meiner Ansicht nach leistungsschwächere Prozessor hatte es auch getan.
Aufwendige Skins brauchen mehr Rechenzeit und Sachen wie EPG und Scrapper brauchen auch etwas mehr Performance.
Was kann die Intelbox was die VU+ nicht kann?
Ich schreibe mal X86 anstatt Intel, man kann threoretisch auch eine AMD CPU nehmen.
Im Prinzip reicht die VU+ oder jede andere Receiver und kann alles was ein X86 kann.
Früher war der Stromverbrauch der Vorteil gegenüber dem X86
Wenn du einen einfachen Receiver willst, dann kannst auch einen Banana PI, Raspberry PI, Wetek, ...
nehmen.
Der entscheidende Vorteil ist, man bekommt für das gleiche Geld mehr.
Mehr RAM, mehr Rechnenleistung (100x?), mehr Schnitstellen.
Der X86 hat eine Vielzalhl von Schnittstellen, N x SATA, N x USB, N x USB 3.0
Diese Schnittstellen laufen auch mit voller Bandbreite. Aber bitte mich darauf nicht festnageln,
vielleicht hat sich dies bei aktuellen SOCs inzwischen verbessert
Spätestens wenn die Interne Festplatte voll ist, braucht man entweder eine zweite SATA oder ESATA oder USB.
Ich persöhnlich würde nicht auf einen NUC zurückgreifen, da der auch schlecht erweiterbar ist.
Aber ein ITX X86 ist auch aktualisierbar und erweiterbar, wenn jetzt H.265/HEVC kommt, neue CPU oder GPU dazu und schon gehts.
Die meisten X86 sollten alle schon 4K ausgeben könne.
Auf dem X86 läuft Kodi
Der X86 kann als Medienzentrale, Datenschleuder usw. dienen.
Johns
Das System ist Hotplug orientiert.
Das ist genau das Problem. Der VDR kann damit nicht. Devices müssen da sein, bevor der VDR gestartet wurde. Auch wenn es fummelig ist. Man braucht aktuell einen Punkt, an dem alle Devices, die eingesteckt sind, initialisiert wurden. Danach kann der VDR gestartet werden.
die Konfigurationen haben sich über die verschiedenen Releases auch geändert und wir wollen das nicht maintainen...
systemd Service Files sind eigentlich ziemlich konstant. Die beiden oben genannten Änderungen schaden euch nicht, helfen aber denen, die eben ein "Event" benötigen, bevor der VDR gestartet werden kann. Gestartet wird euer Service so und so, bei meiner Variante weiß systemd aber, wann euer Service fertig initialisiert ist und andere Services können dann auf diesen Zustand warten.
Opensource bei den Treibern kannst Du absolut vergessen, wir arbeiten so eng mit den Chipsatzfirmen & Kunden zusammen das klappt mit Opensource nicht. Wir können es uns einfach nicht leisten diese Arbeit für andere Unternehmen kostenlos bereitzustellen.
Wenn ich das rein wirtschaftlich betrachte, kann ich euren Standpunkt natürlich nachvollziehen. Als verwöhnter Linux-User ist es aber natürlich unschön, sich speziell mit eurem Treiber zu beschäftigen. Wenn ich aber dann die Tortur bei den Digital Devices Treibern sehe... OK. Ich bin still.
Wenn ich das rein wirtschaftlich betrachte, kann ich euren Standpunkt natürlich nachvollziehen. Als verwöhnter Linux-User ist es aber natürlich unschön, sich speziell mit eurem Treiber zu beschäftigen. Wenn ich aber dann die Tortur bei den Digital Devices Treibern sehe... OK. Ich bin still.
Trotzdem passt so eine Denke zu Linux wie das Weihwasser zum Teufel.
Würde jeder so denken, dann würde es sowas wie Linux und die ganze Software-Infrastruktur darum, überhaupt nicht geben.
Wird aber Off-Topic und bringen wird so eine Diskussion ohnehin nichts...
Hallo Leute,
warum läuft BM2LTS eigentlich nicht auch auf er AVG3 ?
Wei die AVG III kein PC-Mainboard mehr als Basis enthält, sondern ein speziell von Reel entwickeltes Board auf Basis eines Embedded Prozessors.
Also auch keine Grafikkarte, sondern einen On-chip Grafikprozessor...
Das bräuchte einige Anpassungen.
MfG
maier2505
Danke für die Info.
Ob der Prozessor und Grafikchip fest onboard sind dürfte doch eigentlich egal sein.
Wenn Reel selbst das Board designed haben
wird man da doch darauf geachtet haben
dass das Board nicht allzu anders ist als das Kontron-Board
damit sie selbst nicht soviel Anpassungsarbeit mit der Software haben.
ich habe gerade bei Google-Bilder das Board der AVG3 gefunden,
ist eigentlich ein komplett anderes Gerät,
so aufgebaut wie man es heute erwartet aber komplett Anders.
Da gibt es aber wohl eher nicht genug verkaufte AVG3 damit sich der Aufwand letztlich lohnt.
Wieso Anpassung der Software?
Die Übergabe an die Hardware erfolgt doch m.E. über fest definierte Schnittstellen, daher muss lediglich der Hardwareteil, also die Treiber entsprechend angepasst werden.
Oder liege ich hier falsch? 
cu
ich denke schon.
inwieweit die Ubuntu-Software die verwendeten Hardwarebauteile unterstützt weiss ich nicht.
ich habe dort auf dem Board neue Baugruppen gesehen, USB 3 Schnittstellen, Flashram usw..
Ich gehe mal davon aus das für BM2LTS nicht die Programm-Sourcen von Reel vorliegen hat
an die Reel ihre Software angepasst hat.
Aber vielleicht war die AVG3 für RMM ja eine komplette Neuentwicklung im alten Gehäuse?
soll allerdings auch zuviel Strom verbrauchen:
im Vergleich dazu kommt der Technicorder mit 4-core Prozessor und insgesamt 6 Tunern (incl. 2 DVB-S2 Zusatz-Tunern) mit ca. 16 Watt aus,
das ist das Genügsamste was ich in dieser Klasse bisher in den Fingern hatte und nur 1/4 der AVG2.
Ich halte es in diesem Fall allerdings für sinnvoller die Programmier-Resourcen von BM2LTS für die Anpassung an irgendeinen einen anderen, aktuell erhältlichen Receiver mit möglichst vielen Tunern anzupassen wenn es dafür genug Interessenten gibt
VDR/BM2LTS könnte ja auch auf neuerer Hardware weiterleben,
früher oder später werden alle AVGs verreckt sein ...
Natürlich sind weite Teile der Software lauffähig, handelt sich ja nach wie vor um einen x86er Prozessor.
Aber genauso natürlich sind viele teile anders, die komplette Initialisierung, das Ansprechen der Hardware ( es gibt zum Beispiel so etwas wie ein vom Nutzer ansprechbares BIOS gar nicht mehr...), die Grafikausgabe, die nicht mehr über eine externe Grafikkarte läuft...
Als Hauptgrund haben die Entwickler von BM2LTS schon mehrmals angegeben, daß Sie schlicht keine AVGIII haben.
Ich verstehe ehrlich gesagt das ganze Gemotze über die ach so schlechte Hardware nicht, die auch in anderen Threads breitgetreten wird.
Ganz davon abgesehen, daß da Hardwareentwickler dabei sind, die sich nicht die Spur davon vorstellen können was auf so einem Netceiverboard so reinentwickelt wurde
Ich fand die Hardwarebasis um die Kontron boards nie schlecht, die HDE hatte wegen des Micronas Chips, der nicht lange genug unterstützt wurde Ihre Probleme.
Die Umsetzung mit dem Netceiver war einfach nur genial, da können auch heute nur wenige hinriechen...
Aber es gab ein paar bekannte Schwachstellen, die sich recht leicht ausmerzen liessen.
Das Netzteil lässt sich mit ein paar Handgriffen und 50 Euro Einsatz gegen hochklassige Standardware tauschen, die so schnell nicht wieder kaputt gehen wird.
Der HDE wurde es gerne etwas zu warm, vor allem wenn mal wieder ein Anwender drauf kam er könnte auf die AVG was drauf stellen oder wenn er das Ding in ein Regal stellte das drüber 1 cm Luft hatte.
Aber ein etwas besserer Kühlkörper auf dem Grafikchip und ein leiser, langsamer 80mm Lüfter (hat mit leichten Anpassungen Platz im Gehäuse) hat das behoben.
So laufen meine mittlerweile vier AVGs und sie laufen und sie laufen.
Ist eine AVGIII dabei, das ist das langsamste Gerät von allen.
Auch von den drei externen Netceivern ist noch keiner kaputt gegangen. Nachdem aber AVGs jetzt ganz günstig hergehen, hat man halt noch ein Netceiverboard und ein paar Tuner als Ersatzteil rumliegen.
Wird noch eine Weile dauern bis die AVGs weg sind, ich könnte mir auch nicht vorstellen wie das bei uns ohne sie gehen sollte.
Allerdings machen wir auch nichts anderes damit als massiv aufnehmen aufs NAS und ansehen...
Und das funktioniert gerade jetzt mit BM2LTS super.
Beste Grüße
Don’t have an account yet? Register yourself now and be a part of our community!
