SnowHead

@dboxulle Allein mit "grep" geht das nicht, mit ein paar extra Kommandos aber schon: wget -q -O- http://192.168.178.197/weather.json | grep humidity | cut -d'"' -f4 | sed s/^$/0/g

@waves Wie gesagt, das Einfachste wäre ein Eintrag in der auto.net in allen Boxen. Der ist selbsterklärend und schnell gemacht.

@waves User, NFS4.1 und die Domainangabe braucht man für die Verbindung zu Neutrino nicht. Da ist NFS unproblematisch aber (ohne Aktivierung der speziellen NFS-Berechtigungen) auch ziemlich unsicher und sollte in dieser Konfiguration ausschließlich im Heimnetz verwendet werden.

@waves Der NFS-Dienst auf dem NAS muß natürlich aktiviert sein: Fals es automount im Image gib, ist es am einfachsten, diesen Dienst zu starten und die Datei /etc/auto.net zu bearbeiten. Um /volume1 vom NAS nach /streaming im Automount-Verzeichnis zu mounten wäre so ein Eintrag nötig (wobei "192.168.0.1" bei mir die IP des NAS ist): streaming -fstype=nfs,nolock,async,rw,udp,rsize=32768,wsize=32768 192.168.0.1:/volume1

Unter Deiner dienstlichen IP habe ich 1314 Postings in der Datenbank gefunden. Die sind allerdings dem Gast "Vernichter" zugeordnet. Da scheint bei einem der früheren Datenbankcrashs die Verbindung zu Deinem Account verlorengegangen zu sein. Ich habe bis jetzt leider keine Möglichkeit gefunden, die Deinem Account wieder zuzuordnen und habe deshalb wenigstens erst mal Deinen Posting-Counter aktualisiert. Vielleicht schreibt ja einer der Profi-Admins ein Script, das die Postings wieder Dir zuordnet.

Der Server ist nun wieder online.

Leider ist unser Update-Server im Moment nicht erreichbar. Damit gehen Online-Update der Images und z.B. auch die Heise-News nicht mehr. Onkel Hotte wurde informiert und kann das hoffentlich wieder hinbiegen. Wir anderen haben leider keinen Zugriff auf diesen Server.

Rutscht gut rein und ein gesundes Neues!

Euch allen ein schönes Fest, einen guten Rutsch und ein gesundes neues Jahr. ... und immer schön negativ bleiben!

@stotor Beim Flashen: "boot net failed", der Klassiker. Mal diese Punkte prüfen. Ein serielles Bootlog von einem normalen Startversuch der Box wäre auch mal interessant.

Dumm gelaufen. Wer sowas gegen Geld macht gehört auch eingesperrt.

Ein weiterer Grund war und ist aber auch, daß vor dem Posten einer Frage nicht wenigstens mal grob geschaut wurde, ob diese oder eine ähnliche Frage nicht vielleicht doch schon ein oder mehrere Male gestellt und auch beantwortet wurde. Der Ablauf war dann: Registrieren -> Fragen -> Antwort lesen -> Verschwinden auf Nimmerwiedersehen ohne wenigstens Danke zu sagen oder das Ergebnis der angewandten Antwort mitzuteilen Diese Woche stellt sicher, daß es dem neuen Mitglied auch ernst ist und er nicht nur ein Ein-Posting-Wunder ist.

Ich habe für Übersetzungen für eigene Projekte gute Erfahrungen mit crowdin gemacht. Man muß dann halt nur die richtigen Leute dazu einladen, damit das nicht alles an Einem hängenbleibt. Welche anderen Sprachen noch sinnvoll wären, kann ich nicht einschätzen da ich die Verbreitung des KW-Images nicht so genau kenne.

@Mr.Servo Du kannst davon ausgehen, daß Einträge, die im Leitwolf nicht mehr drin sind wohl aber in anderen locales, nicht mehr benötigt werden. Leerstrings zu füllen kann schiefgehen, wenn die z.B. aus Platzgründen weggelassen wurden. Dann könnte es eng werden mit extra Texten. Die roten Übersetzungen kann man im Prinzip si stehen lassen, nur halt "Info 2" groß und getrennt schreiben. In der Empfehlung von thomasrichter könnte man ggf. "Bookmark" noch durch "Lesezeichen" ersetzen. Wenn sich nicht aus Symbol- oder übersetzem Text ablesen läßt, wo ein Eintrag verwendet wird, kommt man ohne Analyse der Quelltexte nicht weiter. Dazu muß man das Neutrino nicht einmal bauen sondern nur auschecken und mit Eclipse untersuchen. Damit kann man sehr einfach rückverfolgen, in welchen Menüs und Listen die jeweiligen symbolischen Konstanten verwendet werden (und ob überhaupt).

@Mr.Servo Leitwolf ist tatsächlich die english.locale. Diese muß der Imagebauer pflegen und konsistent halten. Fehlt ein Keywort in einer anderssprachigen locale, nimmt Neutrino die zugehörige Übersetzung aus der english.locale. Fehlt das Keywort dort auch, wird statt der Übersetzung das Keywort selbst angezeigt. Deshalb wurden aus Faulheit vermutlich einige Einträge in anderssprachigen locales, die unverändert gegenüber der english.locale sind (z.B. Leerstrings), einfach weggelassen. Ich weiß aber nicht, wieviele solcher Fehleinträge Neutrino insgesamt ausgleichen kann. Ein Leerstring für ein Keywort ist legitim und meistens auch gewollt. Wenn in der aktuellen english.locale Keywörter weggefallen sind und im OSD diese weggefallenen nirgends unübersetzt auftauchen, werden die im aktuellen Image nicht mehr benötigt. Wie gesagt, solange die english.locale vollständig ist tauchen im OSD keine unübersetzten Keywörter auf. Sind auch die anderssprachigen locales konsistent zur english.locale dürften dann auch keine defaultmäßig englisch übersetzten Ausgaben mehr auftauchen.

@Mr.Servo Eigentlich werden die Images und Plugins am einfachsten gleich unter Linux gebaut. Da kommt man nicht in die Verlegenheit, die Zeilenenden einer Linux-Datei (LF) aus Versehen automatisch durch Windows-Zeilenenden (CR+LF) ersetzen zu lassen. Da passiert unter Windows häufiger als man denkt. Als Entwicklungsumgebung unter Linux ist Eclipse sehr gut. Das kann man für die verschiedensten Entwicklungsumgebungen und Compiler anpassen und viele Automatikfunktionen des eingebauten Editors (z.B. automatische Formatierung mit Klammern und Einrückungen) nutzen. Unter Windows verwende ich (wenn erforderlich) den freien Editor Notepad++, den kann man fest auf Linux-Format einstellen. Als FTP-Client verwende ich WinSCP oder den Total Commander. Wichtig bei beiden ist, das Dateiformat für den Transfer keinesfalls auf "Text" oder "Automatisch" zu stellen, dabei gehen viele Linux-Dateien kaputt. Immer das Format "Binär" einstellen.

@Mr.Servo Mach es nicht zu kompliziert. Nicht daß Du mehr Aufwand in die Sache steckst, als eine manuelle Anpassung der paar Textdateien machen würde. Die Quellen des KW-Images sind selbstverständlich nicht öffentlich zugänglich. Wenn Du Dich mit Markham abstimmst, schickt er Dir kurz vor Fertigstellung der nächsten Imageversion sicher gern die deutsch.locale des KW-Images zur Erzeugung der restlichen Sprachdateien. Inzwischen kannst Du ja mit den aktuellen üben und zum Test mal eine italienische oder französische locale erstellen.

@Mr.Servo Ich habe die locale-Beiträge mal in einem neuen Thema zusammengefaßt. Wenn sich, wie Du schreibst englische und deutsche locale in der Zeilanzahl unterscheiden, stimmt irgendwas nicht. Entsprechend dem Verarbeitungsprinzip der locales in den Images müßten die exakt gleich viel Einträge haben. Als Basis für die Ableitung der locales für andere Sprachen ist nach wie vor die deutsch.locale vom Imagebauer vorzuziehen. Die enthält genau die Anzahl Einträge, die das neue Image benötigt. Nicht mehr und nicht weniger. Ausßer den zusätzlichen KW-spezifischen Einträgen muß sie nicht unbedingt mit der im git verfügbaren übereinstimmen, da die sich ja im Vergleich zum Stand des Images beim Auschecken durch den Imagebauer inzwischen ja schon wieder geändert haben kann (und damit nicht mehr zum mit dem Checkout gebauten Image passen würde). Die locales für andere Sprachen (außer englisch, die Markham in der Regel auch schon selbst mit baut (aber sicher auch gern abgeben würde) müßten beim ersten Mal komplett neu aufgebaut werden inklusive der Übersetzungen- Dazu könnten aber als Hilfsmittel die locale anderer Sprachen herangezogen werden, um dort die zu den symbolischen Konstanten gehörenden Übersetzungen herauszuholen und in die eigenen locales einzufügen. Die KW-spezifischen Symbole müßten natürlich mit eigenen Übersetzungen versehen werden. Für spätere Imageversionen müßten dann nur die, wie schon empfohlen, mit Diff gefundenen Änderungen in die bisherigen locales eingepflegt werden.

@Mr.Servo Ich verstehe den Begriff "Maximalliste" nicht. Übersetzungen für alles denkbare und eine Liste mit allen vorstellbaren symbolischen Bezeichnern kann kann es ja noch nicht geben. Im Prinzip ist die z.B. deutsch.locale der jeweils aktuellen Imageversion ja so eine Maximalliste. Die deutsch.locale der gerade in Arbeit befindlichen Imageversion wird ja in der Regel vom Imagebauer erstellt, da nur er weiß, welche symbolischen Konstanten er einfügen oder löschen will. Wenn Du diese neueste locale vom Imagebauer bekommst, kannst Du die mit "diff" gegen die vorherige vergleichen und bekommst sofort angezeigt, welche Zeilen hinzugekommen, weggefallen oder verändert wurden. Nur diese Differenzen müßten dann (natürlich nach Übersetzung der neuen Klartextstrings) in die bestehenden ausländischen locale übernommen werden um sie auf den aktuellen Stand zu bringen. Das würde in meinen Augen den geringsten Aufwand bedeuten. Wenn Du das automatisieren willst, kannst Du ja die Ausgabe von diff per Script analysieren und daraus die Handlungsanweisungen für die anderen locales erzeugen.

Hier liegt ein Mißverständnis vor. Mit dem "Bootloader" hat das gar nichts zu tun. Der ist ein extra geschützer Bereich im Flash, aus welchem beim Start die Routinen aufgerufen werden, welche die erste Hardwareinitialisierung vornehmen und dann das eigentliche Betriebsystem laden. Um auch beim Flashen nicht kaputtgemacht zu werden und so immer eine Möglichkeit zu bieten, auch bei kaputtem Betriebssystem zumindest wieder ein neues Flashen zu können, ist der besonders schreibgeschützt. Wovon hier die Rede war, ist das "Bootlog". Das ist die Ausgabe von Debuginformationen beim Systemstart und -betrieb über die serielle Schnittstelle. Die ist bei den meisten Boxen nicht mehr direkt herausgeführt, sodaß man meist über einen USB<->TTL-Umsetzer von einem internen Stecker in der Box auf den PC verbinden muß, um dieses Log in einem Terrminal auf dem PC anschauen zu können. Mit diesem Log kann man Fehler und Probleme beim Starten gut identifizieren. Um aber mal zu schauen, welche locales Neutrino anmeckert, ist aber nicht mal solch ein Umsetzer nötig. Hier genügt Telnet. Gibt man (nachdem Neutrino auf der Box gestertet ist) in der dann zu öffnenden Telnet-Verbindung vom PC "setconsole" ein, bewirkt dieser nette Befehl, daß die Daten, die bisher auf der seriellen Schnittstelle ausgegeben wurden, nun auf die Telnet-Sitzung umgeleitet werden. Startet man nämlich Neutrino nach "setconsole" über das Service-Menü neu, kann man alle von Neutrino beim Start ausgegebenen Debugmeldungen (einschließlich des eventuellen Gemeckers über nicht passende locale) nun im Telnet verfolgen. Um herauszufinden, was sich von der vorigen zur aktuellen locale geändert hat, kann man beide Dateien mit der Diff-Funktion verschiedenster Editoren oder auch gleich mit dem diff der Box untersuchen. Hier mal testhalber der Vergleich mit dem Diff der Box via Telnet zwischen zwei locales, bei welchem bei der neuen zwei Zeilen hinzugekommen sind (die sind am Anfang mit einem "+" gekennzeichnet: # diff -aBt /tmp/deutsch_alt.locale /share/tuxbox/neutrino/locale/deutsch.locale --- /tmp/deutsch_alt.locale +++ /share/tuxbox/neutrino/locale/deutsch.locale @@ -943,6 +943,7 @@ kw.camd_upd_menu Camd/Cardserver-Update Men kw.cardserver_menu Cardserver Men kw.cardserver_reset Cardserver Reset +kw.channellist_spec Nachfolgesendung (fest) kw.flash_reboot rebooting ... kw.flash_save_settings Aktuelle Settings bernehmen ? kw.flash_saving bernehme Settings @@ -964,6 +965,7 @@ kw.infobar_camd_show Camd-Status anzeigen kw.infobar_ci_show CI-Modul-Status anzeigen kw.infobar_cs_show Cardslot-Status anzeigen +kw.infobar_cw_show CW-Quelle anzeigen kw.infobar_ip_show Sharing-IP anzeigen kw.infobar_mails_show Info ber neue Mails kw.infobar_res_got empfangen

Die Plugins tuxwetter, msgbox, input und shellexec wurden damals im KW-Board für die DBox2 entwickelt, um aus Scripten auf die von diesen Tools angebotenen Funktionen zugreifen zu können. Damals war es noch nicht möglich, eine .so von der Kommandozeile zu starten (das ging nur über ein spezielles weiteres Tool, welches aber die weitere Nutzung durch ein Script nicht zuließ). Deshalb sind diese Tools reine Binaries ohne .so. Nachdem diese von uns ins git gelangten, konnte sich jeder Imageschnitzer seine eigene Version bauen und einige meinten wohl, daß z.B. die shellexec gleich als Shellstarter ausgeführt werden solle, welche zu dem Zeitpunkt auch schon über die Konsole gestartet werden konnten, um das gleichzeitige Vorhandensein von "shellexec" und "shellexec.so" zu vermeiden. Warum auch immer. Die Pfade im KW-Image und den anderen sind historisch so gewachsen. Daß das mal vereinheitlicht werden könnte, glaube ich nicht.. Den Imagenamen kann man in jedem vernünftig gepflegten Image über "cat /.version | grep imagename | cut -d'=' -f2" abfragen.

@Mr.Servo Du hast mein Post oben leider nicht korrekt gelesen. Der Aufruf im Script muß "shellexec" ohne ".so" und ohne Pfadangabe lauten. Wie gesagt, ist die shellexec.so nur ein Shellstarter, welcher die shellexec ohne Übernahme von Parametern mit der standardmäßigen config, also dem KW-Menü startet. Der Aufruf muß lauten "shellexec /tmp/bundesland.conf > /dev/null" So hatte ich das im Script geändert und so lief das bei mir auch. Edit: Da war Markham ein paar Sekunden schneller

@Zapt Ja, 16 Jahre seit dem Tuxwetter-Script und 6 Jahre seit Deinem letzten Posting. ;-b

@Mr.Servo Ist im Prinzip richtig. Um aber einen Eintrag für eine Änderung schnell wiederzufinden (auch der Neutrinobauer muß ja wissen, wie die symbolische Konstante heißt) sollte der erste Teil der Zeile schon besser mit der Symbolliste in den Quellen übereinstimmen. Da Markham die Images für die verschiedenen Boxen aus den gleichen Quellen baut, wird in der Regel eine Version der locales je Imagerelease gebraucht. Da die Sprachen aber auch nachträglich online nachrüstbar sind, könnte man z.B. auch schon mit dem aktuellen Image anfangen. ;-)

@Mr.Servo Ich habe das Plugin mal nach /tmp gepackt, die drei shellexec-Aufrufe angepaßt und ganz oben "set -x" zum Aktivieren der Debugausgabe aingefügt. Scripte, welche msgbox, shellexec oder input verwenden, können nicht über die Konsole aufgerufen werden., da sich sonst Script und Neutrino gleichzeitig um die Fernbedienungseingaben und den Framebuffer für die Grafikausgabe prügeln. Das geht schief. Solche Scripte immer aus Neutrino heraus aufrufen. Im KW-Image genügt dazu eine zusätzliche Zeile in "/var/tuxbox/config/flexinc/my_plugin_run.mnu". Für mein Beispiel in der Form ACTION=§Vodafone,/tmp/vodafone.sh Dann kann das aus dem KW-Menü heraus aufgerufen werden. Um zu sehen, was es tut, öffnet man eine Telnet-Konsole und gibt dort ein "setconsole". Nun werden alle Ausgaben von Neutrino und von Scripten im Telnet mitgeloggt. Bei mir sah das dann so aus: und brachte diese Bildschirmausgaben: