Sansа Clip Zip - Improve battery life

[johnb]

Clip +
rockbox983c808M-150808-clipplus-amsv2_scaling_v8.zip    3.27 Mo https://1fichier.com/?ca4hek70y1
rockbox983c808M-150808-clipplus-amsv2_scaling_v8+gui_boost+restore_irq.zip  3.27 Mo https://1fichier.com/?vr0xv2k8o2
(clip+ already has CDDV2=113, so no 3rd link)

I guess people should try them in the order given, so developpers can know how much the other patches are needed.
(I haven't tested them, so use at your own risk.)

I am trying these on two different clip+:
- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.
- for a newer one the first build seems stable so far, also with the SDcard inserted. Needs further testing.

Both are AMSv2 variant 1.

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).

[Mihail Zenkov]

- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.

Can you test this build: http://knk.zz.mu/rb/clip+.zip ?

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).

All audio patches already commited to rockbox. We switch audio mode when traversing the -40 volume value, so small click unavoidable.

[johnb]

- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.

Can you test this build: http://knk.zz.mu/rb/clip+.zip ?

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).

All audio patches already commited to rockbox. We switch audio mode when traversing the -40 volume value, so small click unavoidable.

Hi Mihail,

your build works fine, I couldn't break it so far ;-)

As for the "audio patch" I know that Saratoga had commited it. I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.

[Mihail Zenkov]

your build works fine, I couldn't break it so far ;-)

Can you also test next two builds?

http://knk.zz.mu/rb/clip+_20.zip
http://knk.zz.mu/rb/clip+_21.zip

I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.

Very strange. You should have small clicks/distortion on all builds. Better do cold restart (power off and than power on) after installing new build.
I hear more noise and have more power consumption when restarting without power off.

[Scalpos]

OK, did some tests with my 3 years old Clip Zip, AMSv2 variant 1; it is loaded with a 32GB Kingston µSDHC Class 10 / UHS-1 reported as SD32G Rev 3.0, Prod: 1/2014, Ser#: 0x00124ACE by Debug/View disk info. Database and dir cache are disabled.

- amsv2_scaling_v8 seems OK, but I experienced µSD card instability: songs played from the card were sometimes skipping to next one after 10-30 seconds, and after reboot Clip often displayed "nothing to resume", just as if the card was missing, and indeed it was not available in files browser. Playing from internal memory was fine. I live in France, and temperature has not exceeded 27 °C the last few days, so it's up to you to decide if this SD card instability might be related to the climate 

- amsv2_scaling_v8+gui_boost+restore_irq has what looks like the same µSD card instability as previous build, plus when the clip was linked to the PC, drives show up, but Windows was not able to recognize them properly. I tried many times, rebooted both the Clip and the PC, with or without the card. Finally, as I had no access anymore to the Clip internal memory from PC in order to update it, I copied with the 3rd build's .rockbox directory onto the card and once loaded into the Clip, I copied it to internal memory. The copy partially failed, but it was enough to have access again to mounted drives with the Clip linked to the PC (full Rockbox reinstall avoided, fortunately).

- amsv2_scaling_v8+gui_boost+restore_irq+CVDD2_113 looks fine so far, no more SD instability for the moment. Had only one issue: at power on, load was stuck displaying Rockbox logo step; ejecting the card, power on + loading the card after the Clip had properly started was enough. I only played few hours with it and will use it as usual this week. I already noticed estimated autonomy looks funny, don't know if Rockbox is lost with the battery improvements. The remaining power percentage shown sometimes jitters: 75% is displayed, then 74%, 75% again and few seconds-minutes later it's back to 74%. Shall I reset anything in order to have it properly calculated, and have it taken into account by Rockbox Information panel ?

Let me know if providing any logs (and how) would help.

BTW, I did not notice any GUI lag using all three builds, Clip was of course restarted after every update.

[johnb]

your build works fine, I couldn't break it so far ;-)

Can you also test next two builds?

http://knk.zz.mu/rb/clip+_20.zip
http://knk.zz.mu/rb/clip+_21.zip

I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.

Very strange. You should have small clicks/distortion on all builds. Better do cold restart (power off and than power on) after installing new build.
I hear more noise and have more power consumption when restarting without power off.

I will test the new builds.
I have to take some of my statement back: If I pause playback and the change the volume, I do hear a click, but don't notice during playback.
In the one by LolaPalocz, it's very noticable also during playback.

[johnb]

While testing I concentrate on the older refurb which seems to be more picky.

Using clip+_20, while listening to music and no particular activity, I suddenly face a crash with "data abort" like in this snapshot or the music stops playing and I have a black screen.
In either case pressing the power button for > 10sec is needed to be able to reboot.

This can happen after 5, 20 or 40min of playback, i.e. I have no indication what triggers it and I failed to reproduce it (e.g. playing the same playlist again).

clip+_21 is next.

[LolaPalocz]

(you miss usb patch:  http://forums.rockbox.org/index.php/topic,48549.msg233822.html#msg233822).

Oups. I guess it wasn't essential for me, I'll include it next time I post a patch here or if people want it.

I have to take some of my statement back: If I pause playback and the change the volume, I do hear a click, but don't notice during playback.
In the one by LolaPalocz, it's very noticable also during playback.

I can't check this on a clip+. But I had this click at 40/41 since I started building with this patch (and i quite like it, as an audio feedback that I'm traversing this 40/41).
I checked on my clip zip that I also have it with the nightly dev build (unpatched). Dunno about the clip+.

- amsv2_scaling_v8+gui_boost+restore_irq+CVDD2_113 ...  I already noticed estimated autonomy looks funny, don't know if Rockbox is lost with the battery improvements. The remaining power percentage shown sometimes jitters: 75% is displayed, then 74%, 75% again and few seconds-minutes later it's back to 74%. Shall I reset anything in order to have it properly calculated, and have it taken into account by Rockbox Information panel ?

So, I guess clip zip need 113 to work with all sd cards. Dunno how much more power is used with 113 vs 111.
For the display of power %, I also notice it.
I dont think there's anything to reset, rockbox on the clips just follows a static table battery voltage => % left, so if it quickly goes up and down and up, it's because the battery voltage does this.
It's probably because of the gui_boost patch, which may suddenly draw more power, thus reducing the voltage (so the %). When boost mode is exited, less power is drawn, the battery is happy and shows more voltage (so the %). I wouldn't worry.

[saratoga]

In terms of getting something we could commit, I would really like to see fully stable frequency scaling (ideally on all AMSv2 players) at stock voltages first.  Then we could commit that and work on voltages.  Otherwise its very hard to know what is broken when someone reports a random crash. 

[Mihail Zenkov]

Had only one issue: at power on, load was stuck displaying Rockbox logo step; ejecting the card, power on + loading the card after the Clip had properly started was enough.

It was only at once or you can reproduce this behavior?

Using clip+_20, while listening to music and no particular activity, I suddenly face a crash with "data abort" like in this snapshot or the music stops playing and I have a black screen.
In either case pressing the power button for > 10sec is needed to be able to reboot.

Good, I expect this result.

I guess it wasn't essential for me

Essential if you don't reboot player after usb disconnection.

Dunno how much more power is used with 113 vs 111.

Not much, in any case stability is more important.
For the display of power %, I also notice it.

I dont think there's anything to reset, rockbox on the clips just follows a static table battery voltage => % left, so if it quickly goes up and down and up, it's because the battery voltage does this.
It's probably because of the gui_boost patch, which may suddenly draw more power, thus reducing the voltage (so the %). When boost mode is exited, less power is drawn, the battery is happy and shows more voltage (so the %). I wouldn't worry.

Yes, you right.

In terms of getting something we could commit, I would really like to see fully stable frequency scaling (ideally on all AMSv2 players) at stock voltages first.

I think it stable but only with restore irq hack. I still don't have enough time to try fix this problem in more correct way.

Then we could commit that and work on voltages.  Otherwise its very hard to know what is broken when someone reports a random crash. 

You right, but all last crash report reproducible and we can fix it right now.

[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]

I will revisit http://knk.zz.mu/rb/clip+.zip with that flac album.

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. 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.