Posts by not_so_important

    Ich denke ich habe es gefunden!
    Bisher hatte ich in dem virtuellen Image eth0 / eth1 und eth2 ... wobei eth2 noch ein Relikt aus verschiedenen Tests war und in einem anderen Subnet lag, welches lediglich den interconnect zwischen verschiedenen VMs macht.
    Nachdem ich nun stur eine AVG II mit internem Netceiver am Server "emuliere" ... also nur eth0 (IPv6 zum externen Netceiver) und eth1 (IPv4) --- kein VLAN, keine Bridge und per OSD das Netzwerk nochmal komplett durchkonfiguriert habe (feste IP, nameserver, gateway etc. etc.) ist das Problem scheinbar behoben.

    Das Multiroom hat nun bereits einige Neustarts von AVG und NetClient überlebt ... keine Fehlermeldungen mehr im vdr-avahi.log

    Und das beste ... nun klappt es auch mit RPi und Fire TV sehr vernünftig ...

    Danke für die Bemühungen ... das weiß ich zu schätzen!

    Gruß,
    Rainer

    O.K. ... hab's gefunden ... ich brauche net.ifnames=1 in der /etc/default/grub ... danach wurde die /etc/udev/rules.d/10-my-net-names.rules ausgeführt und die Adapter umbenannt.

    Allerdings macht auch die neue Version immer noch die Probleme als Multiroom Server (AVAHI) wie bereits hier beschrieben:

    {stable} BM2LTS - Based on Ubuntu 14.04.x


    Wird sich da noch etwas ändern? So kann ich leider alle aktuellen Versionen auf dem Server nicht einsetzen und somit auch meine RPIs und FireTVs nicht vernünftig anbinden. Das VNSI unter 1.94 ist ja nun gar nicht mehr aktuell ... leider ...

    Gruß und Danke,
    Rainer

    Ich habe nun noch ergänzend versucht die Module für virtio und r8169 in anderer Reihenfolge zu laden.
    Dies geht jedoch auch nicht, da virtio ein "builtin"Modul ist und sich nicht mit modprobe entladen lässt ... :wand


    Unfassbar ... mann muss doch irgendwie eth0 mit eth1 austauschen können ... ist doch "eigentlich" nur ein Ubuntu ... nur das UDEV nicht den Regeln zu folgen scheint.


    Gruß,
    Rainer

    Ich habe mit "Server als/auf Reelbox Basis" installiert ...
    Der Fehler liegt aber daran, dass das Ubuntu scheinbar beim hochfahren nun die Realtec Netzkarte erst nach der Virtio-Karte initialisiert. Beim 1.94 konnte ich hier einfach durch Zuweisung der MAC-Adressen in der 70-persistent-net.rules das korrekte Mapping herstellen ...udev ist hier ja (noch) der aktuelle Standard bei Ubuntu nach meinem Wissen. Wenn ich diese Datei nun erstelle, wird sie beim nächsten Boot jedoch wieder gelöscht und kommt nie zur Anwendung. Eine 71-persistent-net.rules wird scheinbar nie angewendet. Das Syslog schreibt nichts erkenntnisbringendes dazu ...

    (Von meiner funktionierenden VM mit 1.94):
    root@BM2LTSR66RBex:~# more /etc/udev/rules.d/70-persistent-net.rules
    # This file was automatically generated by the /lib/udev/write_net_rules
    # program, run by the persistent-net-generator.rules rules file.
    #
    # You can modify it, as long as you keep each rule on a single
    # line, and change only the value of the NAME= key.

    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="50:e5:49:5b:ea:f7", KERNEL=="eth*", NAME="eth0"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="8e:43:70:83:13:f2", KERNEL=="eth*", NAME="eth1"

    cinfo: Hast du etwas am udev des Ubuntu verändert?

    Gruß,
    Rainer

    Hallo,

    ich habe nun mal die aktuelle 2.88 RC9 auf meinem Proxmox Server installiert um die AVAHI Problematik mit Multiroom zu prüfen (das MYSQL-Problem aus 2.87 scheint behoben).
    Im Server habe ich eine Realtec Karte direkt an die vm durchgereicht (diese macht IPv6 zum Netceiver) und eine zweite Karte hängt an einer vmbr bridge im normalen IPv4.
    So läuft auch alles unter 1.94 seit Monaten perfekt ...

    Nun habe ich heute festgestellt, dass im neuen BM2LTS plötzlich eth0 und eth1 vertauscht sind ... somit kommt der IPv6 Multicast ebenso falsch wie das IPv4 an. Nix läuft ...

    Ich habe, auch nach langem Suchen, keinen Weg gefunden diese Interfaces zu tauschen.

    70-persistent-net.rules in /etc/udev/rules.d geht nicht (wird sogar bei jedem neustart gelöscht ??!). Auch die entsprechenden GRUB-Parameter hatte ich dazu gesetzt.

    Auch ein Script, eingefügt in /etc/network/if-pre-up.d das mit ifrename die interfaces umbenennen soll funktioniert nicht.

    root@BM2LTSR66RBex:/etc/network/if-pre-up.d# more nameif#!/bin/sh
    PATH=/sbin
    /sbin/nameif -s eth0 50:e5:49:5b:ea:f7

    /sbin/nameif -s eth1 b2:a4:8c:e0:1c:52


    Ebenfalls eine direkte Anpassung im Grub als Kernelparameter unter /etc/default/grub mit nachforgendem update-grub brachte nichts:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash netdev=irq=52,name=eth0"

    Ich bin da etwas ratlos ... alle mir bekannten Methoden zum umbenennen der Adapter greifen scheinbar in BM2LTS nicht ...

    Wie kann ich das hin bekommen?

    Gruß,
    Rainer

    Hallo,

    ich habe nun die aktuelle 2.87 RC9 auf meinem Proxmox Virtualisierer installiert.
    Alles sieht gut aus, bis auf Multiroom.
    Beim Einrichten des Multiroom Servers wird stets "Fehler: Verbindung zu Datenbank fehlgeschlagen" ausgegeben.
    Ich habe den mysql patch aus dem Post vom September auch bereits eingespielt ... ohne Veränderung.

    Das error.log aus /var/log/mysql ist (maskiert als .txt aber als originale linux datei) beigefügt ... sagt mir jedoch leider nicht viel ... wird hier mysqld ggf. doppelt gestartet ... wenn ja, dann von wo aus?

    Any help?

    Gruß,
    Rainer

    Quote

    Danke für Dein Vorschlag Rainer, habe über Putty den Port 2002 zu öffnen auf der Sever
    IP. TELNET Verbindung Wählen /PORT 2002
    eintragen / IP des Servers und kann jetzt mit der Fernbedienung vom Browser jetzt
    im Konsolen Fenster OSD MENU sehen. DANKE!


    Bin nicht sicher ob es schon gelöst ist ...
    Anyhow ... Die FB vom RBC geht auch ... und die hat sicher eine Setup Taste ...
    http://ip-der-box:8002/cgi-bin/reelhttp.sh?rbc


    Gruß,
    Rainer

    Hi,

    über ein WEB-Browser mit http://Deine_VDR_IP:8002/cgi-bin/reelhttp.sh?rbc

    Dann Tools --> OSD --> Konsole

    Man muß aber Java haben!

    Grüße
    cinfo

    Leider gibt es da Probleme mit neuerem JAVA ... das gute alte/neue Rechtesystem von JAVA...


    Alternativ ein Terminalfenster (z.B. mit putty) auf Port 2002 gegen die IP des headless öffnen und die Fernbediienung aus dem VDRADMIN im Browser zur Bedienung nutzen.
    Im Terminal erscheint dann das OSD ... mache ich schon seit Jahren so auf meiner virtuellen AVG die unter Proxmox im Keller headless läuft.

    Gruß,
    Rainer

    Hallo,

    habe gerade die aktuelle RC8 auf meine AVG II gespielt.
    Alles bestens ... nur die Kanalliste ist etwas störrisch.
    Wie immer habe ich zunächst p.bouquets aktiviert (true) und dann meine Kanalliste vom Server importiert.
    Somit kann ich auch wieder meine Bedienung über die Bouquets nutzen ... funktioniert alles bestens.

    Wenn ich nun jedoch die Box neu starte, dann habe ich eine völlig andere Kanalliste ... auch meine Bouquets sind weg.
    Lade ich die Liste vom Server (Import über Empfangseinstellungen --> Kanallisten --> Funktionen --> Kanalliste Importieren) ist wieder alles bestens, bis zum nächsten reboot. Dann habe ich wieder die falsche Liste.

    Die Channels.conf unter /etc/vdr ist meine korrekte. Die unter /etc/vdr/channels/channels.con scheint die zu sein, welche nach dem Neustart jedesmal wieder geladen wird ... zumindest sieht es für mich so aus ...

    Any clues?

    Gruß,
    Rainer

    Hallo,

    -- über den Rest muß ich so etwas nachdenken

    Da meine Server noch ein paar Kapazitäten frei haben, habe ich es aktuell dadurch gelöst, dass ich zwei VMs parallel betreibe. Eine Virtual Machine mit 1.94 als MCLI ... diese läuft als Multiroom Server für die AVG II und die NetClients. Eine weitere VM mit 2.74 läuft als Multiroom Client zu der ersten virtuellen 1.94er, ebenfalls als MCLI für das Streaming, und bedient so die VNSI Clients ...

    Ist zwar ein ziemlicher Overkill ... aber so geht erstmal die Kombo aus zentralem Aufnahmeserver mit Suchtimern etc.per Multiroom an die AVG und die NetClients (virtuelle 1.94er) und das Bedienen der VNSI-Clients über die 2.74er VM, die Timer etc. wiederum als Multiroom Client von der "alten" VM bekommt und per VNSI weitergibt.

    Auf Dauer würde ich die zwei VMs natürlich gerne wieder zusammenfahren ...

    Gruß und Danke,
    Rainer

    Hallo nochmal ...

    Alles gut, mit Bezug auf VNSI / XVDR Clients. Mir fehlt nur ein wichtiges Detail:

    Wie bekomme ich zentrale Timer auf dem Server verwaltet wenn ich (oder meine Regierung) vor einer der physikalischen AVGs sitzen? Dies ist heute unser Hauptgerät im Wohnzimmer.

    --> Timer auf den Reel Client´s werden direkt abgearbeitet

    Die verteilten AVG/NetClients nehmen nie direkt auf, da diese ohne aktiven Betrieb stromlos sind. Das kann ich auch nicht ändern, da ich nur so die ganzen Instabilitäten mit dem deep standby zu 100% verhindern kann.

    Alle meine Reelboxen hängen direkt am NAS ... Aufnahmen anzusehen ist kein Problem ... mir geht es um die hervorragende zentrale Timerverwaltung inkl. Suchtimern. Gibt es mit VNSI denn auch Suchtimer? Die Option habe ich bisher noch nicht gesehen ... schaue ich mir nochmal an.

    Streamdev ... klappt mit 2.74 als Client mit "Reelbox (BM2LTS) to Reelbox (BM2LTS) nicht (siehe oben).
    Multiroom geht auf dem Server mit 2.74 nicht ... und ist dann auch bald ganz demontiert.
    Eine AVG hat keinen VNSI-Client ... würde auch keinen Sinn machen.

    Ich finde die ganze Entwicklung zu BM2LTS wirklich hervorragend und möchte mich an dieser Stelle auch in keinster Weise beschweren ... Allerdings waren und sind die zentralen Timer und Suchtimer für mich einer der wichtigen Vorteile von Reel ...

    Aus meiner Sicht bleibt mir nur zu versuchen die 2.74 "irgendwie" mit Multiroom stabil auf dem Server ans Laufen zu bekommen (um einen aktuelleren vnsiserver für die Kodi's zu erhalten) und dann ggf. noch einige Zeit auf diesem Stand zu betreiben ... und dann mal schauen wie es mit SAT>IP (Octopus o.Ä.) mit MythTV oder Tvheadend ausschaut ... da gibt es nach meiner Recherche ebenfalls intelligente Suchen auf Basis von EPG für Timer.

    Gruß,
    Rainer

    Hallo,

    mit Bezug auf diesen Beitrag, aus dem 1.94er Forum habe ich gerade versucht auf meiner AVG II mit 2.74 RC7 im Multiroom auf "Client" und "Streamdev" umzustellen.

    {Version 1.94.3A} BM2LTS-Image mit eHD-Karte, DVB-Karten, NetCeiver, Reelbox etc...

    Abfolge:
    1) Multiroom inaktiv geschaltet
    2) Reboot
    3) In den Systemeinstellungen den Streamdev Client aktiviert und an eth1 gebunden
    (Ich
    bekomme dann auch ein Bild von meiner zentralen BM2LTS Installation via
    streamdev, allerdings kommt bei jedem Umschalten das Fenster "Es konnte
    kein freier Tuner gefunden werden" eingeblendet. Dies muss man dann mit
    O.K. bestätigen (bei jedem Umschalten!) Im Hintergrund läuft das
    Fernsehbild o.k.)
    4) Reboot
    5) Multiroom aktiv geschaltet (Client, dann BLAU (Experten) --> Streamdev) --> Speichern (dauert dann recht lange)
    6) Menu nochmals aufgerufen --> Einstellung steht dann wieder auf Client / MCLI.
    7) Reboot
    8) Nochmals checken ... Einstellung immer noch falsch

    Leider merkt sich der BM2LTS also diese Einstellung nicht und schaltet immer wieder auf "Client" und "MCLI" um.

    Weiterhin finde ich bei der Einstellung nach 3) (Multiroom inaktiv) unter Menu --> TV --> Timer leider keine Timer (also in jedem Fall nicht die vom Server, dort sind über 50 Timer programmiert).

    Multiroom als Streamdev kann ich nicht einschalten --> Einstellung ist nach dem Speichern zurückgesetzt auf MCLI (siehe oben)
    Ohne die Einstellung Multiroom sehe ich keine Timer vom Server, die ich jedoch benötige.

    Any Ideas?

    Danke,
    Rainer

    Hallo,

    Man kann z.B: eine AVG/NUC/VM Gerät als Server anlegen und diesen eine interne Platte oder NAS zuweisen (für Client wie Fire TV oder RPI) und wenn man ein Reel-Client nutzt richtet man die Auszeichnungs-Ablage ein (z.B. AVG intern oder NAS) und gibt dem Client einen Tuner über den MCLI (alles ohne Multiroom). Damit hat man Streaming Clients (Fire TV /RPI) und "echte" Clients mit Tuner (Reel-Client) in seinen VDR-Netz eingebunden.


    Deshalb verstehe ich diesen Gedankenansatzt leider nicht so richtig

    Ich nutze die Reelboxen ebenfalls bereits seit langen Jahren. Alle meine Clients haben eigene NFS Shares vom zentralen Fileserver ... da ist die virtuelle AVG völlig aussen vor.

    Mein Verständnis war bisher, dass man eine zentrale Timerverwaltung (um genau diese geht es hier) nur mit Multiroom bei NetClients oder AVG als Clients erhält. Meine NetClients und die Avantgarde sind typisch "stromlos", es sei denn jemand schaut aktiv. Alle Timer müssen also auf dem Server, der eh 24x7 läuft liegen und auch abgewickelt werden.

    Im Multiroom sind RB-Clients typisch ebenfalls per MCLI mit einem Tuner verbunden ... auf der Serverbox (egal ob virtuell oder "on tin") werden ja nur Tuner für Aufnahmen ungenutzt gelassen wenn man z.B. sagt, dass es 2 Clients geben soll. Also die echte Tunerverwaltung in der Reelbox gilt hauptsächlich bei Anbindung per VNSI/XVDR oder Streamdev ... da verwaltet der Server die Tuner und es findet folgende Streamverarbeitung mit z.B. Kodi oder einer AVG als StreamingClient statt:

    Tuner --> Multicast IPv6 --> Multiroom Server --> Unicast IPv4 --> Client (Kodi, Fire TV etc.).

    Bei Multiroom mit MCLI läuft IPv6 direkt bis zum Client und Multiroom macht defacto nur die Timerverwaltung für Aufnahmen ... das allerdings sehr elegant mit Suchtimern etc.

    Ich müsste also meine RB-Clients auf Streamdev umstellen, was bei den NetClients unglücklich ist, da diese als Streamdev Clients nicht zuverlässig funktionieren (ständige Meldung "Auf einen freien Tuner wird gewartet" trotz funktionierendem Streaming) ... Die Netclients sind da etwas ... naja ... pingelig. Aber eventuell kann ich die ja mit einem stabilen VNSI dann durch RPIs oder Fire TV ablösen ...

    Allerdings geht Streamdev "Reelbox to Reelbox" nach meinem Wissen <mit zentralen Timern> ebenfalls nur im Multiroom ... ist das ggf. nicht korrekt?

    Gruß,
    Rainer

    Danke für die Mühe in jedem Fall!

    Ohne Multiroom kommt für die Familie leider nicht in Frage. Dazu haben wir noch zu viele echte Reel-Geräte im Haushalt die ich nicht alle einzeln aufnehmen lassen will (Stromverbrauch, Instabilitäten etc.). Der Server mit 1.94 in der VM läuft typisch wochenlang ohne reboot und funktioniert tadellos.Avantgarde und Netclients wachen schon mal nicht aus dem deep standby auf oder "hängen" anderweitig ... schlecht bei geplanten Aufnahmen.

    Eine andere Idee:
    Einen funktionierenden XVDR-Client für SPMC 14.02 oder für Kodi 15 habe ich leider ebenfalls nirgends finden können. Hat ggf. jemand hier im Forum einen solchen für Android/Fire TV? XVDR war in der Vergangenheit bei mir immer recht stabil ... bis inklusive Gotham, danach gab es irgendwie nur noch VNSI mit seinem ganzen Versionsdurcheinander und den ständig wechselnden Protokollständen die nicht abwärtskompatibel sind.
    Auch streamdev empfinde ich z.B. mit dem VDR-Zapper auf einem PC mit VLC als grundsätzlich wesentlich stabiler als VNSI. Gibt es hier eventuell eine Lösung für Kodi? Auch hierzu habe ich nur Infos zu alten XBMC-Versionen gefunden ... ab Kodi - Funkstille.

    Oder könnte man eventuell sogar den Simple-IPTV Client in Kodi gegen den VDR der Reelbox laufen lassen ... Dann wäre es allerdings wahrscheinlich nix mit zentralen Timern etc. ...

    Auch ein interessanter Ansatz, direkt auf Android: https://github.com/pipelka/roboTV
    Leider erst ab Android 5.1 mit API Level 22 lauffähig, also nix für's Fire TV ...

    Es bleibt schwierig ...

    Gruß,
    Rainer

    Na dann tests ich doch gerne mal weiter ...

    Anbei das Ergebnis im syslog mit der letzten Version:

    Laden kann er ihn nun:

    Code
    Jul 22 22:11:08 BM2LTSR66RBex vdr: [9349] loading plugin: /usr/lib/vdr/libvdr-vdrmanager.so.1.7.29.5
    Jul 22 22:11:08 BM2LTSR66RBex vdr: [9349] loading plugin: /usr/lib/vdr/libvdr-vnsiserver5.so.1.7.29.5
    Jul 22 22:11:08 BM2LTSR66RBex vdr: [9349] loading plugin: /usr/lib/vdr/libvdr-xinemediaplayer.so.1.7.29.5

    Beim Connect mit dem VNSI Client in Isengard (15.0 RC2) auf dem Fire TV dann folgendes:

    Code
    Jul 22 22:04:16 BM2LTSR66RBex vdr: [5200] loading /etc/vdr/plugins/vnsiserver5/allowed_hosts.conf
    Jul 22 22:04:16 BM2LTSR66RBex vdr: [5200] VNSI: Client with ID 0 connected: 192.168.1.2:53621
    Jul 22 22:04:16 BM2LTSR66RBex vdr: [5679] VNSI: Welcome client 'XBMC Media Center' with protocol version '8'
    Jul 22 22:04:16 BM2LTSR66RBex vdr: [5679] VNSI-Error: Client 'XBMC Media Center' have a not allowed protocol version '8', terminating client
    Jul 22 22:04:20 BM2LTSR66RBex vdr: [5154] connect from 127.0.0.1, port 60429 - accepted
    Jul 22 22:04:20 BM2LTSR66RBex vdr: [5154] closing SVDRP connection
    Jul 22 22:04:23 BM2LTSR66RBex kernel: [  196.110401] VDR VNSI Server[5679]: segfault at 53c61a20 ip b54fbd93 sp b494b260 error 4 in libvdr-vnsiserver5.so.1.7.29.5[b54dd000+4e000]
    Jul 22 22:04:23 BM2LTSR66RBex logger: VDR crashed!!!

    Danach startet der VDR neu und beim Connect von VNSI erneut das gleiche:


    Ich habe auch nochmal mit dem originalen VNSISERVER unter 1.94 getestet. Es dauert dort halt EWIG das EPG einzulesen (im Bereich 30 Minuten für 100 Sender). Das gleiche gilt für den etwas älteren Client im Kodi 14.02 Stable mit der Protocol Version 6. Isengard kommt inzwischen mit der Protocol Version 8 im vnsi addon.

    Wobei das hier tausende Male im syslog erscheint:


    Gruß,
    Rainer

    Danke für den Einsatz!

    Leider tut auch der nicht ... nun ein anderes "undefined Symbol" ...

    Code
    Jul 22 01:41:27 BM2LTSR66RBex vdr: [5131] loading plugin: /usr/lib/vdr/libvdr-vnsiserver5.so.1.7.29.5
    Jul 22 01:41:27 BM2LTSR66RBex vdr: [5131] ERROR: /usr/lib/vdr/libvdr-vnsiserver5.so.1.7.29.5: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
    Jul 22 01:41:27 BM2LTSR66RBex vdr: [5131] plugin.c:340 loading plugin FAILED; removing it from dll list

    Kann ich irgendwie noch mehr debug info erzeugen um den Fehler einzugrenzen?

    Gruß,
    Rainer

    Danke ... verstehe die Problematik ... ich würde meinen Server auch zu gerne auf 2.74 umstellen. Auf der AVG II läuft 2.74 inzwischen bestens.
    Aber ohne stabiles Multiroom (zentrale Timer und Suchtimer) zum Aufnahmeserver streikt die Regierung.

    Anbei Ergebnis vom Test mit der neuen Version:

    Code
    Jul 19 23:11:28 BM2LTSR66RBex vdr: [5046] loading plugin: /usr/lib/vdr/libvdr-vnsiserver5.so.1.7.29.5
    Jul 19 23:11:28 BM2LTSR66RBex vdr: [5046] ERROR: /usr/lib/vdr/libvdr-vnsiserver5.so.1.7.29.5: undefined symbol: _ZNK8cChannel4NameEv
    Jul 19 23:11:28 BM2LTSR66RBex vdr: [5046] plugin.c:340 loading plugin FAILED; removing it from dll list

    XVDR auf Isengard ist ja leider ebenso wie Streamdev keine echte Option mehr ... scheint sich alles auf VNSI zu konzentrieren.

    Gruß,
    Rainer