--- Log for 06.12.109 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 14 hours ago 00.00.34 *** Saving seen data "./dancer.seen" 00.02.23 Join sustineo [0] (n=42116ef5@giant.haxx.se) 00.02.27 # Hello i have a problem, i have moved some data on my sandisk sansa e260v2 from my microsd to the flash memory that was abortet with a sd transfer error. Now rockbox wont start and the original firmware says "Not enough space for music db please free up 90 mb" but the player wont detect on my pc anymore. I dont know how I can format my player now. I dont know if the recovery mode can help because the memory is full 00.03.06 # Vampireking: plug the e200v2 on USB and format the disk 00.03.32 # hte player wont detect from my pc 00.04.29 # are you using windows ? 00.05.06 # at the moment but i have kubuntu 09.10 installed 00.05.24 # the player doesn't appear in dmesg output ? 00.05.27 # athe moment i using windows 00.05.51 # i have a dmesg log 00.06.03 # linux typically detects better, you may want to at least try it in linux 00.06.03 # i don't remember having problems with corrupted filesystems, i could always format the player 00.06.52 # i have tried but the player wont show up in linux 00.06.59 # hm 00.07.26 # wait, are you connecting to the pc w/ rockbox or default booted up? 00.08.03 Quit sustineo ("CGI:IRC") 00.08.04 # rockbox stops at the bootloader screen 00.08.08 Join sustineo [0] (n=42116ef5@giant.haxx.se) 00.08.23 # and the OF says Not enough space for music db please free up 90 mb 00.08.36 # Vampireking: try removing your microsd card 00.10.35 # Vampireking: anf then see if Rockbox will boot 00.10.44 # /anf/and/ 00.11.46 # i have tried it rockbox stops 00.11.53 # here a dmesg log http://nopaste.info/e912d96c33.html 00.12.11 # Vampireking: do you have a microsd card in the slot? 00.12.29 # i have it removed 00.12.49 # and Rockbox still will not boot? 00.14.13 Quit sustineo ("CGI:IRC") 00.14.48 # yes rockbox stops booting 00.17.26 # here are part 2 of the dmesg log http://nopaste.info/0ec77d752b.html 00.17.42 # Vampireking: The "Not enough space for music db please free up 90 mb" can be caused by a corrupt file system. You might try doing a file system check from your linux system. 00.17.44 # saratoga - sorry, back now. (although you seem to be gone now..). still calculating the tremor mul+add numbers 00.17.52 # sudo mkfs.vfat -F 32 /dev/sdb 00.19.48 # mkfs is an interesting way to check a filesystem... 00.19.49 # how do I find out what the device under linux is my mp3 player 00.20.41 Quit petur ("Zzzzz") 00.22.57 Quit pamaury ("exit(*(int *)0 / 0);") 00.23.24 # Vampireking: plug it in, then say dmesg | tail. 00.25.21 # ok I try it 00.25.24 # thank you 00.26.46 Quit Vampireking ("Nettalk6 - www.ntalk.de") 00.37.12 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 00.37.28 # stripwax: i'm working but i'll keep an eye on the channel 00.39.01 # I get something like 91008 muls and 131872 adds for tremor 2048-point 00.39.20 # can't help thinking I've miscounted. would probably be better to just instrument the code to print out each time.. 00.45.13 Quit n17ikh () 00.46.16 Join DerPapst1 [0] (n=DerPapst@p4FE8FFA7.dip.t-dialin.net) 00.46.22 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 00.47.01 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 00.47.05 # 91,000 muls per second, not per block? 00.47.49 # stripwax: ^ 00.50.01 Quit DerPapst (Read error: 60 (Operation timed out)) 00.52.38 # yeah , per block. must have miscounted. as you say, it's hard to read. I wouldn't be surprised if I'm off by a factor of 4, which would make it pretty similar to the other one 00.54.09 # Unhelpful: ah, the conditional version is faster, i didn't even try that :) aslo the thing with saturating unsigned subtraction also just hit me, now if can only remember the inline asm syntax :) 00.54.17 # stripwax: 91000 would mean something like 50MHz just for decoding 00.54.51 # err 50MHz just for the multiplies 00.55.09 # since theres roughly 86 blocks per second 01.00.28 Join Strife89 [0] (n=michael@adsl-146-208-154.mcn.bellsouth.net) 01.08.56 Quit voltagex (Remote closed the connection) 01.09.44 Join Vampireking [0] (n=quassel@82.113.106.217) 01.14.49 # saratoga - for n=2048, with instrumented code to track counts, I report 11136 single muls + 19904 single adds. for n=256, I get 1008 muls + 1696 adds. 01.14.58 # I'm back with my problem 01.14.58 # tail -f /var/log/messages says 01.14.58 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.827331] scsi 12:0:0:0: Direct-Access SanDisk Sansa e260 v03. PQ: 0 ANSI: 0 01.14.58 DBUG Enqueued KICK Vampireking 01.14.58 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833321] scsi 12:0:0:1: Direct-Access SanDisk Sansa e260 v03. PQ: 0 ANSI: 0 01.14.58 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833621] sd 12:0:0:0: Attached scsi generic sg3 type 0 01.15.01 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.833684] sd 12:0:0:1: Attached scsi generic sg4 type 0 01.15.04 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.849680] sd 12:0:0:0: [sdc] 7964672 512-byte logical blocks: (4.07 GB/3.79 GiB) 01.15.07 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.855332] sd 12:0:0:1: [sdd] 1989632 512-byte logical blocks: (1.01 GB/971 MiB) 01.15.10 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.861317] sd 12:0:0:0: [sdc] Write Protect is off 01.15.13 # Dec 6 00:52:41 patrick-kubuntu kernel: [ 1040.867313] sd 12:0:0:1: [sdd] Write Protect is off 01.15.15 # but I can't use sudo mkfs.vfat -F 32 /dev/sdc 01.15.16 # stop before the bot kicks you 01.15.17 # it says /dev/sdc: No such file or directory 01.15.34 # Vampireking - please use something like pastebin in the future for posts/replies like that 01.16.10 # ok sorry 01.18.20 # saratoga - (cont'd) - which (assuming 6 clocks for mult) ought to make it much, much slower than the ffmpeg mdct 01.19.49 # stripwax: so we save at least 2500 muls per pass with the ffmpeg one, and probably a lot more once its optimized 01.21.03 # I don't know about "a lot" (which multiplies are you going to take out?). but there's obviously material amounts of overhead elsewhere otherwise it would already be faster than the tremor one. 01.21.12 # i think we can pretty easily drop the mul and add count by another 1500 to 2000 in the ffmpeg one 01.21.30 # although some of those tricks would probably work on the tremor one too 01.22.02 # tremor already has pretty much all the tricks I can think of in it (other than using a different algo entirely) 01.22.09 # which tricks do you have in mind? 01.22.14 # stripwax: the rotation math could be done faster 01.22.34 # you can factor out the complex multiplies to go from 4 mul, 4 add, to be 3 mul, 3 add and a table lookup 01.23.19 # that would apply for all cross-product terms or just the initial/final rotation steps? 01.23.55 # stripwax: you can use it anywhere you multiply by a constant, but i don't know if it makes sense everywhere because of the large look up tables needed 01.24.03 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 01.24.22 Quit Vampireking (Remote closed the connection) 01.25.12 Join Strife1989 [0] (n=michael@adsl-154-22-241.mcn.bellsouth.net) 01.25.24 # yeah, extra lookup could turn out to be quite a large penalty 01.25.48 # the helix people do use that trick though, so its probably worthwhile 01.26.15 # but if you're going to use an extra lookup table for the pre/post rotation, you might as well use it in the butterflies too, I would have thought. 01.26.30 # since it would be the same table 01.26.39 # it won't be the same table 01.26.46 # the pre/post rotation constants aren't the same 01.27.16 # don't they both use sincos_lookup0? 01.27.33 Quit Strife1989 (Read error: 104 (Connection reset by peer)) 01.27.46 # oh maybe they do in the tremor one, they don't in ffmpeg 01.28.01 # heres where i got the idea: http://cnx.org/content/m12021/latest/ 01.28.17 Join Strife1989 [0] (n=michael@adsl-220-123-178.mcn.bellsouth.net) 01.29.13 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 01.30.46 # its interesting that tremor can get away with just one lookup for rotation and transform, i had thought that wasn't possible without considerable error 01.31.08 # saratoga - I'd seen that before, although (for me at least), the "but alernatively" (sic) section is basically unreadable. is it the same as (6) and (7) here? http://mathworld.wolfram.com/ComplexMultiplication.html 01.31.27 # look at the pdf version of the page 01.32.03 # but yeah thats the idea 01.32.10 # you just store ac, bd, etc already multiplied 01.32.24 # so your table gets 1.5x bigger, but one of the multiplies is already done for you 01.33.11 # it won't help on faster arm so its probably not worthwhile there, but it would be a good compile time switch to have for arm7/9 01.34.04 # wait, you can't store ac, bd already multiplied. a comes from constants but c comes from your data. you mean a+b, a-b ? 01.35.22 # Also if only one set of factors is used, could you just replace the table of [as] and [bs] with a table of [a+bs] and [a-bs] for no extra memory usage? 01.36.02 # also, on arm, a 64-bit add is a pain if you're not also doing a mul at the same time 01.37.21 # just look at the derivation in the link above 01.37.27 # it explains how to do it 01.37.47 # yep I did, but it doesn't say anything about storing ac, bd in a table - just storing a+b, a-b in a table. 01.37.49 # and 32 bit precision should be more then fine, thats all we use now anyway for trig 01.39.03 # oh maybe i remembered it wrong 01.39.14 # do you only need to store 2 constants and not 3? 01.39.21 # that's how I read it 01.39.42 # i think you need to store C too 01.39.58 # you're right - just spotted that 01.40.09 # n1s: i think the conditional is faster than that, anyway. sat has a result latency of two, so it's 4 cycles for clz, rsb, sat. the conditional version is 3 cycles if it needs to test explicitly, and 2 if not due to using a calculated input 01.40.26 # although maybe you could compute it just as easily 01.40.36 # since C = (D+E)<<1 01.41.00 Quit Strife89 (Read error: 110 (Connection timed out)) 01.41.23 # actually i think you can compute C easier then storing it 01.41.59 # since both C and S have 31 bits of precision, though, doing C+S is going to make things start getting a bit fiddly 01.42.05 # can arm shift the input to a mul for free or just the add? 01.42.39 # that should be ok, we've got tons of precision 01.43.18 # I believe you can shift for most things, but I don't think you can shift the inputs to the 32x32->64 smull/umull stuff. 01.45.38 # doing the D+E<<1 step is only going to be marginally faster then just doing an extra mul unless i'm missing something 01.46.17 # stripwax: i believe all mul instructions take only unshifted inputs. add, sub, rsb, and all bitwise logical instructions allow shifts, or any shifted 8-bit value, as inputs. 01.46.28 # although actually it might not matter 01.46.31 # (for the second operand only) 01.46.55 # if you double every number by 2 theres no need to shift then back as long as you remember you've changed your fixed point 01.47.08 # shifted register operands need to available 1 cycle before they are used, or they incur a stall on armv6 01.48.30 # armv6 has a pipelined mul so this probably wouldn't help anyway 01.48.55 # does armv6 have a packed mul16x2 op? 01.50.46 # http://forums.rockbox.org/index.php?topic=23263.0 < c200v2 mkamsboot confirmed several times to not work on every model 01.50.49 # saratoga: it can multiply the elements of two packed 16x2 vectors and produce a 32-bit sum or difference, optionally accumulating and optionally swapping the components of one vector 01.50.59 # yeah i think this is actually faster on arm < 5E, since you trade on fixed point mul (<=6 clocks) for 2 ordinary adds (2 clocks) 01.51.40 # with a free shift folded into one of the adds 01.52.22 # it also can extra the top or bottom 16-bit value from a 32-bit register as a multiply operand - there's an instruction to pick top or bottom of two registers and produce one 32-bit result, and also 32*(16t/b), but the last shifts output right by 16 01.52.37 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 01.52.53 Quit BlakeJohnson86 ("Leaving.") 01.52.58 # Unhelpful: ok not what i was thinking 01.53.07 Quit DerPapst1 ("Leaving.") 01.53.31 # you want to multiply the components of two 16-bit vectors to produce packed 16-bit results? 01.53.36 # so this trick is probably worth using almost everywhere on those targets 01.53.47 # Unhelpful: well packed 32 bit results I guess 01.54.12 # basically a way to do 32x16,32x16 = 32x32.32x32 01.54.33 # but that'd be asking too much 01.55.35 # Unhelpful: yeah, i thought there was a "uqsub" instruction but there isn't one 01.56.37 # btw the conditional version showed only +- 0.01s differences on my beast decoding flac so it's about the same as my slightly less readable code :) 01.58.27 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 01.58.27 # well time to go read about waveguide for a couple hours, maybe someday we'll actually get around to writing this thing :) 01.58.51 # saratoga - so how much 'free' precision do we have in, say, tremor? I can't see any easy way to use this 3mul,3add rearrangement without losing 2 bits of precision and/or having a load of carry shifting instructions 01.59.10 # stripwax: we've got plenty of precision 01.59.44 # you could probably throw away 5-10 bits before you'd have even 1 bit difference on 16 bit output 02.00.05 # for WMA I can't even measure the accuracy because the Windows decoder is less accurate then we are 02.00.11 # heh! 02.00.38 *** Saving seen data "./dancer.seen" 02.00.45 # if you have any ideas about how to trade accuacy for speed, please suggest them 02.00.50 # accuracy 02.01.52 # i was thinking maybe trying to pick off the mdct coefficients that get multiplied by large trig values and shift them by 8 bits or so, that way they're more likely to save a cycle here and there on arm7 and arm9tdmi 02.02.06 # due to early termination in the multiplier 02.02.28 # that or maybe see if 32x32 fixed point multiplies can be used anywhere, since those are also faster then the 32x32=64 variety 02.03.01 # but thats hard to do without a very good understanding of the algorithm 02.03.15 Quit arohtar (Client Quit) 02.03.31 Join faemir [0] (n=faemir@78.33.109.163) 02.03.43 # although thats my favorite thing about this new fft, its quite easy to understand compared to all the others we've looked at 02.05.02 Join Strife89 [0] (n=michael@adsl-220-102-238.mcn.bellsouth.net) 02.05.16 # stripwax: did i send you the annotated version of the new fft that has the mul/add counts for each step of the split radix ? 02.05.23 # i don't think so 02.06.38 Join ansuz [0] (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) 02.07.12 # n1s: qsub/qadd, you mean? those appear to saturate one of their inputs, and then do a sub/add. 02.07.35 # stripwax: http://pastebin.com/m40a70235 02.08.18 # stripwax: this doesn't have the optimizations though, so FFT8 and FFT16 use 4 and 8 too many multiplications respectively 02.09.11 # since all the TRANSFORM calls with both trig factors equal can be factored into half as many muls 02.09.23 # saratoga: that'd need two result registers... to my knowledge the only ops on arm using dual result registers are those returning 64-bit results. 02.09.37 # Unhelpful: yeah thats what i figured 02.09.38 # Unhelpful: tey saturate the result but only for signed values, there are no unsigned saturating add/sub 02.10.18 # (there are however *parallell* unsigned saturating add/sub for 16 and 8 bit packed values... 02.10.41 # if anyone can see any other savings in that fft, please let me know! 02.10.50 Nick ansuz is now known as ansuz_ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) 02.11.01 Nick ansuz_ is now known as ansuz__ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) 02.11.19 # n1s: well, since the value in question is only 5 bits, that would work fine, but those don't accept op2, only register operands, so you need a mov r, imm. 02.11.27 Nick ansuz__ is now known as ansuz_ (n=kevin@dsl093-172-019.pit1.dsl.speakeasy.net) 02.12.29 Part ansuz_ ("Konversation terminated!") 02.12.46 # saratoga: i had an idea about packed SWAR multiplies for *very* small multipliers - i thought it might manage to save vs 3 mask+multiply for blending rgb subpixels independently, but i've not tested it yet. 02.13.27 # also that's not using any special platform instruction, it's construction a mask value, with some unused low bits that will eventually overflow and clear the mask after they're incremented enough times. 02.13.36 Quit Strife1989 (Read error: 113 (No route to host)) 02.14.03 # the idea was to do a packed (5,6,5) * (2,2,2) multiply-accumulate 02.17.01 Quit stripwax ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.17.58 # Unhelpful: clz, rsb, usat is faster than the conditional 02.19.15 # n1s: on arm6? i guess that makes sense if the conditional must be tested explicitly, and if there are other ops that can be done to fill usat's result latency. 02.19.50 # Unhelpful: yeah on the beast decoding flac 02.20.03 Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) 02.20.56 # maybe usat can run conditionally even 02.21.28 # n1s: hey.. I think it can 02.23.31 # n1s: would that gain anything? you'd need to test the input or output of clz to have a flag to condition it with, and then you'll probably be slower than the clzne,rsbne version 02.23.55 # nothing that saturates or is parallel supports immediates. maddening. :P 02.25.40 # What's the status of the arm-eabi build? 02.26.12 # i was thinking that rsbs can set C and V flags, can't these be used? 02.26.27 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 02.26.27 # * n1s points out he's a asm newbie 02.27.40 # and the N and Z flags 02.29.20 # so clz, rsbs, usatmi 02.30.12 # i'm not sure that buys us anything, though: "Most instructions execute in one or two cycles. If these instructions fail their condition codes then they take one and two cycles respectively." 02.30.27 # ah 02.30.37 # although, sat *executes* in one, with results in 2? 02.31.02 # i would *try* making the sat conditional and seeing if it matters. 02.32.49 # * n1s tries 02.34.44 Quit funman ("free(random());") 02.35.28 # nah, no diff 02.35.28 Join Omlet [0] (i=omlet05@91.176.181.84) 02.39.38 Join sustineo [0] (n=42116ef5@giant.haxx.se) 02.39.59 # i need help rockboxing a v1 fuze 02.40.09 Join webguest06 [0] (n=4a398403@giant.haxx.se) 02.40.33 # i was thinking that we could have a bit-scanning generic in the codeclib, with flags for type of result, and 0-input handling. so av_log2 would be someting like bs(x, BS_LOG, BS_ZERO) 02.41.17 # Can I have mod access to the Wiki to add a couple of devices? 02.41.23 # Username is lduperval 02.41.26 # when i use the auto-installer, it says [err] original firmware unknown, please try another version. Tested c200 versions are: 3.03.05 (on the bootloader install) 02.41.49 # oops, sorry 02.41.53 # *3.02.05 02.42.21 # whats with that? 02.42.34 # does the installer even support fuze? that's an unsupported port. 02.42.41 # Unhelpful: i'm not quite sure i understand what you mean, can you elaborate a bit on that? :) 02.42.43 # apparently it does 02.42.51 # it has it in the list 02.43.05 # and says it does on the site 02.43.14 # but that error seems strange 02.44.23 # it says rockbox runs on fuze. i don't see anything saying that the installer supports it, and the front page at least implies that only stable ports are supported by the installer: "Rockbox runs well on these players, has a complete manual and is supported by the installer: " 02.44.33 Quit Strife89 (Read error: 110 (Connection timed out)) 02.45.41 # JdGordon: is there a good place to force the menus to always use the touchscreen option set in settings, and then revert the touchscreen setting to what it was before the menu was entered? 02.45.50 # n1s: bit-scanning as in scanning from one end or the other for a set bit. BS_LOG indicating that the output should be log2(x), and BS_ZERO indicating that 0 input should produce 0 output 02.46.00 # ah 02.46.06 # BS_DONTCARE might be used by things that pre-test 0 input. 02.46.13 # how do i install w/o installer 02.46.39 # Unhelpful: aha like a macro that expands to a call to the correct function, yes that could be nice 02.46.59 # here's my asm av_log2 thing if you want to look http://pastebin.com/m3a285382 02.47.11 # n1s: it needn't be a macro, if the flag inputs are constant then inlining will specialize it to remove the dead branches 02.47.28 # true 02.47.38 # kkurbjun: umm... what? when would it swap? 02.48.14 # a BS_ISPOW2 might also be useful on targets w/o clz, to indicate that inputs needn't be reduced to a power-of-2... assuming we even decide that the best algorithm is one that does that. ;) 02.48.15 # sorry.. i mean why would you go from one to the other without the user wanting it? 02.48.53 Quit sustineo ("CGI:IRC") 02.49.54 # kkurbjun: I guess you mean in a game? in that case I would wrap do_menu() with your own function to do that... that is not something that shold happen in the core 02.50.16 Join Casainho [0] (n=chatzill@bl15-146-182.dsl.telepac.pt) 02.50.27 # the benefits of such an algorithm are that 1) 0 as a special case can be handled by the LUT 2)on coldfire, a mul is fairly cheap and the reduction avoids any branches 02.50.43 # JdGordon: so, with plugins they are always, by default forced to grid mode when you enter them, and that makes sense when you are actually in the game, but the menu's are not currently consistent between the plugins, the plugins that are "aware" of absolute more and make use of it set the menu to the user setting when they go into menu's and then revert to the plugin setting when exiting, but that's currently being done piecemeal, each plug 02.50.56 # I'm also trying your latest patch 02.51.02 # Unhelpful: yeah 02.51.04 Part froggyman 02.51.14 # I'm still getting graphic glitches when I enable/disable the custom statusbar 02.51.23 # should i commit the asm version for armv6? 02.51.30 # AH ok, I didnt realise plugins force to grid mode... 02.52.31 # n1s: i'd say yes, without the conditional. if i want to generic-ize log2 i can do that after we see what's best on armv4 and coldfire 02.53.25 # kkurbjun: even then, I wonder if that would confuse users... 02.53.35 # unfortunately, while it's branchless, the rounding is rather lengthy on cf 02.53.56 # but sure, if you want to force it back you could easily set up something like the stack in the patch for the themes 02.54.03 # (kugel hates that stack idea :D ) 02.54.51 # not only does it lack shifted operands, it appears it can only do shifts in place, so the sequence becomes move; shift; or; :/ 02.54.53 # JdGordon: it is definitely confusing for menu's currently. I think that changing the mode in game is reasonable since the controls for a touchscreen on most games will be very different 02.55.49 # Unhelpful: yeah, i think the only place you get free shifts on coldfire is with the mac instructions 02.56.01 # *emac, even 02.56.05 # JdGordon: what needs to be done to get pluginss to retain the background in menu too? Does that just need to be fixed on a plugin by plugin basis? 02.56.37 # n1s: yes, but i'm rather shocked that you can't specify an output operand for lsr :/ 02.56.41 # register, rather. 02.58.04 Quit ansuz ("Konversation terminated!") 02.58.14 Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) 03.00.13 # JdGordon: why is a stack needed? 03.00.31 Join sustineo [0] (n=42116ef5@giant.haxx.se) 03.00.45 # how do you manually install rockbox on a fuze v1? 03.01.25 # i need a bootloader, right? 03.01.43 # (i tried just unzipping to the sansa) 03.01.50 # (.rockbox) 03.03.05 # New commit by 03nls (r23868): slightly faster asm av_log2 for armv6 (currently only Gigabeat S) 03.03.58 # anyone know? 03.04.08 # the rockbox site is being unhelpful 03.05.04 # i would say "read the manual" but they seem to have gone MIA so maybe a search in the wiki? 03.05.20 # it looks like 16 ops to do the rounding job on cf, a mul with extension word, and then fetch from LUT. 03.05.33 # n1s: there's a manual for fuze? 03.05.41 Quit Casainho (Read error: 60 (Operation timed out)) 03.06.10 # Unhelpful: yeah, it's listed on the manual page at least but the link to it and many more manuals give 404 03.06.22 # something is fishy 03.08.05 # n1s: so that recent commit is arm v5+? or is it just v6? 03.09.05 # kkurbjun: v6 (and up) 03.09.09 # because of usat 03.09.10 # is the D2 v5 or v6? 03.09.17 # i think it's v5 03.09.54 # the speed difference between this version and the one with clz and a conditional is very small 03.09.58 # I was wondering because of the conditional, I ddin't see a >6 03.11.24 # >6 would be 7 and up 03.11.31 # thank you, google cache. ::) 03.11.50 # :), oh wow, I'm still foggy aparently 03.13.06 # which cf do our targets have? ISA_A+ has a ffs instruction, it appears 03.14.39 # kkurbjun: clz is armv5, usat is armv6. the conditional version, or n1s's earlier version with the shifts, is probably best on armv5 03.14.45 Quit Lss (Read error: 54 (Connection reset by peer)) 03.16.07 # i'd say use the conditional on armv5, it's always 3 cycles, unless the input is calculated in which case gcc can add an s to the instruction producing the input and save the explicit input test. 03.16.44 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 03.17.03 Quit klapaucjusz ("leaving") 03.17.08 # sustineo: click the fuze link on the front page, the directions are there 03.20.06 # JdGordon: the new patch does get rid of the graphic glitch when you click resume and there is nothing to resume 03.20.52 # Unhelpful: our coldfires are ISA_A and don't support the ff1 instruction AFAIK 03.22.15 # n1s: boo. so we're between using an LUT and using straight binary search. 03.23.51 Join Tomis [0] (n=Tomis@70.134.93.64) 03.24.08 Quit efyx_ (Remote closed the connection) 03.26.46 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 03.27.50 # yeap "Error: invalid instruction for this architecture; needs ColdFire ISA_A+ (521x, 528x, or aliases)" 03.28.22 Quit n1s ("Lämnar") 03.29.31 # n1s: I'm not sure if you saw the red, but the conditional does need to include ARM_ARCH >4 with CPU_ARM or some alternate since it's failing to build with arm targets below 5. 03.29.42 # oops 03.30.27 # kkurbjun: sorry, was watching tv... stack makes enable/undo really easy :) 03.30.51 # I'm tossing up weather to add the background image drawing to the theme enable stuff which would solve that problem 03.31.07 Quit efyx_ (Remote closed the connection) 03.31.23 # JdGordon: couldn't you just have a local variable that stores the setting in the menu. - you wouldn't need to have a separate stack. 03.32.01 # Also, I'm logging some notes about the artifacts I am seeing in the main build in FS10824 03.32.06 # sure that would work... thats the current solution for the bars stuff 03.32.12 # great 03.34.01 Join |Kirin| [0] (n=Kirin@modemcable164.145-82-70.mc.videotron.ca) 03.34.44 # is do_menu() the only core function with this plugin touchscreen problem? 03.35.12 # I believe so 03.35.38 # n1s: but i thought we weren't even able to use our *actual* target with gcc3? 03.35.39 Quit |Kirin| (Client Quit) 03.36.02 # maybe add a wrapper for it and use that instead of do_menu in the plugin api? assuming its just background image and touchscreen which needs forcing 03.37.34 # is ARM_ARCH not defined on PP and AMS ? that red looks odd 03.38.26 # saratoga: CPU_ARM is defined, but there's no function for arm arch's less than 5 defined in the CPU_ARM block 03.39.16 # the previous conditional forced arms less than 5 to use the C implementation 03.39.17 # oh i misread that as "ARM_ARCH == 4" 03.39.30 # :-D, that's what I was doing 03.39.44 # it might be more clear to do a >= 5 and a >=6 03.40.59 # can anyone think of a good reason to not add a lcd driver function which is "dealy update" which just tells the driver to do a full screen update next time any updat is done? 03.41.07 # s/dealy/delay 03.41.18 # JdGordon: the wrapper is probably the way to go, I was thinking about the touchscreen stack thing and I think it would cause problems when the setting is supposed ot actually be changed in the core 03.41.55 # yeah, its probably overkill for the touchscreen stuff 03.43.38 # JdGordon: why do you want a wrapper that does that, you can just call the fullscreen update when you want the full update 03.44.51 Quit GeekShado_ ("The cake is a lie !") 03.45.50 # JdGordon: I added the comments with the artifacts that I was seeing 03.53.12 # kkurbjun: 1 and 2 probably wont be fixed... but thanks 03.54.36 # JdGordon: why won't 1 and 2 be fixed? 03.54.54 # because they are almost never hit... its not a common thing to do 03.55.01 # also that setting is being removed anyway 03.55.11 # not just yet.. but soon 03.55.27 # you will still be able to enable/disable the statusbar won't you? 03.55.38 # yes 03.55.43 # its load a sbs, or dont 03.56.45 Join dmb [0] (n=Dmb@unaffiliated/dmb) 03.57.25 # JdGordon: I can preoduce similar artifacts when loading different sbs's 03.57.26 Quit sustineo ("CGI:IRC (EOF)") 03.57.31 # produce 03.57.40 # sure, so that should be fixed... 03.58.26 # :), ok, I'll give directions on how to do the same thing without that menu 04.00.19 # I'm more worried about artefacts that dont involve chanign sbs :) 04.00.26 # swtiching between screens and stuff 04.00.30 # * JdGordon is off for the evening 04.00.42 *** Saving seen data "./dancer.seen" 04.01.21 # JdGordon: that's fair enough, but the interface doesn't look too good when these things happen, and I would still consider them a bug 04.01.24 # see ya 04.03.58 # (I added a fifth artifact that is similar to 1 and 2 without the custom statusbar menu when you look at that fs). 04.04.31 Quit webguest06 ("CGI:IRC (EOF)") 04.20.08 Join Rondom_ [0] (n=quassel@dslb-084-057-140-109.pools.arcor-ip.net) 04.34.09 Quit Rondom (Read error: 110 (Connection timed out)) 04.35.42 Join kugel [0] (n=kugel@e178107118.adsl.alicedsl.de) 04.54.46 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.56.59 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 04.59.37 Quit fdinel (Client Quit) 05.07.23 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 05.31.10 Part froggyman 05.43.26 # New commit by 03unhelpful (r23869): Fix red: av_log2 undefined for ARM_ARCH <= 4, missing codeclib.h includes. 05.47.48 Join Greenhorn [0] (n=Green@CPE001d7e3dde7f-CM0011aec4fcb2.cpe.net.cable.rogers.com) 05.48.36 # are there mirror links for the manuals? 05.48.44 # i chose a bad day to start using this 05.50.17 Quit ansuz ("A motion to ajourn is always in order.") 05.54.07 # Greenhorn: the manuals are built nighlty. Last night's run must have had problems. 06.00.08 Quit Greenhorn () 06.00.45 *** Saving seen data "./dancer.seen" 06.00.48 # n1s: av_log2 benches slower on my e200 than the pseudo-debruijn version - maybe because of the larger LUT, 256 entries vs 64 (or 4 cachelines vs 16, and perhaps we ought to cache-align the LUT)? 06.02.18 # i was thinking, the pseudo-debruijn version could also allow the user to transform the results by some arbitrary function, by defining the LUT in a macro 06.21.49 Join kadoban__ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 06.35.23 Quit kadoban_ (Read error: 110 (Connection timed out)) 06.52.42 Join JdGordon| [0] (n=me@rockbox/developer/JdGordon) 06.55.59 Quit panni_ (Read error: 104 (Connection reset by peer)) 07.04.14 Quit bluebrother (Read error: 104 (Connection reset by peer)) 07.04.17 Join bluebrother [0] (n=dom@f053152163.adsl.alicedsl.de) 07.07.21 Quit JdGordon| (Remote closed the connection) 07.27.04 # Vampireking:(for the logs) I think I have a solution for you. Plug your player into the usb and wait for the Sandisk logo to appear. Now unplug the player before the database refresh starts. Should put you into the menu in the OF and you can format from there. 07.30.03 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.31.08 Quit Tomis (Read error: 104 (Connection reset by peer)) 07.31.26 Join Tomis [0] (n=Tomis@70.134.93.64) 07.37.23 Quit Horscht (Read error: 60 (Operation timed out)) 07.56.35 # FlynDice: i haven't had any problems starting my Fuze anymore since your little patch. had a couple of glitches while playing, but have yet to confirm the original files don't have this glitch as well 08.00.17 Join AndyIL [0] (n=pasha_in@212.14.205.32) 08.00.28 # Unhelpful: rbutil supports the Fuze, but that guy probably ran the latest Fuze firmware for which rbutil (or mkamsboot) has no support. 08.00.49 *** Saving seen data "./dancer.seen" 08.08.48 # does it give a meaningful error message if you try too new a firmware? 08.09.44 # it gives the mkamsboot error sustineo pasted 08.11.46 Quit AndyI (Read error: 110 (Connection timed out)) 08.16.45 # the mkamsboot on the wiki page give a friendlier 'unknown firmware model' message 08.21.30 # topik: but he was using a c200v2 right? i don't think rbutil will work at all with those 08.22.31 Join stoffel [0] (n=quassel@p57B4DB42.dip.t-dialin.net) 08.23.47 # nope, fuze v1. http://www.rockbox.org/irc/log-20091206#03:00:45 08.24.06 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 08.24.27 # the mkamsboot in current rbutil does have this error message for the fuze though: Tested c200 versions are : 3.02.05 08.25.03 # you get that with the 01.02.28 OF 08.25.24 # 01.02.26 works fine 08.25.30 # the error message he quoted mentions the c200 though? 08.25.51 # yes, the fuze mkamsboot gives the c200 error 08.26.09 # weird 08.26.16 # [ERR] Original firmware unknown, please try an other version. Tested c200 versions are : 3.02.05 08.26.19 # bluebrother should probably be pinged about that 08.26.36 # that's the exact error with rbutilqt-v1.2.3.zip and fuze01.02.28.zip 08.27.07 # replacing the mkamsboot with the one from the wiki, or yours that supports fuze01.02.28.zip would be an option 08.32.43 # New commit by 03FlynDice (r23870): Sansa AMS: Move the boost from SD ident to operating frequency to after the cards get switched to HS timings. ... 08.35.27 Join Rob2222 [0] (n=Miranda@p4FDCB710.dip.t-dialin.net) 08.40.12 Quit CaptainKewl (Remote closed the connection) 08.53.47 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.18.26 # Morning 09.19.52 # I gather the only way of getting at the DB (and thus, playcount/ratings... I'd like to sync with home, and update ratings while on the road) is via the export mechanism? 09.21.03 # jae: Sorry can't help with the DB but I'm interested in how you're player is working 09.21.14 # FlynDice: that wouldn't, by any chance, fix the SD card problem? (As in I couldn't boot (first time) with the SD inserted) 09.21.35 # FlynDice: mostly fine, except for the just-mentioned problem 09.21.40 # jae: Well I'm really hpoing it does.... 09.21.48 # hoping even 09.22.25 # Strange thing, it hung the very first time; I could boot without the card, and then insert it while running... and it boots nicely since then 09.22.38 # Only I'm not sure the DB picks up the SD contents 09.22.44 # Have to check in more detail 09.23.03 # yes, that's similar to what topik was reporting 09.23.29 # Oh, have to do an update then 09.24.06 # yes please do and give me a holler with the results ;-) 09.24.49 # I also get random gfx glitches, but they are totally (it seems) random, and very transient... and w/o any consequences as to function of the player as a player 09.25.12 # what do you mean gfx glitches? 09.25.45 # Oh, and the automatic manual build seems to be broken (okay, so it's the weekend... so it should possibly be fixes quicker than on weekdays... ;-) 09.25.51 # ... still, that is 09.26.30 # Oh... stuff like a white screen with a black smear of pixels across... which immediately disappears 09.27.05 # display corruption is a known issue on some ams targets, theres an FS task with some patches in it 09.27.15 # Or just a couple minutes ago, I got a weirdly "split" page in some setting subcategory... one button press later it corrected itself again 09.27.18 # its particularly bad in mpegplayer 09.32.03 # * jae mounts his Fuze on WinXP... hoboy... ;) 09.34.58 # Whee, let's see if I can update last.fm successfully 09.37.31 # It worked. Nice. 09.37.38 # i've had similar glitches as jae reports, but they are hardly a showstopper 09.37.47 # random menu distortions and such 09.38.22 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 09.38.25 # Yup... but since there so extremely short-lived... 09.38.44 # same here. all the benefits of rockbox eclipse this glitching 09.39.13 # theres a fix it just breaks other stuff 09.39.19 # it'll be fixed eventually in svn 09.39.31 # do you know what it breaks? 09.39.51 # topik: *Very* much so... I'm so happy to finally run rb, what's a *nanoscopic* (almost ;-)) thing like that 09.40.36 # "theres a fix it just breaks other stuff" <--- Now that's a phrase to assign a macro to.. ;-) 09.40.44 # lol 09.42.30 Quit phanboy4 (Read error: 54 (Connection reset by peer)) 09.43.14 # FlynDice: what benefits would it be to have my sdhc card run at high-speed timings? 09.43.53 # topik: i think the scroll wheel 09.44.42 # i pick screen glitches over scroll wheel glitches any day. but the FS patch might be an indication for the direction of a real fix 09.45.24 # well the card frequency can be run at up to 50 MHz with HS timings instead of the standard 25MHz. 09.46.52 # yeah, but i doubt there's anything the Fuze can playback that needs 50Mbit/s. and without USB, read/write performance should be enough on low-speed timings 09.48.02 # topik: If your card is reporting 25.0 for speed though it's quite likely that it is not a HS card. In that case we're overclocing it now as the cards are both running at 31 MHz. The internals are v1 non HS cards too 09.48.22 # HS is speed class 2? 09.50.24 # I'm not sure on that, I looked at the spec last night and it doesn't specifically say. But my class 6 card definitely takes the switch to HS timing and reports 50.0 MBit/s. 09.52.11 # wikipedia suggests class 2 is 2Mbyte/s and class 6 is 6Mbyte/s 09.52.37 # And the internal cards also do not take the switch. We don't try it now with current code but I tried it before and they reported 25.0 after trying to switch. 09.53.06 Join flydutch [0] (n=flydutch@host140-41-dynamic.116-80-r.retail.telecomitalia.it) 09.53.31 # topik: thats write 09.53.33 # speed 09.53.36 # there doesn't seem to be much reason for the Fuze to be HS i think 09.53.44 # we don't care about rated write speed 09.53.59 Quit advcomp2019 ("Leaving") 09.54.31 # good point. missed that crucial word 09.56.00 # i understand why you want things to work within specs and at least as good as in the OF 09.56.17 # but for me as a user, it is amazing what you guys did for both my Fuze and Nano 2G 09.57.26 # * jae is updating his Fuze... 09.59.28 # Stupid noob question: how do you build this thing? I have an SVN checkout, but when trying "make" in the manual dir (since the manual is still not updating online)... only errors. Looks like some env/make vars need to be defined, and I don't know where they are defined. 10.00.20 # make a directory called build in the svn dir 10.00.50 *** Saving seen data "./dancer.seen" 10.01.16 # well not in the svn dir but inyour source dir 10.01.40 # Then run tools/configure? In the dir, right? 10.01.45 # yes 10.01.52 # ../tools/configure 10.01.55 # * jae is guessing... oh, he guessed right! :D 10.02.37 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 10.02.43 # then make && make zip 10.02.59 # make manual more likely 10.03.35 # ../rockbox-svn/tools/configure in my case... oops, needs input, so can't run it just as GNU configure 10.04.05 # it's not autoconf, no 10.04.42 # you can use commandline options though 10.05.04 # normal/advanced? What's the diff? 10.05.20 # you want normal 10.06.10 # Is there a wiki page on this? Or is "arcane knowledge"? ;-) 10.06.26 # yes there is but I'm interested in helping you help me.. ;-) 10.06.38 # FlynDice: I realized what I want: I want to read configure (it's not Perl, so it's not that painful ;)) 10.06.44 # http://www.rockbox.org/wiki/DocsIndex#For_Developers 10.08.05 # gevaerts: stupid me, I think I've looked at (this part of) that page before... 10.13.44 # Well... I don't have an arm toolchain, it seems (it can't find arm-elf-gcc and arm-elf-ld) 10.13.52 # Not really surprised 10.15.23 # http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling answers how to get one 10.15.41 # pretty much running tools/rockboxdev.sh 10.17.41 # There isn't, by any chance, a .deb running around somewhere with a suitable arm gcc? ;) 10.18.19 # And rockboxdev.sh it is (I built gcc manually, some years ago, just out of curiousity, and this just for reference...) 10.19.15 # i doubt it 10.19.33 # the only advantage of a deb would be that you don't have compile it yourself, but on a modern computer its pretty quick 10.20.13 # Define "modern" ;) 10.21.13 # i just switch from my p3-500Mhz laptop to a virtual machine on a modern pc for compiling rockbox. makes all the difference 10.25.09 # I'll try on my Linux box first... it's definitely faster than a p3-500 :P 10.27.57 # multicore system takes probably 5-10 minutes for just one cross compiler 10.28.06 # just be sure to use make -j 10.28.48 # my virtualbox vm does a single build in about 4m30s 10.28.58 # hmm, -j for more cores. must try that 10.48.26 # i have an e200 that has had its hd completely wiped. what can i do 10.51.44 # sunrider: would this help? http://www.rockbox.org/wiki/SansaE200Unbrick 10.52.21 Join Telos [0] (n=Telos@c-65-34-193-169.hsd1.fl.comcast.net) 10.52.44 # maybe. ill look into it. thanks 10.53.07 # Just poppin in to see any work's been started for Rockbox on the Fuze v2. 10.54.52 # nothing yet that is usable at this time 10.59.16 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 11.00.41 Join n1s [0] (n=n1s@90-230-78-242-no134.tbcn.telia.com) 11.00.51 Join fyre^OS [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) 11.05.42 # does not apprear to be working. 11.05.52 # im not finding anything i can mount ;( 11.06.26 # i guess it doesnt matter. it was a noisy player 11.06.33 # time to upgrade to something 11.07.27 Join FOAD_ [0] (n=dok@dinah.blub.net) 11.07.48 # sunrider: what does "had its hd completely wiped" mean exactly? 11.08.10 # gevaerts, all partitions were lost 11.08.19 # how? 11.09.16 # well., i needed a usb stick. i couldnt find any so i thought i could `dd` an iso onto this thing. i made the backups and then formatted the sansa 11.09.21 # havent been able to make it mount since 11.09.47 # FlynDice: SD card, still no dice with 23870, it hangs at the startup logo w/ card, starts up correctly without 11.10.00 # hm, the manufacturer mode recovery with e200tool should work then 11.11.11 # just discovered i can capture usb ports with wireshark 11.11.30 # heh! 11.11.36 Quit kugel (Read error: 60 (Operation timed out)) 11.12.37 # jae: ok, if you pop the card in after rockbox boots will it init ok? 11.15.29 Quit Telos () 11.17.46 # Bus 002 Device 011: ID 0781:0720 SanDisk Corp. Sansa C200 series in recovery mode 11.17.58 # C200? thought it was e200. 11.18.01 # Yup, it does 11.18.32 # says `e280` in small print on the back 11.18.34 Quit fyrestorm (Read error: 110 (Connection timed out)) 11.19.09 # sunrider: the usb id databases in linux aren't always perfect 11.19.24 # jae: would you try rebooting with card intalled now 11.19.42 # New commit by 03bluebrother (r23871): Remove special lib Makefile targets that aren't used anymore. 11.19.46 # New commit by 03bluebrother (r23872): Improve detection of system libspeex and fallback earlier. ... 11.21.20 Quit FOAD (Read error: 110 (Connection timed out)) 11.21.20 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 11.21.25 # and if that works, would you turn it off and wait awhile (10 mins?) and then try again? Not that you had anything better to do.... 11.23.37 Quit robin0800 (Read error: 110 (Connection timed out)) 11.24.53 # * FlynDice is headed to bed, will read logs in the AM thanks for the help! 11.25.08 # Nopes, still hangs when rebooting 11.25.19 # That actually looks like a regression to me 11.25.27 # ooops, sorry for the commit-and-run last night :/ 11.25.29 # Rats... 11.25.54 # Unhelpful: thanks for fixing, maybe i shouldn' 11.25.59 # t do this at 3 am 11.33.43 # Unhelpful: that's true about the coldfires and gcc < 4.3 we use mcf5206e instead which has the same isa except for the emac and also different execution timings for muls etc 11.34.54 Quit bzed (Remote closed the connection) 11.34.55 Join bzed_ [0] (n=bzed@devel.recluse.de) 11.35.09 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 11.36.48 # Unhelpful: the table is in iram, is that cached? 11.40.34 Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) 11.46.07 Quit dfkt (Read error: 60 (Operation timed out)) 11.46.38 # *Now* I feel stupid... I just noticed that the version running is 23863 (or so everything tells me), even though rbutil says it installed 23870. 11.46.40 Quit Tomis () 11.47.04 # So I do I make it actually *do* the upgrade? Or is just a wrong version number? 11.47.29 # +who 11.47.37 # +how (dagnabbit9 11.47.45 # *aaaargrggh* 11.47.48 # can't type 11.50.55 Join Llorean [0] (n=DarkkOne@adsl-76-202-17-167.dsl.hstntx.sbcglobal.net) 11.54.40 Join bzed_ [0] (n=bzed@devel.recluse.de) 11.58.34 Quit bzed (Read error: 111 (Connection refused)) 11.58.34 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 12.00.54 *** Saving seen data "./dancer.seen" 12.07.19 Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) 12.30.31 Quit BHSPitLappy (Read error: 110 (Connection timed out)) 12.33.25 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 12.35.23 # Whee. I can read the DB! 12.35.49 Join DerPapst [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) 12.48.16 # hmm, quite some manuals seem to be broken :( 12.49.29 # I have a feeling it's all the unstable ones... but it's just a hunch, I didn't really make any scientific study 12.50.23 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.50.26 # as far as I can see it's related to some tuner thing. Well, the description of it obviously :) 12.50.41 # but we'll see once my batch run finishes 12.55.20 # How does one upload stuff to the wiki? And... what if I want to supersede a file already up there? 13.01.47 # Could someone add me to WikiUsersGroup? Can't even edit my very own page... oh, name is "JaE" (natch) 13.02.33 # jae: that's the wrong name ... 13.04.46 Quit antil33t (Read error: 104 (Connection reset by peer)) 13.04.53 Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) 13.05.07 # How's that the wrong name? 13.06.00 # because we have a real name policy, which is mentioned in the signup page. User names are FirstnameLastname, not SomeNickIWantToUse 13.06.30 # http://www.rockbox.org/wiki/JaE exists... 13.06.31 Join Anyone [0] (n=52716adc@giant.haxx.se) 13.07.06 # And it's pretty real... just my initials (just like here on IRC) 13.07.06 # jae: Yes, it exists until it's deleted during some cleanup. 13.07.11 # hmm, the signup page changed slighly. It was more obvious in the past, as far as I remember ... 13.07.45 # jae: The rule is enforced manually 13.07.45 # The policy is "real names" not "real initials" though. 13.07.55 Quit dfkt_ (Read error: 110 (Connection timed out)) 13.09.20 # jae: Basically, any account can be created (because it's impossible to automate 'real name' checks) but there's a manual review (this) before an account can edit pages. 13.09.59 # Okay then... I'll have to reevaluate if I want/have to edit the wiki then 13.10.29 # Note that I do give my real name even here on IRC (check /who, that *is* my real name) 13.12.59 Quit Anyone ("CGI:IRC (EOF)") 13.15.11 # n1s: i don't know, is it? i would guess so as the smaller-table version that won is more ops... 13.16.18 # * bluebrother added a notice to the wiki signup page. 13.16.44 # Unhelpful: ok, cachealign might be worth trying then i guess 13.16.46 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 13.17.01 Join happytodd [0] (n=7cbbaee5@giant.haxx.se) 13.17.46 # Hello =] 13.18.48 Quit happytodd (Client Quit) 13.19.32 Quit n1s ("Lämnar") 13.29.47 Join teru [0] (n=teru@KD059133115245.ppp.dion.ne.jp) 13.31.20 Join petur [0] (n=51a46563@rockbox/developer/petur) 13.32.39 Quit teru (Client Quit) 13.33.14 Join teru [0] (n=teru@KD059133115245.ppp.dion.ne.jp) 13.33.43 # jae: I must say that if you don't mask your real name on IRC I don't see why you would object to the wiki real name policy :) Anyway, it's your decision... 13.34.33 # irc whois names don't show up in google 13.37.10 # true 13.37.50 Quit faemir (Read error: 54 (Connection reset by peer)) 13.42.07 Join faemir [0] (n=faemir@78.33.109.163) 13.45.33 Quit faemir (Read error: 104 (Connection reset by peer)) 13.46.00 Join faemir [0] (n=faemir@78.33.109.163) 13.49.44 Join Jaykay [0] (n=chatzill@p5DDC5A51.dip.t-dialin.net) 13.50.28 # My real name shows up in google (of course it's on the JaE page) 13.51.20 # hi... the manuals are broken (at least i think they are) 13.51.28 # And since I can't really give my real name (as wiki names don't like umlauts or anything non-ascii... right?), I wanted to use my usual short 13.51.30 # they're not shown in the manuals list 13.51.46 # But whatever... 13.52.42 # Jaykay: we know ... ;-) 13.53.00 # ok, sorry :) 13.53.20 # I'm looking into this right now, but haven't figured whats the problem. My manual build setup is outdated :( 13.53.37 # hehe, no problem. Better than nobody noticing it 13.58.50 # bluebrother: were they broken for a longer time? because in daily/manual there are not even older versions 14.00.55 *** Saving seen data "./dancer.seen" 14.01.30 # Jaykay: no idea, I just figured today. Still wondering why they are broken. 14.03.54 # hmm, that radio feature for the remote tuner on Ipods seems to be at least part of the problem. 14.04.39 # bluebrother: what/where? :) 14.06.10 # the Ipods now have the feature "radio" enabled, but some key action macros are missing. 14.08.07 # this certainly seems to say iram is not cached: http://daniel.haxx.se/sansa/memory_controller.txt-0 14.08.28 # but then why should a smaller LUT with more setup ops be faster? 14.09.37 # jae: Using the asciified version of your name is perfectly fine 14.10.53 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 14.11.02 Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) 14.11.14 # bluebrother: then they would be broken for a really long time :) i cant find such a commit in the last few days 14.12.08 # hmm, seems r23805 broke it. At least it builds again for the Ipod4G if I add keymap stubs 14.12.25 # would be 11 days 14.14.01 # how does the radio screen look on Ipods with FM remote? 14.14.51 Join DerPapst1 [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) 14.16.46 Quit AndyIL () 14.20.14 Quit liar (Read error: 113 (No route to host)) 14.25.04 Quit petur ("real life") 14.31.52 Quit DerPapst (Read error: 110 (Connection timed out)) 14.32.22 Join DerPapst [0] (n=DerPapst@p4FE8FEF6.dip.t-dialin.net) 14.34.12 # New commit by 03bluebrother (r23873): Make manuals for Ipods with remote tuner build again. ... 14.38.04 # rasher: not for me, sorry ;) 14.39.53 Quit DerPapst1 (Read error: 60 (Operation timed out)) 14.40.36 # bluebrother: i think this didn't fix it 14.40.58 # Anyone know what I did wrong? Player's rockbox says it's r23863, but I did install r23680. And the files in .rockbox are of today, and not yesterday. 14.41.13 # jae: you wanted to get writing access in the rockbox-wiki, right? 14.41.26 # jae: maybe you didnt overwrite the files... 14.41.50 # Jaykay: yes? 14.42.06 # jae: then you should accept the rules of the wiki... 14.42.19 # which are, use your real name as wikiname. 14.42.22 # Jaykay: Doesn't rbutil do that? Didn't do it manually... 14.42.39 # then try it manually 14.42.40 # Jaykay: not the past tense... 14.42.45 # *note 14.42.47 # hrm, part of it might be that gcc does unsigned x & 0xffff0000 in a rather braindead way... 14.43.19 # Jaykay: well, looking at the .rockbox dir it seems the files *were* overwritten. 14.43.57 # jae: just do it manually again 14.45.39 # should short select in the wps on e200 brng me to the file browser, database or the one which was opened last? 14.45.52 # *bring 14.49.21 # Now it worked (just redid the upgrade with rbutil)... 14.49.24 # Weird 14.49.47 # FlynDice: and it now detects the SD on boot, so the fix *did* work it seems :D 14.49.54 Join DerPapst1 [0] (n=DerPapst@p4FE8EB68.dip.t-dialin.net) 14.50.51 # Jaykay: why not? 14.52.30 # New commit by 03teru (r23874): Correct checking return value of open in plugins. 14.58.56 # * bluebrother spots that it's not the 12th today but the 6th 15.01.03 Quit DerPapst (Read error: 110 (Connection timed out)) 15.02.43 # bluebrother: did you catch the discussion about the mkamsboot message when trying rbutil on the latest fuze firmware? 15.04.19 Join kugel [0] (n=kugel@rockbox/developer/kugel) 15.05.03 # teru: I don't think the search.rock change is correct 15.05.58 # hm, nevermind, I read strchr not strrchr 15.10.07 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 15.10.07 # bluebrother: when are the manuals built again? 15.12.08 Join Lss [0] (n=Lss@cm91.delta92.maxonline.com.sg) 15.12.13 # topik: yes, spotted the message. Haven't thought about it yet though. 15.13.00 # Jaykay: the manuals are build somewhen in the night. So unless there still is something wrong (spotted a typo in my commit -- urgh) we should get them back tomorrow 15.13.49 # there's probably not a whole lot to think about it :). i assume it needs a new version to fix it, and then you will probably include the version that supports the latest fuze firmware 15.14.24 # bluebrother: so there's no way to check them without building them "manually"? 15.14.43 # Jaykay: just build them all. That's what I'm doing right now :) 15.15.40 # but there's no trigger for building them on the server, or some kind of build system. The swedes could trigger a build on the server. 15.15.55 Quit linuxstb ("Leaving") 15.16.39 # bluebrother: there were more manuals broken than the ipod-manuals... so why should the fix fix it? :) 15.18.40 # this doesn't necessarily mean they are broken -- if the build script simply hangs and gets killed a couple of hours later other manuals might be skipped too. LaTeX can hang with a prompt, and if that happens it's kinda problematic when running from a script 15.19.09 # bluebrother: ok, thanks :) 15.20.03 # I'm a bit surprised though that at least my script hangs. LaTeX should run in nonstopmode for the manual, which means it should simply error out instead of waiting for user input. 15.20.23 Quit CIA-6 (niven.freenode.net irc.freenode.net) 15.20.23 NSplit niven.freenode.net irc.freenode.net 15.20.23 Quit FOAD (niven.freenode.net irc.freenode.net) 15.20.23 Quit kadoban__ (niven.freenode.net irc.freenode.net) 15.20.23 Quit n17ikh (niven.freenode.net irc.freenode.net) 15.20.23 Quit solexx (niven.freenode.net irc.freenode.net) 15.20.23 Quit Kitr88 (niven.freenode.net irc.freenode.net) 15.20.23 Quit B4gder (niven.freenode.net irc.freenode.net) 15.20.23 Quit yosafbridge (niven.freenode.net irc.freenode.net) 15.20.23 Quit Sajber^ (niven.freenode.net irc.freenode.net) 15.20.23 Quit DerPapst1 (niven.freenode.net irc.freenode.net) 15.20.23 Quit faemir (niven.freenode.net irc.freenode.net) 15.20.23 Quit dmb (niven.freenode.net irc.freenode.net) 15.20.23 Quit jae (niven.freenode.net irc.freenode.net) 15.20.23 Quit TaZzZ (niven.freenode.net irc.freenode.net) 15.20.23 Quit tarbo (niven.freenode.net irc.freenode.net) 15.20.23 Quit gevaerts (niven.freenode.net irc.freenode.net) 15.20.23 Quit mt (niven.freenode.net irc.freenode.net) 15.20.23 Quit FlynDice (niven.freenode.net irc.freenode.net) 15.20.23 Quit killan (niven.freenode.net irc.freenode.net) 15.20.23 Quit Byan (niven.freenode.net irc.freenode.net) 15.20.23 Quit loyx (niven.freenode.net irc.freenode.net) 15.20.23 Quit JdGordon (niven.freenode.net irc.freenode.net) 15.20.23 Quit preglow_ (niven.freenode.net irc.freenode.net) 15.20.23 Quit topik (niven.freenode.net irc.freenode.net) 15.20.23 Quit dionoea (niven.freenode.net irc.freenode.net) 15.20.23 Quit SIGSEGV (niven.freenode.net irc.freenode.net) 15.20.23 Quit Kohlrabi (niven.freenode.net irc.freenode.net) 15.20.23 Quit YPSY (niven.freenode.net irc.freenode.net) 15.20.23 Quit zu_ (niven.freenode.net irc.freenode.net) 15.20.23 Quit jds2001 (niven.freenode.net irc.freenode.net) 15.20.24 Quit Utchybann_ (niven.freenode.net irc.freenode.net) 15.20.24 Quit rvvs89 (niven.freenode.net irc.freenode.net) 15.20.24 Quit Tuplanolla (niven.freenode.net irc.freenode.net) 15.20.24 Quit Torne (niven.freenode.net irc.freenode.net) 15.20.24 Quit xavieran (niven.freenode.net irc.freenode.net) 15.20.24 Quit Kopfgeldjaeger (niven.freenode.net irc.freenode.net) 15.20.24 Quit shodanX_ (niven.freenode.net irc.freenode.net) 15.20.24 Quit tha (niven.freenode.net irc.freenode.net) 15.20.24 Quit Zambezi (niven.freenode.net irc.freenode.net) 15.20.26 Join smogzer [0] (n=quassel@213.13.206.196) 15.20.53 Quit thegeek_ (niven.freenode.net irc.freenode.net) 15.20.53 Quit Topy44 (niven.freenode.net irc.freenode.net) 15.20.53 Quit fxb__ (niven.freenode.net irc.freenode.net) 15.20.53 Quit Unhelpful (niven.freenode.net irc.freenode.net) 15.20.53 Quit crashd (niven.freenode.net irc.freenode.net) 15.20.53 Quit scorche (niven.freenode.net irc.freenode.net) 15.20.53 Quit markun (niven.freenode.net irc.freenode.net) 15.20.53 Quit fish_ (niven.freenode.net irc.freenode.net) 15.20.53 Quit rjg (niven.freenode.net irc.freenode.net) 15.22.25 Join linuxstb [0] (n=linuxstb@94-193-103-239.zone7.bethere.co.uk) 15.22.25 NHeal niven.freenode.net irc.freenode.net 15.22.25 NJoin DerPapst1 [0] (n=DerPapst@p4FE8EB68.dip.t-dialin.net) 15.22.25 NJoin faemir [0] (n=faemir@78.33.109.163) 15.22.25 NJoin FOAD [0] (n=dok@dinah.blub.net) 15.22.25 NJoin kadoban__ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 15.22.25 NJoin dmb [0] (n=Dmb@unaffiliated/dmb) 15.22.25 NJoin n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 15.22.25 NJoin jae [0] (n=jae@HSI-KBW-082-212-058-254.hsi.kabelbw.de) 15.22.25 NJoin solexx [0] (n=jrschulz@e176098107.adsl.alicedsl.de) 15.22.25 NJoin Kitr88 [0] (i=Kitarist@BSN-143-158-207.dial-up.dsl.siol.net) 15.22.25 NJoin B4gder [241] (n=daniel@rockbox/developer/bagder) 15.22.25 NJoin TaZzZ [0] (i=GamingEx@hidden.botpack.eu) 15.22.25 NJoin tarbo [0] (n=me@unaffiliated/tarbo) 15.22.25 NJoin yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) 15.22.25 NJoin gevaerts [0] (n=fg@rockbox/developer/gevaerts) 15.22.25 NJoin mt [0] (n=mtee@rockbox/developer/mt) 15.22.25 NJoin FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 15.22.25 NJoin Sajber^ [0] (n=Sajber@c-c33271d5.012-155-73746f22.cust.bredbandsbolaget.se) 15.22.25 NJoin killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) 15.22.25 NJoin Byan [0] (n=notByan@lackey.csl.mtu.edu) 15.22.25 NJoin loyx [0] (n=men@ool-43554637.dyn.optonline.net) 15.22.25 NJoin JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 15.22.25 NJoin jds2001 [0] (n=jds2001@fedora/jds2001) 15.22.25 NJoin xavieran [0] (n=xavieran@ppp118-209-112-86.lns20.mel4.internode.on.net) 15.22.25 NJoin Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 15.22.25 NJoin shodanX_ [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 15.22.25 NJoin tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) 15.22.25 Join Zambezi [0] (i=Zulu@unaffiliated/zambezi) 15.22.25 NJoin Torne [0] (i=torne@rockbox/developer/Torne) 15.22.25 NJoin Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 15.22.25 NJoin rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 15.22.25 NJoin Utchybann_ [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) 15.22.25 NJoin CIA-6 [0] (n=CIA@208.69.182.149) 15.22.25 NJoin Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) 15.22.25 NJoin topik [0] (i=awesome@wtf.grmpf.org) 15.22.25 NJoin zu_ [0] (n=zu@bucketheaded.eu) 15.22.25 NJoin SIGSEGV [0] (n=user@61.250.113.98) 15.22.25 NJoin dionoea [0] (n=dionoea@yop.chewa.net) 15.22.25 NJoin preglow_ [0] (i=thomj@tvilling2.pvv.ntnu.no) 15.22.25 NJoin YPSY [0] (n=ypsy@geekpadawan.de) 15.22.40 NJoin Topy44 [0] (n=quassel@my.fastsh.it) 15.22.40 NJoin thegeek_ [0] (n=nnscript@s168c.studby.ntnu.no) 15.22.40 NJoin fxb__ [0] (n=felixbru@85.214.97.64) 15.22.40 NJoin scorche [50] (n=scorche@rockbox/administrator/scorche) 15.22.40 NJoin Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) 15.22.40 NJoin crashd [0] (i=foobar@lostnode.org) 15.22.40 NJoin rjg [0] (i=rgordon@odie.tomelliott.net) 15.22.40 NJoin fish_ [0] (n=fish@freigeist.org) 15.22.40 NJoin markun [50] (n=markun@rockbox/developer/markun) 15.23.31 # New commit by 03bluebrother (r23875): Add missing closing bracket. No idea how that got lost, I'll blame the keyboard. 15.24.51 # bluebrother: a stupid question: why didn't you commit FS#5737? 15.25.13 # it saves the scratchpad in sudoku 15.25.35 # ah, that one. I'd need to resync it first. 15.27.41 # ...well...ok :) 15.27.57 # i just noticed FS#7861 might be out of date 15.28.04 # but I should look at it again :) 15.28.32 Quit dfkt (Read error: 110 (Connection timed out)) 15.32.52 Join patrakov [0] (n=aep@pppoe-0045.urtc.ru) 15.33.47 # hi. how do I use cue files (those that are supposed to apply to whole-disk flac files) in rockbox? 15.34.44 # just play the media file that's accompanying the cue 15.35.10 # ... after enabling cue support in Rockbox 15.35.31 # where is it enabled? 15.35.36 # patrakov: the cue sheet needs to have the same base file name (i.e. excluding extension) and you need to explicetely enable cue sheet supprt 15.35.58 # it might be in playback settings, not sure though 15.36.00 # patrakov: The manual should describe the details. 15.36.37 # thanks 15.36.48 # the only problem is that the manuals are currently broken :) 15.37.00 # bluebrother: All of them? 15.37.03 # * bluebrother might have svn builds online in a couple of minutes 15.37.25 # linuxstb: not all but most. AFAICS the building stopped somewhere in between. 15.38.53 # patrakov: But just browse the menus, I'm sure you'll find it... You then need to turn your DAP off and on again for the setting to take effect. 15.39.54 # found it 15.41.01 # and it works 15.45.41 # ok, some svn manuals are up until the official ones are rebuilt: http://www.alice-dsl.net/dominik.riebeling/rockbox/ 15.47.25 Join robin0800_ [0] (n=quassel@general-kt-199.t-mobile.co.uk) 15.49.06 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 15.50.26 Quit robin0800 (Read error: 60 (Operation timed out)) 15.51.41 Quit teru ("Quit") 15.59.49 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 16.00.48 Quit mc2739 ("leaving") 16.00.58 *** Saving seen data "./dancer.seen" 16.03.20 Join Tomis [0] (n=Tomis@70.134.93.64) 16.05.10 Join mc2739 [0] (n=mc2739@rockbox/developer/mc2739) 16.10.16 Join alex` [0] (n=user@client-86-31-144-85.watf.adsl.virginmedia.com) 16.10.25 Join FOAD_ [0] (n=dok@dinah.blub.net) 16.14.08 Join merbanan [0] (n=banan@c-94-255-215-42.cust.bredband2.com) 16.21.00 Join cluemore [0] (n=bc65b886@giant.haxx.se) 16.22.04 # Hello everyone! I just found Rockbox and it seems to rock. One question: Can Rockbox be easily configured to delete the currently playing song? 16.22.22 Quit Jaykay (Remote closed the connection) 16.22.40 Quit FOAD (Read error: 110 (Connection timed out)) 16.22.40 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 16.23.31 Quit patrakov ("Leaving.") 16.24.42 Join ansuz [0] (n=ansuz@dsl093-172-019.pit1.dsl.speakeasy.net) 16.24.58 # does anybody know? 16.25.10 Join Jaykay [0] (n=chatzill@p5DDC5A51.dip.t-dialin.net) 16.26.17 # cluemore: how about context menu of wps (thats long select on e200) and then delete? 16.27.01 # thanks Jaykay, wps? 16.27.05 Quit stoffel (Remote closed the connection) 16.27.15 # I found the emulator .. I 16.27.20 # while playing screen 16.27.22 # will try 16.27.57 # cool, If that works I will buy a supported player. Any recommendations? (real cheap for jogging) 16.28.30 # deleting songs I dont want to hear while jogging is THE killer feature for me 16.28.51 # i don't know many players, but i think the sansa clip is quite cheap 16.28.56 # and nearly supported 16.29.04 # nearly :) ? 16.30.14 Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) 16.30.16 # cluemore: afaik some features as recording are missing, but it is working 16.30.32 # *like recording 16.31.13 # cool thanks so much Jaykay. You guys seem to do an amazing job. Keep up the great work .. I will go play with the emulator now. Cheers 16.33.17 # cluemore: if you have any further questions, just ask here :) 16.34.56 # bluebrother: if you want to close another FS task, FS#8025 is also out of date 16.35.21 # i think the "searching..." is now gone or displayed only very short 16.36.41 # thanks Jaykay, I tried the sansa clip emulator and deleting works, but it still ask for Yes and No etc. How complex is changing that behavior. Is it configurable or hardcoded in the source code? 16.37.40 # cluemore: i think thats "hard-coded"... i think double-pressing the select-button is not that hard ;) 16.37.58 # as an alternative you might learn C and create a patch for that :D 16.38.56 # hmm :) .. well I have to long press SELECT then scroll down to delete and then double-press .. 16.39.14 # while jogging that is kinda cumbersome 16.39.49 # true 16.40.34 # but nobody wants a delete without a yes/no question... the cahnce that you delete a file by accident is too high 16.40.48 # *chance 16.41.18 # cluemore: you could just use skip? 16.41.24 # ack, I know that I have a very special itch to scratch here .. 16.42.32 # robin0800_: he wants to *delete* a song... 16.42.34 # cluemore: well I always sync mine against a backup on a computer 16.42.34 # robin0800, well the idea is to just dump mp3 an my player and listen to them while jogging and delete everything that I don*t like .. so I evolve my perfect running sound 16.44.18 # that is actually so important to me that I might dive into the code ;) .. is compling and installing ones own build very complicated? 16.44.40 # Jaykay: does the database keep a list of skipped songs in its play count? 16.45.18 # cluemore: which OS do you use? (windows/linux/mac/whatever) 16.45.29 # robin800_, that would be a clever solution :) 16.45.30 # robin0800_: i don't think so 16.46.05 # I run everything .. Kubuntu on the netbook and Debian on the desktop ( I have OSX and Windows too) 16.46.17 # cluemore: no, it wouldn't... because about 2 people would need it :) 16.46.22 # Jaykay: so you could use that to find ones skipped? 16.46.58 # robin0800_: afaik the database does *not* keep a list of skipped songs... 16.48.03 # cluemore: http://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling 16.48.08 # But last.fm log does 16.48.22 # Sort of... meaning, you could use it for it 16.49.04 # Because "skipped" means "pressed 'go to next' shortly after it went on" 16.49.26 # jae: have fun with writing a program which extracts skipped songs out of a scrobbler-log, then finds them on your mp3-player and delets them 16.49.38 Join gentgeen__ [0] (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) 16.49.54 # Jaykay: that's really just a SMOP 16.50.12 # jae: then do it 16.50.39 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.51.01 # As last.fm (or the submit tools, don't know where it's done) already filters "skipped"... you have to have listened to at least 50% of the song for it to "scrobble" 16.51.14 # I'd do it if I needed it... maybe I will 16.51.21 # One last question, when I enable voice every command selected will be spoken, right? ( That might be really helpful while jogging ) 16.52.36 # cluemore: yes, it will speak the menus and files/folders if set up correctly 16.54.26 # Is there a way to check the status of the DB update (since it happens in the background). Or can one pull it to fg, for that matter? 16.54.44 # voice does not work in the emulator, right? 16.57.44 Join kugel_ [0] (n=kugel@e178107118.adsl.alicedsl.de) 16.58.19 # Jaykay: I don't think FS#8025 is out of date 16.58.20 Join klapaucjusz [0] (n=jch@88-121-49-75.rev.libertysurf.net) 16.58.20 # New commit by 03mcuelenaere (r23876): Boomshine: ... 16.58.25 # Hi. 16.59.01 # Anyone willing to review FS#10832 and FS#10833, in a view to committing them? 16.59.12 # That's a total of four patches. 16.59.13 # kugel_:why not? 16.59.28 # FS#10832 is about supporting correct but unstreamable mp4 files. 16.59.34 # I think it still happens 16.59.46 # FS#10833 is about not crashing on a certain class of broken mp4s. 16.59.51 # it's hard to reproduce but I seem to remember experiencing this once in a while still 17.00.12 # and I actually think it's the very same bug as the one after leaving some plugins 17.00.30 # kugel_: i know that i got the "searching..." message quite often a few months/a year ago, and now i don't get it... 17.00.31 # (Sorry, a total of 5 patches) 17.01.17 # the bug is not the splash messages, but that the scrollwheel doesn't work if you press a button while that splash 17.01.34 # ahh fark .. I will just hop on amazon and buy the Sansaclip :) Longpressing SELECT UP UP SELECT SELECT isn't that bad :) 17.01.35 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 17.02.03 # and I fixed the logic of that splash, it was intended to show up only after the search takes more than half a second 17.02.12 # thanks again, you guys rule :) Cya 17.02.21 # it didn't follow that logic but does now 17.03.41 Quit robin0800_ ("http://quassel-irc.org - Chat comfortably. Anywhere.") 17.04.00 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 17.05.50 # kugel_: aaaah, now i know.... that also "works" with usb-mode 17.05.58 Quit cluemore ("CGI:IRC (EOF)") 17.07.40 # kugel_: wasn't there another task for that? 17.08.11 Quit kugel (Read error: 113 (No route to host)) 17.09.49 # * klapaucjusz is feeling ignored 17.11.24 # I think so yes 17.14.54 Quit kugel_ ("exit(0);") 17.15.09 Join liar [0] (n=liar@83.175.83.185) 17.25.04 Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) 17.28.40 Join n1s [0] (n=n1s@rockbox/developer/n1s) 17.30.53 # FS#8025 and FS#7332 are the same so i suggest closing the first of them 17.33.57 Join Tomis2 [0] (n=Tomis@70.134.93.50) 17.37.56 # Should simulator build DEBUGF's go to standard out or are they for target builds only? 17.41.17 Quit Tomis (Read error: 110 (Connection timed out)) 17.41.18 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.93.50) 17.41.37 # klapaucjusz: Maybe try the mailing list? 17.42.01 # klapaucjusz: BTW do you publish your GIT tree? 17.44.45 # alex`: DEBUGF works for sim 17.46.37 # alex`: no, I don't. 17.46.44 Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) 17.46.58 # And I'd rather not subscribe to Yet Another Mailing List. 17.47.04 # Any chance you could do it for me? 17.48.47 # klapaucjusz: OK, I'll I'll send and email 17.48.56 # By the way, Alex, perhaps you know what's the situation with FAAD. 17.49.09 # The latest version is pure GPL, so it should be able to go into RB. 17.49.47 # The old version that's in RB has a number of known bugs (ringing at low bitrates). 17.56.13 # klapaucjusz: I'm afraid my knowledge of FAAD is limited to hacking around with the metadata, most of which was just to work with my other halfs m4a's (I use ogg). 17.56.55 # klapaucjusz: But I don't see any reason why the latest couldn't be ported in, however I don't know how hacked the original was to fit it into the rockbox codec style 17.57.32 # is it gplv2 r v3? 17.57.36 # or* 17.58.00 # 2 or later 17.58.44 # As published in June 1991. 17.58.47 # Looks ok to me. 17.58.48 # Sounds like apps/codecs/libfaad/README.rockbox is out of date then? 17.59.24 # Indeed. Hold on, I'll find you a ref. 18.00.37 # alex`: well, it's mostly correct just they changed it back again 18.01.01 *** Saving seen data "./dancer.seen" 18.02.14 # http://www.audiocoding.com/faad2.html mentions gplv2 now 18.02.17 # klapaucjusz: Most of the compile stuff seems to be in svn r7700 and doesn't look that scary. It may be the best thing to do is do a CVS diff of the libfaad tree between the Rockbox snapshot and now and then seen if that will apply (modulo rockboxisms) 18.04.26 # alex`: or use git to do the merge. 18.04.50 # I'd really rather use a 3-way merge. 18.12.47 Join hannesd [0] (n=hd@HSI-KBW-095-208-052-100.hsi5.kabel-badenwuerttemberg.de) 18.16.03 Quit niekie (Remote closed the connection) 18.16.27 Join niekie [0] (i=quasselc@CAcert/Assurer/niekie) 18.16.40 Quit liar (Read error: 113 (No route to host)) 18.17.30 Join Kitar|st [0] (n=Kitarist@BSN-61-87-230.dial-up.dsl.siol.net) 18.27.24 Join liar [0] (n=liar@83.175.83.185) 18.35.32 Quit Kitr88 (Connection timed out) 18.35.51 Join Kitr88 [0] (i=Kitarist@BSN-142-77-103.dial-up.dsl.siol.net) 18.39.05 Quit Kitar|st (Connection timed out) 18.40.48 Quit saratoga (niven.freenode.net irc.freenode.net) 18.40.48 NSplit niven.freenode.net irc.freenode.net 18.42.30 Quit hannesd (Read error: 110 (Connection timed out)) 18.42.31 NHeal niven.freenode.net irc.freenode.net 18.42.31 NJoin saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 18.43.00 Quit tha (Remote closed the connection) 18.43.18 Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) 18.45.42 Quit robin0800 (Remote closed the connection) 18.47.41 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 18.48.15 Quit tha (Remote closed the connection) 18.48.16 Quit saratoga (niven.freenode.net irc.freenode.net) 18.49.25 NJoin saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 18.53.01 Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) 18.53.02 # would allow one WPS to work on multiple targerts with the same screen resolution but different volume ranges > 0dB 18.53.33 # Don't they already? 18.53.46 Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) 18.53.52 # I thought if the range goes >0db the last part of the conditional is just ignored. 18.53.57 # Er *doesn't* go >0db 18.54.04 # i belive so 18.54.08 # I'd assume so 18.54.20 # .me checks 18.54.30 # I believe the claimant's problem in this theoretical case was no resolution > 0dB 18.54.47 # there sholdnt be 18.54.57 # So if you have , f only shows up on targets that go greater than 0db, e is always *only* 0db, a is always mute, and b,c,d are divided evenly up for the volume range below 0db 18.55.07 # as in there shouldn't be with the current tag, or there shouldn't be ever, JdGordon ? 18.55.13 # I think we shold shut him up with "By design" 18.55.39 # soap: How do you propose to add resolution above 0db then? I misunderstood something along the way. 18.56.22 # soap: both.. although I'd like to limit all my targets to 0d 18.56.26 # dB if i could 18.56.34 # >0 is baaad 18.56.58 # JdGordon1: i think that suggestion has been shut down many times :) 18.56.59 # I was just playing with his idea of an output-power-agnostic 0-100%... and saying that IF you modified his proposal and had the tag return something different for values > 0 dB you would kill two birds with one stone. 18.57.04 # bird one being his desire 18.57.22 # bird two being the fact that the current tag has no resolution at volumes > 0dB IIUC. 18.57.23 # soap: Return something different? 18.57.47 # I mean it's a conditional tag, so it just looks like ?pv0db> 18.57.55 # Llorean, ie the theoretical players I mentioned in the other room. 18.58.06 # shot down, even 18.58.18 # Yeah, but how would you modify that line in a way that it allows multiple images above 0db? 18.58.34 # Basically, how do you have two arbitrary length segments in a <|> block? 18.58.37 # i don't really understand why people are opposed to an optional volume limit though 18.58.43 # soap: sure, but I think both birds arnt worth the effort... it means adding a new tag for it.. you cant overload the %pv to do it 18.58.48 Quit tha (Remote closed the connection) 18.58.48 # Having one is pretty easy since you have a fixed number of values before and after the arbitrary length section 18.58.49 Join toffe82 [0] (n=chatzill@75.3.221.27) 18.59.23 # by returning a different value based on the capabilities of the player one WPS could serve two hardwares, one with green bars 0-100 and one with green bars 0-80 and red bars 81-100 (for example of a player which crosses the 0 dB boundary at 80% of range) 18.59.33 # n1s: did you figure out your menu question? 18.59.42 # soap: What do you mean by "returning"? 18.59.57 Join CaptainKewl [0] (n=jason@64-121-176-61.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 19.00.04 # WPS tags don't have a concept of what the actual volume range is. 19.00.07 # soap: OH, you want to only change it for targets without the >0 volume? 19.00.15 # the WPS looks for image X or image Xn if the volume is > 0dB. 19.00.25 # Llorean, 19.00.33 # JdGordon: yes, i got the menu item to disappear when it shouldn't be shown but it led to a deeper problem that i didn'ẗ solve 19.00.53 # and if Xn isn't available it goes ahead and uses image X 19.01.14 # also the menu was abit weird, a left press would exit the menu, not just go up a level 19.01.15 # soap: WPSes allow arbitrarily named image files. Might even be a bitmap strip. 19.01.25 # so? 19.01.33 # you can still add a prefix. 19.01.43 # regardless of how the file is named, or which strip is used. 19.01.50 # n1s: more info if you want help :) 19.02.17 # n1s: i think now there should be just one modes/flags value. also that BS_0_X is as clear as _DONTCARE and can be default. did we ever figure out if av_log2 can see a 0, and if the result matters? 19.02.19 # soap: If the tag is where does the prefix go? 19.02.25 # if the second strip (or image) is there it would use that for > 0dB volumes. 19.02.29 # Or if the tag is ? 19.02.40 # (I should have said suffix) 19.02.46 # Well, suffix too 19.02.47 # JdGordon1: i'll ping you if i decide to look at it again :) 19.03.01 # email me if im not around 19.03.25 # Llorean, this would be his 0-100% idea. 19.03.37 # flac has a lead-zero-count, also, right? i think the only "personalities" i'll worry about for now are BS_LOG2 and BS_CLZ. BS_CTZ could be added if anything needs it 19.03.56 # mute would be the first image (or first strip position) and "full" would be the branch point. 19.04.16 # soap: What do you mean by "branch point" in terms of WPS tags? 19.04.24 # What would the actual tag for this look like? 19.04.28 # Unhelpful: no i don't know if it ever gets a 0, that it worked even when 0 gave a value of -1 suggests it is at least uncommon for flac 19.04.35 Join GeekShado_ [0] (n=Antoine@104.190.204-77.rev.gaoland.net) 19.04.42 # soap: That's what I'm trying to understand - how you would write this in a WPS tag. 19.05.07 # just like the current one. 19.05.29 # %?pv<%?"gt0"|mute|strip...> ? 19.05.37 # except: no mute image, no caution image. 19.05.52 # just the strip or list of arbitrary images. 19.05.56 # Unhelpful: alac calculates leading zeroes, don't think flac does 19.06.27 # soap: So it just divides the images across the whole volume range, and if the volumes are above 0db it uses a secondary automatically selected alternate version of the image (if present)? 19.06.28 # the difference is that when the player is at >= 0 dB the WPS looks for IMGSTRIPx instead of IMGSTRIP 19.06.35 # right 19.07.08 # soap: if you want to add resolution >0 the way to do that would be add a token like above and use that for the conditional for the >0 block 19.07.09 # the alac clz has an optimization that only tests for set bits in the lower 16 though 19.07.17 # soap: It seems like that might create some odd effects between targets 19.07.24 # Llorean, example? 19.07.29 # soap: One target might have three bars of yellow and two of red, while another has five bars of yellow. 19.07.41 # Assuming each bar is 20% volume, for example, and it goes way beyond 0db. 19.07.45 # correct 19.08.21 # and is that not showing the user exactly what is going on w/o resorting to numerical representation? 19.09.11 # I dont understand "(10:06:30 AM) soap: the difference is that when the player is at >= 0 dB the WPS looks for IMGSTRIPx instead of IMGSTRIP" at all... remember the conditional values can be anything.. including other conditionals 19.09.14 # soap: I'm not really sure 19.09.35 # soap: Does it show an alternate image *immediately* upon crossing the 0db mark (possibly swapping img5 with img5x)? 19.10.11 # JdGordon1: I can only see it working with strips, since they're handled specially for arbitrary length conditionals right? 19.10.42 # the pv doesnt take a strip name.. it takes a "value" for each image you want to display 19.10.56 # Ah, I thought it could use a strip name for the part between mute and 0db 19.11.00 # no 19.11.03 # Ah well 19.11.04 # NEver mind then 19.11.25 # that would be nice though 19.11.25 # JdGordon1: Well his proposed one is a second tag that is *just* an arbitrary length conditional 19.11.29 # So it should be able to take a strip name. 19.11.49 # strips can only go up to 26 values i think... 19.11.51 # or 52 19.12.39 # JdGordon, being a conditional for other tags (vs loading of images) is not a case I considered. 19.12.39 # and there is a very big difference between %?xx and %? in the skin handling code 19.13.09 Join pamaury [0] (n=pamaury@88-123-149-12.rev.libertysurf.net) 19.13.21 # soap: That was part of what I was trying to understand is how the tag would "know" things about the images. 19.13.54 # n1s: was it alac? :/ 19.14.22 # adding a token to the current tag appears (at first glance) to be problematic. For if you don't know the numerical range of your target, how do you decide how many steps to create from mute to 0 and how many steps do you create from 0 to max? 19.14.27 # Unhelpful: yeah alac was the first place i used the __builtin_clz 19.14.31 # I can see it working if it *requires* a strip. And if a target had a range of ~80 going up to +6 (Clip and similar I think) and a max of 52 images that'd still be 3-4 images for the >0 range adding some degree of extra precision 19.14.36 # Still, that's if you use *52* volume images. 19.14.42 # Unhelpful: why :/ ? 19.14.46 # If you use a more reasonable 10-15 there's no benefit on our current tag. 19.14.57 # You're forced to either code for specific targets (not specific resolutions) or live with the two sides of the scale being out of balance. 19.14.59 # n1s: just my memory going. ;) 19.15.06 # soap: What do you mean? 19.15.32 # faad also calculates leading zeroes too 19.15.40 # s/also// 19.15.54 # soap: Our current tag doesn't require a knowledge of steps. It's basically 19.15.59 # Llorean, wasn't JdGordon proposing to add an additional token to the current tag to cover the > 0dB range the same way the <0dB range is covered? 19.16.01 # you mean wl_min_lzc? if you look at what it actually calculates it's log2 + 1... 19.16.14 # soap: I don't think so. 19.16.15 # * JdGordon1 butts in with technical issues 19.16.37 # soap: if you want to add resolution >0 the way to do that would be add a token like above and use that for the conditional for the >0 block 19.16.38 # and then both callsites do if(result) result--; 19.16.39 # 1) any token needs to be able to go anywhere any other token can go (so as values in conditionals) 19.16.55 # soap: Ah, missed that somehow. 19.16.56 # 2) an image strip displayer token would need to be added to do what you want 19.17.06 # Unhelpful: aha 19.17.18 # 3) 2 is impossible (right now at least) because one token cant know the value of another token 19.17.26 # it doeesnt work that way! 19.17.54 # soap: I dont see the problem of having the scales differ... 19.17.59 # soap: Still, if you build an image 26 pixels wide for (mute to 0) and 4 pixels wide for (0 to max) you can divide either image across an arbitrary range of db splitting it evently, but you do end up with 1 pixel of yellow != 1 pixel of red. 19.18.04 # either way its an arbitrary scale 19.18.44 # * Llorean still doesn't quite get why you need resolution above 0db without being exposed to the db value, though. 19.18.50 # if the log2 is 0->0 it can just use log2 and skip the if... although for some reason doing so seems to have *slowed* it.. 19.18.52 # JdGordon, Llorean - correct. The scales on the two sides of 0 won't match if you don't take the specific target into account. 19.18.58 # You can *hear* that the volume's changing, and the numbers above 0db don't serve a realistic purpose. 19.19.16 # that argument can be made for that below 0 as well, no? 19.19.21 # yes 19.19.29 # soap: yes it can, which is why the default WPS uses an image. 19.19.45 # Though I personally need to know where -25 (or approximately -25) is, and the image isn't fine grained enough for that generally 19.19.47 # Depending on target. 19.19.50 # then why selectively use the argument for the >0 case? 19.20.12 # because <0 is important, 0 is important and >0 is important 19.20.49 # the fact is that more targets have more vbalues <0 than >0 so its nicer to give them more informtion there 19.21.06 Quit GeekShadow (Read error: 110 (Connection timed out)) 19.21.11 # we could of course split it down the middle.... 19.21.24 # but that would be stupid :p 19.22.12 # soap: I guess the image doesn't serve much of a realistic purpose in general other than "if it's more than 3/4 full I probably want to turn it down before putting on my headphones" 19.22.29 # As an approximation it's great, but I'm not sure how much fine-grained approximation you ever need that we'd need to add more detail above 0db 19.23.25 # I don't know how many people frequently use the range > 0dB, I was just attempting to toss around an agnostic solution which didn't discriminate based on the 0dB threshold while still respecting it enough to show it. 19.23.46 # klapaucjusz: Looking at FS#10832, do I understand correctly that it's still causing the codec to seek to the end of the file and hence cause a rebuffer? (the main objection to FS#10160 IIUC) 19.23.54 # JdGordon1: Could a conditional be made to accept to single images, or two strips? 19.24.06 # no 19.24.12 # single image yes... strips no 19.24.13 Quit pixelma (Nick collision from services.) 19.24.15 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 19.24.19 # read technical butting in above 19.24.27 Quit amiconn (Nick collision from services.) 19.24.31 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 19.24.35 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 19.24.45 # JdGordon1: none of those three points say anything about a tag not accepting two strips 19.24.46 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 19.24.58 # JdGordon1: I'm thinkingg like a vs? tag (volume safe) that's a conditional for Yes and No (<=0db, >0db) 19.25.05 # strips are something that would be nice, but technically nodo right now 19.25.16 # Don't we already do strips? 19.25.39 # not to my knowledge... we do strips but each image needs to be drawn individually 19.25.47 # linuxstb: no. 19.25.51 # I mean, sometimes. 19.26.01 # JdGordon1: Maybe I"m thinking of some patch 19.26.07 # probably 19.26.13 # (1) for a proper streamable mp4 (the only kind we support right now), we behave just like now. 19.26.43 # (2) for an unstreamable mp4 (the kind that has the moov chunk after the mdat chunk), it will cause a seek and possibly a rebuffer. 19.26.58 # JdGordon1: I seem to recall a patch that, for certain tags, could just take a strip and divide its sub-images across however many values the conditional has (or if arbitrary, use as many values as there are images in the strip) 19.27.02 # So there is no regression -- the only case where we're inefficient, is the case that's not supported at all right now. 19.27.12 # once again, we dont want to force token knowlegde on another token.. we dont want to add dependancies between tokens... and one cant find out the value of another 19.28.01 # See the code in demux.c around line 19.28.33 # Sorry, demux.c around line 767, in the patch called "Support for unstreamable AAC (mp4) files." 19.28.55 # Llorean: yeah, I think i remember it also.. but thats something that may be nice, but imho not wanted 19.29.30 # JdGordon1: Fair enough 19.29.42 # Okay then. 19.29.45 # You need two tags. 19.29.53 # but adding a token to say if its >0 and by how much would be fine 19.29.59 # linuxstb: do you want me to add the above explanation to the ticket? 19.31.00 # JdGordon1, soap: How about two tags. A full-range percent volume, and a "is it safe?" volume tag. So for the swapping between alternate images, you use %vs<%percent using yellow images | %percent using red images> 19.31.04 # klapaucjusz: You could do, but that's what I understood anyway (I was just double-checking). So the problem Lear mentioned in his comments to FS#10160 still exists... 19.31.06 # So you get soap's "switch upon crossing 0" 19.31.12 # but neither tag has to know about the other ones 19.31.54 # Interesting idea - but no need to sell me. ;) I was just kicking the can around trying to envision a mutual solution. 19.32.16 # soap: Well, I was just trying to figure out how to address that "need" within existing limitations. 19.32.57 # linuxstb: I don't understand. 19.33.08 # What lear pointed out was a regression. 19.33.24 # There is no regression in this code. 19.33.54 # For unstreamable files, there is a single seek (i.e. one forward, one backwards) at the beginning of playback. 19.34.17 # The single seek is used to parse the metadata, which is then buffered for the rest of the track. 19.34.30 # There is no seeking during playback, just the one initial seek. 19.34.34 # klapaucjusz: No, it may not be a regression, but it's not the way we want it to be implemented. And no, it's not a seek, it's an "advance_buffer", which causes the buffering code to potentially discard what has been loaded. 19.34.35 # Llorean: imo.. overkill 19.34.44 # * JdGordon1 really doesnt see the problem with the current token 19.34.45 # Isn't that just the strategy that lear suggests? 19.35.01 # Okay, so how do you want it to be implemented? 19.35.06 Join Tomis2 [0] (n=Tomis@70.134.97.99) 19.35.44 # klapaucjusz: No. There's a difference between the metadata code reading/seeking (it has direct access to the file descriptor and uses disk I/O) and the codec itself reading/seeking (it uses the audio buffering API). 19.36.32 # klapaucjusz: The idea is that the metadata parser would read the required data from the end of the file, and store that somewhere for the codec to use, so the codec doesn't need to seek again to the end of the file. 19.36.39 # I see. 19.36.42 # No problem. 19.36.47 # Where do I put it? 19.36.54 # klapaucjusz: That's the problem ;) 19.37.13 # linuxstb: have you seen FS#10690, iirc you originally ported alac? 19.38.02 # An alternative would be to allow the codec to do open/lseek/close on the file underlying the buffered stream. 19.38.31 # klapaucjusz: Not really, as that would mean spinning the disk up (on hard disk targets). 19.38.54 # I think we'll have to live with that. 19.39.22 # Unless we stash the full mp4 metadata permanently with the RockBox metadata, we are going to spin up the disk when reading an unstreamable mp4. 19.39.27 # There's just no way around it. 19.40.25 # (And we don't want to hold on to the mp4 metadata -- it can be very large.) 19.41.01 Join tha [0] (n=philippk@ccc2.rbg.informatik.tu-darmstadt.de) 19.41.50 Quit shai (Read error: 60 (Operation timed out)) 19.42.55 Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) 19.45.36 Join portwolf [0] (n=portwolf@unaffiliated/portwolf) 19.45.40 # hey ppl 19.46.05 Quit tha (Remote closed the connection) 19.46.44 # ive got an ipod video 30 gig, trying to get down the install manual from your page i saw that the links are dead, how come? and where could i get them? 19.46.50 # klapaucjusz: Disk I/O isn't even in the (playback) codec API. Hopefully Lear will see your patch and comment on it - I'm sure he has ideas about how to do this nicely. 19.46.55 # i am using linux (arch) here 19.47.12 # portwolf: What links? The links to the manual? 19.47.17 # FWIW I don't think its worth leaving one set of m4a's unplayable because there is a theoretical better solution w.r.t. seeking if "normal" m4a's are unaffected 19.47.26 # linuxstb: yes 19.47.42 # http://www.rockbox.org/manual.shtml <- those links 19.47.59 # see for yourself: click on "online" below the ipod video sign 19.48.01 # Yes, we know about that. Try this - http://www.alice-dsl.net/dominik.riebeling/rockbox/rockbox-ipodvideo-r23875-091206.pdf 19.48.28 # big thanks! 19.48.30 # (the official versions should be fixed tomorrow) 19.48.38 # alright 19.50.26 # perhaps manual should be part of the build system :) 19.51.11 Quit Tomis (Read error: 110 (Connection timed out)) 19.51.11 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.97.99) 19.51.24 # it should, broken manual builds are often undetected for quite some time 19.52.38 # Plus not delete the old one if the new build fails... 19.52.56 # linuxstb: while I have your ear, could you please give me write access to the wiki? Username is JuliuszCh. 19.53.13 # * Unhelpful is very confused by this, and wondering if he's wrong somewhere about what he built and tested 19.54.01 # klapaucjusz: You're supposed to use your full name. 19.55.06 # And in addition, could you please commit the two patches in FS#10833, which should be uncontroversial. 19.55.25 # Llorean: it's rather long. I've already compromised, I usually like to use the username jch. 19.55.58 # klapaucjusz: Didn't you think you should ask if you could have an exception before unilaterally deciding to compromise? Usually a compromise is between two people, not a single person and written rules. 19.56.38 # Llorean: are you trying to be a free software project, or a bureaucracy? 19.56.48 # no 19.57.08 # My personal details are available on my user page, that's the important part, isn't it? 19.57.21 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) 19.57.24 # wl_min_lzc and floor_log2 in faad are both based on the same algorithm, which fills in all bits below the highest set bit, and then does a population count. replacing floor_log2 with with the debruijn-ish version provides a small speedup, replacing it with the new av_log2 after a small fix is faster still, but replacing wl_min_lzc slows things down again :/ 19.57.35 # klapaucjusz: If you're not afraid of making them available, why didn't you simply use your whole name like it asked? 19.57.46 # hrm, and now i can't duplicate my "good" benchmark :/ 19.58.59 # Llorean: are you actively trying to discourage potential contributors by imposing arbitrary bureaucratic constraints? 19.59.23 # klapaucjusz: No offense but it says something when someone's primary objection to do something is simply the fact that someone asked them to. 19.59.41 # Juliusz, Rockbox just requires that all commits be done with the person's full name, it looks like it is on your website, but it is a bit difficult to track down on the rockbox pages: http://www.pps.jussieu.fr/~jch/ 19.59.48 # Unhelpful: strange, no dircache weirdness this time? :) 20.00.03 # n1s: that was on beast. i don't actually *use* my e200. ;) 20.00.29 # klapaucjusz: The "real names to contribute to the wiki" policy is a long standing one and rather benign. There's always going to be some restriction, so it's *always* going to discourage someone. 20.00.44 # There are other people who will be unwilling to register at all. 20.00.52 # can I get more testing on FS#10824 please? I'm more and more confidant that its good to go in today... 20.00.54 # I don't think it's a written rule that you have to have your full name in the tracker or wiki, but it is needed for a commit and it makes it alot easier to find if it's all in there 20.01.02 *** Saving seen data "./dancer.seen" 20.01.03 # kkurbjun: It is in fact written for the wiki 20.01.08 # It explicitly says not to use initials. 20.01.13 # kkurbjun: It's stated on the registration page. 20.01.36 # JdGordon, I found some more bugs in the patch, I will post them on FS later today, it is looking really good with the latest update though 20.02.04 # Llorean, linuxstb, my mistake 20.02.14 # kkurbjun: sweet.. big bugs or niggly ones? 20.02.22 Join tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) 20.02.44 # bah, splash leaves crap behind 20.02.49 # Folks, chill out. 20.03.22 # they are smaller ones, but plugins are working worse than before, and the album art doesn't display if music is already playing when you switch from none to a theme 20.03.22 # In order to try to contribute to Rockbox, I had to (1) register, (2) provide a valid e-mail address, (3) go through the silly e-mail validation rigmarole. 20.03.26 # Fair enough. 20.03.40 # But once I did all of that, I still have to beg on the IRC channel just to get write access to the wiki? 20.03.49 # klapaucjusz: In order to contribute to Rockbox you need to do none of those. 20.03.51 # And I'm being told that I didn't choose the right username? 20.04.03 # * klapaucjusz gives up on gaining write access to the wiki. 20.04.07 # In order to edit the wiki you need to do all of those, plus establish you're a human being by asking here *and* sign up with a name that meets the guidelines. 20.04.10 # the registration page is clear on RealNames for the wiki 20.04.22 # klapaucjusz: It sounds like you're blaming us because you didn't read it? 20.04.37 # klapaucjusz: I agree it sounds a bit bureaucratic, but every other wiki user has followed that convention, and the wiki admin regularly goes through and cleans up names which are not in FirstnameLastname format. We don't want to make a big deal of it... 20.04.42 # klapaucjusz: if you make a user name with your full name I can add the write permissions 20.05.05 # klapaucjusz: If you'd put in a proper username any one of us would've added it pretty much. 20.05.21 # it couldn't be a weird flash performance issue, could it? doing a few more make install shouldn't impact read speed of files that aren't touched, i'd think... 20.05.36 # * JdGordon doesnt know how to fix the splash garbage issue :( 20.05.39 # JdGordon, yeah, I noticed that spashes are leaivng artifacts now too 20.05.43 # linuxstb: how many contributors did you loose because of that? 20.06.08 # klapaucjusz: Some people want to be anonymous, so we lose those. I don't believe anyone has objected for other reasons, until you ;) 20.06.11 # I've recently had to spend a good while on IRC convincing a serious contributor to register with the bug tracker of a project I work on. 20.06.23 # klapaucjusz: There's no way to quantify that. But it is possible to quantify the work that's had to be done to clean up the wiki in the past causing some of these rules to go into place. 20.06.49 # Many people dislike registering, and most of them will give up after they see the amount of pointless activities you need to go through. 20.07.01 # klapaucjusz: You judge them pointless. 20.07.09 # As I've mentioned, I'm giving up on write access to the wiki, let's please go back to discussing my patches. 20.07.13 # A valid email and verification that a human being is behind them serves a point from other perspectives. 20.07.36 # Folks, sorry for starting this flamewar. 20.07.42 # Let's close it, and go back to discussing code. 20.07.50 # linuxstb: actually one griped about it a day or so ago. but it doesn't come up very often, i think. 20.08.25 # klapaucjusz: it's not a flame war, please don't take it personally 20.08.40 # JdGordon, also, I am not sure about enabling the statusbar when going into plugins, I am getting weird artifacts on the plasma demo on the MR500 target 20.09.02 # it looks like it is still updating the statusbar in the background 20.09.02 # Going back to the code, linuxstb, I see a very unpleasant trade-off. 20.09.17 # i'll check 20.09.45 # Given an unstreamable mp4, we either do the seek, or we use up memory in order to keep the metadata around. 20.09.46 Part portwolf 20.10.02 # klapaucjusz: i think we have some precedent for plugins or user tools to "fix" files that can't play correctly... 20.10.08 # Are there unstreamable MP4s that can't be made streamable? 20.10.12 # it doesn't show on the sim, but I think that is because of the hardware 256 color palette blitting 20.10.45 # * Llorean thinks the best tradeoff is "ignore it gracefully, allow the user to fix it once, and play it efficiently going forward" 20.10.58 # * klapaucjusz disagrees. 20.11.30 # I don't know if my usage of RB is typical, but the main reason for preferring RB to the OF is that it groks any file I wish to throw at it. 20.11.45 # If I were willing to go through a conversion process, I'd be using the OF. 20.11.51 # klapaucjusz: It's not a conversion process 20.12.04 # You shouldn't lose any audio quality, you're just re-positioning parts of the container right? 20.12.15 # I cant see anything in the plugin loader or plasma code which would make me think its updating in the background... 20.12.20 # Llorean: i think i might see a feasible solution... what if the metadata reader could set a flag to put the last N bytes at the start of the buffer? then the codec can read the data it needs first... 20.12.40 # JdGordon, you still have the MR500 around right? 20.12.52 # Unhelpful: So it loads the file, moving parts of it to the start as it comes across metadata? 20.12.54 # It's a conversion process of the container, not of the samples. 20.12.56 # Granted. 20.13.06 # klapaucjusz: Which means there's no reason not to want to do it other than "I can't be bothered" 20.13.12 # There's valid reasons not to transcode files, and many of them. 20.13.21 # if you start playing a song on it with the cleangreen theme and go into the plasma demo you will see the song title periodically scrolling 20.13.31 # Llorean: very well put. 20.13.35 # Llorean: the metada reader would set a field with the number of end bytes to buffer. on load the buffering thread would seek and read those bytes, then resume buffering from start-of-file. 20.13.45 # The reason I use RB is that I can't be bothered with the silly requirements of the OF. 20.14.11 # I think it may be related to plugins without menu's but I can't say for sure 20.14.53 # Unhelpful: Since I don't understand the exact problem, I don't understand what you're referring to there. 20.15.22 # Unhelpful: My objection is more on the general principal of "if a file isn't suitable to be played, it probably makes more sense to make the user aware and let them fix it, than harm their battery life silently" 20.15.33 # I think the reason it is showing in the mr500 is because there are two different lcd update functions that are implemented, one for the 256 color blitting, and another one that uses DMA, it looks like lcd_update is being called outside of the plugin 20.15.41 # Since we have no way of knowing if it's a file they'll listen to often (or if it's true of their whole collection) 20.15.46 # Llorean: the issue as i understand it is that the codec needs some bytes from the end of *some* filesbefore it can start decoding 20.15.48 # kkurbjun: I'll get it charging.. its been siting on the bench for about 3 months without being touched :p 20.16.08 # Unhelpful: I wasn't aware it was specifically the end. Somehow I got the impression it could be anywhere in the file with MP4 metadata. 20.16.15 # * Llorean is ill informed almost certainly 20.16.40 # klapaucjusz: Looking at FS#10833 (and the implementation of NeAACDecDecode in libfaad) - the check for NULL returned by NeAACDecDecode seems required, but should you still call NeAACDecGetErrorMessage in that case? 20.16.40 # Llorean: that case could still be handled with a similar mechanism if the data in question is contiguous 20.17.04 # Unhelpful: True. 20.17.33 # one extra seek when already spun up shouldn't do much harm, i'd think 20.18.05 # Isn't that more or less what we do for ID3v2 anyway? (or was it v1)? 20.18.27 # linuxstb: no, I shouldn't. 20.18.40 # though i'm not sure why this data can't be stashed by the metadata reader, perhaps after reducing it to only the relevant bits? don't we have codecs that do similar things already, and some space in the metadata structure for codec-private data? 20.19.41 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 20.20.11 # Unhelpful: yep, that's a solution. 20.20.49 # But even if you reduce it to just the needed bits, it's still potentially quite a lot of data (the frame position info). 20.20.56 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.21.00 # Not reasonable to put it statically -- need to malloc and stuff. 20.21.18 Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) 20.21.39 # There is no malloc in rockbox, this was the problem I came across when I started looking into carrying the data into the codec 20.21.56 # There was also talk of why Rockbox has 2 different tag readers 20.22.28 # JdGordon1: how did you fix the flicker? 20.22.33 # So what I'm saying is -- in that particular case (unstreamable mp4), let's just take the efficiency hit. 20.23.14 # alex`: The metadata parser should parse the file and extract the metadata. The codec parser should parse the file and extract the audio data to decode. They use different APIs, and do different things. 20.23.27 # kugel: it inly clears if it has to 20.23.32 # i.e it went from off to on 20.23.37 # um.. on to off 20.23.43 # one of them :p 20.24.15 # I thought we agreed that the refresh event stays because that also removes dead parts from splashes for example? 20.24.27 # linuxstb: But so much of the code is duplaicated, why isn't there one parser which can either extract the metadata or the audio data on demand? 20.24.44 # Anyway I feel I may be de-realing the conversation somewhat 20.25.10 # kugel: I'd *really* rather not have that event... but yeah splashes are buggered atm 20.25.22 # but thats not enough reason to put it back in 20.25.26 # you said it's ok as function call? 20.25.37 # what's bad about it? 20.25.42 # klapaucjusz: Why take the efficiency hit? 20.26.04 # as a function its ok 20.26.14 # so it fixes bugs but also introduces some... 20.26.27 # feel free to make it a function call, it's fine 20.26.35 Join Tomis2 [0] (n=Tomis@70.134.100.133) 20.28.00 # Llorean: what other solution do we have? 20.28.18 # Recall that unstreamable mp4s are fairly rare, so we don't want to complicate the code a lot just for that case. 20.28.21 # Not support unstreamable files. 20.28.22 # alex`: Because they're using two different APIs (disk I/O and the buffering API). But if you could merge the code, please do! 20.28.31 # klapaucjusz: If they're rare, people shouldn't have many that need fixing. 20.28.40 # Just to point out when we are calling these unstreamable files they are not, they are valid m4a's which Rockbox won't play. 20.28.47 Quit parafin ("new kernel") 20.28.57 # alex`: exactly. 20.29.14 # RB claims to support AAC-LC mp4s. 20.29.15 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 20.29.17 # This is a lie. 20.29.26 # It only supports a subset of AAC-LC mp4s. 20.29.46 # Llorean: I think I would agree with klapaucjusz - it's better to support inefficiently designed files inefficiently than not to support them at all. But I do think we should try and explore better ways to deal with them. 20.29.51 # Llorean: They are not that rare, believe me. And besides I think my other halfs iTunes would complain if I start duplicating her m4a's with ones especially for RB 20.30.10 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 20.30.25 # alex`: Why would you duplicate them? fix them once and be done with it, right? 20.30.32 # linuxstb: how much data is buffered typically? 20.30.36 # is there some reason where unstreamable metadata is required? 20.31.06 # klapaucjusz: There is no typically. It depends on the player, how much RAM is used for other features, and in the context of a single file, where that single file lands in the playlist. 20.32.02 # Llorean: because I have no idea how iTunes would react if the checksums of it's files changed under its feet and I'd rather not get the grief if my other half suddenly can't play her music. 20.32.21 # alex`: Checksums? 20.32.47 Join MethoS- [0] (n=clemens@134.102.106.250) 20.32.47 # alex`: iTunes will play any non-DRM m4a just fine. Any DRM one won't play in Rockbox anyway. 20.32.47 # does AAC use COP? if not i think using it could get us to realtime for AAC-HE on PP... we're already ~66% 20.33.05 # klapaucjusz: the total audio buffer is probably about the size of memory the player has minus a couple of megs usually, not sure how metadata fits in there 20.33.07 Join Dhraakellian [0] (n=ntryon@cpe-67-253-173-122.rochester.res.rr.com) 20.33.19 # ahah! i have backlight on while plugged. the fast test was made while unplugged. 20.33.28 # Unhelpful: No, it doesn't. 20.34.00 # is it possible to disable the reboot into OF when USB power is connected on the Fuze? 20.34.27 # on players with larger screens the audio buffer is smaller, on the m:robe 500 I think there is about 4 megs less than the total ram (60 megs out of 64) 20.34.41 # holding Select is rather inconvenient when one is turning the ignition while wearing gloves 20.34.42 # I don't care what iTunes does or doesn't do. However it seems silly to force users to "fix" their m4a's with some unspecified magic which they may not understand if they are not metadata gurus. 20.35.17 # Should we just submit a Documentation patch saying Rockbox can't play some m4a's and what the fix for them is? 20.35.58 # What is the magic fix BTW? 20.36.00 # kkurbjun: so the buffer is a couple dozen megs, typically? 20.36.18 # In that case, for a typical m4a track, the skip will not cause a rebuffer, right? 20.36.33 # these are files that don't conform to the spec? 20.36.42 # One case of m4a's that needs testing is audiobooks BTW 20.36.44 # alex`: Depends. Programs have "optimize MP4 layout" or similar options which make the files streamable (which they aren't - note that streamable is not the same as playable) 20.36.46 Quit Tomis (Read error: 110 (Connection timed out)) 20.36.58 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.100.133) 20.37.12 # stripwax: which spec? I think they conform to the spec I read. 20.37.13 # stripwax: no, they conform perfectly to the spec. The spec allows one-pass reading of files (normal mp4s), and one-pass writing of files (unstreamable mp4s). 20.37.35 # I.e. metadata at the beginning (one-pass reading) or metadata at the end (one-pass writing). 20.37.40 Quit Xerion (Connection timed out) 20.37.40 Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) 20.37.52 # klapaucjusz: I'm not sure about that - you're calling "advance_buffer", which is telling the codec API that the codec is finished using all data up to that point. I don't know if the buffering code will reuse it - it would be within its rights to just start reading more data over the top of it... 20.37.55 # alex`: Large audio books suffer their own problems simply due to the size of the file. 20.38.08 Quit dfkt_ (Read error: 110 (Connection timed out)) 20.38.21 # linuxstb: hold on, I'll try to grok the buffering code. 20.39.04 Join parafin [0] (i=parafin@paraf.in) 20.40.29 # Ok. bufadvance is just an alias for bufseek. 20.40.42 # New FS#10834 : Fix off-by-one in playlist.c found by valgrind. 20.40.57 # And bufseek does the reasonable thing (it just changes the current position pointer if possible). 20.42.00 # And since we're not yielding between the two seeks, the buffering thread doesn't have a chance to discard the data before the current pointer, right? (I'm a little shaky on that.) 20.42.27 # So unless I'm missing something, no rebuffering in the typical case. 20.44.46 Join domonoky1 [0] (n=Domonoky@g229127107.adsl.alicedsl.de) 20.45.00 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 20.46.40 # Unhelpful: no, not to my knowledge (COP in AAC). But I'm a little surprised by your 60% figure, AAC-HA doesn't play realtime on nano2g, which has a 200MHz chip. 20.47.13 Join solexx_ [0] (n=jrschulz@e176103158.adsl.alicedsl.de) 20.47.16 Join Tomis2 [0] (n=Tomis@70.134.103.64) 20.47.25 # klapaucjusz: How does it perform with test codec? 20.47.26 # * alex` wonders if snrncpy got deprecated since he last re-based his patch 20.47.34 # test codec? 20.47.57 # The plugin we use to see what percentage of realtime a codec performs. 20.48.06 # klapaucjusz: The Nano2G seems to have its own speed issues - it's performing much slower than the CPU clock would suggest. 20.48.07 # * klapaucjusz is all ears. 20.48.08 Quit domonoky (Read error: 60 (Operation timed out)) 20.48.17 # How do I bench it? 20.48.45 # Add test_codec.c to apps/plugins/SOURCES, rebuild rockbox, then you can open audio files with test_codec (it's a viewer plugin) 20.48.58 Quit stripwax ("http://miranda-im.org") 20.49.15 # I just add test_codec.c to sources, anywhere in the file, right? 20.49.30 # Do I need to make clean? 20.49.44 # Shouldn't need to, no. 20.50.43 Quit Tomis (Read error: 60 (Operation timed out)) 20.50.43 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.103.64) 20.51.13 # linuxstb: Don't you need to reconfigure though if you change sources? 20.52.22 # Llorean: it appears to work fine with just a make 20.52.26 # Llorean: No, configure is independent of that. 20.52.38 # I thought something was necessary if you changed it. Ah well. 20.52.43 # Okay, nano2g, 192kbit Ogg, 356.54%. 20.53.54 # After which my nano crashed. 20.54.00 # * alex` boggles 20.54.04 # The flash is gone. 20.54.24 # * klapaucjusz needs to reinstall the OF. 20.54.59 # Is that behaviour typical of iPods? A crash causes the flash to disappear more often than not? 20.55.13 # Something as simple as a division by zero forces a reinstall. 20.55.27 # Or is there something fishy with the nano2g's exception handler? 20.57.50 # dd if=Firmware-19.8.1.3 of=/dev/sda1 20.58.28 # Folks, any other nice development tricks? (Like the test_codec?) 20.59.03 # klapaucjusz: There is stuff documented on wiki although I do find it a bit hard to search for some reason. 20.59.39 Quit solexx (Read error: 110 (Connection timed out)) 20.59.48 # * alex` wonders if there is a way to test if the current playlist has never been saved but is resuming from svaed state on a reboot? 21.00.22 # * klapaucjusz has just made a mistake while reinstalling his iPod, it now speaks Chech. 21.00.57 # * klapaucjusz now knows that "Language" in Czech is "Jazyk". 21.01.00 # New commit by 03Domonoky (r23877): fix email link in admin view. 21.01.35 # alex`: You mean checking if it's a dynamic playlist, and if it's a bootup-resume rather than a standard resume? 21.01.55 # Llorean: exactly 21.02.02 # Why on bootup but not on normal resumes? 21.02.32 # I thought I'd have one more go at sumbitting FS#9677 but currently it doesn't kick in if the system has been rebooted 21.03.16 # global_settings.party_mode is false, as is playlist_modified(NULL) 21.03.16 # Does that mean it currently fails to give the normal warning if the system has been rebooted? 21.03.32 # Is there a bug for that? 21.03.49 # New commit by 03Domonoky (r23878): show submitted timestamp in themeslist. 21.03.54 # Llorean: with FS#9677 (which is an enhanced warning for erasing the playlist) 21.04.10 # That's not a bug. 21.04.39 # If there's an issue that occurs without that patch, it should be in a bug task so that people not interested in potential features can still spot it easily. 21.05.15 # It's a bug in my patch, I'm just trying to detect the case so I can offer the warning 21.05.41 # alex`: I asked if the *normal* warning doesn't happen, and if there's a bug for it. 21.05.49 # A playlist shouldn't get wipped if the player has powered down inbetween and someone fat fingers a new playlist 21.05.50 # Not the one from your patch. 21.06.12 # Does the current in-rockbox dynamic playlist erase warning fail to show up if it's been rebooted? 21.06.37 # Llorean: I have no idea, I was testing something else. I can check it now if you want. 21.07.11 Quit gevaerts (Nick collision from services.) 21.07.19 # Well, that's what I meant. If it works in-Rockbox as it stands, then it should give you a path for investigating your issue. If not, it should be bugged and shouldn't affect whether or not your patch is accepted, I would think. 21.07.23 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 21.07.50 # Llorean: True... I shall check 21.09.39 Quit shai ("Leaving") 21.17.43 # curious, the logic is the same, the behaviour different 21.20.05 Quit Tomis (Read error: 60 (Operation timed out)) 21.21.08 Join Tomis [0] (n=Tomis@70.134.88.217) 21.22.12 # Nano2g benchmarks: http://rockbox.pastebin.com/m4b107eea 21.22.42 Quit liar (Read error: 113 (No route to host)) 21.23.06 # Interestingly, we're really close to having AAC-HE usable. 21.25.54 # Llorean: Ahh, no the behaviour is the same with and without the patch, as in if you haven't hit "Resume" after a bootup and select a new playlist creating action it will go straight ahead without a prompt 21.26.09 # I'm not sure if that is undesirable or not 21.26.28 # If you're stopped I wouldn't expect it to prevent you. 21.26.40 # But that's me. 21.26.52 # Does it prevent you if you actually stop playback without rebooting? (not just pausing) 21.27.49 # What's a stop, long hold on pause on iPod? 21.28.48 Join xordos [0] (n=xordos@adsl-99-29-119-167.dsl.hstntx.sbcglobal.net) 21.28.52 # klapaucjusz: how close? i've a few *small* aac-he-specific tweaks... 21.29.22 # Llorean: If you stop and start a new playlist it still prompts if you want to erase the current playlist 21.30.01 # By that behaviour should it do the same on a reboot? 21.30.04 # Unhelpful: 102%. 21.30.38 # Depending on the bitrate, somewhat less. It stutters on some files, but some play fine. The UI is completely unresponsive, of course. 21.32.06 # alex`: Are you actually stopping? 21.32.24 # Sorry to ask what seems like an obvious question, but it can be hard to tell if it's stopped or simply paused sometimes 21.33.07 # odd, test_codec on e200 shows it needing ~133MHz. with 200 you should be fine, but not all arm cores are equal. ;) 21.33.34 # Unhelpful: linuxstb said the Nano 2G is underperforming for some reason. 21.33.53 Quit GeekShado_ (Read error: 104 (Connection reset by peer)) 21.34.27 # Llorean: Think so, I get a solid square instead of || in the top left corner of the menu display 21.35.11 # alex`: I wonder if it's different intentionally because if someone hasn't set "resume on startup" it's unlikely for them to think "I have a playlist" immediately on boot, and might cause more confusion if it did warn them. 21.35.12 # I don't know 21.36.16 # I've put a bunch of clarifications in FS#10832. 21.37.16 # Unhelpful: it's ARMv4T, in case it matters. 21.37.51 # Llorean: Doesn't sound like I should raise a bug, and helpfully this doesn't regress FS#9677 21.38.42 # It might be worth raising a bug to find out if this is "as intended" or if it's a bug (after which it might make sense to document it in the 'Warn on erase' entry in the manual) 21.40.40 # klapaucjusz: e200 is ARMv4 as well. maybe there's a memory issue of some sort? 21.41.43 # If you have any ideas, I'll be glad to try out your tweaks. 21.42.31 Join burden555 [0] (n=burden55@76.246.196.177) 21.43.10 # hello, I want to reformat my Video iPod (30gb) to NTFS file system so I can put larger than 4gb files on it. Will rockbox support it still? 21.43.49 # Llorean: FS #10835 21.44.10 # burden555: no. 21.44.37 Quit phanboy4 (Read error: 54 (Connection reset by peer)) 21.45.19 # Llorean: Ahh, there may be an answer in FS#9660 21.45.24 # what else can I do so I can put a 14gb file on it? 21.45.39 Part smogzer ("http://quassel-irc.org - Chat comfortably. Anywhere.") 21.46.05 # klapaucjusz: i'd expect what works best on e200 to work best on nano2g if they're both armv4... but there *is* an LUT involved, so if memory access is much slower an LUT-less algorithm might be called for 21.46.24 # burden555: Create a second partition not to be used by Rockbox, or split the file with an archiving tool and re-combine it to the system if you need to access it. 21.48.01 # Llorean: how do you profile? 21.48.26 # The simulator spends most of its time in ps_decorrelate and fft_dif, and a little in sbr_qmf_syntesis_64. 21.48.59 # Oh, and just a wee bit in dct4_kernel. 21.49.10 # Since all of these are in libfaad, I think it might make sense to first try to upgrade to the latest version. Filing a feature request. 21.49.15 # * alex` updates #FS9677 with the (hopefully) final update 21.49.25 # klapaucjusz: There's no feature requests in the tracker. 21.50.01 # I would appreciate any comments or review items on #FS9677, even if it's just a "never going to happen" comment. The patch is almost a year old now 21.50.38 # alex`: might want to take it to the -dev list. 21.51.12 # The problem with IRC is that you have to say it at just the right time for it to end up in front of the right eyes at a time where they feel like thinking about it. On-list it sits in the inbox until they can get back to it. Not guaranteed, but at least it helps odds somewhat 21.52.02 # Llorean: I have mentioned it on the dev list before, however I shall send one more 21.52.26 # Llorean: I agree IRC is a bit hit and miss, but it seems to be where most of the action is 21.53.21 # alex`: Getting a feature change in as a non-committer can be difficult. You basically need to have it in a state where you can confidently say "I think it's ready" and then manage to catch somebody's attention with it who's willing to take responsibility for it just in case you aren't around after they commit it if something goes wrong. 21.54.00 # how can I partition my iPod? 21.57.33 # burden555: don't bother. 21.57.35 # Just split the file. 21.57.47 # (Into 14 chunks of 1GB each.) 21.57.59 # Zip, rar, dd, whatever. 21.59.37 # Its a concert I recorded and I want to play it on my LED TV which has a USB port so it must stay in the original video format. 21.59.39 # klapaucjusz: i've looked at lot speeding up libfaad 21.59.46 # Llorean: I am aware of this :-) However I think it was ready about 11 months ago. No one reviewed it after I addressed the first review comments. 21.59.50 # your best bet is to improve the QMF filterbanks 22.00.13 # there are already faster versions in rockbox for other codecs (atrac, mp3 and mpc use them as well) 22.00.43 # FS#10836 22.00.54 # i've also been bugging stripwax to profile aac-he but i don't think he has had time just yet 22.00.59 # Llorean: It's certainly an area of soliting casual submissions to Rockbox that could be improved on, however it's up to the core devs if they think it's a problem. 22.01.03 *** Saving seen data "./dancer.seen" 22.01.17 # alex`: It's not really something that can be readily improved. 22.01.23 # saratoga: is profiling on target all that difficult really? 22.01.27 # There's nowhere to pull "more time for reviewing other peoples' code" from. 22.01.35 # please don't file bug reports for things that aren't bugs 22.01.39 # its annoying to have to close them 22.02.01 # if you want to resync faad, submit a patch, but IIRC last time we looked at it the changes didn't seem all that impressive 22.02.06 # saratoga: so what's the proper policy? 22.02.08 # klapaucjusz: I thought I told you not to put feature requests in the tracker just a few minutes ago. 22.02.12 # libfaad current svn is still slow as heck 22.02.42 # So where do I put wishlist-type bugs? 22.02.46 # we don't have one 22.02.55 # Great. 22.03.00 # saratoga: i believe somebody mentioned decode errors (ringing) for low-bitrate files w/ the old version, earlier... then again low-bitrate files ring like hell anyway. ;) 22.03.10 # yeah but i htink that was my fault 22.03.15 # klapaucjusz: he had hundreds of FQ's noone ever looked at, not great either 22.03.26 # i fixed a bug related to bad optimizations on my part recently in libfaad 22.03.44 # that causes ringing due to the wrong window being used sometimes when inverse transforming 22.04.00 # klapaucjusz: if there's an actual *bug* that the new faad would fix for us, document the actual bug, give steps for reproducing, and mention the relevant code in newer versions of faad (perhaps the revision that fixed it) 22.04.02 # That would be ideal 22.04.05 # klapaucjusz: all the work is done by volunteers... feature requests aren't really compatible with that. asking volunteers to fix actual bugs is one thing, telling them you want this or that is another. 22.04.21 # basically libfaad sucks and I don't see much sense in trying to keep up to date with all the ways its not very good 22.04.31 # Unhelpful: I realise it's 100% volunteer work. 22.04.45 # I do myself participate in a number of projects that are based on volunteer work. 22.04.55 # * domonoky1 completed the first step to a userarea on the themepage: FS#10837 :-) 22.04.58 # saratoga: how about using opencore for aac ? 22.05.02 # It's not completely impossible that you downloaded the files that you're listening to using my software. 22.05.20 Quit Res1 (Read error: 60 (Operation timed out)) 22.05.24 # Being based on volunteer work does not mean that you have to ignore your users and friendly contributors. 22.05.48 # It means that you don't commit to deadlines, and that your feature request tracker has a position that says "reasonable suggestion, nobody can be bothered." 22.06.02 # So please, please stop giving me the "if you want it, submit a patch" line. 22.06.19 # klapaucjusz: The old feature request tracker wasted a *ton* of time keeping it clean and organized. 22.06.24 # If I want it, I submit a feature request, which the developers are welcome to ignore. 22.06.30 # Llorean: I appreciate the issue with review time, and perhaps Rockbox is more special given the embedded nature of the code. However in my experience Rockbox is one of the hardest projects to make contributions to and it's an open question if that is good or bad for Rockbox. 22.06.34 # klapaucjusz: We had feature requests. They weren't useful in any way, so we ditched it 22.06.56 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-060-031.pools.arcor-ip.net) 22.07.07 # klapaucjusz: This is the second time you've assumed that we should work a certain way without taking into consideration that we might have experiences you haven't that have caused us not to. 22.07.30 # Yes? 22.07.59 # alex`: really? i didn't find it difficult, i fixed up a patch on FS to reduce memory footprint and when it looked nice enough somebody said "hey when are you committing that?" :P 22.08.08 # which was amusing as i did not have commit access 22.08.10 # klapaucjusz: So stop telling us we should do things a way that doesn't actually work effectively here. 22.08.59 # Unhelpful: see? It was hard! 22.09.04 # klapaucjusz: And more specifically, stop ignoring things just because you don't agree with them if you want to become involved with the project. 22.09.07 # alex`: to get patches commited, you have to nag us here often :-) if we get annoyed and your patches are good, you get commit access :-) 22.09.40 # Unhelpful: I'm not saying it's impossible, indeed I have several patches committed myself but I'm just comparing with my experience across other projects. 22.10.23 # domonoky1: There is a fine line between nagging and winding people up. I've been on the recieving end of flame material on the RB mailing list before. 22.11.05 # domonoky1: Anyway, go review FS#9677 then ;-) 22.11.24 # * domonoky1 goes looking.. :-) 22.11.40 # or if you pick an FS task that will make users nag for a commit any time it has any activity ;) 22.11.53 # New commit by 03nls (r23879): FS#10834 by Alex Bennee, fixing off-by-one bug in code calling format_track_path 22.13.06 # alex`: The only thing close to flaming of you I see immediately is when I asked you not to post questions like "I listen to a lot of podcasts, why do my database updates take so long?" to the -dev list. 22.15.38 # the two big problems we have with good patches is that 1) devs have little spare time 2) people who know part x of the code might no longer be around so noone really knows it well enough to do a good review without investing lot's of time 22.16.17 # n1s: 3) If it changes how things work rather than simply fixing things, people are often shy about accepting that some people won't like it. 22.16.35 # * domonoky1 decides that he doesnt know the code this patch touches, and calls others to review this :-) 22.16.42 # Llorean: yeah 22.17.01 # domonoky1: is that n1s's 1), 2) or 3)? ;) 22.17.22 # gevaerts: 1) and 2) 22.17.26 # :-) 22.18.52 # Llorean: it seemed like a fair question to ask on -dev, seeing as I was seeking ilumination as to the reasons why. However I was jumped on because it's not a place to contact developers. So these days I mainly don't bother unless I've got time to sit in front of IRC asking questions 22.19.18 # Llorean: It certainly would be the sort of question I'd be happy asking on any other -dev list 22.19.39 # alex`: You were talking about emotional responses to it. That you were frustrated. You didn't mention any interest in attempting to fix it. 22.19.56 # I'm sure you can see how the phrasing of the question, as well as the question itself, looked like a simple support request. 22.20.02 # "This is bad, why is it happening to me?" 22.20.53 # alex`: does your patch still allow to abort the playlist erasing action ? 22.21.27 # Llorean: Sure, and I'll be more careful in future. Anyway the point was not to go over any particular incidents just to make the general observation w.r.t to other projects 22.21.53 # domonoky1: Yes, if you press the back arrow to exit the menu the action aborts 22.22.58 # alex`: I'm not sure what "being asked to keep support separate from development" does to make getting something committed harder. 22.23.23 # A "cancel" action in the menu might make sense for people who don't assume left will cancel. 22.23.35 # * domonoky1 thinks the functionname playlist_maybe_save_current() sounds strange.. :-) 22.24.52 Quit pamaury ("exit(*(int *)0 / 0);") 22.25.23 Join saratoga_lab [0] (i=9803c264@gateway/web/freenode/x-mjgiucziekfprhhy) 22.25.53 Quit merbanan (Read error: 110 (Connection timed out)) 22.26.32 # merbanan: i didn't even know there was an open core aac decoder 22.26.35 # do you have a link? 22.26.45 # bah too slow 22.27.43 # alex`: also you changed a few lang entrys (instead of depriciating and adding new ones), i dont know if that is safe for the translations (and their tools). 22.28.27 # domonoky1: I'm all ears to alternatives, I kept playlist at the front as it is a playlist_ api function 22.28.52 # domonoky1: Maybe maybe_save_current_playlist() 22.29.06 # is apache licensing GPL compatible? 22.29.20 # what about playlist_try_save_... but the function name is not really important. 22.29.26 # domonoky1: Could you add comments to FS#9677 please as I need to go do my chores right now ;-) 22.30.15 # Sounds like an additional menu item is the important one 22.30.47 Quit Tomis (Read error: 60 (Operation timed out)) 22.31.35 # Unhelpful: (just now getting caught up on logs) using cop for aac-he is attractive on PP, but the SBR parts take up close to 90-100MHz, so splitting it would be ackward 22.32.25 # IMO the best way would be to apply some minor optimizations (either taken from MPC or ATRAC or from one of the other AAC-HE decoders like ffmpeg or apparently google's opencore one) to get sbr performance below 80MHz 22.32.28 # saratoga: ick... so even splitting SBR vs "the rest" would leave it non-working? 22.32.38 # correct 22.33.02 # but apparently we're a factor of several slower then good SBR implementations, so it might not be very hard to fix that 22.33.22 # for LC I got a large speed up just by deleting the faad mdct and replacing it with an ok one from another codec 22.33.31 # i suspect the same will work here for the sbr filterbanks 22.33.57 # the nero people implied to me that they are not efficiently implemented 22.34.42 # saratoga: if the implementation is as bad as some bits i've looked at... 22.34.58 Quit rvvs89 (Read error: 110 (Connection timed out)) 22.35.14 # i think the best approach would be to look at the analysis or synthesis filterbank, and just throw it out and use a different one 22.35.18 # i bet you'd get a large speed up 22.35.36 # but filterbanks aren't really my thing 22.35.50 # alex`: done :-) 22.36.56 # saratoga: ideally i'd like substitute functions that can be expected to use the same layout for their input and output data... because we're talking about code i don't really understand, here ;) 22.39.49 # Unhelpful: well filterbanks should be pretty simple like that 22.39.53 # data in, data out sort of thing 22.40.24 # its basically just a weird FIR filter IIRC 22.40.47 # saratoga_lab: The Apache license appears to be incompatible with GPLv2 (but not GPLv3) - http://www.gnu.org/licenses/license-list.html#apache2 22.41.11 # hmm annoying 22.41.26 # i suppose though this is just like the Helix SBR code, where we can steal their ideas if not their code 22.41.36 # saratoga_lab: Are those filters somehow related to what ape does for compression levels > -c1000 ? 22.41.55 # hrm, so, on arm, debruijn-ish log2 has 10 ops, binsearch+LUT has 9 - both not counting load of the LUT address. gotchas: binsearch has an add dependent on the table load, with one instruction it can slot in between. so 1) what's result latency for ldr from iram? 2) how much do we care about table size (64 vs 256 entries) 22.42.17 # amiconn: i really have no idea 22.42.22 # (about APE) 22.42.32 # but they should be the same as the mpeg and mpc ones IIRC 22.42.57 Quit burden555 () 22.43.08 # basically just perform a DCT on a vector, then run through multiply-accumulating filter coefficients on each sample out of the dct 22.43.24 Part froggyman 22.43.25 # saratoga_lab: opencore also looks like it's C++, although that's probably relatively easy to fix... But it seems a non-starter license wise anyway. 22.43.40 # its c++ but the code all looked like c to me 22.44.09 # The first file I looked at wasn't - http://github.com/android/platform_external_opencore/blob/master/codecs_v2/audio/aac/dec/src/decoder_aac.cpp 22.44.19 # (I don't know if that's the right git repo...) 22.44.22 # the filterbanks were c at least 22.44.30 # the entry points probably aren't 22.44.36 # amiconn: check this: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/atrac3.c?revision=22341&view=markup 22.44.39 # search "static void iqmf" 22.45.10 # "loop1" is a 4 point DCT since this is a 4 channel QMF 22.45.21 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 22.45.30 # "loop 2" is a 48 tap filter 22.45.34 # and thats the QMF 22.46.32 # basically just a really stupid way to implement a time -> frequency conversion, using FIR filters instead of an MDCT 22.48.14 # That looks much simpler than the ape filters 22.50.09 Quit mt (Read error: 104 (Connection reset by peer)) 22.50.39 # google says AAC-HE uses a 64 band QMF instead of a 4 band so that DCT is probably more complicated, but yeah, i think its not too hard 22.50.46 # The latter are (iiuc) fir filters as well, but they dynamically adjust their coefficients, and apply mac results conditionally, based on sign and magnitude of the result 22.52.06 # The high compression levels also use much longer filters (up to 1280 samples for "insane") and two filter "layers" with different length 22.53.04 # * amiconn wonders whether someone tried to asm-ize this qmf thing 22.53.47 # amiconn: yes we did on ARM 22.54.03 # (for ATRAC) 22.54.18 # If this function takes a significant part of the total decode time, there should be quite some gain 22.54.20 # see: http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/libatrac/atrac3_arm.S?revision=22548&view=markup 22.54.39 # also for MP3 the filterbank there was rewritten to use EMAC for everything on coldfire 22.54.40 # Especially on coldfire, as our current gcc doesn't know anything about coldfire emac 22.55.19 # but yeah atrac could use it, i think its not even real time right now since the fitlber bank needs about 200Mhz or something ridiculous 22.55.55 # could probably just replace that 48 tap loop with a couple lines of asm and get real time 22.57.02 Quit saratoga_lab ("Page closed") 22.58.24 # The arm loops aren't optimal for the newer generations (arm9 and up) regarding interlocks 22.59.17 # * amiconn would probably unroll the whole loop if performance is that critical there 22.59.32 # The whole inner loop of course 23.00.20 # hmhm 23.02.14 Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 23.02.24 Join Omlet [0] (i=omlet05@40.10-65-87.adsl-dyn.isp.belgacom.be) 23.04.15 Quit Omlet (Client Quit) 23.04.46 # domonoky1: I'm back. Are you just refering to the LANG_WARN_ERASEDYNPLAYLIST_MENU id? The others are all new 23.04.46 # 23.06.00 # yes, and LANG_WARN_ERASEDYNPLAYLIST_PROMPT 23.06.42 # APE -c3000 uses a 64 tap filter and is realtime on coldfire, so it shouldn't be hard to get that 48 tap filter (with simpler structure) realtime as well 23.06.44 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 23.08.31 Quit n1s ("Lämnar") 23.10.25 # amiconn: i'd meant to ask something re: font bitmap combining... cf can retrieve unaligned machine words, right? would it be worth using machine words instead of bytes when moving or combining font glyph data? 23.10.25 # http://groups.google.com/group/pycorn/pendmsg?hl=en 23.10.25 # oops 23.10.27 # pardon my mispaste 23.15.18 # Coldfire supports unaligned memory accesses, yes. But there is of course a performance penalty 23.17.07 # Unaligned longword accesses are split into byte and word accesses, and even more importantly, movem.l doesn't use burst mode if the address is unaligned, even if a whole longword or line is covered 23.17.31 Join melat0nin [0] (n=melat0ni@88-109-45-49.dynamic.dsl.as9105.com) 23.17.49 # anybody know when the manuals will be back online? 23.17.51 # The memory controller isn't *that* intelligent, at least not on coldfire v2 (I have no idea about coldfire v3 or v4 regarding that - no such rockbox targets exist) 23.18.19 # was reading the Fuze manual 2 days ago but it's gone now, both html and pdf 23.18.43 # I think they'll be around once me or zagor figure out why they vanished 23.18.55 # wahey :) 23.18.59 # thanks 23.19.05 # in a day or two I hope 23.19.10 # So on coldfire it is extremely important to either use iram, or use movem.l with full-line accesses for larger buffers if performance is important 23.19.15 # am using google cache in the meantime, but there are no images :( 23.21.26 # There is a reason for that memcpy/memmove monster on cf... 23.22.04 # is there a rockbox mirror w/manuals? 23.22.44 # http://download.rockbox.org/manual/ 23.23.04 # hm no 23.23.56 # amiconn: so it might be worth using aligned words when blitting or blending font data, even if they need to be shifted to meet the correct alignment, and even if they might need swapped to get bytes in-order? 23.24.55 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 23.25.14 # It depends on where the buffer resides. If the intermediate buffer is in IRAM, shifting & swapping will probably make things worse 23.25.23 # ach well 23.26.01 # hrm... ok. the non-blend case could always just call memcpy for each row, too. 23.26.10 # That is one reason why I think an intermediate buffer might even speed things up overall 23.26.25 # melat0nin: http://forums.rockbox.org/index.php?topic=23338.msg159076#msg159076 23.27.54 # Another reason is that the drawing routines (which need to apply drawmode, background etc) will operate on fewer, larger source bitmaps 23.28.42 # pixelma: thankyou very much! :) 23.28.56 Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) 23.29.27 # * pixelma deflects the thanks to bluebrother ;) 23.30.47 # :D 23.31.55 Quit melat0nin () 23.32.01 Join Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) 23.33.12 Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) 23.33.53 Join angelwolf71885 [0] (n=chatzill@cpe-173-171-133-36.tampabay.res.rr.com) 23.33.53 Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) 23.35.22 # is it possible on CF to load a byte from a table into the register used to index the table? it would save having to extend the byte (i know it will be clear in the high 24) 23.35.22 Quit fxb__ (Read error: 104 (Connection reset by peer)) 23.36.42 # i can't get gcc to do it, so i'd have to use asm, but i was kind of wondering if that was even going to be legal, or if it might incur a performance penalty and/or trigger a fault or exception of some sort 23.37.10 Quit dfkt_ ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 23.37.47 Quit angelwolf71885 (Client Quit) 23.38.06 Quit advcomp2019 ("Leaving") 23.38.33 Join angelwolf71885 [0] (n=chatzill@cpe-173-171-133-36.tampabay.res.rr.com) 23.38.43 # irc.betaarchive.co.uk 23.39.55 # Unhelpful: You mean in scaled index mode? 23.40.35 # gcc isn't very clever in general (read: several instruction sequences it produces are braindead) 23.41.28 # Maybe it 's different for x86, but for our target architectures I've seen it doing many strange things 23.42.31 Join fxb [0] (n=felixbru@h1252615.stratoserver.net) 23.42.52 # the function in question is av_log2 in codeclib/codeclib.h. to the extent of my coldfire asm knowledge the generated code is optimal, except that *if* the LUT value (from a char array) could be written into the register used to index the load, we could save an ext.b 23.43.05 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.43.41 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 23.43.52 Nick Rondom_ is now known as Rondom (n=quassel@dslb-084-057-140-109.pools.arcor-ip.net) 23.44.18 # Afaik there is no such restriction 23.44.25 # hah... you know what, actually, gcc answered my question, as it generates "move.b (%a0,%d0.l),%d0; extb.l %d0" 23.45.01 # It just doesn't know that the extb.l is superfluous... 23.45.22 # exactly. that would need it to be a bit more clever than we can probably expect 23.46.25 # nls: I found another off-by-one for format_track_path which I should have checked for when I submitted the patch, should I raise another Flyspray bug? 23.46.27 # although it's smart enough to figure do x ? 31 - __builtin_clz(x) : 0 on arm as tst; clzne; rsbne; 23.46.40 # and to skip the test if the input is calculated 23.47.06 # We're using gcc 4.0 on arm, but 3.4 on coldfire 23.47.07 Quit dfkt (Read error: 110 (Connection timed out)) 23.47.26 # (4.0 on coldfire isn't really an improvement though) 23.48.28 Quit dmb ("Leaving") 23.49.44 # that's true, but gcc only seems to be reasonably clever about zero/nonzero, and sometimes equality tests. value range/size stuff it doesn't figure out so much, half of the gain on armv4 for jpeg idct in asm was forcing optimal order for multiply operands and killing a bunch of superfluous extension instructions created by the mul16 C macro 23.52.04 Quit saratoga (Ping timeout: 180 seconds) 23.52.30 # B4gder: Have we deliberately changed to only keeping the previous two daily builds? I thought we kept a month's worth? 23.53.07 # I'm not sure, zagor's the one who's fiddled with the scripts 23.53.23 Quit bmbl ("Bye!") 23.54.35 Part froggyman