Posts by tomtom007

Hallo,
ich habe nun eine dritte Skystar USB HD angeschlossen und der RPi2 streamt auf drei Transpondern gleichzeitig HD Material auf eine NFS -Freigabe !
Die CPU Last geht in "top" bis 110% aber keine merkbaren Aussetzer.
Es ist also tatsächlich so, daß die TeVii 650 und 660 und die DVBSky S960 (zumindest meine Exemplare) ein Problem haben,
sobald mehr als ein USB Tuner im System ist !
Das hatte ich auf einem Zotac Atom x86 früher auch schon beobachtet, war mir aber nicht mehr ganz sicher.

Hallo,
sicherlich kosten Switch und NAS zusätzlich Strom, sind bei mir aber aus anderen Gründen sowieso vorhanden.
Das eigentlich Problem ist aber die Suche nach USB DVB-S2 Tunern, die
a) parallel zu weiteren Geräten betreibbar und
b) noch verfügbar sind
Die alten Skystar arbeiten parallel, die S960 und TeVii 650/660 machen (zumindest bei mir) Probleme.
Hat niemand mehr als 2 DVB-S2 USB Tuner parallel ohne Probleme am VDR laufen ?

Ja, wie bereits geschrieben
"Die zweite Aufnahme mit einer Skystar arbeitet tadellos"
Nur andere Fabrikate wie die S960 oder TeVii liefern schlechte Daten sobald ein weiterer Tuner aktiv wird.
Die beiden Skystar schaffen es selbst mit vier HD Aufnahmen nicht das System zu überlasten.
Und 3W aus USB für den RPi sind mit X86 m.E. nicht machbar.

Hallo,
ich schlage mich nun schon seit einiger Zeit mit einem lästigen Problem herum.
Ich habe mein VDR Zotac -System gegen einen Raspberry Pi 2 getauscht um Strom zu sparen.
Es sind mehrere KODI Clients im Hausnetz die versorgt werden wollen.
Es läuft nun Raspbian mit VDR 2.2.0 sowie dynamite und vnsi plugin (von GIT -Sourcen compiliert) im reinen Serverbetrieb ohne Bildschirm.
Mit zwei Technisat Skystar an einem vierfach LNB funktionierte alles prima, leider reicht das manchmal nicht, weil Aufnahmen die Auswahl einschränken.
Sobald nun ein dritter USB Receiver dazu kommt gibt es extreme Bildstörungen auf diesem dritten Tuner, die beiden Skystar funktionieren problemlos weiter.
Ich habe DVBSky S960, TeVii 660 und 650 als weiteres Gerät ausprobiert.
Die beiden Skystars funktionieren prima aber die dritte (mit Montage Tuner) liefert nur verstümmelte Daten sobald die beiden Technisat aktiv werden.
Ich starte Aufnahmen nacheinander auf allen drei Tunern und und kontrolliere die Streams auf einem anderen Rechner im Netz mit Kodi parallel zur Aufnahme.
Die naheliegendste Lösung wäre es, einfach noch eine Skystar zu kaufen, aber leider sind diese nicht mehr erhältlich.
Die Auslastung des RPi 2 liegt um 50% mit drei streams, das kann es nicht sein.
Worin kann dies Problem liegen, DVB-S2 Tunerkarte oder Quattro -LNB ?
An der Stromversorgung der Geräte liegt es nicht, ich habe auch andere Netzteile ausprobiert, den LNB hatte ich auch getauscht.
Gibt es mit USB -Tunern irgendwo eine Begrenzung oder ein Limit auch wenn die CPU noch Reserven hat ?
Ich meine, daß ich dies Problem vorher auch auf dem Zotac System mit Atom N2130 hatte, mit mehr als 2 Tunern Klötzchenbildung/Artefakte.
Und der hat noch erheblich mehr Rechenleistung als der RPi.
Die LNB -Kabel habe ich natürlich auch zwischen den Tunern getauscht, das war es auch nicht.
Von der Busbandbreite her ist der RPi 2 etwas schwach, aber der USB2 mit 480MBit/s sollte für drei DVB-S(2) Streams reichen, auch mit streaming auf ein NFS Share,
zumal wie geschrieben die beiden Technisat funktionieren nur der dritte nicht.
Ideen ?

Update:
Wenn ich mit der S960 aufnehme und dann auf einem anderem Transponder einen weiteren Kanal aufnehme gibt es auf dem ersteren starke Artefakte und Bildstörungen.
Die zweite Aufnahme mit einer Skystar arbeitet tadellos. Stoppe ich die Aufnahme auf der Skystar gehen auch die Störungen auf der S960 vorbei.
Nehme ich als Gegenprobe die S960 raus und nur zwei Skystar klappen zwei parallele Aufnahmen ohne Probleme.
Ich habe die S960 darauf an einem extra Single LNB angeschlossen um das Quatro LNB als Fehlerursache auszuschließen.
Es gab keine Verbesserung, daran liegt es also auch nicht !
Hat jemand 2 oder mehr S960 oder TeVii mit Montage Tunern an USB fehlerfrei mit VDR/VNSI laufen ?

Hallo nochmal,
wenn ich Raspberry Pi 2 lese kann ich mir schon vorstellen, daß er auf dem nfs share beim Aufnehmen so an die Grenzen kommt.
Man könnte die Zahl der Netzwerk Schreibzugriffe "testweise" mal verringern,
indem man die Indexdatei während der Aufnahme nicht miterzeugt.
Das sollte dann später bei ersten Zugriff auf die Aufnahme passieren.
Ich hab das allerdings noch nicht ausprobiert,
da ich zwischenzeitlich die Lösung mit dem Wechsel von cifs auf nfs gefunden habe.
In recorder.c in cRecorder::cRecorder() die Zeile "index=" auskommentieren wäre mein Plan gewesen.

Hallo,
ich habe die Problematik bisher dadurch umgangen, daß ich auf die lokale SSD aufgezeichnet habe
und nach Ende der Aufnahme in rec.cmd die Daten auf die Cifs -Freigabe geschoben habe.
Wiedergabe von Cifs war ja kein Problem, nur die Aufnahme schlug fehl.
Letzte Woche fand ich nach einem Firmware Update meiner WD MyCloud NAS einen nfs Server vor
Ein schneller Test mit einer HD Aufnahme funktionierte gut, danach klappte es auch mit zwei und drei Aufnahmen gleichzeitig.
Fazit: auf der gleichen Server Hardware geht mit cifs nicht ein Stream fehlerfrei, mit nfs aber sogar drei gleichzeitig.
Nfs Puffergrößen stehen auf default, asynchrone Übertragung.

Hallo,
ich habe dann mal weitergesucht und letztendlich führt das Schreiben zumindest des Indexfiles zu einem Aufruf von write().
Die ist die ungepufferte I/O -Schnittstelle im Gegensatz zu fwrite() etc.
Jetzt kenne ich den Grund hierfür nicht.
Nach K&R reduziert die gepufferte I/O mit den fxxx() Funktionen ja die Systemaufrufe,
was gerade bei Dateien "auf dem Netz" erhebliche Latenzzeiten sparen soll,
weil eben weniger echte write() aufgerufen werden.

Siehe auch: https://wiki.openoffice.org/wiki/Performance/Buffered_File_IO

Evtl. kann KLS hier klären, warum die ungepufferte I/O Schnittstelle notwendig ist.

Gruß
Tom

Hallo,
das NAS ist ein fertig gekauftes System mit CIFS.
NFS ist "out of the Box" leider nicht verfügbar.
CIFS hat bei jedem Zugriff Latenzzeiten.
Ich weiß jetzt nicht, in welchen Blockgrößen VDR schreibt.
Es sind im fortlaufenden Stream ja zumindest zwei Dinge
a) die DVB -Datenpakete
b) der Index auf die "Bilder" im Stream
Ob das zwischengepuffert wird oder jeder kleine Datensatz einzeln geschrieben wird wäre hier auch meine Frage.
Wenn dem so wäre, hilft wohl nur die lokale Zwischpufferung auf Datenträger
und Wegschreiben nach Ende der Aufnahme auf das NAS.
Falls aber die Writes gepuffert werden, wäre meine Frage wo dies geschieht und ob man die Puffer vergrößern kann.
Gruß
Tom

Das wäre dann ja nur ein 20MB entsprechend 10s Timeshift und fest einkompiliert.
Kann ich mir eigentlich nicht vorstellen.
Hängt es evtl. mit der Indizierung der Videodaten zusammen ?
Die Abläufe dort habe ich noch nicht verstanden.
Gruß
Tom

Hallo,
ich habe Probleme mit Aufnahmeverzeichnissen auf Netzwerk Shares seit einigen VDR Versionen.
Nachdem es mit einem NAS auf der Fritzbox 7390 zu Problemen kam habe ich es auf den recht
schwachen Durchsatz der Box um die 4MB/s geschoben. Nun nutze ich ein WD Cloud NAS System.
Hier erreiche ich vom VDR mit kopieren aus dem /dev/zero auf den Share zwischen 30 und 50MB/s.
Jedoch kommt es auch hier nach einigen Sekunden zum Ringbuffer Overflow und unbrauchbaren Aufnahmen.
Ich habe die Puffergröße in recoder.c von 20MB auf 200MB hochgesetzt.
Die einzige Auswirkung war, daß es etwa 10x länger dauerte bis es zum o.g. Problem kam.
Testweise eingebrachte esyslog Ausgaben zeigen, daß mehr Daten in den Puffer reingeschrieben werden als
herausgenommen und weggeschrieben werden.
Sobald ich /video auf ein lokales Drive mappe, läuft es wunderbar.
Ich fasse zusammen: Durchsatz vom NAS ist im Mittel hoch genug, Ringpuffer vergrößern beseitigt das Problem nicht.
Daraus schließe ich, daß die Daten nicht häufig genug abgeholt werden, bzw. dort irgendwas bremst.
Ich habe bereits viele ähnliche Meldungen gefunden, aber leider keine wirkliche Lösung.
Hat jemand einen Hinweis bzw. was mag die Ursache sein ?
Zur Zeit helfe ich mir damit, daß ich auf die lokale Platte aufnehme und am Ende der Aufnahme die Dateien auf das NAS verschiebe.

Mfg.
Tom

Mein System: VDR mit SoftHDDevice aus dem git gebaut unter Debian x64 testing
Shuttle Barebone Atom DualCore 1.8GHz, 4GB DDR3, ION Graphik und 64GB SSD
2 x TeVii 660 USB DVB-S2 und 1 x Technisat SkyStar USB
1 x Gigabit Ethernet zum 1GB -Switch und von dort 1GB Ethernet zum WD My Cloud 4TB NAS

Hallo,
ich denke, bei meinem Rotor gibt es das gleiche Problem.
Bei 18V gibt es Überlast der USB DVB-S Geräte bzw. Netzteile.
Ich hatte das vor einigen Monaten schon mal mit dem rotor-ng plugin getestet und dann abgebrochen wegen Zeitmangel.
Gibt es schon eine Möglichkeit, eine Testversion (vdr mit rotor) zu bekommen
um sowas zu testen und ggf. schon mal Netzteile etc. zu checken.
Gruß
Thomas

Shuttle Barebone mit Atom @1,8GHz, 4GB RAM und SSD
Aufnahmeverzeichnis per SMB Share auf Fritzbox NAS,
2-3 USB DVB-S2 Budget TeVii 650
Softhddevice VDPAU/ION, diverse weitere Plugins
Compiliert aus GIT unter Debian/Testing x64

Hallo,
nachdem ich seit etwa 10 Jahren begeisterter VDR User bin möchte ich die Inhalte nun im ganzen Haus
per Stream Clients verfügbar machen. Da der eigentliche VDR (Server) mir aber immer noch
zuviel Strom verbraucht, soll dieser nur laufen bei Live TV oder Aufnahmen.
Das Aufnahmeverzeichnis habe ich per CIFS auf die Fritzbox gemountet; die läuft sowieso 24/7.
Somit sind die Aufnamen also unabhängig vom VDR verfügbar.
Leider ist die Schreibdatenrate auf die FB per CIFS recht mäßig,
mit 2 HD Streams gleichzeitig schlägt es fehl und beide Streams sind fehlerhaft.
( Und oftmals kommen interessante Programme zum gleichen Zeitpunkt
Dann kam die Idee eines Schreibcaches auf der SSD im VDR,
schnelles streamen mehrerer Aufnahmen auf die SSD und nach Aufnahmeende
dann mit langsamer CIFS Datenrate auf die HDD der FB überspielt.
Dazu suche ich eine sinnvolle Lösung.
CIFS mit CacheFS funktioniert nach meinen Infos bisher nur mit Lese -Cache,
Schreiben geht ungepuffert durch.
Ein Ansatz mit mhddfs funktioniert prinzipiell,
leider scheint mhddfs beim Schreiben sehr CPU lastig,
ich messe etwa 70% CPU mit top auf dem Dual Atom beim Schreiben eines HD Streams.
Das läuft jetzt seit einigen Tagen so, nach Aufnahmeende wird per Script automatisch umkopiert.
Teilweise sind die Aufnahmen trotzdem fehlerhaft, vermutlich Aussetzer wegen zu hoher CPU Last im mhddfs.
Mit AUFS gibt es das grundsätzliche Problem, daß das unterlagerte RO-System mit den alten Aufnahmen
(CIFS) kein Löschen zulässt. Neue Aufnahmen könnte man aber natürlich so dazufügen (SSD).
Eine Idee wäre noch die VDR Ringpuffer von 20MB auf Platz für ca. 2-3h HD aufzubohren,
das wären dann einige GB. Dazu müsste deren Verwaltung zuerst von 32Bit int auf 64Bit long umgebaut werden.
Den vielen Speicher könnte die Linux VM liefern mit einem hier etwa 40GB großen Page File auf der SSD,
die eigentliche Speicherarbeit wäre damit auf den Kernel ausgelagert, der das am effizientesten kann.
Oder falls man dem VDR beibringen könnte zur Aufnahme ein anderes Volume zu nutzen (auf der SSD) und es mit
dem "-r Script" nach beendeter Aufnahme in das normale /video zu kopieren wäre das einzige was mir noch
einfällt.
Welche Lösung erscheint am Sinnvollsten, hat jemand schon sowas durchgeführt ?

SW: Debian Testing (AMD64) mit aktuellem VDR und Plugins aus dem vdr-developer git.
VDR: Shuttle XS35GTV2 mit Atom 1,8GHz und ION2 GPU, 4GB DDR2, 60GB SSD, 3xUSB DVB-S2
Server: Fritzbox 7390 mit 2x750GB HDD an aktivem USB Hub
Client: RaspBerry Pi mit OpenELEC
Client: Mehrere Debian u. Windows Notebooks