Possible minor issue in Bootloader mode.

[kramgrand]

A club mate has just purchased a new XE transmitter and I was helping him with setting it up and getting everything updated to latest everything via Ethos Suite. Ethos 1.4.17 Part of the setup was adding a soundpack (Amber soundpack) to the radio, this was done as a bulk copy in Bootloader mode.

We encountered a problem when adding a “Special Function Play Track” to a model. The problem was that the audio files looked corrupted and all of file names started with ._ ie ._1cell ._2cell etc. The files did not play.

Under the XE radio system file manager, all the files looked perfect and there were no corrupted files present. Likewise when viewed via the computer (Mac) there were no corrupted files to see and everything looked good.

I tried doing exactly the same with my radio (X20Pro) when I got home.

Backed up my audio files via Ethos suite. Deleted all audio .wav files in the root of the audio folder. Downloaded the Amber soundpack from OpenTX org and unzipped it. In Bootloader mode, copied contents of Amber soundpack to Radio/audio. 525 files Ejected drives from the computer desktop and power cycled the TX.

In the radio file manager all the audio files look perfect, 1cell to zoom and likewise the same when looking from the computer. But when you try to do a SF play track the list starts with ._1cell all the way to ._zoom. From there and after ._zoom, you get it all again except correctly named. I.e. 1cell all the way to zoom. In effect under the +SF play track, you see twice as many audio files 1050 files with half of them corrupt..

In Bootloader mode, I deleted all the audio files from the TX, but this time used the Audio tool in Ethos suite to bulk convert the 525 audio files in one go to the audio folder on the radio. This time all the files looked perfect, as before in file manager plus there were no corrupted file duplicates when creating a Special Function. Everything was looking good and working again.

I just wondered if this is expected behaviour ? If it is, I guess there is no problem to fix. But if working with audio files in bootloader mode should work, then there is a slight problem. It certainly got me scratching my head for a while.

[bsongis-frsky]

Are you sure they are not hidden files on your SD?

[pstasek]

It's a Mac related issue where the OS is creating hidden files with metadata starting with a ._ on any USB drives. These files are not visible in the Mac system but appear in any other platforms.

More info about this Mac related issue here: https://forums.macrumors.com/threads/solved-prevent-hidden-files-creation-on-usb-drives.2022099/

[kramgrand]

OK... That is interesting and I am not saying your answer is not correct, but I have used a Mac for many years pre Ethos Suite. A time when you transferred files about only with Bootloader mode and this has never happened before. Also, if they are hidden files why would adding a SF playtrack unhide the files when the file manager and Mac Finder does not. I will transfer some more files without going through ethos suite and change file attributes to see if they appear. BTW the files are not on a SD card. They are loaded on the Radio drive/disk.

[kramgrand]

For testing purposes, I renamed the 1st file in the Amber sound pack from 1cell.wav to 1bell.wav. Copied it over via Bootloader mode to the audio directory, ejected the drives and restarted the radio. I can confirm that on adding a FS play track the file on the very top is corrupt or damaged in some way as it displays ._bell Again shows correct in file manager on the radio and Finder on the Mac. Restarted in Bootloader mode and navigated to the Radio/audio directory. On the Mac I unhid every drive path on the Mac with ( Command + Shift + . ) and sure enough a number of files were unhidden, none of which were .bell.wav. I then did a Spotlight search of the drives for any file beginning with . or ._bell.wav No file like that exists on the radio or on the Mac.

[bsongis-frsky]

@pstasek yes it makes sense to me So MacOS creates those files and Ethos sees them (I think they are not hidden, they just start with a .) We have decided to hide such files in the File Explorer of Ethos and it makes sense to me to hide them everywhere else in the firmware

[kramgrand]

Thank you gentlemen. After some internet searching I now see the ._ file issue is down to the Mac OS.

[pstasek]

I think they are not hidden, they just start with a .

Yes, in the Unix world, a filename starting with a dot means a hidden file as attributes are limited to read/write/execute. In the Windows world, there's a Hidden attribute and file starting with a . are visible as a regular file. It does make sense to hide files starting with a dot in Ethos indeed.

[bsongis-frsky]

Done in RC2 (coming in a few hours)