Beiträge von m.list

    Hallo,


    Zitat

    Wenn tatsächlich Bedarf besteht, den UDP-Port einstellbar zu machen, könnte ich mir vorstellen, die Option --port so zu erweitern, dass man den UDP-Port [optional] mit angeben kann, etwa


    --port=TCP-port[,UDP-port]


    das wäre sicherlich die flexibelste Lösung


    m.list

    Hallo,


    danke für die schnelle Antwort.


    ich denke die Möglichkeit den Port zu verändern würde mehr Flexibilität erlauben, aber ich kenne den gegenüberstehenden Aufwand den Code zu verändern nicht.


    Also wie muss die Konfiguration aussehen?


    Konfiguration für den Produktiven Teil





    Konfiguration für den Test Teil. Das passt aber nicht weil "If no default host has been defined, the behavior is the same as with any host" und da werden dann die zwei Headless Server sich verbinden oder?



    m.list

    Hallo


    obwohl ich den SVDRP Port auf 65019 geändert habe, bleibt der UDP Port auf 6419. Das ist ungeschickt wenn ich mit zwei VDRs unabhängig von einander testen möchte den mit dem Broadcast "255.255.255.255:6419" verbinden sie sich.

    Code
    yavdr    | 2020-08-02T20:07:44.543766+02:00 yavdr vdr: [213] SVDRP server handler thread started (pid=185, tid=213, prio=low)
    yavdr    | 2020-08-02T20:07:44.544096+02:00 yavdr vdr: [213] SVDRP yavdr opening port 65019/tcp
    yavdr    | 2020-08-02T20:07:44.544656+02:00 yavdr vdr: [213] SVDRP yavdr listening on port 65019/tcp
    yavdr    | 2020-08-02T20:07:44.553835+02:00 yavdr vdr: [214] SVDRP client handler thread started (pid=185, tid=214, prio=low)
    yavdr    | 2020-08-02T20:07:44.553948+02:00 yavdr vdr: [214] SVDRP yavdr opening port 6419/udp
    yavdr    | 2020-08-02T20:07:44.554230+02:00 yavdr vdr: [214] SVDRP yavdr listening on port 6419/udp
    yavdr    | 2020-08-02T20:07:44.554866+02:00 yavdr vdr: [214] SVDRP yavdr > 255.255.255.255:6419 send dgram 'SVDRP:discover name:yavdr port:65019 vdrversion:20401 apiversion:20401 timeout:300'


    Siehe auch SVDRP Peering mit Docker Aufnahme Server


    m.list

    Hallo rfu,


    ich wollte den Vorschlag ausprobieren aber bin auf ein anderes Problem gestoßen - der Test VDR (SVDRP Port 65019) verbindet sich mit den Produktions VDR (SVDR Port 64019) und holt sich die Timers.


    Ich denke ein Grund liegendes Problem ist das man den UDP Port nicht ändern kann "SVDRP yavdr opening port 6419/udp" was dazu führt das ein Broadcast an alle VDRs geht.

    Code
    yavdr    | 2020-08-02T20:07:44.543766+02:00 yavdr vdr: [213] SVDRP server handler thread started (pid=185, tid=213, prio=low)
    yavdr    | 2020-08-02T20:07:44.544096+02:00 yavdr vdr: [213] SVDRP yavdr opening port 65019/tcp
    yavdr    | 2020-08-02T20:07:44.544656+02:00 yavdr vdr: [213] SVDRP yavdr listening on port 65019/tcp
    yavdr    | 2020-08-02T20:07:44.553835+02:00 yavdr vdr: [214] SVDRP client handler thread started (pid=185, tid=214, prio=low)
    yavdr    | 2020-08-02T20:07:44.553948+02:00 yavdr vdr: [214] SVDRP yavdr opening port 6419/udp
    yavdr    | 2020-08-02T20:07:44.554230+02:00 yavdr vdr: [214] SVDRP yavdr listening on port 6419/udp
    yavdr    | 2020-08-02T20:07:44.554866+02:00 yavdr vdr: [214] SVDRP yavdr > 255.255.255.255:6419 send dgram 'SVDRP:discover name:yavdr port:65019 vdrversion:20401 apiversion:20401 timeout:300'



    Ein zweites Problem ist das ein neues (Random) Port, 44204,eröffnet wird das nicht gemappt ist und auch nicht gemappt werden kann weil es nicht bekannt ist


    Code
    yavdr    | 2020-08-02T20:07:44.555444+02:00 yavdr vdr: [213] SVDRP yavdr < 172.19.0.1:44204 client connection accepted
    yavdr    | 2020-08-02T20:07:44.556567+02:00 yavdr vdr: [185] OSD size changed to 720x480 @ 1
    yavdr    | 2020-08-02T20:07:44.557513+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:44204 server created
    yavdr    | 2020-08-02T20:07:44.558369+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:64019 server connection established
    yavdr    | 2020-08-02T20:07:44.558867+02:00 yavdr vdr: [213] SVDRP yavdr > 172.19.0.1:64019 client created for 'keller'


    Bis es ein Lösung für die zwei Probleme gibt wird das nichts.


    m.list

    Hallo rfu,


    so weit ich das verstanden habe sind das NAT Mappings in der Form HOST:CONTAINER und NAT Mappings greifen nur für eingehende Verbindungen. Ausgehende Verbindungen sind ja in der Format IP:Port und die Regeln haben keine Möglichkeit den IP zur berücksichtigen deshalb können die Regel nicht für ausgehende Verbindungen greifen. Also ist das kein Problem und außerdem funktioniert es auch nicht wenn ich Zeile 3 weg lasse.


    Wenn sich der Client, mit Port 64019, mit dem Server vebindet mapped Docker das auf dem Container Port 6419. Einfaches SVDRP funktioniert weil ich zum Beispiel auf dem Menü von VDR im Container zugriff habe.


    Was nicht funktioniert ist das SVDRP Peering beziehungsweise SVDRP Peering der Timer


    Code
    Peering
    
    If there is more than one VDR in the local network, they can now form a peer-to-peer network, so that timers can be moved freely between them. The following changes have been made to implement this:
    
    VDR now sends out a broadcast to port 6419/udp, which was assigned to 'svdrp-disc' by the IANA. VDRs listening on that port will automatically initiate an SVDRP connection to the broadcasting VDR, and in turn send out a broadcast to make other VDRs connect to them. That way all VDRs within the local network will have permanent "peer-to-peer" SVDRP connections between each other. The configuration in the svdrphosts.conf file is taken into account when considering whether or not to respond to an SVDRP discover broadcast.
    
    The new SVDRP command PING is used by automatically established peer-to-peer connections to keep them alive.
    [snip]


    m.list

    Hallo rfu,


    danke für die Antwort.


    ich habe zwei VDRs am laufen, einen Produktiven und einen für test Zwecke, deshalb muss der test VDR auf andere Ports ausweichen. In diesem Fall habe ich 64019 gewählt.


    Warum ist deiner Meinung nach das Mapping widersprüchlich? Es werden jeweils der 64019 TCP und der 64019 UDP Port von Server auf den 6419 TCP und 6419 UDP Port von Container gemappt.


    Das Problem ist nicht mit remoteosd, das funktioniert einwandfrei.


    Das Problem ist mit der neuen SVDRP Peering Funktionalität. Ich vermute das es entweder daran liegt das ich den UDP Port nicht ändern kann oder es werden irgendwelche Random (UDP?) Ports noch zusätzlich aufgemachen.


    m.list

    Hallo,


    ich versuche gerade mein Glück beim einrichten von SVDRP Peering mit einen Aufnahme Server der in einem Docker Container lauft.


    Wenn der Container in Host Netzwerk Modus (Docker Container Netzwerk = Host Netzwerk) lauft dann funktioniert alles bestens aber wenn ich den Aufnahme Server im Docker Netzwerk laufen lass dann bekomme ich immer den Fehler:


    Code
    ERROR: Error while accessing remote timer 0@keller!


    Was ich auch bei meinem vielen Fehlversuche festgestellt habe ist das ich den SVDRP TCP Port umstellen kann aber nicht den UDP Port

    Code
    SVDRP server handler thread started (pid=17823, tid=17843, prio=low)
    SVDRP mld opening port 64019/tcp
    SVDRP mld listening on port 64019/tcp
    SVDRP client handler thread started (pid=17823, tid=17844, prio=low)
    SVDRP mld opening port 6419/udp
    SVDRP mld listening on port 6419/udp
    SVDRP mld > 255.255.255.255:6419 send dgram 'SVDRP:discover name:mld port:64019 vdrversion:20401 apiversion:20401 timeout:300 host:keller'



    Konfiguration Client

    Konfiguration Server

    Konfiguration docker-compose yml


    Ich denke mir fehlt ein Port Mapping aber welches?


    Danke für euer Hilfe wäre ich dankbar

    m.list

    Nachdem der MegaSat SAT-IP Server 3 sich ständig aufhängt (reboot nur am Gerät selber möglich) und der Support bestätigt hat das der Server nicht mit einem DiSEqC Multiswitch funktioniert habe ich ihn zurück geschickt.


    Als nächstes habe ich einen DIGIBIT R1 ausprobiert. Gerät angeschlossen, Sat Positionen eingetragen und schon waren alle Kanäle von meine zwei Satelliten am Client zu sehen. Eigentlich genau so wie ich mir das vorgestellt hatte. Als ich aber versucht habe zwei Streams von Server zu nutzen traten die ersten Fehler im Logfile auf und bei vier Stream hatte ich laufend Ton- und ab und zu Bildaussetzer – also nicht brauchbar.


    Sat>IP ist eine feine Sache und ich war begeistert als es funktionierte (leider nur mit 1-2 Streams aber immer hin hat es funktioniert ) aber ich überbelege mir ob ich wirklich 400-500EUR ausgeben will für ein DD Gerät das als einzige wirklich zu funktionieren scheint oder ob ich einfach abwarte bis die Preise fallen.

    Zitat

    Sorry, aber kann es sein, dass Du weder von der Signalverteilung in Satanlagen, noch von SAT>IP die geringste Ahnung hast?

    Es kann durch aus sein das ich keine Ahnung habe, aber deshalb frage ich ja hier damit ich was lernen kann von denen die Ahnung haben. :]


    Wozu denn das?? Nimm einen Multiswitch und gut is!

    Ich habe schon einen Multiswitch (habe ich oben versucht dazustellen) und verstehen nicht wie ein zweiter helfen soll ?( – aber vielleicht ist das ja weil ich keine Ahnung habe oder vielleicht weil ich mein Problem nicht richtig erklärt hab.


    Also versuch ich noch mal mein Problem dazustellen:


    Zwei Anschlüsse von Multiswitch liegen im Keller beim VDR Server, der Rest schön in Haus verteilt. Eigentlich brauch ich aber 4 Anschlüsse am VDR Server, drei für parallel aufnahmen und eins zum Zappen/Live TV.


    Welche Möglichkeiten habe ich den? Anschlüsse im Haus verlegen geht praktisch nicht. VDR Server zum Multiswitch unters Dach zustellen würde gehen, ist aber nicht praktikabel. Soweit ich weiß bleibt nur die Möglichkeit die Signale anders zu verteil zum Beispiel mit SAT>IP. Aber ich gebe zu ich hab da eventuell keine Ahnung ob es mehr gibt.


    Da ich zwei Antennen/Satelliten bedienen muss brauch ich etwas was DiSEqC fähig ist. Also habe ich mir den DiSEqC fähigen MegaSat SAT>IP Server 3 zugelegt und am Multiswitch angeschlossen. Dabei gab es zwei Probleme, erstens hat der Server sich immer wieder aufgehängt und zweitens konnte ich nur die Sender von ersten Antenne/Satellit sehen. Außer mit VDR habe ich auch mit dem DVBViewer das gleiche Problem, Sender nur von ersten Antenne/Satellit zu sehen.


    Was jetzt? Einen anderen DiSEqC fähigen SAT>IP Server ausprobieren? Oder vielleicht das DiSEqC Problem ganz aus dem Weg gehen und einen SAT>IP Server an jedem Antenne/Satellite mit einem Splitter/Verteiler hängen? Keine Ahnung und deshalb frage ich ja hier damit ich was lernen kann von denen die Ahnung haben.

    Ich dachte ein Diagram wäre besser zum erklären :( . Ist auch kein Unicabel system, ich wollte nicht immer 4 bis 8 Kabel darstellen.


    Klar, kommt das satip-Plugin mit mehreren SAT>IP Servern klar:

    Wie ist es mit dem Devices, ich kann ja die Anzahl angeben bei der Plugin Konfiguration. Wenn nich zwei SAT>IP Server hab (19.2 und 28.2) und 4 Devices konfiguriere, auf welchen Server und wann werden sie allokiert?


    Ja schon, ging mir mehr um die Frage nach Servern (Mehrzahl) ... :)

    Es würden zwei MegaSat Sat>IP Server3 sein, eins für 19.2 und eins für 28.2. Da aber mein test Exemplar jetzt zum zweiten Mal sich total aufgehängt hat (ging nichts mehr ohne Stecker zu ziehen) wird das wohl nichts und ich schike es zurück.



    Ich habe jetzt auch ein hinweiss auf der Verpackung gefunden die nicht in der Anleitung ist

    Zitat

    ... oder über einen Multischalter onhe DiSEqC

    Erfahrungsbericht:

    Code
    Raspberry Pi mit Gb LAN
    4.4.38-v7+ armv7l GNU/Linux
    vdr:
    vdr (2.2.0/2.2.0) - The Video Disk Recorder, satip (2.2.3), rpihddevice (1.0.3) 
    MegaSat Sat>IP Server3:
    H/W Version: 1.0, S/W Version: 3.1.6


    Habe den sat-ip-plugin 3 Devices zugewiesen.


    Ich habe einfach mein bestehendes channles.conf genommen und zuerst ging Garnichts so richtig, aber nach dem VDR die ganzen PIDs angepasst hat konnte ich recht gut Live TV anschauen.



    Folgende Fehler sind öfters im log File zu sehen, aber scheine keine Auswirkung auf die Stabilität zu haben. Kann sein das die ersten zwei durch einen EPG Scan ausgelöst werden

    Code
    SATIP-ERROR: Tuning timeout - retuning [device x]
    SATIP: Detected x RTP packet errors [device x]
    ERROR: TS packet not accepted in Transfer Mode


    Folgendes kommt sehr heufig vor

    Code
    changing pids of channel 90 (Test-R) from 401+401=2:402=deu@3:0:0 to 501+501=2:502=deu@3:0:0
    changing pids of channel 90 (Test-R) from 501+501=2:502=deu@3:0:0 to 401+401=2:402=deu@3:0:0
    changing pids of channel 116 (NDR FS MV) from 2601+2601=2:2602=deu@3,2603=mis@3:0:2604 to 2401+2401=2:2402=deu@3,2403=mis@3:0:2604
    changing pids of channel 116 (NDR FS MV) from 2401+2401=2:2402=deu@3,2403=mis@3:0:2604 to 2601+2601=2:2602=deu@3,2603=mis@3:0:2604


    Aufnahmen funktionieren, aber manchmal wenn ich eine aufnahme anschaue und beende dann bekommen ich folgenden Fehler und kein Bild mehr bis nach einem Restart:

    Code
    rpihddevice: OmxError(InsufficientResources)


    Zappen funktioniert meistens gut, aber manchmal kommt es vor das wenn ich zum Beispiel von Kanal 7 nach 8 zappe dann kommt kein Bild, erst wenn ich weiter nach Kanal 9 zappe und dann zurück nach 8 ist das Bild da oder auch nicht. Fehler gibt’s dabei in log File keine.


    Wann Devices freigegeben werden blicke ich nicht aber ab und zu passierts.


    Noch ein Problem das ich habe ist das das Ganze nicht mit zwei Antennen funktioniert:
    Ausgang - Ohne SAT-IP:

    Code
    G1-----K1
        	|
       	G3------K3------ TVs/VDR
        	|
    G2-----K2


    SAT-IP Server(G4) bekommt Signal nur von der erste Antenne:

    Code
    G1-----K1
        	|            ------ TVs
       	G3------K3--|
           |             ------ G4-----K4----VDR
    G2-----K2


    Vielleicht so?:

    Code
    G1-----K1-----G5-----K1-----G4-----K4----- VDR
               	|
              	G3-----K3----- TVs
               	|
    G2-----K2-----G5-----K1-----G4-----K4----- VDR


    G1,G2: Quatro LNB/Sat Antenne
    G3: Multiswitch (mit DiSECq)
    G4: SAT IP Server
    G5: Splitter/Verteiler
    K1.K2: 4x Koaxial (SAT Ebenen H/H-H/L-V/H-V/L)
    K3: 8x Koaxial
    K4: LAN


    Ideal wäre es wenn G3 und die zwei G4s in einem Geräte wären oder mindestens das mann die zwei G4s kombinieren könnte aber ich hab nichts gefunden, weder multiswitch/SAT-IP kombi noch ein SAT-IP Server für zwei Antennen.
    Eine frage ist ob der sat-ip-plugin mit zwei SAT-IP server klar kommt?

    Hi,
    nach dem ich vdr 2.0.7 installiert habe waren dir meisten "TS packet not accepted in Transfer Mode" Fehler weg. Zusaetzlich habe ich auch noch dem vdr-plugin-suspendoutput installiert und jetzt lauft das System etwas stabiler und die meisten"PANIC: watchdog timer expired - exiting!" sind auch weg


    Jetzt habe ich noch folgende Fehler, wo bei die ersten Zwei scheinbar ueblich sind

    Code
    EpgSync: Error parsing EPG data
    ERROR (device.c,1754): Bad file descriptor
    ERROR: Can't start Transfer Mode!
    rpihddevice: buffer stall!

    Die Fehler tritt dann auf wenn ich viel herum zapp oder wenn VDR lange lauft und ich dann anfange herum zu zappen. Der Fehler mit rpihddevice kommt nich immer dafuer aber mit "ERROR: TS packet not accepted in Transfer Mode".


    Wenn die "ERROR: TS packet not accepted in Transfer Mode" Fehler anfangen und ich den VDR process (nicht denn Server) ueber denn OSD Menu restarte dann kommen die Fehler nach dem Restart weiter. Irgendwann kommt dann der Fehler "rpihddevice: OmxError(InsufficientResources)" und dann geht nix mehr ohne Server Restart.


    Was ich auch nicht so recht verstehe ist:
    1. EPG ist ausgeschaltet (EPGScanTimeout = 0) aber trotzdem steht alle 10 Minuten im log file

    Code
    May 24 07:22:17 vdr-wohn vdr: [3684] epg data writer thread started (pid=3647, tid=3684, prio=low)
    May 24 07:22:22 vdr-wohn vdr: [3684] epg data writer thread ended (pid=3647, tid=3684)


    2. Folgende Fehle sehe ich oefters auch im Logfile aber kann die nicht richtig zuordnen

    Code
    May 24 12:31:38 vdr-wohn vdr: [3790] cStreamDevice::GetTSPacket: GetChecked: NOTHING (0)
    May 24 12:31:38 vdr-wohn vdr: [3791] ERROR (device.c,1754): Bad file descriptor
    May 24 12:32:49 vdr-wohn vdr: [3656] rpihddevice: OmxError(StreamCorrupt)


    Client: rpihpdevice 0.0.10,
    Client und server VDR 2.0.6, rpihpdevice 0.0.10, streamdev-client 0.6.1-git, svdrpservice 1.0.0

    Hi,


    Ich habe mir ein Raspi zusammengebaut aber es lief nicht so wirklich gut - hing und absturtze oefters ab. Ich lade jetzt auch epgsync nicht mehr aber habe immer noch probleme und weis auch nicht so recht wo ich anfangen soll.



    /usr/local/bin/runvdr:

    Code
    VDROPTIONS="-w 60 -u pi -c /var/lib/vdr -s /usr/local/bin/vdrpoweroff.sh"
    
    
    VDRPLUGINS="-P rpihddevice -P streamdev-client -P svdrpservice  -P remotetimers -P remoteosd "



    $ dpkg --status vdr
    [snip]
    Recommends: lirc, ttf-bitstream-vera | ttf-freefont


    Beide Pakete sind installiert, VDRSymbols.ttf find ich nicht als Paket.


    setup.conf


    Ich kann leider auch nicht so recht die fonts auswahl im OSD sehen da sie auf der rechten Seite abgeschnitten sind, ich sehe zB nur "bitstrea"