I can make my Clip+ backlight stay on indefinitely. It’s set to turn of in 5 seconds and does unless the following is true:
Be playing an MP3 file from the Music screen. (does not happen on podcasts)
Go to the ‘Track Info’ screen and scroll down to the section which shows the file’s bit rate and sample rate.
Don’t touch anything, let the backlight turn off.
Backlight does not turn off.
Using the latest Clip+ firmware 01.02.16
Other notes: My music files are VBR MP3 with replay gain tags. Tags are ID3v2.3 latin1, no ID3v1 tag.
Verified that my player acts similarly, with firmware version 13. The track info. screen that shows the bit rate (i.e., the 3rd “page” of the track info.) reverts back automatically to the currently playing info. screen at 15 seconds or so, my setting for the backlight (the revert time seems tied, upon my experimentation, to the backlight time setting–when I set my backlight setting to 5 seconds, the reversion occurs at 5 seconds); and then at that point, the currently playing info. screen stays on (at least for a few minutes; I didn’t go beyond that). This behavior (that is, the backlight refusing to turn off) does not occur for me with the other track info. pages (i.e., the 1st, 2nd and 4th pages of the track info.).
The easy answer, of course (if you don’t want a perpetually-on state): don’t simply leave the player at the 3rd track info. page or let it automatically fall back from there to the currently playing screen.
I just finished playing around with this some more, installing different firmware versions and setting different backlight times. In all cases, including the the latest fimware version 01.02.16 and the parameters specified above (Backlight - 5 secs. Bit & Sample Rate screen in Track Info) I find I cannot duplicate the issue of the backlight staying on as color43 suggests.
No matter what backlight time setting I used, the backlight would go off at the prescribed time (5 sec., 10 sec., 15 secs., etc.) in all instances. I have tried with both FLAC and MP3 files. I have tried installing 3 different firmware versions.
Sorry, mine just works right; I can’t get it to display this alleged ‘bug’ under any circumstances. I guess I just got one of the ‘good’ ones.
Hmmm, given that this obviously is a bug (for some of us, at least), one wonders if it only occurs when some other parameter is set. Or perhaps only at certain atmospheric conditions.
Miikerman, did I understand you to say you were able to reproduce this too?
The only differences I see between color43’s parameters and mine is that I do not use any VBR .mp3 files. All of mine are 256kbps CBR and do not contain Replay Gain tags, although they do have APE amendments to the ID3 tag from MP3Gain.
Miikerman, did I understand you to say you were able to reproduce this too?
The only differences I see between color43’s parameters and mine is that I do not use any VBR .mp3 files. All of mine are 256kbps CBR and do not contain Replay Gain tags, although they do have APE amendments to the ID3 tag from MP3Gain.
And I live at sea level . . .
Yep, I reproduced the bug right off (repeatedly). Although as far as bugs go, it’s a minor one. My files are MP3 VBR files (without Replay Gain), but could that simple factor (VBR) be causing this? Although, having said that, stranger things have happened in the computer field–who knows what’s possible? Also, my player was at about 20’ above sea level when I reproduced the glitch.
Well, it doesn’t have anything to do with altitude.
My curiosity piqued, I ran a FLAC file through the Format Converter in Winamp and converted it to a VBR .mp3 file. Sure enough, playing it and going to the 3rd page of the Track Info and letting it sit reverted back to the Now Playing screen after the time set in the Backlight setting (5 secs., 10 secs., 15 secs., etc.) and the backlight stayed on indefinitely.
I found though, that if you simply press the center button twice (once for the frequency analyzer, & again to go back to the Now Playing screen) the backlight will once again resume it’s natural (user-set) time-out so as you said, it’s not a huge bug or one that’s going to negatively affect a lot of people.
It is ■■■■■ though, that this reveals itself only when playing VBR .mp3 files and not CBR or .flac. I’ve been told CBR files are so 20th century (Thanks, Marvin) and that virtually all mp3 players nowadays play VBR without any issues whatsoever, and that the memory space savings is so significant that it’s silly to rip in CBR.
Well, call me a dinosaur but I didn’t have any issues with this bug (or any others) until I tried the VBR file. Hard telling what other bugs or un-explained anomalies can be attributed to the variable bit-rate, but I plan to continue to rip in CBR format. I _ know _ that it works.
Fascinating stuff there, Holmes ;), that the software’s mere reporting (and, seemingly, reading) of a VBR file’s VBR setting in and of itself somehow causes a glitch in the backlight timeout protocol. Perhaps one of the SanDisk engineers had taken a quick nap when he was coding that section of the program? Good sleuthing there!
Well, it doesn’t have anything to do with altitude.
My curiosity piqued, I ran a FLAC file through the Format Converter in Winamp and converted it to a VBR .mp3 file. Sure enough, playing it and going to the 3rd page of the Track Info and letting it sit reverted back to the Now Playing screen after the time set in the Backlight setting (5 secs., 10 secs., 15 secs., etc.) and the backlight stayed on indefinitely.
I found though, that if you simply press the center button twice (once for the frequency analyzer, & again to go back to the Now Playing screen) the backlight will once again resume it’s natural (user-set) time-out so as you said, it’s not a huge bug or one that’s going to negatively affect a lot of people.
It is ■■■■■ though, that this reveals itself only when playing VBR .mp3 files and not CBR or .flac. I’ve been told CBR files are so 20th century (Thanks, Marvin) and that virtually all mp3 players nowadays play VBR without any issues whatsoever, and that the memory space savings is so significant that it’s silly to rip in CBR.
Well, call me a dinosaur but I didn’t have any issues with this bug (or any others) until I tried the VBR file. Hard telling what other bugs or un-explained anomalies can be attributed to the variable bit-rate, but I plan to continue to rip in CBR format. I _ know _ that it works.
Hey, it’s still a free country, for now at least. So by all means, my dear fellow, rip as you please. My folder of just MP3 files is 114GB (for now) , and while I didn’t rip them all, the ones that I have ripped are VBR. All of my current devices, be they Sansa, Apple,or Microsoft in origin, seem to play my mix of VBR and CBR files just fine.
So by all means, my dear fellow, rip as you please. 
My folder of just MP3 files is 114GB (for now) , and while I didn’t rip them all, the ones that I have ripped are VBR. All of my current devices, be they Sansa, Apple,or Microsoft in origin, seem to play my mix of VBR and CBR files just fine.
