Automatischer MP3 download, falls nicht auf SDKarte

Niko · 17. Januar 2025 um 21:18

Wie verhält sich das dann mit den virtuellen Tags 900000000001 bis 900000000009
Die kann jeder aktiviert haben.

QDaniel · 17. Januar 2025 um 21:35

Die werden nicht zum System geschickt, da diese ja im NVS zugeordnet werden.

Aber ich werde die wohl im Backend nochmal extra sperren.

Grundsätzlich gilt immer die erste Registrierung, wenn die SerienNr schon vorhanden ist passiert nix.

Niko · 17. Januar 2025 um 22:43

Damit können aber die Tasten (virtuellen Transponder) nicht über die Cloud bedient werden

Niko · 17. Januar 2025 um 23:39

Ja, Download scheitert immer wieder.
Hab nun sicherheitshalber noch deinen letzten Source von Git gecloned.
Jetzt crasht die cpu beim Volume + Taste

Mach jetzt mal pause und warte, wie @Dotmatrix812 weiterkommt.

@Dotmatrix812
Gib mir bitte BEscheid, ob es dir gelingt:

Einem neuen Tag eine MP3 zuzuweisen, sodass dieser beim Auflegen auf den reader das Streamen von der cloud auslöst. (Funktioniert bei mir)
Nachher in der cloud ein anderes MP3 File dem selben TAG zuweisen
Spätestens nach 2maligen Auflegen des Tags sollte dann das neue File gestreamt werden.

Punkt 2 bekomme ich nicht zum Laufen. Bekomme bei DownloadM3U immer wieder http result: -5 (oder auch 7 oder 204)

VD im Voraus!

BACKTRACE vom crash:

I [12648] Neue Lautstärke empfangen via Queue: 4
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x400d71d7  PS      : 0x00060330  A0      : 0x800d72e5  A1      : 0x3ffb3830  
A2      : 0x00000000  A3      : 0x3ffb387c  A4      : 0x3ffb37fc  A5      : 0x00000000  
A6      : 0x3ffb37fc  A7      : 0x000003ff  A8      : 0x00000000  A9      : 0x3ffb3808  
A10     : 0x00000001  A11     : 0x3ffb37c8  A12     : 0xffffffff  A13     : 0x00000001  
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000002  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000004  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffe  


Backtrace: 0x400d71d4:0x3ffb3830 0x400d72e2:0x3ffb3850 0x400d7bbf:0x3ffb3870 0x400e600a:0x3ffb38d0 0x400d3635:0x3ffb3980
  #0  0x400d71d4 in ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>::result_type ArduinoJson::V721PB22::detail::VariantData::accept<ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter> >(ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>&, ArduinoJson::V721PB22::detail::ResourceManager const*) const at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Variant/VariantData.hpp:44
  #1  0x400d72e2 in ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>::visit(ArduinoJson::V721PB22::detail::ObjectData const&) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Json/JsonSerializer.hpp:51
      (inlined by) ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>::result_type ArduinoJson::V721PB22::detail::VariantData::accept<ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter> >(ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>&, ArduinoJson::V721PB22::detail::ResourceManager const*) const at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Variant/VariantData.hpp:64
  #2  0x400d7bbf in ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>::result_type ArduinoJson::V721PB22::detail::VariantData::accept<ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter> >(ArduinoJson::V721PB22::detail::VariantData const*, ArduinoJson::V721PB22::detail::ResourceManager const*, ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>&) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Variant/VariantData.hpp:105
      (inlined by) unsigned int ArduinoJson::V721PB22::detail::doSerialize<ArduinoJson::V721PB22::detail::JsonSerializer, ArduinoJson::V721PB22::detail::StaticStringWriter>(ArduinoJson::V721PB22::JsonVariantConst, ArduinoJson::V721PB22::detail::StaticStringWriter) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Serialization/serialize.hpp:16
      (inlined by) ArduinoJson::V721PB22::detail::enable_if<ArduinoJson::V721PB22::detail::JsonSerializer<ArduinoJson::V721PB22::detail::StaticStringWriter>::producesText, unsigned int>::type ArduinoJson::V721PB22::detail::serialize<ArduinoJson::V721PB22::detail::JsonSerializer>(ArduinoJson::V721PB22::JsonVariantConst, void*, unsigned int) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Serialization/serialize.hpp:37
      (inlined by) ArduinoJson::V721PB22::serializeJson(ArduinoJson::V721PB22::JsonVariantConst, void*, unsigned int) at .pio/libdeps/lolin_d32_pro_sdmmc_pe/ArduinoJson/src/ArduinoJson/Json/JsonSerializer.hpp:144
      (inlined by) Cloud_SendStatusInfo() at src/Cloud.cpp:377
  #3  0x400e600a in Web_SendWebsocketData(unsigned int, WebsocketCode) at src/Web.cpp:1164
  #4  0x400d3635 in AudioPlayer_Task(void*) at src/AudioPlayer.cpp:410

Niko · 17. Januar 2025 um 23:59

Noch eine INFO:

Ich verwende den PN5180 anstatt dem MFRC522

felixSt · 18. Januar 2025 um 08:56

Ich muss mir erstmal einen zweiten ESPuino aufbauen, um anständig testen zu können.
Nr1 ist zu stark in benutzung.
Mache ich aber direkt;-)

Dotmatrix812 · 18. Januar 2025 um 11:30

Hi Zusammen.

Muss mich gesundheitlich leider nochmal abmelden. War gestern dabei die Firmware zubauen. Leider musste ich heute aber nochmal ins Krankenhaus gehen. Ich lese mit, aber machen kann ich aktuell leider nichts.

Viele Grüße

Niko · 18. Januar 2025 um 13:14

@Dotmatrix812
Alles Gute!

QDaniel · 18. Januar 2025 um 20:52

Hab nun im Web-Server das anlegen von Alben fertig gestellt.

Und im dev branch paar memory fixes hinzugefügt, das der speicher nicht vollläuft.

Niko · 18. Januar 2025 um 22:17

Hallo Daniel,

hab auf deine neue Version upgedatet und die Firmware geflasht.

Gute Nachricht: Eine Lautstärkeänderung führt nun nicht mehr zum Absturz.

Nicht so gut:
Siehe bitte auf meinen Logauszug.
Was kann das sein, dass der DownloadFileM3U mit
http result: 204 endet (empty response).

Die darauf folgenden enden mit 304 (not modified)

Wie gesagt, ich hab lediglich den rfid reader auf PN5180 konfiguriert.
Ansonsten die Platine „ESPuino-mini 4Layer“ ggf. Pin angepasst.

Bin für Tipps die zur Lösung führen dankbar!

VD im Voraus!

Niko · 18. Januar 2025 um 22:22

Hier noch das LOG beim Starten:

QDaniel · 18. Januar 2025 um 23:40

Also 304 ist normal. Er prüft ja beim auflegen die Datei neu und erkennt das es nichts neues gibt.

204 kam noch fehlerhafterweise bei Album Zuordnungen.

Niko · 19. Januar 2025 um 12:11

Bei mir kommen unterschiedliche Status Codes ungleich 200

Habe letztendlich die aktuellste Version von Git geholt und komplett unverändert (auch setting) auf neue Hardware von Torsten geflasht.

Leider sind die Ergebnisse, speziell bei Download3MU für recheck der Transponder. m3u nicht vorhersehbar und fast immer mit nicht 200 und nicht 304.

Kann nicht ausmachen, was bei meinen Versuchen anders ist, das zu den derartigen Problemen führt.

Warte nun wirklich, bis mir jemand bestätigt, dass das problemlos funktioniert und bitte dann auch gleichzeitig um Versionsangabe und ggf. um die setting Files.
VG

QDaniel · 19. Januar 2025 um 12:32

Alle Statuscodes mit 20X oder 30X sind soweit normal.
Statuscodes mit 40X oder 50X sind Fehler welche am Server erzeugt werden.

Alle Status Codes <0 sind Fehler des HttpClients , normalerweise wegen instabiler Verbindung.

Niko · 20. Januar 2025 um 00:01

Es kommt leider 204 (Leere RESPONSE) was ich in dieser Anwendung nicht als normale Response sehe
wo 200 (OK) kommen soll.
Zudem genügend negative, die ich nicht mehr notiert habe. Insgesamt instabil und nicht reproduzierbar.
Wie gesagt, so kann ich das leider nicht verwenden, obwohl ich das sehr gerne möchte.
Deshalb hab ich mich sehr bemüht, aufbereitete Feedbacks zu liefern, um das lösen zu können.
Wenn ich dann letztendlich einen unveränderten Source verwende und dieser ebenfalls derartige Probleme macht, weiß ich leider nicht, wo ich noch ansetzen sollte. Für mich scheint es ein Problem zu sein mit gleichzeitigem Zugriff auf das WLAN Netzwerk über mehrere Tasks. Deshalb je nach Zeitpunkt negative Status Codes oder leere Response (204) oder CPU crash (unhandled Exception)

QDaniel · 20. Januar 2025 um 09:07

Wann kamen die letzten 204? Nochmal nachdem 19.01.25 00:40?
War wegen den noch nicht implementierten Alben.

Die Crashes waren wie schon gesagt Memory-Leaks , sollten auch behoben sein. Mit Commit: freeing memory · QDaniel/ESPuino@8bc297b · GitHub

Die Minus Fehler muss man sich genauer anschauen, sind soweit eigentlich immer instabile Verbindung / WLAN.

Niko · 20. Januar 2025 um 13:25

Gerade eben nochmals einen Durchlauf dokumentiert:
Startup LOG:

Neuen Tag 123456789004 ausgelöst:
Alles OK: Message tagnotfound wird abgespielt.

Tag wurde in quino cloud automatisch angelegt:

MP3 Zum Gebutstag zugeordnet

Tag erneut ausgelöst:

Existing File /CloudCache/123456789004.m3u

#"1becd5c94cfe21dc343d4e7d5d16e148"
#TAGNOTFOUND
#OK

Die Message „tagnotfound“ wird abgespielt, da ja noch in der cache .m3u so vorliegt (OK)!
Es wird versucht von der Cloud die aktuelle m3u zu laden:

    I [567940] DownloadFileM3U http uri: http://quino.0011.de/api/rfid/info/123456789004 -> 
11ms später wird auch zum Streamen  connected:
    I [567951] info        : connect to: "quino.0011.de" on port 80 path "/media/tagnotfound.mp3"
369ms nach Start von DownloadFileM3U kommt dann
    I [568309] http result: -5
    I [568309] HTTP Failed, Status: -5
296ms später beginnt das Abspielen des Streams tagnotfound.mp3
    N [568605] 'http://quino.0011.de/media/tagnotfound.mp3' wird abgespielt (1 von 1)

Result: -5

Bisherigen Ablauf dokumentiert.
Scheinbar ist der ESPuino während der Dokumentation in den Sleep Mode gegangen. Ich starte den ESPUINO neu und löse den TAG nochmals aus.

Result: 204

Manuell über Browser heruntergelden:
http://quino.0011.de/api/rfid/info/123456789004.m3u

#TAGNOTFOUND
#OK
http://quino.0011.de/media/tagnotfound.mp3

Habe daraufhin das File „/CloudCache/123456789004.m3u“ angesehen:
Dort befindet sich nur mehr folgende Zeile:
#"94012b15-43b3-4fa9-995d-96773111ae57"
Weiters passiert nichts mehr.
Löse den Tag nochmals aus:

Result: 304 (logisch, da sich die Ressource nicht geändert hat)
Für den User: Tag reagiert nicht

Niko · 23. Januar 2025 um 10:27

@tribut @pako @rbs
Ihr habt für diese feature gestimmt.
Wie ist euer Feedback dazu?

Niko · 23. Januar 2025 um 10:48

Hi, würde mich auch sehr über dein feedback freuen.
VG

pako · 26. Januar 2025 um 12:36

Ich habs bisher leider noch nicht geschafft zu Testen.