"File format not supported" randomly appears

Thanks for the report.  This seems consistent with the report of others, concerning issues with microSD cards over Class 4 in speed.   :frowning:

Thanks for the report.  This seems consistent with the report of others, concerning issues with microSD cards over Class 4 in speed.  

You said your Clip+ is Rockboxed though. The Sandisk firmware seems to have issues with cards that are faster than Class 4. Rockbox handles these faster cards just fine. Unfortunately there isn’t Rockbox for the Clip Sport.

Having the exact same problem with largeish (50-something mb) mp3 podcast files from the CBC (Canadian Broadcasting Corporation). They play for the first 15-20 seconds and then a “File format not supported” message appears and the device skips to the next track. These are on the internal memory of the device, and besides that I’m using a Class 4 microSD card for other files.

Any prospect of a fix for this issue in an upcoming firmware update?

Thanks.

Correction: the files this has happened with actually play for 33-34 seconds. Not every CBC podcast file is doing this. Just did firmware update 1.17 (since my last post)—didn’t fix the problem.

What bitrate are the 50MB podcast files? For voice recordings, imo 32kbps MP3 mono is probably the best choice, as higher bitrates don’t improve the sound of voice recordings much. While 32 kbps wma files sound a bit better than 32kbps mp3 files, playing WMA files seem to consume more battery power and give shorter run times. Using 32kbps mono instead of 128 kbps seems to give me at least 10% more run time per charge.

After I download podcasts, I typically convert them to 32kbps mp3 mono if they are at a higher bitrate. Some podcasters are now using 32kbps.

Anyone find a fix?  I have the same problm with  a brand new player

I just bought the Sandisk and used windows media player to populate the Sandisk 32G memory card.  My files are .wma and some play while others don’t? I get that same “file format not supported” and then a screen appears as if it were trying to play, but there is no progress across the bar and no sound.   It displays the correct album/song info, but shows a 0:00 length.  Has anyone else had this problem?

K.

@kgardner58 wrote:

I just bought the Sandisk and used windows media player to populate the Sandisk 32G memory card.  My files are .wma and some play while others don’t? I get that same “file format not supported” and then a screen appears as if it were trying to play, but there is no progress across the bar and no sound.   It displays the correct album/song info, but shows a 0:00 length.  Has anyone else had this problem?

K.

Are some of the files (the ones that don’t play) ‘protected’ (aka DRM-encrypted) .wma files?

I get this with everything. I use the ogg-vorbis file type for my music that I ripped from CDs. Every song is 44100 Hz sample rate,140 kbps bit rate, downmixed to mono.

I can grab 30 folders and copy them at once or carefully copy one folder at a time. It just doesn’t matter how I get music on it
I just know that I will stick to my Sansa Clip (not clip+) with it’s slowly failing battery until this issue is resolved

I had posted in this thread before and my issue was solved with the 1.22 firmware update found here:

http://forums.sandisk.com/t5/SanDisk-Clip-Sport/SanDisk-Clip-Sport-Firmware-1-22-released/td-p/335935

Even if your player is new go to “Settings” >“System Settings”> “Info”, and verify your firmware “Version”.   If it is not 1.22 then update.

I hope that helps solve your problems!

Yes, this works for the NPR podcasts that it didn’t work for!  Thanks!

I get this issue occasionally, even with the newest firmware update. It generally happens with .mp3 format podcasts (since I usually put those on the external card), but without fail the problem’s just been that the card has become slightly unseated - it seems to stick out quite a bit more compared to the older player models, making this happen more frequently.

Ejecting and replacing the card has fixed the problem every time (also, hitting the ‘back’ button repeatedly can usually break the player out of its scan through every file on the card).

I found out if you just change the format which you download from a cd from standard on window’s media player to mp3 that it works

It might have something to do with the DRM (Digital Media Rights) for the music files.  I a experiencing the same problem on my

clipsport, and it doesn’t even have a external card.

“I found out if you just change the format which you download from a cd from standard on window’s media player to mp3 that it works”

The default for Windows Media Player is to rip to protected WMA. The Clip Sport doesn’t support protected WMA files. I now rip CDs to 320 kbps mp3. I used to rip them to 256 kbps mp3.

 Make sure your file is no greater than 8 bit

(if you created this sound file, it may be 16, 32 bit)

Has a fix to this problem been discovered?  

I have a brand new clip sport + I bought last week, and am running into the same issue:

Several podcases downloaded over the last few days (The Moth and Fresh Air so far) play betwen 20 and 40 seconds, then the ‘File format not supported’ message appears.

  • the files are mp3, 128kbps, loaded onto the internal memory. 

  • As I said it’s brand new, so the firmware is up to date, but I reinstalled v. 2.02 anyhow

  • I ran CHKDSK /R /X on the internal memory.

  • the files aren’t particularly big, 20-40 meg.

  • the files are NOT corrupted - I can connect the device to my computer and play the mp3 from the device on my computer just fine.

I’m REALLY annoyed by this - apparently this problem goes back to 2014?  And the only “solution” offered is to re-encode downloaded podcasts?  I love these little devices, I use them every day  - this is my 3rd or 4th one.    The older versions of the Clips never needed these files to be re-encoded or any crazy workarounds, I can’t remember ever having this problem with any mp3s,  whether downloaded or ripped.

Use CLASS1 SD-card ony (solved and tested)

In having the same issue on mines too i think it’s a firmware bug