Found blst files : one unnumbered file in subdirs in Return
Found font files: one unnumbered file in subdirs in Return
Found Vmend files : one unnumbered file SOME FILES ARE MISSING 1 256 in common
Found vmbegin files : one unnumbered file SOME FILES ARE MISSING! 1 256 in common
Found lowbatt files : one unnumbered file in subdirs in Return
Found ccchange files: one unnumbered file in Return
There is definitely a vmbegin and vmend, but why is it thinking there’s 256?
This is not a global issue, only random user here and there it seems that this happens to.
In this case,
Formatted SD card.
Tried nesting in font.
Other voicepack’s vmbegin and vmend don’t make it work.
No metadata.
ok resolved.
The issue actually IS the hidden resource files that MacOS writes to the SD Card.
Using #define PROFFIEOS_LOG_LEVEL 500, it showed it was scanning 256 times in that instance, and sometimes there were 57000+ lines of scanning all the hidden files just wreaking havoc.
@profezzorn Maybe we can tell the scanning to ignore files that start with a dot?
Somehow, due to a bug, or a wonky font, it’s actually reading the (same) file 256 times. This seems unlikely or impossible based on reading the code.
Compiler bug (try 3.7.0 plugin)
A bug somewhere (could literally be anywhere) is overwriting these values. I may be able to write some code that can narrow down when the problem occurs though.
Can you share the serial log output?
I’d like to understand exactly how this happens.
(Ignoring files that starts with a dot would work for this partcular instance, but who’s to say that the same bug can’t occur if you create a file that starts with a comma or something?)
Copy files to FAT32 formatted SD card using MacOS.
Invisible resource files are written to card, one for one of the originals.
Here’s a snippet of the ls
-rwxrwxrwx@ bconner admin 0 Dec 20 2021 battlevl.wav
-rwxrwxrwx@ bconner admin 0 Dec 20 2021 chreobgn.wav
-rwxrwxrwx@ bconner admin 0 Dec 20 2021 chreoend.wav
-rwxrwxrwx bconner admin 4096 Nov 11 15:06 ._battlevl.wav
-rwxrwxrwx bconner admin 4096 Nov 11 15:06 ._chreobgn.wav
-rwxrwxrwx bconner admin 4096 Nov 11 15:06 ._chreoend.wav
Doing this resolves the issue: find . -type f -name '.*' -delete
It was done remotely and the window is long closed.
But essentially it was 57000+ lines of the VLOG for SCAN: filename where the filename was invisible files, and for some reason it was repeated ~700 times per file.
That’s unfortunate, I was hoping there would be a clue in there.
This is the crux of the matter. I don’t understand how the code can do that.
If this didn’t happen, then these resource files would be a minor inconvenience, nothing more.
Assuming it can be recreated, what would some additional VLOGs be to help reveal what’s going on?
I can add them and hit it hard until hopefully something useful rears its head.
Additionally, got some additional lines of code to filter for .* that I could test while I’m at it?
Really the first question is if it’s somehow going into a sub-directory and the name of that sub-directory ends up being empty, or identical to some other directory, basically failing to concatenate paths.
OR
Is it somehow starting over while reading the directory entries, so that it just appears like it’s one long directory with 57k files, but in really it’s just skipping back to the beginning again for some reason?
Skipping files that begin with . doesn’t fix the problem, it may hide the problem, but that’s even worse.
So this is still a thing then. When you have a chance let me know.
We can do a virtual meet to see if it happens on the newer stuff like say Apple’s Ventura OS.
(I’ve backed away from OS Sonoma for now.)
@NitTheGrit Can you please take a look on your side too since I know what Apple OS you’re on?
Another thing that might be helpful would be a disk image of an sdcard that exhibits this problem. With that I might be able to reproduce the problem myself, and if I can reproduce it, I can fix it. (please note, directory listings or screenshots will not help.)
I’m using MacOS Ventura 13.2.1
ProffieOS 7.9, 3.6, with Arduino v1.8.19
I can confirm that I am seeing hidden copies of font folders as well as hidden copies of each of the individual files within those font folders copied to my SD card.
FWIW this saber is using a proffie v39 board.
This is normal behavior for MacOS.
The issue at hand is why ProffieOS would have issue with the invisible files, specifically that it bothers with them (they should be getting ignored) and then why it would iterate over them numerous times.
It may still help to have others sharing what they see though since you all are gonna love this part. Running the delete input I get operation not permitted.
Example from the new laptop. Late 2022 MBP, OS Ventura 13.6, ProffieOS 7.11 w the 3.6 plugin and Arduino 1.8.19
Before.
[First image pulled as per forum rules now that the info has been seen.]
After.
[First image pulled as per forum rules now that the info has been seen.]
*Shutting down for the night and will check back later.
I don’t really understand the post . You say you don’t have “it” happening anymore. Have what happening though, the Error in FOnt Directory issue?
You expectedly have invisible resource files, and you should just use a list, not a screenshot.
Recheck my reply. I was mid-edit and it’s late so a pair of screenshots were in-kind with what @profezzorn replied.
I’m not gonna keep posting images going forwards. Just showing it is happening again is all.
As expected it also is NOT dependent upon the SD Card maker. I get it on three different brands.
To clarify for you, he meant a compressed disk image with the file structure intact, not a picture “image”.
You won’t be able to delete the Spotlight index or the trashes, so permission denied is expected.
The .DS_Stores are just a windowing position/icon placement save that is also not going to be any issue.
The relevant things are the invisible copies of the audio files themselves.
I understand what @profezzorn meant now and may I humbly suggest making a topic reply in the Best Practices topic outlining the steps to do that since I can’t even remember how to pull down that type of list as I use it so seldom. *You and I actually covered this but can’t find the steps so either way it’s good for other Mac users here to know this.
Another thing to note @profezzorn is that the troubled SD card had been formatted using MacOS built-in Disk Utility. SO the resolution might very well have been using SD Formatter instead, since I had him do that too before copying files to the SD, then deleting invisibles.
I always copy to SD using MacOS, do not delete hidden files, and haven’t had the problem. I also always use SD Formatter. so…