Rockbox Technical Forums
Rockbox General => Rockbox General Discussion => Topic started by: tab on June 14, 2007, 06:58:22 PM
-
I've got a strange problem with my H120 lately. Whenever I start Rockbox (configured to start in the file menu) it starts to scroll down like crazy without me pressing any buttons. After some seconds, this stops. But not completely, it still scrolls down one line every 5 to 10 seconds. When I start playback, it decreases the volume on its own. Again, this is normally done by the same button (Navi "down") as scrolling down in the file menu.
At first I thought my good old iRiver has a problem. But, booting into the original iRiver firmware it doesn't show a similar behaviour. No navi "down" actions without me really pressing the button. So what could this be? I've run Rockbox on the unit for several years now without any bigger problems. But this one is strange. Am I the only one who has this strange problem? Should I try to reflash the bootloader or completely remove the .rockbox directory and reinstall? Any hints?
tab
-
What build and bootloader versions are you running?
-
Hmm. Everything seems back to normal now after imstalling an older daily build and starting Rockbox. The problem might be database related. The odd behaviour started after I selected all tracks of an artist and started playback. Anyway, the old build from June 2nd doesn't have the problem while the latest daily still has it. It's too late here now for me to try out all builds in between. Maybe tomorrow if noone fixed it by tomorrow evening.
I used a build at least one day old when the problem first appeared. Bootloader version 6.
tab
-
I've got a strange problem with my H120 lately. Whenever I start Rockbox (configured to start in the file menu) it starts to scroll down like crazy without me pressing any buttons.
Interesting. This sounds very similar to a problem I had when I first tried building Rockbox using a newer version of GCC. Based on that, I'd try the daily build from June 13 and 14. If the problem starts with the second of those builds, I have something worth trying.
-
Sorry for the delay, I tried to download the 13th daily build, but can't access the download site today :(
tab
-
Well, now that I can download builds again, I can't reproduce the problem any more. I installed both builds, June 13th and 14th, did (I think) exactly the same that I did before. Nothing, no scroll down, no volume lowering, completely normal behaviour. I installed the latest daily now (June 16th) and will watch out for the problem to reappear.
tab
-
ÃŽt happened again! :( This evening I downloaded a current build and at first everything seemd fine. Then I listened to an album while working. After some time I wondered, whether the album was already through because there was no music any more. Actually, it wasn't. Just the volume was something like -100 dB. After I stopped playback, the fast scrolling happened again in the menu. Now I've downloaded and installed the 20070613 daily build again for testing.
tab
-
Hi,
I can report that I've had the same problem with my H120 and Rockbox. Just tried reloading the bootloader with version 6 and using version r13725-070627 of Rockbox to start fresh. If I initialize the database, the highlight bar just keeps scrolling down, wrapping again from the top. Same behaviour at boot time, I suppose it is loading the database at that time. But even without initializing the database, Rockbox seems to detect a down button being pressed every ten seconds or so, which can be observed in menus, the file list, or as the volume decreasing steadily in the Now Playing screen. If I boot back into the original firmware, everything is fine, which leads me to think it's a firmware issue and not hardware related.
I'm kind've new here, so I hope I haven't offended by just jumping in. Just thought I'd add what observations I could to see if I could help.
-
This reminds me the discussion over in http://forums.rockbox.org/index.php?topic=7149.0 where a user was having trouble with buttons on the remote.
On the H120/H320 families most of the buttons on the main unit and remote are read using an analogue input and a chain of resistors connected to the buttons http://www.rockbox.org/twiki/bin/view/Main/IriverHardwareComponents#The_Buttons the CPU reads the Analogue input and compares it to a set of numbers to decide what button is pressed. For example below 1V it is left, between 1V and 2V it is right, 2V to 3V is up, and so on.
I'm wondering if on your unit(s) the value when no button is pressed is very close to the change over point to down button pressed and a litle bit of elecrical noise makes it look like the button is pressed every now and then.
You could try going to the system -> Debug (Keep Out!) -> View I/O Ports menu and look at the ADC_Buttons and record what the value is when there is no buttons pressed and then the down button - post the values here and when I can I'll see what the changeover points are in the source code. You exit the I/O Ports screen with the stop button.
This is just a theory of mine - it may be of no help at all ...
-
On the H120/H320 families most of the buttons on the main unit and remote are read using an analogue input and a chain of resistors connected to the buttons http://www.rockbox.org/twiki/bin/view/Main/IriverHardwareComponents#The_Buttons the CPU reads the Analogue input and compares it to a set of numbers to decide what button is pressed. For example below 1V it is left, between 1V and 2V it is right, 2V to 3V is up, and so on.
I'm wondering if on your unit(s) the value when no button is pressed is very close to the change over point to down button pressed and a litle bit of elecrical noise makes it look like the button is pressed every now and then.
Another possibility: In the code reading the analogue input, there are short delay loops. It may be that some devices need somewhat longer delays for the reading to work reliably.
I don't know if that makes sense hardware-wise, but I did get similar problems when a version of the compiler I tested optimized away the delay loop completely. However, it would explain the case when it only happens sometime, like during playback and during database build. In these cases, the CPU is boosted (at least periodically), making the delay loop shorter in time.
Should be easy enough to test: just make a build with a slightly longer delay loop (for the h100 series, the code in question is in firmware/target/coldfire/iriver/h100/adc-h100.c).
-
just make a build with a slightly longer delay loop (for the h100 series, the code in question is in firmware/target/coldfire/iriver/h100/adc-h100.c).
I can confirm that changing the 9 to 11 in the loop indeed stops the scrolling down problem. Whether boosting or not, ADC_BUTTONS shows mostly consistent readings when buttons are held down - though some still flicker a bit, but not by much.
-
With my H140, I've had exactly the same problem as reported by djhudson, except that the automatic scrolling occurred without any reference to the database, on all the menu screens. This was using the standard daily build from 25 June 2007. Curiously, I deleted it and installed Mmmm's recording enhancements build (r13711M-070625), and the problem did not exist. Perhaps this may help identify when the problem began with the daily build?
-
I had the same problem on my H120. It appeared after installing a build from the 28th June. I did not upgrade for more than a week before that. Now it seems that the problem is gone after installing a build from the 1st July. Both the builds were downloaded from build.rockbox.org. I think that the buggy build was compiled using a different GCC version. Unfortunately I do not have the information anymore. The working version I am running now was compiled using:
gcc: m68k-elf-gcc (GCC) 3.4.6
ld: GNU ld version 2.16.1
Host gcc: gcc (GCC) 4.1.2 (Gentoo 4.1.2)
See the attached rockbox-info.txt.
[attachment deleted by admin for age]
-
Just a moment ago I downloaded the latest build r13758-070701 which is buggy again. It was compiled using
gcc: m68k-elf-gcc (GCC) 3.4.5
ld: GNU ld version 2.16
Host gcc: gcc (GCC) 4.0.2 (Debian 4.0.2-2)
It seems that either at least one of the build servers has a wrong gcc version for Coldfire targets or the code has a new part which is unexpectedly dependant on certain versions of gcc. By the way is it possible to identify the build server from the rockbox-info.txt? The file is attached.
It seems that the phantom down key-presses appear when Rockbock reads from the HDD or when the backligh fade out starts (this is the reason of the volume going down in periodically repeating steps) so it probably has something to do with interrupts or cooperation between threads.
[attachment deleted by admin for age]
-
Bagder has told me he'll be disabling Coldfire builds on the 3.4.5 server until it's upgrade, so keep watchful and see if the problem goes away.
-
Exactly the same problem het as topicstarter describes (H140). Looks like it has something to do with the accessing of the hard disk. When I start the player and Rockbox is scanning the disk in the background, the cursor scrolls down. When it is done scanning, the scrolling stops. When Rockbox starts accessing the hard disk to load the next song, the scrolling starts out again. When in the WPS, the scrolling manifests itself as gradually lowering of the volume.
AFAIK this problem does not exist in the daily build 20070626, but the extensive testing has now exhausted my battery.
-
Seriously, read the whole thread, and test with a CURRENT BUILD.
-
Unfortunately my assumption was wrong >:( I have the same problem on the build r13761-070701 which was made using gcc 3.4.6. rockbox-info.txt is attached. I will keep testing new builds.
[attachment deleted by admin for age]
-
Exactly the same problem het as topicstarter describes (H140). Looks like it has something to do with the accessing of the hard disk. [...]
Scratch that, now running version 13725-070627 while charging the unit. Keeps scrolling, even when not accessing hard disk. Disconnecting charger doesn't make a difference.
AFAIK this problem does not exist in the daily build 20070626, but the extensive testing has now exhausted my battery.
This clue I was right about. The problem is introduced as of build 20070627. I have both Rockbox binaries on my H140 now. When I run build 20070627, the problem is there. It needs some kind of a trigger though, I can reproduce it when starting the 'fireworks' plugin, but it has also shown up at other times.
-
I can confirm that changing the 9 to 11 in the loop indeed stops the scrolling down problem.
I've applied that change now. Lets see if it really fixes it for everyone.
-
I just started testing. I tried a build some days ago and had the scrolling immediately at startup. I'm pretty sure the June 13th daily build is stable. Maybe June 14th as well. June 15th has the problem, although it is sometimes hard to reprduce, so one can never be absolutely sure if a build is ok or not. I ran June 15th build several days without a problem and out of a sudden the scrolling occured again.
So I can't say much about the new build yet, it'll need some time to be reasonably sure. Anyway, there was no immediate scrolling after startup and it runs for 20 minutes now without a problem. I'll keep my fingers crossed ... Thanks for all your efforts.
-
I noticed this problem a few days ago using the June 29th or 30th daily build (it was the most recent daily build downloaded on June 30th, not sure when they are uploaded but would assume it was from the day before).
No trigger needed to begin problem. When left sitting on any screen, curser will scroll down once very 5 to 10 seconds.
I have tried it again using July 2nd daily build. Problem persists. Seems that Magnus Holmgren button delay loop timing increase has not solved problem.
Will continue monitoring this forum and testing as changes are made.
Thanks for the hard work.
-
I have tried it again using July 2nd daily build. Problem persists. Seems that Magnus Holmgren button delay loop timing increase has not solved problem.
That's probably because the July 2 daily build does not include the delay loop change. :)
-
Seems to be fixed for me now.
*thanks*
-
I have installed the latest build of RB for the h120, but when in playback, or when using any processor or RAM hungry functions such as building the database, or when new information is buffered into the RAM, the scroll down function is engaged (I am quite sure this is not a hardware issue on my side as the problem is not evident in the iRiver boot or in the older stable build). The player will not stop scrolling down unless the left button is pressed on the navi stick, in which case it will scroll up, but will not skip back to the start of the menu list. It would not be such a big problem, but it turns the sound off when loading up a new song.
I got this version last night, Ver #= r13764-070702
-
I got this version last night, Ver #= r13764-070702
This version does not include the fix for the Problem. Please try if it still happens with the current build ( http://build.rockbox.org/ ).
-
This version does not include the fix for the Problem. Please try if it still happens with the current build ( http://build.rockbox.org/ ).
Now running r13769-070703. Looks like it has been fixed. What did you do and why did it solve the problem?
-
problem would apear to be fixed. Whatever it was, I think it was processor based (it was very evident pre reinstall in the recording screen), thanks.
-
I had this same problem, which the update fixed, but I have also not been able to get any sound from the optical output since this problem appeared. Light appears in the Opt. out, but no signal is detected by my amp. Anyone else have the same problem?
Edit: It appears this is not a Rockbox issue, but probably a hardware one. Good news for you, bad news for me!
-
Just installed the latest build and, hurray, it's cured the problem on my H140 as well.
Many thanks!
-
After almost a week of testing or IOW listening to music :) I'd say you fixed it. Tried with various build starting with the date of your fix, none of them shoed the scrolling down behaviour. Thank you for fixing this annoying problem!
tab