[VDR4Arch] umstieg von yaVDR

    Moin,


    momentan habe ich mein VDR-Setup wie in der Signatur laufen. Da sowas aber für mich den Charakter einer Modelleisenbahn hat (wenn fertig aufgebaut isses langweilig) spiele ich damit erstmal meinen Server auf Arch umzustellen. Der Server befeuert den Client-VDR über Streamdev, stellt Filme/Serien über NFS zu Verfügung, XBMC's Datenbank liegt in MYSQL und macht noch ein paar dinge über die man hier nichts schreiben darf.
    Anyway, wird ein Projekt für's Wochenende :)
    Auf was für Schwiriegkeiten könnte ich denn stossen? Der Server hat nur nen popeligen VGA-Ausgang, braucht also kein X, was man ja in der runvdr.conf dann auch nicht starten braucht..
    Was später geplant ist: mhddfs abzulösen durch btrfs, wieder ein Wochenende weg ;)



    Zum Client:
    Wie ist es dort gelösst mit dem 'umschalten' von yaVDR zu xbmc? Ich werde mit PVR über xbmc irgendwie nicht warm.



    Arch ist für mich nicht völlig fremd, ich hatte auf Arbeit damit mal nen Samba-Server laufen, das ist aber SEHR lange her ;)


    Schönen dank für die Arbeit an VDR4Arch :)

    Zitat von TesaFilm

    Auf was für Schwiriegkeiten könnte ich denn stossen? Der Server hat nur nen popeligen VGA-Ausgang, braucht also kein X, was man ja in der runvdr.conf dann auch nicht starten braucht.

    Auf keine, jedenfalls auf keine die sich nicht lösen lassen. Bei mir läuft seit ein paar Tagen ein N54L unter Archlinux.

    MSI H55M-E33 |Intel Core i3 530| 4 GB RAM | TT DVB-S2 6400 | Ubuntu 12.04 | Kernel-3.5.0-28 | VDR-2.2.0 | v4l-dvb| eigene Distri.
    ProLaint: Ubuntu Server 12.04.5 auf HP ProLiant ML330 G6, Xeon E5506 2.13-GHz, 16GB ECC DDR3, Digital Devices MaxS8, Samsung 840 EVO 120GB, 4x WD Red WD30EFRX 3TB in HP P410 Raid6, Zotac GT730 1GB

    Zitat von TesaFilm

    Auf was für Schwiriegkeiten könnte ich denn stossen?


    Vorausgesetzt, dass das Teil 64bit fähig ist, sollten die Binärpakete funktionieren. Ist das System allerdings nur 32bit musst du selber kompilieren und damit Arch Linux überhaupt läuft muss das System mindestens i686 fähig sein.
    Probleme sehe ich eher beim Client. Ich weiß nicht, wie Streamdev auf ein nicht vorhandenes Netzwerk reagiert. Das ist in Standardeinstellung nämlich beim VDR-Start noch nicht initialisiert. Im Wiki habe ich aber einen Lösung dafür geschrieben, die angeblich funktionieren soll. (von mir nicht gestestet)

    Zitat von TesaFilm

    Wie ist es dort gelösst mit dem 'umschalten' von yaVDR zu xbmc?


    Das kann ich dir nicht sagen. Ich habe allerdings schonmal externalplayer versucht. bin aber dann an irgendeinen Watchdog gescheitert und habe schließlich das Interesse verloren. Mit Externalplayer sollte das aber eigentlich problemlos machbar sein. Mich würde dann brennend interessieren, wie du es zum Laufen gebracht hast.


    Du wärst der erste VDR4Arch User mit einem Client-/Server System. Mir ist zumindest kein anderes System bekannt.
    Es ist für mich sowieso schwer abzuschätzen, wie viele Nutzer VDR4Arch überhaupt hat. Das können 5 Leute sein, dass können aber auch 50 Leute oder mehr sein.


    Aber wie wino schon schreibt. Alle Probleme lassen sich lösen und soweit es mir möglich ist werde ich auch beim Lösen helfen.


    Edit: yaVDR 0.5.0 läuft ja auf dem Server, also ist es sicherlich ein 64bit System.

    Ja, der Server ist 64Bit, das ist weniger das problem. Ich sehe da auch keine grossen probleme, mal davon abgesehen die verstreuten Daten zu sichern und 'wie hab ich das $DAMALS noch gemacht??' 's beste wird wohl sein das installierte System einmal mit FSArchiver zu sichern und als cheat-sheet das gerümpel mit rsync auf eine der Platten zu sichern :)
    Dann weiss ich ja, was ich Freitag/Sonnabend zu tun habe.
    Der Client sollte sich ja davon unbeeindruckt zeigen..


    Wegen dem Client: wenn ich da was finde wie man es machen könnte oder wie es geht, geb ich laut :) Ebenso wie das mit'm Nyxboard klappt, AFAIK meldet die sich als Tastatur..


    Arch ist schon nen ziemlicher umstieg, selbst wenn man CentOS/Debian/FreeBSD recht gut kennt, aber genial :)

    Zitat von Copperhead

    Du wärst der erste VDR4Arch User mit einem Client-/Server System. Mir ist zumindest kein anderes System bekannt.
    Es ist für mich sowieso schwer abzuschätzen, wie viele Nutzer VDR4Arch überhaupt hat. Das können 5 Leute sein, dass können aber auch 50 Leute oder mehr sein.


    Edit: yaVDR 0.5.0 läuft ja auf dem Server, also ist es sicherlich ein 64bit System.


    Ich habe einen test Server mit VDR4ARCH laufen. Die Clients sind aber Openelec.
    Da ich nur aufgenommenes oder .mkv Files schaue, komme ich und die Familie damit super zurecht


    vdr-box

    So liebe Leute, heute war es soweit, Server platt machen und VDR4Arch drauf. Freitag und gestern hab ich, weil ich 'unbedingt' noch ne neue Platte brauchte Daten umgezogen. Weil ich gute Erfahrung damit gemacht habe kam BTRFS zum einsatz, mit 2 Devices als single (ich weiss selber das das kein RAID ist und evtl. Datenverlust droht) um mhddfs abzulösen. Das aber nur vorweg.


    Heute morgen dann noch Daten für den direkt zugriff kopiert, von USB gebootet, grundinstallaton gemacht, neu gestartet und der Server bringt kein Grub-Menü, startet aber fröhlich neu..
    Also wieder von USB, mit parted und im chroot alles nochmal kontrolliert.. alles i.O.. nach mehreren versuchen dann die Lösung: MBR-Partitionstabelle.. Irgendwie kommt das BIOS wohl mit GPT nicht klar, was ich aus alter Gewohnheit genommen hab..
    Danach das VDR-Geraffel installiert, ein teil meiner alten Konfig übernommen und reboot..


    VDR beschwert sich im log das es keine Channels findet, was OK ist, rechner hängt nich an den Kabeln. Fix feste IP vergeben (schön das die seiten auf netcfg basieren, was aber nicht funktioniert), ssh installiert, kontrolliert, rüber geschleppt, verkabelt (Protipp: Ein Server Served besser, wenn man das Netwerkkabel auch anschliesst ;) ), angerissen und dann der grosse moment: Client angeworfen und sofort Bild! :tup


    Ich meine das das Zappen schneller ist, meine regelmässigen kurzen Tonaussetzer sind weg, ich bin zufrieden :)
    Fehlen nur noch die restlichen Klamotten (NFS, MySQL... und Anpassungen


    Für mich hat sich der Umstieg gelohnt, der im grossen und ganzen Stressfrei war..

    Code
    Nov 24 17:55:48 nas-mopped vdr[1079]: [1103] Streamdev: Accepted new client (VTP) 192.168.178.2:56203
Nov 24 17:55:48 nas-mopped vdr[1079]: [1103] Streamdev: Setting data connection to 192.168.178.2:42319
Nov 24 17:55:48 nas-mopped vdr[1079]: [1375] streamdev-writer thread started (pid=1079, tid=1375, prio=high)
Nov 24 17:55:48 nas-mopped vdr[1079]: [1376] streamdev-livestreaming thread started (pid=1079, tid=1376, prio=high)
Nov 24 17:55:48 nas-mopped vdr[1079]: [1377] receiver on device 1 thread started (pid=1079, tid=1377, prio=high)
Nov 24 17:55:48 nas-mopped vdr[1079]: [1378] TS buffer on device 1 thread started (pid=1079, tid=1378, prio=high)
Nov 24 17:55:49 nas-mopped vdr[1079]: [1079] connect from 192.168.178.2, port 42048 - accepted
Nov 24 17:55:58 nas-mopped vdr[1079]: [1079] closing SVDRP connection

    Ich nochmal..


    Zitat


    Probleme sehe ich eher beim Client. Ich weiß nicht, wie Streamdev auf ein nicht vorhandenes Netzwerk reagiert. Das ist in Standardeinstellung nämlich beim VDR-Start noch nicht initialisiert. Im Wiki habe ich aber einen Lösung dafür geschrieben, die angeblich funktionieren soll. (von mir nicht gestestet)


    Spricht etwas dagegen das nicht direkt mit ein zu bauen? Streamdev-server spielt nach nem reboot nämlich wirklich toter Mann. OK, momentan boote ich den Server öfter aber eigentlich rennt der 24/7.


    ein anderes 'problem' bin ich leider nicht los geworden, ich vermute da aber eher, das die Karte das problem ist:



    Das hatte ich unter YaVDR nachvollziehbar wenn viel last auf dem System war und vdr gleichzeitg streamte. Mal Digital Device anschreiben, ob die das eher eingrenzen können, Treiber schliess ich momentan aus :)
    Kann aber auch sein, das der N40L nach zwei Jahren Dauerbeteib die weisse Flagge hisst ;)


    Ansonsten läuft der Server 1a :)

    Zitat von TesaFilm

    Spricht etwas dagegen das nicht direkt mit ein zu bauen?


    Ja. Das mein VDR dann nicht mehr in gefühlten 10 Sekunden gestartet ist. Die IP bei der Fritzbox abfragen dauert ewig.


    Wie stark sich das auswirkt, muss ich aber erst nochmal genauer anschauen.


    Edit: Ich habe jetzt mal geschaut.
    Der VDR wird bei mir 5 Sekunden nachdem der Kernel geladen und gestartet wurde gestartet.
    Also 1 Sekunde braucht der Kernel zum Starten und 2.5 Sekunden das initrd.


    Mit dieser Änderung würde es weitere 9 Sekunden dauern.


    Für Vorschläge bin ich natürlich immer offen.

    Ganz einfach: Das ist ein Bug in streamdev!


    Man kann niemals wirklich davon ausgehen, dass Netzwerk "da ist" und extra drauf warten ist Murks. Streamdev sollte selber, wenn nötig, mehrfach probieren, bis der Server sich meldet.


    Ist "warte auf Netzwerk" überhaupt technisch möglich? Ich meine: Was ist, wenn ich auf dem VDR mit "Network Manager" mein Netzwerk konfiguriere? Der ist doch sogar fähig im laufenden Betrieb das Stecken eines Netzwerksteckers zu erkennen um dann kurz darauf via DHCP automatisch eine IP auf die LAN-Karte zu geben.


    Wenn man den Bug in streamdev schon umgehen will, dann bitte nur als "dropin" für das Service-File, denn zumindest ich will keine 9 Sekunden unnötigerweise warten. An meinem VDR brauche ich das Netzwerk aktuell nur zu Wartungszwecken um per SSH drauf verbinden zu können.

    Zitat von Mreimer

    Ist "warte auf Netzwerk" überhaupt technisch möglich?

    Wenn du ein Kriterium dafür findest, dass das Netzwerk konfiguriert wurde - systemd bietet ein entsprechendes Target dafür an auf das andere Dienste warten können: http://www.freedesktop.org/wik…re/systemd/NetworkTarget/
    Unter Arch Linux sollte man den Service /usr/lib/systemd/system/dhcpcd@.service für einen Adapter konfigurieren können (ggf. muss man das noch anpassen um explizit auf eine IPv4- bzw. IPv6-Adresse zu warten:

    dhcpcd forkt mit dem Argument "-w" erst, wenn es den Adapter konfiguriert hat:

    Zitat von man dhcpcd
    Code
    -w, --waitip [4 | 6]
             Wait for an address to be assigned before forking to the back‐
             ground.  4 means wait for an IPv4 address to be assigned.  6
             means wait for an IPv6 address to be assigned.  If no argument is
             given, dhcpcd will wait for any address protocol to be assigned.
             It is possible to wait for more than one address protocol and
             dhcpcd will only fork to the background when all waiting condi‐
             tions are satisfied.


    Für den Network-Manager gibt es offenbar auch etwas : https://wiki.archlinux.org/ind…etworkManager_Wait_Online


    Für den VDR könnte man dann so ein dropin für das Service-File basteln: /etc/systemd/system/vdr.service.d/network.conf:

    Code
    [Unit]
Wants=network.target
After=network.target


    Das ganze scheint zumindest hier funktioniert zu haben (auch wenn eine klare Rückmeldung immer etwas feines wäre): [gelöst][VDR4Arch] Problem beim Booten - Bleibt als mal hängen !

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Na das wäre doch zumindest ein ganz passabler Workaround. Und vielleicht wird streamdev ja irgendwann auch mal gefixt. Da ich es selber nicht verwende, überlasse ich das Melden des Bugs jemandem, den es auch betrifft.


    Letztenendes kann nur streamdev wirklich feststellen, ob das Netzwerk einen Zustand erreicht hat, der für einen Empfang nötig ist. Hätte zudem den Vorteil, dass man ohne Bastel-Murks einen Server auch über "Wake On LAN" anstarten könnte. Der Client würde dann genau solange warten bis der Server gebootet ist.

    Moin,


    Ich teste es gerade auf dem Server, ob es nicht einfach nur mein Problem war. Ich hatte unter YaVDR dem streamdev-server die IP mitgegeben auf die er hören sollte, wegen IPv6. Da ich jetzt IPv6 ausgeknipst hab, kann ich netürlich auch wieder die 0.0.0.0 eintragen, was funktionieren sollte.
    Die frage ob er dann auch auf der richtigen IP horcht und Verbindungen annimt kann ich aber erst heute abend prüfen.


    Da ich aber auch kein DHCP verwende, sondern primär feste IPs, ist meine Netz innerhalb 2 sekunden oben als per dhcp von der Fritz.


    'schulligung für die Verwirrung ;)


    Edit:
    Sieht bisher gut aus, streamdev (VTP) mosert zumindest nicht rum wenn das Netz noch nicht oben is, so wie es sein sollte:

    Code
    Nov 26 10:36:44 nas-mopped vdr[304]: [353] streamdev server thread started (pid=304, tid=353, prio=high)
Nov 26 10:36:44 nas-mopped vdr[304]: [353] Streamdev: Listening (VTP) on port 2004
Nov 26 10:36:44 nas-mopped vdr[304]: [304] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearch.conf
Nov 26 10:36:44 nas-mopped vdr[304]: [304] EPGSearch: loading /var/lib/vdr/plugins/epgsearch/epgsearchdone.data
Nov 26 10:36:44 nas-mopped vdr[304]: [353] Streamdev: Couldn't listen (HTTP) 192.168.178.12:3000: Die angeforderte Adresse kann nicht zugewiesen werden
Nov 26 10:36:44 nas-mopped vdr[304]: [304] loading /var/lib/vdr/plugins/epgsearch/epgsearchswitchtimers.conf

    Einmal editiert, zuletzt von TesaFilm ()

    Warum gibst du auf dem Server überhaupt eine IP an streamdev? Wenn man hier wirklich eine IP angeben muss, dann nimm "0.0.0.0". Auf die kann er dann sofort ein "Listen" machen und da "0.0.0.0" nichts anderes bedeutet wie "alle IPs" ist der Port dann auf später dazukommenden Netzwerkverbindungen sofort offen.

    Zitat von Mreimer

    Warum gibst du auf dem Server überhaupt eine IP an streamdev? Wenn man hier wirklich eine IP angeben muss, dann nimm "0.0.0.0". Auf die kann er dann sofort ein "Listen" machen und da "0.0.0.0" nichts anderes bedeutet wie "alle IPs" ist der Port dann auf später dazukommenden Netzwerkverbindungen sofort offen.


    Hatte ich oben schon geschrieben, wegen meinem IPv6-Netz. Ich wollte nicht, das er sich daran bindet und daher die IP eingetragen. Da ich die setup.conf zum grossen Teil übernommen hatte, bin ich da erst heute drauf gekommen, hab ja auch nicht je änderung aus den letzten Jahren im Kopf :)

    Wo ist das Problem wenn er sich daran bindet? Wenn das aus welchem Grund auch immer nicht gewünscht ist, dann ist hier iptables (Paketfilter/Firewall) vermutlich die bessere Lösung...


    Fakt ist in der Tat: Streamdev-Server wird nicht auf nichtexistente IPs binden können. Dein Problem ist also hausgemacht!

    Natürlich bleibt alles beim alten. Wenn jemand auf's Netzwerk warten will, dann geht das über ein Dropin und ist damit ein individuelles Konfigurationsthema.


    Im hier vorliegenden Fall halte ich es aber für sinniger direkt auf 0.0.0.0 zu binden und ggf. mit Iptables den Zugang von IPv6 zu sperren.


    Wobei nach wie vor nicht geklärt ist, warum der Port auf IPv6 nicht offen sein darf. Wenn der schlimmstmögliche Fall vorliegt (IPv6-Adressen ungefiltert von außen erreichbar), dann sollte dieses Problem bereits auf Router-Seite erschlagen werden!

    Zitat von Copperhead

    Gut, dass ich von Netzwerk keine Ahnung habe.


    Was heißt das jetzt für mich? Alles bleibt beim Alten, oder muss ich irgendwo etwas ändern?


    Von meiner Seite aus nicht, alles gut.


    Zitat von Mreimer

    Natürlich bleibt alles beim alten. Wenn jemand auf's Netzwerk warten will, dann geht das über ein Dropin und ist damit ein individuelles Konfigurationsthema.


    Im hier vorliegenden Fall halte ich es aber für sinniger direkt auf 0.0.0.0 zu binden und ggf. mit Iptables den Zugang von IPv6 zu sperren.


    Wobei nach wie vor nicht geklärt ist, warum der Port auf IPv6 nicht offen sein darf. Wenn der schlimmstmögliche Fall vorliegt (IPv6-Adressen ungefiltert von außen erreichbar), dann sollte dieses Problem bereits auf Router-Seite erschlagen werden!


    Komm mal wieder runter. Ich hab den Fehler selber eingesehen und behoben und auch nicht verlangt das Netzwerk-Verhalten, bzw. die Startreihenfolge zu ändern.


    Thema für mich erledigt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden