Beiträge von Antiriad

Zitat von Dr. Seltsam

Ich habe letztlich einen günstigen Philips für meinen Vater gekauft, der zumindest DVDs und Bluray-Discs automatisch abspielt.
...
nein. Ich hatte auch schon darüber nachgedacht, selbst etwas zusammenzubasteln, macht aber wegen der fehlenden Blu-Ray-Unterstützung von Linux keinen Sinn.
Für meine Eltern kommen nur absolut stabile und kinderleichte Lösungen in Frage.

Also meiner Erfahrung mit Philips Blurayplayern nach wiederspricht sich "absolut stabil" und "Philips" ziemlich.
Hatte mal den BDP7700 (sogar zwei Stück um sicherzugehen das es kein HW Defekt war), aber das Ding war auch nach diversen SW Updates der am unstabilsten laufende Player der mir je begegnet ist.
Hat sich gerne mal sporadisch komplett aufgehangen (Netzstecker ziehen zum wiederbeleben notwendig!), Ist oft in Dauerreset loops gegangen wenn man mal eine Bluray im Player gelassen hat und man in dann aus und wieder eingeschaltet hat (rumhämmern auf der Eject Taste während des Bootens hat mit dem richtigen Timming geholfen die Scheibe dann doch noch raus zu bekommen).
Von den unzähligen HMI/OSD Fehlern möchte ich erst gar nicht reden. Ich war froh wenn es die Kiste überhaupt mal geschafft hat nen Film abzuspielen (dann aber auch bloß die Finger von der Fernbedienung lassen, es passierten die komischsten Dinge wenn man sowas exotisches wie z.B. eine FastRewind machen wollte, oder Kapitelsprünge).
Das Nachfolgemodel scheint den Amazonrezesionen nach in gleichem Masse stabil gewesen zu sein was die SW anging...

Und was ich von nem bekannten mitbekommen habe ist die Qualität bei den Philipsfernsehern mindestens auf dem gleichen Standard wie beim obigen Blurayplayer.

Also wenn es absolut stabil funktionieren soll, würde ich sagen bloß KEINEN aktuellen Philips kaufen (oder nur wenn man auch die genaue Typenbezeichnung/modell kennt von dem man weiß das er halbwegs stabil funktioniert).
Die Marke ist was Unterhaltungselektronik angeht bei mir zumindest auf der absoluten "No buy" Liste gelandet.

Hallo ako673de,

das Problem, das root-fs "ro" mounten zu müssen für ein einfaches&schnelles komplett Backup der Vdr installation per "dd" habe ich auch. (Schließlich sollen sich ja nicht grade irgendwelche Sektoren in der Systempartition ändern während dd die Parition grade sichert).
Hatte es vorher auch immer so gemacht erst von ner live-cd bzw. usb stick zu booten, oder noch ne weitere parallele Linux Installation auf der Platte zu haben die man dann im Grub anwählt, aber hat sich alles als zu unpraktisch und unnötig kompliziert bzw. langsam erwiesen.
Einfach nur per ssh ins "echte "System einloggen zu können und nur ein Script auszuführen zu müssen ist einfach unschlagbar was die usability angeht.
Ich gehe die Sache aber quasi vom anderen Ende an.

Ich stelle erst fest welche Prozesse den offene write handles aufs root-fs haben, die beende ich dann bzw. schieße sie ab und dann lässt sich auch das rootfilesystem "ro" re-mounten.
Hat denn Vorteil das man keinerlei Skripte/Configfiles/fstab vorher editieren muss und das gesicherte Image out-of-the box zurückgeschrieben werden kann ohne danach noch Modifikation vornehmen zu müssen.

Mit dem Kommando kann man sich anzeigen lassen wer write handles offen hat auf "/":

sudo lsof / | awk 'NR==1 || $4~/[0-9][uw]/'

Unter yavdr 0.6 ergibt sich bei meiner Installation dann daraus letztendlich diese Stop/Kill Sequenz (muss mit root rechten ausgeführt werden):

stop smbd
stop rsyslog
stop tntnet
stop udisks-automounter
stop avahi-linker
stop openbox
stop vdr
stop nmbd
stop xorg-launcher
killall -9 dhclient
killall -9 console-kit-daemon
stop dbus2vdr
stop lircd
stop systemd-logind

Wenn man jetzt das erste Kommando nochmal ausführt:

sudo lsof / | awk 'NR==1 || $4~/[0-9][uw]/'

Sollte die liste leer sein, wenn nicht, muss man halt schauen was man noch stoppen/beenden muss.

Auf jedenfall kann man danach mittels dem Kommando hier das root-fs read-only mounten:

sudo mount -o remount,ro /

und danach lustig mit dem Backup Tool seiner Wahl loslegen.

Also bei yavdr ist es glaub ich üblich LCDs die Gruppenrechten von "uucp" zu verpassen.
Hab mal letztens auch mal testweise einer meiner VDRs auf die aktuelle yavdr version aktualisiert,
und mein Alphacool LCD läuft z.B. mit dieser udev-rule unter yavdr 0.6.1:

SUBSYSTEM=="usb", ATTRS{idProduct}=="04eb", ATTRS{idVendor}=="060c", GROUP="uucp", MODE="0660"

Evtl. musste bei dir auch die GROUP & MODE Rechte aus dem obigen Alphacool-LCD Beispiel in deine udev-rules übernehmen.

Stimmt leider, bei iOS schaltet sich das VPN wenn man das iPhone nicht nutzt bereits kurze Zeit ab. Also jedes mal nach dem Lockscreen wieder ins Einstellungsmenü gehen und VPN aktiveren (und Finger kreuzen das die VPN Verbindung zur Fritze sich auch aufbauen lässt, klappt hier auf nem iPhone6 nicht wirklich immer...). iOS typisch lässt sich das Verhalten auch nicht konfigurieren, vielleicht geht da was per Jailbreak hack, wer weiß...
Unter Android funktioniert das deutlich besser, das is nur der Autodisconnect nach 1h nervig, aber das kann man leicht per App (VPNZilla z.B. kann reconnect) beheben und dann hat man tatsächlich permanent aktive VPN Verbindung um auf die internen IP Cams zugreifen zu können.

Habs mit dem AndroidStudio mal gebaut (die App setzt übrigens Android 5 vorraus, die anzahl der Gerät (wie z.B. Smart TVs) auf der Sie laufen könnte wird daher wohl sehr überschaubar bleiben),
aber zum laufen bekommen habe ich sie noch nicht. Es beginnt bereits damit das keine Main Activity im manifest angegeben ist, ich hab dann mal die beiden vorhandenen Activitys als MainActivity ausprobiert, aber ausser ein SetUpScreen ohne Funktion konnte ich mit der App noch nix sinvolles anfangen.

Aber vielleicht mach ich auch noch was falsch beim bauen... kenne mich mit dem Android Dev Geraffel noch nicht so gut aus.

Im Prinzip richtig, aber der yaUsbIR V3 hat so seine Probleme mit dem anlernen der POWER Taste zum wecken, das funktioniert nicht mit alle Fernbedienungen so richtig (der ATRIC hat mit der gleichen Fernbedienung übrigens kein Problem). Also auch meine Empfehlung: ATRIC.

Hätte ich jetzt eigentlich auch vermutet das yausbir einfach nur das Sample anlernt und dann halt vergleicht. Darum wundert es mich ja das es mit einigen Tasten funktioniert, aber ausgerechnet nicht mit der Powertaste der Fernbedienung. So komisch kann das Signal was die Hauppauge Fernbedienung ausgibt ja nicht sein, ATRIC konnte das ja auch problemlos samplen und dann die POWER Taste als Weckgrund erkennen.

Die Powertaste habe ich schon so jeweils so kurz gedrückt wie ich nur konnte, hat aber auch nicht geholfen.
Anlernen per irsend war auch mein erster Ansatz, aber das hatte überhaupt nicht funktioniert, darum habe ich dann noch nachträglich den Taster angelötet um überhaupt anlernen zu können.

BTW: Wenn man das LIRC Paket von Seahawk1986 installiert (https://launchpad.net/~seahawk1986-hotmail/+archive/misc -> lirc_0.9.0-16yavdr0~precise_amd64.deb) muss man dann den LIRC Patch trotztdem noch anwenden, oder ist der da bereits enthalten? Das geht aus der Doku nicht so richtig eindeutig hervor (für mich zumindest nicht).
Ich habe nämlich nur den Kernel upgedatet auf (3.8.0-32-generic) und dieses Lircpaket installiert, aber irsend steigt beim Aufruf nach ca. 3 Sekunden mit einer Timeoutmeldung aus:

irsend SEND_ONCE yaUsbIR_control C_IR 1 1 0 C_END
irsend: timeout

Von daher vermute ich mal das in dem seahawk paket der Patch noch nicht drinne ist, richtig? Oder könnte sich irsend auch mit dem ebenfalls auf meinem Intel Mainboard vorhandenen CIR beisen und das Kommando quasi an den falschen IR Port schicken?

Zitat von uwe67

Hallo humme99,

Kritisch ist immer das Anlernen. Bist du so wie in der Anleitung vorgegangen, mit Abstand (3m) lernen. Probier mal eine andere Fernbedienung aus.
Was noch helfen kann, beim Anlernen die Taste der Fernbedienung nur sehr kurz drücken.
Ich habe hier mit einer RC5 Fernbedienung (hauppauge) keine Probleme.

Gruß uwe67

Zitat von uwe67

Hallo humme99,

Kritisch ist immer das Anlernen. Bist du so wie in der Anleitung vorgegangen, mit Abstand (3m) lernen. Probier mal eine andere Fernbedienung aus.
Was noch helfen kann, beim Anlernen die Taste der Fernbedienung nur sehr kurz drücken.
Ich habe hier mit einer RC5 Fernbedienung (hauppauge) keine Probleme.

Gruß uwe67

Ich hab auch Probleme mit dem Anlernen der POWER Taste. Ich verwende auch eine RC5 Hauppauge Fernbedienung (die, die es seinerzeit bei der PVR350 oder FF-Karte bei gab).
Laut LED blinken (am Ende geht die LED kurz zweimal aus), ist die POWER Taste angelernt, aber wenn ich dann POWER drücke um zu wecken, flackert die LED nur beim Tastendruck, weckt aber den Rechner nicht.
Lerne ich spasseshalber die links neben der Powertaste liegende HOME bzw. GO Taste an, funktioniert das Wecken, d.h. die HOME Taste weckt den Rechner und mittels POWER Taste lässt er sich dann wieder per VDR runterfahren. Das ist irgendwie Suboptimal...

Die selbe Fernbedienung hatte mit dem ATRIC als WakeUp Board keinerlei Probleme gemacht, da lies sich die Taste problemlos anlernen und zum Wecken des Rechners verwenden.
BTW: Was ich auch merkwürdig finde ist, das man beim Anlernen die gleiche Taste zweimal drücken soll, wofür ist das genau gut? Wenn ich (ebenfalls Spasseshalber) testweise zwei verschiedene Tasten drücke, bekomme ich am Ende aus das zweimalige Blinken für "Anlernen OK" und kein "Error" blinken oder so.

Ich hab auch eine weitere Hauppauge Fernbedienung ausprobiert (baugleiches Model), aber auch hier lässt sich die Powertaste nicht anlernen, andere Tasten der gleichen Fernbedienung aber schon.

Ne Idee wo da das Problem mit der IR-Erkennung im yaUsbIR sein könne, bzw. wie man das debuggen/fixen könnte?

Naja, die drei Teile sind doch nur zwei Netzteile mit verschiedenen Spannungen und eine "dumme" Einspeiseweiche, richtig?
Wo ist hier der "aktive" Teil zu finden, der dann die jeweils benötigte Umschaltung zwischen 13V/18V macht?

Der SN 1418 hatte ja noch mehr als "nur" die korrekte Spannung anzulegen gemacht, das Ding war ja quasi ein Repeater:

Primarily designed as switch mode signal repeater
for example in installations where the receiver can
not supply the required current
•
The power supply recognizes the polarisation signal
(14 /18 V or DiSEqC commands) and supplies
appropriate voltages with high current reserve
•
The 22 kHz tone and DiSEqC commands as reco-
gnized by the power supply will be amplified and
super imposed onto the output voltage

Normale "dumme" Fernspeisenetzteil gibts wie Sand am mehr, aber so ein Teil ist mir zumindest nicht mehr untergekommen.

Ja, Spaun SN 1418 ist richtig.
Das war genau für sowas gedacht: (Aus der Anleitung kopiert):
"
Primär für den Einsatz als Schalt-
signal-Wiederholer konzipiert, z.B.
wenn das Receiver-Netzteil den
erforderlichen Strombedarf nicht
liefern kann.
"
Ich hatte mir den mal seinerzeit geholt weil die USB DVB-S2 Karte von TT zu schwach brüstig war, hatte seinerzeit soweit ganz gut funktioniert das Teil.
Laut Hersteller liefert das Teil max. 650 mA, bei max. 17W Leistungsaufnahme (warm wurde das Teil schon etwas).
Das Produkt wird aber schon länger nicht mehr hergestellt und ich wüsste auch keinen Händler der noch Restbestände hätte. War wohl zu Teuer und zu speziell das Teil.

Was für ein Filesystem verwendest Du den? Wenn Du neu installiert hast (und hoffentlich auch ne neuere VDR-Distri verwendest) müsstest Du doch eigentlich ext4 als
Filesystem haben, und da ist das mit den FS-Checks nicht mehr so ein großes Problem, das geht das eigentlich recht fix (ext4 fscheck war glaub ich um Faktor 2..20 schneller
als das "früher" verwendet FS ext2/3).

BTW: Einen SAT-Receiver der den nächsten Kanal in der Kanalliste einfach mal auf Verdacht bufferd gibbed wohl schon von Macrosystem mit dem DVC 3000:

http://www.macrosystem.de/file…nhalt_web_Macrosystem.pdf

In dem Test (wohl von einer Vorabversion) werden Umschaltzeiten von 0,3s beim zappen zwischen free-tv sd-sendern erwähnt.
Zappen zwischen free-tv HD-Sendern dauert wohl 0,5s. Im Worstcase kommen die wohl auf 1,6s umschaltzeigen (wenn sich die Auflösung oder Bildformat ändert).

Nur mal so zur Info, mit was für Zappingzeiten mit dem Ansatz (in eine praktischen Umsetzung) wohl zu rechnen währe.

Zitat von hepi

Ach so, und wofür brauchst Du dann die TT S2-6400 mit HDMI-Ausgang?

Lies Dir doch nochmal den Post (aus dem Du die obigen Zeilen zitierst hast) mal komplett durch, da steht warum er die S2-6400 verwendet: "Die FF ist sicherlich übermotorisiert aber nun mal vorhanden."

Zitat von nc17

Ich glaube nicht, dass das so bald passieren wird, der Vertrag mit Nagravision läuft noch bis März 2013 und ob sie es sich dann schon leisten können die S02 Karten gegen V13 zu tauschen ist eher fraglich, vor allem da dann auch ein ganzer Haufen Leihreceiver benötigt werden, da so einige kein NDS unterstützen.

Wenn überhaupt würden Sie dann wohl gegen die neue V14 tauschen, die SKY jetzt bei Neuabschluss verschickt (die hat auch ne neue CAID: 098C).
Aber ich werds erleben, hab ja selbst ne S02.

Sporadische Hänger beim Booten haben ich mit yavdr 0.x auch immer gehabt (auf verschiedenen HWs). Problem scheint häufiger aufzutreten wenn man ne schnelle SSD als Systemplatte hat, verwende ich die gleiche (per dd) geclonte Version auf ner HDD, nahm die Auftretenswahrscheinlichkeit deutlich ab. Vermutlich irgendeine eine Race condition im yavdr startup bei der Initialisierung der HW oder so, aber genaus weis ich auch nicht.

Wenn Du die Chancen erhöhen möchtest wenigsten ne Fehlermeldung auf dem Monitor zu haben, musste das ganze Bootlogo zeugs abschalten (braucht man bei nicht stabilen test&alpha yavdr versionen eh nicht, dann sind callstacks und debug ausgaben viel zielführender), also im grub die Optionen nosplash und noplymouth als Kerneloption hinzufügen.
Wenn Du einfach "nur" willst das die Kiste bei nem Kernel-Oops (durch irgend einen abgeststürzten Linux oder nvidia closed source treiber) nicht bis in alle Ewigkeit mit einem Callstack (auf dem Monitor sichtbar oder auch nicht) stehen bleibt, musst die Kerneloption "panic" mit angeben, z.b. panic=5 sorgt dafür das ein Kernel-Oops für 5s angezeigt wird und dann der Kernel automatisch nen Reset durchführt. Das hat bei mir die Wahrscheinlichkeit das eine programmierter Timer auch zu ner Aufnahme führt, drastisch erhöht (quasi auf 100% ).
Ohne diesen Parameter hatte ich immer wieder sporadische Boot Hänger und Kernel-Oopses aus z.B. dem nvidia-treiber, und dann ist die Kiste das ganze Wochenende in dieser Callstackanzeige verblieben und hat damit auch alle folgendenen Aufnahmen verpennt. Wenn das jetzt passiert, gibts halt nach 5 Sekunden automatisch nen Reset, und beim folgenden Boot ist bisher wie durch ein Wunder alles ok und yavdr startet durch.

Kann keine Probleme beim DL feststellen, der Link http://<entfernt> funktioniert (bei mir), Download läuft.

Naja, was femon anzeigt ist mit großer Vorsicht zu geniesen. Die Linux DVB-Treiber zeigen diesbezüglich schon mal merkwürdige Dinge an, auch wenn kein Signal vorhanden ist. Was zeigt den der andere "normale" Receiver an bei Signalstärke und Signalqualität? Jeweils 0%?

Meiner Erfahrung nach geht ein LNB sehr, sehr, selten kaputt (außer es hat z.B. ein defektes Gehäuse und Wasser dringt ein oder so). Ich tippe hier er viel mehr auf den Multischalter (vieleicht hats die interne Sicherung im MS durchgehauen beim Stromausfall?). Wird das Netzteil des Multischalters denn noch warm? (Oder hast Du eine Energiemeßgerät und kannst checken ob der Multischalter noch Energie verbrät?)

Ob das LNB noch tut könntest Du aber auch testen wenn Du einen der vier LNB Ausgänge direkt mit dem Receiver verbindest (musst natürlich auf ein Programm schalten das sich auch auf der gewählten Ebene befindet, sonst kommt da auch beim funktionierendem LNB nix).

Hab auch mal die 0.5 Alpha Testversion installiert und hatte mit meiner GT520 auch die oben beschriebenen Symptome.
Ändern auf "-gt 1" hat auch bei mir geholfen, damit habe ich dann auch Ton über HDMI. Allerdings auch nur wenn ich im WFE die Ausgabe auf "HDMI Stereo" stelle. Stelle ich auf "Ausgabe an allen Geräten" (Der Rechtschreibfehler steht auch so im Webfrontend, der ist ausnahmsweise nicht von mir ) bleibt HDMI stumm.

Tritt denn der Fehler denn auch auf wenn Du das "böse Plugin" nicht geladen hast?

Zitat von dron72

Hmm, habe ich auch gesehen und war auch eine meiner Überlegungen - das IMON Geraffel vom Board abzuziehen ist aber schwierig, da
1.) Die Kernel Panics nur bei ca. 10-20% der Bootvorgänge kommen, es also kein kurzer einmal-Test ist und ich es wahrscheinlich länger ab lassen müsste, um meinen Kernel wieder panisch zu machen
2.) IMON bei mir für die Fernbedienung (wichtig) und das Display (weniger Wichtig) zuständig ist - und es sich leider um meinen Produktiv VDR handelt, der standardmäßig aktuell wieder den yavdr 0.3 bootet - ohne imon ists aktuell nicht Familientauglich und
3.) IMON ja auch mit dem yavdr 0.3 funktioniert; Hardware scheint in Ordnung - ob die Module auch mit dem 64Bit Kernel tun? Zumindest gibts einige Threads zu IMON mit yavdr0.4 - und da wird nichts von Kernel Panics berichtet...

1) Diese Fehler sind IMMER nur sporadisch und schwer reproduzierbar, sonst währe es ja auch langweilig...
2) SIcher ist ein VDR ohne Fernbedienung ne blöde Sache, aber irgendwie muss man ja die Fehlerursache eingrenzen. Also entweder systematisch die Fehlermöglichkeiten ausschließen oder blind rumprobieren und lustig diverse Pakete und Biosversionen up&downgraden und hoffen das man nen Zufallstreffer landet... So ne Probleme geht halt jeder anders an. Evtl. könntest Du ja auch einen anderen IR-Empfänger bei Dir anschliessen (dein Board hat ja noch intern COM-Ports, also könnte man dort einen LIRC Empfänger als Übergangslösung anschliessen).
3) Ich gehen auch nicht von einem defekt der IMON HW-Aus, sondern eher von einer evt. Unverträglichkeit der imon-sw, verwendeter kernel version in yavdr 0.4 im zusammenhang mit deiner HW vorliegt. Hier könnte die "alte" SW aus yavdr-0.3 evtl. weniger buggy gewesen sein oder es gibt eine Racecondition beim imon-module. der erst mit der (64-Bit) 0.4 Version auffällt (weil die 0.4 schneller bootet z.B., das würde auch zu dem Symptom passen das es mit ner SSD noch häufiger auftritt)