Hi,
es kann durchaus sein das die aktuellen Treiberupdates ein Update auf dem Server und dem Client erfordern.
Es kommen aktuell neue Features bei DVB-S/S2 (Blindscan) hinzu, bei DVB-C/T/T2 werden die Signalstatistiken komplett ausgebaut. Dann sind wir die Linux Treiber an der Stelle endlich komplett fertig.
Habe auch probelhalber einen Sundtek gehabt, der leidlich funktionierte. Trotz gutem Pegel und der Kombi Dynamite/Sundtek hatte ich immer mal wieder VDR-Restarts.
Werde ich dauerhaft nicht nutzen. DD-Karte rein und gut ists. Und damit geht auch HD auf allen Sendern.
Andy
Also eigentlich sind mit unseren Tunern keine Probleme bekannt, USB 3.0 (mit einem falschen Kernel, der USB Stack wird beim Linux Kernel aktiv bearbeitet) und schlechte Verkabelungen sind wohl die häufigsten Ursachen wenn's Probleme gibt
Wenn's Probleme gibt Kontakt aufnehmen damit wir da mal drüberschauen können.
Siehe:
http://support.sundtek.com/ind…06.msg14861.html#msg14861
der hatte sich einen Tuner via Ebay besorgt und damit dann Probleme gehabt (also eigentlich nicht mit dem Tuner sondern mit dem Kabel)...
Danke louis, jetzt bewegen sich die Zeiger im Hauptmenü
Was ich noch nicht hinbekommen habe, ist die Anzeige der CPU-Last des VDR-Prozesses, hat das jemand erfolgreich getestet?
Hat jetzt nicht direkt etwas damit zu tun, aber du kannst mit dem aktuellen Treiber versuchen die Hardware PID Filter zu verwenden, damit bekommst du die Last bei den neueren Tunern herunter (ab SkyTV 4).
Das benötigt aber auch das aktuelle Update von uns.
auf dem NAS:
/opt/bin/mediaclient --lc
zeigt an was auf den Tuner zugreift (und die PIDs welche von der Applikation angefordert werden)
/opt/bin/mediaclient --tsscan /dev/dvb/adapter0/dvr0
Zeigt dir an auf welchem Transponder du bist (listet dir die Sender von der aktuell eingestellten Frequenz) über die PIDs welche du mittels --lc herausgefunden hast findest du so raus welcher Sender von welcher Applikation derzeit angefordert wird)
/opt/bin/mediaclient --readsignal=10 -d /dev/dvb/adapter0/frontend0
zeigt dir unter anderem an welche Frequenz eingestellt wurde
Ansonsten allgemeine Tipps:
USB 2.0 verwenden
lsusb -t sollte oberhalb vom Tuner ehci anzeigen nicht xhci.
Das sind erst mal Infos die du vom Tuner rausziehen kannst.
Alles anzeigenDie Idee dieses Change-Logs ist an und für sich gut und schafft Transparenz, aber letztes Update im Dezember?
Wenn Ihr einmal in der Woche ein einzeiliges Update geben würdet, wären sicherlich ein Großteil der Kunden zufrieden.
Und wieviel Zeit benötigt man dafür im Vergleich zur Beantwortung dutzender Anfragen an kontakt(at)sundtek oder von Support-Tickets?
Sollte eigentlich schon in Eurem eigenen Interesse liegen.
Ich würde da an Eurer Stelle mit offeneren Karten spielen, Eure Kunden sind charakterstark genug, auch mal ein paar Wochen Karenz einzuräumen.
Und jetzt lass ich Euch arbeiten.
Frohes Schaffen
Mister.Spliss
Es gibt diverse Changelogs und Informationen:
* http://sundtek.de/?tb=0&lm=1 (Allgemeine News)
* http://support.sundtek.com/index.php/board,6.0.html (Treiber Übersicht/Changelogs, dies gilt für ALLE Geräte)
Dann wird noch einiges im Hintergrund gekocht was natürlich erst dann so richtig dokumentiert wird wenn's fertig ist.
Die 2015er Serie macht wiegesagt noch eine "Ehrenrunde", weiteres werden wir dann wohl am Montag wissen wenn der Prototyp bestückt ist.
Zur Zeit werden noch die 2014er ausgeliefert, die 2015er werden noch getestet ich denke die nächsten Prototypen kommen am Freitag.
Bei den Details ist es einfach wie in eine Glaskugel zu sehen, es können immer wieder unerwartete Dinge passieren.
Sobald die Auslieferungen morgen abgeschlossen sind geht's auch mit dem Support und den Fragen bezüglich DVB-S/S2 weiter.
Es wird auf Anschlag gearbeitet... bitte noch 1-2 Tage etwas Nachsicht.
Verwende den Tuner mit einem Raspberry PI via Netzwerk!
Du kannst DVB-C/T/T2 dann einfach via Netzwerk einbinden.
Ganz ehrlich, das will wirklich niemand. Erst recht keine Linux-Distries.
Userspace Apps verlinken mit closed-source third-party libs.
Und damit liegst du komplett falsch, wir haben mehr als genug Kunden die das anwenden, insbesondere Industriekunden benötigen jahrelangen Support und langfristige Liefergarantien.
Dort wird das Binary ausgetauscht und die nächste Geräteserie eingesetzt und fertig, niemand setzt sich dort noch hin und baut einen Treiber extra für die verwendete Kernelversion das wäre absolut
nicht ökonomisch (oder direkt gesagt absolut verrückt).
Wir wollen auch nicht direkt in die Linux Distributionen, der Grund ist einfach wenn wir ein Update fahren dann sollen die Kunden direkten Zugriff darauf haben. YaVDR hat das soweit ganz gut gelöst mit den 0-Day Updates, bei OpenElec gibt's einen Punkt im Plugin damit man den Treiber via XBMC Menü aktualisieren kann. Alle Synology NAS Systeme werden supportet ohne das wir da irgendetwas spezielles beachten müssen, selbst wenn die eine neue DSM Version rausbringen kann uns das egal sein denn es läuft ja wie es ist.
Die Installationsroutinen sind seit ca 5 Jahren gleich, es ist ein Kinderspiel die Treiber zu aktualisieren und es dauert auch nur 10 Sekunden auf egal welchem System (die Anzahl der Treiberdownloads nach einem Treiberupdate
zeigen auch dass das sehr gerne von unseren Kunden angenommen wird).
Aber jetzt wieder zurück zum Thema, und haltet uns davon raus - bei uns läuft es halt etwas anders und es hat genau so seine Berechtigung. Es gibt ja auch sehr wenige Treiberdiskussionen bei uns da es ja läuft wie es ist und praktisch keine Probleme bereitet.
Willst du für jeden Treiber eine eigene Software schreiben? Wozu gibt es dann definierte Schnittstellen?
Dafür kann man Plugins erstellen, für tvheadend haben wir das bereits getestet, es wurde auch angenommen aber wir müssen den Patch noch einmal aktualisieren. Ein Plugininterface ist sehr einfach zu realisieren ausserdem läuft das auch auf Android ohne das man dort Administratorrechte benötigt um die Treiber zu installieren.
Die benötigt Linux auch nicht. Es ist ein monolithischer Kernel. Treiber gehören in den Kernel!
Das ist BS, die Schnittstellen wurden ja im Linux Kernel implementiert damit man sie auch nutzt. Oder warum denkst du gibt es diese Schnittstellen - noch dazu sind sie mit voller Performance ausgestattet.
Zudem gibt's auch VFIO damit man PCI/e mit DMA in den Userspace bringen kann, es gibt denke ich sogar gewisse Treiber die im Userspace damit eine bessere Performance bringen (nachzulesen auf der LKML).
er auf die gleiche glorreiche Idee kommt, systemaufrufe wie ioctl, read && co per LD_PRELOAD umzubiegen, dann gibts trouble.
Nein selbst das ist kein Problem da man diese Dinge Chainloaden kann.
Ausserdem kann man wie schon tausend mal erwähnt direkt auf den Treiber zugreifen, es ist nur ein Kompatibilitätslayer, wenn man direkt drauf zugreifen möchte wird's nicht benötigt. Dann linkt man die Applikation einfach gegen libmediaclient.so; noch direkter geht's mit libmcsimple.so wo die Befehle direkt mit net_* Prefixen ausgewiesen sind. Also alles kein Problem mit sehr vielen Freiheiten.
- Man bekommt dann eingeredet, dass Treiber nicht in den Kernel gehören. (Sundtek ist da Meister). Treiber gehören unter Linux schon immer in den Kernel. Das war schon immer so und wird auch so bleiben.
Wenn du selber einen Kerneltreiber geschrieben hast und den auch für sehr viele Kunden so bereitstellen kannst das sie diesen sofort verwenden können dann können wir gerne darüber sprechen.
Wenn wir ein Geräteupdate machen sind die Treiber schon im Vorhinein verfügbar, kleine Anpassungen können wir jederzeit für alle Systeme anbieten.
Unsere Kunden verwenden teilweise noch ältere 2.6er Kernel welche sie nicht so einfach aktualisieren können.
Zudem ist das Ganze so getrimmt das es auch auf allen möglichen Architekturen läuft. Wir müssen uns um Kernel-Updates nicht kümmern.
Des weiteren kommt da demnächst noch einiges mehr, und es baut alles auf die vergangenen Entwicklungen auf.
Vom Treiber-Support her haben wir keinerlei Probleme mit unseren Kunden und das vom ersten bis zum aktuellsten Kunden, und das zählt.
Versuche vielleicht mal die USB Kabel wegzulassen?
Vielleicht gibt's aber auch EMV Probleme und längere Kabel (oder ein Ringkern USB Kabel) würden helfen (hatten wir schon mal beim Raspberry PI bei einem Kunden).
Du wirst wohl einen alten Tuner haben? Ich denke nicht das die mehr als 300mA benötigen, das Netzteil ist ausschließlich für die LNB Stromversorgung zuständig.
Schau mal im Bios nach ob es dort USB Settings gibt. Wenn der XHCI Treiber geladen wird dann wird's wohl ein USB 3.0 Port sein.
lsusb -t oder so (ich kenn das Flag jetzt nicht 100%ig auswendig) kann dir anzeigen wo der Tuner dranhängt
Dort steht das der Tuner als USB 1.1 Tuner erkannt wird und dann irgendwie alles schief geht, ich würde das dem USB Controller oder USB Controller Treiber zuschieben.
Hat der Rechner USB 2.0 Ports? Wenn ja verwende die Tuner ausschließlich daran. USB 3.0 Ports haben unter Linux selbst vom Controller Treiber her einen sehr schlechten Support (oder genauer gesagt die USB Controller Treiber funktionieren nur bei ausgewählten Systemen).
Ich könnte mir vorstellen das der USB Controller Treiber in so einem Fall den Port resetten sollte damit die USB 2.0 / USB 3.0 Erkennung erneut gemacht wird - aber das ist im Linux sicherlich nicht implementiert. Bei NAS Systemen hatten wir das auch schon mal das auf einem USB 3.0 Port der Tuner als USB 1.1 erkannt wurde - Synology hat uns zwischenzeitlich aber gemeldet das sie ihre USB 3.0 Probleme in den Griff bekommen haben.
Wir hatten soweit 3 Tuner an einem Notebook mit 1.3 GHz mit DVB-C getestet (mehr USB Ports hatte das Notebook nicht). Es ist halt abhängig vom System.
Ja, lass den USB 3.0 Port frei, und nimm zur Not ein USB 2.0 Hub für alle USB 1.1 und USB 2.0 Geräte hinten an der Box (z.B wenn du 2 Tuner und USB Keyboard + Maus verwendest)
Der Treiber kann das System nicht abstürzen lassen da er ja nur eine Applikation ist, demnach stolperst du da genau über einen anderen Bug im Kernel und der Bug ist sehr wahrscheinlich der USB 3.0 Bug.
http://www.intel.de/content/ww…nuc-board-dn2820fykh.html
das ist dieser NUC hier oder?
Stürzt dir der NUC komplett ab?
Eventuell bereitet dir genau der andere USB Port die Probleme.
Um das einmal aufzuklären, du stolperst hier über einen bekannten USB 3.0 Bug welcher auf der Linux Kernel Mailingliste bearbeitet wird.
Du wirst mit allen USB 2.0 Tunern auf diesem System einen Systemabsturz bekommen da der Controller Treiber das Problem ist (nicht die Hardware).
Die einzige Hardwarelösung für den NUC wäre somit ein nativer USB 3.0 Tuner - so etwas gibt es derzeit aber noch nicht (und das auch nur da der Linux USB 3.0 Sofwtare-Stack derzeit noch Probleme hat).
https://bugzilla.kernel.org/show_bug.cgi?id=75521
Es gibt derzeit experimentelle Patches, jedoch bereiten die dann noch Probleme mit USB 3.0 Geräten, in dem Beitrag steht auch das andere USB 2.0 Geräte Probleme bereiten.
Bei Intel sitzt jemand der das Thema bearbeitet, sie haben auch einen Tuner von uns zum Testen (das ist Intel in Finnland)
Kann es sein dass dort ein AMD SB700 USB Controller verbaut ist?
Da würde dir nicht viel anderes übrig bleiben einen anderen USB Controller zu verwenden, die USB Controller von AMD sind und waren schon immer sehr fehlerbehaftet und bei AMD selber interessiert das niemanden (selbst die USB Chipfirmen beissen sich bei AMD die Zähne aus). Die Antwort von AMD ist lediglich wir wissen das etwas nicht passt.
Alternativ DVB-C via Netzwerk in den Rechner einbinden z.B über einen Raspberry PI.
danke, der Sundtek ist sicher eine moegliche Wahl. Heisst das, dass ein RPi mit Sundtek Stick 'ganz normal' als VDR betrieben werden kann? Reicht da die Performance?
Wie im Eingangspost angemerkt, ich koennte mir auch einen RPi mit DVB-S2 als reinen Streaming-Server fuer einen weiteren RPi als Streaming-Client vorstellen. Aber da wirds wohl Serverseitig mit der USB-Bandbreite des RPi kniffelig, oder? (Der muss dann ja ueber einen USB den DVB-S2 sowie das Netzwerk bedienen koennen)...
Andererseits, wenn ich nur einen RPi nehme (als vollwertigen VDR), dann habe ich zwar kein USB-Bandbreitenproblem, aber ist der RPi dann schnell genug um beides, Client und DVB-S2-Empfaenger zu spielen?
Ich wuehl' mal noch hier im Forum rum, vlt. wirds ja doch sowas wie ein Cubie als Streaming-Server...
VDR klappt damit auch direkt auf dem Raspberry PI ja. Ein reiner Streamingserver ist natürlich auch möglich. Beim Streamen zu Windows (kompletter Transponder) wird ca 50% CPU veranschlagt, bei weniger Bandbreite wird natürlich gleich dementsprechend weniger Performance benötigt.
Der Raspberry PI funktioniert mittlerweile problemlos wie es aussieht.
