Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
johnb:
I would be happy to do the systematic testing Saratoga suggests (if you can provide the compiles).
In our family we have 4 clip+ and 2 fuze v2.
But I will be on holiday for 4 weeks starting next Tuesday.
johnb:
Using clip+_21, everything seemed fine listening to mp3 and mpc.
Then on a flac album, I felt it was skipping to the next track while in the middle or close to the end of the song.
I couldn't reproduce it on this particular song, but then it happened again on a different song.
Then still in he same session, I got a similar "data abort" crash as with _20.
I will revisit http://knk.zz.mu/rb/clip+.zip with that flac album.
Mihail Zenkov:
--- Quote from: johnb on August 13, 2015, 12:27:15 PM ---I will revisit http://knk.zz.mu/rb/clip+.zip with that flac album.
--- End quote ---
clip+_20.zip have CVDD1=20 (like in amsv2_scaling_v8)
clip+_21.zip have CVDD1=21
clip+.zip have CVDD1=22
So yes, please test clip+.zip more carefully.
keyb_gr:
^ I've slapped this one onto my bedside Clip+ now and will see how it behaves - fairly recent sample with a Sandisk 64 gig card. Feels just like the last standard build (c3c2c91-150421) so far, complete with the usual quibbles. (The database has been somewhat slugtastic ever since it's no longer being kept in RAM, and the scrobbler is the usual handbrake, with occasional crashes upon skipping back, even if the file played is on the µSD card. Power issue? Race condition during overlapped R/W?)
EDIT: Oops, it doesn't seem to like unplugging from the computer at all - dark screen and need for hard reset. (Safe removal, power not turned off.) Actually the unit is steadily refusing to come back up after attempt #2, even after holding the power button for what seems like an eternity. :o Looks like it has totally hung up. >:( Do I need to wait until the battery is depleted or what, like I once had to with my old Clip with OF? The headphone amp still seems to be running, so it should be a matter of about 2-3 days tops. Still annoying. There must be some quirks in USB disconnect handling still.
keyb_gr:
Phew, it's alive again. Woke up to find no more activity from the player (a portable MW receiver is good for checking for DC/DC emissions, grabbed my trusty ICF-SW7600 from the drawer of shortwave receivers in this case), plugged it into the computer, booted up. Then it apparently crashed (no drives), so I just unplugged again and reconnected, worked this time. Replaced RB with previous build, pushed a button to turn on the display before unsafely removing it, confirmed "Reboot now?", and now it's charging.
I suppose what may be happening is that after "safe removal", the player returns to unboosted state while still connected when the display is off, and disconnecting external power somehow causes a major glitch. It's not like unplugging from the computer would have been totally trouble-free for me, the occasional crash with abort does occur even with a standard build. Is there anything one can do to track this kind of stuff? I usually can't even read these abort error screens since they're (a) in tiny font (and yours truly can easily compete with any proverbial bat) and (b) only visible for a second or two.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version