Re: h120 weirdness
Hi Dave I've been running cvs-060304 for some time...obviously. 20060221 I was bumping along listening to a FLAC file (the player had been on for 5 about minutes). I decided to locate a different file but instead of just navigating to the file I hit STOP so it would throw me into the Everything froze up. I pulled out the trusty reset tool. When I powered up everything seemed functional except I had no files showing. Anybody have any idea what might have caused such a singular component to get blasted by the lock up/reset? Yes. Something similar happened to me a few days ago. For some reason (forgot the cause) I had to reset the device. When it rebooted General Settings - File View - Show Files was set to ID3 database, but I am perfectly sure, that it was set to All before the reset. BTW: This firmware freezes instantly when trying to browse the ID3s. So maybe it changed the settings before the reset for unknown reasons (maybe my fault) and that caused the freeze. However: If something similar would have happened to you and there is no ID3 database on your HD the player will show nothing in the browser, giving you the illusion of an empty drive. In that case: Just click and hold A-B to check. I really have a feeling I could have installed any version and fixed the problem. Me too, but I really do not know, if updating the firmware resets this configuration option. cu John
Re: Bug in screen_access.c affecting all drivers.
On Thu, 6 Apr 2006, gl wrote: Agreed - but you guys can't have it both ways either. Either the policy exists because you genuinely don't want to work with anonymous users, then don't accept contributions through the backdoor. It makes the policy a joke. Small and trivial changes will always be accepted and used with or without the user being known or anonymous. We've always done it like this and your case is not an exception. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
mp3_encoder.c does not compile with cygwin
Hi!
Compiling mp3_encoder.c fails on cygwin that way:
mp3_encoder.c:69: error: parse error before else
mp3_encoder.c:69: warning: type defaults to `int' in declaration of `cc'
mp3_encoder.c:69: error: `c' undeclared here (not in a function)
mp3_encoder.c:69: warning: data definition has no type or storage class
mp3_encoder.c:69: warning: type defaults to `int' in declaration of `sz'
mp3_encoder.c:69: error: `s' undeclared here (not in a function)
mp3_encoder.c:69: warning: data definition has no type or storage class
mp3_encoder.c:69: error: parse error before '}' token
I guess this is caused by excessive ^M in the file. This will split a
macro, so it is seen like that:
#define putlong(c, s) if(s+sz = 32) { cc = (cc s) | c; sz+= s; } \
else { putbits(cc, sz); cc = c; sz = s; }
Under *nix ^M are ignored, so most probably no problem there.
Stripping the file for example with
# sed s/Finest Music Player Firmware//g mp3_encoder.c mp3_encoder.c.okay
will fix that issues and the result cleanly compiles.
cu
John
P.S.: Anyone may fix that giving credit to whoever she wishes. ;-)
Re: Bug in screen_access.c affecting all drivers.
First, I'm glad that reasonable is met with reasonable, I was afraid to enter this thread. Second, I have met Linus and Daniel in person, and I've rarely met more friendly and jovial engineers. I don't think that the policy is that we don't want want to _work with_ anonymous people, but merely that we cannot accept anonymous code ownership in our repository, so we can't take a patch from you, apply it and put you in the credits without your name. Users who submit bug reports generally do not get put in the credits file, and that is how you are being treated now, you are credited (I bet they would even let us credit you by 'gl' in the CVS logs) as having found the bug, and your proposed fix, implemented by one of us, is put in the repository. Rockbox is a very unique project in the open source world. It's a fairly large project, with a high level of technical difficulty that is implemented without any corporate financial backing. I think it is arguably only as successful as it is because of the attitude of real software by real people. This project feels like _real software_, and this means that in order to work on it, you must be a _real engineer_. I'm sorry that you won't be contributing bug reports any more. Good bug reports are very valuable to a project, probably better than half baked patches (no claim about _your_ patches here, just a general statement). Peace, Brandon On Thu, 04/06/06 at 10:14:27 +0100, gl wrote: If you post bugs to this list, and offer a fix, what would you have us do with it? Simply ignore it since you refuse to be given credit by name, or would you rather we improve the project by reimplementing and comitting that fix to the repository? At last somebody who can make a point in a reasonable way. What happened was that whilst I was reporting those bugs, it ocurred to me that the whole thing was ridiculous - if my work is no good here, why is it being accepted? I agree that it makes no sense to continue to do so. You can't have it both ways, if you don't want your ideas used, then don't post them, don't give them to us. If you _do_ then feel free to continue posting them, and we appreciate them. Agreed - but you guys can't have it both ways either. Either the policy exists because you genuinely don't want to work with anonymous users, then don't accept contributions through the backdoor. It makes the policy a joke. Either way, no bitching and moaning is needed, it's your choice, and as long as you continue posting those fixes to this mailing list, they will keep making their way into the repo. with or without your name attached to them. Bitching and moaning is the result of people acting like jerks to a legitimate complaint, reasonably made - Linus in this case. If you guys want a reasonable discussion, act reasonably (like you just have). It just goes to show that _everybody_ online hides behind their anonymity - unless you can see someone face to face, you can act how you like. But that seems to be generally sanctioned here, so I'm getting out of the zoo, problem solved. -- gl
Re: h120 weirdness
was set to ID3 database, but I am perfectly sure, that it was set to All before the reset. BTW: This firmware freezes instantly when trying to browse the ID3s. So maybe it changed the settings before the reset for unknown reasons (maybe my fault) and that caused the freeze. However: If something similar would have happened to you and there is no ID3 database on your HD the player will show nothing in the browser, giving you the illusion of an empty drive. This is entirely possible. I didn't look too hard before I updated. I've never used the tag database and always have the show files set to supported unless I have some good reason to change it to all. Dave kenshin/kawika/sithia
make clean
i'm slightly confused ... why does 'make clean' make sources unusable? (for example it removes 'firmware' dir) --
Re: make clean
On 4/6/06, Anton Romanov [EMAIL PROTECTED] wrote: i'm slightly confused ... why does 'make clean' make sources unusable? (for example it removes 'firmware' dir) in fact, it does not 'make'. it only 'cleans'. It erases everything that 'make' could use for an incremental build, because some source-changes do not get detected by 'make' and so not rebuild properly. If the thing you are trying out is not working as expected, 'clean' first, then rebuild it all. ~lImbus
Re: make clean
On Thu, 6 Apr 2006 22:14:55 +0200 Manuel Dejonghe [EMAIL PROTECTED] wrote: in fact, it does not 'make'. it only 'cleans'. yeah, i know It erases everything that 'make' could use for an incremental build, because some source-changes do not get detected by 'make' and so not rebuild properly. of course If the thing you are trying out is not working as expected, 'clean' first, then rebuild it all. thats what i was trying to do... BUT: make clean killed 'firmware' directory...(maybe some other source files too) while it should remove only *.c,*.o,*.a and so on so after 'make clean' i had nothing to do but checkout from cvs --
Re: make clean
Your build dir should absolutely never be a parent or the same as your source dir. However we should check for that in configure. use a build dir that is a subdir of your source dir or external to it, and this will not happen. Brandon On Thu, 04/06/06 at 23:29:00 +0300, Anton Romanov wrote: On Thu, 6 Apr 2006 22:14:55 +0200 Manuel Dejonghe [EMAIL PROTECTED] wrote: in fact, it does not 'make'. it only 'cleans'. yeah, i know It erases everything that 'make' could use for an incremental build, because some source-changes do not get detected by 'make' and so not rebuild properly. of course If the thing you are trying out is not working as expected, 'clean' first, then rebuild it all. thats what i was trying to do... BUT: make clean killed 'firmware' directory...(maybe some other source files too) while it should remove only *.c,*.o,*.a and so on so after 'make clean' i had nothing to do but checkout from cvs --
Re: make clean
The way the Rockbox code works, you do NOT build in the source directories. Instead, you create a empty directory at the same level as the other Rockbox dirs (like apps). Then, you go into that empty directory and do a ../tools/configure which will create a makefile depending on how you answer the questions. Then you do a make. The advantage of this is that you can have several configurations of builds all using the same untouched source files. I don't think anything ever gets written into the source tree. Hope this helps. - Original Message - From: Anton Romanov To: rockbox-dev@cool.haxx.se Sent: Thursday, April 06, 2006 10:05 PM Subject: Re: make clean On Thu, 6 Apr 2006 15:50:29 -0500 Brandon Low wrote: Your build dir should absolutely never be a parent or the same as your source dir. However we should check for that in configure. why not? use a build dir that is a subdir of your source dir or external to it, and this will not happen. not really sure how do i do this anyway to build i should cd to source dir and 'make' isn't it so? --
