--- Log for 01.02.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 day and 14 hours ago 00.00.08 Join tarbo [0] (~me@unaffiliated/tarbo) 00.00.10 # no, someone elses 00.00.47 # so the buffer is full with 2 backdrops now? 00.01.07 # http://themes.rockbox.org/index.php?themeid=370&target=sansae200 00.02.45 # ah, the 2 fullscreen mono bitmaps are still there 00.05.10 # I tihnk I need to make the skin buffer size selectable before fms goes in so it doesnt get crazy 00.05.15 # (limited in both directions) 00.05.30 # its either too much reserved, or not enough 00.06.03 Quit tarbo (Ping timeout: 265 seconds) 00.06.05 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.4.231) 00.06.23 # the increase it got should be sufficient for the fms I imagine 00.06.26 # Can someone explain to me how to exclude specific plugins from being built on the SA9200? It's only the ones that have no bitmaps for the 128x160 screen. 00.07.13 # LambdaCalculus37: #ifdef in SOURCES 00.07.40 # kugel: not really, the buffer only increases enough for a backdrop, which is always loaded unless %Xd is there. so you cant have a bmp intensive WPS and sbs and fms all together 00.09.22 # a theme which worked before now needed a buffer increase to still work? 00.09.53 # no, I'm not sure it ever did 00.10.05 # but I thought that was a silly size anyway 00.10.40 # I'm thinking something went wrong if it worked before 00.11.00 # I used that Klean theme once on my e200, although it wasn't v4 00.11.17 # kugel: I'm a wee bit confused on how to add in plugins I want to exclude, though. 00.14.28 # ui viewport is completely gone now? 00.14.50 # not if you dont specify a sbs 00.15.23 # ah I found where it's parsed 00.15.35 # so you can still use ui veiwport if no .sbs is loadd? 00.15.58 # yes 00.16.21 # and it is used internally if the inbuilt bar is enabled 00.16.21 # aha...that's where i'm messing up 00.16.26 # thanks. 00.16.46 Join TopyMobile_ [0] (~topy@f049041081.adsl.alicedsl.de) 00.18.50 # so when is that inbuilt statusbar finally replaced with the sbs version? 00.18.53 Quit stoffel (Remote host closed the connection) 00.19.00 Quit jgarvey (Quit: Leaving) 00.19.36 # probbaly never :p 00.19.50 # it's no longer getting in the way so much 00.20.09 Join tarbo [0] (~me@unaffiliated/tarbo) 00.20.31 # ... 00.21.09 Quit TopyMobile__ (Ping timeout: 272 seconds) 00.21.18 # Have there been recent changes to french translation ? The playing screen displays some stranges strings on my device 00.22.18 # no, but there's a possible memory corruption in buffering.c which may result in garbage strings 00.23.28 # Not garbage strings but for example when in a playlist, it display say "11 suivant: 14" but it doesn't make sense to use "suivant:" for say 11 "out of" 14 00.23.39 # *to say 00.23.48 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 00.24.32 # Hum, the same happens in english: "11 next: 14" 00.24.47 # Is it the normal text ? 00.25.06 # Also it display "automatic track change only" above the track title 00.25.09 # did you compile yourself? 00.25.11 # yes 00.25.19 # try a current build 00.25.36 # That's the first time it happens to me 00.26.04 # Wait, I'll try to recompile without -j 3 00.26.18 # did you do make bin? 00.26.21 Quit tarbo (Ping timeout: 265 seconds) 00.26.25 # your language is out of date 00.26.57 # Ah yes you're right, for strange reasons it didn't copy the language files o 00.26.58 # oO 00.28.02 # * kugel recommends make install :) 00.28.08 Quit JdGordon (Quit: Leaving.) 00.28.49 # I haven't done a make install for days ! ;) 00.30.36 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 00.30.55 Quit JdGordon (Remote host closed the connection) 00.32.50 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 00.34.41 Quit Strife89|VM (Quit: Shutting down the VM.) 00.35.36 Quit perfectdrug (Quit: perfectdrug) 00.40.07 # Doesn't make install copy language files ? 00.40.10 Join tarbo [0] (~me@unaffiliated/tarbo) 00.43.13 # make install only works with the sim 00.43.16 # you need make zip 00.44.24 # but I don't want to make a zip ! 00.44.59 # anyway I managed to get a clean build with make install. 00.45.46 # Hum, I puzzled. When using dircache with logf enabled I get a strange error message which happens from time to time 00.46.33 # JdGordon: wrong 00.46.58 # pamaury: make install should work (it does make zip + extract behind the scenes) 00.47.07 Quit tarbo (Ping timeout: 272 seconds) 00.47.16 # New commit by 03funman (r24428): Fuzev1: estimate current use with battery_bench results 00.47.32 Quit flydutch (Quit: /* empty */) 00.48.11 # ok then 00.48.31 # New commit by 03funman (r24429): Fuzev1: estimate current use with battery_bench results 00.50.16 # funman: shouldn't CURRENT_NORMAL and CURRENT_BACKLIGHT be the other way around? 00.50.53 # or am I confused by the naming? 00.52.36 Quit efyx_ (Read error: Connection reset by peer) 00.53.54 Quit S_a_i_n_t (Ping timeout: 265 seconds) 00.55.09 Join TopyMobile__ [0] (~topy@f054208125.adsl.alicedsl.de) 00.55.45 # New commit by 03funman (r24430): Modify version strings for 3.5 00.55.49 Quit ender` (Quit: If I had only finished this sentence,) 00.58.34 Join perfectdrug_ [0] (~marko@p5B0EF455.dip.t-dialin.net) 00.59.01 Quit TopyMobile_ (Ping timeout: 256 seconds) 00.59.56 Join froggyman [0] (~sopgenort@pool-72-69-205-209.chi01.dsl-w.verizon.net) 01.01.59 Quit pamaury (Quit: abort();) 01.02.42 Join martian67 [0] (iTIPeHu2HT@over.the.cat) 01.02.42 Quit martian67 (Changing host) 01.02.42 Join martian67 [0] (iTIPeHu2HT@about/linux/regular/martian67) 01.03.23 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.159) 01.05.42 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.4.176) 01.06.07 Part S_a_i_n_t_ 01.06.13 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.4.176) 01.07.31 Quit Tomis (Read error: Connection reset by peer) 01.08.24 Join Tomis [0] (~Tomis@70.134.88.68) 01.09.05 Quit S_a_i_n_t (Ping timeout: 248 seconds) 01.09.54 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.4.176) 01.12.20 Quit TopyMobile__ (Quit: TopyMobile__) 01.13.53 Quit Tomis (Ping timeout: 248 seconds) 01.14.55 Quit S_a_i_n_t (Ping timeout: 246 seconds) 01.18.29 Quit DerPapst (Quit: Leaving.) 01.22.08 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 01.22.08 Quit tarbo (Changing host) 01.22.08 Join tarbo [0] (~me@unaffiliated/tarbo) 01.23.01 Quit andrewRB (Read error: Connection reset by peer) 01.28.00 Quit tarbo (Ping timeout: 264 seconds) 01.30.44 # is it possible to use the eabi gcc compiler when compiling the nano2g rockbox, and if so will it improve anything? 01.33.41 *** Saving seen data "./dancer.seen" 01.34.53 # its mostly possible (search the logs from this month) 01.34.58 # it saves some memory 01.37.33 # Hello, I have a 5th generation iPod that I put Rockbox on over summer. I have not used my iPod in months. Anyway, I remember then, and have the same problem now, that when Rockbox loads, my iPod vibrates. It sounds like the seeker head on the hard drive is moving about rapidly. This however, does not happen when I am using the apple software. Any idea what could be causing this? 01.40.04 Join andrewRB [0] (adb@88-110-101-140.dynamic.dsl.as9105.com) 01.42.09 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 01.42.09 Quit tarbo (Changing host) 01.42.09 Join tarbo [0] (~me@unaffiliated/tarbo) 01.47.28 Join Llorean1 [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) 01.47.29 Quit tarbo (Ping timeout: 248 seconds) 01.47.41 Quit Llorean (Killed (NickServ (GHOST command used by Llorean1!~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net))) 01.47.43 Nick Llorean1 is now known as Llorean (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) 01.47.46 Quit Llorean (Changing host) 01.47.46 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 01.47.56 # TheSeven: ping 01.48.23 Quit grndslm (Read error: Operation timed out) 01.51.04 Quit lyngaas (Read error: Connection reset by peer) 01.53.44 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.5.7/20100106054534]) 01.54.29 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.4.111) 01.55.49 Quit kugel (Ping timeout: 258 seconds) 01.59.11 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 02.01.04 Quit perfectdrug_ (Quit: perfectdrug_) 02.01.16 # If anyone's planning on compiling for the nano2g from current svn...don't bother 02.01.20 # she's broken. 02.01.22 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 02.01.59 # and this: http://pastebin.org/84736 is the fix for it 02.02.13 Join tarbo [0] (~me@unaffiliated/tarbo) 02.02.17 # We've been at it all night... 02.02.23 # and not in *THAT* way :P 02.02.34 # buildserver says the 2g built? 02.02.47 # saratoga: it fails at runtime 02.02.52 # ah ok 02.02.59 # saratoga: for nanos with less than 4 banks 02.04.01 # because of one variable is initialized too late 02.06.24 Quit Sajber^ (Ping timeout: 265 seconds) 02.09.27 Quit tarbo (Ping timeout: 272 seconds) 02.10.26 Join RusselKubes [0] (~626d0007@giant.haxx.se) 02.12.49 # Hello everyone. I just recently registered, I was wondering if I could get write privileges for the wiki? There was a page about iPod Hard Drives that I want to add info for for my model. 02.14.03 # liar: pong 02.14.25 # RusselKubes: <- id that your wiki user name? 02.14.30 # TheSeven: Hello Stranger... :D 02.14.35 # Yes 02.15.42 # RusselKubes: done - please do not spam 02.15.43 # TheSeven: to keep it short: nand_type[x] isnt initialized when nand_power_up is called the first time.. thats why nand_power_up calls nand_reset for unexisting banks 02.16.11 # ok, thank you very much :) 02.16.24 # yep, I got it 02.17.05 # * TheSeven wonders why we haven't caught that before - obviously there aren't many nanos with less then 4 banks... 02.21.15 Join JdGordon| [0] (~Miranda@c-24-22-210-83.hsd1.wa.comcast.net) 02.21.15 Quit JdGordon| (Changing host) 02.21.15 Join JdGordon| [0] (~Miranda@rockbox/developer/JdGordon) 02.22.09 Join tarbo [0] (~me@unaffiliated/tarbo) 02.23.46 # New commit by 03theseven (r24431): Fix iPod Nano 2G bank detection broken in r24414. 02.25.44 Quit RusselKubes (Quit: CGI:IRC) 02.28.09 Quit tarbo (Ping timeout: 265 seconds) 02.31.24 Part froggyman 02.33.44 Join Hawson [0] (~hawson@c-98-204-227-110.hsd1.md.comcast.net) 02.36.07 Part brybot 02.36.48 # New commit by 03unhelpful (r24432): FS#10943, optimized division and clz routines to replace libgcc routines for ARM. Replaces libgcc support functions for unsigned and signed 32-bit ... 02.39.44 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 02.42.43 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 02.42.43 Quit tarbo (Changing host) 02.42.43 Join tarbo [0] (~me@unaffiliated/tarbo) 02.48.24 Quit tarbo (Ping timeout: 264 seconds) 02.48.43 Quit toffe82 (Read error: Connection reset by peer) 02.53.29 Join FlynDice [0] (~FlynDice@67.110.137.2.ptr.us.xo.net) 02.53.44 Quit AndyI (Read error: Connection reset by peer) 02.54.03 Join AndyI [0] (~pasha_int@212.14.205.32) 02.54.59 Join AndyIL [0] (~pasha_int@212.14.205.32) 02.55.00 Quit AndyI (Read error: Connection reset by peer) 02.56.27 Join Tomis [0] (~Tomis@70.134.80.102) 03.02.45 Join tarbo [0] (~me@unaffiliated/tarbo) 03.06.34 Join Strife1989 [0] (~michael@adsl-220-102-33.mcn.bellsouth.net) 03.06.46 Quit chaos (Ping timeout: 276 seconds) 03.08.05 Join chaos [0] (~chaos@gentoo/user/ch4os) 03.08.59 Quit Strife89 (Ping timeout: 272 seconds) 03.10.16 Quit tarbo (Ping timeout: 240 seconds) 03.16.46 Join stooo1 [0] (~sto@f051001064.adsl.alicedsl.de) 03.19.45 Quit stooo (Ping timeout: 272 seconds) 03.22.44 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 03.22.44 Quit tarbo (Changing host) 03.22.44 Join tarbo [0] (~me@unaffiliated/tarbo) 03.22.51 Join rhodan [0] (~quassel@120-176.3-85.cust.bluewin.ch) 03.26.23 Quit liar (Quit: Verlassend) 03.28.34 Quit tarbo (Ping timeout: 265 seconds) 03.30.08 Quit MethoS- (Read error: Connection reset by peer) 03.30.56 # Unhelpful: in firmware/target/arm/support-arm.S:665 there is a ":" missing i suppose 03.31.24 Join wind [0] (~7a05aa05@giant.haxx.se) 03.31.25 # i mean it should be "__aeabi_idivmod:" 03.33.42 *** Saving seen data "./dancer.seen" 03.33.42 # btw, i get this when compiling with --eabi, any help? : rockbox/build/firmware/libfirmware.a(pcm-s5l8700.o): In function `fiq_handler': pcm-s5l8700.c:(.icode+0x58): undefined reference to `dma_callback' 03.34.41 # piotrekm: i don't know what that one's about, but thanks for the heads-up on the missing colon. 03.35.30 # New commit by 03unhelpful (r24433): Remove heaps of trailing whitespace from new file. 03.35.36 # New commit by 03unhelpful (r24434): Missing colon in support-arm.S for EABI. 03.36.02 # urgh, i didn't realize i hadn't pushed that first change already :/ 03.36.15 # how do i delete the bootloader from a nano2g using command-line ipodpatcher? 03.36.55 # S_a_i_n_t: it should ask you what to do 03.37.07 # just run it without any commands 03.39.00 Join BlastTyrant [0] (~Dan@cpe-74-70-177-91.nycap.res.rr.com) 03.39.19 # thanks...i thought so, but thought it may be different with the osbk 03.39.52 # wanted to ask irst, and not be sorry later. 03.40.08 # s/irst/first/ 03.42.41 Quit rhodan (Remote host closed the connection) 03.42.44 Join tarbo [0] (~me@unaffiliated/tarbo) 03.48.23 Quit tarbo (Ping timeout: 265 seconds) 03.51.44 Quit LambdaCalculus37 (Ping timeout: 248 seconds) 03.52.16 Quit ps-auxw (Quit: leaving) 03.53.04 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 03.53.26 Nick Strife1989 is now known as Strife89 (~michael@adsl-220-102-33.mcn.bellsouth.net) 03.53.42 Quit ps-auxw (Client Quit) 03.54.11 Join Rob2223 [0] (~Miranda@p4FDCB515.dip.t-dialin.net) 03.55.28 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 03.56.40 Join LambdaCalculus37 [0] (~rmenes@ool-457bccf5.dyn.optonline.net) 03.56.40 Quit LambdaCalculus37 (Changing host) 03.56.40 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 03.57.45 Quit Rob2222 (Ping timeout: 272 seconds) 04.02.43 Join bangfoo [0] (~477b0e82@giant.haxx.se) 04.02.47 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 04.02.48 Quit tarbo (Changing host) 04.02.48 Join tarbo [0] (~me@unaffiliated/tarbo) 04.03.45 Quit bangfoo (Client Quit) 04.09.25 Quit tarbo (Ping timeout: 256 seconds) 04.11.21 Join RusselKubes [0] (~russ@pool-98-109-0-7.nwrknj.fios.verizon.net) 04.13.35 Quit piotrekm (Ping timeout: 272 seconds) 04.19.51 Quit thegeek (Read error: Connection reset by peer) 04.22.47 Join tarbo [0] (~me@unaffiliated/tarbo) 04.25.57 Join thegeek [0] (~nnscript@s080b.studby.ntnu.no) 04.28.28 Quit tarbo (Ping timeout: 246 seconds) 04.28.36 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 04.32.59 Join Blast_Tyrant [0] (~Dan@cpe-74-70-177-91.nycap.res.rr.com) 04.33.05 Quit TheSeven (Killed (NickServ (GHOST command used by The_Seven))) 04.33.16 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.33.27 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.36.25 Quit BlastTyrant (Ping timeout: 245 seconds) 04.42.47 Join tarbo [0] (~me@unaffiliated/tarbo) 04.42.54 Quit Blast_Tyrant (Quit: Leaving) 04.44.00 Join BlastTyrant [0] (~Dan@cpe-74-70-177-91.nycap.res.rr.com) 04.47.15 # Hello everyone. After updating from r24254 to r24404 on my Fuze I noticed a problem with the BlackSunrise theme that I made (I get the same results in the 1/31 compiled simulator). I just wanted to find out if this problem is a bug or if I'm missing something obvious: 04.47.43 # It seems that the backdrop specified in the theme cfg shows through the WPS backdrop in non-static areas of the screen. I put up an example of this on Imageshack: http://img200.imageshack.us/g/blacksunrisewpsproblems.jpg/ 04.48.17 # gimme 5 min and I'll help 04.48.25 Quit tarbo (Ping timeout: 246 seconds) 04.48.48 # sure thing, thanks 04.53.54 Quit LambdaCalculus37 (Quit: Fwump) 04.54.03 Join Barahir [0] (~jonathan@gssn-5f757ab6.pool.mediaWays.net) 04.54.30 # BlastTyrant: if the theme online somewhere? 04.55.44 # yes, it's up on the Fuze theme page: http://themes.rockbox.org/index.php?themeid=427&target=sansafuze 04.57.05 Quit Barahir_ (Ping timeout: 240 seconds) 04.57.23 # fuze is the same scren as h300 yeah? 04.57.51 # yes 04.58.47 Part andrewRB ("Leaving") 04.58.53 # which of your screenshots is what it is supposed to look like? 04.58.59 Join andrewRB [0] (adb@88-110-101-140.dynamic.dsl.as9105.com) 05.00.27 # this one is what it looked like originally: http://img42.imageshack.us/i/blacksunrisescreenshotv.png/ 05.00.35 # and this is what it's doing now: http://img200.imageshack.us/i/blacksunrisewpsproblems.jpg/ 05.01.18 # *it's supossed to look like the first one 05.01.53 # ah, the progressbar isnt shown 05.01.59 # is that part of the wps backdrop? 05.02.05 # yes 05.02.19 # hmm, ok 05.02.43 # and the next artist text usually scrolls and has the same problem with the bottom bar being transparent where it scrolls 05.02.47 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 05.02.48 Quit tarbo (Changing host) 05.02.48 Join tarbo [0] (~me@unaffiliated/tarbo) 05.03.29 Quit chaos (Ping timeout: 240 seconds) 05.04.04 # %we shouldnt go in the .sbs 05.04.10 # not that it makes any difference 05.04.43 # and comments should match the code :p 05.04.44 # # Disable the Status Bar 05.04.44 # %we 05.04.48 # wrong! 05.04.55 Join chaos [0] (~chaos@gentoo/user/ch4os) 05.05.05 # yes, I realized that about 40 minutes ago and changed it 05.05.41 # ah, so you want it on or off? 05.06.25 # on by the looks of it? 05.06.47 # yeah, I thought that I needed it on... 05.08.21 Quit tarbo (Ping timeout: 256 seconds) 05.09.46 # BlastTyrant: try putting the %pb in a viewport 05.10.51 # JdGordon: Did you ever do a postmortem examination of your clip+ bricking? ie do you have an idea what went wrong there? 05.11.44 # I didnt, but it was assumed that the OF needs some registers which our bootloader mangles 05.12.36 # You don't still have the patch you used by any chance? 05.14.34 # I dont, but I tinhk I just added some #if's for the clip+ 05.15.32 # Ok thanks, figured I'd at least ask before I try next...... 05.16.26 # talk to funman before fiddling 05.18.16 # BlastTyrant: I think I know whats happening. the default viewport isnt cleared when entering the WPS, because if it was the sbs would be overwritten, which also means the wps backdrop isnt being drawn into that area 05.18.26 # so putting it into a new viewport should fix it 05.20.19 Join Blast_Tyrant [0] (~Dan@cpe-74-70-177-91.nycap.res.rr.com) 05.22.48 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 05.22.48 Quit tarbo (Changing host) 05.22.48 Join tarbo [0] (~me@unaffiliated/tarbo) 05.23.48 Quit BlastTyrant (Ping timeout: 260 seconds) 05.24.27 # Blast_Tyrant: did you see my replies? 05.26.24 # yes, YChat had some connection problem and killed my connection, but it should be fine now - I'm trying the new viewport now, but it'll take a few mins 05.29.12 Quit tarbo (Ping timeout: 264 seconds) 05.30.24 # hmm, no, it still clears too much of the area 05.33.46 *** Saving seen data "./dancer.seen" 05.33.52 # crap, I tihnk I know whats happening (really this time) 05.34.54 # yeah, this is a real bug 05.34.57 # The new viewport doesn't seem to fix it, but I'll fiddle with it a litte more 05.35.12 # no, its my fault, you shouldnt need to do anything 05.36.11 # is this be from r24336 then? the display->clear_display() line? 05.36.21 # i was looking at that earlier 05.37.54 # no, that was all changed again 05.38.37 # well no. Becuase of orering that is the actual issue 05.38.46 # but removing that probably wont fix anything 05.40.30 Quit fdinel (Read error: Connection reset by peer) 05.40.36 Quit Strife89 (Quit: Bed.) 05.40.53 # interesting, where are we doing signed division in rockbox before we even hit the splash screen? 05.41.23 # setting up viewports maybe? 05.42.13 # JdGordon: and the other question, i have a rather large test set with operands of all sizes, so how do i have an error i've not caught? :/ 05.42.48 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 05.42.48 Quit tarbo (Changing host) 05.42.48 Join tarbo [0] (~me@unaffiliated/tarbo) 05.44.06 Quit JdGordon| (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.44.42 Join Strife89|Desktop [0] (~Strife89@adsl-220-102-33.mcn.bellsouth.net) 05.44.44 # * Unhelpful had better disable the signed divider on armv5+ until he finds the problem 05.47.21 # New commit by 03jdgordon (r24435): make sure skins always draw with their backdrop, otherwise the backdrop only changes on a full redraw which usually ends up being in the wrong order 05.47.32 # Blast_Tyrant: that commit fixes your problem 05.47.53 Quit tarbo (Ping timeout: 240 seconds) 05.50.26 # New commit by 03unhelpful (r24436): Some sort of issue in the signed divider is causing Gigabeat S to abort on startup, disable this routine until it's fixed. 05.54.02 # HAHA, I just noticed the forum description for the "User interface" sub forum. nothing but 3 NODO's and heated debate topics :p 05.59.36 Join ball [0] (~ball@adsl-99-151-140-83.dsl.emhril.sbcglobal.net) 06.02.46 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 06.02.46 Quit tarbo (Changing host) 06.02.46 Join tarbo [0] (~me@unaffiliated/tarbo) 06.08.51 Quit tarbo (Ping timeout: 272 seconds) 06.22.45 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 06.22.45 Quit tarbo (Changing host) 06.22.45 Join tarbo [0] (~me@unaffiliated/tarbo) 06.26.17 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 06.28.44 Quit tarbo (Ping timeout: 252 seconds) 06.41.11 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 06.42.52 Join tarbo [0] (~me@unaffiliated/tarbo) 06.45.52 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.1.75) 06.46.49 Quit S_a_i_n_t (Read error: No route to host) 06.46.50 Quit S_a_i_n_t_ (Read error: Connection reset by peer) 06.47.53 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.5.248) 06.50.12 Quit tarbo (Ping timeout: 264 seconds) 06.57.05 Quit S_a_i_n_t (Ping timeout: 240 seconds) 07.04.00 Join n1s [0] (~n1s@210.19.59.3) 07.04.00 Quit n1s (Changing host) 07.04.00 Join n1s [0] (~n1s@rockbox/developer/n1s) 07.05.53 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 07.05.53 Quit tarbo (Changing host) 07.05.53 Join tarbo [0] (~me@unaffiliated/tarbo) 07.12.17 Quit tarbo (Ping timeout: 240 seconds) 07.15.04 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 07.15.20 Quit saratoga (Quit: Page closed) 07.30.34 Join JdGordon| [0] (~Miranda@c-24-22-210-83.hsd1.wa.comcast.net) 07.30.34 Quit JdGordon| (Changing host) 07.30.34 Join JdGordon| [0] (~Miranda@rockbox/developer/JdGordon) 07.33.47 *** Saving seen data "./dancer.seen" 07.33.51 Quit n1s (Quit: Lämnar) 07.46.37 Quit gevaerts (Killed (NickServ (GHOST command used by gevaerts_!~fg@195-144-092-187.dyn.adsl.xs4all.be))) 07.46.46 Join gevaerts_ [0] (~fg@rockbox/developer/gevaerts) 07.50.44 Join tarbo [0] (~me@unaffiliated/tarbo) 07.51.59 Quit Zarggg (Read error: Connection reset by peer) 07.52.06 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 07.57.28 Join Horscht [0] (~Horscht2@p4FD4CE08.dip.t-dialin.net) 07.57.28 Quit Horscht (Changing host) 07.57.28 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.59.18 Quit kadoban (Read error: Connection reset by peer) 08.00.24 Quit tarbo (Ping timeout: 264 seconds) 08.00.59 Join kadoban [0] (~mud@cpe-24-93-17-195.rochester.res.rr.com) 08.07.07 Quit wind (Quit: CGI:IRC (EOF)) 08.11.30 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 08.11.30 Quit tarbo (Changing host) 08.11.30 Join tarbo [0] (~me@unaffiliated/tarbo) 08.18.11 Quit tarbo (Ping timeout: 252 seconds) 08.23.38 Quit RusselKubes (Quit: Ex-Chat) 08.23.48 Quit Horscht (Quit: Verlassend) 08.28.55 Quit ball (Quit: Lost terminal) 08.31.09 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.31.09 Quit Zagor (Changing host) 08.31.09 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.31.29 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 08.31.29 Quit tarbo (Changing host) 08.31.29 Join tarbo [0] (~me@unaffiliated/tarbo) 08.31.53 Quit TheSeven (Ping timeout: 240 seconds) 08.34.48 # I assume this isn't meant to be spat out by PHP at the top of the themes site? "Warning: zip_read() expects parameter 1 to be resource, integer given in /home/themes/private/themesite.class.php on line 156" 08.37.54 Join ender` [0] (krneki@foo.eternallybored.org) 08.38.09 Quit tarbo (Ping timeout: 248 seconds) 08.39.57 Quit arbingordon (Read error: Connection reset by peer) 08.42.07 Quit thegeek (Read error: Connection reset by peer) 08.42.10 Join flydutch [0] (~flydutch@host66-209-dynamic.15-87-r.retail.telecomitalia.it) 08.44.36 Nick stooo1 is now known as stooo (~sto@f051001064.adsl.alicedsl.de) 08.44.51 Join PaulJam [0] (~Paule@p54BEDA74.dip.t-dialin.net) 08.47.13 Quit AndyIL (Ping timeout: 248 seconds) 08.51.30 Join tarbo [0] (~me@pool-173-75-5-88.pitbpa.fios.verizon.net) 08.51.30 Quit tarbo (Changing host) 08.51.30 Join tarbo [0] (~me@unaffiliated/tarbo) 08.53.06 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.54.04 Join AndyI [0] (~pasha_int@212.14.205.32) 08.58.20 Quit tarbo (Ping timeout: 252 seconds) 09.01.02 Join petur [0] (~petur@rockbox/developer/petur) 09.02.01 Quit andrewRB (Quit: Leaving) 09.03.57 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 09.09.40 Join RusselKubes [0] (~russ@pool-98-109-0-7.nwrknj.fios.verizon.net) 09.17.47 Quit elcan (Read error: Connection reset by peer) 09.19.30 # New commit by 03pixelma (r24437): Update German translation including minor fixes - be more accurate about 'shuffle' (not 'random') and fix some occurences of wrong spaces. 09.20.47 Join Bagder [0] (~daniel@static-213.88.151.242.addr.tdcsong.se) 09.20.47 Quit Bagder (Changing host) 09.20.47 Join Bagder [0] (~daniel@rockbox/developer/bagder) 09.23.41 # New commit by 03pixelma (r24438): Update German translation including minor fixes - be more accurate about 'shuffle' (not 'random') and fix some occurences of wrong spaces. 09.23.53 Join elcan [0] (user36@pr0.us) 09.24.03 # * pixelma nags about the branch info once more but has to leave 09.24.04 Quit JdGordon| (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 09.24.49 Quit RusselKubes (Quit: Ex-Chat) 09.33.50 *** Saving seen data "./dancer.seen" 09.40.23 Quit phanboy4 (Ping timeout: 272 seconds) 10.14.37 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 10.16.14 Nick gevaerts_ is now known as gevaerts (~fg@rockbox/developer/gevaerts) 10.19.11 Quit elcan (Ping timeout: 252 seconds) 10.22.48 Join elcan [0] (user36@pr0.us) 10.36.26 Join kugel [0] (kugel@141.45.194.218) 10.36.26 Quit kugel (Changing host) 10.36.26 Join kugel [0] (kugel@rockbox/developer/kugel) 10.37.18 Quit kugel (Read error: Connection reset by peer) 10.37.28 Join DerPapst [0] (~DerPapst@wlan-nat-24.fh-friedberg.de) 10.37.34 Join kugel [0] (kugel@141.45.194.218) 10.37.34 Quit kugel (Changing host) 10.37.34 Join kugel [0] (kugel@rockbox/developer/kugel) 10.42.36 Quit kugel (Ping timeout: 265 seconds) 10.43.49 Quit BHSPitMonkey (Quit: Ex-Chat) 10.47.31 Quit shai (Read error: Connection reset by peer) 10.47.41 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 10.47.53 Quit shai (Client Quit) 10.51.21 Join S_a_i_n_t [0] (~st.lasciv@203.184.0.86) 11.00.25 Join LinusN [0] (~linus@gateway/web/cgi-irc/labb.contactor.se/x-mvxeijxtpvvuwxuq) 11.00.26 Quit LinusN (Changing host) 11.00.26 Join LinusN [0] (~linus@rockbox/developer/LinusN) 11.06.31 Join kugel [0] (kugel@141.45.207.152) 11.06.32 Quit kugel (Changing host) 11.06.32 Join kugel [0] (kugel@rockbox/developer/kugel) 11.09.33 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.14.49 Quit bluebrother (Ping timeout: 246 seconds) 11.16.35 Join bluebrother [0] (~dom@g224236020.adsl.alicedsl.de) 11.16.35 Quit bluebrother (Changing host) 11.16.35 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.32.35 Join Suit_Of_Sables [0] (~Suit_Of_S@c-65-96-112-171.hsd1.ma.comcast.net) 11.33.06 # I wish I still had my iPod 5.5G T_T 11.33.35 # damn encoded firmware 11.33.52 *** Saving seen data "./dancer.seen" 11.37.11 Quit FlynDice (Remote host closed the connection) 11.45.32 Join Frampis [0] (famas@noppakerho.com) 11.57.54 Join Horscht [0] (~Horscht2@p4FD4DE2D.dip.t-dialin.net) 11.57.54 Quit Horscht (Changing host) 11.57.54 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 11.59.16 Quit DerPapst (Read error: Connection timed out) 12.01.58 Join DerPapst [0] (~DerPapst@wlan-nat-24.fh-friedberg.de) 12.02.20 Join MethoS- [0] (~clemens@134.102.106.250) 12.05.03 # is there a way to customise the splash screen and the USB icon that's displayed when the player is connected to a computer? 12.07.25 # yes, but you have to edit the rockbox source code. 12.07.33 # what target do you have? 12.07.37 # I was afraid of that :P 12.07.56 # I have a "dock connector" USB icon i made for ipod. 12.08.43 Join wanttoknow [0] (~7a05aa05@giant.haxx.se) 12.10.25 # I was thinkin I'd crop an approppriate sized version of this: http://human3rror.com/wp-content/uploads/2008/10/bloodyusb.jpg 12.10.45 # but since the graphics are hardcoded I'm not going to bother 12.11.07 # that's a lazy way of looking at it :P 12.11.15 # I can't code at all 12.12.48 # neither could I until I learnt how :D 12.14.59 # That image would be pretty hard to pull off, but not impossible. 12.16.25 # Frampis: this is my "USB Connected" logo at the moment http://imgur.com/VhYbf.png the magenta shows as transparent on the DAP screen. 12.22.00 # I'd probably just make it fil the whole screen, I'm too lazy to photoshop it 12.22.06 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.22.21 # but I'm not going to do it anyways because it's hardcoded :P 12.29.14 Quit Suit_Of_Sables (Quit: Suit_Of_Sables) 13.02.41 Join _zic [0] (~user@91-165-227-92.rev.libertysurf.net) 13.06.38 Quit Blast_Tyrant (Ping timeout: 265 seconds) 13.17.49 # if someone is bored - I think the target names table on http://www.rockbox.org/wiki/LangFiles needs updating 13.21.39 # can Zagor's script be used? 13.24.36 # no idea. But while you are here: could you change the CIA bot settings so it also announces the branch? I saw it in other channels and I think it would be good to know while we are committing to the release, www, and the mdct (?) branch 13.24.53 # That is a god idea 13.25.20 # (and trunk of course) 13.26.35 # er, good idea :) 13.33.53 *** Saving seen data "./dancer.seen" 13.35.12 Join David [0] (~770b1218@giant.haxx.se) 13.35.37 Nick David is now known as Guest89113 (~770b1218@giant.haxx.se) 13.36.19 # Upgrading New Rockbox version issue 13.36.49 # more info needed 13.37.06 # CIA is probably Zagor's business, I haven't fiddled with that 13.38.43 Quit bzed (Read error: Connection reset by peer) 13.40.01 Join Sajber^ [0] (~Sajber@c-9c3471d5.012-155-73746f22.cust.bredbandsbolaget.se) 13.41.37 # Upgrading my Toshiba F60 to the new Rockbox from the old rockbox version the first upgrade didn't seem to work so I started again but thought I should uninstall the rockbox AND bootloader first to start fresh. Used the Rockbox utility to do this and all seemed fine. Tried to reinstall everything but now Rockbox Utility cannot recognise the Toshiba. When turninf off the Toshiba text on the unit states 'Rockbox boot loader, Version 3.0, loading firmware, 13.44.43 Quit Zarggg_ (Read error: Connection reset by peer) 13.45.08 Join bzed [0] (~bzed@devel.recluse.de) 13.45.52 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 13.55.43 Quit Guest89113 (Quit: CGI:IRC (EOF)) 13.57.07 Nick evilnick is now known as S_A_N_T (~evilnick@rockbox/staff/evilnick) 13.57.23 Nick S_A_N_T is now known as evilnick (~evilnick@rockbox/staff/evilnick) 14.02.25 Quit evilnick (Quit: Leaving) 14.07.23 Quit MethoS- (Remote host closed the connection) 14.13.58 Join maruk [0] (~papier@titanium.sdv.fr) 14.27.18 Quit _zic (Quit: Ex-Chat) 14.37.17 Join casainho [0] (~chatzilla@87-196-110-177.net.novis.pt) 14.40.40 Join phroggyman [0] (~187b533e@giant.haxx.se) 14.44.54 Quit petur (Read error: Connection reset by peer) 14.45.14 Join petur [0] (~petur@rockbox/developer/petur) 14.46.23 Quit petur (Read error: Connection reset by peer) 14.46.59 Join petur [0] (~petur@rockbox/developer/petur) 15.04.50 Part LinusN 15.07.29 Join Blast_Tyrant [0] (~Dan@cpe-74-70-177-91.nycap.res.rr.com) 15.09.10 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 15.23.01 Join funman [0] (~fun@rockbox/developer/funman) 15.23.49 # FlynDice: the patch JdGordon used didn't restore GPIOA_DIR before branching to OF, the rest looked correct so I suppose it was the problem 15.33.55 *** Saving seen data "./dancer.seen" 15.40.40 Quit PaulJam (Ping timeout: 240 seconds) 15.46.13 # Hmm. If I skip ahead tracks while in the debug buffering screen, the useful data count doesn't go down 15.46.25 # i would expect it to drop by one track's worth.. 15.46.47 # track count goes down, but nothing else changes 15.48.32 # i see what you are trying to do here. I noticed the same 15.49.09 # oh, wait, it does the same if i skip *not* in the debug screen 15.49.13 # that seems.. wrong :) 15.49.21 # if usefl goes down while playing then it should also go down while skipping 15.49.36 # and yes, you can probably guess what i'm trying to do :) 15.49.48 # not actually *your* bug, though, just testing it with DMA 15.49.54 # but then again, the pause also appears when I did not skip any songs. 15.49.58 # oh 15.50.11 # and there i though i was the center of the universe 15.51.03 # no, some people have reported the same happening with DMA 15.52.04 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 15.52.52 # i think it might be a CPU priority issue, though. As increasing the anti-skip buffer did not solve my issue (I assume the people reporting the DMA issue are actualy experiencing the same issue as I) 15.54.36 # possibly, but they are also messing around with crazy combinations of patches 15.54.44 # e.g. not boosting during buffering, or using the gui boost 15.55.43 Quit phroggyman (Quit: CGI:IRC (EOF)) 15.57.17 # i stoped using custom builds a while ago, now I only use current builds 15.57.49 # incidentally you *might* actually find that DMA makes your problem go away :) 15.58.09 # because buffering with DMA means the buffering thread can yield while the DMAs are inprogress 15.58.10 Join casainho_ [0] (~chatzilla@87.196.185.244) 15.58.42 # i can't reproduce your problem, btw 15.58.45 # i just tried it 15.58.56 # huge album art theme, and equaliser running 15.58.59 # with just 5s antiskip 15.59.04 # and it works fine over rebuffer 15.59.08 # I have DMA on, though :) 15.59.16 # what theme were you using? 15.59.27 # fullscreen 15.59.36 # hm... weird indeed... 15.59.47 # not weird, if it's just cpu starvation.. 15.59.57 # as i said, ata dma reduces cpu usage :) 16.00.11 # what's the size of your 16.00.15 # cover.bmp? 16.00.19 # no idea 16.00.26 # whatever picard downloaded for me from amazon 16.00.28 # huge, i expect 16.00.31 # mine are 240x240 16.00.35 Quit casainho (Ping timeout: 256 seconds) 16.00.36 Nick casainho_ is now known as casainho (~chatzilla@87.196.185.244) 16.02.07 # 500x500 apparently 16.02.11 # at least for the album i was using 16.02.12 # is it a bmp? jpeg costs more to decode but might actually be cheaper if you're scaling down by a large factor, because of the 1/8 scale-on-decode 16.02.14 # jpeg 16.02.25 # i myself use bmp 16.02.39 # i use whatever picard happens to download automatically, so hey :) 16.02.40 # bmp will be more i/o of course ;) 16.03.03 # i use 240x240 bmp because that's what my wps uses 16.03.31 # also, i normally have antiskip set to a minute :) 16.03.36 # i reduced it to 5s for this though 16.03.43 # but it'll still skip on rebuffer. If I use cabbie (default theme), no skipping. 16.03.53 # and cabbie uses what? 100x100? 16.04.05 # i think so. 16.04.57 # * Unhelpful wonders if the jpeg loader is yielding on unscaled loads... or the bmp loader for that matter 16.05.25 # anyway it definately sounds like a cpu issue 16.05.33 Join MethoS- [0] (~clemens@134.102.106.250) 16.06.16 # the scaler yields. the bmp loader does not, and it does not call the scaler if you're loading a file of the desired size... or at least that's how it looks 16.06.22 # aha :) 16.06.39 # where's the code? 16.06.51 # you and your programming jibberish :p 16.06.55 # apps/recorder/bmp.c 16.07.45 # Heh 16.07.55 # Horscht: Try resizing one of your album arts to be bigger 16.08.01 # and see if that makes the problem go away :) 16.08.18 # that would pretty much prove it 16.08.50 # one? Wouldn't I need to resize it all? 16.09.12 # * Torne was assuming you'd test it by just playing one album 16.09.18 # :) 16.09.48 # hm... I usualy just random play all my library... but for that purpose i think i can make an exception... 16.10.05 # i assume it does it frequently/every time? 16.10.26 # every time 16.10.39 # right. then any old single album that's bigger than the buffer will do ;) 16.10.46 # the scaler yields per line read.... erm, processed? 16.10.59 # Unhelpful: yah, someting like that 16.11.22 # i guess "large bitmap which is coincidentally the right size" is probably the worst latency case for AA loading 16.11.23 # now... where did I put my ipod? 16.11.24 # Torne: i wrote it.... but i just double-checked. ;) 16.12.55 Quit wanttoknow (Quit: CGI:IRC (EOF)) 16.14.10 # damnit, i wish my ipod had a phone built in... I could ring it and find it that way 16.15.18 # Horscht: they make an ipod like that, you know. ;) 16.15.29 # but I can't run rockbox on it 16.18.44 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 16.20.56 Quit Sajber^ (Read error: Connection reset by peer) 16.24.13 # well, at least it also happens with my insanely oversized folder.jpg coverart 16.24.24 # oh, it does? 16.24.35 # that might still be it, i guess 16.24.47 # depends if the jpeg loader is yielding *enough* 16.24.56 # yes, but that is insanely oversized (1800x1800) 16.25.01 # Right 16.25.15 Quit bmbl (Ping timeout: 246 seconds) 16.25.17 # So even with the "free" scale down the rest of the work might be too much to do in one go without yielding more often than it does 16.25.47 # trying a 250x250 bmp or similar might be very interesting though still 16.25.59 # I am gonna try a moderately oversized jpg and then bmp, though 16.29.41 Quit casainho (Read error: Connection reset by peer) 16.32.31 # jpeg, 300x300 = same 16.32.35 # now for bmp 16.33.23 # same? 16.33.25 # you mean it still skips? 16.33.56 # yes 16.33.59 # still skips 16.38.42 # weird... 300x300 bmp did not 16.38.57 # Ok, that's an interesting data point :) 16.40.31 Quit panni_ (Read error: Connection reset by peer) 16.40.52 Quit funman (Quit: free(random());) 16.42.43 # the resizer yields between each row of the bitmap 16.43.16 # (not sure if that's input row or output row but either way that's 250+ yields) 16.43.19 # that probably helps :) 16.43.30 # it's interesting that jpeg doesn't fix it though 16.46.49 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.49.33 Join fyrestorm [0] (~nnscript@cpe-24-90-81-175.nyc.res.rr.com) 16.52.44 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 16.55.07 # Torne: the scale_h_* functions are called per input row 16.55.14 # maybe move the yield from there to the loaders? 16.55.39 # maybe, but if jpeg also doesn't work.. 16.56.30 # * Torne can't reproduce this problem at all with jpeg album art 16.56.49 # i can't easily get any bitmaps at the moment :) 16.57.03 # and my build has full DMA enabled which might well mask the problem anyway 16.57.09 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.57.48 # Horscht: I'm probably going to be committing the buffering cacheline alignment changes soon, which will mean that almost all buffering reads will be done with DMA on ipod 16.57.55 # this might well make your problem go away :) 17.00.52 # but it would be nice to work out what it is anyway.. 17.02.45 # anyone have an opinion on whether the buffering cacheline alignment stuff should be ifdef'ed or not? :) 17.06.41 Quit kugel (Ping timeout: 258 seconds) 17.11.59 Quit krazykit (Ping timeout: 256 seconds) 17.13.15 Join krazykit [0] (~kkit@70.236.75.75) 17.15.12 Join jobec [0] (paulus@viherharakka.cs.tut.fi) 17.17.09 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 17.19.37 # evening. i ran a couple of battery tests on clipv1 (of and rb). if these results seem relevant, would it be possible to get a write access on wiki? 17.20.03 # anyone who demonstrates they're a human being by asking for it ca nhave write access, yes :) 17.21.31 Quit krazykit (Ping timeout: 260 seconds) 17.22.33 Quit MethoS- (Remote host closed the connection) 17.25.52 Join MethoS- [0] (~clemens@134.102.106.250) 17.29.04 # jobec: What is your wiki name? 17.29.38 # JouniPaulus 17.30.43 # jobec: OK, done 17.31.15 # thanks 17.31.25 # no problem 17.33.58 *** Saving seen data "./dancer.seen" 17.39.56 Quit Bagder (Quit: It is time to say moo) 17.41.06 # New commit by 03b0hoon (r24439): Packard Bell Vibe 500: add the simulator 17.41.06 Join bmbl [0] (~Miranda@92.39.27.243) 17.41.07 Quit bmbl (Changing host) 17.41.07 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 17.42.39 Join Res1 [0] (~Res@adsl-067-034-129-222.sip.mco.bellsouth.net) 17.42.49 Join krazykit [0] (~kkit@70.236.75.75) 17.48.02 # gevaerts/people in general: do we like code that's fractionally smaller or code with less ifdefs? :) 17.48.39 # kugel expressed the desire to have the buffering alignment stuff without the ifdefs; this technically makes the code slightly bigger on targets which don't care.. 17.51.24 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 17.56.34 # Torne: what does "slightly" mean? 17.57.41 # some number of bytes? :) 17.57.58 # if the compiler were superhumanly powerful it would optimise almost the whole lot away when the storage align mask was 0 17.58.19 # not very big 17.58.43 Quit petur (Quit: work->home) 17.59.18 Join guest [0] (~7aa72fd6@giant.haxx.se) 18.00.09 # i dunno, i've not compiled it to compare ;) 18.00.26 # the patch is tiny, and even if it failed ot optimise it out it'd only be a few dozen instructions at worst 18.00.39 # (and it makes buffer handles one word longer) 18.00.45 # I think that's acceptable 18.00.55 # I'd do it without ifdefs then 18.01.14 # it should work for other targets which would like stuff to be aligned properly, also :) 18.01.26 # even if they don't actually require it, it might be faster? depends how their caches work 18.02.49 # * Torne ponders doing horrible things with the gcc return address intrinsic and logf to track down commonly used unaligned buffers :) 18.04.01 # hello, i want to add an option "shut down" to home screen of current theme. CAN ANYONE PLS HELP! 18.06.16 # i have been asking this question here for last three days.. is the question too dumb? 18.06.55 # I at least don't understand what you want to do (and haven't seen this question before) 18.07.42 # thanks for replying.. in a few themes, I have seen an option "shut down" at the home (the page where files, database, all options are there) 18.07.58 # the "home screen" being the main menu, or the "while playing screen" ? 18.08.09 # my current theme doesnt have that, and theme owner doesnt want to add it.. so i thought i would myself add that for me 18.08.21 # can you list one that has it? 18.08.27 # also, hm, where shohuld the definition of the storage alignment go? dreamlayers has it in config.h (the top level one, not target specific) 18.08.33 # yes, main menu.. pardon me for my less knowledge 18.08.33 # yes, 1 min 18.08.43 # it's not really a target specific parameter, it's determined by the chip type/DMA config/etc 18.08.49 # guest: http://www.rockbox.org/tracker/task/6733 18.08.52 # http://themes.rockbox.org/index.php?themeid=31&target=ipodvideo 18.08.57 # is config.h the right place for that kind of thing? 18.10.07 # seems it requires the patch from JdGordon's link, not just a theme 18.10.44 # @JdGordon, thanks for link, i will try to apply patch on my ipod's rockbox 18.10.59 # which i am sure wont be an easy task! 18.11.00 # :) 18.11.02 Quit guest (Quit: CGI:IRC) 18.11.05 # yes, it is not anything to do with the theme, it's just that patch. The theme author took the screenshot on a build with that patch :) 18.11.15 # ah 18.11.47 Join guest [0] (~7aa72fd6@giant.haxx.se) 18.12.01 # [18:10] yes, it is not anything to do with the theme, it's just that patch. The theme author took the screenshot on a build with that patch :) 18.12.03 # [18:10] ah 18.12.30 # thanks Torne.. 18.12.45 # let me try that out.. you guys here for some more time? till then i would try appyling patch 18.13.13 # you have to compile from source 18.13.43 # ooops :( so i would be required to hv some maven/svn client at my laptop, right? 18.13.52 # let me find out instructions to do so somewhere on the rockbox site 18.14.32 # guest: http://www.rockbox.org/wiki/SimpleGuideToCompiling 18.14.47 # guest: and http://www.rockbox.org/wiki/WorkingWithPatches 18.14.53 # thanks mc2739 18.14.57 Join Omlet [0] (omlet05@91.176.176.213) 18.16.46 # New commit by 03torne (r24440): Align addresses in the buffering code to STORAGE_ALIGN_MASK if the target has one. ... 18.17.25 # * Torne thinks he could've worded the commit comment for that more awkwardly if he tried. Maybe. :) 18.17.41 # * Torne also expects this will ruin the "All 158 builds are OK" record :) 18.20.21 # ooh, it worked 18.20.45 # binsize increase is up to 208 bytes 18.20.52 # but that's mostly only on the targets that actually need it 18.21.08 # the ones that don't are <150 bytes 18.21.47 # hm, how much space is still left on the ondio rombox? 18.22.13 # dunno, but this doesn't affect hwcodec 18.25.12 # well, it did. but probably rather because of that gcc randomness 18.25.39 # Yah 18.28.33 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.29.16 Join tarbo [0] (~me@unaffiliated/tarbo) 18.30.40 # there's more than 50% difference between a battery runtime benchmark on my clip v1 (1GB) vs the one done by JouniPaulus (clip v1, 2 GB) 18.31.55 # He ran the benchmark with 256 kbps mp3 and I did it with 160 kbps ogg, could this explain the huge difference? 18.31.58 # i noticed that myself, too. but still the experiences without taking time have been in the same order 18.32.56 Quit maruk (Quit: Leaving.) 18.33.09 Join Kitr88 [0] (Kitr88@BSN-142-79-79.dial-up.dsl.siol.net) 18.33.57 # i can run it again after recharging for verification 18.34.05 Join JdGordon1 [0] (~jonno@173-138-6-212.pools.spcsdns.net) 18.34.38 # jobec, I believe you even without verification 18.34.49 Quit Kitar|st (Ping timeout: 265 seconds) 18.35.49 Quit tarbo (Ping timeout: 252 seconds) 18.35.54 # hmm 18.36.10 # The buffer align thing for dma might be useful on coldfire as well 18.36.26 # There it would be sufficient to aligh stuff to even address 18.36.37 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.37.00 # Torne: the image readers will probably be doing lots of reads to unaligned buffers - iirc the layout when scaling is bmp struct, output bmp buffer, decode and read buffers, scaler buffer 18.37.11 # Right now we don't do dma, but we could. It wouldn't be faster, but it would free cpu cycles 18.37.30 # buffering is already aligned to four without setting STORAGE_ALIGN_MASK 18.37.57 # Unhelpful: and yes, that's the kind of thing i'm going to investigate 18.37.59 # jobec, just makes me wonder: is it the codec? or the battery itself? or the fact that mine is 1GB and yours is 2GB? 18.38.06 # Unhelpful: but it's only relevant when the buffer is bigger than a sector 18.38.08 # DMA is only possible for even alignment though, since the coldfire dama engine cannot split words 18.38.32 # I do remember the 1 GB clips being a bit different than the 2 GB and bigger clips 18.38.58 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 18.39.07 # amiconn: well, you could take advantage of the stuff i'm doing then :) 18.39.15 # can someone commit 10945? 18.39.21 # bertrik: MP3 is significantly more demanding than vorbis on ARM. That combined with the higher bitrate... 18.39.33 # Torne: ah. that might be a non-issue, then... bmp uses an on-stack read buffer that is sized, at maximum, to hold a screen row of 32-bit values. jpeg uses a *much* smaller read buffer, 256B i think, though we could easily make it sector-sized and aligned if it would speed things up. 18.39.49 # Unhelpful: if it's less than a sector it reads into the cache in file.c and then copies from there 18.40.01 # Unhelpful: obviously the cache in file.c needs to be aligned :) 18.40.03 # which i've not done yet 18.40.04 # amiconn, but would that account for more than a 50% runtime difference? 18.40.17 # idk 18.40.24 Join Bullet` [0] (~Bullet@AMontsouris-159-1-54-45.w92-128.abo.wanadoo.fr) 18.40.37 # Depends on how much power the cpu draws compared to the other components 18.40.50 # Torne: sector == 512B? if we're still speaking of a reasonable size we could round the buffers for both up to sector sizes... 18.42.40 # I'll start a clip v1 battery benchmark playing mp3 tonight then 18.42.47 # and jpeg should probably yield per row-passed-to-scaler when scaling, and per MB-row when not, i would think... if not scaling the reader itself is surely where the heavy lifting is happening 18.43.11 Quit DerPapst (Quit: Leaving.) 18.47.13 # bertrik: the default clock on samsas is high enough to do ogg/mp3 without boosting at all, so the difference should be subtle (if any) 18.47.43 # Unhelpful: that might *also* be worth doing, yes, but that's kinda a seperate thing 18.48.08 # and it's not just sector *sized* reads, it's sector aligned reads :) 18.48.10 # Torne: worth hacking a test into test_disk if sotrage_align_mask > ? 18.48.35 # kugel: I have an expanded crazy test_disk that messes around with raw sector accesses, i might commit that at some point 18.48.51 # but yes, it probably should also use storage_align_mask instead of just assuming that 4-byte-aligned is enough 18.48.51 # yea, why not 18.49.05 # (to both :) ) 18.49.09 # well the "why not" would be "because the write speed part of the test overwrites bits of your disk" 18.49.11 Join tarbo [0] (~me@unaffiliated/tarbo) 18.49.30 # I assumed that my freshly formatted ipod had nothing useful outside of the first 1mil sectors so I just arbitrarily told it to write over the rest :) 18.49.32 # kugel: That's not true if the core has an efficient sleep implementation 18.49.44 # Torne: that can be done quite easily for the jpeg reader - it does disk reads to fill a buffer, which is processed via a getc-type interface 18.50.00 # does anyone have an idea what could have caused that massive ramsize fluctuation in r24417 on nano2g? 18.50.02 # right. 18.50.13 # Unhelpful: I could *also* instrument the file code to find out where we are not doing zero copy IO 18.50.23 # amiconn: any idea if we have that? I think we use the generic sleep (which all arm except pp do?) 18.50.30 # we'd need people to run these builds and give their logf results back though 18.50.39 # since just me doing it is not going to reflect all use cases :) 18.51.03 # Unhelpful: anyway i'm not going to do this, like, now. :) 18.51.29 # * Torne waits to see if anyone discovers their player burning to the ground after the DMA stuff first :) 18.51.40 # especially the pp502x devices that nobody actually tried ;) 18.52.08 # kugel, amiconn: I don't believe the dramatic effect of the codec yet, but we'll see what happens when I run another runtime benchmark 18.52.09 # pp502x is my daily DAP 18.52.17 # TheSeven: You mean G4 greyscale? 18.52.27 # JdGordon1: which, though? 18.52.33 # mini2g 18.52.37 # i'm pretty sure it works on most/all the ipods 18.52.47 # but afaik nobody ever tested the 9708 patches on non-ipods 18.53.02 # well, I tested it quickly on my samsung 18.53.09 # amiconn: don't get what you mean? 18.53.10 # nag me this evening and I can test on a e200 18.53.20 # well, it's enabled for all pp502x, and it should now be being used for 95%+ of buffering reads 18.53.25 # so if there's a problem i'm sure we will hear about it :) 18.53.33 # [18:50:02] does anyone have an idea what could have caused that massive ramsize fluctuation in r24417 on nano2g? 18.54.04 # The table shows such fluctuation for ipod G4 greyscale, not nano G2 18.54.17 # oops, yes 18.54.29 # well, anyways, what could cause such a thing? 18.54.41 # investigate :) 18.55.13 # the build system isn't totally reliable yet so I tend to blame that 18.55.13 # * Torne votes "wizards did it", since no code changed 18.55.19 Quit tarbo (Ping timeout: 260 seconds) 18.55.23 # That build was built on saratoga's machine. Maybe there's something special about the compiler? 18.55.32 # It's the standard version though... 18.55.46 Join saratoga [0] (~9803c6dd@gateway/web/freenode/session) 18.55.46 Quit saratoga (Changing host) 18.55.46 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-jvqiuerqlgaexlou) 18.55.55 # GSOC2010 has been announced 18.56.15 # we should probably make an effort to promote it, gather ideas for prospective projects, etc 18.56.23 Join DerPapst [0] (~DerPapst@p4FE8FF61.dip.t-dialin.net) 18.56.41 # * kugel wants to participate this time 18.56.48 Quit kaniini (Ping timeout: 248 seconds) 18.56.49 # are we going to bother? 18.57.15 # i've heard from a few current SVN members about applying, so I hope so 18.57.27 # we havn't really had much luck with gsoc, and it is a PITA 18.57.33 # sure we have 18.57.39 Join webguest50 [0] (~4f883f79@giant.haxx.se) 18.57.40 # WMA, Cook, ATRAC3 codecs 18.57.47 # are you saying 2009 wasn't a success? 18.58.06 # trick someone into the rockbox-as-an-app thingy 18.58.14 # that would be kugel 18.58.24 # huh? 18.58.33 # that's my fallback at least :p 18.59.06 Join evilnick [0] (~0c140464@rockbox/staff/evilnick) 18.59.10 # also MOB and HID were GSOC projects 19.00.43 # maybe this year we'll get lucky and get someone interested in more MPEG codec work too 19.00.48 # MP3 and AAC could use cleaning up 19.01.04 # so we get one good one per year and 2 or 3 mostly flops 19.01.08 # is cleaning up gsoc worth? 19.01.18 # yes I think so 19.01.29 Join funman [0] (~fun@rockbox/developer/funman) 19.01.30 # i'd like to see the ffmpeg MP3 decoder merged into libmad 19.01.40 # and the ffmpeg aac decoder replacing most of libfaad 19.02.01 # better mp3 is by far the most widely used codec, its also one of the least efficient in rockbox 19.02.14 # embedded AA! 19.02.21 # and lyrics support 19.02.26 # saratoga: isn't it the oldest codec designed ? 19.02.33 # raap would be interesting since it (imo) involves cleaning up sim stuff (=refactoring into the target tree) and touchscreen improvements 19.02.38 # you mean oldest format or oldest in rockbox? 19.02.45 # oldest format 19.02.47 # replacement mp3 based on ffmpeg would be more glorious than polishing the current one 19.03.01 # afaik mp3 was the "first" codec on archos :P 19.03.09 # saratoga: Not entirely true. It's less efficient than vorbis *on arm*. On coldfire it's the other way round 19.03.16 # I have bought I toslink cable and it planing to record from Spotify, but I don't understand presplit gap. And which record config is the best for recording from Spotify? 19.03.22 # on x86 the ffmpeg mp3 decoder is only marginally faster then libmad, so i tend to think its worth merging 19.03.47 # amiconn: yes but thats not due to algorithmic efficiency, but due to brute force EMAC power in the QMFs 19.04.06 # i would prefer to have an algorithmically we designed decoder as it will benefit all targets 19.04.27 # and anyway tremor would destroy libmad on coldfire were it to make reasonable use of EMAC 19.04.30 Join pamaury [0] (~pamaury@ALyon-551-1-89-37.w92-137.abo.wanadoo.fr) 19.05.08 # "i would prefer to have an algorithmically we designed decoder as it will benefit all targets" -> "i would prefer to have an efficient decoder, as that will benefit all targets" 19.05.22 # sorry trying to do two things at once 19.05.34 # So why didn't someone interested in vorbis do it? 19.05.46 # no one has coldfire targets anymore 19.06.03 # I could also have a step on porting rockbox to that yh-j70 19.06.17 # i need to get a CF target actually 19.06.47 # amiconn: that reminds me, if you get a chance would you benchmark the new IMDCT library on coldfire (preferably with WMA but vorbis will work too) 19.06.49 # * amiconn has several, but isn't really interested in vorbis 19.07.12 Quit JdGordon1 (Ping timeout: 265 seconds) 19.07.24 # the new library should be pretty easy to optimize for CF, but will take some ASM as GCC fails quite badly on ARM, and so probably CF too 19.07.39 # GCC knows nothing about coldfire emac 19.08.01 # the biggest issue is actually just the butterflies, not EMAC 19.08.08 # gcc completely screws them up 19.08.41 # the new lib is pretty close to the lowest known multiply count for a fourier transform, which is why PP gains so much from it 19.09.14 Join tarbo [0] (~me@unaffiliated/tarbo) 19.09.21 # the hand optimized ASM is > 2x faster then the gcc generated code for the pure load/butterfly/store sections 19.09.34 # I don't understand much of the i(m)dct business, but at least for 2d, a straight, "brute force" idct using emac is more efficient than a butterfly implementation on coldfire afaiu 19.10.00 # since gcc thinks arm like it when you load operands one at a time, store them, and then load them again for the next butterfly 19.10.43 # amiconn: an imdct is basically just an N point 1D FFT with N (or maybe 2N I forget) multiplies before/after 19.11.23 # the new algorithm is nice in that it has much lower add/mul/load/store counts then the old (although addressing is somewhat uglier) 19.11.30 Join JdGordon| [0] (~Miranda@nat/microsoft/session) 19.11.30 Quit JdGordon| (Changing host) 19.11.30 Join JdGordon| [0] (~Miranda@nat/microsoft/x-dfsvfwyxlfljkbqv) 19.12.00 # I.e. coldfire doesn't profit from lowering the multiply count, it profits most from balacing and fusing multiplies and adds 19.12.25 # yeah that makes sense 19.12.40 # hey, how can i get 3.4 released code using svn? 19.12.55 # but i think the real issue with all the transform codecs on CF is just that gcc does a terrible job at the bufferflys, and they're all in c 19.13.07 # guest: checkout the v3_4 tag 19.13.08 Quit webguest50 (Quit: CGI:IRC) 19.13.17 # the lack of EMAC is probably the second biggest issue 19.13.23 # I suggest to wait for 3.5 though which is due tomorrow 19.13.27 # A mac.l is single cycle (albeit with 3 cycles latency), and a mac.l with parallel load is 2 cycles. The loading part of the latter is more efficient than pre-loading operands with movem.l (as that needs n+2 cycles for n regs) 19.14.12 # ohh, is it only tomorrow! great. but the code wud be frozen by now, right? ;) can i get link to that pls..will download n apply shutdown patch 19.14.19 # An ordinary muls.l / mulu.l in turn needs 3 cycles... 19.14.42 # also interesting, on PP WMA 192k (with the awful multiplier) is faster then MP3 192k on CF (using all EMAC) 19.14.52 # guest: just checkout branches/v3_5 instead of trnk/ 19.14.55 # trunk* 19.15.43 # you mean i shoudl type in: "svn co svn://svn.rockbox.org/rockbox/v3_5 rockbox" 19.15.48 # right? 19.15.53 # no 19.15.54 # in spite of WMA using a lot of DRAM while CF can fit mp3 almost entirely into IRAM 19.16.06 # svn co svn://svn.rockbox.org/rockbox/branches/v3_5 rockbox 19.16.31 Quit tarbo (Ping timeout: 252 seconds) 19.16.40 # Looks like we need to rethink iram allocation on PP5020 in almost all codecs 19.16.41 # okay, 1 more question. to apply that patch, i can survive by downloading only the rockbox leg.. not the complete tree, right 19.16.58 # Then it should be possible to get it much closer to PP5022 speed 19.17.16 # the full tree 19.17.18 Join domonoky [0] (~Domonoky@g229100041.adsl.alicedsl.de) 19.17.18 Quit domonoky (Changing host) 19.17.18 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 19.17.48 # bcoz i dont need code for rockbox utility... 19.17.53 # Arrays which are frequently accessed (in loops) and are small enough to fit completely in the cache should go into dram 19.18.07 # kugel: I'd say that whether or not cleanup is OK for gsoc depends on who does it. I don't think I'd agree with someone new doing that sort of thing 19.18.19 # It seems that PP5020 has the inverse effect of PP5002 (although to a lesser degree) 19.18.25 # Could someone try a manipulation on his device ? The requirement are: dircache available. Ability to do a custom build. 19.18.58 # While on PP5002 the cache is broken (one waitstate for every access), iram seems to be slightly slower (read: broken) on PP5020 19.19.25 Quit flydutch (Quit: /* empty */) 19.20.37 # Only large arrays should go into iram (since accessing iram is of course still faster than cache misses) 19.20.52 # kugel: do you still want to revert matsch commit in branch ? 19.20.59 # yes 19.21.28 # I would also like to revert it in trunk, since it's in fact broken for all other targets 19.22.25 # pamaury: nobody here to test something ? 19.22.25 # are you sure of the fix ? there's not much time to test it now ;. 19.22.48 Join _zic [0] (~user@91-165-227-92.rev.libertysurf.net) 19.25.30 # funman: do you mean me? 19.25.59 # I've reverted it locally once and it didn't show the brokenness 19.26.37 # iirc you didn't revert it completely but just moved some code 19.29.13 # no, I reverted it when bisecting the exact cause 19.29.29 # what you mean is when I tried to fix it without completely reverting 19.30.01 Join tarbo [0] (~me@unaffiliated/tarbo) 19.30.23 # * pixelma tries summoning Zagor 19.31.53 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.34.00 *** Saving seen data "./dancer.seen" 19.37.09 # could someone try a manipulatioin on his device ? It requires a small change in one file + a recompilation of the firmware only + rebuild of tagcache database. Should take less than 5 minutes 19.37.19 Quit tarbo (Ping timeout: 260 seconds) 19.37.30 # amiconn: isn't IRAM cached on PP5020? 19.38.25 # or perhaps that is the difference, IRAM is cached on PP5022 and not on PP5020 19.38.40 # pamaury: I can have a go 19.38.58 # saratoga: Nope, and it wouldn't make sense 19.39.17 # gevaerts: Ok. So first, you have to add #define LOGF_ENABLE in firmware/common/dircache.c (juste before the #include "logf.h") and recompile 19.39.20 # @kugel : its taking too long to download.. i know thats written on the webpage.. but cant we include this patch in to the upcoming build as well or its left for a reason 19.39.21 # IRAM is single-cycle sram on PP, as is the cache 19.39.31 # It even can't be cached iirc 19.39.57 # amiconn: IRAM is cached on PP5024 19.40.10 # It's not 19.40.10 # there is a performance advantage, see http://daniel.haxx.se/sansa/memory_controller.txt 19.40.25 # "Combining both cache and iram seems to be the fastest combination (it probably can do something in parallel on the HW level)." 19.41.03 Quit robin0800 (Remote host closed the connection) 19.41.12 # That doesn't mean iram is cached 19.41.16 # guest: maybe you can leave out bootloader/, rbutil/, manual/ and uisimulator/ but you aren't going to save much download (everything is compressed before transfering anyway) and you need to checkout the other subfolder speparately 19.41.26 # amiconn: ah you are right 19.41.28 # just misread it now 19.41.36 # It cannot be cached. The cache controller only handles addresses below 0x40000000, and iram is fixed at that address 19.42.01 # well if it's as fast as the cache, it would be even a bad idea to cache it 19.42.31 # yep 19.42.39 # kugel: presumably the IRAM is only 32 bits wide, so it could not service both COP and CPU at the same time for instance 19.42.42 # Well, unless it doesn't work as designed... 19.42.52 # kugel: what build are you running? 19.42.59 # rc right now 19.43.02 # @kugel yes, me downloading complete package.. just that even compiling would take similiar (enormous) time, unless its fast.. 19.43.17 Join Buschel [0] (~ab@p54A3EBF2.dip.t-dialin.net) 19.43.28 # i have a old generation laptop :( to add to all this 19.43.31 # It seems that getting it right took them at least 3 tries (public tries, there may have been even more internal ones) 19.43.36 # you don't save compile time by only downloading half of the source. it would just fail 19.43.43 # the PP5003 19.43.58 # kugel: can you get a svn going and see if you see any background wierdness? apparently it was broken for a few days, I fixed it but I dont know if it will leave artefacts on the screen in dead areas 19.44.17 # it apparently had improved cache over the pp5020 19.44.37 Join Tomis2 [0] (~Tomis@70.134.83.196) 19.44.49 # honestly though after all this AMS fun i am looking back at PP more kindly, they certainly could have done worse (by making the IRAM slower then DRAM for instance) 19.44.49 Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 19.45.02 # funman: nothing changed in buffering.c since then so reverting should be safe 19.45.11 # The 5003 was in interim version between PP5002 and PP5020 iiuc. It had the cache issue fixed; I don't know whether it has the iram issue we observed on PP5020 19.45.17 # PP5022 has that fixed as well 19.45.19 # @kugel i agree, i hope we can compile only 1 target.. i.e. the player and that too only for ipod.. 19.45.19 Join kaniini [0] (~kaniini65@dyn75-70.yok.fi) 19.45.30 # saratoga: if we had docs we would love all PP probably 19.45.37 # ha 19.45.48 # B4gder: for the release builds, do you want to build them? or just copy them from someone? I can do a full set in 15min or so 19.45.51 # i remember those posts from the ecos guy who had the docs 19.45.55 # assuming we are ready to release later today? 19.45.58 # he said something like "everything in the docs was a lie" 19.46.16 # it has many gpio, fast caches and fast and many iram, a very useful user timer 19.46.18 # * amiconn wonders what happened to the port involving the new PP thing 19.46.28 # the sansa view? 19.46.35 # Obo vanished 19.46.35 # Something 6000-ish 19.46.56 Quit Tomis (Ping timeout: 248 seconds) 19.46.56 Nick Tomis2 is now known as Tomis (~Tomis@70.134.83.196) 19.48.07 # i like the Nano2G chip, fast IRAM, faster ARM core, and somehow still an order of magnitude more power efficient then PP/AMS 19.48.15 # shame sandisk didn't use it instead 19.48.17 # pamaury: ok, new build installed. What am I looking for? 19.48.58 # saratoga: ams was probably very cheap 19.49.04 # yeah probably 19.49.17 # plus the integrated DRAM 19.49.20 # even the s3c2440 is the better soc, even though it's a lot older 19.49.50 # but anyway, what i was getting before was that I bet mp3 on CF could be a lot faster even than it is if we improved the design of the decoder 19.49.54 # * amiconn likes coldfire more than this arm stuff 19.50.01 # gevaerts: now, you have to do the following. (**) First go into database and start to play a playlist. Then stop it. (**) Go into settings->system->database->Intialise Now. Go into debug menu and wait until the databse build is finished. (**) Go back into database and play ANOTHER playlist. (**) 19.50.18 # gevaerts: (**) means "go to debug menu and copy the content of logf buffer" 19.50.23 # and in fact, the ams choice didn't have an effect for the users (except the improved sound quality), the OF feels the same 19.50.25 # Ideally they should have chosen a SoC with proper cache though 19.50.33 # whats the advantage of CF over ARMv5E where you have the single cycle MAC? 19.50.42 Join jgarvey [0] (~jgarvey@cpe-065-190-068-017.nc.res.rr.com) 19.51.30 # Coldfire emac is more flexible, and it has more registers available 19.51.47 # * gevaerts enables dircache and starts again 19.52.05 # gevaerts: I looking for a dircache error: "fd access error" 19.52.09 # *I'm 19.52.10 Join tarbo [0] (~me@unaffiliated/tarbo) 19.52.12 # Coldfire also has a division instruction 19.52.19 # how many registers does CF have? 19.52.55 # i always though ARM9E was basically perfect for audio, fast loads/stores, single cycle DSP instructions, short pipeline, available with fast IRAM from some vendors 19.52.57 # It has 8 address and 8 data registers. The pc is separate, so that makes one more reg than arm 19.53.16 # The emac has 4 accumulators in addition to that 19.53.18 # plus gcc can target the MAC unlike CF 19.53.23 # anything speaking against lowering the minimum "disk_spindown" to 1 second? during the standard buffering process the HDD-spwindown should be as low as reasonable. I also would like to change default spindown from 5 to 2 seconds. Are there use cases that need 5 seconds spindown delay? 19.54.00 # saratoga: short pipeline? didn't v5 have a increased pipeline again? 19.54.09 # The accumulators are 48 bit, and it can handle fixed point directly 19.54.38 # 3 on arm7, 5 on arm9tdmi, 9(?) on arm9e ? 19.55.13 # still 5 IIRC 19.55.43 # amiconn: whats the advantage over mulal on ARM? isn't it still one cycle for the mul, and one for the shift? 19.56.14 # Buschel: Spinning down too often is bad for the hdd. And when buffering, rockbox does quick spindown anyway 19.56.37 # mulal? 19.56.45 # multiply long accumulate 19.56.58 Join Grahack [0] (~Grahack@ip-222.net-82-216-222.rev.numericable.fr) 19.56.59 # You men smlal/umlal? 19.57.02 # *mean 19.57.07 # oh maybe 19.57.24 Join moos [0] (moos@85-171-102-158.rev.numericable.fr) 19.57.35 Quit moos (Changing host) 19.57.35 Join moos [0] (moos@rockbox/staff/moos) 19.57.40 # amiconn: ok, didn't know that there is a fast shutdown while buffering 19.57.50 # Buschel: 0.5 sec 19.57.56 # I'd also guess that cases of spinning down and up quickly is more power hungry than keeping the disk spinning for a little longer 19.58.06 # s/is/are 19.58.10 # amiconn: perfect :) 19.58.34 # IIRC arm can do 32x32+32 = 64 then shift off the top 32 bits in two clocks on arm9e, but i could be mistaken 19.58.47 # pamaury: no fd access errors seen 19.59.19 Quit tarbo (Ping timeout: 245 seconds) 19.59.30 # saratoga: some armv6 have 9-stage pipeline, maybe I confused it 19.59.31 # pamaury: full logf of the session at http://pastie.org/804567 19.59.45 # saratoga: The 32x32->64 take away two precious general purpose registers though (of which arm already has effectively one less than cf) 19.59.49 # gevaerts: thanks, I'll look at the log 19.59.51 # which is basically all i ever wanted for codecs, well that and a load multiple operation that can stride by a variable amount :) 20.00.03 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 20.00.18 # * amiconn would like 32 or even 64 general registers 20.00.19 Join mitk [0] (~594e0d92@giant.haxx.se) 20.00.26 # yeah MIPS would be nice 20.00.41 # the amount of work making butterflies fit in registers was really, really annoying compared to MIPS 20.01.01 # Well, we have some mips targets. Unfortunately they're all touchscreen crap^h^h^h^hstuff 20.01.12 # actually i would also like a hardware complex mul instruction with single cycle latency :) 20.01.46 # but i don't think we'll see 6 operand instructions any time soon on arm 20.02.14 # gevaerts: hum, are you at svn HEAD ? 20.02.18 # Well, coldfire emac with parallel load are 5-operand instructions... 20.02.31 # so it does a load and a MAC in one op? 20.02.36 # Hi. Can an dev review and maybe commit FS#10945? 20.03.08 # Yes (but not in a single cycle) 20.03.36 # CF seems neat, i need to get one eventually 20.03.36 # One cyccle review, second cycle commit? :) 20.03.38 # pamaury: should be, yes. I did run svn up before this 20.04.05 # mitk: unfortunately i don't know much about playlists, maybe get JdGordon to look at it? 20.04.22 # or stripwax 20.04.33 # gevaerts: That's strange, I would exact same log but with the error. Did you run the playlist like I told you ? Before AND after the database init ? 20.04.44 # mitk: hi, yeah I saw the patch and plan on commmiting tonight unless somenoe else can do it 20.04.55 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 20.05.07 # yes 20.05.19 Join kugel_ [0] (~kugel@e178084148.adsl.alicedsl.de) 20.05.38 # * pamaury doesn't believe gevaerts , the log says the contrary 20.05.45 # * gevaerts is at r24440 20.06.42 # JdGordon|: Is it worth to commit to the branch also? 20.06.51 # gevaerts: could you please retry ? The logf should display a line like "bind: 1//.rockbox/.playlist_control" between each dircache release at least. Here it's not the case 20.07.09 Quit kugel (Killed (NickServ (GHOST command used by kugel_!~kugel@e178084148.adsl.alicedsl.de))) 20.07.14 Nick kugel_ is now known as kugel (~kugel@e178084148.adsl.alicedsl.de) 20.07.16 Quit kugel (Changing host) 20.07.16 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.07.26 # mitk: maybe, it depends when we release, 20.07.43 Join ajb` [0] (~user@client-86-23-54-122.brhm.adsl.virginmedia.com) 20.08.00 # Understand. Bye. 20.08.04 Quit mitk (Quit: CGI:IRC) 20.08.14 # Hi, I've fixed a little bugget in the UI simulator code that broke bookmarks (and anything else that does a rename). 20.08.21 # http://www.rockbox.org/tracker/task/10954 20.08.39 # If a comitter could look at and commit that would be ace thanks :-) 20.09.31 # ajb`: heh, I found that too but I always thought it was a sim limitation 20.09.45 # commit! 20.10.09 # I would change strncpy to strlcpy before committing though 20.10.30 # Do you want me to submit a new one? 20.11.22 # yea 20.11.32 # Hmm, where do we define our strlcpy? 20.11.37 # it doesn't really matter I assume, but we don't use strlcpy in rockbox 20.11.40 # strncpy* 20.12.07 # ajb`: firmware/common/strlcpy.c 20.12.22 Quit Buschel () 20.14.27 # All the rockbox includes in the simulator seem to come from fireware/export/, should I create such an export for strlcpy? 20.14.49 # Or just include "firmware/include/strings.h" directrly 20.15.42 Join tarbo [0] (~me@unaffiliated/tarbo) 20.16.47 Quit jgarvey (Read error: Connection reset by peer) 20.18.25 # ajb`: string.h is included 20.19.13 Join perfectdrug_ [0] (~marko@p5B0EE9DE.dip.t-dialin.net) 20.21.56 # kugel: but not strlcpy according to my compiler.... 20.22.52 # it probably includes the system's string.h first 20.23.11 Quit tarbo (Ping timeout: 264 seconds) 20.24.11 # try changing to "string.h" 20.26.54 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 20.27.11 Quit GodEater (Read error: Operation timed out) 20.27.25 Quit JdGordon| (Changing host) 20.27.25 Join JdGordon| [0] (~Miranda@rockbox/developer/JdGordon) 20.29.28 Quit shaggy-h (Ping timeout: 240 seconds) 20.32.35 Quit amiconn (Killed (NickServ (GHOST command used by amiconn_))) 20.32.36 Quit pixelma (Killed (NickServ (GHOST command used by pixelma_))) 20.32.36 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 20.32.39 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 20.32.48 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 20.32.54 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 20.33.04 Quit kugel (Quit: exit(0);) 20.33.56 Join Farthen [0] (~chatzilla@e176132039.adsl.alicedsl.de) 20.34.08 # gevaerts: when you did, did you select custom playlist or did you play, say, an album directly from the database menu ? 20.35.27 Join AdB3 [0] (~44c7f9cf@giant.haxx.se) 20.35.45 # hi 20.36.07 Join jgarvey [0] (~jgarvey@cpe-071-070-228-143.nc.res.rr.com) 20.37.01 # could someone build the bleeding edge Windows Rockbox Utility for me??? 20.37.24 # The custom versions for the D2 are missing 20.37.50 Join tarbo [0] (~me@unaffiliated/tarbo) 20.37.58 Quit funman (Quit: leaving) 20.38.25 # n/m 20.38.29 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 20.38.37 Quit AdB3 (Client Quit) 20.44.19 Quit tarbo (Ping timeout: 245 seconds) 20.44.33 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 20.44.34 Quit GodEater (Changing host) 20.44.34 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 20.48.09 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.49.17 Quit saratoga (Quit: Page closed) 20.50.13 Part Llorean 20.51.41 # it appears the buffering "regression" was there before 20.52.31 # kugel: I am including "string.h", something else odd must be happening 20.54.44 Quit guest (Quit: CGI:IRC) 20.55.11 # fine, I won't revert r23680 as it appears it didn't cause the bug 20.55.23 # but we're going to have a sad "known issue" this time 20.58.28 # how rare is this? 20.58.41 # it does sound like a showstopped if its common 20.59.51 # probably not a show stopper 21.00.19 # I'm apparently the only one who even found it, even though it's 100% reproducable 21.00.35 # whats the repro? I'll try it here 21.00.41 # is it target dependant/ 21.01.05 Join tarbo [0] (~me@unaffiliated/tarbo) 21.01.40 # turn on "skip to outro" and skip to the last 5s of the song and skip back again 21.01.59 # it may work without skip to outro, but I have that always on 21.02.19 # funman reproduced it on his samsung (with 32MB ram) too 21.02.28 Quit S_a_i_n_t (Ping timeout: 272 seconds) 21.03.13 # and what happens if its hit? 21.03.29 # data abort, string corruption, freeze 21.03.33 # strange things 21.03.50 # not here 21.04.03 # r24365 21.04.59 # Suspects he needs to tweak the include directives to include firmware/include 21.05.49 # maybe just keep strncpy as it seems to just use the host OS functions anyway 21.06.17 # kugel: In that case the patch is ready to go as currently is in Flypsray 21.07.18 # Next question, if I want to ensure a bookmark is created when the USB is plugged in where would I do it? 21.07.52 Quit tarbo (Ping timeout: 252 seconds) 21.08.03 Quit kugel (Remote host closed the connection) 21.13.00 Join Stephen__ [0] (~S@86-45-89-221-dynamic.b-ras2.srl.dublin.eircom.net) 21.15.08 Quit Grahack (Quit: Tu m'as vu ?) 21.18.35 Join Casainho [0] (~chatzilla@87.196.185.244) 21.18.58 # domonoky: with the release coming up, how should we handle the D2? AFAICS the bootloader installation places the firmware file to the wrong drive 21.19.58 # is there a big warning to the user, that he has to move the file ? 21.20.33 # none that I noticed when installing it on an usb drive 21.21.02 # then we should perhaps disable d2 in rbutil for this release. 21.21.07 # there is also no notice to the user that the mountpoint selected has to be the sd card 21.21.37 # so while it's basically working it's nothing I consider suitable for the average user 21.21.49 # yeah, I was thinking about that too. 21.22.11 # jup, i think its not good to provide a "easy install tool" when it does wrong things for a target. 21.22.24 Join samlii [0] (~samlii@h-72-245-223-210.chcgilgm.static.covad.net) 21.23.11 Quit Farthen (Ping timeout: 264 seconds) 21.23.21 # how does Rockbox store what file and location is the current resume point? 21.23.27 # D2 users can still use svn binaries anyway 21.24.02 Join Farthen [0] (~chatzilla@e176140046.adsl.alicedsl.de) 21.24.02 Join tarbo [0] (~me@unaffiliated/tarbo) 21.24.48 # samlii: /.rockbox/.playlist_control 21.26.52 Quit efyx_ (Remote host closed the connection) 21.27.37 # * ajb` is confused as to why the USB code in wps is tucked into ffwd_rev() rather than the main loop 21.28.02 Join phanboy4 [0] (~benji@gate-22.spsu.edu) 21.29.39 # that is (presumably) so usb while its doing a ffwd or rewind works 21.29.48 # that is a secondary button loop 21.29.59 # the regular loop in wps.c handles usb 21.30.24 # New commit by 03bluebrother (r24441): Give the user a hint on where find the required bootloader file. 21.30.59 Quit tarbo (Ping timeout: 264 seconds) 21.31.22 # JdGordon|: Ahh yes, I see. 21.32.17 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 21.34.04 *** Saving seen data "./dancer.seen" 21.34.08 Quit stooo (Ping timeout: 272 seconds) 21.36.02 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 21.36.06 Quit jgarvey (Ping timeout: 252 seconds) 21.36.10 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 21.36.34 Join fml [0] (~5dd2dc30@giant.haxx.se) 21.38.16 # I have a small aestethic issue with the manual. Look at http://download.rockbox.org/daily/manual/rockbox-iriverh100/rockbox-buildch4.html#x7-380004.1.2 Do we need periods after the names of the menu items? 21.39.15 Join froggyman [0] (~sopgenort@pool-72-69-205-209.chi01.dsl-w.verizon.net) 21.39.21 # saratoga: xMULL is 3 cycles on arm9e, and the top word is not available on the next cycle. also as amiconn pointed out the low word will clobber a register. if you can keep the top bits of your constants clear (or wanted to use a signed mul in the first place) armv6 has a signed-only, top-word-only multiply 21.39.52 # ARMv6 is a bit better here 21.40.48 # It also has this 16bit simd stuff 21.42.11 # if one of the values only needs 16-bit precision, SMULWy is the best bet. it's available from arm9e up, it's one cycle to execute, one additional cycle result latency, and it gives you signed 32x16->48>>16 21.42.23 # fml: the idea was to end each description item with a full stop. This looks good in the pdf manual (imo). No idea why the html puts a line break there. 21.42.34 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 21.42.58 # amiconn: yes, the armv6 versions of the jpeg idct kill the competition, especially the small sizes. 21.43.32 # But the typical armv6 is overpowered for a dap 21.45.29 # fml: seems the line break is caused by the use of the
tag in the html output. Might be worthwhile to check how to remove that. 21.45.44 # bluebrother: id doesn't look good in the PDF manual IMO. I must have missed the discussion. A full stop marks a sentence. But those are not seentences. 21.46.35 Join tarbo [0] (~me@unaffiliated/tarbo) 21.46.38 # bluebrother: I've stumbled upon it in the PDF 21.47.36 # i'm starting to think that maybe i should make the jpeg coeff/idct buffer 32-bit values on armv4... although it only really makes a difference when i can load rows, loading columns from the buffer is always going to be 3c/load :/ 21.47.53 # I'm assuming the simulator should behave as the real target when "U" is pressed for USB insertion? i.e. sound stop playing 21.48.17 # yes 21.48.36 # fml: well, IMO a : looks even worse, and that is whats been used more often years ago. But some separator is needed. 21.53.42 Quit tarbo (Ping timeout: 252 seconds) 21.54.05 # what about a colon as a separator? 21.54.10 # fml: see http://www.rockbox.org/wiki/LatexGuidelines?rev=25#Descriptions -- this was added by me :o over 3 years ago 21.54.10 # or just a linebreak? 21.55.04 Join jgarvey [0] (~jgarvey@cpe-071-070-228-143.nc.res.rr.com) 21.55.52 # fml: Those periods also look odd to me. If there should be any punctuation, shouldn't it be a colon? 21.56.44 # well, a colon looks worse IMO. But I'm not actively working on the manual anymore, so if the active contributors decide that a colon would be better that's fine. 21.57.37 # suspects the queue broadcast isn't working properly in simulator mode, the threads only see the USB connection on the second toggle. 21.59.53 Quit yosafbridge (Quit: Coyote finally caught me) 22.00.01 # * TheSeven thinks the way it's being rendered in the html version, with the full stop removed, would look best, also for the pdf (so just using a linefeed as the separator) 22.00.03 # Unhelpful: The 3cycles only apply to arm7. arm9 is faster, even if it's a v4 22.01.42 Join yosafbridge [0] (~yosafbrid@adsl-71-142-225-118.dsl.scrm01.pacbell.net) 22.02.00 Quit yosafbridge (Client Quit) 22.03.01 # IMO it would look best without punctuation. No period, no colon. It's already marked clearly via formatting. 22.03.26 # fml: that's what I'm thinking (in the HTML view, haven't looked at the PDF) 22.03.49 Join yosafbridge [0] (~yosafbrid@adsl-71-142-225-118.dsl.scrm01.pacbell.net) 22.04.25 # TheSeven: I think it would look good in both 22.05.16 Join petur [0] (~petur@rockbox/developer/petur) 22.09.01 # amiconn: ah, i see that. is there any way to differentiate between arm7 and arm9 cores with armv4? 22.09.11 Join tarbo [0] (~me@unaffiliated/tarbo) 22.09.27 # anything with cp15 tells you exactly what it is; other than that it can be awkward 22.10.07 # How do recipients of queue_broadcast messages know who to send responses too? 22.11.32 # also, you'd mentioned that the multiplies killed any real chance of a swar efficiency gain on armv4... might removing the store between the add/sub part and the multiplies change that? it seems that unpacking the packed 16-bit values for the multiply could be rolled together with adding or subtracting them at fairly low cost 22.11.38 # pamaury: I think the first one was a single album 22.12.42 # pamaury: if you know exactly what I should get, why do you need a tester? ;) 22.13.27 # gevaerts: because I need to know if it's easily reproducible on another device. 22.13.55 # do you need another run? 22.14.11 # Unhelpful: #ifdef CPU_ARM7TDMI 22.14.14 # If you have time, I'll be very pleased that you try another time 22.15.25 # ok. So start playing from the database, stop, re-init the database, and play another thing? What sort of playlist should I make? 22.15.55 # I don't know. On my device I played an album. 22.16.01 Quit JdGordon| (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 22.16.04 Quit tarbo (Ping timeout: 252 seconds) 22.16.24 Quit phanboy4 (Ping timeout: 240 seconds) 22.16.41 # I'm not sure the type of the playlist is important but you should try an album also to be sure to have the same protocol 22.17.05 # fml: I'm not sure what I prefer 22.17.14 # should I skip through it to touch all tracks, or can I just stop soon? 22.17.18 # Also, catalog should be catalogue in UK English 22.18.30 # gevaerts: no just play and stop. Thinking about it, to stop it I just pushed the power button. Not sure it's important also. No need to skip tracks 22.18.43 # ok 22.19.16 # gevaerts: I'm still not sure about the reason of this "bug" but I have a theory 22.21.48 # pamaury: http://pastie.org/804834 22.22.36 # ah ! I'm happy with it 22.22.44 # * pamaury is happy to see a bug :) 22.23.02 # good. Can I go back to my jigsaw puzzle now? :) 22.23.35 # AlexP: "Catalog" in the manual is correct as it's what I see on the player :-) I.e. it should be corrected in both places. 22.24.16 # gevaerts: yes 22.24.20 # good luck 22.24.24 # Thanks! 22.26.47 Quit ajb` (Ping timeout: 264 seconds) 22.27.27 # I there's no punctuation after the item then we get a readable sentence since the sequel is in the "does" from. E.g. "Delete Deletes the currently selected file." 22.27.37 # *If 22.30.46 # And "Open with" should be capitalized (like on target) 22.31.43 Join tarbo [0] (~me@unaffiliated/tarbo) 22.33.56 Quit Zagor (Quit: Clint excited) 22.38.04 Quit tarbo (Ping timeout: 240 seconds) 22.47.50 Quit fml (Quit: CGI:IRC) 22.48.59 Quit _zic (Ping timeout: 264 seconds) 22.49.39 Join JdGordon_ [0] (~836b004a@rockbox/developer/JdGordon) 22.54.15 Join tarbo [0] (~me@unaffiliated/tarbo) 22.59.19 Quit Bullet` (Quit: Bye les gens =)) 23.01.07 # Slasheri: you was the one who wrote dircache isn't it ? 23.01.14 # *are 23.01.32 Quit tarbo (Ping timeout: 252 seconds) 23.05.10 # New commit by 03bluebrother (r24442): OSX: Add CFBundleName to display a nicer name in the menu bar. Replace deprecated CFBundleGetInfoString. 23.10.30 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.12.17 Quit JdGordon_ (Ping timeout: 248 seconds) 23.14.46 Join tarbo [0] (~me@unaffiliated/tarbo) 23.15.27 Join einhirn [0] (~Miranda@p54859E29.dip0.t-ipconnect.de) 23.18.31 Join JdGordon_ [0] (~836b004d@gateway/web/freenode/x-wfeiprbmsybudvgw) 23.18.52 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 23.18.56 # pamaury: yes, he wrote it 23.20.29 # did he also wrote tagcache 23.20.30 # ? 23.21.08 # slt, yeah he also did 23.21.28 # and he did wrote the software playback enginne at start 23.22.22 Quit tarbo (Ping timeout: 252 seconds) 23.23.30 # pamaury: I already say you this yesterday...already forgot? :) 23.24.04 # I was unsure, and it was a way to check if he was here or not ;) 23.25.31 # I need to talk with him about another dircache bug 23.25.40 # hehe, simply ping him :) 23.26.11 # Slasheri Slasheri Slasheri! :) 23.26.39 # also know as Flasheri by few here... 23.27.55 # Did someone look at "FS#10954 - UI Simulator fails to rename files correctly". The patch seems simple enough to commit it, no ? 23.28.49 Quit bmbl (Quit: Bye!) 23.30.58 Quit evilnick (Quit: Page closed) 23.31.52 # pamaury: yep, commit it if you want 23.32.06 Join PaulJam [0] (~Paule@p54BEE2F8.dip.t-dialin.net) 23.33.10 # JdGordon_: did you test it or you trust the fix ? 23.33.45 # neither :p but any simple fix is good 23.33.56 # im at work so cant look at it more than which file it touches 23.34.07 *** Saving seen data "./dancer.seen" 23.34.54 # haha JdGordon faithful to yourself 23.35.24 # JdGordon_: anyway, if rename doesn't work with the simulator, that patch can't be worse 23.36.27 Join tarbo [0] (~me@unaffiliated/tarbo) 23.43.27 Quit tarbo (Ping timeout: 258 seconds) 23.45.10 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 23.45.29 # New commit by 03pamaury (r24443): FS#10954: fix rename under simulator by Alex Bennee 23.46.09 Quit samlii (Quit: leaving) 23.46.57 # Meh, cache aliasing :\ 23.51.13 Quit JdGordon_ (Ping timeout: 248 seconds) 23.52.03 Join JdGordon_ [0] (~836b004a@gateway/web/freenode/x-hunylorkuhbvgdsr) 23.54.18 Join akur [0] (~akur@bl7-91-245.dsl.telepac.pt) 23.55.15 Quit GeekShadow (Quit: The cake is a lie !) 23.55.24 Quit jgarvey (Quit: Leaving) 23.57.53 Join tarbo [0] (~me@unaffiliated/tarbo)