Is there a maximum number of wav files that the system can cope with in a single folder? I have a force folder with 345 wavs in it and I’m getting the “Error in Font Directory” warning. Numbering is all consistent and correct, but if I strip out a couple of hundred wavs it all works.
That’s what I thought. Which makes this an odd one.
I have 345 files in the folder, all numbered correctly, but when I run ‘effect’ it says:
20:06:38.854 → Found force files: 7-345 using 2 digits in subdirs SOME FILES ARE MISSING! 339 != 17600 in FontPrem/Graflex
(Apologies for the screen shots Prof - just showing the SD card contents are correct).
Have tried the same folder on two systems with two SD cards, and both give the same result. I also tried deleting the first half dozen or so wavs, renaming everything else from force1, then adding the deleted wavs back at the end from 339 to 345.
You can list the files and use that instead of the screenshot.
Type cd then a space, then drag the folder you want to list onto the terminal window to autofill the path.
Type ls > list.txt to create the text file in that directory.
You didn’t show 339, although I assume it’s there since you said all numbered correctly.
Why it starts at 7 I have no idea.
It’s a bit of trial and error, but I’d be curious at what point the problem starts. Like, have 200 in there see if it works. Go up to 300, see if it still works, go to 350, did it break yet, etc…
All that said, I’m curious what the heck you got going on in 345 files? LOL
Theoretically, the limit is 32768 I think.
However, once you go above a few hundred, you will start getting buffer underflows every time the effect is played. (Unless you have a Teensy4 setup, which reads SD cards much much faster than Proffiieboards.)
This suggests that it expected 339 files, but found 17600, which doesn’t really make much sense, unless alt-directories are involved somehow.
The more likely scenario here is there is a bug in the scanning code, and it’s double-counting some files for some reason. We’ve seen bugs like this before, but have not been able to narrow down what causes them. I might be able to add some VLOG statements to the code, which might help us figure it out though…
It’s within the rules, but it doesn’t show that all files are present. File 245 might still be missing.
However, it does show that the numbering is inconsisent.
force01.wav has two digits, while force345.wav has three.
There are two options: either make all files use the same number of digits, or remove all leading zeroes. (So it’s just force1.wav) ProffieOS should handle both cases.
Yeh, that was me experimenting - initially it was just force1, force2… force345 etc. I tried adding two zeros to see if it made a difference but it didn’t.
And yes, the idea with the screen shots was to show they started at force1 and ended at force345, with the very bottom number showing that there were 345 files in that folder. But the point is noted and Brian’s suggestion was much better. Will make a note of it for next time as I seldom venture into Terminal.
I did wonder what the 17600 referred to. I thought it might be the amount of memory used, but clearly not. (And no, there’s nothing fancy in the config - no alt-directories or anything like that).
I’ve no idea if it’s relevant or helps, but I tried stripping out wavs 25 at a time.
Had to go down to 95 before it was OK. BUt then bizarrely I went back up a few increments and was still working at 125.
Thanks Brian - I’ll take a look at that.
I’ve always just used the one built into MacOS, but it has its limitations - one of which is you can’t specify, for instance, Force01 - it will only let you do Force1. Looks like yours has a few other features too. Downloading now…
I looked at the code, and there is simply no way for the num_files_ counter to go to 17k without actually counting 17k files. (Which it absolutely did not do according to the serial monitor.)
The code simply loops through the files, it shouldn’t matter if there are 10, 100 or 100000000. The only difference should be higher numbers and more time. The fact that the number of files matters makes no sense. It would be like a movie changing the second time you watch it. (And I don’t mean any special edition shenanigans.)
So… maybe it’s a compiler bug?
I suggest trying version 3.7.0 of the Arduino-Proffieboard plugin and see if that helps.
Instructions for how to do that can be found in this thread: Gcc 12.3 (new compiler maybe)
Unfortunately I just tried loading that but got this error:
Caused by: java.lang.ClassNotFoundException: org.tukaani.xz.XZInputStream
... 5 more
It might be my system as I’m on MacOS 10.15 Catalina which is a little long in the tooth now, but don’t want to change it as I have a couple of mission-critical apps I use which I can’t afford for Apple to break for me… sorry, I meant upgrade.
Apologies - I’m going round the houses a bit here. I thought I’d successfully loaded the 3.7.0 plugin, but it turns out it had indeed thrown the error from two posts ago. So unbeknown to me I’ve just loaded the config using 3.6.0…
…what’s weird is that has now fixed the font directory problem!
So maybe it was my 3.6.0 plugin that had got corrupted and messing around reloading it has straightened it out.
I will keep an eye on it, but for now it seems to be working. But as I say, the bad news is I can’t load the 3.7.0 plugin which I know is a work in progress.