--- Log for 13.06.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 19 hours and 16 minutes ago 00.11.41 # saratoga: the disassemled code for the mpc dct (compiled with eabi) doesn't look too bad. nothing really obvious that could be further optimized (except maybe one or two ldm) 00.12.47 # is it much different then what libmad uses? 00.13.52 # saratoga: no. it is nearly identical. mpc uses a 64-value output (mirroring) of the calculated 32 values 00.14.16 # saratoga: this is to avoid the even/odd handling in the dewindowing 00.15.29 # saratoga: btw, maybe for >ARM4 it might be possible to rearrange ldr/ldm's a bit. in general the code would be hard to maintain... 00.15.36 Join Casainho [0] (~chatzilla@bl17-243-59.dsl.telepac.pt) 00.16.29 # would it be possible to efficiently reorder the coefficients before they get to synth_filter so that more of them could use ldm? 00.16.43 # well i guess that would mostly just help armv4, and thats not much use at this point 00.17.13 # I thought about this and found no solution 00.22.30 # google says mad_bit_read uses a fair amount of time, so maybe thats an option 00.31.44 # funman, I got 10:59:00 runtime on my clipv1 today with a eabi+thumb build, very nearly the same as before 00.39.35 Quit r0b- (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 00.41.34 Quit ender` (Quit: Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert A. Heinlein) 00.55.35 *** Saving seen data "./dancer.seen" 00.56.48 # Zagor (for the logs): Not that it would really matter, but one could maybe suppress or change the "All green" message for the case where a build isn't even started, because only some irrelevant files were changed 01.02.09 Quit bieber (Ping timeout: 260 seconds) 01.02.26 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 01.06.57 Join r0b- [0] (~nnscript@adsl-76-235-208-125.dsl.klmzmi.sbcglobal.net) 01.26.11 Join lev_ [0] (~lev@89.221.199.187) 01.27.38 Join will [0] (~chatzilla@76.235.38.39) 01.28.08 # "(arm-elf-eabi-gcc) is not in your path!" -- is this new? What package do I have to install? (Ubuntu) 01.29.37 # will: launch rockboxdev.sh 01.29.42 # And build eabi 01.30.37 # won't rockboxdev.sh redo the entire installation? Can't I just install one package? 01.31.00 # It isn't a missing package 01.31.15 # I just that the toolchain changed for some target 01.32.05 # thanks 01.34.55 # ./rockboxdev.sh gets me this ---- Please install "makeinfo" and re-run the script. --- I don't see "makeinfo" in synaptic 01.35.14 # will, install texinfo 01.36.41 # ok thanks 01.37.09 # saratoga: Just took a look at mad_bit_read(). It seems like the data buffer is organized in uint-packets. mad_bit_reader() calls betoh32() to resort to little endian each time. This is inefficient. betoh32() needs to be called only once for each new uint-adress. 01.37.23 Join BHSPitLappy [0] (~BHSPitLap@unaffiliated/bhspitmonkey) 01.39.24 # saratoga: We could add two variables: first holds the last uint-buffer index and the second holds the last betoh32'ed value. A similar approach was added to mpc's sv8 bitstream reader to reduce memory accesses to DRAM on Coldfire. 01.40.06 Quit S_a_i_n_t_ (Ping timeout: 240 seconds) 01.40.57 # saratoga: The code would avoid to call betoh32(), if the data of the wanted address has already been converted. 01.41.46 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.190) 01.45.49 Part Jerom 01.49.17 # saratoga: quick-n-dirty approach (not compiled, not tested) -> http://www.pastebin.org/326820 01.49.39 # Buschel: nice! 01.51.08 # maybe you find time for test? I am too tired now and will better go to bed... 01.52.43 # i'm compiling now 01.53.11 Quit domonoky (Ping timeout: 245 seconds) 01.54.06 # Buschel: did this compile for you? 01.55.04 # ah last value shouldn't be a pointer i guess 01.55.54 Quit Buschel (Ping timeout: 265 seconds) 02.02.44 # Buschel: 27.89 MHz on PP5024 w/o COP 02.02.48 # sorry 37.89 02.02.50 Quit lev_ (Ping timeout: 258 seconds) 02.06.18 Quit will (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 02.07.30 # Buschel: 37.60MHz without the patch 02.08.05 # not sure why it got slower, ARM is LE so it should save shifting 02.10.02 Quit BHSPitLappy (Ping timeout: 264 seconds) 02.11.38 # aduio sounds fine though 02.13.44 # anyway i have to go, but my random guess would be some kind of gcc weirdness, since the call to swap32 should be a lot slower then adding a single branch 02.25.07 Quit Casainho (Ping timeout: 260 seconds) 02.27.36 Quit bieber (Ping timeout: 240 seconds) 02.27.53 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 02.43.26 Join masterrogue [0] (8ea6c5b4@gateway/web/freenode/ip.142.166.197.180) 02.44.00 # hi room, i have a question about compatibility with rockbox and my player 02.45.17 # ive got a sansa e260 v2. the site has a link for the installer, but everywhere else it says its not supported. anyone in here get it to work on a v2? i'd really rather not brick my player 02.52.45 # masterrogue: the e260v2 is supported as a stable target 02.53.56 # masterrogue: where does it say it is not supported? (so that we can fix it) 02.55.37 *** Saving seen data "./dancer.seen" 03.05.58 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 03.06.24 # umm, just a second, ill post the link 03.10.19 # http://www.rockbox.org/wiki/SansaC200Port 03.10.52 # first line: " Rockbox doesn't function on the v2 models. The v1 hardware uses firmware named 01.xx.xx, while the v2 hardware uses firmware beginning with 03. This version number can be retrieved under Settings->Info." 03.11.55 # ...woops, as i look at the actual link * facepalm* my bad, ive been looking at the wrong page for months, my bad 03.15.06 Quit GeekShadow (Quit: The cake is a lie !) 03.15.29 # thanks for the help anyway mc 03.16.10 Quit bertrik (Quit: De groeten) 03.17.25 Quit masterrogue (Quit: Page closed) 03.21.35 Quit togetic (Ping timeout: 260 seconds) 03.35.44 Join togetic [0] (~togetic@unaffiliated/ibuffy) 03.38.40 Quit steve|m (Ping timeout: 276 seconds) 03.44.25 Join bba1973 [0] (www-data@giant.haxx.se) 03.45.12 Join hebz0rl_ [0] (~hebz0rl@dslb-088-067-205-060.pools.arcor-ip.net) 03.45.51 Quit bba1973 (Client Quit) 03.45.57 Join krazykit [0] (~kkit@206.183.185.8) 03.46.35 Join moparx [0] (~moparx@unaffiliated/moparx) 03.49.04 Quit hebz0rl (Ping timeout: 276 seconds) 03.52.32 Join steve|m [0] (~steve@p4FD4694F.dip.t-dialin.net) 03.54.05 Quit S_a_i_n_t (Ping timeout: 264 seconds) 03.54.22 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.4.68) 04.19.55 Quit efyx (Remote host closed the connection) 04.25.50 # * JdGordon wonders why his new parse tree walker doesnt hit any TAG elements :( 04.27.15 # New commit by 03jdgordon (r26824): count line numbers correctly, handle the VIEWPORT change so it only ever has one child 04.28.58 # r26824 build result: All green 04.30.49 # bieber: please be awake :D 04.33.06 # JdGordon: skinupdater.exe is still valid/returns valid syntax...right? 04.33.24 # svn will yes 04.34.08 # Hmmmm, I have the sim bitching about lines it *really* shouldn;t be :/ No real time now, I'll get back to you later about it when I've found out more. 04.42.44 Quit pixelma (Disconnected by services) 04.42.45 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.42.49 Quit amiconn (Disconnected by services) 04.42.51 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.43.01 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.43.09 # bieber: I dont know how you've done it, but there seems to be a bug in the parser which is giving TAG elements the vIEWPORT type, and the editor doesnt seem to mind? 04.43.11 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.46.57 # bieber: p *line->children[0]->next->next->next->tag 04.46.57 # $33 = {type = SKIN_TOKEN_DISABLE_THEME, name = 0x403b64 "wd", params = 0x4039f3 ""} 04.46.58 # ^ WTF? that should be a TAG type... (do make in utils/newparser and ./newparser cabbie) 04.49.24 Join Barahir_ [0] (~jonathan@frnk-590f77e6.pool.mediaWays.net) 04.52.42 Quit Barahir (Ping timeout: 245 seconds) 04.55.38 *** Saving seen data "./dancer.seen" 05.02.32 # damn, found the issue... skin_allow_element() doesnt init a value for element->type, and it happens that type == 0 here which is VIEWPORT 05.02.32 Quit krazykit (Read error: Connection reset by peer) 05.02.34 # which is a bug 05.03.06 # curious that it doesnt effect the themeeditor though 05.03.14 Join krazykit [0] (~kkit@206.183.185.8) 05.04.45 Quit moparx (Ping timeout: 240 seconds) 05.13.03 # New commit by 03jdgordon (r26825): initialise the element->type value so TAG types dont accidently get VIEWPORT if it element->type == 0 at alloc time 05.14.36 # r26825 build result: All green 05.18.04 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.45.36 Join brewmster [0] (~brewmr@dsl-149-227.aei.ca) 05.46.27 # can rockbox on Sansa fuze v1 handle a micro SDHC card with an ext3 filesystem on it? 05.46.31 # no 05.46.41 # JdGordon, only vfat? 05.47.07 # correct 05.47.23 # ok thanks 05.47.41 # just installed rb yesterday--pretty cool stuff 05.50.36 # * simonrvn likes rockbox a lot 06.01.07 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 06.02.38 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 06.02.42 Quit elcan (Ping timeout: 240 seconds) 06.03.40 Join elcan [0] (user36@pr0.us) 06.04.32 # JdGordon: Sorry, I'll be back tomorrow night 06.04.32 # Busy weekend 06.04.55 Join JdGordon| [0] (~jonno@123-243-140-31.static.tpgi.com.au) 06.04.55 Quit JdGordon| (Changing host) 06.04.55 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 06.14.37 Quit panni_ (Read error: Connection reset by peer) 06.28.10 Join sawyer7 [0] (~sawyer@ip68-0-192-76.ri.ri.cox.net) 06.36.20 Quit sawyer7 (Quit: Leaving) 06.37.38 Join sawyer7 [0] (~sawyer@ip68-0-192-76.ri.ri.cox.net) 06.40.09 # anyone here ever have any troubles with micro sdhc cards? mine keeps messing up when i try to transfer files to it 06.41.05 # i've had "input / output error" with it twice now 06.41.53 # after the first time, I did a dd if=/dev/zero of=/dev/sde1 to it and then mkfs.vfat to make a new fs 06.42.05 # * S_a_i_n_t assumes this is a rockbox specific problem....? 06.42.09 # ...or hopes so. 06.42.20 # doubtful 06.42.57 # what I mean is, are you asking because you want to use it in rockbox? Being a rockbox dev/support channel and all... 06.43.45 # ah, yes 06.44.03 # i've already tried it in rb 06.44.09 # and it works fine 06.44.56 # then, this isn't the place to ask for support. if it works with RB, that's great, if not working elsewhere...then this isn;t really the right place for support. 06.45.55 Quit sawyer7 (Quit: Leaving) 06.55.39 *** Saving seen data "./dancer.seen" 07.08.36 Join Xerion_ [0] (~xerion@82-170-197-160.ip.telfort.nl) 07.11.18 Quit Xerion (Ping timeout: 265 seconds) 07.11.19 Nick Xerion_ is now known as Xerion (~xerion@82-170-197-160.ip.telfort.nl) 07.27.27 Quit Horscht (Ping timeout: 260 seconds) 07.29.52 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.31.54 Quit brewmster (Quit: Leaving) 07.56.08 Join hamish_ [0] (~hamish@119.224.50.74) 07.56.37 Quit hamish_ (Client Quit) 08.18.25 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.45.46 Quit grndslm (Read error: Connection reset by peer) 08.47.20 Join Buschel [0] (~~andree@p54A3C337.dip.t-dialin.net) 08.47.52 # Buschel: ping 08.49.10 # pong 08.50.00 Part toffe82 08.51.01 # saratoga: I just see my last night's idea makes arm slower? maybe I can find some time today to further look into this... 08.54.09 # ok was just checking if you saw that 08.54.41 # do you have any idea how big the average read is? 08.54.56 # i wonder if the common case takes most of the word, and so the cache does little 08.55.43 *** Saving seen data "./dancer.seen" 09.01.08 # I would expect an average read of (much) smaller than 16 bits. so, it should be more efficient to buffer. I will try to measure this on a small sample file 09.02.30 # I'll be off for a while now. see you latere 09.02.34 # *later 09.04.25 Join dfkt [0] (dfkt@unaffiliated/dfkt) 09.06.52 Quit Buschel (Ping timeout: 248 seconds) 09.21.16 # * JdGordon wonders what the heck to do about all these tags which no longer eat the \n in the skin files 09.21.26 # which will cause problems when we move to the new parser 09.22.24 # http://forums.rockbox.org/index.php?topic=25056.0 09.22.45 Join MethoS- [0] (~clemens@134.102.106.250) 09.25.33 Join stoffel [0] (~quassel@p57B4C30F.dip.t-dialin.net) 09.26.04 # * S_a_i_n_t seems to lean more toward the "Another possible option is if the line has any of a set of tags it will never cause a new line? Then we only need to get the list of such tags (pretty easy to find)..." side of things...maybe. 09.35.38 # yeah, I tihnk i like that one best also 09.36.02 # I have a WPS problem... 09.36.27 # run skinupdater, the sim flakes on every subline. 09.36.38 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 09.37.03 # has the syntax changed for sublines? 09.37.29 # what's wrong with "%t(5.00) %Vd(a)%Vd(b);%t(5.00) %Vd(c)%?mv<%Vd(b)|%Vd(d)>"? 09.37.33 # * S_a_i_n_t sees nothing... 09.38.51 # no thats correct 09.39.08 # what is winging? 09.39.36 # the output doesn;t match...as usual, but only commenting out the sublines fixes it :/ 09.39.49 # shall I pastebinerooney? 09.39.57 # doesnt match what? 09.40.11 # it parses correctly in the editor which means it is correct 09.40.16 # and the tree looks correct 09.40.34 # the sooner I scrap the old code the better /me thinks 09.40.39 # "ERR: Failed parsing on line 72 : ERR: Invalid parameter list for token 11: "volume" " 09.40.47 # I mean, what the hell does that even mean?!? 09.40.59 # btw...it's not even line 72. 09.41.19 # ignore the debug output.. it goes totally mental now :) 09.41.46 # the SIM HATES it, and apparently checkwps does too, as it fails there...well, when rasher tried to update it for me. 09.41.49 # pastebin the whole skin? 09.42.02 # yeppers. one sec. 09.44.56 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.44.58 # http://www.datafilehost.com/download-deb90585.html 09.45.05 # that isnt pastebin! 09.46.06 # I jut wanted to look at the skin in the editor 09.46.36 # yesterday I got all pissy trying to debug it, I attempted to get rasher to replace the zip on the themesite as the script missed it, then I handed him this theme and he said it failed checkwps on line 62, I have no idea if that was .sbs or .wps though. Interestingly, both the sbs and wps gave the same line 62 error in the sim. 09.46.44 # methinks checkwps is broken? 09.46.55 # shouldn't be 09.47.17 # WPS fails 09.47.31 # the sim gave the exact same output he got re: line 62, but for both .sbs and wps 09.47.44 # the sbs does even have code at line 62 IIRC 09.48.10 # yeah, I get the sbs to load *today*, I couldn't on yesterdays sim though. 09.48.43 # the wps is fine if I comment out the sublines around line 60. 09.49.30 # both pass the new parser so meh :) 09.49.42 # AAAArrrgh! 09.49.49 # but it failed checkwps!?! 09.50.09 # yeah, lame aye? 09.50.15 # this also makes the sim essentially useless...so, it;s a little more than "meh" ;) 09.50.31 # well, useless for me :P 09.50.52 # debug output, useless..parsing...useless :P 09.50.55 # the sbs works, it is the wps with the error 09.51.07 # *Ahem* "error" 09.51.39 # I haven't actually tried it on target. I trusted the sim too much. 09.51.50 # but, I also trusted checkwps. 09.52.06 # you really want such a short timeout? 09.52.14 # yep. 09.52.19 # the theme needs it. 09.52.29 # well, as short as it can possibly be. 09.52.34 Join Rob2223 [0] (~Miranda@p4FDCBFB8.dip.t-dialin.net) 09.52.44 # otherwise the animation looks awful. 09.52.44 # i gtg, I'll help you in a couple hours 09.52.51 # no problem. 09.55.38 Quit Rob2222 (Ping timeout: 245 seconds) 10.05.51 Join Buschel [0] (~~andree@p54A3AD43.dip.t-dialin.net) 10.08.16 Join lev_ [0] (~lev@89.221.199.187) 10.10.15 Join ender` [0] (krneki@foo.eternallybored.org) 10.11.52 # JdGordon: You said the theme editor parses the theme correctly? I figured out the problem...but, it means that the skinupdater is broken. And, possibly the theme editor as well. 10.12.00 # Gimme a yell when you get back. 10.12.37 # Actually, not possibly...if it parses it correctly, then it *is* broken. 10.20.18 # saratoga: new libmad patch -> http://www.pastebin.org/327529 10.20.59 # saratoga: the patch contains a small printf-debugging/-measuring and another caching (loading next dword) 10.22.41 # saratoga: on my sample file I get the following results: a=83k, b=2000k, c=900k (hits). that means in total there were 983k calls of betoh32() against 2000k cached accesses or against 2983k betoh() in an unpatched environment. 10.23.07 # saratoga: so, in total the betoh()-calls are reduced to 1/3 10.23.48 # will test on target now 10.27.31 # saratoga: a test on a Coldfire target could be interesting, too. I am not sure whether the bitstream is kept in IRAM or not... 10.33.48 Join showfiles [0] (www-data@giant.haxx.se) 10.34.15 Quit hebz0rl_ (Quit: Ex-Chat) 10.35.14 # General Settings > File View > Show Path > "Off" is this setting supposed to remove the path from all screens ? 10.35.48 # it's suposed to only show the last part of the patch IIUC 10.36.17 # ie. if it was ./rockbox/path/thing it should dhow "thing" 10.36.23 # *show 10.36.43 # well it doesn't show the path when in files, but does show path elsewhere, I thought that "Off" was global 10.37.29 # no diaplay of path anytime 10.37.42 # what screens doesn't it show the path in? 10.37.52 # when in Files 10.37.54 # or...does...rather 10.38.03 # everything except files? 10.38.10 # yes 10.39.18 # Hmmm...actually, what I was thinking of was 'Current Directory Only" 10.40.23 Join Kitr88 [0] (Kitar_st@BSN-210-236-116.dial-up.dsl.siol.net) 10.40.52 # wait...are you considering the "Rockbox" "Settings" etc. as the "Path"? 10.40.56 # the "Off" option doesn't really tie up with what really happens, what does "Off' really mean, current only or global 10.41.06 # it should *only* apply to "Files" 10.41.55 # the title and the path are totally different things...if you're mixing the two up. 10.42.46 # perhpas i am, the directory title, is that = path 10.43.14 # yep. 10.43.20 Quit Kitar|st (Ping timeout: 276 seconds) 10.43.41 # the rest, like when you enter settings and it says "Settings" for example...that's totally different. 10.44.01 # You can only remove that by editing the .sbs 10.44.08 # saratoga: slightly slower with patched version... (37.0 MHz against 37.15 MHz). I am confused 10.44.21 # ok, so is the "Off" option supposed to only remove the directory title from the files directory 10.44.27 # add %?Lt<> to the .sbs, and it will turn those off. 10.44.41 # to your last question, yes. 10.44.53 # thanks 10.45.00 # No problem 10.45.43 Quit showfiles (Quit: CGI:IRC (EOF)) 10.46.27 # can somebody with a Coldfire target please make a short test_codec run with a mp3 file. svn against patch with http://www.pastebin.org/327554 ? 10.49.56 # \o\ |o| /o/ Radio receives a station on my rockboxed clip+ with mystery radio chip :) 10.55.45 *** Saving seen data "./dancer.seen" 10.59.55 Quit MethoS- (Remote host closed the connection) 11.03.51 # S_a_i_n_t: oh? 11.03.53 Join tjytj [0] (~velvetaci@87.252.227.32) 11.04.57 # yeppers...the sim seems to hate %t(x.xx) (it has to be "%t(x.x)" 11.05.30 # and, that'll be where checkwps is failing I assume, but your parser doesn;t seem to mind it. 11.05.43 Part tjytj 11.05.43 # s/your parser/theme editor/ 11.06.12 # it took me *so* looooong to figure that out :/ 11.06.21 # i dunno why x.xx should fail 11.06.40 Join tjytj [0] (~velvetaci@87.252.227.32) 11.06.46 Part tjytj 11.06.47 # I've verified it...that's why the sim is failing. 11.07.10 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 11.07.33 # I can make the whole theme bork just by adding an extra digit after the decimal point on a single subline timeout. 11.08.04 # skinupdater.exe didn;t pick up on it, I assume because it isn;t supposed to not work. 11.10.07 # wierd. i dint see why it should fail 11.10.33 # %t(x.xx) used to be totally valid syntax, and from your reaction I assume it still *should* be? 11.11.10 # damn it took me a long time to figure it out though... :/ 11.11.53 # the (rather comical) debug output from the sim had a slight hand in that though l) 11.12.08 # ok ill look into it later... 11.12.10 # s/l)/:D/ 11.12.47 # sweet, just letting you know I figured it out. Hope I saved you *some* time, though perhaps I just handed you more work... 11.19.09 Join DerPapst [0] (~Alexander@p4FE8EBC3.dip.t-dialin.net) 11.20.51 # Ohh! ohh! JdGordon: One more thing...and alignment tag before %mv(x.x) fails to parse also ie. "%ar%?mv(x.x)"...if *this* is expected or not, I have no idea. 11.21.03 # I seem to remember it working in the past also. 11.31.01 Join Luca_S [0] (www-data@giant.haxx.se) 11.33.31 Join flydutch [0] (~flydutch@host23-166-dynamic.15-87-r.retail.telecomitalia.it) 11.34.27 Quit stripwax (Quit: http://miranda-im.org) 11.37.43 Join halmi [0] (~netbook@80-123-34-112.adsl.highway.telekom.at) 11.39.39 # * Buschel is shaking head about libmad implementation 11.54.46 Join hamish_ [0] (~hamish@119.224.50.74) 11.56.14 Quit hamish_ (Client Quit) 11.57.32 Quit halmi (Read error: Connection reset by peer) 12.00.10 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.00.24 Join halmi [0] (~netbook@80-123-34-112.adsl.highway.telekom.at) 12.03.11 # could someone with Coldfire target please test FS#11398? 12.09.14 Join petur [0] (~petur@rockbox/developer/petur) 12.12.17 Quit Kitr88 (Ping timeout: 258 seconds) 12.15.53 # Hahahah! S_a_i_n_t is on a roll... 12.16.20 # * S_a_i_n_t discovers that even if it's in a theme config, that the SIM won't load a .kbd file. 12.16.43 # and if a .kbd file is loaded manually, that it won;y unload after the sim settings are reset. 12.16.58 # s/won;y/won't/ 12.17.24 # when did the sim get so....for lack of a better word, useless? 12.24.08 # hmmm...if a theme that doesn;t use icons is loaded in the sim, then one that *does* is loaded, the icons won't show either. 12.27.27 # the only thing that seems to get icons displaying after that is "reset settings" :? 12.27.47 # I don't recall it being this broken in the past... 12.37.54 Join Kitar|st [0] (Kitar_st@BSN-182-58-75.dial-up.dsl.siol.net) 12.41.02 # do i understand it correctly that %we enables an .sbs status bar, and %wi enables the default one? 12.42.54 Join Jerom [0] (~Jerom@79.132.53.242) 12.51.33 # dfkt: %we enables *any* status bar, %wd disables it....%wi draws the inbuilt status bar in the "current viewport" 12.53.46 # and, for the record...all status bars are .sbs now. 12.55.48 *** Saving seen data "./dancer.seen" 13.04.10 # thanks, S_a_i_n_t (i also just noticed that classic_statusbar.sbs still uses the old syntax, no wonder i can't load it...) 13.04.28 # it does!?! 13.04.32 # what target...? 13.04.41 # x5, current build, and current simulator 13.05.02 # well, that just simply should't be. 13.05.10 # ah :) 13.05.21 # thanks for sharing that. good to know. 13.06.10 # when you say "current sim", you built it? 13.06.18 # no, i downloaded if from rasher's site 13.06.33 # aha...that's a 3.6 sim. 13.06.42 # none if that will be in current syntax. 13.06.55 # s/current/SVN/ 13.07.14 # well, depending which link you followed, it could even be 3.5 13.07.27 # i upgraded the firmware it runs to r26813 13.07.39 # you can't "upgrade" a sim. 13.07.39 # S_a_i_n_t: Only if he downloaded the 3.6 version. 13.08.11 # S_a_i_n_t: I have both current and release sims 13.08.32 # i didn't download the 3.6 release sim, i downloaded a current revision build 13.09.03 # what does "[23:07] i upgraded the firmware it runs to r26813" mean? 13.09.09 # that kinda threw me. 13.09.19 # **** Target ipodnano2g is using non EABI compiler ! 13.09.20 # why? 13.09.21 # i just checked the system info in the sim, that's what it shows 13.09.33 # maybe i didn't upgrade it then 13.09.47 # mabye that was the downloaded sim revision 13.09.58 # S_a_i_n_t: if you unzip over the sim dir, that's in effect upgrading a sim. 13.10.53 # sweet as, just made me think you'd tried to "upgrade" the sim...which, isn't possible ;) 13.11.39 # rasher: If you write over a sim with another sim...of course. It sounded to me like a target build had been applied to a sim, just checking. 13.13.05 # to clarify/confuse more, this is what i see in classic_statusbar.sbs - http://pastie.org/1002478 13.13.13 # i assume that's old syntax? 13.14.44 # you're correct. 13.15.04 # and, this came with the sim? 13.15.18 # it's also in the current firmware build i just downloaded, not only the sim 13.16.11 # current meaning r26825, directly from build.rockbox.org 13.16.57 # wow...what the hell?!? that *IS* old syntax. 13.17.04 # yet, it runs on device here. 13.17.12 # i'm afraid it's in the clip+ build too... 13.17.36 # I believe you, it's in my nano 1st/2nd gen build also. 13.17.50 # why does it run on device though? 13.19.05 # maybe it uses the old "hardcoded"(?) status bar, not the .sbs? 13.19.20 # %we doesn't show anything on the sim, %wi does 13.19.34 # yet %we works on my real x5 13.19.46 # AFAIK there is no "hardcoded" .sbs anymore. 13.20.26 # that change was made a while ago, that's the reason there's "classic_statusbar" 13.21.21 # No ifs/buts/or maybes...this just simply shouldn't be. 13.21.33 # not only that, it shouldn;t *work* :/ 13.21.48 # heh 13.21.54 # * S_a_i_n_t is more than a little confused. 13.22.19 # JdGordon: ^^ 13.26.37 # I'm trying to se if I'm insane/confused or not...but I can run this old syntaxed classic_statusbar.sbs on sim and on device. 13.29.03 Join TopyMobile [0] (~topy@p5DCC554F.dip.t-dialin.net) 13.32.58 # Hmmm, ok, I am slightly insane I think. Now the SIM *is* rejecting it. 13.34.20 # which is, good? I think there must still be an inbuilt .sbs, but I was under the impression that there was no inbuilt .sbs and that was the reason there was "classic_statusbar" 13.34.48 # Despite that wee messup of mine, it still shouldn;t be in the old syntax. 13.35.10 # i checked, the built in one was in apps/gui/gwps-common.c.. which doesn't exist in current revisions 13.35.34 # that doesn't mean it's not somewhere else though ;) 13.35.37 # heh 13.35.46 # it *has* to be getting it from somewhere...right? 13.37.05 # ah, there's statusbar.c too 13.37.26 # and the sim is now failing on line 7 (which really means line 8), which makes sense...that's the first line of code, in old syntax" 13.44.00 Quit elinenbe (Ping timeout: 272 seconds) 13.46.56 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 13.52.46 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 14.05.30 Join Jaykay [0] (~chatzilla@p5DC570C5.dip.t-dialin.net) 14.07.25 Quit sinthetek (Ping timeout: 260 seconds) 14.15.36 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 14.18.09 Quit bluebroth3r (Ping timeout: 260 seconds) 14.19.44 Join bluebrother [0] (~dom@f053153223.adsl.alicedsl.de) 14.19.44 Quit bluebrother (Changing host) 14.19.44 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 14.21.54 Quit elinenbe (Ping timeout: 245 seconds) 14.23.07 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 14.28.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.29.32 Quit elinenbe (Ping timeout: 258 seconds) 14.36.32 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 14.41.47 Quit elinenbe (Ping timeout: 252 seconds) 14.42.21 Quit Topy44 (Ping timeout: 248 seconds) 14.44.57 Quit stoffel (Remote host closed the connection) 14.45.09 Join Topy44 [0] (~topy@my.fastsh.it) 14.50.35 Quit Buschel (Ping timeout: 252 seconds) 14.50.41 Quit TopyMobile (Quit: TopyMobile) 14.51.15 Quit petur (Quit: Leaving) 14.53.42 Join funman [0] (~fun@rockbox/developer/funman) 14.54.40 Quit Jaykay (Ping timeout: 260 seconds) 14.55.49 *** Saving seen data "./dancer.seen" 15.06.32 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 15.07.06 Quit sinthetek (Client Quit) 15.07.13 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 15.10.19 # S_a_i_n_t: ok back 15.16.15 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 15.16.43 # New commit by 03jdgordon (r26826): update classic_statusbar to the new syntax 15.16.45 Quit Jerom (Remote host closed the connection) 15.18.16 # r26826 build result: All green 15.23.37 # bieber: (thinking loudly so ignore if you are sick of the parser)... in parse_viewport you check to see if the line will have sublines, and then if it does you do the same code to count how many are there. Why not always call parse_subline() (so dont check if it is needed) and then in that if sublines == 1 (so no ;'s) change to the parse_line instead? 15.29.57 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 15.30.54 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.32.43 # The_Seven: someone needs to check if eabi works and commit the changes to configure and the build file 15.32.58 # (re: why no eabi on ipodnano2g) 15.34.42 # https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090531.html [FFmpeg-devel] [CHECKLIST] what is preventing us from switch to git 15.36.05 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.36.34 # http://mailman.videolan.org/pipermail/vlc-devel/2008-February/039627.html [vlc-devel] Switching to git (this thread seems to not contain any flamewar, just technical details on the switch from svn to git) 15.39.25 # for the record I wouldnt really have any problems if every switched to git... the learning curve is annoyingly steep though to get the the point where it actually has a benefit over svn 15.41.01 # kugel: IIRC i confirmed that it worked during the transition 15.45.20 # New commit by 03theseven (r26827): Switch ipodnano2g to eabi in /www/buildserver/builds 15.45.35 Quit elinenbe (Ping timeout: 252 seconds) 15.46.25 # New commit by 03theseven (r26828): SSwitch ipodnano2g to eabi in /trunk/tools/configure 15.46.27 Join voRia [0] (~voria@ppp-45-70.98-62.inwind.it) 15.47.25 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 15.48.03 # r26828 build result: All green 15.49.07 # New commit by 03funman (r26829): Buildserver: build cowond2 with eabi 15.49.12 # New commit by 03funman (r26830): build cowond2 and iaudio7 with EABI, they aren't stable 15.50.09 # * funman looks for b0hoon 15.50.42 # amiconn: did you test all the ipods still building with gcc 4.0.3 ? what's the problem with them, stack overflow iirc ? 15.50.51 # r26830 build result: 0 errors, 2 warnings (funman) 15.50.59 # \o/ 15.54.02 # not sure what i should do here: make the code do what the comment says, at the risk of breaking cowond2 lcd ? 15.54.36 # New commit by 03jdgordon (r26831): get the renderer working more better! "handle" sublines correctly, dont "draw" in the first viewport if we are using viewports, get rid of the idea of ... 15.54.56 Quit elinenbe (Ping timeout: 265 seconds) 15.55.30 Quit ender` (Quit: I like work: it fascinates me. I can sit and look at it for hours. -- Jerome K. Jerome) 15.56.06 # r26831 build result: 0 errors, 2 warnings (jdgordon) 15.56.13 # JdGordon: how many parsers do we need? 15.56.18 # JdGordon: fix your yellow! 15.56.19 # 6! 15.56.25 # haha 15.57.00 # JdGordon: what is newparser for? I thought the theme editor's parser was the way to go? 15.57.23 # kugel: the way it works is text -> new parser -> awesome text target independant parse tree -> middle ground to make it target specific and build "tokens" which are useful -> renderer 15.57.28 # OH, no thats just my playground 15.57.34 # git is too hard :p 15.57.48 # bassically I'm building the new renderer outside of the core to make sure it works 15.57.56 # once it is mostly done it will be copied in 15.58.12 # this is to replace skin_parser.c and skin_display.c and the .h's 15.58.59 # so the themeeditor's parser won't be used? 15.59.05 # it will be 15.59.09 # I am using it directly 15.59.32 # the code in that folder is after it goes through the parser 16.00.07 # it would be pretty slly if we wernt using the new parser :p 16.00.23 # oh ok 16.00.32 # New commit by 03funman (r26832): cowond2: make the code consistent with the comments and really clear the bits ... 16.00.56 # JdGordon: "dont "draw" in the first viewport if we are using viewports" isn't this allowed currently (except for sbs)? 16.01.09 # no 16.01.17 # this is explicitly not allowed 16.01.33 # we go through the viewport but not draw anything 16.01.57 # Bagder: Have a Mydoom worm? 16.02.04 # * kugel misremembers then 16.02.10 # r26832 build result: All green 16.02.12 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 16.03.14 # kugel: maybe misunderstood... if any viewports are defined then the default viewport isnt drawn 16.03.46 # yea, in my memory it was drawn in the wps but not in the sbs 16.04.48 # ah, the default vp in the sbs gets the VP_NEVER_VISIBLE flag, in the wps this doesn't happen 16.05.48 # * kugel now thinks he remembers correctly 16.06.15 # hows RaaA giong? still going th android route? 16.06.51 # quick topic change? 16.07.23 # it's going good I think, although I'm busy with uni-work currently. yes, android is planned 16.10.53 Quit elinenbe (Ping timeout: 252 seconds) 16.13.38 # bertrik: can you test http://www.rockbox.org/tracker/task/11330?string=clip on your clipv1 ? 16.22.25 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 16.25.08 # is it better to case a void* to a intptr_t and use it as an int? or alloc a int and store the pointer there? 16.25.08 Quit halmi (Read error: Connection reset by peer) 16.25.46 # cast 16.26.03 # int could be too small to hold a pointer, but not intptr_t 16.26.48 Join halmi [0] (~netbook@80-123-33-117.adsl.highway.telekom.at) 16.26.58 # the struct member is a void* 16.27.09 # I just need to store some flags there 16.28.04 # flags in a pointer ? Oo 16.28.29 # void* data;... most types store a struct * there, I only need an int here 16.28.31 # for this one 16.28.52 # what about using an union? 16.29.30 # meh, I'll just do it safewly and add a struct, saves doing &'s later also 16.33.26 # I'd use a union too 16.37.15 Quit elinenbe (Ping timeout: 264 seconds) 16.40.14 # * JdGordon has line eating tags working :) 16.40.29 Quit GeekShadow (Read error: Connection reset by peer) 16.41.05 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 16.42.11 # New commit by 03jdgordon (r26833): Start dealing with LINE elements... setup a flag which lets tags tell the renderer to not start a new line in the viewport (i.e %we/d/i %X/x/xd etc) 16.42.49 # New commit by 03jdgordon (r26834): duh, this is needed also 16.43.58 # r26833 build result: All green 16.45.31 # r26834 build result: All green 16.48.14 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.49.21 Quit perrikwp (Quit: CGI:IRC (Ping timeout)) 16.49.27 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 16.52.16 Quit elinenbe (Read error: No route to host) 16.54.46 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 16.55.52 *** Saving seen data "./dancer.seen" 16.59.09 # funman, I'll have a look, anything specific I should look at? 16.59.28 # bertrik: nope, i just wanted to know if it has a real effect on battery life 17.00.21 Quit elinenbe (Ping timeout: 276 seconds) 17.00.32 # ok, I think I'll start a battery bench tonight and let you know tomorrow 17.01.37 # by the way, the clipv1 battery benchmark I did after the recent eabi + thumb changes showed no significant difference (about 1 min in 11 hours) 17.02.21 # yeah i've seen that, perhaps memory use doesn't affect battery a lot 17.02.26 # quite remarkable actually that they got so close 17.02.43 # codec speed is almost the same for thumb & arm 17.03.56 # I have basic tuning working now for my clip+ 17.04.27 # The_Seven: as if those mails come from me... 17.05.33 # The_Seven: why not make the commit then? 17.05.42 # kugel: I've already done that 17.06.24 # * The_Seven still wonders where they could come from, especially how that friggin' worm could have found out about the list 17.06.34 # The_Seven: oh, overlooked that 17.11.08 # mails and worms do that all the time, I've stopped wondering. I see my email used like that every day 17.13.39 # * kugel wonders what this worm talk is about 17.14.45 # a mail that was sent with my From: adress to rockbox-dev 17.14.58 # it included an .exe 17.15.12 # infected with a worm 17.15.50 # oh, I didn't get that mail, only Mosner's reply 17.16.11 # yeah, I had the same experience 17.17.31 # but the mail archive shows it 17.18.41 # I didn't get it either. I assume a lot of us have filters that just snagged it for us. 17.20.47 Quit halmi (Quit: halmi) 17.32.14 # yep, i saw my filter snag it 17.32.32 # however, i couldn't see it on the archive, it was probably already removed by some admin 17.32.35 Quit funman (Quit: free(random());) 17.32.42 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 17.33.28 # http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-06/0089.shtml 17.34.00 # I've however replaced the attachment so it isn't spreading more 17.34.09 # * Bagder runs off 17.36.52 Quit elinenbe (Ping timeout: 240 seconds) 17.38.42 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 17.40.47 Join elinenbe_ [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 17.43.09 Quit elinenbe (Ping timeout: 248 seconds) 17.45.25 Quit elinenbe_ (Ping timeout: 258 seconds) 17.48.29 Quit storm` (Ping timeout: 258 seconds) 17.51.30 Join storm` [0] (~lol@ip98-179-182-180.ri.ri.cox.net) 17.52.13 Join kugel_ [0] (~kugel@e178063187.adsl.alicedsl.de) 17.52.21 Quit kugel (Ping timeout: 260 seconds) 17.52.23 Nick kugel_ is now known as kugel (~kugel@e178063187.adsl.alicedsl.de) 17.52.37 Quit kugel (Changing host) 17.52.37 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.53.09 Quit r0b- (Read error: Connection reset by peer) 18.13.29 Join Buschel [0] (~~andree@p54A3F84F.dip.t-dialin.net) 18.14.06 # * Buschel again waves to Coldfire testers 18.14.16 Join Photoguy [0] (~chatzilla@97.73.159.241) 18.19.37 # Does anybody know if it's possible to get a d2+ replacement touchscreen? 18.28.59 Quit Photoguy (Read error: Connection reset by peer) 18.36.09 Join ender` [0] (krneki@foo.eternallybored.org) 18.47.28 Join domonoky1 [0] (~Domonoky@agsb-d9bd94f7.pool.mediaWays.net) 18.47.52 Quit domonoky (Ping timeout: 240 seconds) 18.48.02 Join webguest30 [0] (www-data@giant.haxx.se) 18.48.09 # Hello lifesavers 18.48.14 Nick webguest30 is now known as m0ar (www-data@giant.haxx.se) 18.48.35 # Is there an ETA of rockbox 3.6 -> clip+ ? 18.48.37 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 18.48.44 Nick m0ar is now known as Guest79727 (www-data@giant.haxx.se) 18.48.48 # 3.6 has been released for all the targets it is going to be 18.48.53 # Dang 18.49.05 # If the clip+ is deemed stable at the time it will be in 3.7 18.49.19 # But only if it meets the stable requirements 18.49.55 # Ah 18.50.07 # What problems exists with the current version? 18.50.40 # I don't know 18.50.58 # Is there a wikipage or sumthing? 18.51.12 # There are a couple, but they don't seem too helpful 18.51.18 # They are linked fro; the front page 18.51.34 # Among other things, the Clip+ doesn't yet play files back at the right speed yet. 18.51.43 # There's just still hardware that isn't working right and so on. 18.52.13 # Guest79727: http://www.rockbox.org/wiki/SansaAMS#Specific_problems 18.52.42 # Thanks 18.52.52 Quit elinenbe (Ping timeout: 240 seconds) 18.54.53 # What might be the reason to the clip having such an odd problems as a 1.1% slowdown? 18.55.02 # See the bug report linked 18.55.06 # It explains it 18.55.50 # Trying to understand already 18.55.55 *** Saving seen data "./dancer.seen" 18.56.45 # The bug report comment explanation is pretty straightforward, if you don't get it there's probably not much that can be done to help. 18.57.10 # Well I get it technically, but I'm still unsure of what may cause such a problem 18.57.17 # But thanks for the chitchat guys 18.57.20 Quit Guest79727 (Quit: CGI:IRC) 18.57.27 Join funman [0] (~fun@rockbox/developer/funman) 18.57.34 # what do i have to do to get an .sbs loaded into my theme? i added a "sbs: /.rockbox/wps/classic_statusbar.sbs" line to my theme .cfg, and enabled the status bar by either %we or %wi... but that's obviously not all 18.58.19 # Llorean: the fact that samplerate isn't 100% accurate isn't a bug per se. Having a higher precision is merely an enhancement, not a bugfix 18.58.56 # funman: It's a bug if files are playing measurably too slow, isn't it? 18.59.04 # no 18.59.11 Join stoffel [0] (~quassel@p57B4D254.dip.t-dialin.net) 18.59.13 # hardware limitation 18.59.19 # What would you call it if a file that's supposed to be 4 hours long completes in 3 hrs 50 minutes? 18.59.35 # funman: So it's impossible to fix? 18.59.52 # i would tell the difference is below the human ear precision, so it's ok 18.59.57 # The OF (while not being perfect) is quite a bit better IIRC 19.00.01 # it's possible to have more precision 19.00.12 # yeah bertrik suggested that the OF resamples everything to 48kHz 19.00.52 # funman: Feel free to close the bug report as "not a bug" then. 19.01.07 # I always find it odd that hardware made for playing audio has such stupid limitations 19.02.24 # well i believe having a clock freq which is an integer multiple of every samplerate in existence is hard 19.02.42 # true, but 44.1 seems a fairly obvious one 19.02.46 # Yeah, but when CDs are 44.1... 19.05.15 # AlexP: But if I recall Sandisks' response was more or less "Well, you wanted a cheap player, and cheap means not everything can be perfect" 19.05.27 Join r0b- [0] (~nnscript@adsl-99-156-28-54.dsl.klmzmi.sbcglobal.net) 19.05.48 # funman: could we do that as well? 19.05.56 # Yeah, and if it is small enough to not be noticeable, then never mind, but still seems slightly silly :) 19.06.06 # kugel: resample? 19.06.10 # yes 19.06.11 # AlexP: Well, people *heard* it and complained to Sandisk that it didn't sound quite right originally. 19.06.17 # So some people can hear it, at least. 19.06.24 # sure but i don't think you can resample without quality loss 19.06.27 # ah, didn't know that 19.06.37 # funman: Especially not with our resampler 19.06.49 # I think dismissing it as "not a bug" isn't something that should happen. It should, more likely, be resigned as a "known issue" if we can't figure out how to fix it. 19.06.56 # perhaps 22.05 -> 44.1 would be doable (just duplicate every sample) 19.07.20 # that was one of the biggest complaints with a whole generation of marketed as 'high quality' sound blaster cards - people complained about them resampling everything to 48khz and audibly making the sound worse... 19.07.26 # I'd think that resampling upwards shouldn't affect quality 19.08.29 # what does the pitchscreen do? I once set it to 101.2% and couldn't hear a change in quality (but I found the speed difference noticeable) 19.10.16 # i think it calls dsp_upsample / dsp_downsample 19.10.37 # Llorean: well i closed it as notabug with an explanation 19.11.29 # any idea how duplicating a sample once in a while would affect sq (negatively)? 19.12.02 # well you're just outputting a different sound 19.13.59 # dfkt: The problemwith the sound blaster emu chip is that it does hw resampling for lots of channels and they had to cut corners so the resampler isn't quite that good. 19.14.19 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 19.14.29 # And doing high quality resampling in software would probably mean less runtime for rockbox... 19.15.09 # what's the samplerate precision of other rockbox targets (not the AMS) ? 19.15.25 # iirc, one can find out if a resample does its job well with a simple sine sweep 19.15.32 Quit stoffel (Ping timeout: 265 seconds) 19.20.53 Quit lev_ (Ping timeout: 258 seconds) 19.29.09 # about svn properties i'll wait a bit and propose change of the conventions: 19.29.31 # - make Id keyword optional (not mention it on the wiki) 19.29.46 # - make eol-style optional as well (and mention that text files should have unix line endings) 19.30.10 # - give image files their correct mime type (not octet-stream) 19.31.46 # hm well nobody (but gevaerts on irc) said Id was useful so I'll propose to remove it completely 19.32.51 Join hebz0rl [0] (~hebz0rl@dslb-088-067-205-060.pools.arcor-ip.net) 19.34.02 # funman: For Id I'd rather have it one way or the other - use it everywhere or not at all, rather than a mishmash on files 19.34.26 # Personally, I don't really care if it is used or not :) 19.34.45 # Wait, I don't see the problem really, just seems to be that some people can't or won't want to use subversion and try to find reasons to use git instead, which is IMO a separate discussion 19.35.00 # bertrik: then you didn't read the thread 19.35.28 # really it's not about "some" people using git-svn and not svn 19.35.35 # bertrik: There are two discussions IMO - one is whether guidelines should be followed (yes, absolutely IMO), and the second is what those guidelines should be 19.36.15 # If the guidelines are there, then they should be followed regardless on whether some people don't want to, whether through thinking them pointless, or choice, of tools, or whatever 19.36.34 # However, what the guidelines actually are can be changed of course :) 19.37.06 # So, we're discussing now a change in the subversion guidelines here, right? 19.37.18 # yeah 19.37.18 # I think so :) 19.37.55 Quit kugel (Remote host closed the connection) 19.38.15 # I wait a bit to see if more people have something to say about these properties and i'll send an email about removal of some of these properties 19.41.00 # Change 3) looks fine to me, 1) I find very reasonable, but I wonder if change 2) might give problems for people still using windows 19.41.53 # 1) Just bin them, not have a half-way house, 2) no idea) 3) sure :) 19.42.39 # on windows we still use unix tools which expect unix line endings 19.43.27 # and the plan is for new files, unless someone wants to go through all existing files and remove properties 19.43.44 Join saratoga_ [0] (463f90ed@gateway/web/freenode/ip.70.63.144.237) 19.44.25 # why is likely the OF resamples? Couldn't they just use a different PLL clock? 19.44.52 # People on a cygwin setup might still want to edit files with a windows text editor, although that's probably a rather small percentage of people compiling rockbox 19.46.04 # Buschel: isn't Coldfire BE? so this would probably be slower since you have the overhead from the branch 19.47.04 # saratoga: the access to DRAM is much more expensive than the branching (from what I experienced so far) 19.48.00 # saratoga: I am wondering why the patch is slightly smaller on arm7tdmi -- which is LE 19.48.11 Quit kramer3d (Read error: Connection reset by peer) 19.48.15 # saratoga_: there's only 2 PLL settings (that i've seen) in the OF : 160 & 240MHz 19.48.39 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 19.48.56 # bertrik: windows text editors handle unix line endings (just not the original notepad.exe, at least not on XP) 19.52.02 # its possible to test for resampling by playing a tone really to 22khz and recording it (ideally at 48khz) and seeing if it comes out at some other frequency 19.52.11 Part ocin 19.52.26 # but dfkt's rmaa results don't look like resampling 19.52.35 # at least not very fast resampling 19.52.50 # saratoga, AFAIK the resampling option is just a guess now and is not really supported by experiments yet 19.53.22 # the frequency response looks identical to RB even out to 22khz, which would require a very good resampler and a lot of CPU time 19.57.09 # ranma: what's left for AMSv1 usb driver ? 19.57.22 # i just see a TODO: switch max packet size depending on speed 19.59.50 # JdGordon: Makes sense, I'll take a look at it 19.59.51 # Shouldn't be a hard change to make 20.00.06 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 20.01.11 # Hi. Been gone a week, and now I don't have the right toolchain anymore. How do I get eabi on Cygwin? 20.01.28 # echo e|./tools/rockboxdev.sh 20.01.58 # you'll probably need to install some other packages too since i don't think we ship cygwin with all the dependencies 20.02.29 # tbbppppbpbp. 20.02.36 # k 20.02.40 # that'd be texinfo 20.02.54 # why is that needed anyway? 20.03.24 # texinfo appears to be installed already. 20.04.36 # "echo e|./tools/rockboxdev.sh" ? Is that all? 20.05.01 # What does the "echo e|" do for me? 20.05.58 # Never mind, figured it out. 20.06.52 # saratoga_: some docs which can't be disabled without tweaking makefile i think 20.07.14 # ROCKBOXDEV: Please install curl or wget and re-run the script 20.10.21 # hm the SD change seems to get 1h30 of battery on fuzev2 (now 21h) 20.10.42 # i started benchmark on clipv2/clip+ today 20.10.54 # which changes? 20.11.23 # disable the 4 clocks in sd_enable 20.11.56 # http://pastie.org/1002863 20.12.54 # ah thought you meant this was already committed 20.13.14 # i'll make sure to run test_codec before committing (because that kind of change broke on AMSv1) 20.13.46 Quit Buschel (Ping timeout: 260 seconds) 20.13.52 Join Luca_S [0] (www-data@giant.haxx.se) 20.16.01 # Holy crap! That script is... busy... 20.16.16 # s/codec/disk/ 20.17.13 Quit scorche (Ping timeout: 264 seconds) 20.22.06 # Hello! Is frequency switching still unstable on fuzev2? I just completed an entire battery cycle without crashes (not a bench, just a few days of casual listening) in my custom build that includes the latest patch on the tracker 20.23.25 # Luca_S: i don't remember how it crashed on fuzev2 20.23.39 # But i just remember that with svn the battery life should be ~14h30, not ~19h30 20.23.49 # so with the SD patch, 14h30 -> 21h is quite awesome 20.24.10 # wow, indeed 20.24.34 # Luca_S: you have made a bench of unpatched SVN recently? 20.24.59 # in the early days of the port it simply froze, no panic message and no reactions to button presses 20.26.09 # and it happened randomly but usually once in half an hour 20.26.15 # Luca_S: reading FS#11297 again, I think it didn't crash on fuzev2, but I didn't want to enable it because the same settings crashed on clips 20.27.36 Join scorche [0] (~scorche@rockbox/administrator/scorche) 20.28.06 Quit bieber (Ping timeout: 272 seconds) 20.28.21 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 20.28.28 # couldn't it be selectively committed? I'm asking since I'm unable to create a recent custom build, still can't build the eabi toolchain with the vmware image :( 20.28.54 # selectively? 20.29.14 Join petur [0] (~petur@rockbox/developer/petur) 20.29.53 # i.e. enabled only on fuzev2 20.30.11 # sure it could 20.31.57 Quit storm` () 20.35.00 Quit Luca_S (Quit: CGI:IRC (Ping timeout)) 20.37.41 Join Luca_S [0] (www-data@giant.haxx.se) 20.41.09 # ahh, damn cgi, I couldn't read your replies :D 20.41.37 # funman Luca_S: you have made a bench of unpatched SVN recently? << no, but I could start it now if you need it 20.41.46 # http://img444.imageshack.us/img444/8675/fuzev2.png <- 14hours is probably for old builds 20.42.34 # Luca_S: yeah please, i want to measure how http://pastie.org/1002863 affects battery life 20.42.54 # ok, just plain latest svn then 20.43.16 # I think the Cygwin config wiki needs updating in regards to required install packages. In addition to the listed packages, we need python, curl, and so far, libiconv... 20.44.54 # Blue_Dude: something else than thumb_cc.py needs python? 20.45.05 # Also, the dev script terminated with an error because I didn't have libiconv. Now I can't rerun, because build-binutils already exists. Is there a workaround? 20.45.21 # funman: analysis tools need it. 20.45.30 # Not required I suppose, but useful. 20.45.47 # Blue_Dude: if binutils is installed you can comment the "build ...." line for it in rockboxdev.sh; else just remove the folder to start building it agfain 20.45.50 # again* 20.46.07 # I was afraid of that. 20.46.13 # I'll start over. 20.46.19 # can you run arm-elf-eabi-as ? 20.47.17 Quit Luca_S (Quit: CGI:IRC) 20.47.26 Join Luca_S [0] (www-data@giant.haxx.se) 20.47.45 # I already started over... 20.48.09 # Takes a long whole to run. I hope I have all the dependencies I need this time. 20.48.13 # *while 20.48.30 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 20.49.37 # I'm so dumping Cygwin in a few weeks. Is there any particular flavor of Linux that works well with the Rockbox dev tools? What would you install if starting from scratch? 20.50.52 # any really 20.51.10 # There are people using debian, ubuntu, fedora, arch, .... 20.51.19 # Probably a convo for community :) 20.55.23 # battery bench started, default settings, mp3 mixed bitrates, volume 0db 20.55.35 # Blue_Dude: Just about any distro with a package manager should have all the crap you need in its repositories. I've always found Ubuntu the easiest to set up and use, but anything you can get running on your machine should work fine 20.55.58 *** Saving seen data "./dancer.seen" 20.55.58 # Yeah, let's not start a distro war in here - any will do it :) 20.56.35 # I moved the question to the other forum... 20.58.06 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.00.19 Quit Luca_S (Quit: CGI:IRC) 21.00.26 Join Luca_S [0] (www-data@giant.haxx.se) 21.04.18 # did anybody notice that in recentish svn for fuzev2 any time OF boots after a RB session it triggers OF's 'rebuilding database'? 21.04.48 # yes, look on flyspray 21.07.11 # funman: PP5002 sees immediate stkov panic on COP 21.07.25 # But increasing that stack (the idle stack) doesn't help 21.07.30 # all the ipods listed in configure are PP5002 ? 21.07.36 # So something else is wrong 21.08.20 # nope 21.08.21 # did you try printing the stack pointer in the panic message to check it was really overflowing ? 21.08.25 # 1g2g and 3g are 21.08.35 # The others are just untested 21.08.46 # domonoky1: Could you please test 4g? 21.10.30 # * amiconn suspects that something in thread.c is going wrong 21.12.54 # try changing C/ASM code line 298 of thread-pp.c ? 21.13.08 # (just throwing the idea) 21.21.23 Quit flydutch (Quit: /* empty */) 21.22.20 Quit funman (Quit: free(random());) 21.46.08 Join lev_ [0] (~lev@89.221.199.187) 21.58.26 Quit saratoga_ (Quit: Page closed) 21.59.50 Quit shai (Ping timeout: 245 seconds) 22.01.42 Join MethoS- [0] (~clemens@134.102.106.250) 22.03.03 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 22.10.36 # *Still building* eabi tools in Cygwin... 22.11.37 # And here I was thinking only a few minutes. 22.12.51 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.13.56 Join m0ar [0] (www-data@giant.haxx.se) 22.14.00 # Hello 22.14.41 # When trying to set the YellowBarDynamic WPS I just get reverted back to the original theme, any ideas? 22.15.15 # m0ar: which version of Rockbox are you using? 22.15.41 # mc2739: Todays 22.15.51 # Just upgraded, thought it might have been that 22.16.40 # Same thing with dfkt minimum clip 22.16.43 # So that's wierd 22.17.39 # the syntax for the theme files was changed after Rockbox 3.6 was released. You need to download a new version of the theme from the theme site. 22.17.53 # Just did 22.17.57 # Oh 22.18.04 # The RBU isn't using the new files? :) 22.18.29 # not unless you have a recent svn build 22.18.38 # Then there's the problem 22.18.45 # Thanks a bunch 22.18.55 # Time to update the RBU then? 22.19.03 # it is in the works 22.19.14 # Wonders 22.19.25 # * m0ar sends some e-love to all the devs of RB 22.20.01 # in the meantime, go to http://themes.rockbox.org/ and download an updated theme and unzip it to your device 22.20.43 # Yeah, already on it 22.22.35 # Running svn-stuff in windows, which I barely visits, isn't worth it 22.22.59 # And I spilled a glass of water in my linuxlaptop last night, so now I'm stuck hehe 22.23.33 # Now the themes works just fine, thanks dude 22.24.30 # you're welcome, FYI, you can find a link to recent Rockbox Utility builds here: http://forums.rockbox.org/index.php?topic=23544.0 22.27.05 # Not a nessicity, thanks anyways 22.28.05 Quit m0ar (Quit: CGI:IRC) 22.41.31 Quit petur (Quit: Zzzzz) 22.48.22 Quit stripwax (Quit: http://miranda-im.org) 22.56.00 *** Saving seen data "./dancer.seen" 23.02.11 Join ender1 [0] (krneki@foo.eternallybored.org) 23.05.12 Quit grndslm (Read error: Connection reset by peer) 23.05.31 Quit ender` (Ping timeout: 258 seconds) 23.06.16 Join Buschel [0] (~~andree@p54A3B69A.dip.t-dialin.net) 23.10.55 Quit Luca_S (Quit: CGI:IRC (EOF)) 23.14.17 Quit The_Seven (Remote host closed the connection) 23.17.26 Quit Buschel (Ping timeout: 240 seconds) 23.18.18 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.23.29 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 23.25.05 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.28.35 Join stoffel [0] (~quassel@p57B4D254.dip.t-dialin.net) 23.29.41 Quit Guest43341 (Read error: Connection reset by peer) 23.33.00 Quit stoffel (Remote host closed the connection) 23.42.43 Quit hebz0rl (Ping timeout: 276 seconds) 23.48.16 # hm, just hit a bug. I turned on the display on my Clip+ and it shows the (paused) track that I was previously playing 23.48.55 # not the one it's currently playing, which is even in another playlist/album 23.49.27 Join moparx [0] (~moparx@unaffiliated/moparx) 23.49.41 # even if I navigate the menus, or pause/play, it still shows the old paused track 23.49.47 # in the WPS 23.50.05 # New commit by 03gevaerts (r26835): Build D2 with the old compiler again (builds) 23.50.11 # New commit by 03gevaerts (r26836): Build D2 with the old compiler again (configure) 23.50.14 # the problem "fixed" itself when the current track ended 23.51.54 # r26836 build result: All green 23.51.57 Nick CGL is now known as CGL_emo_WTF (~CGL@186.90.252.47) 23.54.47 Quit ender1 (Quit: To err is human; to moo bovine.) 23.56.27 Quit stripwax (Quit: http://miranda-im.org)