Anpassungen für Player mit dem DFROBOT LISP3 Chip

Thomas-Lehnert · 18. Februar 2022 um 15:27

kobayashi_maru:

Vom Code her würde ich sagen das ist ok.

  if (!AdvPlaying) {
        PrintlnSourceAction(source, "OPin -> nxtTr2");
        nextTrack(track);
      }
      AdvPlaying = false;
    }

Füge mal vor dem AdvPlaying = false; ein Serial.println("RESET PlayAdvert"); ein.
Dann haben wir schonmal eine Kontrolle ob der Code da ausgeführt wird.
Oder hinter AdvPlaying = false; eine abfrage if(!AdvPlaying) Serial.println("RESET PlayAdvert durchgeführt"); Dann sehen wir ob das Resetten ausgeführt wird.
Dann tausche auch mal die beiden Zeilen.

PrintlnSourceAction(source, "OPin -> nxtTr2");
        nextTrack(track);

Scheint erst mal ohne tieferen Sinn, aber manchmal hat die Reihenfolge Einfluss auf den Ablauf.

Hast du die Ansage der Tracknummer über longpress Play bei dir enthalten?
Dann probiere es mal mit diesen Adverts, ob da das gleiche Phänomen auftritt.
Eine Möglichkeit wäre noch die Abfrage anders zu formulieren
if (AdvPlaying == false)… Das ist eigentlich das Gleiche.

kobayashi_maru · 18. Februar 2022 um 17:06

So Code wie folgt geändert und für advert die Trackansage genutzt, aber keine Änderung

    static void OnPlayFinished(DfMp3_PlaySources source, uint16_t track) {
//      Serial.print("Track beendet");
//      Serial.println(track);
      delay(100);

      PrintlnSourceAction(source, "OPin -> nxtTr1");

      if (AdvPlaying == false) {
        PrintlnSourceAction(source, "OPin -> nxtTr2");
        nextTrack(track);
      }
       Serial.println("RESET PlayAdvert");
      AdvPlaying = false;
      if(AdvPlaying == false) Serial.println("RESET PlayAdvert durchgeführt");
    }

Advert als Tracknummern-Ansage durch mp3.playAdvertisement(advertTrack); AdvPlaying = true; Serial.println(F("Track-Ansage --> TRUE gesetzt")); in der Konsole sichtbar gemacht.

Konsolen-Ausgabe bei diesem Versuch:

17:54:20.094 -> RFID UID:  15 55 9C 28
17:54:20.094 -> PICC type: MIFARE 1KB
17:54:20.127 -> Authenticating Classic using key A..
17:54:20.127 -> Reading block 4 ..
17:54:20.127 -> Data on RFID :
17:54:20.127 ->  13 37 B3 47 02 13 05 00 00 00 00 00 00 00 00 00
17:54:20.127 -> 
17:54:20.127 -> 19
17:54:20.127 -> 19
17:54:20.127 -> == playFolder()
17:54:20.127 -> == disablestandby()
17:54:21.782 -> 147 Dateien in Ordner 19
17:54:21.782 -> Hörbuch Modus
17:55:44.357 -> SDOPin -> nxtTr1
17:55:44.357 -> SDOPin -> nxtTr2
17:55:44.357 -> == nextTrack()
17:55:44.357 -> Hörbuch Modus -> nächster Track & Fortschritt sichern
17:55:44.390 -> 8
17:55:45.946 -> RESET PlayAdvert
17:55:45.946 -> RESET PlayAdvert durchgeführt
17:56:02.262 -> Track-Ansage --> TRUE gesetzt
17:57:10.175 -> SDOPin -> nxtTr1
17:57:10.175 -> RESET PlayAdvert
17:57:10.175 -> RESET PlayAdvert durchgeführt

Gleiches Vorgehen wie oben, nur das eben das advert diesmal die Tracknummern-Ansage war.

Werde mir wohl einfach einen Knoten in’s Ohr machen, dass der Chip ne andere Codeanpassung braucht als andere

Thomas-Lehnert · 18. Februar 2022 um 17:33

Also nach der Konsolenausgabe macht der Code was er soll. Hast du denn gewartet, bis nextTrack durch ende des aktuellen Tracks automatisch ausgelöst werden soll?
Kann es sein, dass der Player, nachdem er das Event beim Abspielen des Advert ausgegeben hat, das Event beim Beenden des normalen Medientracks nicht mehr ausgibt? Aber eigentlich nicht, denn das nextTrk1 zeigt ja eigentlich das event an.
Kratz,Kratz Hinterkopf!

Thomas-Lehnert · 18. Februar 2022 um 18:08

kobayashi_maru:

   static void OnPlayFinished(DfMp3_PlaySources source, uint16_t track) {
//      Serial.print("Track beendet");
//      Serial.println(track);
      delay(100);

      if (AdvPlaying == true)  Serial.println(" Adv Beendet -> nextTrack wird nicht gesetzt");
    else
{
        
        nextTrack(track);
        //PrintlnSourceAction(source, "OPin -> nxtTr gesetzt");
        Serial.println(" Track Beendet -> nextTrack wird  gesetzt");
}
      
       Serial.println("RESET PlayAdvert");
      AdvPlaying = false;
      if(AdvPlaying == false) Serial.println("RESET PlayAdvert durchgeführt");
    }

Probiere das mal aus. Ich weiß jetzt nicht ob der Compiler das mit dem SerialPrint so durchgehen lässt. Sonst aktiviere PrintlnSourceAction(source, "OPin -> nxtTr gesetzt"); wieder und setze das andere in Kommentar.

kobayashi_maru · 18. Februar 2022 um 18:25

Erstmal DANKE für deine Unterstützung!

Jupp!

Werde ich noch noch machen, aber für jetzt ist erstmal Schluss. Meine Frau rollt schon mit den Augen

Thomas-Lehnert · 18. Februar 2022 um 18:29

Ok. Habe das eben gepostete mal in meinen Scetch eingebaut und teste es gerade mit dem DFROBOT LISP3. Der gibt ja auch bei Advert das Event aus. Schreibe dann noch das Ergebnis auf. Vielleicht klappt das ja dann auch auf dem anderen
IL Chip
Hier nochmal die Konsole

19:25:31.123 -> Alb.modus -> nxtTrk 
19:25:31.123 -> idx: 1 --> 2 von: 76
19:25:31.170 -> Play Q-idx: 2, Trk: 3
19:25:31.170 -> 
19:25:31.170 -> StdBy OFF
19:25:34.761 ->  Wait for Track To Finish
19:25:37.406 ->  Adv Beendet -> nextTrack wird nicht gesetzt
19:26:14.238 -> Leiser -> 19
19:26:14.392 -> Leiser -> 18
19:26:14.539 -> Leiser -> 17
19:26:14.708 -> Leiser -> 16
19:26:14.793 -> Leiser -> 15
19:26:14.940 -> Leiser -> 14
19:28:53.658 -> SD-K EoT -> nxtTr
19:28:53.658 -> 
19:28:53.658 -> Alb.modus -> nxtTrk 
19:28:53.658 -> idx: 2 --> 3 von: 76
19:28:53.658 -> Play Q-idx: 3, Trk: 4
19:28:53.658 -> 
19:28:53.658 -> StdBy OFF
19:28:53.658 ->  Track Beendet -> nextTrack wird gesetzt
19:28:53.758 -> SD-K EoT -> nxtTr
19:28:53.758 ->  Track Beendet -> nextTrack wird gesetzt
19:29:53.261 -> 
19:29:53.261 -> Alb.modus -> nxtTrk 
19:29:53.261 -> idx: 3 --> 4 von: 76
19:29:53.261 -> Play Q-idx: 4, Trk: 5
19:29:53.261 -> 
19:29:53.261 -> StdBy OFF
19:29:55.800 -> prev.Track : Alb.modus
19:29:55.800 -> Album -> vorh.Track : 4 --> 3 von: 76
19:29:55.854 -> Play Q-idx: 3, Trk: 4
19:29:55.854 -> 
19:29:55.854 -> StdBy OFF
19:30:05.098 ->  Wait for Track To Finish
19:30:07.807 ->  Adv Beendet -> nextTrack wird nicht gesetzt
19:30:10.314 ->  Wait for Track To Finish
19:30:13.042 ->  Adv Beendet -> nextTrack wird nicht gesetzt

Und hier der Code wie ich den bei mir ausprobiert habe.

    // Meldung vom Df Player - Track beendet ,                                  Meldung erfolgt
    static void OnPlayFinished(DfMp3_PlaySources source, uint16_t track)    //  am Ende von normalen mp3 Files 
    {                                                                       //  am Ende von Files aus dem mp3-Ordner
    delay(100);
                                                                            // Zusatzabfrage für DF-Player, die auch am Ende
                                                                            // von Adverts ein Track beendet ausgeben. z.B.DFROBOT DF 290
    if(AdvPlaying)Serial.println(" Adv Beendet -> nextTrack wird nicht gesetzt");
    
    else
    //if(!AdvPlaying)                                                         // Wenn kein Advert abgespielt wurde
      {
#ifdef Konsole
      PrintlnSourceAction(source, "EoT -> nxtTr");                          // wird am Ende von advert-Tracks nicht gesendet
#endif
      nextTrack(track);                                                     // nextTrack wird nur ausgeführt, wenn kein Advert abgespielt wird
     Serial.println(" Track Beendet -> nextTrack wird gesetzt");
      }                                                                     
     AdvPlaying = false;                                                    // Marker zurücksetzen dass Advert gespielt wurde
    }

Funktioniert soweit. vielleicht klappt es damit auch auf dem IL.

kobayashi_maru · 18. Februar 2022 um 21:26

@Thomas-Lehnert auch deine letzten Anpassungen greifen bei meinem Player nicht.
Ich habe dann auch noch einen weiteren Anlauf zur „Fehleranalyse“ unternommen und meine Player noch mal durch den DFPlayerAnalyzer gejagt.
Abschließende Erkenntnisse für mich der neue JL von tinytronics sendet zwar ein anderes finish-event als alle „alten“ Chips, aber er sendet das nur einmal und auch nur nach den „normalen“ mp3 aus den Ordnern 1 bis 99, also nicht nach advert. Deswegen braucht er das Workaround überhaupt nicht.
Meine anderen Player, von denen auch ein paar kein finish-event nach advert senden, senden aber ZWEI finish-events nach den „normalen“ mp3, so dass vermutlich das workaround hier greift, weil das erste finish-event im workaround als „von advert kommend“ interpretiert wird und dann das zweite noch das nextTrack auslöst.
Lange Rede kurzer Sinn, für meinen neuen JL darf ich nur das finish-event in der DFPlayer lib angepassen!
@Thomas-Lehnert DANKE für deine Geduld, dein Gehirnschmalz und die Arbeit, die du in dieses Problem gesteckt hast und auch sonst hier ins Forum einbringst!

Thomas-Lehnert · 19. Februar 2022 um 18:50

Hallo @kobayashi_maru
Ich bin der Sache auf der Spur. Kannst du feststellen, ob der Player ein oder zwei Events am Ende des Tracks ausgibt. Genau darin liegt nämlich das Geheimnis des Phänomens. Im normalen Ablauf ohne Event nach Advert, ist es egal ob ein oder zwei EndOfTrack events ausgegeben werden. Jedes ruft einen NextTrack auf. NextTrack selbst unterdrückt allerdings die zweite Ausführung, weil sich die Tracknummer zwischen den beiden Events nicht geändert hat. Es wird also im Normalfall das NextTrack sofort nach dem ersten Event ausgeführt. Kommt ein EndOfTrack Event auch nach Advert, wird der Aufruf von NextTrack durch die If Abfrage des Flags für das Advert unterdrückt und das Flag zurückgesetzt.
So nun kommt was ich rausgefunden habe. Gibt der Player kein EndOfTrack Event nach Advert aus, ist das Flag beim ersten Event noch auf true. Dadurch wird NextTrack nicht aufgerufen, aber das Flag auf false zurückgesetzt. Das zweite Event kann jetzt aber NextTrack aufrufen, weil das AdvertFlag jetzt auf false zurückgesetzt ist. Gibt der Player jetzt aber nur ein EndOfTrack Event aus, fehlt sozusagen der zweite Versuch und NextTrack wird nicht aufgerufen. Jetzt muss ich noch austüfteln, wie man das lösen kann.
Hier noch mal der Code erweitert um die Sache in der Konsole verständlicher zu machen.

    // Meldung vom Df Player - Track beendet ,                                  Meldung erfolgt
    static void OnPlayFinished(DfMp3_PlaySources source, uint16_t track)    //  am Ende von normalen mp3 Files 
    {                                                                       //  am Ende von Files aus dem mp3-Ordner
 //   delay(100);
#ifdef Konsole
      PrintlnSourceAction(source, "EoT");                                   
      Serial.print("EoT - nextTrack - global: ");
      Serial.println(track);
#endif                                                                            // Zusatzabfrage für DF-Player, die auch am Ende
                                                                            // von Adverts ein Track beendet ausgeben. z.B.DFROBOT DF 290
    if(AdvPlaying)Serial.println(" Adv Beendet -> nextTrack wird nicht aufgerufen");
    
    else
    //if(!AdvPlaying)                                                         // Wenn kein Advert abgespielt wurde
      {
#ifdef Konsole
     // PrintlnSourceAction(source, "EoT -> nxtTr");                          // wird am Ende von advert-Tracks nicht gesendet
#endif
      Serial.print(" Track Beendet -> nextTrack wird aufgerufen :");
      Serial.println(track);
      nextTrack(track);                                                     // nextTrack wird nur ausgeführt, wenn kein Advert abgespielt wird
      }                                                                     
     if(AdvPlaying)
     {
      AdvPlaying = false;                                                    // Marker zurücksetzen dass Advert gespielt wurde
      Serial.println("Reset AdvPlaying");
     }
     delay(100);
    }

Da ist jetzt noch keine Lösung für das Problem drin. Das muss ich noch rausfinden.

kobayashi_maru · 19. Februar 2022 um 20:17

Das ist genau das, was ich mit meinen letzen Post sagen wolte!
Der Player sendet nur EIN Event am Ende eines normalen Tracks aus den Ordner 1 bis 99 und gar keins nach advert.

stephan · 19. Februar 2022 um 20:22

Wo ist dann das Problem? Das ist doch das beste Verhalten überhaupt.

Gute_Laune · 19. Februar 2022 um 20:25

Die bisherige Anpassung für das Abfangen des nextTrack vom Advert funktioniert bisher nur bei Playern die entweder ein nextTrack nach dem Advert triggern oder die ein doppeltes nextTrack nach dem nächsten Track ausgeben. Deshalb muss der Fix noch weiter angepasst werden

stephan · 19. Februar 2022 um 20:36

Nee. Für den Case den @kobayashi_maru beschreibt braucht man gar keinen Fix.

Thomas-Lehnert · 19. Februar 2022 um 20:40

Das trifft für diesen Player zu. Ist die Frage, ob es auch Player gibt, die ein Event bei Advert und auch nur ein Event bei normalplay ausgeben. Wenn das der Fall ist muss eine Anpassung gefunden werden. Wenn es aber nur diesen einen Player betrifft kann man das über ein #define machen.

kobayashi_maru · 19. Februar 2022 um 21:06

Ein kleiner Fix ist doch nötig: Es muss in die DFPlayer lib von Makuna der case 0x4c: wie hier:

beschrieben zusätzlich eingetragen werden.
Bezieht sich in dem Post zwar auf einen anderen Player, aber der JL-AC20BP nutzt das gleiche.

raznz_snasna · 9. März 2022 um 11:47

Mal ein ganz anderer Ansatz dazu, ohne die Möglichkeit zu haben es zu testen.

Beendet er einen normalen Track, sollte doch der BUSY Ausgang High sein, wenn das finish Event kommt.
Track beendet - > Busy High - > finish Event
Eventuell fragt man nach 4ms ab

Unterbricht er aber wegen einem Advert, dann spielt er anschließend seinen Track weiter. Busy sollte also low bleiben während finish gemeldet wird.

Gute_Laune · 10. März 2022 um 18:38

3 Beiträge wurden in ein neues Thema verschoben: Fragen zum Gd3200b