The order of file names 0001 0002 is not the order of file names,

[semibank]

The order of file names 0001 0002 is not the order of file names, but the numbers are played according to the file modification date.

this library does not read files in order of name, but rather determines the order based on the file modification date. Please correct the error

The way to check for errors is to set the most recent file modification date to 0001xx.mp3.

If you designate a file with an old modified date as 0002xx.mp3 and play 0001xx on Arduino, you can see that 0002xx is actually played.

I don't know why the number is determined by being rearranged in order of modified date.

[zoldaten]

the library DOES NOT play in order files!
even i set myMP3.play(3) - it plays not 003.mp3 but some other file.

spent hours while found this issue!

[zoldaten]

i found the way out.
i create folder on sd card named '01' and put there all my files:

then in .ino file i called:
myMP3.playLargeFolder(1,35) , where i is track number.
and it starts working as expected.

[prodestrian]

This is a hardware limitation of the DFPlayer itself, it's a known issue and not something this library has any control over (it's the same with all DFPlayer libraries). It's actually nothing to do with the file modification date, it's the order in which the file is written to the SD card.

If you copy 0002.mp3 then 0001.mp3 to the SD card in that order, then playFile(1) will play 0002.mp3. This is even documented on the official website:
https://wiki.dfrobot.com/dfplayer_mini_sku_dfr0299#Copy%20your%20mp3%20into%20you%20micro%20SD%20card

NOTE: The order you copy the mp3 into micro SD card will affect the order mp3 played , which means play(1) function will play the first mp3 copied into micro SD card.

This is only a problem with files in the root folder though, as @zoldaten pointed out above you can work around this by creating folders. Even one single folder should be fine.

[sercona]

I plan to have a 'make' procedure that will do (on linux) mkfs.vfat, then mount, then copy file 1, then copy file 2, one by one, blocking between. if paranoid do cli 'sync' every so often.

I learned not to trust file naming. fat dir table entry order (when you copied the file first to the disk) almost always is the first thing cheap chips do to 'sort'.

if you have to add a new file, start from the beginning and re-run that script that formats and copies each by, by name, one by one.

btw, here's what I just used on linux to copy files in sorted order. lets assume sda1 is the partition.

% sudo mkfs.vfat /dev/sda1
% sudo mount /dev/sda1 /mnt
% cd some_folder_where_your_files_are
% sudo bash
# find . | sort | cpio -pvd /mnt
# sync
# umount /mnt
# exit
%

you should get the general idea. make a brand new 'filesystem' each time you have to update that folder. force a fresh 'mkfs' with vfat.

I dont run automounters so I mount and copy and umount as root.

key is the find . | sort line. cpio WILL copy in the order given, one by one and so by doing a sort, you feed the 0001 file before the 0002 file, etc.

cpio is not often the first cmd to come to mind, but it sure has its uses.