deadlock on getFolderTrackCount

[leagris]

Library version 1.0.2 from this repository

Call on to getFolderTrackCount or getTotalFolderCount never returns.

Issue could be similar to DFRobot/DFRobotDFPlayerMini#12

[Makuna]

That issue is specific to the use of the "request ack" feature, which I do not enable or use.

Do you have more information to help reproduce the problem? minimum sample sketch and data layout of your memory card would be useful.

[seisfeld]

I use getFolderTrackCount() all the time in my project. I did not see any issue with it on any of my modules yet. I did contribute getTotalFolderCount() a few months ago and over time i found it works on some modules and fails on others. There are lots of counterfeits with various different chips available, it’s hard no nail down the reason so far. I did blame it on the chips firmware so far...

[leagris]

Here is the structure of the flash card, listed unsorted (in the order they were copied)

SD Card freshly formatted to FAT-16 with:

sudo mkdosfs -F 16 /dev/sdd1

SD Card structure:

lea@meumeu:~/$ tree -U /media/lea/06CD-F02B
/media/lea/06CD-F02B
├── 001
│   ├── 003.MP3
│   ├── 004.MP3
│   ├── 001.MP3
│   ├── 002.MP3
│   ├── 005.MP3
│   └── 006.MP3
├── 001.MP3
├── 002
│   ├── 004.MP3
│   ├── 006.MP3
│   ├── 007.MP3
│   ├── 001.MP3
│   ├── 002.MP3
│   ├── 003.MP3
│   └── 005.MP3
├── 003
│   ├── 004.MP3
│   ├── 005.MP3
│   ├── 006.MP3
│   ├── 001.MP3
│   ├── 002.MP3
│   └── 003.MP3
├── 004
│   ├── 001.MP3
│   ├── 002.MP3
│   ├── 003.MP3
│   ├── 004.MP3
│   ├── 005.MP3
│   └── 006.MP3
├── 005
│   ├── 002.MP3
│   ├── 001.MP3
│   ├── 006.MP3
│   ├── 003.MP3
│   ├── 004.MP3
│   └── 005.MP3
├── 006
│   ├── 001.MP3
│   ├── 002.MP3
│   ├── 003.MP3
│   ├── 004.MP3
│   ├── 005.MP3
│   └── 006.MP3
├── 007
│   ├── 003.MP3
│   ├── 004.MP3
│   ├── 005.MP3
│   ├── 001.MP3
│   ├── 002.MP3
│   └── 006.MP3
├── ADVERT
└── MP3

9 directories, 44 files

[seisfeld]

I don't want to hijack the conversation, so @Makuna tell me an I stop. ;)

IMHO, if you use playFolderTrack() to play audio, folders should be double (not tripple) digit and files triple digit. That's what we use in our project and don't have issues. Granted, the documentation here in the wiki says different. Maybe this is wrong? I never used playFolderTrack16() though.

[Makuna]

@seisfeld Interesting, I just checked the latest stuff from DFRobot, and they follow what you do, 2 digits for folder, three digits for file. This was not what was originally documented, but there have been other corrections since I wrote this.

@leagris Could you try changing the folders to only two digits and see if the problem continues.

[leagris]

I am away for the next 10 days, so I'll try as I return.
I am also considering that the DFPlayer modules I got are broken counterfeit. I did not buy from DFRobot directly because it is oversea from the US, with killing taxes and shipping delays. I try to find a suitable sound module for my ATMega2560, as it is intended to play voice tracks while having my robot doll perform various scripted animatronics.
Everything works, an IR Remote, a 16x2 Alphanumeric LCD panel, a Polulu Maestro. But this DFPlayer has so much troubles.
I tried Hardware Serial1 from the ATMega2560 and even SoftwareSerial. Wiring form the MC TX pin has a 1k resistor to lower Voltage from 5V to 3.3V. I had to power the DFPlayer with batteries because powering from the Arduino causes the player to emit an horrible low Hz noise. This device is really tricky compared to other stuffs I connect without issue.

[Makuna]

Just update here with what you discover when you can. If the folder name doesn't fix it, I can provide some debug code to print out what is sent and received so I can see what is happening at a lower level since I can't reproduce.

I would still like to support these clones if its an easy work around, as I am sure you are not the only person to have one ;-)

[derbero]

Hello,

I encounter the same issue. getFolderTrackCount, getStatus, getVolume, like all getSomething methods never return a value and end up in a deadlock (or something similar). What is actually working is the call playFolderTrack(1,13) which plays the track just fine.

IMHO it could also mean that the TX pin on the MP3 module or the RX pin on the Arduino Nano is not working at all (I tried to rule this out by using another MP3 module and another Arduino and other cables). So I am staying with library or module issues...

The MP3 module in use is a JC_AA19HEW496-94 and JC_AA1628CJ490C1-94 (as far as I could read it correctly).

Could you provide the debug code so that I could have a look and report back, please?

Best, Ole

[Makuna]

To Test if its the TX/RX issue, simply use the sample sketch that plays; and if you get notifications that the play stopped then its more than likely not the issue.

[derbero]

This is the output for PlayMp3.ino:

initializing...
10:42:15.838 -> mp3.begin()
10:42:15.838 -> mp3.setVolume(10) - 1
10:42:15.872 -> Folders in SD

after that nothing is coming. Like all the getSomething() functions do not work...

[Makuna]

@derbero I am confused by your output, the sample PlayMp3.ino doesn't have those outputs. Did you modify it?
Take the sample, provide the required files, remove the following lines to remove the "get" methods.

  uint16_t volume = mp3.getVolume();
  Serial.print("volume ");
  Serial.println(volume);
  mp3.setVolume(24);
  
  uint16_t count = mp3.getTotalTrackCount();
  Serial.print("files ");
  Serial.println(count);

[Makuna]

#26
I added a new error, DfMp3_Error_RxTimeout, if your notification class OnError is called with an errorCode with this new value, then more than likely your RX is not connected and none of the get calls will work.

[derbero]

new output (the sound is fine saying "one, two, three"):

05:49:09.761 -> initializing...
05:49:19.837 -> 
05:49:19.837 -> Com Error 129
05:49:19.837 -> volume 0
05:49:29.867 -> 
05:49:29.867 -> Com Error 129
05:49:29.867 -> files 0
05:49:29.867 -> starting...
05:49:29.900 -> track 1
05:49:34.901 -> track 2
05:49:39.878 -> track 3

when uncommenting the lines the output looks like this (the sound is fine saying "one, two, three"):

05:54:33.117 -> initializing...
05:54:33.117 -> starting...
05:54:33.117 -> track 1
05:54:38.179 -> track 2
05:54:43.170 -> track 3
05:54:48.189 -> track 1

I have received other MP3 modules and they work just fine in my setup. So it seems more likely to be a hardware issue.

[Makuna]

The error is DfMp3_Error_RxTimeout (0x81=129). This means the device is not sending or has a hardware connection issue.

[derbero]

From my point of view this issue can be closed as it is most likely that the root cause is a hardware problem.