00:00:54 | webguest89 | Haven't used that in ages. But since it's a matter of just files, I don't think I need that. Oh, and here's something interesting: Turning on fade in prevents the light from going oon, but if fade out is also turned off, the light will switch on and off just fine. If I activate fade out, it won't turn off or on anymore (even if DISABLING the light) If I leave the light disabled and then go and touch the "fade |
00:01:39 | webguest89 | And it's a clean rockbox install. |
00:01:54 | gevaerts | webguest89: rockbox is *not* rockbox utility... |
00:02:06 | gevaerts | rockbox is what runs on the player |
00:02:45 | Zagor | Bagder: longest post yet? :) |
00:03:05 | Bagder | quite possibly, yes ;-) |
00:03:19 | gevaerts | I'm pretty sure that there are longer ones |
00:03:50 | Bagder | 986 words wordpress says |
00:03:56 | webguest89 | and where is that menu located? does it do anything to that bootloader thing that I don't ever get to see (unless installing or uninstalling rockbox completely) |
00:04:20 | Zagor | Bagder: how many of those are "build"? |
00:04:26 | Bagder | 43% |
00:04:27 | | Quit Lss (Read error: 104 (Connection reset by peer)) |
00:04:28 | Bagder | :-P |
00:04:30 | Zagor | hehe |
00:04:36 | n1s | Bagder: nitpick s/a around/a round/ otherwise nice writeup! :) |
00:04:46 | Llorean | webguest89: What menu? |
00:04:50 | Bagder | n1s: thanks, fixed that |
00:05:07 | linuxstb | webguest89: Main menu -> Settings -> Manage Settings -> Reset settings |
00:05:36 | Llorean | webguest89: When did you last update your bootloader, exactly, anyway? |
00:05:43 | | Join barrywardell [0] (n=barrywar@79.97.85.223) |
00:05:49 | saratoga | i wonder why the show fps text in mpegplayer flickers so badly on the ams targets |
00:06:25 | linuxstb | Doesn't it flicker everywhere? |
00:06:38 | | Quit flydutch ("/* empty */") |
00:06:41 | webguest89 | light's out again :) that's what teset settings did :D |
00:07:00 | webguest89 | *reset |
00:07:56 | webguest89 | ugh, and my Icons are screwed up |
00:08:27 | Llorean | Yes, they're part of "settings" which you just reset... |
00:08:33 | Llorean | About that bootloader? |
00:09:09 | webguest89 | yep. that one DOESN'T need fixing/updating? right? |
00:09:25 | Llorean | It needs updating occasionally. When we release new versions. |
00:09:30 | Llorean | Which is why I'm asking. |
00:09:36 | Dhraakellian | erk |
00:09:51 | webguest89 | erm... never updated it |
00:10:10 | Dhraakellian | anyone have any advice for running rockboxdev.sh on OpenSUSE 11.1? |
00:10:32 | webguest89 | *ding* might be the solution to my problem, right? (or might screw it up worse) |
00:10:33 | Dhraakellian | I'm running into errors with /usr/include/asm |
00:10:38 | Bagder | Dhraakellian: can you build "normal" things with gcc? |
00:10:58 | Llorean | webguest89: Seriously, why not just answer the questions you're asked instead of trying to figure out why people are asking them? It would make this go a lot faster. |
00:11:11 | Llorean | I can't suggest whether you need to update the bootloader until you tell me when you installed the one you currently have. |
00:11:12 | Dhraakellian | y'know, come to think of it, I'm not sure I've tried |
00:11:19 | Llorean | Or give me its version. Either bit of info will do. |
00:11:23 | Dhraakellian | wait, yes, I believe I have... a plasmoid or two |
00:11:34 | Bagder | Dhraakellian: that 'asm' dir is supposed to be there |
00:11:37 | Dhraakellian | (although those may have been builton the laptop) |
00:11:45 | mt | In rm, when skipping a track, there's no problem if I skipped to the next track, but if I chose to skip to a previous track, it sometimes just stops. Sort of like when seeking in a codec that doesn't support seeking. |
00:11:55 | Bagder | or to be a symlink |
00:12:04 | Dhraakellian | Bagder: /usr/include/asm-generic and a number of /usr/include/asm-<arch> dirs |
00:12:16 | linuxstb | mt: The first skip backwards causes a seek to the start of the current track. |
00:12:23 | mt | Is this related to the 'no seeking support yet' or is it a porblem that should be fixed ? |
00:12:24 | Bagder | Dhraakellian: so you want the 'asm' to be a symlink to your arch's asm-<arch> dir |
00:12:46 | CIA-71 | New commit by kugel (r21680): Add a possibility for plugins to go directly to the WPS after exiting. ... |
00:12:54 | linuxstb | mt: It should be easy to add support for that specific seek operation. Other codecs may do it (or may have done it in their history). |
00:13:17 | | Quit stripwax ("Leaving.") |
00:13:18 | Bagder | Dhraakellian: but it does indicate a flawed install somehow |
00:13:25 | Bagder | of the kernel headers |
00:13:35 | webguest89 | wait a moment... how do I do that? |
00:13:41 | linuxstb | mt: shorten.c looks like it does that. |
00:13:52 | webguest89 | got it |
00:13:59 | Dhraakellian | I symlinked everything from -generic and -x86 into asm/ (and renamed the sigcontext32.h symlink to sigcontext.h, but now I'm getting some errors in that file, which makes me think that maybe that wasn't the proper solution) |
00:14:18 | mt | linuxstb: So just this specific seek operation should be handled now until full seeking is supported ? |
00:14:42 | Dhraakellian | https://bugzilla.novell.com/show_bug.cgi?id=299670 |
00:14:55 | Dhraakellian | but that's dealing with 10.3 stuff, and this is 11.1 |
00:14:58 | linuxstb | mt: Yes, it would be nice to do that. But no need to do it before a commit IMO. |
00:15:11 | CIA-71 | New commit by kugel (r21681): Adapt pictureflow and random_folder_advance_config to make use of the new goto-wps exit feature. ... |
00:15:19 | | Part domonoky |
00:15:19 | webguest89 | version 2.0 . It stays on for just 1 sec so it might take a while |
00:15:25 | Bagder | Dhraakellian: you would make an 'asm' symlink to point to asm-x86 |
00:15:47 | Bagder | or asm-i386 or whatever the name is ;-) |
00:16:01 | Llorean | webguest89: Try having RBUtil or the newest version of iPodpatcher update your bootloader. |
00:16:15 | linuxstb | mt: Also, have you tested that Rockbox rejects other types of .rm files cleanly? |
00:16:16 | mt | linuxstb: Are you free for a minute to check a patch ? If yes I'll upload one so that you could review it before I commit. |
00:16:30 | mt | No I didn't. |
00:16:30 | linuxstb | mt: I can have a quick look, yes. |
00:17:26 | Dhraakellian | Bagder: I think it was wanting files from both asm-x86 and asm-generic |
00:17:36 | webguest89 | but will the new bootloader be compatible with that version of rockbox I got a half a year or so ago? cause if not... screw this, as soon as I get home, I'll put my old version back again |
00:17:54 | Bagder | Dhraakellian: no, 'asm' is the arch-specific directory |
00:18:16 | Mikachu | Dhraakellian: those directories are the headers for the kernel source iirc, try installing a linux-headers package or something like that? |
00:19:13 | Dhraakellian | linux-kernel-headers is already installed |
00:19:23 | * | Dhraakellian will try a -f |
00:19:25 | Llorean | webguest89: No, we don't guarantee things will work with severely outdated builds or bootloaders. But since nobody else, including me (and I have a Nano) is experiencing your problem, once you're up to date you shouldn't need to use extremely outdated builds. |
00:19:54 | Llorean | webguest89: But, thanks for expressing your unwillingness to help figure out whether this is a real bug or not if it's likely to cause you any real inconvenience. Nice community spirit, that. |
00:20:02 | gevaerts | webguest89: the "new" bootloader is from october 2008, so it should work with any rockbox version newer than that, and probably with some older versions as well |
00:21:13 | mt | linuxstb: http://www.rockbox.org/tracker/task/10182 |
00:21:30 | | Join funman [0] (n=fun@rockbox/developer/funman) |
00:21:35 | webguest89 | well, I need it to work. But okay, I'll install the new bootloader. And if it won't work, you will help me put back my old one. |
00:22:12 | Llorean | webguest89: No, if it doesn't, we'll continue trying to figure out why it doesn't. Because that's what actually matters. |
00:22:28 | | Quit rasher (Read error: 110 (Connection timed out)) |
00:22:31 | Llorean | If there's a bug it needs to actually be *fixed* not ignored. |
00:22:41 | linuxstb | mt: Do those DEBUGFs mean that the sim will display lots of debugging information for rm files now? |
00:22:56 | saratoga | running an old rockbox build on the ipod doesn't make much sense given how much we've changed recently |
00:23:44 | webguest89 | Uh ok. As long as it will work some day. I could tolerate a broken player for a few weeks or so... So. Doing that bootloader thingy now. |
00:24:29 | | Quit n1s ("Lämnar") |
00:24:36 | Dhraakellian | "zypper in -f linux-kernel-headers" and then retrying hasn't crapped out yet |
00:24:52 | webguest89 | @ saratoga: indeed, but at least that one _worked_ :) |
00:24:52 | mt | linuxstb: yes. |
00:24:59 | Torne | well, the beast flash has a configuratino area, which contains a bit which tells it what to do if the bootloader encounters a fatal error |
00:25:06 | Torne | if it's set to 1 it formats and reboots |
00:25:07 | Torne | :) |
00:25:16 | linuxstb | mt: Hmm, you shouldn't declare those metadata variables - you're adding 1KB to the size of Rockbox. (char title[256] etc) |
00:25:30 | Torne | i've not tracked down specifically where it decides the disk is wrong, but this is probably where it ends up |
00:25:34 | Llorean | webguest89: The current one works too, for everyone else. |
00:25:35 | gevaerts | Torne: you mean it's possible to just tell it not to do that? |
00:25:50 | Llorean | webguest89: But you chose to partially updated. |
00:25:59 | Llorean | *update |
00:26:07 | linuxstb | mt: And you should disable those debugs when you commit - it would be chaos if every part of Rockbox did that. |
00:26:07 | saratoga | current works fine you're just doing something wrong |
00:26:16 | Torne | gevaerts: it's quite possible there are *other* places in teh code which trigger the same behaviour |
00:26:24 | Torne | gevaerts: but this is certainly one, yes,a nd it could be disabled |
00:26:43 | Llorean | webguest89: RButil can install an updated bootloader for you in a flash, so it shouldn't take long for you to test. |
00:26:47 | Torne | writing to the config area in the flash seems *reasonably* safe. if its checksum is wrong it just re-initialises it from preset valus. |
00:27:10 | Torne | the problem is its not going to make the device usable :) |
00:27:27 | Torne | if you flip the bit it skips the logic to format itself but it still goes to the infinite "crashing" loop |
00:27:40 | Torne | so the bootloader will presumably never work again then, unless you pop the drive out and fix it externally :) |
00:27:45 | mt | linuxstb: At first I just copied the tags directly to the id3v1buffers, but then I did this thing because it looked neater. :) I could revert back to copying directly in the buffers. |
00:28:04 | Torne | gevaerts: but it seems like a relevant discovery at least. |
00:28:14 | | Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") |
00:28:18 | linuxstb | mt: Yes, copying directly to the buffers is better. |
00:28:32 | webguest89 | I do admit I want the newer version as well. I sense a png image viewer coming up :D Yep, downloading RButil now... |
00:28:51 | saratoga | speaking of rbutil, whats left to get it to install the AMS targets? |
00:29:03 | saratoga | just adding that list of firmware hashes to the website? |
00:29:03 | Llorean | Torne: I've had my Beast claim it needs to reformat when booting into the OF using Dual Boot. |
00:29:23 | Llorean | I rebooted into Rockbox, used it a few days, then accidentally booted the OF again later, and it didn't claim it needed to reformat |
00:29:30 | Torne | Llorean: yah. it looks like that's the fallback logic for *any* error at boot. |
00:29:32 | Torne | literally anything |
00:29:34 | Llorean | So there's some cases, at least, where it can mis-detect it needs to reformat |
00:30:00 | linuxstb | mt: Also, why use the id3v1 buffer? Is there a limit on tag length in RealAudio (you're limiting things to 32 characters if I understand correctly). |
00:30:06 | * | Llorean doesn't know why it stopped deciding it needed to reformat, though |
00:30:08 | Torne | i've not gotten too far into the boot process yet, not even to disk init, but already there are *loads* of places that call that error ahndler :) |
00:30:44 | Torne | Llorean: well ideally i'm going to work right through the boot process until it hands control to the nk.bin on disk, and make a list of every reason it might decide to format itself. :) |
00:30:50 | | Quit saratoga ("CGI:IRC (EOF)") |
00:30:53 | Torne | Llorean: then we can look and make sure we never do those things ;) |
00:31:05 | | Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) |
00:31:50 | Torne | Llorean: also hoping i will discover why later firmwares don't seem to allow the single boot bootloader. |
00:32:12 | Llorean | That's the most important one right now |
00:32:24 | Torne | yah. im not looking for anything in particular though |
00:32:24 | Llorean | Since it's the main thing preventing the Gigabeat S from upgrading to "supported" I believe. |
00:32:28 | Torne | i am literally trying to grok the entire boot process |
00:32:32 | | Quit matsl ("Leaving") |
00:32:34 | Torne | it's too awkward to find anything specific :) |
00:34:11 | webguest89 | Yup. version 3.0. And it boots up with less light. It's done. Checking the stuffs now... |
00:34:52 | webguest89 | Um, yes it works just fine ^^; |
00:35:17 | webguest89 | Apparently... |
00:35:33 | Llorean | This is part of why we ask you make sure everything's up to date before asking for help. ; |
00:35:35 | Llorean | ;) |
00:36:49 | mt | linuxstb: MAX_STRING is 92 bytes (the size of a id3v1 buffer). I believe this would be enough for one tag, right ? |
00:37:11 | linuxstb | mt: Sorry, I misread that as 32... |
00:37:16 | * | linuxstb cleans his monitor |
00:37:20 | | Join legendarymidget [0] (n=3ce62093@gateway/web/cgi-irc/labb.contactor.se/x-2e631c2883ba3d69) |
00:37:41 | linuxstb | mt: Well, a comment could be longer... |
00:37:53 | webguest89 | Thanks for your help! :D And please excuse one more question... theme compatibility? why won't old themes work on the new rockbox. I loved my customized BlackGlassMgrbis |
00:38:07 | Llorean | Because certain parts of the theme language have changed. |
00:38:25 | Llorean | it's usually a relatively simple process to update. |
00:38:46 | linuxstb | webguest89: Were you using a custom build of Rockbox in the past? (i.e. one with patches to add new theming features?) |
00:38:50 | | Quit legendarymidget (Client Quit) |
00:38:54 | mt | linuxstb: Comments could be read to id3v2buf then ? |
00:39:01 | mt | 300+ bytes iirc |
00:39:45 | linuxstb | mt: Well, other codecs just treat the id3v1 and id3v2 buffers as one large buffer, and put the tags there. |
00:40:15 | linuxstb | (see vorbis.c for example) |
00:41:58 | webguest89 | custom themes only (and tweaked by my hand to stuff in as much useful info as possible). Never patches of the actual software. Tho I downloaded cygwin today and plan to play around with it and compile myself that png plugin... |
00:43:34 | webguest89 | I wish somebody posted it as a rock file and spared me all the hassle. I only program in visual c++ |
00:43:47 | linuxstb | webguest89: If you post your theme somewhere, maybe someone will look at it and help you find the problem. No-one can say why your theme won't work without seeing it. |
00:44:16 | krazykit | webguest89, you can't really post a rock file, as it'll quickly stop working on newer builds. |
00:45:05 | Torne | anyone got a beast they'd be able to dump the flash from for me? :) patch for flash dumping is on FS #10410 |
00:45:21 | mt | linuxstb: OK, so now I've modified the parser to write directly to id3v1buf, and disabled DEBUGF (could be re-enabled with a define). The problem now is that a comment could be bigger than 92 characters, right ? |
00:45:25 | Torne | i could do with a couple more flashes to compare |
00:45:46 | webguest89 | I don't intend posting it. I just noticed it's totally screwed up with the new firmware. But I'm gonna fix it. I loved it. Ok, I understand. |
00:46:55 | webguest89 | can't be that hard. where do I find some info regarding the new wps files? |
00:47:25 | linuxstb | mt: Another comment - do you need to read desc and mimetype? |
00:48:26 | linuxstb | mt: Anything could be bigger than 92 characters (although comments is most likely). |
00:48:39 | Bagder | webguest89: you might be better off by getting a fresh theme that works, and then adapt it with the changes you want |
00:49:54 | pixelma | webguest89: I'd suggest searching the forums a bit, there were a few threads about the changes. Or read up on the new syntax in the CustomWPS wiki and compare to yours |
00:49:56 | | Join farthen [0] (n=farthen@e176174253.adsl.alicedsl.de) |
00:50:30 | webguest89 | yeah, i put the new default cabbiev2 for the time being. It has album arts :) |
00:50:37 | mt | linuxstb : No, no need to. Will lseek beyond them. |
00:51:04 | webguest89 | ok will google that. |
00:52:52 | *** | Saving seen data "./dancer.seen" |
00:54:49 | mt | linuxstb: Done. But about the tags, do you think it's a no-commit issue ? |
00:54:56 | linuxstb | mt: Have you measured the binary size increase in Rockbox when applying your patch? (the rockbox-info.txt file shows that) |
00:55:07 | linuxstb | mt: No, it can be improved later. |
00:55:56 | linuxstb | mt: The reason I'm looking at the metadata parser is because it's part of core Rockbox - so it needs to be "lean and mean"... |
00:56:22 | mt | I see. |
00:56:57 | | Quit mcuelenaere () |
00:56:58 | mt | I just thought that improvements could be done when optimizing later on. |
00:58:11 | webguest89 | Bye everybody, thanks for the help :) |
00:58:25 | mt | linuxstb: What's the difference between 'binary size' and 'actual size' ? |
00:58:36 | mt | Binary size = 611328 btw. |
00:58:55 | linuxstb | mt: And without your patch? |
01:00 |
01:00:31 | mt | hmm .. If you have time, I'll still have to checkout a clean copy. (I currently have no source copy without my patch :/ ) |
01:00:37 | | Quit webguest89 ("CGI:IRC (EOF)") |
01:00:49 | * | Mikachu hugs git |
01:00:49 | | Quit ender (" Everything we know about the Devil has been told us by the the friends of God.") |
01:00:59 | linuxstb | You can just reverse your patch (patch -R)... |
01:01:46 | Mikachu | (and if you don't have a patch yet, svn diff > mypatch.patch) |
01:02:11 | linuxstb | Or svn revert... |
01:02:22 | Mikachu | svn revert is not good if you haven't saved a patch :> |
01:02:39 | linuxstb | Yes, it does have that flaw... |
01:03:04 | linuxstb | mt: I think actual size includes any headers or checksums added to the main binary. |
01:03:41 | mt | linuxstb: But actual size is smaller than bin size ? |
01:04:05 | mt | Mikachu : I had the patch and was able to reverse it. (phew!) |
01:04:34 | Torne | does actual size not include bss? |
01:04:51 | linuxstb | mt: Then I guess it's the other way around - "actual size" is the size of the binary, and "binary size" is the binary + headers etc. |
01:05:09 | mt | linuxstb: Increase in bin size is 3072 |
01:05:28 | linuxstb | Torne: Neither includes bss |
01:05:46 | Mikachu | isn't bss all zeroes? :) |
01:06:12 | linuxstb | Initially, yes... |
01:06:27 | Torne | linuxstb: it seems like there should be a number that does.. :) |
01:06:34 | Torne | since bss takes up ram |
01:06:38 | linuxstb | "ramsize" |
01:06:43 | Torne | ahh |
01:06:52 | linuxstb | Or "RAM usage" to be precise |
01:07:38 | mt | linuxstb: So what is the significance of this increase in the bin size ? and when is it considered big ? |
01:07:40 | linuxstb | mt: Now you need to decrease that number as much as you can... |
01:07:48 | Torne | how would i go about moving the rom dumping code into target-specific bits of firmware/ ? |
01:08:32 | funman | which code ? |
01:08:32 | Torne | (i mean where to put it, what header to stuff itin, how to know if it's present) |
01:08:43 | linuxstb | mt: You simply need to make it as small as you can... |
01:09:02 | | Quit Thundercloud (Remote closed the connection) |
01:09:09 | Torne | funman: kugel rightly pointed out that the rom dump code in apps/debug_menu.c is target-specific and the file is already rather complicated and huge |
01:09:25 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
01:09:31 | linuxstb | mt: More RAM used by Rockbox itself means less RAM for audio buffering and other things. So we want to pay attention to it. |
01:09:33 | Torne | funman: and i'm adding yet another set of #ifdefs for the beast |
01:10:11 | mt | linuxstb: If I'm allowed a stupid question - How could I decrease it ? What affects bin size in a codec? |
01:10:25 | funman | Torne: just move it in firmware/target/sh/archos |
01:10:45 | Torne | funman: but then am i gonna need a config-*.h flag to say whether the target has that |
01:10:53 | linuxstb | mt: I'm just talking about the metadata parser (apps/metadata/rm.c). You make it smaller by writing the code more efficiently, and making sure you've removed any unneeded code. |
01:10:54 | funman | and create a debug-target.h file next to it, it will be included automagically |
01:11:25 | funman | Torne: sorry i'm wrong, debug-target.h inclusion is conditional (at the top of debug_menu.c) |
01:11:52 | Torne | but debug-target is a good place to put it at least? |
01:12:12 | funman | yes |
01:12:23 | funman | other targets use debug-XXXX.c / debug-target.h |
01:12:34 | | Join xnyhps [0] (n=xnyhps@2001:470:1f14:da:219:e3ff:fed7:c57c) |
01:13:07 | Torne | then just a define in there for DEBUG_CAN_ROMDUMP or something? |
01:13:28 | mt | linuxstb: Ah ok.. If it's alright, I could commit the changes now and work on that tomorrow (I really have to sleep now :) ). If not I will wait till I've decreased bin size before committing any changes. |
01:13:44 | Torne | this is the first thing i've changed in core that wasn't localised, so not sure what is good form :) |
01:15:22 | funman | Torne: hum what is this function's name ? (debug_menu.c is *very* cluttered) |
01:15:22 | linuxstb | mt: It's never a good idea to commit when you're tired (in case something goes wrong and you need to fix it...) |
01:16:22 | Torne | funman: dbg_save_roms |
01:16:41 | Torne | funman: there are already three versions, and imx31 makes four :) |
01:16:54 | mt | linuxstb: Good point :) .. I'll just upload another patch now and leave everything else for tomorrow. |
01:17:13 | funman | Torne: whatever you choose to do, we should do the same for other target specific options |
01:17:20 | Torne | funman: yeah i was looking at that |
01:17:24 | Torne | some of them are kinda done that way already |
01:17:37 | Torne | dbg_ports has code in debug_menu.c for a few targets, then just calls __dbg_port for all the others |
01:17:45 | Torne | which is indeed in debug-target.h |
01:17:46 | funman | Torne: or even provide a way for targets to add their own entries in the menu (from their target specific code and not debug_menu.c) |
01:18:10 | Torne | that could be a *lot* tidier, yes.. |
01:18:20 | Torne | though the options might end up in different orders then :) |
01:18:24 | funman | is there any common code in this file ? |
01:18:46 | Torne | very little |
01:19:24 | funman | logf/cpuboost/screendump .. |
01:19:31 | | Join farthen_ [0] (n=farthen@e176144030.adsl.alicedsl.de) |
01:19:38 | Torne | h, actually yah |
01:19:38 | Torne | and most of the disk stuff |
01:19:39 | Torne | and usb hid |
01:19:40 | DBUG | Sent KICK Torne to server |
01:19:40 | Torne | etc |
01:19:40 | Kick | (#rockbox Torne :No flooding!) by logbot!n=bjst@rockbox/bot/logbot |
01:19:51 | | Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk) |
01:20:01 | funman | I think there some people mentioned problems with the debug menu |
01:20:07 | Torne | ok i need to press enter less often. |
01:20:09 | funman | like items not belonging there |
01:20:12 | funman | Torne: ^^ |
01:20:29 | Torne | i have a bad habit of punctuating with carriage return instead of comma |
01:20:32 | funman | also the possibility to remove the debug menu from release builds (which could save a bit of binsize) |
01:20:45 | funman | i |
01:20:46 | funman | see |
01:20:52 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
01:21:11 | Torne | it does seem ripe for a reorg, yes. |
01:21:24 | Torne | in which case i might, er, *not* volunteer for that one :) |
01:21:47 | funman | Torne: well i could help you |
01:22:06 | funman | I did that for the timer.c file |
01:22:16 | * | linuxstb sees Torne is finding the "start to make a simple change and end up refactoring a large chunk of Rockbox" effect... |
01:22:28 | Torne | linuxstb: that's called "software development" isn't it? @) |
01:22:42 | funman | Torne: i think there isn't much target specific bits in apps/ now |
01:23:50 | Torne | i think having the targets add their own menu options would be a good start for quite a few of those options |
01:23:52 | pixelma | if someone is *really* bored, he or she could go through all the button tables in the manual's tex files and change them to one readable indentation and also writing style... :\ |
01:24:16 | Torne | since it looks like most of the implementations of those are completely seperate and don't depend on anything else in debug_menu.c |
01:25:06 | Torne | also the really target specific stuff would probably be first on the chopping block to remove stuff from release builds |
01:25:20 | kugel | Torne: isn't this for the beast |
01:25:30 | Torne | kugel: that's the one i'm trying to add, yes :) |
01:25:38 | Torne | the patch you looked at yesterday |
01:25:43 | kugel | that one already has debug-XX.c |
01:25:53 | funman | Torne: timer.c went from 365 lines to 63 (almost 6x less) : much more readable .. for both common code and target code |
01:26:31 | Torne | kugel: yes, but i was gonna move the other target's dbg_save_roms as well for consistency. and now i'm looking at all the *other* bits of that file that are a big ifdef'ed mess :) |
01:26:36 | funman | kugel: but debug-XX.c only has 2 menu entries (view hardware info and view ports) |
01:26:46 | kugel | a #define in debug-target.h seems sensible, and some sort of debug_rom_dump(void) { target_rom_dump() } |
01:26:52 | Torne | not all targets use debug-XX.c for those entries either |
01:27:02 | Torne | the older ones are implemented right in debug-menu.c |
01:27:50 | Torne | kugel: that sonuds reasonable but having the targets add menu entries would remove even more :) |
01:28:25 | kugel | for specific stuff yes, but I thought rom dump is relatively common? |
01:28:44 | Torne | it's only implemented for three processors |
01:28:47 | funman | there would be no common code anyway between the targets |
01:28:49 | Torne | four, with the imx31 |
01:29:46 | Torne | the effort of actually making it generic would be sprintf'ing filenames with address ranges and the like |
01:29:59 | | Quit farthen (Read error: 110 (Connection timed out)) |
01:30:05 | Torne | whih probaly works out as more code than just having the targets do it themselves with no shared code :) |
01:30:30 | kugel | I think we can have targets add menu entries also |
01:30:32 | Torne | not all the targets have only one rom, and so on |
01:30:47 | | Part xnyhps |
01:31:22 | funman | the target code could even be moved progressively |
01:31:32 | | Quit saratoga ("Page closed") |
01:32:32 | kugel | sadly, I have no real idea how simplelist works, but I think items can be hidden based on some callback |
01:33:36 | kugel | Torne: but almost all targets have rom dump as you can see |
01:33:53 | kugel | it's basically only the flash-based PPs that don't have it (and the ams sansas) |
01:33:55 | funman | the menu is just a structure with { "string", function } elements |
01:34:37 | Torne | yah, simplelist is too simple for this :) |
01:35:15 | Torne | so just having defines seems like a better plan for now |
01:35:33 | funman | :( |
01:35:50 | Torne | it'll still be way shorter |
01:35:54 | Torne | and it could always be done more later |
01:36:12 | funman | shorter than writing the function in debug_menu.c ? |
01:36:44 | Torne | debug_menu.c can just have the menu item in an #ifdef DEBUG_ROM_DUMP |
01:36:52 | Torne | and call the function in debug-XX.c directly |
01:37:30 | funman | you could just add your targets to the list without using a DEBUG_ROM_DUMP |
01:37:49 | Torne | #ifdef huge list of cpus is kinda ugly though :) |
01:38:08 | funman | yes but #ifdef huge list of cpus mixed with capabilities defines is even more ugly |
01:38:39 | * | funman adds debug_menu.c cleaning in his TODO list |
01:38:41 | Torne | hm? |
01:38:47 | Torne | you wouldn't need the cpu defines any more, is the point |
01:39:17 | funman | Torne: yes but there is a lot of other functions conditional on "list of cpus", no ? |
01:39:18 | kugel | you want to add debug-sh.c, debug-cf.c and and debug-pp.c? |
01:40:49 | Torne | hrm. |
01:41:34 | Torne | i dunno, that's why i was asking :) |
01:41:47 | kugel | you could totally do that imo |
01:42:42 | * | Torne volunteers funman :) |
01:43:11 | * | Torne is having too much 'fun' reversing the beast bootloader |
01:43:48 | funman | Torne: well i make no deadline promise, but i'm willing to do this |
01:44:05 | Torne | funman: it's not particularly vital from my pov |
01:44:16 | Torne | having the beast dumping patch committed is not that important |
01:44:33 | Torne | i am guessing anyone willing to dump a beast rom for me is already building it themselves :) |
01:46:43 | | Quit funman ("free(random());") |
02:00 |
02:02:10 | | Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
02:06:32 | | Quit barrywardell () |
02:07:31 | CIA-71 | New commit by kugel (r21682): Fix returning too early (before cleanup) in RFAC, which led to not cancelling ... |
02:18:53 | CIA-71 | New commit by zagor (r21683): Killed children must let go of their cores. |
02:20:30 | | Join homielowe [0] (n=homielow@66.183.72.25) |
02:21:02 | CIA-71 | New commit by zagor (r21684): Moved handoutbuilds() to last, to avoid end-of-round being ran before end-of-build. Skipped the .info file, since that's already logged in the ... |
02:30:46 | | Quit efyx_ (Read error: 104 (Connection reset by peer)) |
02:32:39 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
02:34:07 | Zagor | getting closer: http://build.rockbox.org/new.cgi |
02:34:40 | kugel | Zagor: uhh nice! |
02:35:10 | Zagor | the last round was as fast with 12 server as the old build was with 22! |
02:35:20 | kugel | awesome! |
02:35:36 | kugel | and the fast servers are still working for the old system, I guess? |
02:37:23 | Zagor | well it's a mixed bunch in both the old and new server pools |
02:38:16 | kugel | I see, still impressive. The new system is the win |
02:38:35 | kugel | does it already do "live updates" also? |
02:39:29 | CIA-71 | New commit by zagor (r21685): Bumped minimum client revision to 11. |
02:40:57 | Zagor | kugel: yes it does |
02:41:12 | Zagor | we added that during devcon already |
02:41:28 | kugel | heh, I didn't know |
02:42:30 | kugel | the logs aren't accessible yet though |
02:48:57 | kugel | Zagor: how does the ranking of the heaviness of a build work? |
02:51:31 | Zagor | the server simply sends the heavy builds to the heavy servers |
02:52:30 | kugel | I mean how does the server know a build is heavy? |
02:52:55 | *** | Saving seen data "./dancer.seen" |
02:53:37 | Zagor | we keep it in a table. it is currently a static table derived from gevaerts' binsize builds, but the idea is to create the table dynamically using statistics from previous builds. |
02:54:17 | kugel | Hmm, I wonder if that is smart |
02:54:44 | Zagor | ? |
02:55:30 | kugel | giving a fast client a heavy build will make it appear less heavy then. And a utterly slow client that needs 100s for a bootloader will let the build appear heavy, won't it? |
02:55:53 | Zagor | naturally the relative speed of the clients will have to be taken into account |
02:56:11 | kugel | I'm thinking the length of the logs (i.e. the number of compiled files + genlang etc) is a good messure |
02:56:26 | kugel | but what do I know :) |
02:56:46 | kugel | measure* |
02:57:15 | Zagor | actually we plan to simply to a "calibration run" every 100 commits, where a single server builds all targets. that eliminates the client speed from the rating. |
02:57:57 | Zagor | I really need to go to bed now... see you tomorrow. |
02:58:00 | | Quit Zagor ("Clint excited") |
02:58:10 | | Quit kugel (Remote closed the connection) |
03:00 |
03:08:12 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
03:13:27 | | Quit farthen_ () |
03:39:32 | | Quit Sajber^ (Read error: 54 (Connection reset by peer)) |
03:42:45 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
03:42:58 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
03:45:47 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
03:50:43 | | Quit bubsy (Client Quit) |
03:56:06 | | Quit pixelma (Nick collision from services.) |
03:56:06 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
03:56:24 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
03:56:59 | | Quit amiconn (Nick collision from services.) |
03:57:03 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
03:57:12 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
04:00 |
04:02:18 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
04:27:49 | | Quit efyx_ (Remote closed the connection) |
04:41:43 | | Quit dmb (Read error: 113 (No route to host)) |
04:52:58 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:11:24 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
05:14:18 | | Quit bubsy (Client Quit) |
05:20:56 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
05:21:16 | | Quit bubsy (Remote closed the connection) |
05:22:16 | | Join bubsy [0] (i=Bubsy@94.139.72.137) |
05:28:43 | | Quit homielowe () |
05:33:04 | | Quit Horscht ("Verlassend") |
05:55:08 | | Quit FlynDice (Remote closed the connection) |
05:58:53 | | Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
06:00 |
06:13:34 | | Quit JdGordon ("Leaving.") |
06:17:07 | | Join JdGordon [0] (n=Miranda@c-67-160-44-90.hsd1.wa.comcast.net) |
06:27:16 | | Join ReKleSS [0] (n=ReKleSS@d58-110-100-89.mas6.nsw.optusnet.com.au) |
06:38:52 | | Join donutman25 [0] (n=Dagni@65.75.86.64) |
06:52:24 | | Join homielowe [0] (n=homielow@66.183.72.25) |
06:53:00 | *** | Saving seen data "./dancer.seen" |
07:00 |
07:15:05 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
07:21:02 | | Join stoffel [0] (n=quassel@p57B4E41A.dip.t-dialin.net) |
07:23:00 | | Part BHSPitMonkey ("Ex-Chat") |
07:31:38 | drakonik | What's the difference between the sim build and the actual build you'd install onto your player? |
07:31:46 | | Part donutman25 |
07:33:31 | drakonik | I ask because whatever it is, it matters. I copied the sim onto my ipod, wtih the full contents of the disk inside the simdisk directory. And the sim didn't crash. If it really was JUST a hardware issue, wouldn't the sim crash as well? |
07:33:31 | Llorean | One has hardware drivers and works as an OS, the other is an application that runs on the PC. |
07:34:08 | Llorean | Why would the sim crash? The sim has no hardware drivers at all, it just uses the host computer's operating system. |
07:34:17 | drakonik | hm |
07:36:22 | drakonik | I dunno. My understanding of the causes of the crash was "Your ipod hardware is faulty". I figured that if it was true, then the sim should choke on the hardware issue the same way the real software does. |
07:36:56 | drakonik | I dunno, I'm kinda grasping at straws now. I've exhausted my options and I'm not ready to give up yet. |
07:37:49 | Llorean | The sim doesn't even work remotely like how the real software does. |
07:37:58 | drakonik | Yeah, I figured. |
07:41:36 | drakonik | Hm. Is there some kind of uberlogging option/tool that I could use? Comb through everything rockbox is doing before it crashes? Having the db log the file opening isn't sufficient cause the log doesn't stop at the same file every time. Somewhere there's a common cause for the crashes and I want to know what it is, in more detail than "your hardware's fault kthbai" =\ |
07:44:34 | Llorean | You're going to need to code up your own solution if you want more logging than Rockbox provide.s |
07:44:44 | drakonik | I figured as much. |
07:48:02 | Llorean | Really though, why are you so unwilling to believe it's a hardware issue? |
07:48:35 | Llorean | What about it makes you think there's something else? |
07:52:19 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) |
07:53:01 | drakonik | Because my ipod has never EVER exhibited any behavior like this. |
07:53:05 | drakonik | In its entire lifespan. |
07:53:17 | drakonik | Not a single crash, not a single battery glitch |
07:53:25 | Llorean | What is that supposed to demonstrate exactly? |
07:53:35 | Blue_Dude | A fix for the fixed point code bloat is at FS #10411. Thanks. |
07:53:37 | Llorean | Problems *start* which means there's a point before they were there. |
07:53:38 | | Quit Blue_Dude (Client Quit) |
07:53:41 | drakonik | Of course. |
07:54:56 | Llorean | Is there a formula for consistently reproducing the problem? Have you isolated a file that triggers it each time? Can you cause it to happen on another iPod of the same model using the same version of Rockbox? |
07:55:22 | drakonik | I don't have access to another ipod. |
07:56:16 | Llorean | The problem is, you're the _only_ person experiencing exactly this. |
07:56:19 | drakonik | And yeah, I know how the evidence looks. I just think that if my ipod were prone to having these kinds of fits, it'd have started showing a long time ago, and not the exact moment I installed Rockbox and tried to do a database scan |
07:56:32 | Llorean | Why would it have started a long time ago? |
07:56:52 | Llorean | Hardware fails all the time. iPods are particularly prone to start showing problems after they've aged some. |
07:56:58 | drakonik | Of course. |
07:57:40 | Llorean | So you're going to either need to thoroughly investigate with a systematic plan, or just accept that failure may be the case. |
07:57:52 | drakonik | But. Well, what exactly is a database scan, from an operational point of view? Opening a file, reading its contents/metadata, then closing it. |
07:58:08 | drakonik | Right? |
07:58:08 | Llorean | Coming up with random things really isn't going to help you, especially without developing a good enough understanding that you think trying the sim is going to tell you something. |
07:58:33 | drakonik | The sim was a shot in the dark, I won't deny it. |
07:59:13 | Llorean | Rationalizing isn't going to do too much good. Yes, that's more or less all a database scan is. But saying "so if other file openings work, why doesn't the database" doesn't necessarily mean anything. |
07:59:22 | Llorean | The database opens a lot more files, a lot more quickly, than most other operations, for example. |
08:00 |
08:00:08 | Llorean | Rather than try to rationalize why it's *not* hardware, try to find out specifically what it *is* by doing some deeper investigation. Logic games aren't going to get you much if they haven't gotten you anything already. |
08:00:21 | drakonik | Right |
08:00:34 | drakonik | Which is why I asked about logging. |
08:04:00 | Llorean | As I said, you'll have to code up your own solution for that if the current logging offered isn't good enough. |
08:06:35 | | Quit stoffel (Read error: 104 (Connection reset by peer)) |
08:08:06 | drakonik | Yeah. I'll work on it in the morning, I'm in no fit state to code. |
08:16:19 | | Quit JdGordon (Read error: 104 (Connection reset by peer)) |
08:29:51 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
08:30:46 | | Quit homielowe () |
08:33:19 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:37:25 | | Part safetydan ("Leaving.") |
08:38:54 | | Join r4v5 [0] (n=r4v5@lenin.glasnost.us) |
08:40:18 | r4v5 | So I'm using the most recent daily (r21682-090706) on my sansa e280 and usb has stopped working. In both mac os and windows, the device seems to disconnect itself or time out. |
08:42:07 | | Join stoffel [0] (n=quassel@p57B4E41A.dip.t-dialin.net) |
08:42:57 | Llorean | r4v5: Unrelated, but we don't really recommend using the daily. Why not the current build instead? |
08:43:16 | Llorean | Also, what build did you upgrade from? |
08:44:17 | r4v5 | I wish I had kept track. I noticed the reversion from somewhere in the last month. |
08:44:53 | r4v5 | Time to start with 3.3 and binary search through builds, I suppose. |
08:45:11 | Llorean | And why use a daily build rather than the current? |
08:45:59 | r4v5 | I was using the current; I apologize, I used the wrong term. |
08:46:33 | Llorean | So you skipped over about a month of builds and USB stopped working? |
08:46:54 | r4v5 | Yes. |
08:46:58 | Llorean | Are you sure the cable hasn't just gone bad. It's surprising how often it's something as simple as that. We haven't had anyone else report problems or anything. |
08:47:18 | r4v5 | I tried with a second cable because I was suspecting that, actually. |
08:47:53 | r4v5 | Transfers work with the OF but using rockbox it times out. Moving the mousewheel gives me a screen at like half brightness compared to usual. |
08:53:01 | *** | Saving seen data "./dancer.seen" |
08:56:23 | | Join petur [50] (n=petur@rockbox/developer/petur) |
08:57:36 | | Join Rob2222 [0] (n=Miranda@p4FDCC076.dip.t-dialin.net) |
08:59:48 | Dhraakellian | my brother noticed that my e260v1 wasn't mounting on his XP laptop with recentish svn |
08:59:55 | Dhraakellian | worked with the OF |
08:59:59 | Dhraakellian | same on my linux box |
09:00 |
09:00:04 | r4v5 | Okay, it's working fine on linux for me now |
09:00:19 | Dhraakellian | reverted to 3.3, and it worked on my linux box. didn't try it on his laptop |
09:00:22 | Dhraakellian | yet |
09:00:31 | Dhraakellian | (or is it vista? ...I don't recall) |
09:01:04 | Llorean | All well and good, but you could've also filed a bug report documenting the version, the hardware, and how to reproduce... |
09:01:08 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
09:02:19 | * | Dhraakellian wonders where to find version information in the zip file |
09:02:32 | Llorean | In the rockbox-info.txt file |
09:02:39 | Dhraakellian | ah |
09:02:49 | Dhraakellian | I need to go to bed. I didn't even see that |
09:02:50 | Llorean | It also can be viewed from the menus in Rockbox. |
09:02:56 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
09:03:10 | Dhraakellian | Llorean: yeah, but my brother has my e260 atm |
09:03:10 | Llorean | And since you'd need to be in Rockbox to confirm the exact behaviour, including what your host OS says when attempting to connect, I don't know why you'd be looking in the .zip anyway |
09:03:31 | Dhraakellian | Version: r21593-090701 |
09:03:57 | Llorean | I didn't ask for your version number. I asked you to file a proper bug report documenting as many useful details as possible. |
09:04:13 | Dhraakellian | Llorean: I'll look into it tomorrow |
09:04:42 | Llorean | I'm not someone who can fix this, and bug reports are the proper way to make sure information is posted for the people who can look into it more deeply |
09:04:53 | Llorean | But they should always be filed against the current version, with instructions to reproduce if possible |
09:04:57 | GodEater | morning everybody |
09:06:34 | Dhraakellian | my first instinct was to put it back to 3.3, since it'll probably be heading back down south with him when he goes home. |
09:07:05 | Dhraakellian | Llorean: test with current version, describe behavior, how to reproduce, and possibly track down when it started? |
09:07:36 | Llorean | Dhraakellian: Exactly. |
09:08:24 | Dhraakellian | should probably also touch base with r4v5, since I only mentioned it right now because I saw what he said as I was passing by |
09:09:34 | Dhraakellian | oh, and just a general thanks/kudos to the devs specifically working on the SansaAMS ports |
09:11:42 | Dhraakellian | (not that the rest of the devs don't deserve thanks as well, of course) |
09:12:07 | Dhraakellian | and now I must head to bed before I make a total idiot of myself or veer off-topic |
09:13:04 | r4v5 | Unfortunately, in my attempt to figure out steps to reproduce, it's working fine for me. |
09:13:12 | r4v5 | Which I guess is fortunate. |
09:16:06 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
09:16:10 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
09:16:14 | Dhraakellian | heh |
09:16:42 | Dhraakellian | well, I'll try to see if I can reproduce it tomorrow |
09:24:35 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
09:31:04 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
09:32:35 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
09:45:21 | | Quit stoffel (Remote closed the connection) |
09:47:34 | | Quit Thundercloud (Remote closed the connection) |
09:50:10 | | Quit Llorean ("Leaving.") |
09:51:22 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
09:51:24 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
09:52:01 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
09:52:16 | | Quit Llorean (Client Quit) |
09:53:34 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
09:57:59 | | Join _Auron_ [0] (n=DarkAuro@adsl-76-203-192-240.dsl.rcsntx.sbcglobal.net) |
10:00 |
10:00:05 | | Part Llorean |
10:00:34 | | Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) |
10:04:23 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
10:07:39 | | Quit Llorean (Client Quit) |
10:13:45 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
10:13:57 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
10:18:23 | CIA-71 | New commit by lenzone10 (r21686): Updated italian translation. |
10:28:38 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
10:29:44 | | Quit XavierGr (Client Quit) |
10:32:52 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
10:39:42 | | Quit flydutch ("/* empty */") |
10:39:58 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
10:46:42 | | Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) |
10:50:34 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
10:53:03 | *** | Saving seen data "./dancer.seen" |
11:00 |
11:16:46 | | Join stoffel [0] (n=quassel@p57B4E41A.dip.t-dialin.net) |
11:20:53 | | Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) |
11:23:05 | | Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
11:27:44 | | Quit kugel (Nick collision from services.) |
11:27:52 | | Join kugel [0] (n=kugel@141.45.205.29) |
11:52:15 | | Quit perrikwp ("Leaving.") |
12:00 |
12:01:35 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
12:16:52 | | Quit mt (Remote closed the connection) |
12:24:55 | GodEater | is the idea that the build client should clear up the build-nnnnn directories it creates ? |
12:48:34 | | Quit Sajber^ (Read error: 54 (Connection reset by peer)) |
12:49:09 | | Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) |
12:53:05 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:02:33 | | Quit kugel (Remote closed the connection) |
13:04:35 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
13:09:39 | | Join funman [0] (n=fun@rockbox/developer/funman) |
13:28:07 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
13:30:22 | | Join chrysaetos [0] (n=9d52e746@gateway/web/cgi-irc/labb.contactor.se/x-ce75ab62e067b244) |
13:31:22 | | Quit chrysaetos (Client Quit) |
13:32:43 | | Join mt [0] (n=mt@41.233.147.176) |
13:43:27 | | Join linuxguy4 [0] (n=timj@68.253.217.221) |
13:47:47 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
13:56:26 | | Quit linuxguy3 (Read error: 110 (Connection timed out)) |
14:00 |
14:01:31 | | Join paulk [0] (n=paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
14:02:33 | paulk | Hello ! Are the SDHC microSD cards supported by Rockbox (for a sansa 250) ? |
14:03:14 | paulk | microSDHC cards* |
14:05:14 | funman | yes |
14:05:24 | | Join linuxguy3 [0] (n=timj@68.253.217.221) |
14:06:02 | paulk | great ! |
14:07:28 | paulk | thank-you ! |
14:07:34 | GodEater | we like the easy questions :D |
14:07:41 | paulk | ^^ |
14:09:28 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
14:17:24 | | Quit linuxguy4 (Read error: 113 (No route to host)) |
14:19:16 | mt | linuxstb: Shouldn't I consider RAM usage not Binary size ? Whatever modifications I make to metadata/rm.c only affect RAM usage. |
14:20:15 | kugel | funman: so, after FlynDice's post, I think we can disable voltage scaling and make the forum post? |
14:20:22 | funman | both in fact, binary size is the size of the rockbox.XXX file, while RAM usage is the size filled by it (rockbox.XXX file + stack + bss) |
14:20:40 | funman | kugel: yeah, are the bootloaders and mkamsboot binaries online ? |
14:27:23 | mt | Does using lseek() instead of read() make it possible to increase any of both ? |
14:29:11 | funman | it's not related |
14:29:35 | funman | the binsize depends of the size of your code (functions), and the static variables you declare (they go in bss) |
14:30:21 | mcuelenaere | mt: did you read my Flyspray comment? |
14:30:44 | mt | mcuelenaere: No, will check now. |
14:31:05 | kugel | funman: yes |
14:31:21 | kugel | http://download.rockbox.org/bootloader/sandisk-sansa/ |
14:32:19 | funman | the fuze bootloader is 11kB bigger than e200v2 ! |
14:35:24 | mt | mcuelenaere: Are you talking about metadata/rm.c ? |
14:35:29 | | Quit paulk ("Ex-Chat") |
14:35:41 | mcuelenaere | mt: I think so yes, lemme check the patch |
14:35:57 | mcuelenaere | yep |
14:37:41 | mt | mcuelenaere: read_uint* functions are already defined in metadata_common.[c/h] .. |
14:38:00 | mcuelenaere | oh |
14:38:08 | * | mcuelenaere still thinks they are inefficient |
14:38:16 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
14:38:53 | mt | Well, they could be altered, but this will be sort of a big change. :) |
14:39:13 | mcuelenaere | yes ok, but that's unrelated to your work so forget I said it :) |
14:39:23 | | Join perrikwp [0] (n=Keith@74.167.148.160) |
14:41:21 | mt | I think maybe later (after soc ends :) ) new functions could be written, with the current ones intact, until all metadata parsers are using the new ones. |
14:41:32 | | Quit robin0800 ("Leaving") |
14:42:32 | kugel | funman: the logo is bigger on the fuze |
14:43:36 | | Join robin0800 [0] (n=robin080@81.98.157.181) |
14:43:51 | funman | how come since they use the same screen size (only orientation is different) ? |
14:44:29 | kugel | the logo is full width |
14:44:37 | kugel | not full <whatever side is larger> |
14:44:51 | | Join MethoS [0] (n=clemens@85.16.165.250) |
14:45:50 | kugel | the e200v2 one is 176x54, the fuze's one 220x68 |
14:47:24 | kugel | funman: http://pastie.org/535583 |
14:48:05 | funman | ok |
14:49:28 | kugel | funman: your mkamsboot binaries are somaller than mine too |
14:51:17 | funman | upx packed ;) |
14:51:47 | funman | and stripped |
14:51:53 | kugel | what is upx packed? |
14:52:10 | funman | upx is a compressor for executables |
14:53:06 | *** | Saving seen data "./dancer.seen" |
14:53:38 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) |
14:54:45 | Blue_Dude | Saratoga was right. The exp function wasn't broken as long as you keep the input within bounds. My test was bad. |
14:54:58 | Blue_Dude | So the bloat is gone. FS #10411 |
15:00 |
15:00:04 | | Join Nico_P [0] (i=39428a0e@rockbox/developer/NicoP) |
15:00:51 | mcuelenaere | Blue_Dude: I'm willing to commit this, but I'm not sure about the changes you did; is this the original code or did you optimise it a bit? |
15:02:31 | Blue_Dude | It's mostly converting back to 32 bit variables. It is modified from the original to allow for something other than 12 fractional bits (notice the constants are larger), but it's mostly the same. fp_factor is a single line now. |
15:02:32 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
15:03:20 | | Quit perrikwp ("Leaving.") |
15:03:24 | mcuelenaere | well I can't verify whether this breaks something, so I'll wait till someone who knows the code verifies it doesn't |
15:03:27 | kugel | Blue_Dude: you seem to have the svn executable property always set, what platform are you on? |
15:03:44 | mcuelenaere | kugel: I have that too as a default option if I don't change it |
15:03:55 | mcuelenaere | (when creating new files, that is) |
15:04:11 | kugel | hm, I see |
15:04:15 | Blue_Dude | kugel: that's something generated by svn diff. I didn't know if it's significant so I left it in. I'm on win XP running cygwin. |
15:04:30 | | Join michael__ [0] (n=michael@87.167.213.3) |
15:04:32 | Nico_P | has anyone considered giving the recently released "milepost GCC" a try? |
15:05:10 | Blue_Dude | mcuelenaere: how to change svn so I don't get svn:executable anymore? |
15:05:11 | | Quit michael__ (Client Quit) |
15:05:21 | mcuelenaere | Blue_Dude: svn propdel svn:executable [FILE] |
15:05:39 | Blue_Dude | ok, I'll make them go away then. |
15:05:41 | mcuelenaere | but don't worry, I'll remove those (if they even get set, I don't think 'patch' sets these parameters) |
15:05:42 | kugel | funman: I'd also still would like reboot on usb insert :( |
15:05:54 | mcuelenaere | s/parameters/properties/ |
15:13:20 | funman | kugel: a bit of cleanup of the usb code is needed for that |
15:13:50 | CIA-71 | New commit by kugel (r21687): Sansa AMS: Disable voltage scaling for now until we found a way to make it reliable for everyone, it's causing problems with storage for many people. |
15:13:59 | funman | currently, bits of target usb code are needed for that (and that is incorrect) |
15:14:40 | kugel | it just needs a little hack :> |
15:14:51 | funman | well when things can be done properly it's better |
15:14:58 | kugel | yes sure |
15:14:59 | funman | i'll look at this today |
15:15:22 | funman | i don't think this is a big work |
15:15:30 | funman | gevaerts: do you have an idea ? |
15:20:38 | gevaerts | funman: as far as I know the *only* bits of target usb code that are needed are the actual plugin detection bits. Is that really too much? |
15:21:42 | funman | usb.c try_reboot() is #ifdef HAVE_USBSTACK , which implies a bit more code |
15:22:12 | | Join Lynx_ [0] (n=Lynx@xdsl-78-34-206-83.netcologne.de) |
15:23:06 | Nico_P | Bagder: here? |
15:23:24 | gevaerts | possibly, but the rest can be just stubs |
15:23:34 | funman | why needing stubs at all? |
15:24:21 | funman | usb plug detection is not an "usb stack" |
15:24:33 | GodEater | Nico_P: Bagder is on holiday |
15:25:02 | | Join kachna|lappy [0] (n=kachna@84.42.177.178) |
15:25:04 | Nico_P | oh, good for him :) |
15:25:14 | Nico_P | I wasn't sure whether he had left already |
15:25:38 | gevaerts | funman: rebooting on plugin is meant as a temporary hack until a full usb driver is ready |
15:25:40 | | Quit MethoS (Read error: 110 (Connection timed out)) |
15:29:48 | funman | ok i'll look at it then |
15:30:59 | | Quit MarcGuay_ (Remote closed the connection) |
15:32:38 | GodEater | Nico_P: what were you after from him ? |
15:33:38 | GodEater | LambdaCalculus37: did you ever manage to get your 2G into DFU mode *without* scrapping the firmware partition ? |
15:34:02 | LambdaCalculus37 | GodEater: No, I haven't tried. I can now, if you'd like. |
15:34:24 | GodEater | it seems there are some Nanos which will do it, and some which won't |
15:34:34 | Nico_P | GodEater: just a few questions about the new build system |
15:34:35 | GodEater | I tried with Mrs. GodEater's Nano a lot, and can't make it work |
15:34:43 | GodEater | Nico_P: are you running it already ? |
15:35:00 | Nico_P | no, I have no server |
15:35:14 | GodEater | LambdaCalculus37: however the trick to get the Nano 3G into DFU mode works like a charm |
15:35:26 | GodEater | Nico_P: just a laptop or something ? |
15:35:42 | Nico_P | exactly |
15:35:46 | LambdaCalculus37 | GodEater: The trick is holding MENU+SELECT until the screen goes black, right? |
15:36:01 | GodEater | Nico_P: I run it on my laptop when I'm using it, on the off chance a build comes through ;) |
15:36:08 | GodEater | LambdaCalculus37: correct |
15:36:32 | LambdaCalculus37 | GodEater: I have a 3G nano here. Let me see that trick. |
15:36:33 | Nico_P | GodEater: well, I'll think about doing that with the new build system |
15:37:03 | Nico_P | the current one made it too much of a hassle and my comp isn't powerful enough to be worth it |
15:37:25 | GodEater | the new system makes it very easy to join and leave, and it's designed to take advantage of everyone |
15:37:36 | GodEater | as far as I understand it anyway |
15:38:13 | LambdaCalculus37 | GodEater: I think I need to time it better, but every time the screen goes black on mine, it immediately resets again when I release the buttons. |
15:38:22 | rasher | Nico_P: What questions do you have? Maybe some of us know |
15:38:30 | GodEater | LambdaCalculus37: do it whilst it's disconnected ? |
15:38:35 | GodEater | I think |
15:38:39 | LambdaCalculus37 | It is disconnected. |
15:38:49 | GodEater | LambdaCalculus37: curious, I got it to work first time |
15:38:56 | Nico_P | rasher: actually I found the answer on BuildServerRemake :) |
15:39:02 | rasher | Ah |
15:39:21 | Nico_P | it was about the client ranking by speed |
15:40:29 | CIA-71 | New commit by kkurbjun (r21688): DM320: Add the same fix from r21647 |
15:40:31 | LambdaCalculus37 | GodEater: I got into DFU mode on the 2nd gen nano without trashing the firmware. |
15:40:43 | GodEater | LambdaCalculus37: that's SO annoying |
15:40:45 | | Quit Lynx_ (Read error: 104 (Connection reset by peer)) |
15:40:46 | GodEater | I cannot do it :( |
15:41:08 | GodEater | it's menu+select till reboot, then immediately |<< + Play right ? |
15:41:13 | LambdaCalculus37 | Yes. |
15:41:27 | GodEater | has no affect on mine at all - just reboots to the OF |
15:41:44 | LambdaCalculus37 | Are you holding BACK+PLAY? |
15:41:49 | Nico_P | has anything intersting come out of the recent developments at linux4nano? |
15:41:50 | | Join Lynx_ [0] (n=Lynx@xdsl-84-44-254-39.netcologne.de) |
15:42:36 | GodEater | LambdaCalculus37: of course |
15:42:49 | GodEater | Nico_P: not *hugely* interesting |
15:42:56 | GodEater | they think they can dump the decrypted firmware |
15:43:07 | GodEater | but they need to work out how to write to the dock adaptor to do that |
15:43:14 | GodEater | which so far they have epic failed at |
15:43:25 | GodEater | they also refuse to write anything down :( |
15:43:38 | GodEater | which is probably more annoying |
15:45:05 | Nico_P | if they do manage to dump the decrypted firmware, it means a port can officially start, doesn't it? |
15:45:41 | GodEater | Nico_P: well it would help immensely of course |
15:45:42 | funman | they also need to run a custom firmware |
15:45:56 | GodEater | but we'd still need to disassemble the OF to work out a lot of the hardware I'd guess |
15:46:16 | Torne | yah, the manuals available are not exactly complete/final |
15:46:26 | Torne | even for the soc itself |
15:46:30 | GodEater | I don't think it'd be quite as bad as the original ipods |
15:46:37 | GodEater | since there was virtually no docs at all for that |
15:46:41 | Torne | indeed. |
15:46:42 | GodEater | but still pretty hard work |
15:47:16 | | Join Blue_Dude_ [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) |
15:47:44 | LambdaCalculus37 | GodEater: The SOC is very similar to that in the Meizus, so we have a basis to work on, at least. |
15:48:06 | GodEater | yes, but as Torne says, it's still not perfect |
15:48:46 | Torne | (and christ that's an awful manual) |
15:49:55 | | Quit kugel (Read error: 110 (Connection timed out)) |
15:52:32 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
15:52:57 | | Quit Blue_Dude (Read error: 60 (Operation timed out)) |
15:53:12 | | Nick Blue_Dude_ is now known as Blue_Dude (n=chatzill@adsl-235-206-197.mco.bellsouth.net) |
15:54:54 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
15:54:54 | CIA-71 | New commit by funman (r21689): Samsa AMS: start of an USB driver (nothing working atm) ... |
15:55:51 | LambdaCalculus37 | \o/ |
15:56:05 | * | LambdaCalculus37 gives funman a beer just for starting the USB driver :) |
15:56:09 | funman | well, there is really nothing to applause |
15:56:24 | kugel | SAMSA!? |
15:56:24 | funman | I just had looked at getting some interaction with the USB registers but failed |
15:56:34 | funman | kugel: oops |
15:56:43 | funman | sAMSa just looks a nice shortcut for Sansa AMS ;) |
15:57:07 | kugel | ah, yea that's clever :) |
15:57:27 | | Quit n1s ("Lämnar") |
15:57:39 | kugel | http://forums.rockbox.org/index.php?topic=22137.0 |
15:57:46 | kugel | funman: do we have reboot now? |
15:58:00 | funman | like the commit log says, no |
15:58:28 | LambdaCalculus37 | kugel: Instructions for OS X can be similar to those for Linux (from your forum post). |
15:58:46 | kugel | LambdaCalculus37: I figured, but we have no binaries for that yet :) |
15:59:13 | LambdaCalculus37 | kugel: What do you need a binary for? |
15:59:14 | kugel | funman: oh, I didn't read the full log |
15:59:23 | kugel | LambdaCalculus37: OS X :P |
15:59:30 | kugel | mkamsboot |
15:59:42 | LambdaCalculus37 | kugel: I can do that now if you'd like. :) |
15:59:49 | kugel | would be cool |
16:00 |
16:00:21 | kugel | LambdaCalculus37: build it from this branch please: http://svn.rockbox.org/viewvc.cgi/branches/bootloader_ams_pp/ |
16:01:21 | | Quit GodEater ("Terminated with extreme prejudice - dircproxy 1.0.5") |
16:01:36 | | Join GodEater [0] (n=bibble@rockbox/staff/GodEater) |
16:02:12 | * | LambdaCalculus37 checks out that branch |
16:03:33 | | Join aaron424 [0] (n=chatzill@65.13.2.216) |
16:05:51 | * | kugel wonders if he should post in the official sandisk forum also |
16:05:56 | | Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) |
16:06:01 | funman | i wouldn't :) |
16:06:21 | kugel | many admins and mods posted there without showing any hate against rockbox |
16:06:46 | funman | i mean i think this would cause extra work for moderating the rockbox thread |
16:06:55 | LambdaCalculus37 | kugel: Probably best not to whack the beehive, though. |
16:07:10 | kugel | What? |
16:07:39 | mc2739 | funman, kugel - do either of you see the virtual led on your fuze during disk access? |
16:07:51 | funman | no |
16:08:01 | funman | where is the code for the virtual led? |
16:08:18 | kugel | mc2739: indeed, I already wondered why that's not there |
16:08:59 | kugel | we define VIRTUAL_LED though |
16:09:08 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
16:10:59 | ReKleSS | kind of obscure question... where does the coldfire CRT run? |
16:11:09 | ReKleSS | from the datasheet it looks like the ram starts out unmapped |
16:11:18 | mc2739 | funman: I think the disk activity timer is in ata_sd_as3525.c |
16:12:55 | funman | isn't this led meant to appear in the wps / status bar ? |
16:13:13 | kugel | funman: Any idea why it doesn't reboot? I see a #if 0'd usb acknowledgement in the sd driver |
16:13:25 | funman | looking at it |
16:14:20 | mc2739 | funman: yes, it should be to the right of the time on the status bar |
16:14:42 | funman | mc2739: perhaps the icon is not here in the theme |
16:14:55 | | Quit robin0800 (Read error: 110 (Connection timed out)) |
16:15:20 | mc2739 | the status bar is separate from themes |
16:15:28 | | Quit GodEater ("Terminated with extreme prejudice - dircproxy 1.0.5") |
16:15:39 | | Join GodEater [0] (n=bibble@rockbox/staff/GodEater) |
16:16:05 | mc2739 | besides, I use the same theme on my v1 and v2 |
16:16:11 | funman | kugel: that's it, the code needs to be enabled and include usb.h |
16:16:29 | kugel | awesome |
16:16:44 | funman | mc2739: ok then there is a bug (I only had seen this icon on a samsung YH920, I thought it was ATA-specific) |
16:17:49 | funman | mc2739: what if you cjhange MIN_YIELD_PERIOD to 1 ? |
16:20:06 | mc2739 | funman: I'll test later - leaving for work now |
16:20:54 | CIA-71 | New commit by funman (r21690): Samsa SD driver : acknowledge USB events, now reboots on USB insertion |
16:21:22 | funman | kugel: your forum post has too much [/list] :) |
16:22:13 | | Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
16:23:00 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
16:24:26 | CIA-71 | New commit by funman (r21691): Samsa: fix red for clip/m200v4/c200v2 (typo) |
16:26:42 | kugel | funman: \o/ |
16:27:50 | kugel | hmm, it doesn't work for me |
16:30:30 | | Join GodEater_ [0] (n=bibble@bb-87-80-121-64.ukonline.co.uk) |
16:34:32 | | Quit GodEater (Client Quit) |
16:34:43 | | Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) |
16:34:50 | | Join robin0800 [0] (n=robin080@81.98.157.181) |
16:46:22 | CIA-71 | New commit by kugel (r21692): sAMSa: Turn the backlight off before rebooting to avoid irritating lcd flash. |
16:48:51 | | Quit notlistening (Remote closed the connection) |
16:49:18 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
16:50:58 | | Quit LambdaCalculus37 ("Fwump") |
16:53:10 | *** | Saving seen data "./dancer.seen" |
16:57:31 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
16:58:37 | notlistening | kugel, did i ned to make any other changes for booting from the SD card like a new bootloader? |
16:58:56 | kugel | of course |
16:59:50 | notlistening | ok ;) |
17:00 |
17:00:24 | | Quit kugel (Nick collision from services.) |
17:00:28 | | Join kugel [0] (n=kugel@e178083094.adsl.alicedsl.de) |
17:00:40 | | Quit kugel (Nick collision from services.) |
17:00:48 | | Join kugel [0] (n=kugel@e178083094.adsl.alicedsl.de) |
17:00:56 | | Quit kugel (Nick collision from services.) |
17:01:02 | | Join kugel [0] (n=kugel@e178083094.adsl.alicedsl.de) |
17:01:15 | | Join kugel_ [0] (n=kugel@e178083094.adsl.alicedsl.de) |
17:01:27 | | Quit kugel (Nick collision from services.) |
17:01:31 | | Nick kugel_ is now known as kugel (n=kugel@e178083094.adsl.alicedsl.de) |
17:01:50 | | Quit kugel (Nick collision from services.) |
17:02:03 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
17:06:33 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
17:11:41 | amiconn | ReKleSS: crt0 runs from IRAM. SDRAM does not only start out unmapped, but unconfigured. |
17:12:06 | ReKleSS | ok, thanks |
17:21:13 | | Quit kugel (Read error: 110 (Connection timed out)) |
17:22:58 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
17:34:35 | | Quit ReKleSS ("Leaving") |
17:38:13 | | Quit flux (Remote closed the connection) |
17:44:19 | | Join evilnick [0] (i=0c140464@gateway/web/freenode/x-4c662f274b13591f) |
17:44:52 | mt | linuxstb: change in bin size could be decreased (roughly from 3072 to 2048). But then we wouldn't be able to display debugging info in the sim except for those in RMContext. But I've seen vorbis.c and flac.c don't display as much debugging info so I think this is okay ? |
17:45:56 | funman | you can make debugging info display conditional |
17:46:20 | mt | funaman: Yes but then it will look really ugly. :) |
17:46:24 | mt | *funman |
17:47:16 | funman | why? |
17:47:27 | | Quit Dhraakellian (Read error: 110 (Connection timed out)) |
17:47:35 | funman | we don't need debugging info on target |
17:49:44 | | Join mc2739 [0] (n=mc2739@adsl-69-152-231-53.dsl.snantx.swbell.net) |
17:50:01 | mt | The problem isn't with displaying the debugging info, it's with reading them. Cutting down the number of read()'s that has to be done makes it possible to reduce bin size (and some ram usage too), but will also hide some header parameters. (which aren't used anyway, at least currently) |
17:51:02 | mc2739 | funman: changing MIN_YIELD_PERIOD to 1 did not help with virtual led |
17:51:42 | funman | i have no idea how to use the led now |
17:56:43 | funman | try hacking the statusbar code i think |
17:59:31 | | Join n00b81 [0] (n=taylor@unaffiliated/n00b81) |
18:00 |
18:00:15 | mt | I know I should minimize the bin size change as much as I could, but how much is small enough ? I mean, 2048 is < 0.34% increase ..? |
18:00:36 | funman | it's never small enough ;) |
18:00:47 | mt | :) |
18:02:16 | Mikachu | there are several changes every day, if every is 0.34% it quickly grows :) |
18:02:25 | | Join JdGordon| [0] (i=ae90a306@gateway/web/freenode/x-3878c42a3510838f) |
18:04:20 | mt | yes, but daily changes are not always as big as the addition of a new plugin or a new codec. :) |
18:05:01 | | Quit petur ("work->home") |
18:05:10 | mt | Anyway I'll look into how I could further reduce it .. |
18:05:31 | | Quit thegeek ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
18:06:55 | Torne | mt: you could compare it to the metadata implementation for other codecs |
18:07:05 | Torne | if you compare favourably to them that might be considered reasonable |
18:07:09 | Torne | though obviously smaller is always better |
18:08:02 | funman | that's what she said |
18:08:22 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
18:11:08 | | Join Asa_Thor [0] (n=chatzill@adsl-99-19-49-230.dsl.pltn13.sbcglobal.net) |
18:11:32 | | Quit at0m ("it is now safe to turn of your machine.") |
18:11:54 | | Quit Nico_P () |
18:16:20 | mc2739 | funman: virtual led fix - http://pastie.org/535817 |
18:17:05 | mc2739 | duplicated code from ata-sd-pp.c |
18:17:13 | linuxstb | mt: You could replace those individual reads with a single read, and then just extract the data you need from what you've read. |
18:17:36 | funman | mc2739: if it's duplicated you could put it into the new firmware/driver/sd.c so every sd driver use it |
18:17:52 | funman | PP / Samsa / Ingenic |
18:19:01 | bertrik | I prefer AMS Sansa or Sansa AMS over Samsa |
18:19:10 | funman | sAMSa ? |
18:19:12 | mc2739 | funman: I'll try that now |
18:21:07 | | Quit flydutch ("/* empty */") |
18:27:09 | | Quit robin0800 ("Leaving") |
18:27:25 | mt | linuxstb: I was thinking of replacing the unneeded reads with a single lseek |
18:29:42 | mt | Do you mean for keeping the debugging info for the sim ? |
18:30:54 | Asa_Thor | Hello. I'm looking for a 32gb compact flash card for my iPod. Any recommendations? |
18:31:24 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
18:31:33 | | Quit JdGordon| ("Page closed") |
18:31:38 | linuxstb | mt: Yes, but I was also thinking that before you mentioned that problem. i.e. instead of a sequence of 10 reads of 4 bytes, do a single read of 40 bytes and then extract anything you need from memory. But it probably doesn't make much difference... |
18:31:55 | | Join mc2739_ [0] (n=mc2739@adsl-69-152-231-53.dsl.snantx.swbell.net) |
18:32:17 | | Quit mc2739 (Nick collision from services.) |
18:32:19 | | Nick mc2739_ is now known as mc2739 (n=mc2739@adsl-69-152-231-53.dsl.snantx.swbell.net) |
18:40:52 | | Quit robin0800 ("Leaving") |
18:41:11 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
18:41:21 | funman | mc2739: we could inline led() and not use a custom sd_led() |
18:42:56 | funman | the led icon doesn't look like a led on the fuze ;) |
18:43:04 | | Join lee321987 [0] (n=chatzill@adsl-76-235-49-36.dsl.dytnoh.sbcglobal.net) |
18:43:48 | | Join JdGordon| [0] (n=Miranda@nat/microsoft/x-0684b15fca8cf803) |
18:44:09 | | Part Asa_Thor |
18:45:01 | CIA-71 | New commit by funman (r21693): Sansa AMS: display the virtual led icon on disk transfers ... |
18:45:13 | lee321987 | On Ubuntu "sudo ./e200rpatcher.linux32" gives me, "sudo: /e200rpatcher.linux32: command not found" |
18:45:17 | | Quit stoffel (Read error: 60 (Operation timed out)) |
18:45:51 | | Quit HBK (Read error: 54 (Connection reset by peer)) |
18:45:57 | funman | lee321987: run "file e200rpatcher.linux32" |
18:46:35 | funman | did you run chmod +x e200rpatcher.linux32 ? |
18:46:42 | | Quit funman ("free(random());") |
18:46:54 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
18:46:55 | lee321987 | e200rpatcher.linux32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped |
18:47:59 | lee321987 | I have to build this myself, if I'm on an AMD, right? |
18:48:25 | Torne | no. |
18:48:37 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
18:48:58 | lee321987 | does bootloader.bin need to be in the same folder? |
18:51:35 | lee321987 | http://download.rockbox.org/bootloader/sandisk-sansa/e200r-patcher/ −−−−- what are the files in the folder "0.1"? |
18:52:03 | | Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
18:52:42 | mt | linuxstb: http://www.pastie.org/535860 This is rm.c with sequences of read()'s replaced with 1 lseek |
18:53:14 | *** | Saving seen data "./dancer.seen" |
18:53:16 | mt | there are still unused variables that have to be cleaned. |
18:54:12 | | Join perrikwp1 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
18:55:15 | mt | Before that change, increase in bin size is 3072, now it's 2048. Given that asf.c has an increase of 4096 on bin size, Is this change needed ? |
18:56:35 | | Join sajes [0] (n=sajes@67.143.34.85) |
18:57:05 | domonoky | mt: saving binsize in the core is always good :-) |
18:57:24 | sajes | At this point of the AMS sansa development, would it still be considered a stupid idea to try and install rockbox an e200v2? It didn't say which device was having the corruption issues. |
18:57:39 | sajes | It as in rockbox.org development status. |
18:58:09 | domonoky | sajes: no, take a look at the testing section in the forums :-) |
18:59:01 | domonoky | so its not a stupid idea to try it, but its ofcourse at your own risk :-) |
18:59:41 | | Quit robin0800 ("Leaving") |
19:00 |
19:00:00 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
19:00:10 | sajes | domonoky: You mean the rockbox development section? |
19:00:12 | mt | domonoky: Yes I know, I've been getting that a lot :). It's just that without this change it still has less impact than parsers like mp4 and asf on bin size, and we still get full debugging info in the sim. That's why I'm asking. |
19:00:48 | Mikachu | the goal isn't to make every change as large as the biggest one |
19:00:51 | Torne | ifdef it to be only for the sim |
19:01:01 | Torne | it's not messy to do so, really, it's fairly standard :) |
19:01:53 | bertrik | gevaerts, has someone ever thought about what a 'real' bootloader for the meizus would look like? |
19:01:55 | mt | okay, will give it a shot. |
19:02:00 | | Quit perrikwp (Read error: 110 (Connection timed out)) |
19:02:19 | domonoky | mt: that only means that the parsers for mp4 and asf probably could be improved :-) using a ifdef to enable more debugging info is a good idea. |
19:02:46 | gevaerts | bertrik: I don't think so. Lots of people probably want dual boot, but I don't think anyone has ever looked into that either |
19:03:09 | bertrik | the OF bootloader just seems to extract a RAR image into sdram, the code for that seem quite small (< 0x2000 bytes) |
19:03:34 | bertrik | we could imitate that (and choose between the OF image or the RB bootloader) |
19:03:45 | bertrik | depending on a keypress or something similar |
19:04:45 | gevaerts | ah yes. They use that weird rar format |
19:04:46 | bertrik | we could use something completely different (and possibly faster) than RAR of course, maybe UCL like we do for the ams sansas |
19:05:05 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
19:05:07 | gevaerts | I'm not sure if the m6sl was the same, but we can check that |
19:06:31 | | Quit robin0800 ("Leaving") |
19:06:48 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
19:06:49 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
19:07:51 | | Quit bmbl ("Woah!") |
19:09:19 | bertrik | the meizu has 1MB NOR flash, the compressed OF takes 600 kB, so a RB bootloader should fit easily besides it I think |
19:11:47 | | Part sajes |
19:12:02 | amiconn | mt: As long as your debug output is pure output, just use DEBUGF(). This collapses to nothing on target for non-debug builds |
19:12:53 | | Nick GodEater_ is now known as GodEater (n=bibble@rockbox/staff/GodEater) |
19:13:17 | amiconn | bertrik: So you could probably decompress the OF and have an of.meizu which could be roloed |
19:13:49 | GodEater | gevaerts: I based that forum post off something from Bagder's blog. So it's not all my fault! |
19:13:53 | bertrik | amiconn, yes we can decompress it, not sure was rolo-ing involves |
19:14:06 | bertrik | *what |
19:14:22 | amiconn | Load it from disk, set up the hardware like the OF loader does, then branch to it |
19:14:30 | gevaerts | GodEater: Good idea! We can always blame Bagder! |
19:14:55 | GodEater | :D |
19:15:37 | bertrik | amiconn, so the bootloader would in that case just boot rockbox, right? |
19:16:11 | | Quit AndyI (Read error: 110 (Connection timed out)) |
19:16:44 | amiconn | The bootloader could also offer the choice, loading either ockbox or the OF from disk (or flash, if possible) |
19:17:26 | | Join Dauron [0] (n=DarkAuro@adsl-99-170-79-85.dsl.rcsntx.sbcglobal.net) |
19:17:45 | mt | amiconn : It's not pure output, that's the problem. :) |
19:18:26 | | Quit robin0800 ("Leaving") |
19:18:41 | amiconn | On archos we have dual boot from flash rom, although OF and rockbox don't fit anymore together, so we have bootbox (basically a cut-down rockbox which loads the default on-disk firmware) and rockbox in flash |
19:19:28 | amiconn | Both firmwares can be ucl compressed, in which case they're first decompressed into ram and then executed, or uncompressed, in which case they're executed directly |
19:20:49 | bertrik | ok, thanks for the info. There's quite a few possible ways of booting. |
19:20:56 | amiconn | Bootbox is always compressed to save space. Uncompressed rockbox does only fit on Player and Ondio SP, unfortunately, or if you've upgraded the flash to 512KB |
19:21:33 | bertrik | A nice intermediate step would be to have a dualboot loader that can boot either the OF or the RB bootloader from flash (we can't access NAND yet) |
19:22:09 | amiconn | Running from ROM obviously leaves more free RAM, but is a little slower (ROM data bus is 8 bit but RAM data bus is 16 bit) |
19:22:32 | bertrik | ouch |
19:23:12 | bertrik | I hope the NAND filesystem is simple enough that we can do reads at least |
19:23:24 | amiconn | Nah, it's not that bad. RAM in turn needs two extra states unless the access happens within the current page (fast page mode) |
19:23:25 | | Quit Lynx_ (" Try HydraIRC -> http://www.hydrairc.com <-") |
19:24:42 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
19:24:46 | amiconn | Later targets often have 16 bit ROM data bus, i.e. same bus width as the SDRAM |
19:28:25 | linuxstb | mt: Shouldn't you check the return value from rm_parse_header? |
19:29:23 | linuxstb | mt: Plus also check that the codec type is COOK, and return "false" from get_rm_metadata() if not? |
19:30:53 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
19:31:06 | mcuelenaere | Blue_Dude (logs, if you read them): don't worry about the bloat; I just wasn't sure about those changes and as I'm not familiar with that part of Rockbox I wasn't sure if no behaviour would get changed when it gets committed. If that's the case, I'll commit your patch. |
19:33:02 | | Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
19:33:15 | | Quit perrikwp1 (Read error: 110 (Connection timed out)) |
19:33:18 | | Quit _Auron_ (Read error: 110 (Connection timed out)) |
19:33:18 | | Nick Dauron is now known as _Auron_ (n=DarkAuro@adsl-99-170-79-85.dsl.rcsntx.sbcglobal.net) |
19:38:05 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
19:44:01 | | Quit kugel (Remote closed the connection) |
19:48:06 | * | linuxstb agrees with bertrik about "samsa"... |
19:49:32 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
19:57:17 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
19:57:23 | | Join at0m [0] (n=at0m@94-225-90-23.access.telenet.be) |
19:59:18 | | Quit aaron424 (Remote closed the connection) |
20:00 |
20:00:21 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
20:02:02 | kugel | typos are independent of any agreement :) |
20:04:09 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
20:04:28 | kugel | samsa is perfet |
20:04:41 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
20:04:46 | JdGordon| | samsa soudns retarted :p |
20:04:54 | * | JdGordon| curses his stupid fingers |
20:05:09 | GodEater | JdGordon|: I thought you did it on purpose to be funny |
20:05:24 | JdGordon| | i mean... yes of course :) |
20:05:25 | Dhraakellian | samsa sammich? |
20:06:11 | | Join petur [50] (n=petur@rockbox/developer/petur) |
20:06:40 | kugel | JdGordon: just like sansa does :p |
20:06:44 | linuxstb | kugel: It's a typo? |
20:06:49 | kugel | yes |
20:07:04 | kugel | see r21689 and irc logs around that time |
20:07:07 | linuxstb | kugel: You made the same typo... |
20:07:28 | kugel | well, it was initially a typo |
20:07:32 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
20:08:12 | Mikachu | "samsa" means "get along" in swedish, fwiw |
20:08:31 | * | JdGordon| calls Mikachu a lier! |
20:08:52 | JdGordon| | samsa isnt a derivative of "bork" |
20:09:06 | JdGordon| | ergo its not swedish! |
20:09:16 | Mikachu | lol |
20:10:59 | Dhraakellian | hmm |
20:11:42 | Dhraakellian | when using the new official test builds of rockbox, should I format from the OF first just to be thorough if I've used previous revisions |
20:11:45 | Dhraakellian | ? |
20:11:59 | kugel | wouldn't be the worst thing |
20:12:15 | kugel | but we actually want to get updating to work without reformatting :S |
20:12:24 | Dhraakellian | hehheh |
20:13:01 | Dhraakellian | then again, it's not like I was keeping music on the internal storage |
20:14:08 | | Quit perrikwp (Read error: 110 (Connection timed out)) |
20:17:28 | * | Bagder welcomes committer #76, teru |
20:17:59 | gevaerts | \☺/ |
20:18:45 | * | kugel doesn't how Bagder counts. Are so many duplicates in docs/COMMITTERS? |
20:18:55 | kugel | also: \o/ |
20:18:59 | * | Bagder has so many secrets |
20:19:17 | rasher | kugel: There are a bunch of duplicates I believe |
20:19:35 | Bagder | most importantly, the number 76 is actual svn accounts |
20:19:42 | Bagder | not all were moved from cvs |
20:19:49 | kugel | ahh, that makes more sense |
20:20:05 | Bagder | so we have >76 total committers, but only 76 can commit atm |
20:20:19 | Bagder | "only" ;-) |
20:30:48 | | Quit robin0800 (Remote closed the connection) |
20:31:35 | | Join tessarakt [0] (n=jens@e180079194.adsl.alicedsl.de) |
20:32:22 | * | kugel waits for his first commit... |
20:38:48 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
20:39:56 | | Join Rondom [0] (n=Rondom@dslb-084-057-171-169.pools.arcor-ip.net) |
20:45:06 | | Join t0pGuN [0] (i=266c416d@gateway/web/freenode/x-afd167b6f6928724) |
20:45:09 | t0pGuN | i just downloaded the .zip file to my desktop, unzipped it, then replated my old .rockbox folder to .OLDrockbox and copied over the new .rockbox folder but now my gigabeat is not recognized by the computer :( |
20:45:10 | | Quit Dhraakellian (Read error: 104 (Connection reset by peer)) |
20:46:21 | | Quit notlistening (Remote closed the connection) |
20:47:33 | | Join saratoga [0] (n=9803c6dd@rockbox/developer/saratoga) |
20:47:49 | t0pGuN | someone pleeeese :D |
20:48:00 | pixelma | be patient |
20:48:26 | saratoga | i don't think you even need a .rockbox folder to get USB on the gigabeat |
20:48:31 | saratoga | its got a bootloader USB mode |
20:48:42 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
20:49:01 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
20:49:32 | pixelma | also, could you give a bit more info, e.g. which Gigabeat is this, which OS are you running, what was the build before that (from when) |
20:50:12 | lilltiger | maybe the rockbox version for gigabeat dosent do usb interaction like the sansa ams, so he needs to turn it of or boot into the OF to enable usb transfears |
20:50:19 | t0pGuN | its F10 |
20:50:25 | t0pGuN | Windows XP |
20:50:31 | t0pGuN | it was working 3 mins ago |
20:50:43 | t0pGuN | then i did what i said, and it stopped working |
20:51:28 | t0pGuN | the build before, i dont remeber, but must be at least a year old |
20:53:08 | | Quit Dhraakellian (Read error: 60 (Operation timed out)) |
20:53:16 | *** | Saving seen data "./dancer.seen" |
20:55:53 | | Quit robin0800 ("Leaving") |
20:56:13 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
20:56:59 | | Quit n00b81 ("Leaving") |
20:57:30 | pixelma | can you see the .rockbox folder in Rockbox's file browser itself? (You might have to change the file view settings to "all") I don't know much about Gigabeats and just try to gather as much info so that someone else would be able to help |
20:58:56 | t0pGuN | nice i see both |
20:59:01 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
20:59:02 | t0pGuN | .rockbox and OLD.rockbox |
20:59:50 | | Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) |
21:00 |
21:00:23 | | Quit flydutch ("/* empty */") |
21:01:16 | | Join ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) |
21:01:54 | Unhelpful | saratoga: you really really want to install rockbox proper and use its usb mode, though. bootloader usb doesn't charge. |
21:02:34 | pixelma | Unhelpful: does the F use Rockbox USB? |
21:03:40 | gevaerts | pixelma: no. Hardware |
21:03:55 | aaron424 | I formatted my sansa e280 in rockbox usb mode and it deleted the OF. What can I do to get it back? |
21:04:14 | t0pGuN | mmm can i just rename .rockbox to .temprockbox and rename the OLD.rockbox to .rockbox ? |
21:04:22 | kugel | aaron424: "deleted te OF"? |
21:04:25 | gevaerts | t0pGuN: so, rockbox works, just not usb? |
21:04:34 | t0pGuN | yep |
21:04:45 | kugel | anyway, can you access the recovery mode? |
21:04:56 | aaron424 | Yes |
21:05:11 | aaron424 | should I put the mi4 there? |
21:06:15 | gevaerts | t0pGuN: are you using a dock, or only a cable? |
21:06:16 | Unhelpful | i had thought we were speaking of the beast... does the F/X also have bootloader USB? |
21:06:21 | t0pGuN | just a cable |
21:07:03 | kugel | aaron424: put the Sansa original firmware there, then reinstall rockbox via rbutil |
21:07:42 | gevaerts | what happens when you plug it in? Does it show the USB logo? |
21:08:19 | aaron424 | kugel: thanks |
21:08:44 | kugel | aaron424: You're welcome |
21:09:04 | aaron424 | I needed to upgrade to 3.3 anyway |
21:09:31 | t0pGuN | yea |
21:09:53 | t0pGuN | but then it says USB Device Not Recognized |
21:10:02 | t0pGuN | can i just rename .rockbox to .temprockbox and rename the OLD.rockbox to .rockbox ? |
21:10:30 | t0pGuN | or will i break everything by renaming .rockbox |
21:10:51 | gevaerts | You can do that. Make sure you end up with a .rockbox though |
21:10:53 | aaron424 | kugel: what patches are needed to use most custom themes? |
21:11:01 | kugel | t0pGuN: you could've also just overwrite the old rockbox |
21:11:23 | kugel | aaron424: multifont and customlist |
21:11:27 | t0pGuN | but wont the device stop working at all if i rename the .rockbox? |
21:11:47 | gevaerts | t0pGuN: as long as .rockbox is there when booting, it will work |
21:11:54 | t0pGuN | ah ok |
21:12:14 | gevaerts | Plugins and music playback won't work if .rockbox is not there, but the file browser will |
21:12:18 | | Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
21:12:22 | t0pGuN | ok great |
21:12:24 | t0pGuN | lemme try that |
21:12:54 | aaron424 | kugel: thanks again, ill get those |
21:12:55 | | Join BryanJacobs1 [0] (n=bryanjac@cpe-74-67-191-154.rochester.res.rr.com) |
21:13:04 | pixelma | gevaerts: hmm? rockbox.gigabeat (or so) is in .rockbox, isn't it needed? |
21:13:37 | gevaerts | pixelma: it needs to be loaded, but as soon as it's loaded to RAM, you don't need the actual file on disk |
21:15:07 | t0pGuN | SWEEET :) |
21:15:10 | t0pGuN | it works again |
21:15:15 | t0pGuN | phhheewww |
21:15:16 | t0pGuN | hehehehe |
21:15:33 | t0pGuN | or else 10 gigs of good sorted music would have been lost :) |
21:15:33 | pixelma | would be nice to know why it didn't |
21:16:04 | t0pGuN | i prolly did something wrong |
21:16:40 | t0pGuN | this is what i did -> i downloaded the .zip file to my desktop (for manual installation), unzipped it, then replaced my old .rockbox folder to .OLDrockbox and copied over the new .rockbox folder |
21:17:59 | kugel | that should work actually |
21:20:02 | toffe82 | execpt if the bootloader is too old |
21:20:55 | kugel | there wasn't a new bootloader in ages I think |
21:21:17 | pixelma | toffe82: what does the bootloader have to do with it? |
21:21:39 | t0pGuN | oh hehe |
21:21:43 | t0pGuN | i dunno |
21:21:47 | t0pGuN | but im happy its back to normal :) |
21:22:26 | toffe82 | pixelma: if you put a new version of rockbox and an old bootloader, it doesn't work , no ? |
21:22:51 | gevaerts | t0pGuN: when did you first install rockbox? |
21:23:20 | pixelma | hmm... the only thing I could imagine is if it searches rockbox.gigabeat in the root and not the .rockbox folder (but that change is longer ago, and I would have thought that the problem then would be broken playback etc.) |
21:23:20 | t0pGuN | ive had rockbox running for a few+ years now |
21:23:30 | t0pGuN | but the last install was about a year ago maybe a little more |
21:23:41 | gevaerts | did you update the bootloader then? |
21:23:46 | pixelma | toffe82: depends on how old and what changed... |
21:24:13 | t0pGuN | last time i installed everything, i did a simple update from what i remember |
21:24:30 | gevaerts | pixelma: we had someone here yesterday with a nano and backlight problems that were solved by a new bootloader |
21:24:45 | t0pGuN | i remember the reason why i updated was cuz when you switched songs in the playlists, it would lag between switching |
21:24:49 | t0pGuN | there was a delay |
21:24:55 | t0pGuN | and after the update the delay was gone |
21:26:05 | gevaerts | t0pGuN: can you check the exact size of the GBSYSTEM/FWIMG/FWIMG01.DAT file? |
21:27:09 | t0pGuN | one sec |
21:28:25 | t0pGuN | hrmm the system is lagging, i cant access folders |
21:28:28 | t0pGuN | brb reboot |
21:28:32 | | Quit t0pGuN ("Page closed") |
21:32:32 | | Quit rob (Read error: 110 (Connection timed out)) |
21:35:38 | LambdaCalculus37 | kugel: Building mkamsboot just involves running make from rbutil/mkamsboot, correct? |
21:35:48 | kugel | yea |
21:36:10 | LambdaCalculus37 | kugel: Let me make a disk image of mkamsboot and I'll send it to you. |
21:37:27 | | Join t0pGuN [0] (i=266c416d@gateway/web/freenode/x-749dd66f45bb14bb) |
21:37:35 | t0pGuN | what file was i supposed to look up? |
21:37:52 | gevaerts | GBSYSTEM/FWIMG/FWIMG01.DAT |
21:38:35 | LambdaCalculus37 | kugel: PM me your email address. |
21:38:47 | kugel | LambdaCalculus37: just mail it to bagder |
21:38:52 | LambdaCalculus37 | Okay. |
21:39:03 | | Join funman [0] (n=fun@rockbox/developer/funman) |
21:39:17 | t0pGuN | 50KB |
21:39:19 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
21:39:34 | funman | LambdaCalculus37: can you make an universal binary of mkamsboot? |
21:40:08 | t0pGuN | Size: 49.5KB (50,784 bytes) and Size on disk: 56KB (57,344 bytes) |
21:40:27 | t0pGuN | i can just tell you the version of the rockbox if you want hehe |
21:40:27 | LambdaCalculus37 | funman: They're compiled automatically as universal binaries. |
21:40:29 | gevaerts | t0pGuN: The current bootloader is 53304 bytes, the old one was 50784 bytes. I'd suggest upgrading the bootloader |
21:40:44 | t0pGuN | ah ok |
21:40:48 | t0pGuN | ill do that |
21:40:49 | LambdaCalculus37 | funman: I already found that out when I still had my PPC-based PowerBook. |
21:40:53 | t0pGuN | im backing up the hd |
21:41:27 | LambdaCalculus37 | kugel: And it's off to Bagder's mailbox. |
21:45:03 | kugel | LambdaCalculus37: very nice |
21:46:19 | kugel | I like the way we're installing rockbox. Our bootloader can be damaged as hell without braking dualboot. And due to patching the OF instead of hacking onto the device our installer is nicely plattform independent :) |
21:48:13 | | Quit BryanJacobs1 ("Java user signed off") |
21:49:51 | t0pGuN | are you guys planning on expanding rockbox on the iphone and stuff and making it look super fancy like iphone's OS ? :) |
21:49:52 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
21:50:20 | kugel | No, we aren't planning (generally spoken) |
21:50:42 | t0pGuN | ok i was just curious |
21:53:51 | kugel | funman: someone installed Rockbox on his fuze. It was his first Rockbox installation ever. It seems the installation isn't actually too complicated |
21:54:17 | | Join stoffel [0] (n=quassel@p57B4E41A.dip.t-dialin.net) |
21:54:52 | funman | nice ;) |
21:55:35 | Llorean | What's with all the "samsa" in commit messages? |
21:55:55 | Unhelpful | "look super fancy" is not really a goal of the project. oddly enough, "play music well" comes first. |
21:56:46 | funman | Llorean: check the irc logs |
21:57:13 | Hillshum | Llorean: sAMSa |
21:57:16 | pixelma | Llorean: first a typo and then it became short for "AMS Sansa" |
21:57:38 | kugel | Nice, isn't it? :) |
21:57:38 | gevaerts | Llorean: don't ask... |
21:57:43 | * | Llorean thinks it's pretty horrible. |
21:58:01 | * | gevaerts thinks that commit messages should be clear to people who don't know the current irc fads |
21:58:09 | Llorean | gevaerts: Exactly what I was typing. |
21:58:36 | Llorean | The three or four extra characters for SansaAMS or Sansa AMS isn't going to kill anyone once per commit. |
21:58:38 | ej0rge | or a man who awoke from unsettling dreams to find himself changed into a monsterous vermin |
21:58:46 | Llorean | ej0rge: That's what I thought every time I see it. |
21:59:00 | * | Unhelpful thinks "beast" is wonderful, and we should be using "beaft" and "beaxt" for the other gigabeats. and "beavt" if it's ever supported. :) |
21:59:33 | GodEater | has "beast" actually ever been used in a commit message though ? |
21:59:36 | gevaerts | yes |
21:59:38 | | Quit desowin ("KVIrc Insomnia 4.0.0, revision: 3303, sources date: 20090703, built on: 2009/07/05 07:40:45 UTC 3303 http://www.kvirc.net/") |
21:59:42 | GodEater | oh dear |
21:59:43 | Hillshum | and plain old beat for the T? |
21:59:54 | funman | GodEater: 18 times |
21:59:55 | kugel | no, butt |
22:00 |
22:00:24 | * | GodEater shares llorean's distaste for using silly names for commit messages that only IRC users will understand |
22:00:47 | * | gevaerts thinks that only one of the "beast" commits was reasonable, since it says "beast's (Gigabeat S) manual" |
22:00:55 | funman | the list of changed files makes it pretty clear that it is for as3525 SoC |
22:01:12 | * | Unhelpful also found "beastie" in a commit message, not in reference to gigabeat s |
22:01:12 | kugel | I think I can agree for commits |
22:01:40 | LambdaCalculus37 | Using beast for commits? I have no problems with that. :) |
22:02:18 | * | Llorean thinks all commit messages should be held to approximately the same standards as manual text - be technical but be precise, no "conversational" language. |
22:02:28 | funman | Unhelpful: perhaps "Ladies & Gentlemen : first song played from the beastie boys" ? |
22:03:10 | LambdaCalculus37 | funman: No one's used the Beastie Boys for first song played on any target, AFAIK. |
22:03:39 | * | funman is looking towards playing music in the Clipv2 bootloader |
22:04:37 | Hillshum | funman: in the bootloader? |
22:04:49 | | Part Grahack |
22:04:49 | Unhelpful | funman: not so much, an SPC codec commit message |
22:04:50 | funman | Hillshum: Clipv2 has no storage support yet |
22:04:56 | LambdaCalculus37 | Hillshum: bertrik managed to play the first music on the Meizu M3 that way. |
22:05:07 | | Quit perrikwp (Read error: 110 (Connection timed out)) |
22:06:48 | | Join raphi [0] (n=raphi@pub082136118205.dh-hfc.datazug.ch) |
22:07:40 | t0pGuN | cya all thanks |
22:07:42 | | Part t0pGuN |
22:09:26 | bertrik | markun, have you (or anyone else) ever worked on a link script for a non-bootloader meizu build? |
22:11:38 | | Quit LambdaCalculus37 ("Fwump") |
22:11:54 | Hillshum | Will mkamsboot work on osx? |
22:12:28 | kugel | self compiled, yes it should. And prebuild binaries are coming soon |
22:12:34 | * | JdGordon| very muchly disagrees with Llorean from 10min ago |
22:13:07 | Llorean | JdGordon|: That we should strive for clarity in commit messages? |
22:13:14 | JdGordon| | yes |
22:13:33 | Llorean | They're very much a log, used by people trying to look up information about old changes. Possibly people who weren't even part of the project then. |
22:14:02 | funman | I use logs very often and I think they must be as descriptive as possible |
22:14:17 | rasher | See, this is the same reason I dislike "fix red", "fix yellow" and "oops" |
22:14:20 | funman | and never "fix red" |
22:14:32 | | Join efyx__ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
22:14:32 | rasher | They're useless if you see them more than 15 minutes after the fact |
22:14:33 | JdGordon| | considering how quickly everything changes, the old logs are really no more than a very quick comment on what might have changed.. which is very likely to bnot be relevant anymroe anyway |
22:14:50 | funman | JdGordon|: not when you are looking at all revisions of a file for example |
22:15:02 | JdGordon| | rasher: then look at the actual change... if the comment isnt clear the 2 line change will be |
22:15:02 | kugel | also, it can't work with JdTypo anyway |
22:15:50 | rasher | JdGordon|: Is it so hard to say "move definition of variable foo into the right scope" rather than "fix red"? |
22:16:00 | Llorean | Commits like "S5L8700: implement kernel timer " are useful information though |
22:16:06 | JdGordon| | no, buts its totally pointless |
22:16:15 | gevaerts | JdGordon|: it isn't |
22:16:17 | Llorean | I mean, no matter when later, if someone's curious when it was added that commit makes it clear. |
22:16:31 | pixelma | if I look for a recently introduced bug, I read the commit look to limit the possibilities. A good commit message helps a lot here |
22:16:48 | pixelma | s/look/log |
22:17:02 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
22:17:14 | JdGordon| | sure, but "fix red/yellow" will be clear from the change what it actually means |
22:17:30 | pixelma | it can also help other people to understand why you made a certain change |
22:17:40 | rasher | JdGordon|: It *might* be clear. And it requires extra work when looking back through the log |
22:17:51 | rasher | JdGordon|: It's just laziness. There's really no excuse |
22:17:51 | gevaerts | JdGordon|: fix colour is a bit less strong, but I still like to see some detail |
22:17:58 | | Quit efyx_ (Read error: 110 (Connection timed out)) |
22:18:15 | * | JdGordon| is going to write a 50000 word sermon next time he does a woops commit |
22:18:45 | rasher | JdGordon|: How very reasonable of you |
22:18:45 | JdGordon| | with html to break the web svn reader :) |
22:19:21 | gevaerts | JdGordon|: if it's relevant to the commit, please do |
22:20:12 | funman | yeah long commit logs don't harm |
22:22:30 | | Quit barrywardell (Remote closed the connection) |
22:24:51 | | Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) |
22:25:00 | | Join webguest63 [0] (n=d8870b32@gateway/web/cgi-irc/labb.contactor.se/x-fd8d8a9c0876a707) |
22:27:06 | | Quit webguest63 (Client Quit) |
22:27:36 | Mikachu | JdGordon|: if it was clear what was wrong, why did you make the mistake in the first place? :) |
22:28:13 | * | JdGordon| throws a LED pig a Mikachu |
22:28:30 | Llorean | Mikachu: You say the "JdTypo" comment earlier, didn't you? :-P |
22:28:33 | Hillshum | JdGordon|: *at? |
22:28:37 | Mikachu | yes |
22:29:02 | JdGordon| | blame the seattle "summer".... im fucking freezing here... |
22:29:19 | JdGordon| | .... this is an on topic channel... STFU |
22:29:22 | | Quit jgarvey ("Leaving") |
22:30:07 | | Quit perrikwp (Read error: 60 (Operation timed out)) |
22:30:56 | bertrik | hmm, some of the register names in the drivers from the s3c2440 (gigabeat f) seem be a bit similar to ones for the meizus |
22:31:23 | bertrik | perhaps I could have a saved some time with that knowledge ... :| |
22:33:29 | | Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060308]") |
22:35:46 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
22:37:13 | | Quit Thundercloud (Remote closed the connection) |
22:47:49 | mt | This what I've been able to do so far to decrease bin size and ram usage : http://www.pastie.org/536195 |
22:48:52 | mt | linuxstb ^^^ |
22:49:26 | Mikachu | mt: does initializing skipped to 4 and removing the += 4; in the beginning change anything? :) |
22:49:32 | Mikachu | (probably not) |
22:49:53 | linuxstb | mt: You can just do "if (rm_parse_header(fd, &rmctx, id3) < 0) return false;" - there is no need for an extra variable. |
22:50:11 | linuxstb | (although it probably doesn't make any difference to the generated code) |
22:50:25 | linuxstb | mt: And do you check for codecs other than COOK? |
22:50:38 | Mikachu | i don't think you need 3 unknown variables, just passing the 32 one to everything should work the same |
22:51:32 | | Quit raphi ("leaving...") |
22:51:38 | mt | linuxstb: I check for other codecs yes. in real_read_audio_stream |
22:52:10 | Mikachu | hm, the lines 241-249 look a bit strange |
22:52:22 | Mikachu | first you return if obj.fourcc is a particular thing, and then the same if it isn't something else |
22:52:28 | Mikachu | just the second check should be enough |
22:52:28 | mt | Mikachu: I just did that to use them accroding to the type of the unknown. |
22:52:44 | linuxstb | mt: Maybe it's just my personal taste, but I don't like mixing variable definitions and code - e.g. the start of rm_parse_header() |
22:52:53 | Mikachu | mt: it wastes a little stack space :) you could use a union if you want :) |
22:53:21 | *** | Saving seen data "./dancer.seen" |
22:53:37 | Mikachu | but i guess you could change those to lseek too? |
22:53:53 | mt | Mikachu : I'll just remove all three and lseek instead. |
22:54:07 | linuxstb | mt: Also, should line 124 have a "return -1" ? |
22:54:51 | linuxstb | mt: But do you check the return value of real_read_audio_stream? |
22:55:22 | linuxstb | (I mean real_read_audio_stream_info) |
22:56:43 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
22:57:18 | mt | linuxstb: memset() at the start of rm_parse_header has been pushed down, and added the missing 'return -1'. |
23:00 |
23:00:09 | mt | linuxstb: Added a check for the return value of real_read_*. (oops :/ ) |
23:03:38 | | Quit fyrestorm ("lamers envy me like they envy bill g -- main boot xp, just the way it should be!") |
23:05:10 | | Quit stoffel (Remote closed the connection) |
23:06:56 | linuxstb | mt: I think using sizeof(id3->id3v1buf[0]) (and [1], [2], [3]) would be nicer than using MAX_STRING in lines 304-310 |
23:08:58 | mt | Yep, definitely better, and done. |
23:09:35 | linuxstb | mt: Do you have a new version? I was about to comment on something Mikachu already mentioned... |
23:09:42 | | Join barrywardell [0] (n=barrywar@79.97.85.223) |
23:10:33 | linuxstb | mt: Also, you use "DEBUG_RM" to enable the DEBUGF() lines - shouldn't you use that instead of SIMULATOR? |
23:11:41 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
23:12:55 | mt | linuxstb: Just checked something, return -1 isn't needed at line 124. |
23:13:17 | kugel | JdGordon|: there's a slight bug with the statusbars |
23:13:46 | * | JdGordon| stick fingers in his ears |
23:13:55 | mt | linuxstb: here's the new version but still with the SIMULATOR thing : http://www.pastie.org/536264 |
23:14:31 | Mikachu | JdGordon|: unfortunately this is irc, you'd have to stick the fingers in your eyes :P |
23:14:39 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
23:14:51 | | Quit funman ("free(random());") |
23:15:02 | kugel | JdGordon|: at least on my fuze the first line of the statusbar is cropped in the pitchscreen |
23:15:09 | kugel | on my e200 not it seems |
23:15:24 | kugel | probably wrong math of mine when doing pitchscreen vp work |
23:15:47 | mt | linuxstb: I just used both (debug_rm and simulator) so that it could be build for the simulator with debugf() enabled or disabled. |
23:16:09 | | Quit evilnick ("Page closed") |
23:16:24 | saratoga | the new PP bootloaders seem well recieved |
23:16:29 | saratoga | any idea when we'll release them |
23:16:40 | linuxstb | mt: Do you need bit_rate, sample_rate and duration in rmctx? They're already in the id3 struct that your codec has access to. |
23:16:51 | JdGordon| | kugel: it could be my mistake.... the bar at the bottom looks like its one pixel too high... maybe thats what you're seeing? |
23:17:06 | kugel | JdGordon|: that could cause that, yes |
23:17:36 | linuxstb | mt: And do you need that switch() in copy_metadata()? Won't the codec always be cook if that function has been reached? (and core Rockbox has already set id3->codectype to that value). |
23:18:20 | gevaerts | saratoga: sansa and mr100 are fine I think. I'd just like to see confirmation that the H10 ones work properly |
23:19:30 | kugel | didn't barrywardell own one? |
23:19:34 | linuxstb | mt: And you could just pass the address ofo id3v2buf (cast to "RMContext*") as the second parameter to rm_parse_header() - this avoids the memcpy().... |
23:19:42 | * | linuxstb thinks he should probably stop reading and let mt commit ;) |
23:20:16 | barrywardell | kugel: I did, but the hdd died :( |
23:20:17 | kugel | linuxstb: nah, just two more complaints and it's having more code of yours than from mt :D |
23:20:38 | kugel | barrywardell: unfortunate :( |
23:20:39 | saratoga | does anyone own an H10 these days? |
23:20:44 | gevaerts | kugel: it works on my H10/5 UMS, but there's also MTP and 20GB |
23:20:52 | mt | linuxstb: the variables you mentioned could be written directly to the id3 struct (the it-looks-nicer attitude) .. but this could be changed. |
23:21:58 | mt | linuxstb: the switch is not needed for cook, will remove the 'case cook' part, but later on, this function will be reached even if the codec isn't cook, so the switch will be needed, just not now. :) |
23:23:06 | linuxstb | mt: I would get rid of the copy_metadata() function completely, and put anything you need to do in the main function. You could set id3->title etc at the point where you actually read the title. |
23:23:23 | linuxstb | (you're not copying the tags, just setting pointers to them) |
23:23:40 | Unhelpful | amiconn: text scrolling in PF is either next on my list or next after 16-point ARM IDCT. i got the impression that greylib doesn't know about viewports... is that correct? |
23:23:53 | amiconn | yes |
23:24:16 | amiconn | Viewports came after greylib, and so far there was no need to introduce them there |
23:25:04 | mt | linuxstb: hmm, actually the variables you mentioned are needed in RMContext, since cook_decode_init() needs them. |
23:25:33 | Unhelpful | ok. the text scrolling is going to need some coordinate fixups, then... styled scroll hooks should have access to the viewport, so all should be fine. |
23:25:33 | linuxstb | mt: You could pass cook_decode_init() the id3 struct instead of rmcontext. |
23:26:13 | mt | linuxstb: back to the problem of standalone program vs rockbox :) |
23:26:17 | linuxstb | mt: But I guess you can start ignoring me now, and just commit it as it is... |
23:26:44 | linuxstb | mt: Then get rid of the standalone program - it shouldn't dictate how you write the codec... |
23:26:56 | | Quit bmbl ("Bye!") |
23:27:09 | pixelma | I guess it's not possible to let SVN commit ignore changes in trailing spaces? My editor was so kind as to remove some but there are other white space changes I don't want to have ignored... :\ |
23:28:01 | | Quit perrikwp (Success) |
23:28:03 | mt | linuxstb: I could wait a little longer for the commit, those comments aren't easily received everyday ;) |
23:28:07 | linuxstb | pixelma: You could perhaps create a patch, then manually edit the patch. (then apply that patch to a clean checkout...) |
23:29:12 | pixelma | undoing them one by one is a bit much I guess (too many files touched), looking at one file each they are not too many and understandable in a diff I think |
23:29:21 | mt | linuxstb: I suppose I could do something condtional, the program is compiling fine currently, I don't think I'd throw it away for such probelm. |
23:29:28 | kugel | gevaerts: sansapatcher -bl worked fine here |
23:31:32 | | Join perrikwp [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
23:31:49 | pixelma | I somehow lean towards just committing it still, already put a bit of work in there and I don't think it's too distracting... :/ |
23:33:16 | mt | linuxstb: question ; those 3 variables take up 10 bytes of space, is this worth changing whatever functions that will be changed to cope with that ? |
23:34:03 | * | pixelma now found a setting in the editor at least |
23:34:22 | mt | linuxstb: And I'm really asking for your opinion not to get to commit quicker :) |
23:34:29 | linuxstb | mt: Plus the code to copy them. |
23:34:42 | linuxstb | mt: But I agree, it's not a big deal, just the fact that I don't like to see things duplicated. |
23:36:40 | mt | Since it isn't abig deal, what about writing the values directly to the id3 struct in the parser and then copying those 3 variables back in the codec before calling cook_decode_init() ? |
23:39:13 | | Quit robin0800 ("Leaving") |
23:39:26 | linuxstb | mt: Well, that still duplicates them... I would either leave it as it is, or remove them completely. |
23:39:33 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
23:41:26 | | Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
23:42:53 | | Quit tessarakt ("Client exiting") |
23:45:57 | | Join stripwax5443 [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
23:47:06 | | Quit archstech (Remote closed the connection) |
23:49:23 | | Join archstech [0] (n=archstec@206.251.250.215) |
23:49:59 | | Join brndyhite [0] (n=brndyhit@206.251.250.223) |
23:50:08 | | Join tucsbgns [0] (n=tucsbgns@206.251.250.211) |
23:52:22 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
23:56:11 | | Quit kugel (Remote closed the connection) |