DFPlayer verschiedene Versionen

Hallo zusammen,

ich habe ebenfalls den GD3200B (5x per Aliexpress 5x Az-Delivery Amazon) leider habe ich das gleiche Problem, was @mihi beschreibt. Je nachdem was ich auf den SD-Karten(2GB;16GB,32GB ordentlich formatiert) habe werden entweder nur Admin Menu Sound oder nur Hörspiele abgespielt. zwischendurch hatte ich auch alle Funktionen aber da war nur ein Soundfile auf der SD-Karte.

Ich habe mir jetzt nochmal andere bestellt, trotzdem finde ich das sehr ärgerlich.
Der GD3200B Chip, scheint sich zunehmend zu verbreiten oder hatte ich nur Pech?
Hat einer eine Idee, was ich noch probieren könnte?

Der Serielle Monitor erkennt fleißig Signale, gibt auch keine Fehlermeldungen aus.

Ich habe nun einen JC AA20HFJ648-94 bekommen, damit funktioniert bisher alles wie gewollt.

Hattest du die Player bei AZ-Delivery reklamiert? Oder einfach neue bestellt? Wenn ja, wo?

@Manuel AZ-Delivery schicke ich mit entsprechendem Grund und Bewertung zurück., auf einen Umtausch/Rückabwicklung wollte ich jetzt nicht warten bzw. da hatte ich nicht drüber nachgedacht.
Die neuen habe ich bei Ebay bestellt, aus Deutschem Lager mit schneller Lieferzeit -> bei berrybase/Sertronics GmbH

Ich habe versucht den GD3200B Chip zu analysieren und zum Laufen zu bekommen.
Leider nur mit Teilerfolg.

Bei mir war das Abspielen von Advertisement und MP3 Track (also aus den Ordnern „advert“ und „mp3“) problematisch.

  • Advertisement abspielen funktioniert nur, wenn ein Titel gespielt wird.
  • mp3.start() -> Advertisement abspielen -> mp3.pause() verursacht Fehler
    • Nachher sind andere Funktionen u.U. auch fehlerhaft
      • bspw. der getFolderTrackCount wird falsch ermittelt oder es treten Com Error 3 auf
      • Diese Fehler treten auch nach Neustart / Neubeschreiben wieder auf
      • Einen Titel aus einem normalen Ordner 1-99 abspielen + ggf. Neustart scheinen das zu beheben.
  • playMp3FolderTrack war generell problematisch/fehlerhaft mit ähnlichen Folgefehlern wie oben

Daher wäre mein Lösungsansatz mit diesem Chip:

  • Alle MP3Track Aufrufe durch Titel in den Ordnern 1-99 ersetzen (oder notfalls ganz entfernen).
    • Im Prinzip sollte das kein großer Nachteil sein, da das Abspielverhalten das gleiche ist wie bei PlayFolderTrack
    • Man muss nur den Inhalt
      • in einer der Ordner 1-15 verschieben und die Titel per playFolderTrack16(folder, track) aufrufen -> mein Favorit
        • Dann kann/muss man die aktuelle 4-Ziffer-Nummierung beibehalten
      • oder auf mehrere Ordner verteilen und per playFolderTrack(folder, track) aufrufen
        • Dann muss man die Nummierung aber auf 3-Ziffern ändern und bei den Aufrufen die jeweiligen Ordner berücksichtigen
  • Advertisement Titel nur dann abspielen, wenn ein Titel abgespielt wird (also der Player busy ist).

Dann sollte der DFPlayer mit diesem Chip wie gewohnt funktionieren. Oder zumindest ausreichend gut. Ich habe es bisher nur an meiner Coinbox testen können, weil die anderen DFPlayer fest eingebaut sind.

Update

Nach den Erkenntnissen hier:

und ein paar weiteren Versuchen ist meine aktuelle Einschätzung der Einschränkungen bzw. nötigen Software-Anpassungen:

  • Advertisement abspielen funktioniert nur, wenn ein Titel gespielt wird.
  • Advertisement und MP3 Track erzeugen ein FinishTrack Event (iirc ist das bei den anderen DFPlayern nicht)
    - getFolderTrackCount(folderNumber) ignoriert den Ordner-Parameter
    • es gibt immer die Dateienanzahl des Ordners zurück, der gerade aktiv läuft
    • wenn kein Titel läuft, den Wert der letzten Abfrage, als ein Titel lief.
  • Unter Umständen sind einzelne Verzögerungen (delays) nötig, bspw. nach dem Starten des Players bzw. eines Titels

Advertisement und MP3 Track funktionieren sonst wie gewohnt.

Für das getFolderTrackCount Problem nutze ich aktuell einen „000 - Silence.mp3“ Track (1 Minute Stille :slight_smile:), den ich in jeden Ordner (zumindest mal 01-99) platziere und vor der Abfrage abspiele. So bekommt der Nutzer von der Abfrage nichts mit und ich bin sicher, dass der aktuell, laufende Titel aus dem Ordner ist, den ich auch abfragen will.

  • WIP: Evt. könnte man die Abfrage-Ergebnisse auch speichern und beim nochmaligen getFolderTrackCount-Aufruf für einen bereits ermittelten Ordner nur diesen Wert zurückgeben und ein erneutes Abspielen vermeiden. Schließlich ändert sich die Anzahl der Dateien auf der SD-Karte während des Abspielens i.d.R. nicht.

Das ist aber doch keine Einschränkung sondern „by design“.

Sowohl der Player auf meiner AiO (MH-ET LIVE (MH2024K-24SS)) als auch der in meinem Classic-Aufbau (JL) erzeugen das ebenfalls.

Ja das sollte auch so sein (und zwar idealerweise nur einen, leider gibts auch Player die erzeugen zwei). Bei Advertisements will man das aber auf keinen Fall haben.

Ja irgendwie schon.
Aber mit den anderen Playern konnte man die eben auch abspielen, wenn gerade nichts lief. Man konnte den Player starten ohne konkret einen Titel abzuspielen und konnte Advertisement Titel nutzen. Jetzt müsste ich dafür

  • eine Titel-Kopie bei den MP3 Tracks ablegen (und MP3 statt Advertisement abspielen, wenn nichts läuft)
  • oder vorher einen „Silence“-Track laden/starten (und nachher pausieren)
  • oder irgendeinen Musik-Titel laden/starten, hoffen das bis zum Abspielen des Advertisement nichts anderes zu hören ist (und nachher pausieren)

Ist also eine Einschränkung der Zweckentfremdung. :wink:

Aber das bringt mich auf die Idee, im Falle eines pausierten Musik-Titels könnte ich den Player wieder starten/fortsetzen - vllt. spielt es das Advertisement dann ohne das vorher etwas vom Titel zu hören ist. Nachher natürlich wieder pausieren. Eine solche Funktion hatte ich schon drin, aber das hatte bei Programmstart Probleme gemacht, wenn ich eben noch keinen Musik-Titel gestartet hatte. Eine Erkennung, ob ein Musik-Titel gerade pausiert ist, war bisher nicht drin.

Bez. des FinishEvents:

Ich habe es in meinem Fork so gelöst (hoffe ich):

  • Beim Abspielen wird Ordner und Track Nummer gespeichert
    • Im FinishEvent kann ich dann Advertisement und MP3 Track Events anhand des Ordners rausfiltern
  • Das doppelte Event hatte ich mit einem MH2024K-24SS auch (mit dem GB3200B noch nicht)
    • Da das fast zur gleichen Zeit erscheint, wird das zweite Event ignoriert

Das mag bei dem ein oder anderen Player mit der ein oder anderen Firmware vielleicht gehen. Aber normalerweise bekommst du dann einen error 7 (DfMp3_Error_Advertise).

Ich verstehe auch das Problem hier nicht. Ich habe schon immer den Inhalt der Ordner mp3 und advert synchron gehalten und dann je nach Situation das ein oder das andere abgespielt. Adverts setze ich bei mir zudem nur sehr sparsam ein (da es eben auch Player gibt die dann finish track events haben, was dann unschön ist wenn der eigentliche Track vorbei ist, vor allem wenn es mehrere Adverts waren).

Das ist doch schon verwirklicht worden bei den Modifikationskarten, wo ein Jingle beim Auflegen oder deaktivieren über den advert ordner abgespielt werden. Da spielt man ein File ganz kurz an, spielt dann den Jingel und nochmal ganz kurz das File. Das hat bei mir aber bei einigen Playern Probleme gemacht, deshalb habe ich das bei mir für das Auflegen der Mod-Karte rausgenommen. Aber im Prinzip baut das darauf auf, dass ein advert-track nur bei laufender Wiedergabe eines normalen Titels abgespielt werden kann und diesen unterbricht. Nach dem Adverttrack wird der normale Track weitergespielt. Wie bei advert (Werbung) im Fernsehen, wo der Film für die Werbung pausiert wird. Grrrrrr !!!. Immer wenns spannend wird. Nach dem gleichen Prinzip funktioniert auch das Ansagen des aktuellen Tracks bei laufender Wiedergabe, wenn die pausetaste lange gedrückt wird.

1 „Gefällt mir“

Im DEV sind die Ordner leider nur teilweise identisch. Und im Code konnte ich keine entsprechende Stelle finden, wo Advertisement versucht wird und im Notfall (wenn der Player pausiert) dann halt MP3 track abgespielt wird.
Meistens wird halt einfach MP3 genutzt, weil der immer geht (mit dem entsprechenden Verlust der Fortsetzungsmöglichkeit).

Daher war das für mich bisher nicht so offensichtlich, dass man beide Ordner am besten synchron halten und alternativ nutzen sollte.

Bisher wollte ich primär Advertisement nutzen, um die Fortsetzungsmöglichkeit zu erhalten.
Aber ich werde das in Zukunft so nutzen, wie du geschrieben hast.

Du meinst diese Stelle(n)?

      if (isPlaying()) {
        mp3.playAdvertisement(261);
      }
      else {
        mp3.start();
        delay(100);
        mp3.playAdvertisement(261);
        delay(100);
        mp3.pause();
      }

So hatte ich das bisher bei mir auch drin. Beim GB3200B reicht nur start() nicht aus, weil vorher oder nachher ein Titel gespielt werden muss. Das könnte ich (wie im vorigen Beitrag geschrieben) durch einen Parameter zumindest erkennen - wenn noch kein Titel gespielt wurde, dann muss man halt MP3 Track nutzen - sonst könnte man den o.g. Weg (start → advert → pause) nutzen. Aber der GB3200B braucht außerdem wohl höhere Verzögerungen (delays) und dann hört man (je nachdem wie schnell der Titel startet) den Musiktitel kurz, bevor das Advertisement kommt. Ich habe mich daher für die Variante von stephan entschieden. Sinn gemäß:

      if (isPlaying()) {
        mp3.playAdvertisement(261);
      }
      else {
        mp3.playMp3FolderTrack(261);
      }

Damit bekomme ich dann bei den Modifiern immer sauber einen Ein- bzw. Ausschalt-Sound.

In der DEV wird damit bestätigt, dass die Modifierkarte erkannt wurde. Wenn man dann ein längeres Hörspiel vorher pausiert hat, wäre der Fortschritt ohne Advert dann weg. Wobei die Lösung mit dem Starten und Pausieren sicher nicht optimal ist. Bei mir funktioniert das mp3.pause eigentlich nie.
Du nutzt ja um die Sperre zu bestätigen die LED, das wäre zumindest für alle die ohnehin eine einbauen sicherlich die bessere Alternative.

Ja,das hast du richtig erkannt. Die verschiedenen Chips der Df-Player reagieren sehr unterschiedlich darauf. Deshalb habe ich das auch so mit dem synchrohalten des mp3 und advertordner .

Hallo, ich habe ähnliche Probleme mit meinem MH2024-16SS.

In der SPEC habe ich gelesen, dass die Checksum optional ist.
Testweise habe ich die Checksum-Berechnung mal in der Library entfernt DFPlayer-noChecksum.

Bingo!

Mit diesen Patch funktioniert der Chip schon sehr gut! Der Arduino liest sogar die korrekte Anzahl an MP3s in einem Folder aus.
Das Einzige, was mir beim Testen aufgefallen ist, dass der Arduino immer noch Probleme hat, zu erkennen, wenn ein Lied vorbei ist.

Testet den Patch gerne mal aus, bevor ihr die Chips wegwerft.

PS: Ich nutze die Tonuino-Version von Stephan Eisfeld.

2 „Gefällt mir“

Das Problem mit dem OnPlayFinished ist mir auch schon aufgefallen.
Der alte Chip „sendet“ am Ende eines Tracks ein Signal in der Form 7E FF 6 3D 0 0 ...... das Signal vom neuen sieht bei mir in dieser Art und Weise aus 7E FF 6 4C 0 0 ......
Das müsste eigentlich das gleiche sein, wie die Antwort auf die Abfrage wieviele Tracks im derzeitigen Ordner sind.
Ein einfaches Ändern des Wertes für OnPlayFinished von 3D in 4C in der Library hat für mich aber noch keinen Erfolg gebracht. Ich suche noch…

Edit: es musste 3D heißen, 3F war falsch

1 „Gefällt mir“

Und weiter geht’s in der DFPlayer Chip Forschungsgruppe … :slight_smile:

Der Tipp mit der Checksumme hat wirklich viel geholfen. Danke @bw87.

Jetzt klappt zumindest das normale Abspielen (inkl. FinishEvent) und Anzahl der Dateien im Ordner auslesen. :sunglasses:

@kobayashi_maru: Um überhaupt zur Abarbeitung der Antwort (und somit der Erzeugung des Finish-Events) zu kommen (d.h. readPacket = true), musste ich noch die Endcode-Abfrage ändern, um den PacketHeader Fehler (0x83, dez. 131) zu umgehen. Scheinbar ist der Endcode bei empfangenen Daten nicht 0xEF (wie beim Senden) sondern 0xFE !
Daher habe ich folgende Zeile angepasst: in[DfMp3_Packet_EndCode] != 0xfe *

  • *Edit: Womöglich werden hier die beiden Checksummen Bytes mit zurückgesendet!?
    Also das 0xFE ist evt. das 1. Byte der Checksumme und nicht der Endcode!?

Danach habe ich, wie du schon geschrieben hast, noch in der Eventabfrage unter case 0x3d: noch ein case 0x4c: hinzugefügt.

Was bei mir noch nicht funktioniert ist das Abwarten, bis ein Titel zu Ende gespielt ist. :frowning:
Irgendwas in der mp3.loop() ist da noch nicht koscher bzw. deaktiviert sich der busy Pin nicht. Der bleibt in der Warteschleife hängen.

Was ich beobachtet habe:

  • Der Busy Pin bleibt nach dem Ende eines Titels aktiv (leuchtet)
    • Sowohl bei Advertisement, MP3 als auch normalen Titel
  • Advertisement und MP3 liefern kein FinishEvent

Somit bekomme ich nicht mit, ob Advertisement oder MP3 Track fertig sind.

Ist das nicht aber Kommando 0x4E (dezimal 78) ?

Ja, da habe ich mich vertan, sry. Ich hatte im Code von @bw87 nicht gesehen, dass das empfangene Byte-Array nicht verkleinert war.
Im Grunde reicht also eine neue Variable _ignoreCheckSum um die Verarbeitung umzuschalten:

	if (_ignoreCheckSum)
	{
		out[DfMp3_Packet_HiByteCheckSum] = 0xEF;
		out[DfMp3_Packet_LowByteCheckSum] = 00;
		out[DfMp3_Packet_EndCode] = 00;
	}
	else
	{
		setChecksum(out);
	}

statt

	setChecksum(out);

sowie die bereits genannte Anpassung für das FinishEvent

	case 0x3d: // micro sd
	case 0x4c:

Du hast recht, da hab ich mich vertan.
das 4C müsste die Antwort auf die Anfrage nach der Nummer des derzeit abgespielten Track im aktuellen Ordner auf der SD sein.

Das hat bei mir leider keinen Erfolg gebracht, das OnPlayFinished wird weiterhin nicht erkannt/verarbeitet.

Da konnte ich allerdings bei meinem Player am Ende vom Advertisement eine Ausgabe in der Form 7E FF 6 4E 0 0 ...... abgreifen.