Beiträge von te36

    Stimmt. das mit der LED hatte ich schon wieder vergessen. Wer lesen kann ist klar im Vorteil ;)


    Also gucken ob da bei Elkos auf dem motherboards irgendwelche Blaehungserscheinungen sichtbar sind, eg: die alumniunum-oberseite nicht kkomplett flach ist. Die Elkos finden sich meist um die CPU herum. Bei mir ging das Motherboard so langsam ins jenseits, liess sich manchmal nur nach 5 minuten einschalten, verklemmte sich nach ein paar tagen, etc. pp. Habe dann sogar mal die Elkos austauschen lassen von einem Profi, hat aber das Motherboard nicht widerbelebt. ;(

    Ich finde das mit hausmitteln immer sicherer ?


    einfach mit gdisk auf der neuen platte die partitionsstruktur der ersten platte auf der neuen platte herstellen, halt bloss mit GPT. Dabei die groesse der einzelnen partitionen waehlen wue gewuenscht.


    Dann die filesystems mit mkfs.ext4 und mkswap anlegen.


    Gucken ob in der /etc/fstab partitionslabel verwendet werden, und entsprechend die name der filesystem (tune2fs -L <name> <part>) anpassen.


    bootpartition mit grub einrichten. Booteintraege anpassen.


    partitionen mounten, jede Partition mit rsync -avxSHD kopieren. Root partition kopiert man indem man "mount --bind / /mnt/root" macht und dann von /mnt/root kopiert.


    Habe mit den hausmitteln mein gentoo system seit ca. 2008 immer wieder auf neue disks/PCs gebracht.


    Mit den Hausmitteln kann man halt einfacher Anpassungen machen und nur einzelne schritte korrigieren wenn was falsch geht.

    ansonsten gucken obs eine von aussen erreichbare sicherung gibt, teilweise merkwuerdig versteckt. Wenn nicht auch mal Netzteil aufschrauben und innen gucken. Sicherungen gehen schon mal kaputt. Wenn innen dann muss man die evtl. raus/reinloeten. Bei mir hat sich das letzte Aufmahen des Netzteils alleine schon fuers Entstauben gelohnt (jaja, haette man den Luftkreislauf im PC besser gebaut waere das nicht noetig gewesen).


    wenn das netzteil noch garantie hat, zur reparatur schicken. auf die art habe ich jetzt auch ersatznetzteil im Schrank liegen.

    Einfach auch zweimal hintereinander den SSH login ausprobieren, und dann im syslog gucken wieviel weiter die PID des geforkten SSHD ist. Das gibt einen hinweis darauf ob evtl. da im Startup etwas busy prozesse forkt oder nicht. Eg: Wenn die differenz der PID zwischen den zwei aufrufen > 50 ist dann koennte sowas sein. Ansonsten, wenn die Differenz niedriger ist dann koennen es solche limiter sein die per user konifguriert werden.


    Auch mal: NFS server stoppen, gucken dass ssh geht. Dann mal alle dateien, insbesondere die . dateien aus dem homedirectory des benutzers wegbewegen. http server starten. gucken ob/was sich da im leeren homedirectory getan hat. ssh ausprobieren, gucken ob sich was im homeidrectoy geandert hat. Sieht zwar alles so aus als ob die probleme passiren bevor der SSH a in das homedirectory geht, aber man weiss ja nie.


    Und natuerlich schauen ob sich die loginshell des users geaendert hat wenn http laeuft (/etc/passwd).

    Danke, Klaus


    So eine Antwort habe ich befuerchtet ;( Mit diesem Design schuetzt der VDR halt nicht die Aufnahmen vor schlecht geschriebenen plugins. Und jeder plugin entwickler hat die Herausforderung einen komplett asynchronen Datenempfangsteil zu schreiben. statt das es dafuer einmal im VDR code gibt der halt in der lage ist pro plugin daten speichern und notfalls pro plugin wegschmeissen zu koennen. Erinnert an MacOS < 10 collaborative multitasking ;-)) Oder SVDRP. Aber da wird das problem ja im VDR core in 2.3 gefixt.


    Meine Befuerchtung ist jetzt halt, dass es so ein bufferdesign im streamdev-server nicht gibt, und das es da fuers streamdev nicht mehr genug aktive Entwicklung gibt dass das da in absehbarer Zeit reinkommt.


    Ansonsten faellt mir als kurzfristiger workaround noch eine art Notbremse ein: wenn die receive funktion fuer ein plugin feststellen kann wie hoch der fuellstand im VDR core buffer ist, dann koennte es einfach die empfangenen daten ab einem bestimmten konfigurierten threshold (< 100%!) direkt wegschmeissen statt rauszusenden. Wenn man das auf der plugin seite implementieren will, dann muss man natuerlich einen API call haben um den fuellstand zu erfragen. Gibts so einen API call ?


    Das notbremsen Design hoert sich dumm an, weil man ja garnicht genau weiss das dieses plugin wirklich der schudige fuer den hohen gemeinsamen bufferstand ist, aber das ist genau das was in Routern beim QoS bei gemeinsamer Queue gemacht wird (per class drop thresholds). Tut statistisch erstaunlich gut. Je verdaechtiger ein plugin ist sich schlecht zu verhalten, desto niedriger muss bloss sein drop threshold sein.

    Gibts da eigentlich eine Moeglichkeit, dass das Teil zum PC hin so aussieht wie ein MCE RC6 empfaenger, also dort ohne aenderung der software angeschlossen werden kann ? Aber dann halt die codes einer anderen fernbedienung empfaengt ? Habe naemlich leider auch mediacenter mit windows, aber keine lust dort viel mit treibern rumzubasteln.


    Gibts irgendwo Doku zu stm32IRconfig/_gui ?


    Danke!

    Diese zeiele sieht eher wie Fehler aus:


    sshd[9603]: error: do_exec_pty: fork: Resource temporarily unavailable


    Stopp mal den hhtpd und probier ssh nochmal, und guck dann was Du da siehst im syslog.


    Wegen dem obigen fehler bin ich mir nicht so sicher, ob es da fuer den naechsten Fehler einen separaten Grund gibt oder nicht:


    sshd[9606]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.140.1 user=httpuser


    Evtl. hilft es halt die syslogs zu verleichen mit, wenns funktioniert.

    vdr 2.2.0 "schneller" Server (E3-1231 CPU, SATA3,..) mit 5 tunern (FF+4*DDbridge), streamdev-server 0.6.1.


    Aufzeichnen von eg: 10 * SD Kanaelen verteilt auf die 5 tuner - keine Probleme.


    Aufzeichnen von nur einem Sender. Natuerlich auch kein Problem
    Gleichzeitig streamen desselben senders per streamdev auf zu langsamen client: Aufnahme hat paketverluste.


    Siehe Auszuege aus Syslog am Ende. Wenn ich das richtig interpretiere passieren die drops im "device section handler thread" und im "device receiver thread", die ja wohl irgendwie beide im Datenpfad fuer die Aufzeichnung sind.


    Das war jetzt getested einfach mit VDR streamdev receiver mit PS oder TS format uebers (viel zu langsame) Internet, weswegen da natuerlich der streamdev nie alle pakete abliefern kann. In der Realitaet ist das Problem ein RPI1 hinter powerline und dann wohl alle arten von temporaeren Powerline durchsatzproblemen. Aber zu langsame clients muss ja auf jeden Fall gehen ohne dass dabei gleichzeitig passierende Aufnahmen kaputt gehen. Temporaere Durchsatprobleme zu clients kann man ja nie komplett vermeiden bei billigclients, wifi oder powerline oder streaming uebers internet.


    Lokal kann man das problem einfach dadurch reproduzieren indem man als 2te zeile in externremux.sh sowas wie ein "sleep 10000" reinkloppt, und dann eg: via VLC /EXT/<kanal> stream. Da kommt beim VLC natuerlich nix mehr an, aber der streamdev verhaelt sich in Richtung VDR genauso wie ein zu langsamer client - er nimmt keine daten vom VDR mehr ab, und im VDR kommt es zum head-of-line blocking der gesharten device/receiver threads.


    Problem ist nicht FF spezifisch (device 1), auch repliziert mit ddbridge (octopus) tuner. Problem tritt auch auf wenn der langsam gestreamte Kanal nicht derselbe ist wie der aufgenommene, sondern bloss auf dem selben transponder/tuner ist - eg: streamen von KIKA bei gleichzeitiger Aufnahme von ZDF.



    01:25:12 vdr[14597]: [14623] device 1 section handler thread started (pid=14597, tid=14623, prio=low)
    ...
    01:25:14 vdr[14597]: [14597] recording to '.../Wilsberg/Die_Entf?hrung/2016-12-07.23.54.28-0.rec/00003.ts'
    01:25:14 vdr[14597]: [14671] recording thread started (pid=14597, tid=14671, prio=high)
    01:25:14 vdr[14597]: [14672] device 1 receiver thread started (pid=14597, tid=14672, prio=high)
    01:25:14 vdr[14597]: [14673] device 1 TS buffer thread started (pid=14597, tid=14673, prio=high)
    ...
    01:26:21 vdr[14597]: [14641] Streamdev: Accepted new client (HTTP) 192.168.124.201:51359
    01:26:22 vdr[14597]: [14883] streamdev-writer thread started (pid=14597, tid=14883, prio=high)
    01:26:22 vdr[14597]: [14884] streamdev-livestreaming thread started (pid=14597, tid=14884, prio=high)
    ...
    01:26:26 vdr[14597]: [14623] ERROR: 1 ring buffer overflow (188 bytes dropped)
    01:26:28 vdr[14597]: [14672] ERROR: 1 ring buffer overflow (188 bytes dropped)
    01:26:32 vdr[14597]: [14623] ERROR: 57 ring buffer overflows (10716 bytes dropped)
    01:26:34 vdr[14597]: [14672] ERROR: 35027 ring buffer overflows (6585076 bytes dropped)
    01:26:38 vdr[14597]: [14623] ERROR: 60 ring buffer overflows (11280 bytes dropped)
    01:26:40 vdr[14597]: [14672] ERROR: 38349 ring buffer overflows (7209612 bytes dropped)
    01:26:44 vdr[14597]: [14623] ERROR: 61 ring buffer overflows (11468 bytes dropped)
    01:26:46 vdr[14597]: [14672] ERROR: 39070 ring buffer overflows (7345160 bytes dropped)

    Naja, zumindestens scheint dann ja das aufnehmen der laufenden Sendung ein workaround zu sein, den auch ein "normaler" benutzer verwenden kann um das system wieder zum laufen zu bringen.


    Koennte helfen, die syslog ausgaben zu vergleichen:


    1) Client started, kriegt schwarzes bild (also die syslogs um den "Frontent timed out" fehler herum).


    2) Schwarzes bild im client, laufende Aufnahme wird programmiert. Ich denke mal da wird ja auch irgendewas geloggt um anzuzeigen dass der
    VDR restarted und hoffentlic warum. Falls da auch ein "Frontent timed out" kommt und direkt danach der VDR restarted wird, dann scheint ja evtl. bei 1) bloss die logik zu fehlen, diesen restart zu machen.


    Wobei restart ja eigentlich immer ein fehler ist, d.h. wir reden immer nur noch von workarounds.

    Deine Fehlerbeschreibung "Dann kann ich mich nicht mehr...einloggen" laesst viel Spielraum fuer Interpretationen. Z.b:


    - Nach Eingabe von username/password kommt "Password incorrect"
    - Nach Eingabe des Passwords kommt keine password Fehlermeldung aber die SSH verbindung terminiert direkt danach.
    - Es taucht ein Terrorist auf der Dich mit einer Waffengewahlt hindert.



    :D :D :D


    Wenn da auf dem System ein sshd laeuft, einfach mal ein strace -f -p <sshd-pid> machen und gucken was da passiert. Und ein "cd /var/log ; xtail * */*" oder so um zu gucken was da fuer Fehlermeldungen kommen (weiss man ja nie wo die kommen wenn da komische neue zusatzsysteme drin sind die in ihre eigenen unterdirectories loggen). Ansonsten auch immer gerne mal in die ersten Zeilen voom .login und .profile oder so was reintun um zu kontrollieren ob die ueberhaupt gestartet werden.


    Sorry, letztes OpenSuse das ich in den Fingern hatte war 7.3. Bin aber sicher, dass Du recht hast und da irgendwelche OpenSuse security magie passiert. Fragt sich, warum Du dagegen ankaempfen willst.

    - VDR prozess laeuft. nix los, keine clients, keine recordings.
    - Client verbindet, eg; KODI/VNSI, VDR produziert "Frontent timed out...".
    - Schwarzes Bild auf client. VDR prozess laeuft weiter. [Y/N]
    - Auf dem VNSI client koenntest Du jetzt eine Aufnahme gucken ? [Y/N]
    - Wenn ja: was passiert wenn Du Aufnahmewiedergabe stoppst und direkt danach wieder versuchst live zu gucken ?
    - Was passiert, wenn Du versuchst die laufende Sendung als Aufnahme zu programmieren und dann von aufnahme anzusehen.


    Ich frage, weil ich in der vergangenheit auch situationen hatte, wo man den vdr mit hin und herschalten aufnahme an/stop, etc.. quaelen musste bis wieder live-tv kam.

    Nein, natürlich kann man den Empfänger an die Standby-Spannung des Netzteils hängen und den Rechner damit auch aus dem S5 holen: https://github.com/ranseyer/ST…/1_Small_ST-Link/Doku.pdf


    Das PDF hatte ich schon gelesen, aber entweder ich erblinde (kann gut sein), oder da stand nur: "Die Platine... mit einem USB Anschluss verbinden, der immer mit +5V versorgt ist" - aber halt keine weiteren Details. Habe die auch nirgendwo anders gefunden. Und bei meinem P sind die USB ports nach eg: einem linux "shutdown" oder so halt nicht mehr mit power versorgt. Deswegen meine Frage wie das ueberlicherweise verkabelt wird und was man da im BIOS fuer einstellen muss, und welcher suspendmodus dann beim VDR verwendet wird, etc.. pp. Wiki URL oder so waere prima ;-))


    Gelegentliches Streaming ist IMHO kein Argument dafür, dass man einen VDR durchlaufen lässt, die 30-40 Sekunden kann ich abwarten, nachdem ich ihn (z.B. per WOL) geweckt habe.


    Klar, man kann alles machen, wird halt evtl. kompliziert. Muesste jede client App WoL senden koennen, und WoL von einem Smartphone/Handy on the road kann schwierig werden weils nicht im gleichen LAN ist. Kommt halt auch immer drauf an ob der VDR noch andere Dinge machen soll. Bei mir laeuft halt noch squeezeboxserver fuer die Radios im Haus und file server. Eg: Wenn man sich aufnahmen aufs tablet kopieren will oder so.

    Also mein VDR watchdog scheint ein simpler script vom gentoo linux zu sein, der einfach den VDR nachstartet wenn der VDR prozess terminiert.
    /usr/sbin/vdr-watchdogd bei mir. Gibt auch einen eingebauten watchdog im vdr, option --watchdog oder -w. Musst Du mal gucken was da bei dir ist. Aber das hilft ja als workaround alles auch nur wenn der VDR bei dem Problem terminiert und nach einem Neustart dann wieder funktioniert. Und da hast du ja nix zu gesagt wie das bei dir aussieht.


    eg: VDR stoppen, 5 minuten warten, VDR manuell starten. Geht's dann ? (5 minuten warten in der hoffnung das irgenwelche idle aktion an der DVB Karte dann zuschlaegt).


    Wenn Du das Problem mit dem "frontent timeout" hast, dann kannst Du im syslog (/var/log/messages oder /var/log/syslog, je nach linux) recht einfach feststellen, ob der VDR danach neu started, z.b. die PID der VDR logeintraege wuerde sich aendern. Oder halt einfach mal VDR manuell starten, warten bis problem passiert. Bei mir gibt dder VDR halt nach dieser fehlermeldung auf und kann deswegen auch neu gestartet werden.

    Ich empfehle eine Konstruktion wie bei der Cray 2: https://en.wikipedia.org/wiki/Cray-2


    - Das RPI gehause gut abdichten, auf beiden seiten je einen Schlauch anschliessen.
    - Aus Glasrohr am Bunsenbrenner eine lange Kuehlschlange blasen, mit Schlaeuchen verbinden
    - RPI und schlaeuche/Kuehlschlange mit Freon fluten. Das ist dein primaerer Kuehlkreislauf
    - Im Baumarkt einen dekorativen Hausspringbrunnen kaufen Kuehlschlange da drauf setzen.
    Das ist Dein Waeremtauscher.
    - Alternativ Kuehlschlange in ein Aquarium versenken und mit Wasserventilatoren (FIschen) bevoelkern.


    Mit so einer Kuehlung muss der VDR auch garnicht funktionieren, und die Familie ist trotzdem gut unterhalten.

    Nochmal zum mitschreiben: Wenn Du jetzt dieses Problem hast und den VDR neu startest (nicht den PC< bloss den VDR prozess), dann ist das problem jedesmal behoben ?


    Was passiert denn wenn das Problem auftrtitt und du nix machst ? Eigentlich sollte da ja der VDR watchdog anspringen und den VDR neu starten. Evtl mal konfigurieren ?


    Wenn das eh nur auftritt wenn alle tuner idle sind (also auch keine Aufnahmen machen) und sich das mit watchdog triggered VDR restart beheben laesst, dann ist das vielleicht keine Loesung aber erstmal ein ausreichender workaround.


    Hast Du mal probiert den VDR bei diesem Vorgang auf einen anderen Kanal zu tunen, kann man glaube ich entweder im vdr.conf einstellen, oder einfach im channels.conf mal einen Kanal von einem anderen Bouquet als ersten Kanal eintragen (eg: ZDF statt ARD).


    Ich habe FF im VDR als primaere Karte und die timed jedesmal beim start des VDR mit derselben Fehlermeldung aus "Frontend 0 timed out while tuning to channel 1". Ich muss deswegen den VDR immer selbst compilieren und den timeout fuer das sync auf glaube ich 2 minuten setzen. D.h. beim VDR startup dauert das haeufig mehr als eine Minute. Irgendwann ging es garnicht, da hatte ich mir nur noch helfen koennen indem ich ZDF als startup Kanal konfiguriert habe. Das ging dann deutlich schneller. War nach ein paar tagen vorbei. Waehrend des Betriebs geht dann monatelang nix mehr schief weil der tuner in der FF ja nie idled sobald er mal gestartet wurde (habe auch deswegen das idle plugin nicht eingebaut auf dem VDR).

    Ein paar Gedanken/Fragen zum Thema VDR einschalten per IR - oder auch nicht:



    Wenn der VDR fuer irgendwelche clients im Haus (RPI, anderes SBC Tablets, Smartphones) oder für streaming ausserhaeuslich (VDRtoGo ;) dienen soll, dann muss der VDR PC sowieso durchlaufen, also waere es dann wichtiger zu schauen, dass der moeglichst mit stromsparenden Komponenten ausgestattet ist und/oder dass der dann im Idle Betrieb wenig Strom verbraucht.


    Habe leider noch keine gute Anleitung gefunden, was man so bezueglich stromsparend machen kann - das einzige was bei mir im Server VDR passiert ist halt dass die Platten stoppen wenn sie idle sind. Ich glaube ich koennte noch den VDR main tuner idlen, so dass der receiver anderen clients zur verfuegung steht wenn der hauptfernseher aus ist. Aber das hat ja weniger mit Stromsparen zu tun als mit tunern effizient nutzen. Aber sonst.. was geht da noch fuer einen VDR "server" (frage kommt gerade gelegen, weil gerade die jaehrliche Stromrechnung kam und *hust* *hust* *hust* ;-).


    Martins IR empfaenger sieht interessant aus, aber so wie ich das verstehe muesste der IR Empfaenger ja selbst mit strom versorgt werden und die MCU da drin arbeiten. Aber die MCU kriegt ihren Strom ja nur vom USB, oder ? Aka: muss man damit das funktioniert z.b. "wake from S3" im BIOS einschalten um sicherzustellen, dass der USB Port im powersave modus strom bekommt ? Und funktioniert das dann halt auch nur bis runter zu S3 ? In welchen power state suspended man denn eigentlich VDR (ich mach ja kein suspend, bin aber neugierig).


    Ich haette ja eigentlich erwartet, dass da die 5V leitung des USB fuer den IR Empfaenger irgendwo angeschlossen wird, wo der PC auch im ausgeschalteten Zustand noch 5 V hat (also hibernate oder poweroff mit angeschaltetem Netzteil). Gibt ja so ein 5V standby line. Dachte auch der Powerswitch vom PC selbst ist darauf angeschlossen, kenne mich damit aber nicht aus.



    Wenn man den PC auf eg: S3 schlafen laesst, dann braucht man aber auch keine Spezial-HW die den Power-Switch betaetigt. Dann sollte man einfach einen guenstigen MCE/RCE6 remote empfaenger nehmen koennen und den PC damit aufwecken koennen:


    https://www.loggn.de/linux-xbm…-fernbedienung-aufwecken/


    Ansonsten: Ich habe die Logitech Harmony 650's im Einsatz, und da gibt es ja (wie bei vielen lernfaehigen Fernbedienungen) die Moeglichkeit ein Geraet/Fernbedienung entweder durch Eingabe von Code/Namen und/oder durch Anlernen von Tasten (IR-zu-IR) zu definieren. In meiner Erfahrung sollte man immer vermeiden, Tasten ueber IR-zu-IR anzulernen Ich habe mal vergleichen fuer die gleiche existierende Fernbedienung IR-zu-IR oder Code angelernt, und bei IR-zu-IR generiert die Logitech bei weitem nicht so einfache/saubere IR-Befehle. Also gerade Befehe fuer die man autorepeat will werden dann sehr langsam oder unzuverlaessig. Deswegen ist es immer wichtig zu verstehen, welche IR-Befehle ein "lernfaehiger" IR empfaenger wie der von Martin kann, um dann zu schauen, welche "Codenummer/Geraetemodell" man auf der Logitech angeben will. Das kann am Ende besser funktionieren als mit MCE (mehr Tasten), aber evtl. auch nicht. Und MCE codes sind halt auf jeder lernfaehigen Fernbedienung bekannt.


    Das nur als Gedanken warum ich immer erst mit MCE remote anfangen wuerde, und auf andere IR-Empfaenger nur gehen wuerde wenn das irgendwie mit MCE nicht hinzubekommen ist, oder wenn ichs wirklich braeuchte: Mehr als ein PC im Raum fuer den ich IR brauche, oder wenn ich halt eine schicke Fernbedienung verwenden will die halt nicht lernfaehig ist. Also z.b. so eine multifunktionsfernbedienung fuer den Fernseher die auch noch vom selben Hersteller DVD Player oder so unterstuetzt (den man nicht hat). Da will man dann im VDR einen IR Empfaenger der sich auf diese DVD Player Befehle einlernen laesst.

    Ah, Ok, hab ehrlich gesagt bisher auch noch nicht versucht existierende Packages auf/fuer RPI zu compilieren. Verwende die RPIs aber nur als reine clients, bin deshalb noch nicht ueber streamdev server limits auf RPI gestolpert.

    Wenn der VDR an einem fernseher haengt der CEC kann wuerde ich auf jeden Fall empfehlen, mal CEC auszuprobieren. Das ist erstmal bastelei, kann aber ddie beste loesung sein, weil Du dann auf der programmierbaren Logitech noch nicht mal ein separates Geraet programmieren musst.
    Bastelei ist vor allem herauszufinden, ob/wie du am besten CEC am PC hinbekommst. Als ich CEC auf meinem PC vor ca. 2 Jahren ? zum laufen brachte, gab es sinnvoll nur Pulse-Eight CEC Adapter. Der laeuft bei mir prima mit Kodi. Hab bisher noch nicht CEC mit VDR gemacht, gibt aber ja das cecplugin.


    Wenn nicht CEC, dann am einfachsten von der Bucht einen billigen MCE remote empfaenger kaufen. Gibts meist zusammen mit Fernbedienung im Bundle. MCE Remote ist gut unterstuetzt in aller software. Und kriegst Du mit jeder lernfaehigen Fernbedienung zum laufen.