Flash drive not playing in car audio system

You have not indicated that your car stereo chokes on the .Spotlight-V100, .Trashes, or .fseventd directories. The removal of the ._ files whose names end in things like .MP3 and .AAC may be enough to make it happy.

I tested things with a couple of .JPG files and a flash drive called "PNY 32GB". Either of the following commands cleared off the metadata files whose names began with ._ and ended with .JPG.

dot_clean -m /Volumes/PNY\ 32GB

rm /Volumes/PNY\ 32GB/._*.*

The dot_clean command complained about not being able to remove .Trashes – but apparently did not skip over the ._*.JPG files as a result of the error. The rm command never tried to remove the directories in the first place. (The ._*.* pattern is general enough to work for .MP3s and .AACs as well as for .JPGs.)

If I ran the rm command when there were no ._ files, I got "zsh: no matches found: /Volumes/PNY 32GB/._*.*. The shell was complaining that there were no matches for the wildcard parameter. But here, no matches meant that the drive was already cleaned of the files likely to cause most trouble.

It depends on what format the car audio wants. I'd try to format with Disk Utility as FAT (MBR partition scheme).

If that does not work, try FAT (GUID). Or exFAT (MBR) or exFAT (GUID).

The dot files (.DS_Store etc) might confuse the car audio app. You can delete them with the macOS built-in dot_clean app:

dot_clean not working for me, what am I d… - Apple Community

There are also GUI apps for that like Blue Harvest.

https://apps.apple.com/kn/app/blueharvest/id739483376?mt=12

JohnA50 wrote:

The flash drive comes already formatted Windows FAT32. The technician's computer is Windows. I have tried formatting the drive every way available on Disk Utility so it appears the problem has something to do with Mac. Any more ideas, I'm all ears. I would really like to find a solution.

It's due to the Finder's attempts to preserve some Mac filesystem attributes and data on a non-Mac filesystem. The Finder creates various files whose name begins with "." for this purpose. (In Unix, using a leading "." is how you would hide a file from ordinary directory listings. Mac OS X / macOS is based in part on Unix.)

The files that really throw non-Mac devices are the metadata files that have names like

._SONG1.MP3

._SONG2.MP3

._PICTURE3.JPG

._PICTURE4.JPG

A non-Mac system will often look at the .MP3 or .JPG extension, decide that the file must be a MP3 or JPG file, discover that the "MP3" or "JPG" file is "hopelessly corrupt", and then complain loudly.

Generally speaking, for a .MP3 or .JPG file, you don't lose much even if you do delete the ._* metadata file, and then later copy just the main .MP3 or .JPG file back to a Macintosh file system.

It seems you did not put a space after "dot_clean -mn" so the command failed to go to the desired folder.

The command works despite some errors because it has no permissions for folders like .Spotlight-V100. You can see what the command does by using "dot_clean -mnv " (-v for verbose). Or with "dot_clean -mnf " disable the futile recursive peek into those folders without permissions.

And to check what is left use "ls -al "

The command in the thread to which I linked was

dot_clean -m /Volumes/volumeName

where you replace volumeName with the name of your flash drive (and enclose the whole /Volumes/volumeName in quotes if there are any embedded spaces). No -r flag and no -n flag. The error you got strongly suggests that the -r flag is not a valid flag, at least not in the version of dot_clean you are using. When I do a

man dot_clean

in Ventura, the manual indicates that there is a -m flag and a -n flag, but no -r flag. (There is a -f flag to do a flat merge; so if -r meant "recursive merge" in an old version of dot_clean, that is now the default behavior, and "-f" would be the way that you shut the recursive merge off.)

Remove the 'r' and try it with just '-m' or '-mn'.

JohnA50 wrote:

I entered dot_clean -m /Volumes/John and click run. This is the result:

Failed trying to change dir to .Spotlight-V100

Bad Pathname: Operation not permitted

Failed trying to change dir to .Trashes

Bad Pathname: Operation not permitted

[Process completed]

You could try doing a

dot_clean -fm /Volumes/John

The addition of the 'f' flag would keep it from trying to recursively clean any directories other than the top-level one. This might get rid of the Bad Pathname errors for .Spotlight-V100 and .Trashes. This would also leave the .Spotlight-V100 and .Trashes directories on the flash drive, but the car audio system might not be confused by those directories the way it is confused by ._*.MP3 metadata files.

One drawback is that if you had subdirectories on the flash drive, you would have to clean those separately.

Granting Terminal Full Disk Access might avoid the need to use 'f'. Ventura seems to be more locked-down that previous versions of macOS. I haven't tried experimenting yet to see what happens.

> Failed trying to change dir to .Spotlight-V100

As I tried to explain, also I get that alert because dot_clean has no permissions for folders like .Spotlight-V100.

But despite that error, the dot files should have been removed. I guess those invisible folders should not bother the car audio player. At least my television don't mind them when using an USB stick to watch movies (I sometimes remove the dot files, but sometimes just ignore the TV's alerts about them).

You can see what the command does by using "dot_clean -mnv " (-v for verbose). Or with "dot_clean -mnf " disable the futile recursive peek into those folders without permissions.

And to check what there is before and after the commands, use "ls -al "

See this Apple Communities thread for a full discussion: Problem with Music Files on USB Drives

For a quick fix, see the post by Barney-15E, on the first page, describing how you can set up a Shortcut to let you run the shell commands to clean a USB flash drive (dot_clean and diskutil eject) from the Finder.

JohnA50 wrote:

I have no idea what the car stereo chokes on.

Well then, how do you jump to the conclusion that making things work is impossible, when you apparently have not followed the explanations in this, or other threads, as to the likely cause of the problem?

Removing items whose names end in .MP3 would remove the music as each tune is an MP3.

Removing all files with the name ._*.* or ._*.MP3 would not remove the music. Those patterns only match .MP3 files whose names begin with "._". If you had been paying attention, you would know that these ._ files contain metadata – not the songs themselves. (Assuming that you are not in the habit of manually creating ._ names.). Use the Finder to copy SONG.MP3 to the flash drive, and the Finder copies it as SONG.MP3 and ._SONG.MP3. The SONG.MP3 gets the main contents of the file, and the ._SONG.MP3 is a holding place for metadata which Mac filesystems maintain, FAT32 ones don't, and the Finder is trying to preserve, "just in case" you ever copy things back from the FAT32 filesystem to a Mac filesystem.

It is the metadata files that are most likely to confuse a car stereo player, TV, digital picture frame, etc. as those are the files whose extensions (.MP3, .JPG, etc.) lead the device to INCORRECTLY conclude that these files are MP3 music files, JPG picture files, etc. When the device tries to use them as such, it discovers that they are hopelessly "corrupt."

Removing them gets rid of the most likely source of confusion, whether or not you get rid of the other unwanted directories.

As I have indicated in several posts there are three items that I can see on the flash drive other than the music; .fseventsd, .Spotlight-V100 and .Trashes. None of the commands recommended by any of those who helpfully replied did anything to solve the problem.

You haven't demonstrated that the .fseventd, .Spotlight-V100, and .Trashes directories are the problem.

The goal here is not to remove all of those directories, just for the sake of removing them. That might be nice – but it looks like the tightened security in recent versions of macOS is making that difficult even for Admin users.

The goal is to prepare a USB flash drive that the car stereo will happily play. Removing the ._*.MP3 metadata files that the car stereo misinterprets as corrupt MP3 music files may be enough to achieve that. You won't know until you actually prepare a flash drive from which you have cleaned the ._*.MP3 files, and tried it out in the car stereo.

I don't have a Vauxhall car with your particular car stereo, and so I can't try that part out for you.

Chances are the USB drive, to which the technician downloaded the files, was a Windows format (FAT32?). Have you tried formatting your USB as that? Or exFAT, or NTFS? I'm not really current on preferred non-Mac formats.

FAT32 started as a Windows file system. Even when you are copying files from NTFS volumes, Windows is probably not trying to preserve any extra metadata that NTFS files might have. (I don’t know offhand what it does with regards to the Recycle Bin; the Windows version of the Trash.)

On the original Mac, files could have a data fork (corresponding to a file on most systems), a structured resource fork, and type + creator codes to help the Finder open files with rhe right application regardless of their extension. Applications, in particular, had their code, icons, menus, etc. in their resource forks, and a trip to a foreign file system that did not make provisions for preserving the resource fork would destroy the application. In the early days, Mac users who had to send shareware and fonts through non-Mac systems would use special third-party tools to encode all of the pieces of a Mac file into a single flat file for transit, and unwrap the pieces on other Macs.

Mac OS X moved away from using resource forks, and from exclusive reliance on type + creator codes … but the file system capabilities to store those things are still there. I expect that it was this that led to the code in the Finder to create the ._ metadata files. It was an attempt to increase backwards compatibility that in practice wound up introducing more compatibility problems (different ones) than the ones it actually solves.

Well, do a

man dot_clean

in the Terminal, and see what that has to say about the Big Sur version of the command. (The man command shows you manual entries for other commands.)

If I remember right, someone else had a similar problem. It turned out the Mac was adding an extra file that was not an MP3 to the flash drive that the car audio system couldn't read and therefor would not play the entire flash drive. See if that might be the problem (by verifying with another computer).