H320 freezes/crashes

[RDP]

Hello all,

I am a longtime iRiver H320 Rockbox user, coming back to the scene after a very extended holiday. The reason I am coming back is I was made aware of the iFlash storage options, and went ahead and purchased the micro SSD Quad adapter. I now have 512gb of flash storage, and am very happy with that, however soon after the upgrade I started to experiences freezes/crashes after a few minutes of playing a track, which would only go away with a press of the reset button, but then the process would repeat. The crashes were at different times, nothing was perfectly repeatable. Out of sheer luck I have discovered how to stop the freezes/crashes, and I felt that a solution (based on the symptoms) would be to get a new battery as my original one was toast. I recently bought, and installed the new battery, but unfortunately the issue persists, so now I have run out of ideas, and turn to the group for possible assistance.

Unit will crash scenario:

Running on internal battery power.
Running on external power that is smart enough to stop charging after the battery gets full, then the H320 reverts to running off of internal battery power.


Until will not crash scenario:

By pressing the play button while inserting a specific USB external power bank I skip the USB connection routine, and can continue to use the unit while it charges. Note: this is charging by USB, not the DC connection. If I use a specific USB battery bank from my collection (not all work this way it seems) that never stops sending out a current (I shall call this a dumb battery) the unit will NEVER crash, I can go all night, not a problem, EVER. Other USB battery banks seem to try and be smart, and stop when the iRiver battery is full, then after a few minutes I will have a crash again.


I'm not sure what this presentation indicates, but I am totally stumped.

thanks in advance for any guidance,
RDP

[Bilgus]

Do you have any way to measure the amperage draw of the adapter?

even if not..
what about if you only use two cards?

[raidraid]

It seems like iflash units has the similar to some cheap chinese cf-sd adapters issue - random non-repeatable freeze. Mostly it occurs at 50% and below charge level (in my case). Sometimes it happened just by menu surf.
I cannot be sure will it help or not, but try to initialize and update database and then turn the "Load database to RAM" option on.

Sorry about my english - it's not native to me.

[RDP]

Bilgus:

1. Can you please advise what you like me to try and check when you say "the adapter"? Is this the external USB power pack?

2. I can reduce to two cards, it will just take a while to come back to four cards later, as it takes 17 hours to load my files back. Should be able to report back in a day or two.


raidraid: My crashes only happen during playback, and can be at 100% battery as well. The only thing I know for sure is using external USB power will 100% solve the problem. I am trying your database recommendation now and will report back.


thanks all!
RDP

[Bilgus]

I was saying the power draw of the sdcard adapter

[RDP]

Hello,

Apologies for the late reply, but I do not like wasting people's time, and wanted to test the reccomended two uSD card instead of the four uSD card thoroughly, which I have now, and can report:

Process to move to two cards: remove two cards (slot 3 & 4), reformat on Windows, rebuild MBR for XP/etc.., copy over test data

Results:

I will still crash if I do not have a USB charger actually being active on the USB port. Using the recommendations by user raidraid might have helped in some combination of factors, but the end result is the same: if I don't have the unit plugged in and charging by USB (the USB battery needs to be working with it's LED light on), then a crash WILL occur. With the internal H320 battery low one night, then adding the external charger I put on a shuffled and repeated a 260 track playlist, and in the morning it was still going strong.

One thing I did notice when using a laptop USB port to charge (and keep the unit from crashing) is that when I look at the LCD on the iRiver it's at 99% and charging, not 100% and not charging. I have a feeling if it's in a charging state that it won't crash, but don't know how I could prove that.

Very separate issue: I set the battery size in the system preferences to 1700mAh as that is what my new replacement battery is supposed to be but have noticed strange behaviour: Lets pretend the unit is reporting 75% battery life remaining. When I plug it in to charge it will immediately drop to say 38%, then charge to 100%. Strange?


thanks
RDP

[raidraid]

Maybe the reason is simple - this adapter needs much more power and become unstable on voltage lower than ~4.0V or maybe even 5.0V (brought by the charger)? Could it be even two cards (+ converter chip) is a heavy load for the unit?

[RDP]

It is  unfortunate as I invested in a converter case to create the iFlash/uSD JBOD raid, four uSD 128g cards, and the iFlash adapter, because I thought it would be great to use this iRiver nit again. Instead these months have been very stressful.

raidraid: I notice in another thread you have had success going back to older Rockbox software. I will try this as well, I don't have many other options left.....

thanks!
RDP

[raidraid]

raidraid: I notice in another thread you have had success going back to older Rockbox software. I will try this as well, I don't have many other options left.....

After one week of use (tested developers build with other card, then got back to 3.9.1) i get this damned freeze once again, so there is no success with older RB version too (that thread is updated already). I'll try with other adapter hoping previous one is just faulty.

[RDP]

Interesting update (still only using 2 uSD cards):

I used the H320 yesterday and it did not crash, and played for many hours. I kept waiting for it to crash, but it didn't. I looked to see what might be different, and the only thing I could see that I was listening to a folder full of MP3 files (DJ mixes) instead of what I have usually been listening to which is my music library, which is all in ALAC of regular length single tracks.

If it really is a power issue then should I understand the ALAC needs MORE VOLTAGE POWER than MP3?

I feel I have discovered something, but not sure yet. More testing....

NOTE: I took a look in DEBUG menu, and VIEW BUFFERING THREAD, and VIEW OS STACKS.

MP3:   124mhz solid while decoding just changed track. Drops to 45mhz after. OS Stack shows NO plus sign by the codec thread once the initial decode is completed.
FLAC:  124mhz solid while decoding just changed track. Drops to 45mhz after. OS Stack shows NO plus sign by the codec thread once the initial decode is completed.
ALAC:  124mhz solid while decoding just changed track. Drops to 45mhz, then up to 124hmz, then repeats this up/down pattern constantly changing every second, it never stops. OS Stack viewer also shows PLUS sign by the Codec thread, coming on and off constantly.

Note: when viewing the VIEW BUFFERING THREAD I sometimes get Boost % figures with MP3, maybe Database work in the background, or high bit rate decoding requires it for specific files? I don't see a pattern here yet.

thanks,
RDP

[RDP]

More testing:

Converting some of my ALAC collection to FLAC to test has given excellent results = no crashes. I am suspicious of the ALAC decoder; watching the VIEW BUFFERING THREAD there seems to be consistency:

OGG/MP3/FLAC/WAV: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: hovers (it is always active) near the top of 100%. Upon track change the cycle starts again (124mhz until pcm: becomes full). I don't seem to get crashes.

ALAC: CPU Frequency goes up to 124 until pcm: becomes full, then drops to 45mhz and pcm: quickly goes down (takes about 2 seconds) to 75%, then cpu switches to 124mhz to get pcm: back up to 100%. This goes on constantly (cpu high - low cycle) while a single track/file is playing. I am now believing this cpu going up and down constantly gives me the crashes. Note on crashes: I don't know when they will happen, sometimes after a minute or two, sometime after 10 minutes , there is no pattern I can tell.

Question: I believe pcm: goes to 100% as the whole file (or what can fill the memory buffer) is decoded. That's why the boost is not needed after pcm: becomes full, the heavy work of decoding has finished. If that is normal operation then why does ALAC need to keep boosting the cpu to keep pcm: full after the initial main decode operation? It seems strange, and seems to be officially not reccomended "First of all, it draws more power. Secondly, the frequency switch itself takes time, and the tick timer will lose accuracy. On the Coldfire, the PLL takes up to 10ms to lock on the new frequency. Because of this, we should not switch frequency too often." Link: https://www.rockbox.org/wiki/DynamicCPUFrequency

P.S. I really don't want to have to convert my whole collection to FLAC because of this issue, but it seems that ALAC is not working for me, and I don't know how to fix this.


thanks,
RDP

[RDP]

It have been over a month now, and things are much better by not using FLAC. I will try to post this as a bug.

thanks all, it's been long process to get to this point to have confidence in what the issue was.

P.S. I still have occasionally crashes, but different errors, and in total way, way less than before, and the Buffering Thread behaves normally (as expected).

happy to answer any questions.

thanks,
RDP

[saratoga]

Looking at the benchmarks for CF, ALAC runs at about 200% realtime, so it should spend about half of its time at 124 MHz, half lower. 

[RDP]

I can post a video if it's helpful. Please let me know.

thanks,
RDP