NewTron-Radio: Auflösungsunabhängiges Tron-Radio


  • habe ich gemacht, der Fehler in der Kondole ist bisher nicht wieder aufgetreten.

    Aber die angeblichen fehlerhaften m3u liest er immer noch nicht.
    Playlist anklicken, nix, mpd connectet ca. nach 10 Sekunden, nach ca. 25 Sekunden spielt die voherige m3u.

    Vorherige Versionen haben aber genau diese (m3u) gelesen. Noch etwas was mich an einen Fehler in der m3u zweifeln lässt, die Dateien werden mit einen Neustart eingelesen und ich kann ganz normal darauf zugreifen.


    Das Einlesen geschieht durch mpd. Und der mpd stellt dem Radio die Liste per mpc.listplaylists() zur Verfügung.
    Du kannst ja mal die Schritte auf der Kommandozeile nachvollziehen.

    mpc lsplaylists

    mpc load <file>

    mpc play [<position>]

    Was du auch noch probieren kannst, ist, sort_playlists auf False (Zeile 80) zu setzen. Wenn es dann geht, hast Du möglicherweise Probleme mit Umlauten (UTF-8)

    Einmal editiert, zuletzt von veloci (14. Februar 2016 um 18:28)

  • NewTron-Radio: Auflösungsunabhängiges Tron-Radio? Schau mal ob du hier fündig wirst!

  • mmh,
    hat nichts gebracht im Skript die Sortierung abzuschalten.
    Wenn ich mit < mpc load xyz.m3u > lade, dann passiert das Gleiche was ich schon beschrieben habe, in der Konsole zeigt mir Linux das irgendwas , was weis ich nicht, passiert wenn es auf einen 'Fehler' beim Einlesen trifft und startet zu diesem Zeitpunkt mpd neu (reconnect) und macht mit der zuvor bekannten playlist weiter.

    Ein verkürzen und anschließendes Probieren mit Verlängern der m3u bringt mich noch nicht dem Fehler näher, oder ich sehe den nicht.

    Einmal editiert, zuletzt von paulaner (28. Februar 2016 um 22:10)

  • Mit nachvollziehen meinte ich nur Kommandozeile, ohne dass das Radio läuft, denn dieses initiiert den Neustart/den reconnect von mpd.

    Probier doch mal eine ältere newtron-radio.py oder eine ganz aktuelle:
    https://www.dropbox.com/s/r2zpv4sjkgp8bam/newtron-radio.py

    Ach so, was mir gerade einfällt: Könnte einer der verwendeten Datenträger (SD-Karte, NAS, Festplatte, ...) eventuell einen Schlag haben?

    Einmal editiert, zuletzt von veloci (15. Februar 2016 um 15:31)

  • Hallo veloci,
    ich habe das nochmal nur in der Konsole gemacht, da kommt dann ein 'error Timeout'.

    Bei lsplaylists ist nas_mp3 mit dabei.
    Dh. mpd liest die m3u schon nicht, da kann deine Oberfläche das sowieso nicht.
    Ok., werde doch in den sauren Apfel beißen und durch stückweises vergrößern der m3u heraus finden woran es liegt.

    Dein Tipp mit den defekten LW kann ich nicht bestätigen, andere m3u von dem gleichen Verzeichnis werden problemlos gelesen. z.B. nas_flac, nas_mp4, nas_alben, nas_mixe, nas_remixe, nas_title; usb_mp3; wav_wav, mod-Files alles m3u ohne Probleme.
    Die nas_mp3 ist aber die Größte ca. 40.000 Title und 3.485.192 groß (3,4 MB)
    Dafür habe ich zum Einlesen ca. 1 Minute gebraucht.

    deine neue Version
    Zeile 27 Fehlzeichen am Ende '

    Wenn Newtron eine 'felerhafte' m3u einliest reconnected der mpd dauerhaft und kehrt aus dieser Schleife nicht zurück. ca. 20 mal egal.
    Eine Auswahl einer andern Playlist ist nicht möglich, da das Display keine Reaktion zeigt.
    Auch mit kill Prozessnummer nichts zu wollen, bricht weder mpd noch newtron ab, Prozessnummer gibt es nicht.
    Ergo Stecker ziehen.

    Aber komisch nach einem Neustert ist die Liste von 4 Titeln auf 38929 angestiegen und er spielt die auch.

    Einmal editiert, zuletzt von paulaner (27. Juni 2016 um 20:53)

  • Die Version aus der Dropbox ist eine alpha-Version. Das da noch einige Fallstricke drin sind ist klar. Aber jetzt weiss ich, dass ich noch an der mpd_connect()-Funktion arbeiten muss...
    Was die Speicherproblematik betrifft: Kann es sein, dass mpd 1. zu lange zum verarbeiten braucht? Und zweitens die SD-Karte voll ist ( wg. datenbank von mpd und so)? Und drittens die Festplatte/NAS einzelne defekte Sektoren hat? Das kann alles eine Rolle spielen.

    Und wie reagiert eine alte newtron-radio.py auf das timeout?

  • veloci
    mit einer älteren Version hab ich es noch nicht wieder probiert.
    Meine SD ist 16GB groß.
    Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
    /dev/root 15G 7,6G 6,1G 56% /
    devtmpfs 214M 0 214M 0% /dev
    tmpfs 44M 320K 44M 1% /run
    tmpfs 5,0M 0 5,0M 0% /run/lock
    /dev/sda1 3,7G 3,5G 259M 94% /media/usb0
    tmpfs 87M 0 87M 0% /run/shm
    /dev/mmcblk0p1 56M 20M 37M 36% /boot
    //http://192.xxx.xxx.xxx/111.Music/01.News 7,2T 5,8T 1,5T 81% /media/nas

    NAS ist von Synology und Erweiterung ebenfalls. Überwacht sich selbst. Aber es gibt Null Fehler. Da ich auch da ein Raid 6 habe.

    Komisch das die m3u, zwar in einer anderen Playlist drin ist und schon 3-4 Stunden spielt. Auch kann ich Sprünge von Titel zu Titel machen, im Radio sowie in der Konsole mit < mpc play 1000 > sogar wohin ich will und es werden alle gespielt, auch diese wo mpd/mpc ausgestiegen ist beim Einlesen der m3u.

    Einmal editiert, zuletzt von paulaner (28. Februar 2016 um 22:14)

  • Hey!

    Erstmal danke für die großartige Arbeit veloci und paulaner für einige Tipps, die mir geholfen haben. Läuft soweit schon gut, Fotos folgen.
    Ich habe das Waterott 2,8" Display. Da ich den Raspi jetzt fest verbaut habe, musste ich mit rotate=90 in der /boot/config.txt das Display drehen.
    Das hat auch funktioniert, aber die Funktionen vom Radio hinter den Buttons sind immer noch spiegelverkehrt, gibts da noch Einstellungen?

    Danke schonmal!

  • basti03

    Leider hast du uns nicht mitgeteilt welchen Pi und damit welches Watterott 2,8" Display du besitzt, B oder B+.

    Eine schnelle Lösung den Touch zu drehen kann ich dir auch nicht sagen.
    Lösungsansatz ist ein flip was man in die Radio.py einbaut oder man definiert die Anordnung der Button spiegelverkehrt.
    Ich denke ab Zeile um die 1400

    # Touchbutton Positionen (screen) - benötigt für rect.collidepoint()
    btn_pos = [(0,0),(0,h/2),(w/4,h/2),(w/2,h/2),(w*3/4,h/2),
    (0,h*3/4),(w/4,h*3/4),(w/2,h*3/4),(w*3/4,h*3/4)]
    btn_rect=[pygame.Rect(btn_pos[0][0],btn_pos[0][1],w,h/2)]
    for i in range(1,len(btn_pos)):
    btn_rect.append(pygame.Rect(btn_pos[i][0],btn_pos[i][1],w/4,h/4))

    # Touchbutton Positionen relativ zum btn_win - benötigt zur Anzeige
    bw=btn_win.get_width()
    bh=btn_win.get_height()
    btn_pos = [(0,0),(0,0),(bw/4,0),(bw/2,0),(bw*3/4,0),
    (0,bh/2),(bw/4,bh/2),(bw/2,bh/2),(bw*3/4,bh/2)]

    eventuell mal die Grafik des TronRadios aufrufen und entsprechende Koodinaten einzeichnen.

    Einmal editiert, zuletzt von paulaner (28. Februar 2016 um 22:16)

  • Danke! Ich habe den Raspberry B und versuche das später wenn ich zu Hause bin. Ich überlege aber schon, ob ich den Raspberry aus seinem Holzkasten wieder raus hole und einfach drehe, das wird wahrscheinlich die einfachste Lösung sein. :)

  • probiere es doch vorher mit veloci Vorschlag, danach kannst du es allemal ausbauen und wenn der Tipp funktioniert, gut, du kannst ja den Originalzustand wieder herstellen.

    Es ist mein Vorschlag, wenn nicht und du uns nichts darüber berichtest, probiere ich es in einer stillen Minute aus.

    Aber ich denke das mit dem Kalibrieren wird nicht funktionieren, da die Kreuze vorgegeben werden und somit Größe und die Koordinaten des Touch feststehen, ebenso deren Ausrichtung! und das ist ja der Knackpunkt. Alternativ bleibt nur ein Neuanordung oder Flip und Neubezeichnung (Änderung der Funktionen) der Button.

    Einmal editiert, zuletzt von paulaner (27. Juni 2016 um 21:03)

  • Hallo,

    genau das Problem habe ich mit meinem neuen 2,8" Display von Adafruit auch.
    Ich habe ein Gehäuse mit leicht schräger Frontplatte, und hier kann das Display nur 'kopfstehend' vernünftig eingebaut werden, da die Buchsenleiste sonst gegen den Gehäuseboden kommt.

    Das Display wird, gedreht, sauber dargestellt. Auch alle 'Knöpfe', nur eben die Touch-Positionen werden nicht 'gedreht'.

    Computer ..... grrrrrr

  • Hab jetzt versucht den Bildschirm zu kalibrieren, das hat nichts gebracht.

    paulaner, ich habe die Zeilen in der radio.py gefunden und hab ein bisschen zum Thema flip recherchiert, aber ich glaube ich bin zu müde :)

    Werde morgen das Display wahrscheinlich drehen, ist kein großer Aufwand.

  • So,

    bin mal wieder etwas am basteln ;)

    Habe nach diesem TUT auf meinen RPi B+ das NewTron-Radio zum Laufen gebracht.

    Installiert war das Raspian Wheezy, welches mit einem 3,5" WaveShare-Touch-Display mitgeliefert wurde (NOOBS).

    Was mich aber störte, das das Backlight sich mit GPIO 18 BCM (PIN 12) nicht abschalten ließ.
    Nach mehreren Recherchen im Netz war mir klar, das die nötige Hardware auf meinem Display nicht vorhanden war.

    Jetzt habe ich mal auf Lochraster eine "Schaltung" "entwickelt", die diese fehlende Funktion bereitstellt.

    Vorerst nur virtuell, aber immerhin.

    Ich kann leider noch nicht sagen, ob die 3,3 V vom GPIO ausreichen, um den P-Kanal MOSFET (IRFU9024N) vollständig zum durchschalten zu bringen, werde das aber in kurzer Zeit mal testen.

    Sollte das irgendwer mal nachbauen sollen -> das gelbe Kabel geht an den PIN 12 des Pfosten-Verbinder´s von der Oberseite der Display-Platine.
    Aufpassen beim Loch bohren!!!!
    Wobei das Display selber mit unglaublich starken doppelseitigem Klebestreifen befestigt ist und das nur mit chemischen Mitteln zu lösen ist -> Achtung Bruchgefahr!!!!

    Hier mal meine "Konstruktion" (der 10k Widerstand ist nur zum Schutz des GPIO´s vom RPi):

    Evtl. hat ja jemand schon damit Erfahrungen gesammelt?

  • Erfreuliches:

    Schaltung funktioniert wie gehofft (vermutet) :)

    SW-Anpassungen:

    rc.local:

    #Display-Backlight einschalten

    sudo echo 18 > /sys/class/gpio/export
    sudo echo out > /sys/class/gpio/gpio18/direction
    sudo echo 0 > /sys/class/gpio/gpio18/value


    newtron-radio.py:

    Zeile 6 -> ...= True
    Zeile 69 -> ... 'black'
    Zeile 1121 -> ... GPIO.HIGH
    Zeile 1131 -> ... GPIO.LOW
    Zeile 1432 -> ... GPIO.LOW

    Wobei ich sagen muß, das ich einige Zeit nach dem Fehler in Zeile 1432 gesucht habe,
    da sich nach dem Screensave nichts mehr bedienen ließ.

    Einen Pull-up Widerstand ist wohl noch zuzufügen, da ansonsten wieder der weiße Bildschirm bei ausgeschaltetem RPi sichtbar ist. Dafür hat man dann einen schwarzen Bildschirm bis zum vollständigem hochfahren.
    Ohne Widerstand ist die Helligkeit beim Hochfahren nur um einiges reduziert, wobei die volle Helligkeit aufgrund des Spannungsabfalls am MOSFET von 0,3 V nur geringfügig leidet.

    Auch die chemische Ablösung der Klebestreifen ist nur "bedingt" zu empfehlen, da die aufgedampfte Spiegelschicht des Displays leidet.
    Eine Erwärmung zum leichteren entfernen scheint da sinnvoller und nicht so riskant.


    Bilder folgen...

  • Hallo,
    bei mir tritt folgender Fehler auf, wenn ich auf die Wetter Seite gehe o. der Wetter-Bildschirmschoner aktiviert wird:

    Vorrübergehend habe ich das gelöst, indem ich die 34.png nach 3200.png kopiert habe.
    Ich denke, dass ist ein Fehler bei "leicht bewölkt"

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!