Directories that begin with the same string are indexed incorrectly
Closed this issue · 10 comments
A new issue has been found where if two directories begin with the same string, the player indexes them incorrectly.
For example, if you had two directories from the same franchise, they might have folders like this:
Shining Force
Shining Force II
The player will then index both of these folders together, giving incorrect values on how many tracks are actually in a specific folder. Eventually the player will jump out of those bounds and end up in an invalid state.
The probable cause of this issue is due to how the Arduino Menu library indexes directories using a startsWith() function, or something along those lines. Fixing this issue might take a little while due to the inherent complexity of the library, but I am aware of it.
A work-around right now would be to start similar directories with numbers preceding them, like so:
1_Shining_Force
2_Shining_Force
Also probably related to the same thing...
MANIFEST.txt <--- my manifest. (renamed to be able to be copied as an attachment here)
Added some to the microsd (which then updated the manifest) to test, it got reallly crazy from here. Everything in a strange order now, looks the same upon forcing a manifest rebuild. Also randomly now a bunch of tracks just skip around.
Just noticed the freefilesync db file, removing that file to see if it clears up the issue. At first I was thinking that some arcade system tracks with compatible chips were just not playing for whatever reason. Saw a strange one where columns 2 arcade was just rapidly changing tracks and I couldn't stop it, had to pull the plug. Interesting.
Deleting the ffs sync db file didn't fix the issue. Upon initial boot columns 2 does the same loop through tracks infinitely. If I play some other stuff, then it works occasionally. Kinda strange.
Hrm.. interesting. A friend of mine reported an issue with their manifest file too similar to yours. The text portion of the manifest file looks like it generated successfully, but the metadata bytes concatenated to the end look duplicated.
Try deleting the _SYS folder on your machine and letting the player generate a brand new manifest from scratch.
I'm actually going to be out of office for the next week, so I'll be on bug patrol the following week. Ditching this manifest system is something that I'd like to do in the future, but that's a pretty big fix, so it might take a bit of time. Hopefully the new system will patch out the original issue above too.
Just as an update for the purposes of providing more data if you need it, when I redid the manifest entirely (with a new folder layout, since I removed a few), this is the result:
Still gets out of order by the end of it.
When I wipe the manifest and start over, same result. So at least it's reproducible! :)
Just a progress report on this issue:
I've been working on a new way to ditch the manifest system at the expense of a little more memory usage. I've got a version that seems to be working pretty well right now as of this commit
Much more testing will be required before it's all done, but early signs look good. I'd also like to create a system to delete or avoid garbage OS files and directories like .DS_Store etc. Those files tend to not do anything terribly important and really only seem to exist to gum up my projects lol.
I am curious as an amateur at all this... Given that the chip you used in your design has instruction and data cache on the chip (unlike a typical arduino chip), have you explored the possibility of converting portions of your code from conditional programming (if-else, etc...) over to "branchless" (buzzword) programming (for then an array, then only do things on that which is in the array).
I've read it can reduce the load on instructions and cache in general to improve efficiency, but I can guess why this would be hard with something like VGM which has a lot of unpredictable variables I'm sure.
The manifest system as been removed as of this commit, though, that was a separate issue.
The current issue with the sequentially named folders has been determined to be a problem with the SdFat library that I'm using, not the menu library that derives from it. I've created another issue on the SdFat page here. Hopefully we can get a resolution from that post as the SdFat library is very, very complicated.
Thanks for your work on this! :)