Beiträge von KiLLERHOLiC

Zitat von Tiroler

Wir haben oft 2-3 TVs eingeschalten und nicht selten nimmt der Server noch 1-2 Sendungen gleichzeitig auf... kein Problem. Ehestens machen verschlüsselte Sender Troubles (ORF, ATV, PULS4) - wenn du das nicht benötigst, sparst du dir viel Ärger

Gefällt mir 2-3 Clients gleichzeitig und parallel noch Aufnehmen.. bestens, mehr brauche ich sicher nicht.
Zurzeit hab ich einen Kabelbetreiber mit Grundverschlüsselung, aber mein "bester Freund" erledigt das decodieren zu meiner vollsten Zufriedenheit. Hast du ein CAM mit CI und ORF-Karte?

Zitat von Mreimer

Wenn die Leitungen an zentraler Stelle zusammenlaufen, dann wäre es durchaus eine Lösung, eine zweite LAN-Karte in den Server zu bauen und dann an der einen Karte nur VDR-Clients und an der zweiten den Rest anzuschließen.

Dann müsste aber der Server auch das Internet Routing übernehmen. bzw. alles was Clients hinter dem Server ist(ausser andere Clients, z.B. Print-Server etc...).

Zitat von Tiroler

Ja, DD-WRT beeinflusst nur den Internet Traffic - ich habe seit 3 Jahren auch eine reine streamdev Lösung im Einsatz... bin recht zufrieden damit, ist auch familientauglich
Seit ich auf einen GBit Switch umgestellt habe, bekomme ich häufiger Probleme wenn Clients größere Dateien vom Server laden... am TV friert dann das Bild ein bzw. es kommt zu Standbildern...
So gesehen würde mich auch eine Dienste bzw. Traffic Regulierung am Server ebenfalls sehr interessieren! Lt. Google gibts ja einiges in diesem Bereich... hat jemand hierzu Erfahrungen?

Freut mich das es Leute gibt die es produktiv einsetzten und zufrieden sind. Das macht mir gleich mehr Hoffnung das ich es auch so betreiben kann.
Wie viele Clients hast du maximal gleichzeitig am laufen?
Mittlerweile gehe ich davon aus das man die QOS Sache nur richtig lösen kann in dem man einen passenden Switch verwendet. Dieser sollte es z.B. möglich machen: http://geizhals.at/615437?v=l
Vorteil ist das es unabhängig von allen PCs ist. Einmal am Switch konfiguriert bekommt das streamdev Protokoll immer die höchste Priorität egal wer oder was sonnst noch im Netzwerk aktiv ist.
Wird es direkt am Server konfiguriert (falls möglich k.a.) kann ja nur der Server seine Dienste priorisieren, falls sich aber Clients untereinander Daten austauschen könnte das Netzwerk wieder blockiert werden.

Nach meinen ersten Tests hatte ich ja hin und wieder mal hänger und Probleme beim Umschalten.
Nachdem ich gestern ein dist-upgrade (yaVDR-0.5) gemacht habe, alle unnötigen Plugins deaktiviert habe und die DVB-C Karte ausgebaut habe funktioniert es richtig gut.
Hatte bei ca. 50x durchzappen einmal das Problem das kein Bild kam, beim nächsten umschalten war es aber wieder da. Hänger hatte ich überhaupt keine mehr.
Ich werde das mal die nächsten Wochen/Monate so lassen und sehen wie gut es funktioniert.
Nach den gestrigen Änderungen kann ich mir aber gut vorstellen alles übers Netzwerk zu machen.
Das einzige ungeklärte Thema ist noch QOS bzw. wie stelle ich sicher das der streamdev-Netzwerkverkehr immer die oberste Priorität hat?
Bei meinen Netzwerk ist es eigentlich so das die Clients untereinander nicht/sehr wenig Verkehr verursachen, beim Internet mach ich mir auch keine Sorgen, das geht sicher auch leicht über die GBit Leitung.
Das einzige wäre Server<->Client da kann es schon mal vorkommen das einige GByte an Daten über die Leitung wandern. Und in solchen Situationen soll das Fernsehbild nicht hängenbleiben.
Kann so eine Bandbreitenverwaltung am Server erfolgen? Oder muss ich das am Router machen?
Zurzeit habe ich einen Router mit DD-WRT drauf, dahinter einen GBit Switch an dem auch der Server hängt und ein paar Clients.
Der Router hat schon QOS Einstellungen aber bisher dachte ich immer das die zum Priorisieren des Internetverkehrs sind (z.B. Skype höher als Torrent). Im eigenen Netzwerk haben die glaub ich keine Auswirkung.

Zitat von Mreimer

Für den separaten Multiswitch spricht die größere Flexibilität. Zudem müssen nicht 8 Kabel bis zum LNB gezogen werden.

Was ist mit Flexibilität genau gemeint? Klar 4 gegen 8 Kabel zum LNB ist ein Argument. Auf der anderen Seite spare ich mir ein extra Gerät.

Zitat von Mreimer

Die Frage zur Zuverlässigkeit ist aber durchaus interessant. Einen VDR-Server als pure "Kopfstation" zu betreiben stelle ich mir von Software-Standpunkt aus recht einfach vor. Man könnte ggf. sogar mit einem Readonly-Root-FS auskommen und dann den Server in Gänze von einer SD-Karte booten lassen. Als TV-Karten-Lösung bietet sich die Octopus-Lösung von L4M an. Damit bekommt man auch auf Mainboards in kleiner Bauform reichlich Tuner zum Laufen.

Es soll ja kein reiner VDR-Server sein. Ich möchte meinen bestehenden Server dafür verwenden. Auf diesem laufen andere Dienste wie Samba, Tonido etc...

Zitat von Mreimer

Wie sieht es mit Stromverbrauch aus? Die ganzen Tuner brauchen dann ja ständig Strom, auch wenn im Haus alle VDRs im Standby sind. Da die Multiswitch-Seitig nie vom Netz gehen, kann auch der Multiswitch nicht in Standby gehen...

Stromverbrauch ist mir vorerst mal nicht so wichtig. Der Server läuft sowieso rund um die Uhr, die paar Watt mehr für Tuner sind dann sicher nicht so schlimm.
Aber Multiswitch ist noch ein Thema, gedacht hab ich an 3 Doppeltuner DVB-S2 Karten, damit sollte ich genug Kapazität für maximal 3 Clients und gleichzeitig laufende Aufnahmen haben.
Bisher war ich der Meinung einen Quad-LNB und einen Multiswitch zu verwenden, allerdings hab ich schon LNBs mit bis zu 8 Ausgängen gesehen. Was spricht für einen Multiswitch oder einen LNB mit 8 Ausgängen?

Hallo,

da ich demnächst eventuell auf Sat umstellen kann hab ich mir mal Gedanken darüber gemacht wie die Ausstattung meiner Systeme geändert werden muss und wie die Verkabelung in Zukunft aussehen muss.
Zurzeit hab ich einen Server (Debian 6 mit e-tobi Paketen) und zwei Clients (yaVDR 0.5). Später wird noch ein dritter Client folgen.
Dabei bin ich auf das streamdev Plugin gekommen welches ich hin und wieder nutze um von meinem Server auf einen Windows-PC zu streamen.
Etwas in Vergessenheit geraten ist dabei das streamdev-client Plugin mit dem man ja von von VDR zu VDR streamen kann.
Ich hab das ganze gestern Abend mal getestet und bin schon begeistert davon. Die Umschaltzeiten sind richtig schnell, kaum ein Unterschied zu der eingebauten TV-Karte zu bemerken.
Hin und wieder hängt sich allerdings der Stream auf. Hatte aber noch keine Gelegenheit die Logs zu prüfen.
Jetzt stellt sich für mich halt die Frage ob ich in Zukunft komplett auf Koax-Kabel verzichte und alles über Netzwerk machen soll.
Hat das jemand bereits Produktiv im Einsatz?
Wie funktioniert der streamdev-server mit mehreren aktiven Clients?
streamdev verwendet ja eine direkte Verbindung zwischen Server und Client, dh. wenn mehrere Clients den selben Sender schauen wird dieser so oft übers Netzwerk gestreamt wie es Clients gibt oder läuft das ganze über Multicast?
Wenn mehrere Clients am selben Transponder schauen wird aber nur eine Karte verwendet oder?
Da mein Server noch andere Dinge als VDR-Server erledigt muss ich irgendwie sicherstellen das die streamdev Verbindung immer oberste Priorität hat (auch wenn über Samba Daten übertragen werden etc...), gibt es sowas wie ein einfach zu konfigurierendes QOS-System?
In der Praxis habe ich dann maximal 2 aktive Clients in einem GBit-Netzwerk. Das sollte von der Bandbreite überhaupt kein Problem sein. Allerdings möchte ich vermeiden das es zu Fehlern bei der Übertragung kommt nur weil ich z.B. Dateien auf den Server kopiere.

Für Tipps und Erfahrungsberichte wäre ich sehr dankbar.

Hallo,

hab gerade vdr-plugin-mplayer installiert und hatte dann das Problem das nach dem anwählen einer Datei das Bild kurz schwarz wurde und dann das Live-TV Bild zurückkam.
Lösung ist das die Template für /usr/share/vdr-plugin-mplayer/mplayer für dvbhddevice erweitert werden muss.
Hab die Datei mal angehängt. Den Inhalt hab ich von hier genommen: vdr-plugin-mplayer

Hab am Sonntag diese Version installiert und bin echt begeistert davon.
Für mich am besten ist das der IR-Empfänger IMON VFD (MCE) vom Antec Fusion wieder funktioniert. Mit der 0.4 hatte ich das Problem das ich hin und wieder mal Kernel-Panics beim hochfahren (meisten wenn der Rechner ein paar Stunden ausgeschaltet war). Meine Lösung damals war das ich einen externen Empfänger angesteckt habe und das imon Modul ge-blacklist-ed hab.
Ausserdem fährt der Rechner jetzt auch sauber runter wenn das XBMC vorher aktiv war. Ich hatte vorher oft das Problem das VDR beim runterfahren gemeldet hat das XBMC noch aktiv ist.
Umschaltzeiten sind gefühlt etwas schneller und auch das vorspringen in Aufnahmen kommt mir etwas schneller vor.
Alles in allem sehr gelungen, da bei mir alles reibungslos funktioniert würde ich die Version als RC-1 statt alpha-1 bezeichnen ;).

Zitat von gda

coHaus scheint in der letzten Zeit einige neue Modelle mit neuen USB-IDs zu verkaufen. Wir haben einen linux-media-dkms in testing der da eventuell etwas weiterhelfen könnte.

Gerald

Danke für den Tip! Hat bei mir auch geholfen, ich hab einen Lenovo RC6 Empfänger über ebay gekauft und der wollte nach dem anstecken auch nicht gleich funktionieren.
Der Empfänger sieht gleich aus wie der bei coHaus, er hat nur ein Lenovo Logo vorne drauf. Er hat auch die selbe Vendor und Device ID (0471:2093 Philips (or NXP))

Hier noch ein Mirror für die Pakete von DarkAngel:

http://web15.public1.linz.at/f…c720b-da0_natty_amd64.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb
http://web15.public1.linz.at/f…d0eb-0da0_natty_amd64.deb
http://web15.public1.linz.at/f…3982-0da0_natty_amd64.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb
http://web15.public1.linz.at/f…3982-0da0_natty_amd64.deb
http://web15.public1.linz.at/f…033982-0da0_natty_all.deb

DarkAngel
Kannst du bitte eine kurze Anleitung machen wie du die Pakete erstellt hast?
Danke!

Zitat von armelle

Nachtrag falls noch jemand darueber stolpert:

Kernelfreeze bei Netzwerktransfer bei GA-M720-US3

Hallo Leute,

kopierte heute eine ISO uebers Netzwerk auf meinen Server, und ca. bei der haelfte fror das gesamte System ein. Danach wartete ich noch ca. 10 Minuten, und ich machte einen Hardreset. Ich versuchte das dann nochmal mit ner anderen ISO, und wieder das gleiche.

Problem:
Immer wieder haengt das System, in meinem Fall Ubuntu 10.04 server/Linux Mint 9 + yavdr-ppa. Gerade bei hoher Netzwerklast. Das Board ist ein GA-M720-US3. In den Logfiles sieht man folgenden Fehler, fast sekuendlich, kurz vorm ableben:

r8169 0000:02:00.0: eth0: link up

Ursache:

Nach laengeren Recherchen im Internet liegt das Problem am falschen Treiber für die Onboard Realtek Netzwerkkarte. Es wir statt dem Treiber r8168 der Treiber r8169 verwendet.

So zu loesen:

Code

apt-cache search r8168

r8168-dkms - r8168 driver in DKMS format.

Code

apt-get install r8168-dkms

reboot,

Code

ethtool -i eth0

driver: r8168
version: 8.015.00-NAPI
firmware-version:
bus-info: 0000:02:00.0

Code

lspci -vv

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: Giga-byte Technology Device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 26
Region 0: I/O ports at bc00
Region 2: Memory at fdcff000 (64-bit, prefetchable)
Region 4: Memory at fdce0000 (64-bit, prefetchable)
[virtual] Expansion ROM at fdc00000 [disabled]
Capabilities: <access denied>
Kernel driver in use: r8168
Kernel modules: r8168, r8169

Code

uname -r

2.6.32-33-server

Danach ist wieder alles gut.

Gruss

Armelle

Alles anzeigen

Jetzt wo ich das lese könnte ich mich in den *** beissen.
Ich hatte genau dieses Problem unter Ubuntu 11.04 und dann auch unter Debian 6.
Meine Lösung war dann eine neue PCIe Netzwerkkarte (auch mit dem 8111 Chip), seit die drinnen ist funktioniert alles ohne Probleme.
Hätte ich nur vorher im VDR-Portal geschaut....

Weis jemand zufällig seit wann das Problem besteht, hatte mein System damals mit Ubuntu 9.04 installiert und dort lief es immer ohne Probleme.
Dann hab ich mal Updates auf 11.04 gemacht und dort lief es auch lange Zeit noch. Und auf einmal hatte ich diese Probleme, immer wenn ich von meinem PC auf den Server kopieren wollte fror das ganze System ein.

Hallo,

erstmal ein rießiges Dankeschön an das yaVDR Team, ich hatte vor Jahren einen "SD" VDR im Wohnzimmer, mit aufkommen von HD-Sendern bin ich zu Windows (DVB Viewer und XBMC) gewechselt.
Da ich damit in letzter Zeit ab nicht mehr so zufrieden war hab ich Media Portal probiert, nicht schlecht aber keine Verbesserung.
Dann erinnerte ich mich wieder an die gute alte VDR Zeit und begab mich auf die Suche... was soll ich sagen, ich bin überwältigt von eurer Distribution.
Von vorne bis hinten durchdacht, einfachst in der Konfiguration/Bedienung und super stabil.

So und jetzt zum eigentlichen Thema:

Ich hab das zappilot plugin etwas umgebaut, zu finden ist es hier:
http://projects.vdr-developer.org/issues/846
Ich hab ein .deb Paket erstellt das mit yaVDR 0.4 kompatibel ist und eine diff Datei für die Quellen.

Vieleicht kann es ja jemand gebrauchen, ich wollte mich einfach nicht von der gewohnten Steuerung abbringen lassen

Zitat von Copperhead

Hat ORF überhaupt NALU-Füll-Daten?

Klingt ehr danach, als ob du einfach einen minimalen Versatz zwischen den Aufnahmen hast.

Nein, die Aufnahmen waren gleich lang und fingen auch gleichzeitig an.
Siehe auch hier: [ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool

Nachdem ich diesen Thread gestern zufällig entdeckt habe hab ich meinen VDR (von 1.7.13 auf 1.7.17) auf den neuesten Stand gebracht und deinen Patch gleich angewendet.
Zum testen hab ich 10 Minuten von ORF 1 HD mit aktiviertem und ohne aktiviertem Patch aufgenommen (waren 2 Zeitgleiche Aufnahmen, also selber Inhalt). Der Unterschied waren 35MB. Hab mir die kleinere Datei mit VLC angesehen und konnte keine Fehler entdecken. Funktioniert also perfekt (und auch mit VDR 1.7.17)! Danke!

Dürfte wirklich am Betreiber liegen. Hab jetzt eine neue channels.conf erstellt. Vorher noch kontrolliert, die Sender wurden als QAM256 eingetragen.
VDR mit neuer Senderliste gestartet, stream gestartet und im Log sind wieder die selben Meldungen aufgetaucht. Stream gestoppt und wieder gestartet und vorbei war es mit dem Bild.

Hab jetzt im Setup ausgewählt das er nur neue Sender hinzufügen soll. Soweit funktioniert es jetzt.
Was passiert jetzt wenn sich irgendwelche Daten vom Sender ändern? Werden z.B. PID änderungen trotzdem gespeichert?
Oder wird der Sender ein zweites mal mit den neuen Daten angelegt?

Zitat

Original von halbfertiger
Ich würde die Einträge der Sender völlig neu anlegen, besser von vdr anlegen lassen. Die QAM256-Sender könnten ja neue IDs erhalten haben.

Wenn ich die Sender einfach aus der Liste lösche findet sie der VDR automatisch wieder? Oder soll ich mit w_scan eine neue Senderliste erstellen?

Hallo,

hab wieder mal ein Problem mit meinem VDR System.
Ich betreibe einen VDR 1.7.13 auf einem Ubuntu Server mit Liwest als Kabelbetreiber. Eingebaut sind 4 DVB-C Budget Karten (Terratec u. Satelco).
Liwest hat vor einiger Zeit (fast) alle Sender auf QAM256 umgestellt. Hab es erst gestern bemerkt das ich manche Sender nicht streamen kann die auf einem anderen PC unter Windows mit DVBViewer funktionieren.
Hab mich auf die Suche gemacht und das Problem auch relativ schnell gefunden, in der channels.conf sind die betroffenen Sender als QAM64 eingetragen.
Hab den VDR gestoppt, die channels.conf händisch geändert, den VDR wieder gestartet und konnte dann alle Sender streamen.
Ich hatte nebenbei den Log laufen und bekam diverse Meldungen das die Transponder Daten für verschiedene sender von QAM256 auf QAM64 geändert werden.
Zum testen hab ich den stream kurz gestoppt und wieder gestartet. Prompt bekam ich kein Bild mehr.
Wie kann ich diese änderung verhindern ohne die gesamte Senderaktualisierung zu deaktivieren?

Vielen Dank für Tipps und Lösungsvorschläge!
KiLLERHOLiC

Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 279 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 280 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 281 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 282 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 283 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 284 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 285 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 286 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 287 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 288 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900
Feb 28 08:36:14 ubuntu vdr: [2283] changing transponder data of channel 396 from 562000:C0M256:C:6900 to 562000:C0M64:C:6900

Zitat

Original von KiLLERHOLiC
Hab das Problem mit dem Ton lösen können. Es liegt am VLC der zurzeit ausgeliefert wird.
Hab ihn nach dieser Anleitung händisch installiert und jetzt funktioniert das konvertieren.
Streamen kann ich erst am Abend probieren wenn ich wieder zuhause bin.

Streamen hat funktioniert (Bild u. Ton), werd es aber jetzt doch anders lösen.
Trotzdem ein nettes Plugin!