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


    VDR-Client1:

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

    VDR-Client2:

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


    VDR-Client3:

    Code
    1. RaspberryPi 2
    2. OS: MiniLinuxDVB MLD 5.4
    3. Kernel: MLD-Kernel
    4. NIC: intern
    5. VGA: "Pi", Ausgabe: HDMI
    6. HDD: 1x 8GB SD-Karte, NFS-Mount für Videos (vdr-Verzeichnis)
    7. DVB-s: keine
    8. VDR-Ausgabe: über rpiHDDevice- Plugin
    9. VDR-Version: 2.4 von MLD
    10. 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
    1. Jun 26 23:08:27 aki kernel: Digital Devices PCIE bridge driver,
    2. Copyright (C) 2010-11 Digital Devices GmbH


    Dann passiert leider nichts mehr.

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


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

    Code
    1. 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
    1. 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
    1. Ausgabe von "watch svdrpsend plug streamdev-server lstc":
    2. Every 2,0s: svdrpsend plug streamdev-server lstc
    3. 220 snrnas SVDRP VideoDiskRecorder 2.2.0; Wed Feb 15 16:22:03 2017; UTF-8
    4. 250-0x7f2bc80008c0: VTP 192.168.0.144:46922 DVB3 2 ZDF HD
    5. 250 0x7f2bc800dbc0: VTP 192.168.0.1:50283 DVB1 11 arte HD
    6. 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

    Hallo,


    Ursprünglich hatte ich die Einstellungen in die "/etc/vdr/conf.avail/streamdev-client.conf" eingetragen. Das funktioniert offenbar noch nicht. Jetzt aktuell mit exakt den gleichen Daten/ Einstellungen in "/etc/vdr/setup.conf" funktioniert der vdr auf dem Client- Rechner! Es wird ein Verbindung zum Server aufgebaut.
    Was ich noch nicht verstehe ist, dass auf dem Server die Einstellungen aus "/etc/vdr/conf.avail/streamdev.conf" geladen und offenbar auch beachtet werden.....wobei ich da auch nichts an den "default"- Optionen geändert habe, könnte also event. auch nicht aus der "/etc/vdr/conv.avail/streamdev.conf" geladen werden. Das muss ich noch mal ausprobieren müssen.
    Wenn ich nun z.B. mit "vlc" per http-Protokoll auf "http://localhost:37890" zugreife, dann bekomme ich das Liveprogramm. Nun habe ich bereits den "VDRManager-AM" auf dem Client installiert und kann mit der dortigen Fernbedienung auf dem Client auch umschalten! Allerdings hängt dann das Programm im "vlc" und ich muss dann "vlc" beenden und neu starten. Nach den "vlc" Neustart kommt dann auch das neue Programm. Mit dem "softhddevice" klappt alles, wie erwartet (umschalten pe "vdradmin-am"- Fernbedienung incl. OSD usw.), nur dass eben der Ton fehlt (ist auch klar, wird ja durch "root" gestartet und das Soundrouting müsste noch angepasst werden). Grundsätzlich funktioniert der Client also, auch "xineliboutput"-Plugin sollte erstmal grundsätzlich funktionieren. Dennoch findet "vdr-sxfe" dummerweise kein passendes Input-Plugin. Ich weiss aber nicht was da fehlt.
    Mir ist zwar aufgefallen, dass ich mit den Standard und eTobi- Paketquellen kann ich auf dem Client "vdr-plugin-xine" nicht installieren (benötigt vdr-abi-2.0). Benötige ich das? Was könnte fehlen? "vdr-fbfe" hilft auch nicht, das mekert sofort, das kein Framebuffer-Gerät gefunden werden kann (ist auch klar, ist ja ein X11- Desktop-Rechner).


    Eine weitere Frage die ich mir stelle ist, ist ob das die sinnvollste Variante ist einen vdr-Client auf dem Client-Rechner zu installieren. Der (bzw. später die) Rechner werden ja als normale Desktop und nicht als Multimedia-Rechner verwendet und nur "bei Bedarf" soll der "Fernseher" durch den Nutzer gestartet werden. Da aber nach meinem Verständnis die "xinelibout"- Variante nur von gleichzeitig einem Clienten verwendet werden kann, scheint es für mich nicht sinnvoll auf dem vdr-Server das Plugin zu installieren und dann vom Client aus mit einem Frontend ala "vdr-sxfe" o.ä. zu zu greifen. Oder sehe ich das falsch? Was mich am "vdr-zu-vdr"- Streaming stört, ist der ständige Netzwerkverkehr auch bei Nichtnutzung......am "http"- Streaming stört mich aber, dass das OSD fehlt, das Umschalten kompliziert ist (man muss die komplette URl eingeben, den Senderplatz wissen usw.), der Teletext und alle "netten" Dinge von vdr fehlen! Außerdem soll ja auf jedem Client- Rechner noch eine IR-Fernbedienung mittels LIRC nachgerüstet werden. Da vermute ich mal, dass das nur mit einem eigenen vdr-Client pro Rechner funktioniert.... ?(


    MfG
    SNR

    Hallo, ich nochmal,


    Ich habe jetzt eine Verbindung zwischen Client und Server hin bekommen!
    Nachdem ich auf dem MLD-Client noch mal auf der Konsole in die Konfig geschaut habe, habe ich die "streamdev-client" Einstellungen nicht in die "/etc/vdr/conf.avail/streamdev-client.conf" sondern in die "/etc/vdr/setup.conf" eingetragen. Und siehe da, es kommt eine Verbindung zu Stande! :cool1
    Beim Neustarten des VDR auf dem Client wird dann auch das "Softhddevice" bzw. dessen Ausgabefenster gestartet und es kommt Kanal 1 (bei mir ARD), aber ohne Ton!
    Mal abgesehen davon ist das sicher nicht die richtige Lösung für mich, da ich beim Systemstart "vdr" per default starten möchte und dann nach Bedarf ein Frontend im frei skalierbaren und jederzeit zu öffnenden/ schließbaren Fenster öffnen möchte! Also so, als hätte ich keinen VDR sondern eine DVB-Karte und z.B. "Kaffeine" als Frontend. Zur Steuerung soll dann mal eine IR-Fernbedienung per USB-IR-Receiver oder, wenn es so was gibt, eine "Fernsteuerung" per Webseite, wie beim MLD dienen.
    Eine Möglichkeit sah ich bisher im Einsatz von "vdr-sxfe" als frei nutzbares Fenster...oder ist das der falsche Ansatz?


    Ich habe nochmal das "vdr-plugin-xineliboutput" installiert und kann dort auch mit z.B. "vlc http://localhost:37890" auf den Client-vdr zugreifen und bekomme Bild/Ton. Dort kommt also was an. Nur "vdr-sxfe" meckert immer noch, das kein passendes Input-Plugin" gefunden werden kann:



    MfG
    SNR

    Hallo,


    Danke für die Hinweise.
    Ich bin mir zwar nicht sicher, worauf die Frage mit dem "Backend VDR" abziehlt, aber ich vermute mal, dass die eigentliche Frage ist, ob im CLient ein DVB-Device steckt?
    Der Server hat eine 8-fach Digital Devices Cine S2 (8x Sat ohne CAM oder ähnliches) und im Client steckt keine DVB- Karte. Wenn das nicht die richtige Info ist, einfach noch mal genauer sagen, welche Info nötig ist..... ?(


    Da ich nat. schon einiges probiert habe und ich deshalb auch einiges hin- und herinstalliert habe, habe ich jetzt einfach mal alle vdr- Pakete und Plugins komplett deinstalliert und die Konfigdateien gelöscht.
    Nun habe ich nur die nötigsten Pakete installiert (vdr, vdr-plugin-softhddevice und vdr-streamdev-client). Damit kann ich zwar den Server nicht "fernbedienen", aber das bracuh ich erst, wenn ch überhaupt ein Bild/ Ton bekomme.
    Beim erneuten Installieren ist mir aufgefallen, dass beim "softhddevice" die Datein im "/etc/vdr/conf.avail/" nicht angelegt wird (Obwohl das bei den installierten Dateien in "Synaptic" mit angezeigt wird!-> event. ein Bug in den etobi- Paketen?).
    Nachdem ich die Datei von Hand angelegt habe, wird das "softhddevice" geladen.


    Dennoch bekomme ich nur das Fenster des "softhddevice"- Fenster (nach "xhost +" im User-Account) und kurz das OSD. Leider weiterhin kein Bild/ Ton und keine Verbindung zum Server.



    Log- Ausgabe:


    Code
    1. root@dorsy:/etc/vdr/conf.d# vdr --version
    2. vdr (2.2.0/2.2.0) - The Video Disk Recorder
    3. softhddevice (0.6.1rc1) - A software and GPU emulated HD device
    4. streamdev-client (0.6.1-git) - VTP Streaming Client
    5. root@dorsy:/etc/vdr/conf.d#


    MfG


    SNR