Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Another interesting skipping phenomenon

Re: Another interesting skipping phenomenon

From: Bradley Alexander <storm_at_tux.org>
Date: 16 Dec 2002 22:16:14 -0500

Sorry for the delayed response, I wanted to do a little testing with
20021214.

On Sun, 2002-12-15 at 06:38, Linus Nielsen Feltzing wrote:
> On 15 Dec 2002 01:17:53 -0500, Bradley Alexander wrote:
> >Hey all,
> >
> >I was running the daily build from 20021208, and I noticed an
> >interesting phenomenon. I was playing some mp3s in a deep directory
> >(4 levels down), and I noticed that as a track was playing (this was
> >in the car), I would hear a click and the Archos would skip backward
> >by about a minute (since I was driving, I couldn't tell exactly how
> >far, but once it actually skipped into the previous track).
> >
>
> Definitely interesting. What bitrate was the mp3?

It happened this evening again with 20021214. The track was Supertramp's
Breakfast In America, which, according to mp3report.pl, is either

Supertramp_-_Breakfast_In_America_04_Breakfast_In_America.mp3
2.86 MB - MPEG 1 Layer 3, 32 kbps, 44.1 kHz, Stereo

or

Supertramp_-_Breakfast_In_America.mp3
3.04 MB - MPEG 1 Layer 3, 160 kbps, 44.1 kHz, Stereo

neither of which is VBR. (I have, over the course of time, accumulated
two different versions of this particular song.)

> >I noticed it again today, with it happening twice preceeding a
> >lockup of the type we have been discussing here (red drive light
> >stays lit and the cache empties itself). Don't know if they are
> >related, but I wanted to put that out there. I just moved to the
> >20021214 build, will report my findings.
>
> Ooooh. lockup...bad. I thought we got rid of those.

Nope. Happened with 20021214.

> >After a day of intermittent use (call it
> >4-6 hours), it would usually be somewhere between 60 and 70%. Now,
> >with the same usage, it gets down to the 30 to 40% range. Again, I
> >don't know if it is actually affecting battery life (I tend to doubt
> >it), but it was, again, something I thought I would mention.
>
> We have changed the battery handling code, and it may very well show
> different values then before. It should not affect battery life
> however. The percentage now shows more or less the expected remaining
> play time than a pure battery voltage.

Okay, I can buy that. However, it is a bit disconcerting. Let me give
you an example of my battery usage concerns. I charged my Archos up
yesterday, and it completed charging before I went to bed, so I
disconnected it from the AC power. I ended up not using it this morning
on the way in to the office, opting instead for the radio. This evening,
I got in the car and fired it up (it should still have a full charge at
this point). I had to stop at the store, so I switched it over to
headphones. At that point, two songs had played. I checked the battery
level and it said 96%. I carried it around with me for my time in the
store, and all the way home. I left work at 6:30 pm and arrived at home
at 8:30 pm. The battery indicator read 38% in the info menu. I plugged
it in to the AC for 5 minutes and checked the level. It read 58%. Is
this normal for the new code?




-- 
--Brad
============================================================================
Bradley M. Alexander                |
Debian Developer, Security Engineer |   storm [at] tux.org
Debian/GNU Linux Developer          |   storm [at] debian.org
============================================================================
Key fingerprints:
DSA 0x54434E65: 37F6 BCA6 621D 920C E02E  E3C8 73B2 C019 5443 4E65
RSA 0xC3BCBA91: 3F 0E 26 C1 90 14 AD 0A  C8 9C F0 93 75 A0 01 34
============================================================================
As long as there are tests, there will be prayer in public schools.
Received on 2002-12-17

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy