Moin,
da du Dir bereits Deine Meinung gebildet zu haben scheinst, deucht mir, Du wartest auf Argumente pro Synology. 
Ich selbst setze auch einen Gen8 unter OMV ein - inkl. 4x2TB und 1x 256GB-SSD bei 16GB und E3-1265Lv3. Die VMs inkl VDR-Server (MLD5) sowie eine einige owncloud-Instanzen für gegenseitiges externes Backup. Das Teil verbrenntt nur gemütliche 30W.
Gruß,
Erik.
Muuhhh,
der Tipp mit /etc/vdr/conf.d war richtig - auch wenn das bei mir ein Link nach /etc/vdr/conf.avail war.
Dort alles umgestellt - rennt.
Da frage ich mich latürnich, woher diese Verzeichnisschieberei kommt.
Den Server will ich schon angeben, weil es einen VDR-Adressbereich gibt, in dem die VDR-Clients und das OctoNet rumeiern.
Gruß,
Erik.
Moin zusammen,
ich schlage mich gerade mit dem Problem unter OMV3.0 (Jessie) herum, dass der vdr (2.2) mit dem satip-Plugin (2.1.3) den Server OctoNet nicht findet.
In /etc/vdr/plugins/plugin.satip.conf steht folgendes:
[satip]
-d 6
-s 192.168.22.20|DVBS2-8|OctoNetWie kann ich herausfinden, warum der Server nicht gefunden wird, obwohl ich per Ping oder WebIf sauber darauf zugreifen kann?
VG
Erik.
Moin!
Zitat von »Pfeifenraucher«
Seitdem ich EPG-Scan als pluging im OSD abgeschaltet habe und nur noch epg2vdr verwende, werden die Tuner auch wieder vom vdr freigegeben.
Aber wer will schon einen VDR ohne diese Funktionen ...
Ja nu, irgendwie muss doch mal die Problemzone eingekreist werden.
Zitat von »Pfeifenraucher«
Wie betreibst Du denn Deinen Octopus? An einem Multiswitch? An den Nutzerausgängen oder Stammausgängen? Wann hast Du das Gerät gekauft?
Das Gerät wird an den Nutzerausgängen betrieben, ich müsste mal suchen, um welchen es sich handelt. Das OctoNet habe ich im Oktober kurz nach der Freigabe gekauft, der Multiswitch ist auch noch kein Jahr alt, nachdem der alte scheinbar ein Problem mit der Stromzufuhr zu haben schien - Hersteller und Namen muss ich suchen, es war aber eine empfohlene Markenware.
Und naja, Dachboden ist halt per se wärmste Ort in einem Haus, dennoch habe ich aktuell keine Probleme mit meinem. Betreibe aber auch (m)einen Eigenbau, passiv gekühlt mit "offenem Gehäuse" ...
Hmm, kann ich nicht bestätigen. Der Dachboden im eigentlichen Sinne ist gedämmt, der Rest vom Dach des alten Kastens nicht - macht auch wenig Sinn. Somit entfällt das Argument mit dem wärmsten Ort.
Momentan sind da oben knapp unter 10°C und gut durchlüftet. Der Hardwaremonitor zeigt 50°C bei sieben aktiven Streams inkl. EPG. Ich habe gestern Abend mal auf mld50-testing mit vtuner umgesattelt, seither gehen auch da mehr als vier Tuner gleichzeitig. Warten wir mal ab, wie stabil das ganze ist.
VG Erik.
Und, läuft die Onet-8 besser, stabiler etc?
Mein ONetmaxS2v2 klemmt irgendwann einmal das Netzwerk ab und reagiert nimmer. Nur ein Power-Off/-On hilft.
Letzte Woche dachte ich, das Ding rennt besser, wenn es nur eine NW-leitung zur FB gibt - zuvor war die VM-Leitung direkt in den Switch gestopft und brach spätestens nach drei Tagen ab. Der VM-Server steckt nun in einem anderen Switch.
Sobald sich das ONet aufhängt kommt:
Feb 28 23:08:27 (MLD) user.err vdr: [1322] curl_easy_perform() [rtsp.c,165] failed: Timeout was reached (28)
Feb 28 23:08:27 (MLD) user.err vdr: [1322] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.2.239/ [device 4]
Feb 28 23:08:27 (MLD) user.err vdr: [1322] SATIP-ERROR: Connect failed [device 4]
Feb 28 23:08:47 (MLD) user.err vdr: [1325] SATIP-ERROR: Tuning timeout - retuning [device 5]
Feb 28 23:08:47 (MLD) user.err vdr: [1322] SATIP-ERROR: Tuning timeout - retuning [device 4]VG Erik.
Moin!
fnu
Danke für die Info´s , der Preis ist ja wirklich ok.
Wenn man das mal runter rechnet, sind das 67Euro pro Tuner.
Dann ist die Lösung mit dem "DD Octopus NET V2 S2 Max - SAT>IP Netzwerktuner" für 499,- nochmalig günstiger
VG
Erik.
Moin!
Die Einstellung "Disable Multiswitch Emulation" war es nicht - System muss dennoch irgendwann neu gestartet werden. Es reicht bei mir, dass das OctoN rebootet wird und weiter geht es im Text - bis zum nächsten mal.
Da scheint mir was im Argen zu liegen - aber was... Hat vielleicht jemand eine Idee, dem Fehler auf die Spur zu kommen?
Warum wird zuverlässig das höchste VDR-Device nach einer gewissen Zeit nicht mehr erkannt?
Der Support reagiert momentan auch sehr schleppend.
Mal schauen, wie es weitergeht. Zur Not muss doch der Netceiver per minisatip angesprochen werden, wenngleich mir VLAN und Virtualbox nicht so geheuer erscheint.
Gruß,
Erik.
Moin!
Ich stelle zur mein System mit einem Netceiver und mehreren Clients der Fa. Reel um auf eine VDR-Server-VM und diversen Clients. An relevanter Stelle kommt ein RPi2B zum Einsatz, welches bei meiner besseren Hälfte für Begeisterung sorgt - außer, dass es natürlich neu ist und der Bauer den Appel nicht kennt.
Zur Zeit arbeite ich noch mit Tastatur, für die Einrichtung einer XBox360-FB bzw. schlussendlich Logitech 900 an einem TSOP4838 fehlt mir noch die Zeit bzw. Urlaub.
Ich persönlich finde das SATIP-Konzept zukunftsweisender und damit auch flexibler.
VG
Erik.
Moin!
Ich habe heute beobachten können, dass der letzte Tuner (Device 2) immer in irgendeiner Weise blockiert wird und dann Fehlermeldungen im Log auftauchen. Eine mögliche Auswahl aus dem log sieht dann so aus:
Mar 1 10:45:39 (MLD) user.info vdr: [1353] SATIP: Detected 10 RTP packet errors [device 2]
Mar 1 10:46:11 (MLD) user.info vdr: [1360] SATIP: Idle timeout - releasing [device 2] 10x alle 30 Sek.Wiederholt sich laufend.
Mar 1 11:04:22 (MLD) user.err vdr: [1360] curl_easy_perform() [rtsp.c,165] failed: Couldn't connect to server (7)
Mar 1 11:04:22 (MLD) user.err vdr: [1360] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.2.239/ [device 2]
Mar 1 11:04:22 (MLD) user.err vdr: [1360] SATIP-ERROR: Connect failed [device 2]
Mar 1 11:04:53 (MLD) user.info vdr: [1360] SATIP: Idle timeout - releasing [device 2]
Zuerst dachte ich wieder an das OctoNet - war aber dieses Mal unschuldig. Erst als ich den VDR-Server-Dienst neu gestartet habe, war alles ok.
Hat jemand eine Idee, wie ich das System konfigurieren kann, dass der VDR nach Benutzung unnötige Belegungen bzw. hängende Threads möglichst selbst beendet?
VG
Erik.
Moin!
Hätte da noch eine Frage: Wie verhält sich bei Deinem Gerät der Lüfter - hört man den?
Die OctupusNet hängt bei mir im Dachboden. Den Lüfter hab ich nur einmal bei der Erstinbetriebnahme gehört und da war er sehr unangenehm.
Im Moment habe ich bei 17°C Umgebungstemperatur und im Webfrontend eine Hardwaretemperatur von ca. 35°C und der Lüfter läuft nicht/unhörbar.
Die OctupusNet schaltet unbenutzte Tuner wohl schon wieder ab. Gemessen mit einer DECT200 Steckdose sehe ich wie der Stromverbrauch zurückgeht, wenn weniger Streams gesendet werden.
Nach dem Einschalten oder einem Reset braucht SIe bei mir ca. 6W im Standby ohne benutzten Tuner. Sobald einmal ein Tuner gebraucht wurde geht der Verbrauch nicht mehr unter 9W.
Das mit dem Lüfter kann ich bestätigen. Auf dem Dachboden zeigt die Betriebstemperatur bei einem belegten Tuner was von 35°C an.
Seitdem ich EPG-Scan als pluging im OSD abgeschaltet habe und nur noch epg2vdr verwende, werden die Tuner auch wieder vom vdr freigegeben. Nichtsdestoweniger klemmte sich irgendwann das OctoNet weg, sodass den Tunern kein Durchsatz (Pakete tröpfeln vor sich hin, Speed nicht messbar) beschert wird.
Ich habe gestern mal die Einstellung "Disable multiswitch emulation" vorgenommen und dem VDR nur drei statt sechs Tuner zur Verfügung gestellt, mal schauen, ob es besser wird.
VG
Erik.
Moin!
Sowas kommt immer mal wieder vor, kann evtl. auch an irgend einem Plugin liegen.
Dieser Absturz ist aber quasi schon nach dem Ende des vdr kurz bevor der Prozess abgeräumt wird. Bisher gab es dadurch keine weiteren Probleme.
Wenn die Meldung nach dem Speichern der channels.conf, timers.conf usw. auftritt, würde ich mir keine weiteren Sorgen machen.
Hmm, befriedigend ist das nicht - wie kann ich mehr Infos herausbekommen?
Was wäre der sinnvolle Log-Level?
Gruß,
Erik.
Moin zusammen,
meine /var/log/vdr füllt sich in unregelmäßigen Abständen mit den Zeilen:
VDR exits at So Feb 28 21:46:30 CET 2016
*** Error in `/usr/bin/vdr': corrupted double-linked list: 0x00000000008589f0 ***
Aborted
Was will der Dichter mir damit mitteilen? Ich setze MLD5 stable ein und kann mit dieser Fehlermeldung nichts anfangen.
Weiß jemand mehr?
Gruß,
Erik.
Wenigstens einer, der das gleiche Problem hat, wie ich.
Bei mir hängt sich das OctoNet nach regelmäßigem Dauerbeschuss durch einen RPi2B auf. Ich schaffe es zur Zeit mangels Monitor nicht, den EPG-Scan via SAT über das Plugin ab zu schalten. Gefüttert wird das System über epgsync mit einem epgd-Server.
Prinzipiell sollte in der Tat ausreichen, dass System per Telnet zu rebooten - was nutzt Dir das, wenn das Netzwerkinterface Dich schlimmstenfalls nicht mehr auf das System lässt? Dann braucht es schon die Keule mit der Stromzufuhr. Aus meiner Sicht kann das jedoch nicht zielführend sein.
Welche Netzwerkeinstellungen hast Du? Ich habe bis auf Telnet nichts angehakt und die vom Support empfohlene Adresse 192.168.xxx.239 eingestellt - was in meinem System alledings keinen Unterschied macht.
Viele Grüße,
Erik.
Moin!
Mir würde ein satip-server-Plugin im vdr gut gefallen, damit alle Clients über diesen Standard sich ihre TV-Daten holen (beim vdr). Und der vdr hat trotzdem noch volle Kontrolle über die Devices und kann sie für Aufnahmen benutzen.
Solange es nur um die Anzahl der zur Verfügung stehenden bzw. einen Belegungsplan geht, wäre ich dem nicht abgeneigt. So muss ich für meinen Client immer ein Device offen halten bzw. auch ein zweites, weil ich u.U. mal gerade in den Modus für "Permanent Timeshift" will.
Vieleicht gibt es für letzteres bereits eine Lösung, die der VDR-Server übernehmen kann.
Gruß,
Erik
Moin!
Und das mit dem streamdev server hab ich auch nicht verstanden: das ist ja gerade das coole das sich die clients direkt auf den satip server verbinden. dem satip client kann man aber im Menu einen EIT Filter mitgeben, dann spart er sich das mit EPG komplett
OK, heute habe ich mal verstanden, was es mit dem EIT-Filter auf sich hat. Wenn ich heute Abend mal den Octopus Net neu gestartet habe, bessert sich das auch vielleicht mal.
Tja, die Einstellungen über den Server habe ich erfolgreich durchgeführt und das OctoNet ist ruhig - einzig der Test-RPi2B, der zudem auch nicht an einem Monitorhängt, belegt noch immer einen Kanal, den habe ich aber per RDP noch nicht so schalten können, dass das Plugin im Menü abgeschaltet werden kann.
Gruß,
Erik.
Hier solltest Du Dich in einmal in rsyslog bzw. die rsyslog.conf einlesen, wenn MLD den nutzt.
In MLD wird syslogd in busybox verwendet. Eine /etc/syslog.conf wird ignoriert.
Ich müsste jetzt "user.err epgd:" und "user.err vdr: epg2vdr" in eine neue Datei /var/log/epg umleiten - da stehe ich noch wie ein Ochs' vor dem Berg.
Vielleicht wäre das eine Option für die grafische Konfiguration.
Viele Grüße,
Erik.
Im Fred ging es aber auch um beide Pakete, von daher spielt epgd schon eine Rolle.
Für epg2vdr gelten weiterhin die Standardeinstellungen, die dann schon das vdr-Log mit Erfolgs-/Statusmeldungen zumüllen.
Gruß,
Erik.
Moin!
Die Log-Level habe ich weder bei epgd noch epg2vdr verändert. MLD-System schreibt auf die Festplatte, VDR läuft mit Log-Level eins und allen anderen Modulen ist keine separate Einstellung für Log-Level.
[Tante]: In der epgd.conf stand doch tatsächlich: LogLevel=0
Das scheint doch keinen Einfluss zu haben.[/TANTE]
Jruß,
Erik.
Moin zusammen,
gibt es eine Möglichkeit, die Log-Datei /var/log/messages zu erleichtern und den epg-Teil z.B. in /var/log/epg auszulagern?
Für mich geht es um zwei Aspekte:
1. Die Log-Datei messages wird mit epg2vdr-positiv-Meldungen (Update der Timer1-123 in 123 Zeilen erfolgreich) in sehr unregelmäßigen Abständen (alle 6-7 Minuten) geflutet - epgscan im vdr-OSD-Menü auf Null.
2. Die Status-/Update-/Fehlermeldungen des epgd erscheinen ebenfalls zahlreich im Hauptlog - auch da wäre es mir lieb, die Meldungen Richtung Fehler einzudampfen bzw. eine andere Logdatei zu verwenden.
Wie jeht dat?
Jruß,
Erik.
Moin zusammen,
ich kämpfe wieder mit einem VDR-Problem. Mein OctopusNet stellt acht Tuner zur Verfügung. Irgendwann diese Nacht meinte dann der VDR, dass Tuner2 nicht mehr da ist und hat damit die erste /var/log/messages voll geschrieben. Irgendwann wurde die Meldung beendet und eine neue eingeführt:
Feb 4 12:10:38 (MLD) user.err vdr: [9057] retrying
Feb 4 12:10:38 (MLD) user.err vdr: [9057] retrying
Feb 4 12:10:38 (MLD) user.err vdr: [9057] retryingIch kann auf dem headless VDR allerdings hin- und herschalten und Aufnahmen tätigen - sofern kein Ausstieg wg double-Link.
Wie kann ich herausfinden, warum:
1. Ein Tuner flöten geht, obwohl alle anderen noch aktiv erscheinen und die restlichen Tunerinstanzen am OctopusNet durchgewechselt werden.
2. Was will VDR mir mitteilen - die Aussage, "VDR: [pid] retrying" ist nicht besonders erhellend.
Gruß,
Erik.