Beiträge von SNR

    Hallo,

    Danke für den Tipp. Das scheint genau das zu sein, was ich suche....:thumbup:

    Eine Frage hab ich aber. Was ich nicht richtig verstanden habe ist, welche Bedeutung hat der "inactivity-timer". Dedeutet das, dass das Suspend-Plugin anspricht, wenn man keine Taste drückt bzw. spricht das nur darauf an? Springt das Plugin auch sofort an, wenn man das sxfe- Fenster schliesst oder wartet es noch die Timeout-Zeit ab, bis es reagiert? Sobald ich es kompiliert bekomme (ist mir auch noch nicht gelungen), kann ich das aber auch ausprobieren......

    Danke schonmal.


    MfG

    SNR

    Hallo,

    Ich steh mal wieder etwas auf dem Schlauch.

    Voraqussetzung: Server-Client Architektur mit vdr-zu-vdr-streaming. Auf dem Client wird der vdr mit vdr-sxfe als Ausgabe verwendet.


    Frage: Wenn ich das "vdr-sxfe-Fenster" schliesse läuft im Hintergrund der Stream weiter, auch wenn keine Aufnahmen usw. auf dem Client laufen. Beim "softhddevice" wurde der Stream gestoppt oder wenigstens auf wenige kB gedrosselt.

    Gibt es eine Lösung dafür. Soweit ich es verstanden habe, kann z.B. das dynamite-Plugin auf dem Server die DVB-Geräte aushängen. Kann man das für meinen Zweck/Wunsch zweckentfremden? Gibt es ggf. eine Anleitung?


    MfG

    SNR

    Hallo,

    *Arg*, das habe ich befürchtet, war mir aber nicht sicher, ob ich das so richtig verstanden habe. Ich werde den Rpi4 gegen einen ThinClient tauschen (das war jetzt der letzte Punkt, der die Entscheidung hat reifen lassen....), da auch KDE für den Pi ein wenig zu viel ist. Da brauch ich aber meinem Vater auch keine andere Oberfläche "einreden", wenn dann immer noch nicht alles funktioniert.


    Danke für die Klarstellung

    MfG

    SNR

    Hallo,

    Ganz kurze Frage: Kann man auf einem RPi4 mit Raspbian und normalem Fentermanager etc. (z.B. KDE Plasma) das "rpihddevice" in einem normalen Fenster starten? Hat da jemand deinen Tipp/ Link zu einer Anleitung? Ich möchte nur sporadisch den VDR- Streamdev-Client auf dem RPi nutzen. Ich habe es schon mit "vdr-sxfe" probiert, aber da stockt das Bild wegen der fehlenden Hardwarebeschleunigung. Einen reinen 'Fernseh-RPi" (RPi2) mit MLD laufen, da funktioniert alles problemlos.....


    MfG

    SNR

    Hallo,

    Ja, "reini-at", genau so hatte ich mir das auch gedacht und schon angefangen mit der Einrichtung. Nach den hier im Forum schon öfter beschriebenen Problemen, habe ich den epgd bereits dazu gebracht Daten in die DB abzulegen. Nur waren die nur rudimentär und ich wusste nicht, woran das liegt. Bevor ich da weiter Zeit reinstecke, wollte ich mich rückversichern auf dem richtigen Weg zu sein. Jetz funktioniert es.

    Was habe ich gemacht:

    - epgd aus dem git auf dem Server installiert

    - mit dem Tool "epgd-ls-channelids /etc/vdr/channels.conf" hab ich mir die ID's für die Channelmap des epgd ermitteln und davor noch "vdr 000:0:0.." in jede Zeile mit der jeweiligen channelid; die Zeilen mit "epgdata" hab ich rausgenommen

    - "epgd-tool -drop-all", "epgd-tool -del-db", "epgd-tool -new-db" und epgd starten

    und jetzt kommen die Daten in die DB und können vom Clienten mit "epg2vdr" geladen werden

    Mein Problem war im Wesentlichen, dass ich die rudimentäre "channelmap.conf-Astra" von epgd verwendet hatte. Die Einträge dort sind für die Quelle "DVB" nur exotische Sender und ARD/ZDF usw., nach denen ich geschaut habe, sollen von "epgdata" auf dem i-Net geladen werden, was ich ja nicht nutzen will.


    Danke

    MfG

    SNR

    Hallo,

    Ich möchte die epg-Daten die "over-the-air" per DVB-S2 auf dem Server gesammelt werden auf die Clienten verteilen (die Bilder usw. brauch ich nicht zwingend, Text reicht mir).

    Das möchte ich u.a., weil auf meinem Debian 10-Clienten die Anzeige im "vdradmin-am" irgendwie länger dauert, als früher. Außerdem schaut ja nicht jeder immer alle Sender und somit sind auf den jeweiligen Clienten einige Sender ohne epg-Einträge oder ich muss jeden Client im Hintergrund scannen lassen. Das finde ich sehr ineffektiv, das kann der Server doch für alle erledigen. Da auf dem Server eh eine MySQL-Datenbank läuft, ist es für mich sinnvoll die Daten darüber zu verteilen.

    Soweit ich das gelesen/ verstanden habe, machen "epgsync" oder die Syncfunktion des "streamdev" das selbe. Nur "streamdev" im Vorder- und "epgsync" im Hintergrund. Es wird die epg-Datei dees Servers auf den Clienten gesynct.

    Ich such eben nach einer Möglichkeit das alles in die DB zu packen und dann von dort zu verteilen. Scheint für mich schneller zu sein, als im Zweifelsfall große Dateien zu verteilen. Oder mache ich da einen Denkfehler?

    MfG

    SNR

    Hallo,

    Danke, aber wie kommen die Daten vom lokalen epg des Servers in die DB? "epgd" habe ich auch schon auf dem Server installiert, aber der will immer nur die Daten aus dem Internet laden. Danach habe ich noch mal genauer in die Doku geschaut und dort steht eben, dass der "epgd" nur die Daten aus der i-Net-DB holt...oder ich habe das falsch verstanden. In meiner "epg2vdr"-DB auf dem Server habe ich nur Daten in den Tabellen "channelmap", "episodes", "parameter" und "vdr"...aber z.B. in "series" oder anderen Tabellen kommen keine Daten. Ist das normal?


    MfG

    SNR

    Hallo,

    Ich habe hier einen VDR-Server und ein paar Clienten mit DVB-S2 und StreamDev-Server. Nun finde ich es sinnvoll, wenn der Server für die Clienten neben dem Live-TV auch das EPG zur Verfügung stellt. Nun gibt es den epgd, der die Daten aus dem Netz lädt und in eine MySQL/ Maria- Datenbank speichert. Das muss nicht unbedingt sein.

    Gibt es eine Lösung die EPG-Daten vom Server-VDR ebenfalls in eine MySQL-/Maria-DB zu speichern und dann mit epg2vdr auf den Clienten abzurufen?


    MfG

    SNR

    Hallo,


    Das mit den Logs in die Code-Tags habe ich in meiner Verzweiflung glatt vergessen. Natürlich nehme ich die Kritik an und habe das geändert.

    Das Thema "zu neues System", na ja, ich hatte die Probleme auch schon unter "Jessie" und vdr 2.2, nur nicht so schlimm. Das das alles nicht trivial ist, ist mir natürlich auch klar, deshalb wollte ich das auch Schritt für Schritt durchgehen. Außerdem habe ich auch schon auf das Thema "Themes/ Skins" verzichtet.

    Da der neue vdr 2.4 ja einen "Watchdog" mitbringt, der eigentlich zum Neustart beim Einfrieren führen sollte, hatte ich die Hoffnung, dass zum einen der neue vdr das Verhalten (Einfrieren) nicht mehr zeigt oder sich eben selbst neu startet. Leider ist dem eben nicht so.


    Ich glaube auch, dass ich eine Spur gefunden habe. Auf dem Client war das zentrale Video-/Aufnahmenverzeichnis eingebunden und per "bind"-mount in "/var/lib/video" eingehangen. Seit dem ich den Bind-Mount entfernt und das zentrale Videoverzeichnis als separaten Eintrag beim vdr- Starten mit gebe, hängt der vdr nur kurz und fängt sich meist wieder. Die Zeilen mit "invalid TS packets" und die "alsa delay" Meldungen erscheinen aber weiterhin im Log/Journal.


    Was bedeuten die "invalid TS packets"? Ist das Problem eher Server- oder Client-Seitig oder gar im Netzwerk zu suchen?

    Gibt es noch einen Weg besser zu sehen, was im Fehlerfall passiert?


    MfG

    SNR

    Teil 2 zu Problem 1:


    Die "alsa" Einträge werden endlos wiederholt. Die Ausgabe zeigt mehrere FEhler. Normalerweise steht da nicht so viel. Was aber immer in einem solchen Fehlerfall im Log auftaucht, ist die Zeile mit "ERROR: xx TS packet(s) not accepted in Transfer Mode".


    Der Server-VDR wird mit folgenden Optionen gestartet:



    Der Client-VDR auf Client1 wird mit folgenden Optionen gestartet:



    Nun stellt sich natürlich die Frage, wie man das beheben kann? Woran liegt das? Das Problem trat i.Ü. auch schon mit Debian Jessie auf und ist nun nach dem Wechsel auf Stretch aber schlimmer/ häufiger geworden! Auch stürzt der VDR bzw. SoftHDDevice auch gern beim schnellen Vor-/ Rücklauf bei Aufnahmen auf.

    Hat jemand eine Idee/ einen Tipp, wie ich das Problem finden/ beheben kann?

    Kommen wir zu Problem 1:

    Auf allen Debian-Clients hängt die Wiedergabe der Sendungen immer wieder. Manchmal verschwindet auch das "SoftHDDevice"- Fenster. Ich kann das Problem auch "provozieren", indem ich mit dem Mausrad "scrolle" (Mauspfeil über Ausgabefenster). Auf dem MLD habe ich das noch nicht beobachtet. Dort kann ich hin- und herschalten, ohne "Hänger"/ Absturz. Der VDR "fängt" sich meist nicht wider und ich muss auf dem Client mittels "systemctl restart vdr.service" das ganze neu starten.

    Da die Rechner nur "nebenbei" als VDR-Client dienen, wird der VDR-Client "detached" gestartet und per Script das Ausgabefenster als normales FEnster unter KDE geöffnet. Dazu sendet das Script "/usr/bin/svdrpsend plug softhddevice stat", ermittelt damit den Status und öffnet das Fenster mit "/usr/bin/svdrpsend plug softhddevice atta". Gleichzeitig wird ggf. das Compositing mit "qdbus org.kde.KWin /Compositor suspend" ausgesetzt. Beim Beenden wird das nat. alles wieder rückgängig gemacht.


    Während des Problems zeigt das "journal" folgende Einträge auf dem Client namens "dorsy":

    Hallo,


    erstmal zu den Voraussetzungen:

    Im Netzwerk gibt es einen VDR-Server, derzeit 2 VDR-Clients und einen MLD 5.4- Client.


    VDR-Server (NAS):

    Code
    OS: Debian Stretch 9 (mit Backports)
    Kernel: 4.18.0-0.bpo.1-amd64
    NIC: Intel I340-T4 (4xGLan, bonding-RR)
    VGA: NVIDIA GK208 (nur zu TEstzwecken, Betrieb normalerweise "headless")
    HDD: mehrere RAID, davon 1x 4TB Raid für Videos (vdr-Verzeichnis)
    DVB-s: DigitalDevices CineS2 v6.5 mit 3x FlexKarte DVB-s
    VDR-Ausgabe: keine
    VDR-Version: 2.4.0-2~etobi1
    weitere Dienste: LDAP-Server, MariaDB, NFS, Samba-Server, CUPS-Server, Apache (u.a. vdradmin-am)



    VDR-Client1:

    Code
    OS: Debian Stretch 9 (mit Backports)
    Kernel: 4.18.0-0.bpo.1-amd64
    NIC: onboard, NVIDIA MCP55 (2xGLan, bonding-RR)
    VGA: NVIDIA GK104
    HDD: mehrere, NFS-Mount für Videos (vdr-Verzeichnis)
    DVB-s: keine
    VDR-Ausgabe: über SoftHDDevice- Plugin
    VDR-Version: 2.4.0-2~etobi1
    weitere Clients: LDAP, NFS, CUPS


    VDR-Client2:

    Code
    OS: Debian Stretch 9 (mit Backports)
    Kernel: 4.18.0-0.bpo.1-amd64
    NIC:  onboard (1xGLan)
    VGA: NVIDIA
    HDD: 1x, NFS-Mount für Videos (vdr-Verzeichnis)
    DVB-s: keine
    VDR-Ausgabe: über SoftHDDevice- Plugin
    VDR-Version: 2.4.0-2~etobi1
    weitere Clients: LDAP, NFS, CUPS


    VDR-Client3:

    Code
    RaspberryPi 2
    OS: MiniLinuxDVB MLD 5.4
    Kernel: MLD-Kernel
    NIC:  intern
    VGA: "Pi", Ausgabe: HDMI
    HDD: 1x 8GB SD-Karte, NFS-Mount für Videos (vdr-Verzeichnis)
    DVB-s: keine
    VDR-Ausgabe: über rpiHDDevice- Plugin
    VDR-Version: 2.4 von MLD
    weiter Clients: LDAP, NFS


    Ziel:

    1. Es soll ein VDR-Server im Haus die Client-Rechner mit Live-Fernsehen und den zentral gespeicherten Aufnahmen per VDR-VDR-Streaming ("streamdev-server" und "streamdev-client") versorgen. Die Senderlisten sollen identisch sein. Ggf. sollen die Clienten nicht selbst nach neuen Sendern suchen, sondern die Listen von Zeit zu Zeit von Hand ersetzt/ aktualisiert werden.

    2. Das Videoverzeichnis (/var/lib/video auf dem jeweiligen Client) soll per NFS eingebunden werden, um allen die Aufnahmen zur Verfügung zu stellen.

    3. Die Bearbeitung (Schnitt/ Werbung entfernen) soll nur an Client1 erfolgen. Deshalb sollen am Ende die Clients unterschiedliche Nutzer für den VDR bekommen (per LDAP gesteuert). Die anderen Client-Rechner sollen nur Leserechte bekommen. (Problem: Timeshift, wie kann man das kombinieren? Event. ein zweites Videoverzeichnis? Geht das überhaupt? Wenn nicht: wie kann ich das Timeshift deaktivieren?)

    4. Aufnahmen (Timer) werden per "vdradmin-am" auf dem Server gesteuert/ verwaltet.

    5. Außerdem sollen die EPG-Daten in eine SQL-Datenbank auf dem Server gespeichert werden und bei den Clienten dann aus der DB abgerufen werden, damit die Clients nicht selbst alles neu scannen/ abrufen müssen.

    6. IP-TV soll auf dem Server und jedem Client in die normale Programmliste aufgenommen werden und als "normales" Fernsehprogramm angesehen werden. Ideal wäre ein Relay auf dem Server, damit im Fall, dass 2 Clients den selben Stream schauen dieser nur 1x per Internet abgerufen wird (ähnlicht dem Paket "streamdev-server" für Musikstreams).

    7. Auf CLient1 soll ein HDMI-USB3.0- Adapter (Inogeni), der für eine Kamera genutzt wird als "Programm" eingebunden werden.

    8. Auf Server und Client1/2 sollen später ggf. auch USB-Webcams als Programm bzw. auch später noch Überwachungskameras auf dem Server eingebunden werden.


    Probleme:

    1. VDR Client bricht immer wieder ab

    2. Installation/ Einrichtung von eepgd mit SQL-DB (auf Server)

    3. unterschiedliche VDR-Nutzer auf den Clients mit einem Video-DIR

    4. Problem mit eepgd- Einrichtung

    5. IPTV funktioniert nur auf dem MLD und ich komme mit der Einrichtung auf den Debian-Clients bzw. dem Server nicht klar

    6. Wie kann ich den Inogeni-Adapter korrekt einbinden und, im Idealfall, auch anderen Clients oder dem Server verfügbar machen?

    Danke anbr für die schnelle und treffende Antwort!
    Ich könnt mich in den Allerwertesten beißen, komm aber nicht rum....


    Ich hab doch glatt die Zeilen unter Punkt 4 ausgelassen. Bei den vorhergehenden Kernelupdates unter SuSE war der Schritt nat. nicht mehr nötig. Aber bei einer Erstinstallation, wie dieses mal, muss das sein.
    Jetzt funktioniert alles, wie es soll und es gibt eine neue glückliche VDR-Nutzerin!




    MfG
    SNR

    Hallo,
    Ich habe den Rechner einer Bekannten von openSUSE 13.2 (3.16'er Kernel) zu Debian Jessie geändert.
    Unter SuSE ging die Cine CT (v6.5) mit den dddvb Treibern. Doch leider ist mir das mit Jessie noch nicht gelungen die Karte zum Leben zu erwecken. VDR (2.2.1 mit softhddevice) funktioniert, nur die Karte wird nicht erkannt.
    Egal, ob ich den 3.16'er Kernel benutze oder einen der 4'er, die Karte wird nicht richtig erkannt/geladen.
    Die ddvb-Treiber (0.9.29 und ältere) konnte ich problemlos kompilieren. Dann wird aber die "ddbridge" nicht automatisch geladen. Wenn ich das Modul per Hand lade, kommt in "journal" nur folgende Ausgabe:

    Code
    Jun 26 23:08:27 aki kernel: Digital Devices PCIE bridge driver, 
    Copyright (C) 2010-11 Digital Devices GmbH


    Dann passiert leider nichts mehr.

    Code
    root@aki:~# lsmod | grep bridge
    ddbridge           	21641  0
    dvb_core          	102060  1 ddbridge
    i2c_core           	46012  4 drm,ddbridge,nvidia,i2c_nforce2


    VDR sagt mir dann beim manuellen Neustart nur das hier (Auszug):

    Code
    Jun 26 23:11:41 aki vdr[4293]: [4293] no DVB device found


    Um einen Hardwaredefekt auszuschließen, habe ich eine easyVDR- Live-CD (mit 4.4'er Kernel und ddvb) probiert und dort werden die Tuner korrekt erkannt (habe leider keine Ausgabe, da ich es nur "auf die Schnelle" probiert habe und so konnte ich nichts abspeichern).


    Die Frage ist nun, warum funktioniert das nicht?
    Welchen Treiber mit welchem Kernel kann ich verwenden (Debian bietet ja 3.16'er, 4.6'er und 4.9'er Versionen)?
    Oder doch besser statt ddvb den media-build (hab ich schon probiert, kompiliert aber nicht)?
    Wie kann ich herausfinden, warum das Modul "ddbridge" beim Booten nicht eingebunden wird ("messages" sagt dazu leider nichts, nur eben die eine Kernel-Zeile) ?


    OS: Debian Jessie (mit Backports, e-Tobi und OppServer- Paketen)
    Kernel: 4.9.30-2~bpo8+1 oder 3.16.43-2+deb8u1 (64bit)



    MfG
    SNR

    Hallo,


    Ich habe mal die easyVDR 3.0 Live ausprobiert. Leider mit einem ähnlichen Ergebnis:


    Code
    Linux easyVDR 4.4.0-45-generic #66~14.04.1-Ubuntu SMP Wed Oct 19 15:05:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux




    Ich habe das dann noch mal mit ein paar mehr "Counts" laufen lassen:



    Die Frage ist, warum das auf einigen Tunern erst funktioniert und dann abbricht. Das das nur was mit dem bekannten Problem der "Werte aus den FlexModulen" zu tun hat glaube ich noch nicht ganz.
    Ich habe noch so eine Vermutung: event. ist das 300W-Natzteil doch zu klein (Kontron APU-Board, 3x HDD, CineS2+3x Flex, 1x Slim-DVD-RW).
    Muss ich am WE event. noch mal mit einem größeren Netzteil ausprobieren.


    MfG
    SNR

    Hallo,


    Ich habe mal einen älteren Kernel probiert (3.16.39-1+deb8u1). Dort ist nat. keine ddvb-Unterstützung drin. Also habe ich den Treiber aus dem git gezogen und kompiliert. Leider gleiches Ergebnis. "DVB3" bringt kein Signal. Mal abgesehen von den Femon- Werten bleibt bei mir der Bildschirm schwarz (bekomme kein Bild/ Ton), wenn ein Client (egal, ob SoftHDDevice-Client oder MLD 5.1) diesen Tuner zugewiesen bekommt.


    Ich werde, sobald ich Zeit habe, einfach mal die Kabel an der CineS2 tauschen (die Flexkabel im Rechner) und so sollte ja der jetzige DVB3 zu DVB5 werden. Mal sehen, ob sich dann was ändert.



    MfG
    SNR

    Hallo,


    Erstmal Danke für eure Anregungen.


    Ich glaube aber, dass ich ein Treiberproblem habe. Ich habe die Satkabel an der Karte gewechselt, also von DVB4 auf DVB3 umgeschraubt, und trotzdem hat DVB3 keinen Empfang.
    Da es hier im Forum schon ähnliche Einträge gab, habe ich mal den Treiber aus dem git von DigitalDevices geclont (Version: 0.9.28 mit Debian Kernel 4.9.2) und installiert.
    Das Ergebnis:
    ---------------------------------------------------
    root@snrnas:~# femon -H -a0
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a1
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a2
    FE: STV090x Multistandard (DVBS)
    status | signal 99% | snr 99% | ber 8388608 | unc 6 |
    status | signal 99% | snr 99% | ber 8388608 | unc 0 |
    status SC | signal 99% | snr 99% | ber 8388608 | unc 0 |
    ^C
    root@snrnas:~# femon -H -a3
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a4
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a5
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a6
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a7
    FE: STV090x Multistandard (DVBS)
    status | signal 99% | snr 99% | ber 8388608 | unc 0 |
    status | signal 99% | snr 99% | ber 8388608 | unc 0 |
    status | signal 99% | snr 99% | ber 8388608 | unc 0 |
    ^C
    ---------------------------------------------------


    Das bedeutet meiner Meinung nach, dass weder DVB3 noch DVB8 Empfang hat.
    Nachdem ich nun den Kernel einfach noch mal installiert habe, ohne den dddvb-Treiber neu zu installieren, bekomme ich folgendes Ergebnis:


    ---------------------------------------------------
    root@snrnas:~# femon -H -a0
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a1
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a2
    FE: STV090x Multistandard (DVBS)
    status SC | signal 99% | snr 0% | ber 8388608 | unc 0 |
    status SC | signal 99% | snr 99% | ber 8388608 | unc 0 |
    status SC | signal 99% | snr 99% | ber 8388608 | unc 0 |
    ^C
    root@snrnas:~# femon -H -a3
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a4
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a5
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a6
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    root@snrnas:~# femon -H -a7
    FE: STV090x Multistandard (DVBS)
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    status SCVYL | signal 99% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK
    ^C
    ---------------------------------------------------


    Das scheint mir ein Treiberproblem zu sein. Oder wie seht ihr das?


    OS: Debian Jessie mit Backports und eTobi
    Kernel: Linux snrnas 4.9.0-0.bpo.1-amd64 #1 SMP Debian 4.9.2-2~bpo8+1 (2017-01-26) x86_64 GNU/Linux
    VDR: 2.2.0-5~etobi1


    MfG
    SNR

    Hallo,


    Danke für Deine Antwort. Ja, einige Plugins muss ich mal rausschmeißen, da ich den Server "headless" betriebe.
    Ich habe in der Zwischenzeit noch etwas "gespielt" und mal beide Clienten gleichzeitig angemacht und folgendes auf der Konsole mitlaufen lassen:

    Code
    Ausgabe von "watch svdrpsend plug streamdev-server lstc":
    Every 2,0s: svdrpsend plug streamdev-server lstc
    220 snrnas SVDRP VideoDiskRecorder 2.2.0; Wed Feb 15 16:22:03 2017; UTF-8
    250-0x7f2bc80008c0: VTP 192.168.0.144:46922 DVB3	2 ZDF HD
    250 0x7f2bc800dbc0: VTP 192.168.0.1:50283 DVB1   11 arte HD
    221 snrnas closing connection


    Beim "wild umschalten" auf beiden Clienten während und nach der Aufnahme ist mir aufgefallen, dass automatisch die DVB-Devices gewechselt werden (so wie ich das erwartet habe).
    Immer wenn das Device "DVB3" verwendet wird kommt nichts! Egal, ob eine Aufnahme läuft oder nicht. Entweder ich habe ein Verkabelungs oder ein Hardware-Problem. Bin gerade am Suchen.


    Danke trotzdem.


    MfG
    Sebastian Reinhardt

    Hallo,


    Ich habe hier ein Client/Server- Setup.
    Server:
    - OS:Debian Jessie (mit Backports und eTobi-Paketen, aktuell)
    - Hardware: DigitalDevices Cine S2 V6.5 mit 3x DupFlex S2 (insgesamt 8 DVB-S2 Tuner)
    - VDR: 2.2.0-5~etobi1 mit Streamdev-Server 0.6.1+git20150213-3


    1. Client:
    - "normaler" Desktop mit Debian Jessie (auch Backports und eTobi, aktuell)
    - VDR: 2.2.0-5~etobi1 mit Streamdev-Client 0.6.1+git20150213-3 und softhddevice 0.6.0+git20151102-2


    2. Client:
    MLD 5.1 auf RaspberryPi 2 an 24" Bildschirm


    Ich kann alle Fernsehkanäle ansehen, bis ein Timer anfängt aufzuzeichen. Dann kann ich nur noch den Kanal ansehen, der gerade aufgezeichnet wird.
    Auf dem Server kommt dann so was im "journal":


    Wenn ich zur gleichen Zeit einen anderen Sender sehe, egal auf welchem Clienten, dann bleiben Ton und Bild einfach weg.


    Versuche ich nun einen Sender, nicht den der gerade aufnimmt, ein zu schalten (hier "kabel eins doku", während ZDF HD aufnimmt), dann bekomme ich im "journal" folgendes:


    Ich bin eigentlich davon ausgegangen, dass der VDR-Server einen anderen freien Tuner verwendet oder sehe ich das falsch?
    Kann ich dem VDR-Server irgendwie beibringen, dass er insgesamt 8 Tuner hat? Beim Start scheint er ja alle Tuner zu erkennen:



    Ich möchte schließlich noch mehr Clienten anschließen.....


    Kann mir da jemand helfen?



    MfG
    Sebastian Reinhardt