Posts by JoergZ

    llutz

    Quote

    Wenn dein Router (bzw. dessen DHCP-Server) Dinge anders macht, als du konfiguriert hast, solltest du über die Wahl des Routers bzw. dessen Software nachdenken.


    Mhm, davon habe ich nicht geredet und weiß auch nicht, ob meine Router sich so verhalten würden - sie bekommen keine Gelegenheit dazu. Mein Faible für direkt an die Geräte vergebenen festen IPs kommt u. a. auch daher, dass gerade z. B. Raspberry Pis mit festen IPs und deaktiviertem dhcpcd deutlich schneller booten. Offensichtlich braucht der Ruf nach Zuteilung einer Adresse ziemlich Zeit. Und daran ändert das Router orientierte Verfahren (statisches DHCP) nichts. Das bedeutet ja nur, dass der Router immer dieselbe Antwort an dasselbe Gerät gibt. Und über einen Routercrash oder ein Hardwareupdate brauche ich mir auch keine Gedanken zu machen. Und überhaupt: in dieser Frage soll jeder nach seiner Facon selig werden. :-)

    Gruß

    Jörg

    Verstehe... Es ist vielleicht eine Glaubensangelegenheit: Ich vertraue nur festen IPs, die ich selbst vergeben habe und die in dem Gerät selbst (und eben nicht im Router) verankert ist. Mit dem übrigen Rest soll der Router machen, was er will. Die Zuweisung derselben IP an ein bekanntes Gerät überlässt es immer noch dem Router diese Regel einzuhalten. Ich meine auch festgestellt zu haben, dass es schwer ist, eine solche IP dem Router wieder abzugewöhnen. Kann es nicht sein, dass nun folgendes passiert: Du hast deinem Router ein Gerät als "immer dieselbe IP" angemeldet. Der Router identifiziert ja nun das Gerät über die MAC-Adresse. Die bleibt immer gleich, egal was du als Firmware-Konfiguration draufflasht. Also bekommt dein Gerät immer wieder die irgendwann mal zugewiesene IP. Ich gebe zu, das ist (sehr) spekulativ, aber vielleicht nicht ganz unmöglich. Wenn du die Firmware so deutlich als Verursacher ausschließt, müsste es an den anderen Komponenten liegen.

    Gruß

    Jörg

    Normalerweise nicht. Ich kenne nur Atom als Flash-Tool. Läuft denn der Flashvorgang ohne Fehlermeldung durch? Ist die feste IP tatsächlich verfügbar und stammt sie aus einem Bereich, der in deinem Router für die Vergabe durch DHCP gesperrt ist? Noch eine Nachfrage zu deinem Beitrag #3: Was meinst du mit statischem DHCP?! Das ist ein Widerspruch in sich. Das D steht für dynamic, was in diesem Fall das Gegenteil von static ist. Kannst du mal deine ganze user_config.h posten?

    Gruß

    Jörg

    dbv

    Ein gutes Tasmota-Forum findest du hier: http://forum.creationx.de/forum/

    Eine Lösung könnte sein, dass du in der user_config.h den Wert des CFG_HOLDER nicht geändert hast. Den musst du bei jedem erneuten flashen mindestens um 1 erhöhen, sonst werden bestimmte Einstellungen nicht überschrieben.

    Ich habe ein Skript programmiert, das du auf einem Raspi installieren kannst. Das sucht nach Tasmota-Geräten und anschließend kannst du bestimmte Einstellungen verändern, z. B. die IP. Mehr Infos hier:

    http://forum.creationx.de/foru…finden-und-konfigurieren/

    Gruß

    Jörg

    Der_Micha
    Wenn ich dich richtig verstehe, hast du eine MPD-Installation als Service (MPD startet nach boot automatisch, mpd.conf liegt in /etc), willst aber auf Playlisten und Musikdateien in der /home/pi Umgebung zurückgreifen. Ich glaube du fährst besser, wenn du entweder MPD auf Benutzerebene installierst (dann liegt eh alles im Pfad /home/pi/... oder du lässt es bei einer sauberen Service-Installation und legst im Verzeichnis /var/lib/mpd/music einen symbolischen Link auf dein Musikverzeichnis im home-Pfad an. In der mpd.conf aktiviere dann die Zeile, die das Verfolgen symbolischer Links erlaubt (follow_inside_symlinks). Anschließend mpc update. Vielleicht hilft auch dieser Hinweis aus der mpc Manpage:

    Code
    add <file>
                 Adds a song from the music database to the playlist. Can also read  input
                 from pipes. Use "mpc ls | mpc add" to add all files to the playlist.


    Demnach müsste eine Angabe wie

    Code
    mpc ls /home/pi/Musik/noch_Verzeichnis/ | mpc add

    den von dir gewünschten Zweck erfüllen.
    Bei mir ist MPD als Service installiert und ich arbeite mit symbolischen Links auf mein NAS und andere Verzeichnisse. Das klappt problemlos.
    Noch ein Aspekt: Wie viele "Dateien" werden denn bei dir hinzugefügt? Vielleicht ist die Menge zu groß, dass es deshalb einen timeout error gibt? Denn eigentlich haben Rechte nichts mit Timeout zu tun. Ein Rechtefehler müsste sofort angezeigt werden oder es passiert schlicht gar nichts.
    Gruß
    Jörg

    Hallo Multimedia-Spezis,
    folgendes Problem treibt mich um:
    Wenn ich in einem LAN/WLAN (Bluetooth geht wegen räumlicher Ausdehnung nicht) einen Raspi mit MPD als Soundserver (Output HTTP) betreibe und in verschiedenen Räumen Raspis mit MPD als Clients einsetze, so kann ich wunderbar in den Räumen die Musik hören, die der Server aussendet. Wenn ich eine andere Musik hören möchte, verbinde ich mich mit einem der vielen möglichen Programme wie MPC/NCMPC, SSH, Android-Apps,... mit dem Server, wähle ein anderes Internet-Radio oder meine DLNA-Musikserver und höre etwas anderes. Soweit so gut, läuft auch alles.
    Wenn ich allerdings die Lautstärke ändern will, muss ich mich immer mit dem jeweiligen Client verbinden, um dort die Lautstärke zu ändern. Meine Frage nun: Gibt es eine Möglichkeit die "Lautstärke" des Streams zu ändern (ich weiß, dass es problematisch sein kann, wenn dieser Parameter am Server beeinflusst wird :-) ) oder brauche ich dazu eine andere Serversoftware (und kann ich mit der dann auch mein Musikprogramm ändern)?
    Unterm Strich geht es mir darum, dass ich mit nur einem Programm/App/Schnittstelle sowohl den Server als auch den Client bedienen kann bzw. die "Sender"auswahl und die Lautstärkeregelung am Soundserver vornehmen kann. Gibt es so etwas oder bich grundsätzlich auf dem Holzweg?
    Gruß
    Jörg

    Hallo TaToosh,
    hab Karfreitag und heute mal mit Buildroot ein neues System mit mpd gebaut. Auf einem Pi 3 dauert es nun nach dem Einschalten 12,6 Sekunden bis der erste Ton kommt, bei einem reboot sind es sogar nur 8,8 Sekunden - ein paar Sekunden dauert es offensichtlich nach dem Einschalten des Stroms bis die Stromversorgung stabil ist und dann erst der Kernel geladen wird. Deshalb geht der reboot vermutlich fixer vonstatten.
    Das System ist noch nicht weiter optimiert, es nutzt zur Zeit noch DHCP für die IP-Numernvergabe. Mit fester IP lässt sich sicher noch einmal ein Sekündchen einsparen. Muss ich erst noch testen.
    Der Pi Zero wird vermutlich nicht so flott sein können, weil sein Prozessor nicht so leistungsfähig ist wie der im Pi 3.


    Zu deinen Fragen

    Quote

    Du nutzt aktuell Jessie light - schwanken hier deine Boot Werte immer noch?


    In den letzten Tagen nicht mehr so stark. Ich weiß allerdings nicht, woran es liegt. Habe den Eindruck, dass nach einem Update es ein paar Bootvorgänge braucht, bis sich das System selbst optimiert hat - aber vielleicht ist das nur Voodoo ;-)


    Quote

    Unter Arch ist die Bootzeit deutlich besser gewesen


    Das ist gut möglich. Archlinuxarm bzw. Archlinux ist schon interessant, vor allem aktueller als Debian/Raspbian. Gutes Wiki in deutsch und englisch. Habe auch ein paar Projekte mit Archlinuxarm gemacht, war aber von Jessie lite dann so angetan, dass ich alle laufende System (zwei Radios, ein Videorecorder) alle auf Jessie lite aufgebaut habe.


    Quote

    War das Basteln der Buildroot Umgebung zeitaufwendig?


    Jein. Mein Hostsystem ist auf einem i7, 4700 irgendwas-Generation mit 16 GB Arbeitsspeicher und Ubuntu 16.04 LTS. Beim ersten Mal dauert es immer lang, weil alle erforderlichen Quellcodes aus dem Internet gezogen werden müssen. Ich wohne auf dem Land, da ist die Bandbreite schon ein Thema :-( .
    Das reine Kompilieren braucht bei mir rund 20 Minuten. Hier können eben alle 8 (virtuellen) Kerne des Prozessors beschäftigt werden, der Prozessorlüfter rauscht dann ein wenig - und das ist gut so :-) . Wenn der Prozessor auf deinem Host-System aus einer anderen Klasse ist, z. B. i3 oder Pentium, dauert auch das Kompilieren länger, weil weniger Kerne zur Verfügung stehen.


    Für den Systembau empfehle ich dir schrittweise vorzugehen. Mach als erstes eine Kompilation mit den integrierten Standard-Konfigurationen. Hier ist beschrieben, wie du an die Vorkonfigurationen kommst:
    http://ltekieli.com/buildroot-…ry-pi-what-where-and-how/
    und
    https://www.raspberrypi.org/forums/viewtopic.php?f=75&t=89518


    In der Standardkonfiguration ist der SSH-Server bereits integriert. Du musst allerdings im Buildroot-Konfigurationssystem auch bei einer Standardkonfiguration ein root-Passwort setzen, sonst kommst du nicht rein.
    Wenn das System im Grundsatz läuft, kannst du anfangen, weitere Software-Packages (z. B. MPD und MPC, Alsa-Subsystem und -Tools, etc.) durch neue Buildroot-Konfigurationen nachzuinstallieren.


    Wichtig: Mach nach jedem (außer beim allerersten Mal) "make menuconfig" zunächst erst einmal ein "make clean" und dann erst wieder ein neues ein "make" (Den Parameter -j, der irgendwo zur Benutzung empfohlen wird. lass' besser weg.) Das "make clean" schreddert zwar alle bisherigen Kompilationen und alles muss neu kompiliert werden. Aber meine Erfahrung ist es, dass ein neues make ohne vorheriges make clean in der Regel nicht (stabil) läuft.
    Hier noch ein paar Links zu Buildroot:
    http://cellux.github.io/articl…ux-with-buildroot-part-1/


    und http://cellux.github.io/articl…ux-with-buildroot-part-2/ sowie http://www.elektronikpraxis.vo…ntierung/articles/173855/


    Versuch's einfach mal. Good luck!

    Hallo tatoosh, wie lange dauert es denn bis zum login Prompt, bzw. bis der SSH-Server läuft nach dem Einschalten des Stroms? Im DietPi-Forum habe ich eine Vergleichstabelle mit Jessie Lite gefunden, laut der ein Pi 2 14,1 Sekunden braucht bis zum login Prompt. Dauert es wirklich so lang?

    Bei mir gibt es keinen neuen Stand, wobei ich das Projekt nicht weiter verfolgt habe. Vor ein paar Wochen habe ich versucht, einen Kernel bzw. System für einen Raspberry Pi 3 zu bauen. Das lief aber aus nicht näher ermittelten Gründen weder besonders schnell und vor allem leider nicht stabil. Inzwischen habe ich ein Radio mit einer aktuellen Jessie lite Version auf einem Raspberry Pi 3 aufgesetzt. Der Vorteil ist, dass alles, was man braucht vorhanden ist bzw. in den entsprechenden Installationspaketen bereit gestellt wird. Der Nachteil: es wird auch jede Menge mit installiert (und gestartet) , was man nicht braucht. Das System ist dann aus dem Stand relativ flott, wobei ich mit fester IP für WLAN0 arbeite und das gesamte Netzwerk über systemd-Methoden starte. Gute Beschreibung dazu (Variante 5!) hier: http://www.elektronik-kompendi…/raspberry-pi/1912151.htm. Da mein Ausgangsziel nach wie vor ist, ein möglichst schnell startendes Radio zu haben, werde ich versuche, das weiter zu optimieren. Allerdings scheint es Aspekte zu geben, die man nicht steuern kann. So habe ich z. B. festgestellt, dass die Kernel-Ladezeiten um bis zu 3 Sekunden schwanken (zwischen 2,555 und 6,549 Sekunden). Das allein bedeutet eine entsprechend lange Verzögerung für das Abspielen des ersten Tones. Auch gibt es manchmal das Problem, dass MPD schon läuft, während das ALSA-Subsystem noch nicht bereit ist. Ich konzentriere mich zur Zeit eher auf diese Fehlerbeseitigung und Optimierungen.

    Hier ein Hinweis für alle, die eine aktuellere Version als 19.1 von MPD benutzen wollen. Die in Raspbian verwendete Version hat ein paar Bugs, z. B. mit dem Abspielen einiger Internet Radio Streams. Die nachfolgenden Informationen stammen von der Volumio-Website (https://volumio.org/forum/mpd-update-available-t3200.html). Da Volumio auf Raspian basiert, kann man das deb-Paket verwenden.


    Und so geht's:

    Code
    wget http://repo.volumio.org/Packages/Mpd/mpd_0.19.9-2_armhf.deb
    sudo dpkg -i mpd_0.19.9-2_armhf.deb
    sudo apt-get -f install


    Danach ein reboot und mpd läuft in der Version 19.9

    Nach meinen Recherchen fallen die QoS Einstellungen auf der FB 7272 unter den Punkt Priorisierung (von Anwendungen und Geräten). Beides habe ich für den Raspi und alle Anwendungen eingestellt, die FB natürlich neu gestartet. Das hat alles nichts gebracht. Nur wenn der Parameter IPQoS 0x00 in der sshd_config gesetzt ist, kann ich über WLAN (ohne LAN) per SSH auf das Gerät zugreifen. Ich kann auch den Zusammenhang nicht ganz nachvollziehen, weil die Priorisierung in den FB Einstellungen nur die Kommunikation mit dem Internet betrifft, aber wohl keine Auswirkung auf das Gerät oder das Heimnetz hat. Denn die Kommunikation des Raspi mit dem Internet war nie gestört. MPD hat nach einem reboot immer zuverlässig die zuletzt eingestellte Internetradiostation abgerufen. Auch die Überprüfung mit nmap, ob der Raspi überhaupt im Netz ist, liefert immer das Ergebnis, dass das Gerät am Netz ist. Sogar die Systeminformationen (nmap -O IP) oder das Abklopfen der höheren Ports (z. B. von MPD Port 6600: nmap -p 6000-7000 IP) über lieferte immer die erwarteten Ergebnisse. Es war ausschließlich das Login mit SSH betroffen, sodass das Problem doch wohl eher beim Raspi selbst bzw. beim SSH-Server liegt. Es bleibt doch merkwürdig, dass wenn ein Netzwerkkabel angeschlossen ist, auch wenn man die LAN-Schnittstelle nicht für das SSH-Login benutzt, der WLAN Login möglich ist. Das deutet doch auch darauf hin, dass das Problem beim Gerät liegt und nicht beim Router, oder?

    Fritzbox 7272 (UI). Ich konfiguriere meine Raspis immer mit festen IPs, weil sie dann deutlich schneller booten. In diesem Fall über dhcpcd.conf und wpa_supplicant. Zwischendurch hatte ich, um irgendwelche Konfigurationsfehler des Interfaces auszuschließen auf DHCP zurückgegriffen. Das hat aber keine Lösung gebracht. Und ja: Ich habe den Thread zu sehr diagonal gelesen ;-)

    Hallo A350XWB,
    ich habe auch all das durchexerziert, was du gemacht hast. Nur das hat die Lösung gebracht (Quelle: https://expresshosting.net/ssh-hanging-authentication/:


    Öffne als root die Datei /etc/ssh/sshd_config und füge als letzte Zeile dies ein:

    Code
    IPQoS 0x00

    Danach entweder den ssh.service neu starten mit

    Code
    sudo systemctl restart ssh.service


    oder

    Code
    sudo reboot

    Netzwerkkabel vor dem Beginn des Reboot abziehen und über die WLAN-IP deines Raspis mit dem SSH-Clienten deiner Wahl einloggen. Hat bei mir (Raspi 3, Jessie lite Version vom 25.11.2016 also alles mit systemd-Funktionen) funktioniert. Ich hoffe, es funktioniert auch bei dir. Den Link, den ich oben angegeben habe, fand ich im Forum von raspberrypi.org ziemlich weit unten in dem Feed (https://www.raspberrypi.org/fo…wlan0+wlan0+sshd#p1085534).
    Good luck!

    Hallo MPD-Spezis und User,
    folgendes Problem:
    MPD startet auf meinem Pi 3 nicht automatisch nach einem Reboot bzw. dem Einschalten. [Ich habe mehrere Pi 2 im Einsatz unter Jessie bzw. Arch, die laufen wunderbar.] Das automatische Abspielen des zuletzt gewählten Senders funktioniert jedoch, wenn ich einen

    Code
    sudo systemctl restart mpd

    ausführe.
    Die Auswertung des log-files unmittelbar nach einem reboot hat folgenden Inhalt:

    Code
    Dec 30 13:39 : zeroconf: No global port, disabling zeroconf
    Dec 30 13:39 : state_file: Loading state file /var/lib/mpd/state
    Dec 30 13:39 : playlist: queue song 1:"http://dradio_mp3_dkultur_m.akacast.akamaistream.net/7/530/142684/v1/gnl.akacast.akamaistream.net/dradio_mp3_dkultur_m"
    Dec 30 13:39 : curl: curl failed: Could not resolve host: dradio_mp3_dlf_m.akacast.akamaistream.net
    Dec 30 13:39 : player: played "http://dradio_mp3_dlf_m.akacast.akamaistream.net/7/249/142684/v1/gnl.akacast.akamaistream.net/dradio_mp3_dlf_m"
    Dec 30 13:39 : playlist: stop

    .
    Es scheint also mit der Netzwerkverbindung zusammenzuhängen, weil das curl-Modul die Webadresse des Senders nicht auflösen kann. Meine bisherigen Versuche, den MPD-Start zu verzögern oder über die rc.local einen reload des Daemon zu veranlassen haben alle keinen Erfolg gehabt. Nur "von Hand" bekomme ich MPD mit dem zuletzt gewählten Sender an den Start. Hat jemand eine Erklärung für das Phänomen? Stimmt meine Vermutung, dass nach dem reboot MPD schneller startet als dass die Netzwerkanbindung steht? Hat jemand eine Idee dazu?

    Hallo Plato1975, kannst du bitte beschreiben was du (anders) gemacht hast. Ich kämpfe nämlich auch mit einem TT S2-4600 und bekomme ihn weder unter Ubuntu 15.04 noch unter Archlinux und auch nicht mit Raspbian ans laufen. Kanäle werden zwar (teilweise) erkannt aber nicht abgespielt bzw. nicht die HD-Kanäle.
    Gruß
    Jörg

    Nachtrag 1:
    Problem 2 ist insofern gelöst, dass Buildroot auch bei Deaktivierung von dhcp einen Link /etc/resolv.conf -> /tmp/resolv.conf stehen lässt. Die /tmp/resolv.conf ist aber leer, weil dhcp abgeschaltet ist. Zur Zeit habe ich eine feste /etc/resolv.conf angelegt mit der Adresse meines Gateways. Innerhalb von Buildroot gibt es aber wohl die Skeleton Funktion, mit der ein rootfs angelegt wird, das vor der Übertragung auf die SD-Karte bearbeitet werden kann. Damit wird sich vermutlich auch mein Problem 1) lösen lassen.

    Danke für den Hinweis auf die Alternative. Es ist mir nun mit meinen Werkzeugen gelungen:
    Es empfiehlt sich offensichtlich bei der Arbeit mit Buildroot nach ein paar Konfigurationsänderungen zunächst ein make clean vor einem erneuten make durchzuführen. Das verlängert zwar den Prozess der Erstellung eines neuen Kernels und Rootfilesystems deutlich, weil alle Paket neu geschrieben werden. Aber auf einem I7 als cross-compiler kann man damit leben.


    Im Ergebnis habe ich nun ein System, dass mir nach dem Einschalten bei einer DHCP-Konfiguration nach 8 Sekunden den ersten Ton liefert und bei einer festen IP sogar bereits nach 4,8 Sekunden. Das ist besser als erwartet!
    Noch zu lösende Probleme (für die Buildroot -Interessierten (und -Kenner):


    1) das Kernelmodul für snd_bcm2835 (der Soundchip) wird nicht automatisch geladen. Ich habe nun im MPD-Startskript /etc/init.d/S95mpd eine Zeile eingefügt, die das Modul mit modprobe snd_bcm2835 als erstes lädt.
    2) Wenn ich eine feste IP vergebe, kann ich mit MPD nicht mehr auf Internetstreams zugreifen, obwohl Gateway und Nameserver definiert sind. Merkwürdig...
    Das erste hängt vermutlich mit Buildroot zusammen das Zweite vielleicht eher mit der mpd.conf.
    Was das Eingangsproblem betriift, markiere ich diesen Thread mal als gelöst.
    Jörg