@NoSloppy Thanks, cd common worked like a charm with that line uncommented, but didn’t really produce anything helpful. Peep the output here: Voice Pack C serial readout - Pastebin.com
For comparison, here’s the Voice Pack A output:
Something really funky going on here, not sure what.
Scanning sound font: commonCounting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Counting vmend.wav as vmend
Counting vmbegin.wav as vmbegin
Wow that is STRANGE.
I tried it on my end and get the same result as you did for Voice Pack A with both C and A.
Is it possible that something in the metadata of the .wav files is causing the OS to get wonky?
Good call, but i checked that. Metadata is clear. I did that for all of the packs.
See if these are any different for you. They are exactly the downloaded version of C, but I don’t have the issue with them.
ProffieOS doesn’t even look at the contents of the files during the scanning phase, it only looks at the available filenames.
Hopefully I have time to give this a try myself tonight.
@profezzorn and @NoSloppy, thank you guys for looking into this! I haven’t done much further investigation, but have been ruminating about potential issues. Only thing I can think of is I have been compiling the ProffieOS from a Macbook, not a PC. Have had no issues really besides this one. Any chance Mac OS could have anything to do with it?
I have a recurring audio dropout issue I’m investigating as well that I’ll post about on a different thread. Appreciate you guys!
-Nate
You could try deleting the hidden resource files that MacOS copies onto the SD card because it’s FAT32.
Open Applications/Terminal.
Type cd (that’s cd with a space), then drag the SD card icon onto the Terminal window to auto-fill the path. Hit return.
Type cd common to go into the common folder.
At this point, if you type ls -al you should see a directory listing of all the Voicepack files and folders, including invisible ones that are the same names but start with a dot.
These are what you will remove next.
Type cd .. to go back up one level to the root of the SD card.
CONFIRM that the prompt says the path to the SD card root, something like /Volumes/SDcardName
Then type (or copy and paste this)
find . -type f -name '.*' -delete
Doing ls -al again now should show the files and folders starting with a dot are gone.
You can cd common and list the contents, should have just the actual sound files in there.
Put in Proffieboard and test.
@NoSloppy Thanks, I’ll let you know when I give this a try. Also, any idea why my above post and subsequent comment (both with PasteBin links) got flagged as spam?
Odd. No idea.
Well, another report of this vmbegin / vmend thing happening on Facebook. Odd indeed.
" Anyone ever run into an issue with the scanning of the common folder? I was setting up my thrawn hunter shoto, and I kept getting “error in font directory”, at first I couldn’t even get an error in console, but after removing all the fonts it still happened. So then I formatted the sd card, redownloaded proffieos, even made a new config, and now it does work, but loading takes FOREVER. From the console tho, I can see it’s not the fonts making it slow, it’s the fact that it scans common every time and every scan seems to hang there.
I also had to delete vmstart.wav and vmend.wav, as for some reason if present they are getting scanned 256 times on boot and every font change. Thus console is complaining 1 != 256 even though it detects only an unnumbered file.
I’m assuming it’s somehow related to the file names and the substring logic, but with all the bit shifting I can’t follow it and I’m also pretty sure it’s somehow related to the subdir logic change, but I’m too used to managed code and can’t figure out which loop is acting up.
I even downloaded alternative voice packs to try in common but same result.
It makes no sense 
I can’t even figure out how to make it just not scan the common folder despite my best efforts."
It might be some sub-folder thing, or it might be a corrupt sd card.
Until we can figure out how to reproduce the problem it’s hard to know.
The FB post is me.
I was also able to reproduce this, and I’ve noticed a few things. I did as you suggested and the other guy proved, it is scanning the folder 256 times. It happens at boot AND every single font change.
You can make the error go away by just deleting vmend.wav and vmstart.wav, but it still makes boot and loading fonts slow as hell. I also tested with various voice packs but no joy.
When you change fonts the console reports:
Scanning sound font: Ronin done
Scanning sound font: common (10-60s delay and then…) done
I spent a ton of time trying different fonts before I realized that common was at issue, as originally I could only get the failure to happen at boot and I didn’t know how to get it to boot while usb was passing power lol.
But once I realized the reset button would do it (or I could just flash and it would reconnect (or I could leave it set to Butterfly-L433CC since no matter what I do, it will not maintain Proffieboard & USB at the same time) I finally got the errors.
I have refreshed multiple times, nuked my proffie os and downloaded a new one. Nuked the voice pack(s), downloaded again. Tried new SD cards. Tried with just 1 font. Even made a totally new config with the 7.0 configurator.
I also did my best to figure out how to go into the scans and make it not check common with every single font change, but my C++ is too weak (managed code dev) and I’m pretty sure I am not matching the right value cause everything is char not string.
I also tried outright doing:
if num_files_ is 256 set to 1, and it does clear the errors, but it doesn’t solve the problem of the huge scan every time, it just makes it not error.
I feel like there has got to be some way to make it only scan common on boot, not font change (really the same should be true for fonts tbh), unless the card is removed, cause there is no way the font will just suddenly change itself. But I can’t find the right spot to do it. Either way there must be SOMETHING causing it to scan 256 times, but I have no idea what.
I do think its somehow related to the subdir logic, but I can’t make sense of it completely cause bitshifting makes my brain hurt.
The weirdest part to me is that it specifically counts the files 256 times without fail, never more, never less. Cause 256 seems odd unless something is converting to uint8 or similar.
Weirdest part is I had used the same exact os to flash other sabers that were previously setup, and those work fine. That said the SD cards for them are older, but I tried swapping cards, using other configs etc, nothing seems to work.
The other folders all process super fast, it’s ONLY common that’s having issues. And seems to only be those 2 files, though at least originally changing vmbegin to vmbegin1 fixed that one, but the same change to vmend did nothing.
I think it’s somehow related to some substring logic (the actual parsing failure), but I can’t for the life of me determine what the 256 scans are caused by. It feels like there is a loop within a loop where there shouldn’t be but I can’t find it.
Edit:
And to be clear, as best I can tell after loading, the saber works perfectly fine. It is only the initial scan. The fonts and sounds all seem to work as best I can determine.
Oh also forgot, I am also working from a Mac, so that part is also in common.
Is this a V2.2 board, or a V3.9 board?
DId you uncomment the line in effect.h above to see what it says about vmbegin and vmend?
Did you try a test of putting common first in the font search path of the preset?
Did you try an older OS like 6.8?
2.2, and yes I uncommented the line, like I said… you can literally see (and I counted) it scans 256 times.
I was however wrong about the other voice packs. It looks like it must have failed when I tried to use pack B (I even did it again now where it “copied” but then said directory not found). But if I copy the whole common folder from pack A or B it works fine. Same with pack C and it goes right back to choking.
I went ahead and tried something a bit more thorough:
{ "Sorcerer;commonA", "tracks/sorctrack1.wav",
StylePtr<ThrawnHunters>(),
"Sorcerer"
},
{ "SorcererBeskar;commonB", "tracks/sorctrack2.wav",
StylePtr<ThrawnHunters>(),
"SorcererBeskar"
},
{ "Ronin;commonC", "tracks/dueltrack1.wav",
StylePtr<RoninRed>(),
"Ronin"
},
{ "Bandit;commonD", "tracks/dueltrack2.wav",
StylePtr<BanditRed>(),
"Bandit"
},
};
Sure enough, no errors for styles 1,2,4, but the one with commonC set immediately reverts to that awful slow loading garbage.
So I did 2 more tests and I was able to learn one more thing, the problem IS with voice pack C, but it is NOT vmend or vmstart.
I tried using pack C and swapped just those 2 files with pack B, and it still gave the errors. Tried again using pack B but using vmend and vmstart from pack C. That works fine (and I checked, it totally uses the right voice for volume start/end, and a different one for the rest as expected).
So there is SOMETHING in pack C that is causing it to behave incorrectly and it is NOT the 2 files that actually get complained about, but I have no idea what it actually is.
Upside is at least using a different pack is a more pleasant workaround than deleting the 2 files like I was before. I’ll take a less preferred voice pack to the 20+sec font loads. It was especially awkward when swapping fonts with the blades ON, cause it would just go silent, but the blade would stay lit and nothing would happen for 10+ sec. Then back to working.
Now back to troubleshooting my other thrawn hunter. I’m even more confused by that one, but I’m gonna redo its config with the new generator and see if that solves it, cause it seems to just start half the time perfect and the other half something goes wrong and like the blade ignitions stutter, and you can see the underflows blow up. But I just restart it and it works. The new configs are formatted a bit cleaner, and I’ve realized that doing substyles to reuse 1 style for multiple fonts isn’t really viable, or not how I’d like it. I wish I could pass arguments to the function styles, mainly 1 for color and 1 for layer. But I guess its probably more efficient to make each layer its own function anyway, and I don’t mind the color bit cause its easy to fix in hilt. Having to go in and manually edit layers was a PITA, and you end up with duplicate built in styles anyway.
Please test this re-export. I see no reason it should be different, but maybe whatever the issue is got ironed out in the process?
Not that that helps figure out the problem, but there really shouldn’t be any problem, so if this makes it all go away, I’m here for it.
I’ll give it a try a bit later, but I even pulled it off another saber that is working (I think it’s on 6.9 or something) and it still whined at me. But who knows maybe it’s some weird zip issue Mac’s have with that 1 file lol.
I’m wondering if maybe there are directory entries with no name somehow?
I’ve some PVLOG_DEBUG and PVLOG_VERBOSE statements to the code on github master that should hopefully tell us what is going on.
Please try ProffieOS from github master, and add the following to your config file:
#define PROFFIEOS_LOG_LEVEL 1000
Then paste the serial monitor output here, and we’ll see what we can see.
I will give it a shot once I finish up with work this afternoon. Can’t focus too much on sabers mid shift lol… well I shouldn’t 
Got this burning in the back of my brain about this unsolved mystery…