--- Log for 08.01.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 19 hours ago 00.00.50 # no, dsp will ignore the message appently unless HAVE_SW_TONE_CONTROL is defined (apps/dsp.c) 00.01.44 # so that explains the sw precut problem 00.01.46 # oh, wait 00.01.58 # is the hw precut value inversed? 00.02.49 # if the maximum of all band gains, which becomes an attenuation 00.02.53 # s/if/it's 00.03.16 # oh, i interpreted it as a gain apparently :) 00.03.24 # lol 00.03.29 # that explains why it was worse than no precut at all :) 00.05.38 # works smoothly now :) 00.05.51 # (apart from a glitch when enabling tone control) 00.06.22 # the codec seems to mute the signal briefly while it powers up the DSP 00.06.31 # powering it down works glitch-free though :) 00.08.04 # New commit by 03theseven (r29001): Implement hold switch and headphone detection on iPod Classic 00.09.14 # New commit by 03theseven (r29002): Fix CS42L55 (iPod Classic) tone control 00.10.17 # r29001 build result: All green 00.12.35 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 00.13.03 # r29002 build result: 40 errors, 68 warnings (theseven committed) 00.13.07 # urgh 00.14.02 # now how did i break hwcodec!? 00.14.44 # oops 00.15.23 # that #define ATA_HAVE_BBT in ata.c looks strange 00.15.23 # something about lba48 00.15.40 # yeah, that's some patch that didn't belong there 00.15.46 # didn't mean to commit that file 00.16.01 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 00.16.46 # TheSeven: "ipod6g" could just have been in a comma seperated "list" 00.16.57 # (your change to english.lang 00.16.59 # ) 00.17.02 # good to know :) 00.17.17 Quit bertrik (Quit: :tiuQ) 00.17.31 # what with the huge red deltas all over? 00.17.48 # just a cosmetic issue though 00.18.37 # jhMikeS: maybe the same that broke hwcodec (non-lba48) targets? 00.19.04 # * jhMikeS finds it odd the tone control new need ata functions :) 00.19.24 # [00:15] yeah, that's some patch that didn't belong there 00.19.25 # [00:15] didn't mean to commit that file 00.19.39 # hehe 00.20.14 # that's my personal hard drive fixing patch :) 00.24.30 Quit sideral (Quit: Leaving.) 00.26.37 *** Saving seen data "./dancer.seen" 00.28.01 # * TheSeven should maybe put that on flyspray 00.34.28 # * jhMikeS 's H10 is still chugging along just fine, nothing weird 00.35.35 # New commit by 03theseven (r29003): Oops, that didn't belong in there. 00.38.00 # r29003 build result: All green 00.39.34 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.43.56 Quit TheLemonMan (Read error: No route to host) 00.44.42 # * TheSeven starts a test_codec run 00.45.09 # aache64 almost 3x realtime, that's nice :) 00.45.32 Join utanapischti [0] (~username@p4FF2DFB8.dip.t-dialin.net) 00.48.13 # * TheSeven wonders which "ape level" it will reach... 00.48.36 Quit sasquatch (Ping timeout: 240 seconds) 00.49.23 # hm, only 3000 00.49.24 Join TheLemonMan [0] (~lem0n@ppp-86-135.98-62.inwind.it) 00.50.22 # i'm sure it could be overclocked enough to handle 4000 :) 00.51.52 Quit {-phoenix-} (Remote host closed the connection) 00.52.13 # Huh, only? How fast is the 6g? 00.52.31 # 216MHz 00.52.44 # and it's 95% realtime 00.53.14 # Ah ok 00.53.30 # Somehow I thought that it was faster... spoiled by the beast ;) 00.53.38 # :) 00.53.54 # The beast (barely) handles ape -c5000 00.54.35 # (at 44.1kHz 16 bit stereo that is - 48kHz would be too much already) 00.55.06 Quit TheLemonMan (Quit: free(me)) 00.55.13 # * TheSeven would like to know if the ipod nano 4g can handle c5000 00.55.49 # what will tell you the ape encoding type? I have a file I was testing with but don't know what it is because I used the first program available that would make ape files and maxed it. 00.56.15 # lemme see... 00.56.20 # On ARMv6 you need ~500MHz to do that, ~285MHz on ARMv7 00.57.38 # On ARMv5 you'd need roughly 1GHz for realtime -c5000 00.57.39 # it's an ARM1136 and i'd expect it to handle some 500MHz 00.57.59 Quit guymann (Quit: one more try...) 00.58.01 # they apparently re-used an ipod touch SoC in that one :) 00.58.36 # Apparently the beast needs 470MHz for -c5000 decoding - and it's an ARM1136 too 00.58.46 # damn, i need to restart the test, some cpu clocking define wasn't accurate 00.59.36 # but that 1GHz for c5000 on ARMv5 can't be right 01.00.02 # the classic was somewhere at ~30% realtime with 216MHz 01.00.23 # and that's an ARM926ej-s 01.01.13 # According to my latest table the Cowon D2 (TCC7801 @192MHz) would need 944MHz for realtime. 01.01.45 # It certainly depends on ram timing, because the filter array for -c5000 is larger than the cache 01.02.36 # Btw, a PP5002 would need 4GHz for realtime -c5000 ;) 01.04.41 Part domonoky 01.04.46 # because of that cache bug? 01.06.00 # Partly. Another reason is that it's arm7 01.06.09 # A PP502x would need ~2.8GHz 01.06.47 # * TheSeven wonders why test_codec thinks the CPU would be running at 192MHz 01.09.04 # c4000 would need 226.3MHz 01.10.27 # ape is using pure convolution fir filters? 01.13.55 # http://wiki.multimedia.cx/index.php?title=Monkey%27s_Audio says they are iir filters 01.14.24 # New commit by 03moos (r29004): pitch detector: Fix a typo in a comment. 01.14.35 # They are of high order, and for -c5000 there are 3 layers of filtering 01.15.09 # 16th, 256th and 1280th order 01.16.37 # r29004 build result: All green 01.19.07 # hm, so for ape the encoding effort is basically identical to the decoding effort? 01.19.28 # yes 01.19.31 Join MethoS- [0] (~clemens@134.102.106.250) 01.20.51 # hm, is it normal that the cook test_files fail with "cannot read metadata"? 01.21.16 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 01.21.21 # flac 8: 7.36MHz :) 01.21.59 # hm, no, actually 8.3MHz due to the wrong clock value 01.22.37 # c'mon, flac puts CPU cycles back 01.30.11 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.30.58 Quit factor (Ping timeout: 260 seconds) 01.39.08 Quit GeekShadow (Quit: The cake is a lie !) 01.45.39 Join factor [0] (~factor@75.108.68.114) 01.46.04 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 01.46.55 # test_codec results: http://pastie.org/1438984 01.51.32 Join guymann [0] (~charles@66-159-148-95.adsl.snet.net) 01.52.41 Quit DerPapst (Read error: Connection reset by peer) 01.53.20 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 02.00.55 # * jhMikeS wonders if filter calculation order can be redone to keep it cache local (doing it in segments) 02.03.39 # flac5: 6.83MHz needed for realtime << insane 02.05.29 # New commit by 03theseven (r29005): Adjust iPod Classic CPU clock speed constants to at least roughly correct values 02.07.44 # * TheSeven wonders if real audio / cook being broken is a known bug 02.07.58 # r29005 build result: All green 02.09.53 Quit leavittx (Ping timeout: 255 seconds) 02.11.28 # TheSeven: fundamentally or just the decoder ? 02.11.51 # apparently the metadata parser 02.12.26 # * TheSeven wonders if that thing being broken fundamentally is a question at all 02.13.30 # TheSeven: I think I saw a related bug report listed in the recent tracker mail 02.13.52 # hm, neither "cook" or "real" yielded any result in the FS search 02.13.54 # about .rm files not working 02.14.41 # hm, it plays fine on my nano running r28818 02.14.53 # http://www.rockbox.org/tracker/11858 even by Buschel 02.18.47 # yes, it was broken recently 02.20.29 # sure looks like the fast ram is helping the classic's cpu be efficient :) 02.20.44 # vorbis < 20MHz at 128kbps :) 02.21.53 # amiconn: i posted a new tool patch in FS#7832 that worked for me on cygwin, i needed to install libiconv and g++ tho 02.22.01 # in case you want to test 02.26.40 *** Saving seen data "./dancer.seen" 02.30.27 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 02.32.14 Quit ender` (Quit: Eagles may soar, but weasels are seldom sucked into jet engines.) 02.36.36 Quit n1s (Quit: Lämnar) 02.47.55 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 02.53.29 Quit pamaury (Remote host closed the connection) 02.56.49 Join keith666 [0] (~5ec0ac4c@giant.haxx.se) 02.57.11 Quit Judas_PhD (Quit: This is a quitting message) 02.58.31 # Hi.... is there a way to change how rockbox handles volume events while locked? Using hdd6320 which by defauly allows volume changes while locked. Thanks 02.58.53 # (BTW when i say locked, i mean the Hold slider is in position) 03.01.40 # keith666: There's no setting for it, it would require you to change the code. 03.03.09 # I would be willing to look in to this, does the site have informaiton on modifying the source code? And if I did amend this then should I submit that somewhere so others can make use of? 03.04.05 # Rockbox only has a patch tracker for changes intended as overall changes, as in patches to be permanently applied, so you'd want to design it as such. The code is primarily in C, the site has the information you need to compile it 03.04.58 # The current general feeling seems to be that a hold switch is meant to prevent all accidental keypresses. I can't tell from your description if it's *not* preventing volume presses, or if it is but you want it not to. 03.05.01 # Thanks, I will look in to that as i'm sure others would appreciate such an option in there too 03.05.10 # Keep up the good work. Bye :) 03.06.34 # Apologies, for clarification: I want the volume to be changable while Hold is active, since it is like with with the OEM software 03.06.59 # It's unlikely such a change will be accepted. 03.07.32 # There's a lot of people who feel certain buttons should be available while hold is on (volume, possibly 'pause' for quick access) and that hold should only prevent a subset of actions, but the desires for which are pretty varied. 03.07.58 # It's also not generally accepted that the original firmware doing it is a strong reason (any feature should stand whether or not the original firmware does it) 03.08.40 # that's a fair point, I take it it's pretty much standard with iPods etc for hold to prevent volume control? 03.09.08 # It seems standard on i think every player I've handled, yes. 03.09.23 # Though I believe on some touchscreen players it disables the touchscreen but leaves physical buttons enabled. 03.10.23 # That's surprising, I've been using the same Philips 30gb for 4 years now and it works the opposite - looks like a learning curve will be my fastest way round this 03.10.30 # Again I appreciate the help, thanks 03.11.16 # You might want to look into replaygain 03.11.29 # Usually well replaygained tracks mean much less adjustment of volume - loud or soft tracks rarely surprise you. 03.12.19 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 03.13.45 # I will do, that's actually what I planned to move on to next :) 03.14.54 # It doesn't make up for environmental needs to adjust volume, but it could at least help. :) 03.22.40 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 03.28.42 # <[Saint]> WHo feels like giving me a casual reminder about where iPod Nano2G IRAM is defined? ;) 03.28.51 # <[Saint]> TheSeven: ^ ? 03.29.23 Join simonrvn_ [0] (simon@70.35.160.181) 03.32.07 Quit keith666 (Quit: CGI:IRC) 03.32.16 Quit simonrvn (Ping timeout: 240 seconds) 03.32.16 Nick simonrvn_ is now known as simonrvn (simon@70.35.160.181) 03.33.05 # [Saint]: I don't understand that question 03.33.18 # do you mean the core/codec iram split? 03.34.17 # <[Saint]> Sorry....I'm overflowing iRAM again, I forgot what we had to set it to to let AA fonts work, and where to define it. 03.34.26 # <[Saint]> grep skills seems to be failing me. 03.34.48 # hm, you have several options 03.35.03 # 1. take away some IRAM from the codecs and use it for the core (might slow things down) 03.35.15 # 2. reduce the main thread stack size a bit (might make it overflow) 03.35.35 # 3. reduce some other IRAM buffer size, or move e.g. the PCM double buffer to DRAM 03.36.59 # <[Saint]> I'm trying to remember how I handled it earlier, but...I can't. 03.37.00 # which option is the best one depends massively on the amount of iram you actually need to free 03.37.09 # <[Saint]> 80bytes 03.37.14 # i think we chose option 2 previously 03.37.27 # <[Saint]> I *think* so, yeah. 03.37.28 # yeah, 80 bytes can probably easily be taken off the stack 03.37.54 # that would be in firmware/target/arm/s5l8700/app.lds 03.38.03 # <[Saint]> well, I suppose it needs a little headroom also, it's overflowed by 80bytes. 03.38.09 # <[Saint]> and, thanks. 03.38.39 # so i'd change the stack size to 0x3f00 03.40.00 # <[Saint]> Hmmm...I think that was it. I was so certain I had kept the .diff but apparently not. IIRC it was moving the PCM double buffer to IRAM that "broke" it. 03.40.26 # <[Saint]> thanks again TheSeven, always helpful. 04.10.35 Quit chattr (Read error: Operation timed out) 04.11.08 Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) 04.16.45 Quit BlakeJohnson86 (Quit: Leaving.) 04.16.57 Quit Barahir_ (Ping timeout: 240 seconds) 04.18.48 Join Barahir [0] (~jonathan@frnk-590f48a4.pool.mediaWays.net) 04.22.04 Quit DerPapst1 (Quit: Leaving.) 04.22.07 Quit DerPapst (Quit: Leaving.) 04.24.51 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.26.19 Quit BlakeJohnson86 (Read error: Connection reset by peer) 04.26.43 *** Saving seen data "./dancer.seen" 04.36.15 Quit Rob2222 (Quit: Rob2222) 04.37.03 Join kisak [0] (~kisak@pool-72-70-187-188.hrbgpa.fios.verizon.net) 04.37.32 # evening 04.38.25 # what's the general status of car stereos that have a usb interface and possibly iPod support 04.38.45 # (to be used with rockbox) 04.39.15 # also, on a side note, you rock TheSeven 04.42.06 Quit pixelma (Disconnected by services) 04.42.08 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.42.10 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.43.36 Quit amiconn (Disconnected by services) 04.43.36 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.43.53 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.47.42 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.48.41 Quit BlakeJohnson86 (Read error: Connection reset by peer) 04.49.12 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.49.55 Quit BlakeJohnson86 (Read error: Connection reset by peer) 04.50.22 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.51.39 Join Strife89_ [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 04.53.12 Quit BlakeJohnson86 (Client Quit) 04.53.36 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 04.54.57 Quit TheSeven (Ping timeout: 240 seconds) 04.55.13 Quit BHSPitMonkey (Read error: Operation timed out) 04.57.18 Join eRivas [0] (~je@190.150.0.99) 05.00.17 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 05.16.13 Quit eRivas (Quit: Saliendo) 05.30.34 Join ZhangNing [0] (~ZhangNing@123.169.146.9) 05.30.43 Part ZhangNing 05.33.50 Join Rob2222 [0] (~Miranda@p4FFF2C9C.dip.t-dialin.net) 05.37.49 Quit JesusFreak316 (Ping timeout: 240 seconds) 05.43.28 Quit Strife89_ (Quit: Reboot.) 05.45.52 Join Strife89_ [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 05.47.59 Join webguest0447 [0] (~55ab5afe@giant.haxx.se) 05.48.13 # hello 05.48.40 # I need help please, if somone is around 05.50.15 # I'm trying to get vmware working well based on the image you shared on your wiki 05.54.11 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 05.54.46 Join ZhangNing [0] (~ZhangNing@123.169.146.9) 05.57.41 Quit parafin (Ping timeout: 276 seconds) 05.58.38 # anyone 05.58.40 # ? 05.59.08 Join parafin [0] (parafin@paraf.in) 06.00.54 # it seems that I couldn't have apt-get working with your shared image 06.03.49 Quit MethoS- (Remote host closed the connection) 06.09.13 Quit parafin (Ping timeout: 260 seconds) 06.10.13 # still sarge :( 06.11.26 Join parafin [0] (parafin@paraf.in) 06.24.27 Quit panni_ (Read error: Connection reset by peer) 06.26.45 *** Saving seen data "./dancer.seen" 06.29.01 Join Horschti [0] (~Horscht@xbmc/user/horscht) 06.30.20 # webguest0447: it's no treat to do that and aptitude worked better. then, you're troubles are just starting. I made an image though, but it's hardly optimal. 06.32.13 Quit Horscht (Ping timeout: 240 seconds) 06.32.58 # jhMikeS: wow, somone alive :) 06.33.22 # Hi, basicly I wanted to apt-get ccache for exemple, but kernel is very old...and I'm a noob 06.34.51 # that's pitty that you didn't take the oportunity to do more in your previous image update (according too the wiki, you made an update just a few before) 06.34.52 # upgrading that image sucked especially since non of the existing vmware tools worked with 5.0.4 06.35.34 # is there any goal to share it semi broken then? :) 06.36.06 # I did on the forum, but here along with a description of all the hardships :) http://jhmikes.cleansoap.org/debian-5.0.4-filelist.html 06.36.45 # Revision r84 - 12 Dec 2010 - 04:11 - MichaelGiacomelli :( 06.37.07 # coul you share it maybe for the wiki? 06.37.25 # a bump on my earlier question ... what are the odds of a car radio with usb(+ipod control) working with rockbox? 06.37.59 Quit parafin (Ping timeout: 276 seconds) 06.38.22 # that was the last image update an still * Debian 3.1 sarge *Linux kernel 2.4.27 06.38.50 # webguest0447: basically, that the link I'd provide cause that's where I'd leave it hosted unless soap tells me to yank it cause it so huge because the disk is probably fragmented enough that it kills the compression ratio 06.39.40 # hence the problem I get to update anything, since libc is too anciant, and I don't know how to upgrade it at hand 06.40.03 # compression ratio? on a vmdk? 06.40.20 # you still have those problems, even for a project that big? :) 06.40.37 # sharing problem I mean 06.40.38 # the compression of the 7z file is less because of all the package updating 06.42.10 # webguest0447: there was an apt-get bug as well that blocked progress, hence aptitude, which handled it all better 06.42.33 Join parafin [0] (parafin@paraf.in) 06.42.42 # but when I use aptitude, I still get this libc6 problem 06.43.04 # I canot install anything in this state 06.43.52 # I had that too iirc 06.44.01 # why not get the vm back to a sane state and just building your cross compile environment in the home directory of the regular user ... just forget about using the system's libc for whatever you want to do 06.44.26 # if it's a VM just for tinkering and/or building rockbox 06.45.04 Quit Keripo (Quit: Leaving.) 06.45.07 # All this because I want to install few more things primordial like ccache, libusb or mtp... 06.47.36 # what's the link to the vm on rockbox.org? 06.47.39 # webguest0447: nothing really worked without getting a new kernel on it and doing massive upgrading (so much stuff I hardly remember it all) 06.48.08 # kisak: which? the old or my munged version? 06.48.25 # jhMikeS: yes, the one in question 06.48.58 # yes? both were in question! old or munged? 06.49.21 # found that http://www200.pair.com/mecham/spam/kernel.html describe well my situation 06.49.56 # the old is in the wiki under development, the cruddy one, I just posted a few min ago 06.50.36 # will have a look thanks :) please put it on the wiki with a notice ;) 06.59.45 # real life calling? I will test your image jhMikeS, thanks to share it 06.59.52 # _? 07.00.22 # good bye 07.00.26 Quit webguest0447 (Quit: CGI:IRC) 07.13.37 # Buschel: FYI when you see this, the H10's been playing all night 07.14.20 Quit anewuser () 07.30.15 Quit Saij (Read error: Connection reset by peer) 07.48.48 # ipod nano 2g with rockbok running ... do ipod accessories work at all with this model? 07.49.01 Quit Judas_PhD (Quit: This is a quitting message) 07.50.42 # in any case ... I have a Clarion cz200 coming and I'll just have to find out 07.59.09 Quit ZhangNing (Remote host closed the connection) 08.16.00 Join T44 [0] (~Topy44@f048064109.adsl.alicedsl.de) 08.18.03 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 08.18.58 Quit Topy44 (Ping timeout: 240 seconds) 08.25.16 # jhMikeS: Btw, current debian testing/ unstable has open-vm-tools. If we want to stick with 'stable' for the image, we have to wait for the 'squeeze' release, which should happen soon 08.25.35 Quit Strife89_ (Quit: Sleeeeeeep.) 08.26.47 *** Saving seen data "./dancer.seen" 08.29.32 Join Topy [0] (~Topy44@f049111177.adsl.alicedsl.de) 08.32.38 Quit T44 (Ping timeout: 240 seconds) 08.42.36 Join sideral [0] (~sideral@unaffiliated/sideral) 08.52.33 Quit linuxguy3 (Ping timeout: 260 seconds) 08.54.27 Join linuxguy3 [0] (~timj@adsl-75-57-173-53.dsl.emhril.sbcglobal.net) 09.03.26 Quit kadoban (Ping timeout: 240 seconds) 09.08.45 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 09.09.42 Quit tchan (Ping timeout: 250 seconds) 09.29.16 Quit BHSPitMonkey (Remote host closed the connection) 09.38.16 Join Buschel [0] (~chatzilla@p54B672D1.dip.t-dialin.net) 09.41.24 Quit Judas_PhD (Quit: This is a quitting message) 09.43.05 # jhMikeS: my iPod Video also played the whole night through (w/o r28877). I need to find a way to reproduce this damn bug :/ 09.44.33 # TheSeven: nice test_codec results :) pretty fast. is the RAM using the CPU clock or is it limited to 100 MHz like on the 8700/8701? 10.00.49 Quit [Saint] (Disconnected by services) 10.00.51 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.25) 10.00.52 Quit factor (Ping timeout: 240 seconds) 10.02.04 # TheSeven: do you have any C code which does DMA transfer to the LCD IF for iPod nano 2g? 10.11.26 Join pjm0616 [0] (~user@110.9.28.187) 10.15.05 Quit froggyman (Ping timeout: 272 seconds) 10.21.19 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.23.57 # Buschel: Any idea why FS#8668 (24-80Mhz GUI Boost) stops Nano2G from building with an error in button-clickwheel.c? 10.24.24 # Sorry I haven't had time to do LCD testing stuff, had a full on day of real life interrupt 10.26.49 *** Saving seen data "./dancer.seen" 10.27.32 Quit parafin (Read error: Operation timed out) 10.28.32 # S_a_i_n_t: seems the patch must be resynchronized due to changes. wait a sec 10.32.01 # S_a_i_n_t: GUI boost (80 MHz) -> http://www.sendspace.com/file/3m310g 10.32.11 Join parafin [0] (parafin@paraf.in) 10.32.21 # S_a_i_n_t: GUI boost (100 MHz) -> http://www.sendspace.com/file/82gjj7 10.32.36 # those should work (if I did not forget to include a file) 10.33.07 # just give a short notice if it works. I will update FS then 10.33.16 # If you did, I'm guessing it won't be ipod-clickwheel.c so all should be well. 10.33.23 # ;) 10.33.58 Join {phoenix} [0] (~dirk@p57AA6C22.dip.t-dialin.net) 10.34.26 # I love this patch. It makes the GUI sooo responsive that it is a pain to use svn builds for testing purposes... 10.35.10 # Indeed. I haven't tried pushing the Colours up to 100Mhz yet, I only have one here...but I should give it a go. 10.35.33 # I got slightly disheartened by the Nano1Gs not clocking that high. 10.35.48 # well, the diff between GUI boost 80 vs. 100 MHz is not that much. the boost itself makes it 10.36.15 # 100 MHz are just "on top" to allow higher framerates for mpegplayer :o) 10.36.28 # yeah, I'm assuming that the higher clock saves more battery? Or is it the lower clock doing all the savings there? 10.37.40 # the lower clock saves the power for efficient codecs like flac/mp3/mpc. the higher clock should not have any measurable impact to battery life (even though HDD transfer rates are higher) 10.38.23 # Hmmm, right. I was wondering if the shorter CPU load times would have any measurable effect. 10.38.27 # But I guess not. 10.40.00 # no, they haven't. faster HDD load does not scale the average power consumption of the HDD 10.40.20 # even the massive speed up via ATA DMA did not have any measurable impact 10.40.39 # that seems quite odd. 10.41.01 # I guess they are just very efficient devices already. 10.41.09 # s/ver/reasonably/ 10.41.13 # &very 10.43.04 # I was confused by this fact, too. reason is that the HDD spinup sucks a lot of power, during read the HDD sucks less power. therefore reducing the read time did not scale the overall consumption that much 10.43.57 # you can calculate all this from some current measurements which dreamlayers did a while ago 10.44.52 # S_a_i_n_t: does the updated patch apply? 10.44.59 # It does, yes. 10.45.06 # and it works? ;) 10.45.09 # thanksyou. 10.45.16 # -s 10.45.22 # Yes, it seems to :D 10.45.57 # updated FS 10.46.52 Quit sideral (Ping timeout: 240 seconds) 10.47.33 Join leavittx [0] (~lev@ip-83-149-1-196.nwgsm.ru) 10.50.36 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.56.18 Join stoffel [0] (~quassel@p57B4A9D7.dip.t-dialin.net) 10.56.43 Join DerPapst [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 10.56.44 Join DerPapst1 [0] (~Alexander@91-66-226-46-dynip.superkabel.de) 10.59.02 Quit Buschel (Ping timeout: 240 seconds) 10.59.12 Nick Horschti is now known as Horscht (~Horscht@xbmc/user/horscht) 11.05.52 Join sampattuzzi [0] (~sam@92.26.118.28) 11.06.24 Join stooo [0] (~sto@f051079145.adsl.alicedsl.de) 11.18.14 Quit stooo (Ping timeout: 240 seconds) 11.25.42 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 11.25.43 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.25.52 Join Lear [0] (chatzilla@rockbox/developer/lear) 11.32.17 Join ZhangNing [0] (~ZhangNing@123.169.146.9) 11.33.03 # [09:44] TheSeven: nice test_codec results :) pretty fast. is the RAM using the CPU clock or is it limited to 100 MHz like on the 8700/8701? << absolutely no idea how it's clocked 11.33.45 # one of the chips used is the K4X51163PE, you might want to look at its datasheet 11.33.57 # [10:02] TheSeven: do you have any C code which does DMA transfer to the LCD IF for iPod nano 2g? << I don't think so 11.34.57 Join PurlingNayuki [0] (~PurlingNa@113.118.61.143) 11.35.51 # [10:43] I was confused by this fact, too. reason is that the HDD spinup sucks a lot of power, during read the HDD sucks less power. therefore reducing the read time did not scale the overall consumption that much << not true for the ipod classic 11.36.12 # the classic 80gb hdd actually sucks less power during spinup than during access 11.36.24 # idle is around 100mA, spinup like 250mA, access like 300mA 11.37.08 # * S_a_i_n_t blinks 11.37.16 # ow? just...how? 11.37.19 # *how 11.43.55 # it's spinning up rather slowly 11.54.04 Join Mystery_Keeper [0] (~Mystery_K@93.157.235.99) 11.55.52 # I still can't register on wiki. I've sent a mail to bjorn@haxx.se few days ago, and still nothing's changed. 11.58.17 Quit ZhangNing (Remote host closed the connection) 12.00.02 Nick 5EXAB0PYG is now known as [fred] (fred@ircop.efnet.at) 12.05.46 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.14.16 Nick [fred] is now known as fred_2 (fred@ircop.efnet.at) 12.15.57 Nick fred_2 is now known as [fred] (fred@ircop.efnet.at) 12.16.39 Nick S_a_i_n_t is now known as [Saint] (S_a_i_n_t@203.184.0.25) 12.26.52 *** Saving seen data "./dancer.seen" 12.30.30 Join kevku [0] (~kevku@2001:7d0:0:f000::135d) 12.41.58 Quit user890104 () 12.46.54 Join ruckus [0] (~Earworm@99-59-195-147.lightspeed.livnmi.sbcglobal.net) 12.49.07 # hey everyone, i have a ipod video 30gig model (although with a 160gb drive) developed some weird problems recently, so I am wondering if anyone knows about them. 2 issues mainly, i would play music and it would randomly freeze. i can tell that the firmware is still working because i can scroll the song back and forth and even browse normally although there's no sound, and the song doesn't progress even if i try to change it. 12.49.21 # i scanned it with chkdsk, and there were no errors of the hdd 12.49.27 # *on the hdd 12.49.36 # hm, ipod classic battery runtime is a shame! 12.50.12 # somewhere around 4 hours currently... 12.58.12 Join sideral [0] (~sideral@unaffiliated/sideral) 13.02.21 # <[Saint]> wow....where's all the juice going to? 13.02.39 # <[Saint]> 4 hours is...wel, yeah. I don't need to say it. 13.02.44 # <[Saint]> *well 13.03.07 Join Kitar|st [0] (~Kitarist@89.142.49.87) 13.03.07 Quit Kitar|st (Client Quit) 13.03.56 Join Kitar|st [0] (~Kitarist@BSN-142-49-87.dial-up.dsl.siol.net) 13.09.40 Join TheLemonMan [0] (~lem0n@ppp-156-142.98-62.inwind.it) 13.09.52 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 13.09.59 # jhMikeS, it's fine 13.30.26 Join Buschel [0] (~chatzilla@p54A39F9D.dip.t-dialin.net) 13.32.28 # ruckus: this is known but not not understood yet. there is already a bug report (FS#11863) 13.32.53 # ruckus: from which revision on did it start and what was your latest rockbox withtout this issue? 13.33.33 # this started very recently 13.33.54 # probably at the beginning of december 13.33.58 # and thank you for replying 13.34.02 # ruckus: do you have any possibility to reproduce this? 13.34.12 # it happens way too often now 13.34.16 Join fml [0] (~chatzilla@manz-590eee7e.pool.mediaWays.net) 13.34.18 # once to twice a day 13.34.56 # and it occurs really randomly 13.35.18 # sometimes i would play an album and it would stop playing toward its end 13.35.44 # <[Saint]> Ahhhh...FUCK! 13.35.45 # if i remember correctly, most of the times the songs freeze within the first minute of them being played 13.35.49 # <[Saint]> I mean, twiddles. 13.36.11 # it's ok [Saint], that's a common typo 13.36.18 # ruckus: can you try to use the following build to cross-check? it has a reverted change... -> http://www.sendspace.com/file/c0jdql 13.36.30 # <[Saint]> Buschel: Turns out I messed up and built for another target. 13.36.53 # <[Saint]> FS#8668 is still erroring for Nano2G in ipod-clickwheel.c 13.36.54 # moos (for the logs): that "iff" was not a typo, it's a short form of "if and only if" which formally more correctly describes what the function does. 13.37.17 # <[Saint]> *button-clickwheel.c rather 13.37.47 # Buschel: yes i can. should i jsut copy it over the existing one, or should i delete rockbox altogether ? 13.38.20 # ruckus: just copy it over the existing installation 13.38.39 # [Saint]: :/ will check now 13.39.30 # <[Saint]> Sorry about that...apparently I didn't select 28 in configure but 27 instead :/ 13.39.51 # <[Saint]> http://pastebin.com/NAQ69fND is the last lines of my terminal, if it helps. 13.39.56 # <[Saint]> Buschel: ^ 13.40.00 Quit bluebrother (Read error: Operation timed out) 13.40.06 # <[Saint]> No rush, though...none at all. 13.41.41 Join MethoS- [0] (~clemens@134.102.106.250) 13.41.53 Quit fml (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) 13.42.11 # Buschel: testing away. i'll be conveniently doing some laundry right now, so i'll use it right away 13.43.06 # ruckus: ok, just keep me up-to-date and write your results down here or in the flyspray entry. I am reading the logs 13.43.17 Quit sampattuzzi (Ping timeout: 255 seconds) 13.43.24 # [Saint]: does this compile for you? -> http://www.sendspace.com/file/1oz8l4 13.43.47 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.49.28 Join stoffel_ [0] (~quassel@p57B4A9D7.dip.t-dialin.net) 13.50.40 Quit Mystery_Keeper (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 13.51.49 Quit stoffel (Ping timeout: 250 seconds) 14.00.07 # [Saint]: for me it compiles for both nano 2g and video 5.5g 14.01.57 Join casainho [0] (~chatzilla@bl15-144-123.dsl.telepac.pt) 14.13.46 # <[Saint]> Buschel: Are you sure you have a clean SVN? 14.14.42 # <[Saint]> with the patch you linked vs. clean SVN head...I get the pastebin I linked earlier. 14.14.44 Quit PurlingNayuki (Ping timeout: 255 seconds) 14.17.03 # <[Saint]> If that's not it...I have *NO* idea what's going on here. :/ 14.17.27 # * [Saint] redownloads the patch, in case something crazy happened in transfer. 14.17.41 # aaarrrgh 14.18.07 # oen file was included in the patch... my fault. wait a sec 14.18.15 # not included 14.18.22 Quit JdGordon| (Quit: leaving) 14.19.56 # [Saint]: http://www.sendspace.com/file/471cbu 14.20.20 # <[Saint]> thanks Buschel. 14.23.19 Quit stoffel_ (Ping timeout: 260 seconds) 14.26.54 *** Saving seen data "./dancer.seen" 14.31.07 # working now? 14.33.19 # <[Saint]> Building now, I deleted ccache and my build dirs in case there was some relic of the past messing it up. 14.36.42 Join stoffel [0] (~quassel@p57B4A9D7.dip.t-dialin.net) 14.39.07 Join factor [0] (~factor@75.108.68.114) 14.39.41 # [Saint]: btw, did you also experience those lockup issues on your iPods? 14.43.05 # [Saint]: you should never need to empty ccache 14.43.50 # <[Saint]> Nothing I can distinguish as being any different from the usual weirdness on my Colo(u)rs, and none at all on my Nano1Gs 14.43.55 # <[Saint]> Buschel: ^ 14.44.38 # <[Saint]> (on a side note, iPod Color has some hard to track down weirdness) 14.44.42 Join petur [0] (~petur@rockbox/developer/petur) 14.44.59 # what are those like? 14.45.12 # <[Saint]> What targets *should* I be seeing this on? 14.45.45 # we know from iPod Video and nano 1g 14.47.13 # <[Saint]> iPod Colour weirdness == refusing to find rockbox.ipod every 1-of-5 times (approx), "critical battery warning" on startup despite the current battery state (needs hard reset, always followed by failing to find rockbox.ipod, disk corruption, occasional refusal to skip tracks (needs hard reset). 14.47.25 # ruckus: what audio format / codec are you mostly using when the lockups occur? 14.48.00 # [Saint]: disk failure? 14.48.01 # <[Saint]> this hasn't been a recent thing though, I was experiencing it as soon as I got my first iPod Colour, and when I got the second CF'd Color and it behaved the same I realised that it was code and not the device. 14.48.12 # Buschel: mp3s 128kbps, and flacs 14.48.48 # <[Saint]> Buschel: I would have said the same thing, but it's two different devices and my HDD Colour only had 1 hour on power-on time on the disk when I got it. 14.48.56 # <[Saint]> the CF'd one behaves the same. 14.50.35 # [Saint]: what is happening if you disable HAVE_ATA_DMA in the config file (firmware/export/ipodcolor.h)? 14.51.16 # <[Saint]> Buschel: I haven't tried that, and I would have to give it at least a full days testing. 14.51.25 # <[Saint]> I will, though, and get back to you about it. 14.51.41 # could be worth a try 14.51.57 # <[Saint]> Couldn't hurt, at least. 14.53.19 # especially as you said "no boost when DMA'ing" does have major impact (what is not expected when ATA DMA works properly) 14.54.10 # <[Saint]> yeah...I was truly amazed at how poorly it performed there, but I assumed it was just a non-maintained patch. 14.54.59 # <[Saint]> It was struggling to maintain realtime playback of lossy mp3s 14.55.48 # the patch is trivial, maintainance should not be a problem. if DMA works well the transfer rates boosted vs. unboosted are nearly the same. PIO is impacted by boositng a lot. so, either your drive does not support ATA or there is some other underlying issue... 14.56.23 Quit leavittx (Ping timeout: 250 seconds) 14.57.16 # <[Saint]> The drive in the HDD colour is just the standard 60GB it came with, but essentially brand new...and the CF'd has a transcend 64GB CF in it that I don't really know a lot about. 14.57.36 # * gevaerts wonders what soap will think of that :) 14.58.22 # <[Saint]> dammit! it's against every fibre of my being missing the u from "color" :P 14.59.26 # lowercase colour is fine. It's the improper proper noun which gets under my skin. ;) 14.59.36 Join mudd1 [0] (~cmertes@ip-78-94-216-65.unitymediagroup.de) 14.59.57 # Buschel, I have been unable (after 24 hours of playback) to reproduce the bug with my iPod Nano, but that (again) is in a cool room. 15.00.28 # Does the Rockbox utility get its voice info directly from the player's .rockbox/ directory? 15.00.30 Quit sideral (Quit: Leaving.) 15.00.40 # soap: but "HDD colour" in this case is short for "HDD Ipod Color"! 15.00.58 # because I tried to teach my player not to say "ploogins" all the time 15.01.03 # annoys the hell out of me 15.01.04 # gevaerts, it's lowercase, it doesn't trigger my revulsion. 15.01.47 # <[Saint]> mudd1: You have to edit the source and compile a voice yourself. 15.02.12 # I did edit the source 15.02.31 # <[Saint]> did you spell the words as they sound? 15.02.34 # but I was hoping that "create voice file" would then do exactly that 15.02.42 # <[Saint]> "plug Ins" as opposed to Plugins" etc. 15.03.20 # Well, I tried "plug-ins", "pluhg-ins", even "plahg-ins" just to make sure it really ignored my edits altogether 15.03.42 # <[Saint]> yeah, it gets voice info from a server. 15.03.49 # <[Saint]> you need to compile the voice yourself. 15.04.08 # damn 15.04.22 # I thought I could "just" change that line 15.04.39 # not learn how to manually replicate that workflow 15.07.40 # mudd1: that's not "manually replicating that workflow" 15.08.14 # There are two ways to build a voice, one is using rockbox utility, the other is using the build system 15.08.39 # oh cool, is there a "make voice" or something like that? 15.09.10 # <[Saint]> yes. 15.10.10 # <[Saint]> "configure, select target, advanced, voice, make voice...done" 15.13.23 # wow, great :) 15.13.27 # sounds easy 15.13.34 Join domonoky [0] (~Domonoky@agsb-5d87e6b9.pool.mediaWays.net) 15.13.34 Quit domonoky (Changing host) 15.13.34 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.13.44 # how do I get it on the device once that's done? 15.15.58 # ah, I guess I copy over the english.voice file? 15.18.34 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 15.22.21 # yay, that worked :) 15.23.00 # Thanks a lot Saint and gevaerts! 15.26.57 # New commit by 03moos (r29006): Revert r29004 putting the original comment back (sorry to fml for this :) 15.28.57 # r29006 build result: All green 15.37.22 Quit Topy (Read error: Connection reset by peer) 15.42.33 Join T44 [0] (~Topy44@f049111177.adsl.alicedsl.de) 15.47.17 Quit stoffel (Remote host closed the connection) 15.48.31 Join stoffel [0] (~quassel@p57B4A9D7.dip.t-dialin.net) 15.54.42 # Buschel: no problems so far. i listened to 2 albums 15.55.09 Quit Kitar|st (Ping timeout: 255 seconds) 15.55.27 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 4.0b9pre/20110105030550]) 15.55.32 # i don't have a fs account, but if i don't dind you here i you're usually online here 15.55.39 # whoops ignore that 15.56.00 # * i don't have a fs account, but if i don't find you here i'll make one and post my results there 15.57.42 Quit T44 (Read error: Connection reset by peer) 16.00.18 Join Kitar|st [0] (~Kitarist@BSN-210-225-109.dial-up.dsl.siol.net) 16.09.44 Join sideral [0] (~sideral@unaffiliated/sideral) 16.10.03 Quit sideral (Remote host closed the connection) 16.10.04 Quit krazykit (Ping timeout: 265 seconds) 16.10.53 Join sideral [0] (~sideral@unaffiliated/sideral) 16.11.57 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 16.13.09 Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) 16.15.17 # <[Saint]> mudd1: No worries. 16.15.21 # <[Saint]> Happy to help. 16.15.41 # <[Saint]> Buschel: Nano2G compiles successfully now, *phew* ;) 16.15.55 # <[Saint]> I wasn't looking forward to telling you if it failed to compile again : 16.15.59 # <[Saint]> +P 16.17.29 Join T44 [0] (~Topy44@f049111177.adsl.alicedsl.de) 16.24.03 Quit T44 (Read error: Connection reset by peer) 16.26.56 *** Saving seen data "./dancer.seen" 16.33.24 Join krabador [0] (~AndChat@host244-172-dynamic.116-80-r.retail.telecomitalia.it) 16.35.42 Join CaptainKewl [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 16.36.08 # <[Saint]> are FS#11619 and 11679 ever going to make it into SVN? 16.37.03 # <[Saint]> particularly the latter. 16.37.25 # [Saint]: for FS#11619, my understanding is that many people feel that this should be part of the playlist control file 16.37.59 Join ender` [0] (krneki@foo.eternallybored.org) 16.38.57 # <[Saint]> Hmmm... 16.39.15 # I'm not sure if I fully agree (I think this data should be kept in the same place as the resume position), and I don't know the playlist code well enough to even try that 16.39.27 # <[Saint]> Well, I can certainly live with it in my tree, but I think there's nothing wrong withthe implementation personally. 16.39.37 # <[Saint]> *with the 16.40.29 # amiconn: any thoughts on this? (FS#11619) 16.40.43 Quit Xerion (Quit: ) 16.42.06 Join user890104 [0] (~Venci@6bez10.info) 16.43.39 # * [Saint] also wants to do his bi-monthly plug to get FS#5855 committed ;) 16.44.12 # <[Saint]> two player only pong on a DAP is criminal! 16.44.33 # <[Saint]> *two player only 16.45.06 Join T44 [0] (~Topy44@f049111177.adsl.alicedsl.de) 16.48.21 # Why isn't that beat pulsing optional? 16.48.58 # * gevaerts hasn't tried yet, but he thinks he would hate that 16.50.30 # I'm also intrigued by the HWCODEC with LCD_COLOR combination implied there :) 16.53.08 # <[Saint]> gevaerts: I disabled the colour changing myself, and I kinda assumed that just the AI would be "cherry picked" from that commit. 16.53.20 # <[Saint]> But, it really isn't all the noticable actually. 16.53.35 # <[Saint]> It shouldn't be commited though, the AI however... 16.54.12 # <[Saint]> On a side note, http://forums.rockbox.org/index.php/topic,26932.msg176466.html#msg176466 is a bug with skip length right? 16.54.27 # <[Saint]> The behaviour he describes really doesn't seem right to me. 16.55.35 # <[Saint]> I mean, I can see how it is happening...but it doesn't seem as thought it would be "ideal" behaviour. 16.58.42 Quit casainho (Remote host closed the connection) 16.59.47 Join casainho_ [0] (~chatzilla@bl15-144-123.dsl.telepac.pt) 16.59.51 Join casainho__ [0] (~chatzilla@bl15-144-123.dsl.telepac.pt) 16.59.57 Nick casainho_ is now known as casainho (~chatzilla@bl15-144-123.dsl.telepac.pt) 17.00.09 Quit casainho__ (Client Quit) 17.03.50 # [Saint]: I think there's an known bug if you try to skip backward in the last few seconds of a song without skip length as well (though I couldn't tell you what it is, only that I seem to remember it being mentioned several times over a long period of time) 17.04.15 Quit T44 (Ping timeout: 240 seconds) 17.05.34 Join T44 [0] (~Topy44@f049111177.adsl.alicedsl.de) 17.06.03 Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) 17.06.25 # [Saint]: what do you think of http://pastebin.com/vb7kPCYw ? 17.06.47 # <[Saint]> Llorean: If you skip backward in the first few seconds of a song *without* skip length it skips to the start of the previos track. 17.07.36 # <[Saint]> Llorean: Oh, I misread. 17.08.14 # <[Saint]> yeah, you said "last" few seconds. 17.08.23 # <[Saint]> this is referring to the "first" few seconds. 17.08.34 # Oh, I misread. 17.08.39 # His post certainly isn't a bug or anything 17.08.41 # <[Saint]> One of us did ;) 17.08.51 # <[Saint]> I kinda think it is. 17.09.08 # How so? Skipping back at the early part of a track takes you to the next track. 17.09.12 # <[Saint]> if I have skip length set to I would never expect it to exceed 17.09.13 # er previous 17.09.22 # His skip length is set to 10 seconds 17.09.34 # I *doubt* it's skipping to the previous track if he's 12 seconds into his track 17.09.45 # he's probably closer to 3 and expecting to end up 7 seconds from the end of the previous track 17.09.46 # That's not a bug 17.10.39 # <[Saint]> if I'm at 0:00, with skip lenght set to 10:00...I would expect to end up at -0:10 in the previous song. 17.10.52 # <[Saint]> +if I skipped back at that time. 17.10.57 # That's not how Rockbox has ever worked as far as I know. 17.10.59 # It's not a bug. 17.11.04 # It's how track skipping works. 17.11.16 # <[Saint]> that fact that it's never worked that way doesn't mean it shouldn't ;) 17.11.18 # Skipping durations happens within a song, it's just coarse seeking. 17.11.26 # Yes, but it doesn't make it a "bug" 17.11.43 # A bug is when things aren't working as the people who wrote them intended. This is working as intended, just not how you personally expect. 17.11.53 # <[Saint]> true, if you read very carefully...I didn't claim it to be so as an absolute. 17.12.06 # I think if you expect multiple tracks to behave as a single track, you should really be asking yourself why you have multiple tracks 17.12.12 # [Saint]: All I said is that it's not a bug. 17.12.27 # * gevaerts wants [Saint] to comment on that little patch 17.12.47 # I didn't say that you said it was, or anything, just answered your question as to whether it is or isn't - what's described is "working as intended" though I'd agree, not necessarily ideal (I'd like seeking, both fine and coarse, to work between tracks as an option) 17.13.25 # <[Saint]> gevaerts: Seems fine to me. 17.14.40 # <[Saint]> gevaerts: Are you actually thinking of commiting it? 17.14.46 # yes 17.14.52 # <[Saint]> as, that would be pure awesome. 17.16.14 # <[Saint]> Hmmm, actually. 17.16.19 # <[Saint]> needs re-wording. 17.16.31 # <[Saint]> shit, no it doesn't ;) 17.16.52 # <[Saint]> I was thinking about the old/current behavior...nevermind. 17.17.35 # I'll just do the AI bit though, not the colour or blinking 17.17.57 Quit CaptainKewl (Remote host closed the connection) 17.18.28 # I don't really object to the original colour change, but that may be more controversial 17.20.13 # <[Saint]> in a one player game the player controls the right paddel, the CPU the left...on iPod a one player game is initiated by using either control up/down for the right paddle...a two player game human vs. human is initiated by using either control up/down for the left paddle. 17.20.53 # <[Saint]> The plugin starts with a CPU vs. CPU demo 17.21.04 # <[Saint]> gevaerts: ^ 17.21.22 # Well, except it's wrong :) 17.21.38 # <[Saint]> it...is? 17.21.52 # In a single player game, you 17.21.55 # 're *left* 17.22.17 # <[Saint]> Nope. 17.22.22 # <[Saint]> Right here. 17.22.43 # * [Saint] wonders what target gevaerts is playing on. 17.22.51 # gigabeat f 17.23.04 # <[Saint]> Hmmm...seems this may be tricky to word. 17.23.37 # <[Saint]> iPod Nano 1/2G (al I have near me) 1p game you're definitely the right paddle 17.23.57 # Which buttons control it? 17.24.13 # I seem to recall the original Pong player 1 was on the left. 17.24.19 # It'd be nice if it was the same for all targets. 17.24.19 # Oh 17.24.23 # <[Saint]> next/play-pause 17.24.32 # [Saint]: any player where you press a button is human-controlled 17.24.38 # So you can play either left or right 17.25.13 # <[Saint]> *derp*! 17.25.19 # <[Saint]> well...that was, fun. 17.25.25 # * gevaerts rewrites 17.25.28 # <[Saint]> sorry gevaerts ;) 17.25.39 # Well, we were both equally wrong :) 17.25.57 # <[Saint]> Or equally right, win/win! 17.30.11 # [Saint]: http://pastebin.com/PCBpTJfV 17.30.59 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 17.31.00 Quit factor (Ping timeout: 246 seconds) 17.31.24 # <[Saint]> gevaerts: A lot more concise than the mess I was editing, well worded. 17.31.30 # ok 17.35.02 # * gevaerts kicks CIA-7 17.35.02 # ow 17.36.55 # New commit by 03gevaerts (r29007): Add AI to the pong plugin, to allow single-player operation. ... 17.36.56 # r29007 build result: All green 17.41.09 Join {-phoenix-} [0] (~dirk@p57AA7122.dip.t-dialin.net) 17.41.54 Quit {phoenix} (Ping timeout: 265 seconds) 17.42.26 Join factor [0] (~factor@75.108.68.114) 17.48.57 Join Strife89_ [0] (~Strife89@adsl-80-148-184.mcn.bellsouth.net) 17.53.07 # * [Saint] spots a comment in usb-fw-pp5002.c which still implies that iPods must enter disk mode for USB 17.53.29 # <[Saint]> ah, from 2007...no wonder. 17.55.47 Quit MethoS- (Remote host closed the connection) 17.56.51 # [Saint]: for 5002-based ipods, that's correct 17.56.56 # soap: thanks. good to know 17.57.49 # * [Saint] facepalms. 17.58.05 # <[Saint]> Ah, yes. I mixed up 5002 and 502x 18.00.52 # amiconn: If it's not too long, wait for squeeze. Those tools were randomly selected from CVS, quick fixed by hand and compiled just so they'd "load". 18.01.20 Quit GeekShadow (Read error: Connection reset by peer) 18.01.57 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 18.05.11 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 18.06.22 # did you fill the image's filesystem with zeros before compressing, jhMikeS? 18.07.03 # soap: no, I failed to figure out a proper way to do that :P 18.07.36 # just dd dev zero to a file until full, then delete? I'm sure there's a more elegant way. 18.07.53 # That's the easiest way 18.08.47 # it makes a quite significant difference in compressed size. 18.09.31 # just the dd thing even though it doesn't jam everything to the beginning? 18.10.33 # yea, no need to defrag 18.11.07 # just replace all that random empty space with real American empty space and you're most the way there and its easy. 18.12.30 # America, f yeah! 18.14.54 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 18.21.21 Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) 18.26.56 # you got some wmapro changes to merge 18.26.58 *** Saving seen data "./dancer.seen" 18.35.02 Join thomasjfox [0] (~thomasjfo@dslb-088-065-024-077.pools.arcor-ip.net) 18.35.37 Quit krabador (Quit: Bye) 18.42.18 # gevaerts: Thanks for the sim_* / app_* fix 18.42.44 # thomasjfox: I'm technically the one who broke it. I didn't have much choice :) 18.43.13 # :) 18.48.22 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 18.53.07 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 18.53.40 Quit factor (Ping timeout: 240 seconds) 18.56.26 Join perfectdrug [0] (~marko@p54B3CCDD.dip.t-dialin.net) 19.01.51 Join factor [0] (~factor@75.108.68.114) 19.03.00 Quit thomasjfox (Remote host closed the connection) 19.10.04 Quit jhMikeS (Read error: Connection reset by peer) 19.11.35 Quit Judas_PhD (Quit: This is a quitting message) 19.13.12 Quit T44 (Read error: Connection reset by peer) 19.16.31 Join jhMikeS [0] (~jethead71@adsl-99-26-177-70.dsl.sfldmi.sbcglobal.net) 19.16.31 Quit jhMikeS (Changing host) 19.16.31 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 19.25.16 Join T44 [0] (~Topy44@f049111177.adsl.alicedsl.de) 19.25.19 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 19.27.11 Quit nexes (Ping timeout: 260 seconds) 19.31.36 Join krazykit` [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 19.32.00 Quit krazykit (Ping timeout: 255 seconds) 19.32.27 Quit liar (Ping timeout: 255 seconds) 19.35.16 Quit TheLemonMan (Quit: free(me)) 19.35.21 Join corndog [0] (corndog@174.90.229.17) 19.38.20 Quit Keripo (Quit: Leaving.) 19.40.08 Join JesusFreak316_ [0] (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 19.40.22 Quit JesusFreak316 (Read error: Connection reset by peer) 19.41.46 Nick JesusFreak316_ is now known as JesusFreak316 (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 19.42.17 Quit JesusFreak316 (Read error: Connection reset by peer) 19.42.49 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 19.43.37 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 19.50.45 Quit corndog () 19.50.49 Quit JesusFreak316 (Read error: Connection reset by peer) 19.51.52 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-84-237.tampfl.fios.verizon.net) 19.53.57 Join toffe82 [0] (~chatzilla@adsl-70-235-225-226.dsl.frs2ca.sbcglobal.net) 19.54.31 # soap: that took it to 540MB from 833MB. 20.01.48 Quit markun (Read error: Connection reset by peer) 20.05.57 Quit stoffel (Read error: Operation timed out) 20.06.26 Join markun [0] (~markun@5ED33C2C.cm-7-4a.dynamic.ziggo.nl) 20.06.26 Quit markun (Changing host) 20.06.26 Join markun [0] (~markun@rockbox/developer/markun) 20.08.33 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.10.08 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 20.20.45 Join Saij [0] (~Saij@cpe-24-93-30-86.rochester.res.rr.com) 20.25.15 Quit fyrestorm (*.net *.split) 20.25.15 Quit Buschel (*.net *.split) 20.25.16 Quit linuxguy3 (*.net *.split) 20.25.16 Quit Barahir (*.net *.split) 20.25.16 Quit simonrvn (*.net *.split) 20.25.16 Quit tmzt (*.net *.split) 20.25.16 Quit literal (*.net *.split) 20.26.21 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 20.26.21 Join fyrestorm [0] (~nnscript@cpe-69-203-144-35.si.res.rr.com) 20.26.21 Join Buschel [0] (~chatzilla@p54A39F9D.dip.t-dialin.net) 20.26.21 Join linuxguy3 [0] (~timj@adsl-75-57-173-53.dsl.emhril.sbcglobal.net) 20.26.21 Join Barahir [0] (~jonathan@frnk-590f48a4.pool.mediaWays.net) 20.26.21 Join simonrvn [0] (simon@70.35.160.181) 20.26.21 Join tmzt [0] (~tmzt@76.211.0.152) 20.26.21 Join literal [0] (hinrik@w.nix.is) 20.27.01 *** Saving seen data "./dancer.seen" 20.29.14 Quit Buschel (Ping timeout: 240 seconds) 20.37.29 Quit balintx (Remote host closed the connection) 20.39.09 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 20.42.40 Quit n1s (Quit: Lämnar) 20.42.55 Quit benedikt93 (Read error: Connection reset by peer) 20.43.29 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 20.45.45 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 20.51.01 Quit Judas_PhD (Quit: This is a quitting message) 20.53.30 Quit Xerion (Quit: ) 20.53.54 Quit kadoban (Ping timeout: 240 seconds) 20.55.19 Quit factor (Ping timeout: 264 seconds) 20.55.59 Join factor [0] (~factor@75.108.68.114) 20.57.59 Quit factor (Excess Flood) 20.58.18 Join u [0] (~4d0b9f00@giant.haxx.se) 20.58.27 Join factor [0] (~factor@75.108.68.114) 20.58.43 # hi 20.59.47 Quit u (Client Quit) 21.01.04 Quit Kitar|st () 21.01.36 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 21.04.08 Join TheLemonMan [0] (~lem0n@ppp-156-142.98-62.inwind.it) 21.19.18 Quit toffe82 (Read error: Connection reset by peer) 21.21.11 Join toffe82 [0] (~chatzilla@adsl-70-235-225-226.dsl.frs2ca.sbcglobal.net) 21.21.39 Join krabador [0] (~krabador@host17-186-dynamic.252-95-r.retail.telecomitalia.it) 21.21.47 Quit Judas_PhD (Remote host closed the connection) 21.39.02 Quit simonrvn (Read error: Connection reset by peer) 21.39.56 Join simonrvn [0] (simon@209.156-ppp.3menatwork.com) 21.41.05 Join Buschel [0] (~chatzilla@p54B6734A.dip.t-dialin.net) 21.45.02 # There is a RTC_NANO2G define but it's not clear which rtc driver this corresponds to 21.46.36 # RTC_D2 as well 21.47.38 # New commit by 03jethead71 (r29008): Some static data is only used by .init functions. Add .initdata to declare such data (otherwise section conflicts arise). For i.MX31, use ... 21.48.32 # r29008 build result: All green 21.51.18 Quit factor (Read error: Connection reset by peer) 21.54.19 Join factor [0] (~factor@75.108.68.114) 22.01.08 # New commit by 03theseven (r29009): Fix iPod Classic LCD problems 22.02.04 # bertrik: the nano2g PMU's RTC 22.02.26 # it has its own driver in /firmware/target/arm/s5l8700/ipodnano2g somewhere 22.03.04 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 22.03.20 # it's actually a PCF50633 from what I can tell, but I'm not using the driver for that 22.03.22 # r29009 build result: All green 22.03.35 Quit Saij (Read error: Connection reset by peer) 22.07.06 # the RTC_NANO2G define seems completely unused 22.17.39 Quit Strife89_ (Quit: Heading out.) 22.27.04 *** Saving seen data "./dancer.seen" 22.33.54 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 22.40.43 Join slooopy [0] (~sloo@p5493CB08.dip0.t-ipconnect.de) 22.44.15 # LambdaCalculus37 (for the logs): All the big known bugs are fixed now :) 22.44.35 # it's time for adding features and optimizing :) 22.46.29 Quit krabador (Quit: Sto andando via) 22.47.14 Quit slooopy (Remote host closed the connection) 22.47.52 Join slooopy [0] (~sloo@p5493CB08.dip0.t-ipconnect.de) 22.49.26 # * TheSeven wonders what to do next 22.51.31 Quit slooopy (Remote host closed the connection) 22.52.03 Join slooopy [0] (~sloo@p5493CB08.dip0.t-ipconnect.de) 22.59.35 Quit benedikt93 (Quit: Bye ;)) 23.00.08 # jhMikeS: re zero filling: cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill 23.00.40 # As root, in order to fill the 5% root reserved space as well. Taken from howtoforge 23.00.52 Join MethoS- [0] (~clemens@134.102.106.250) 23.01.55 Quit {-phoenix-} (Remote host closed the connection) 23.03.00 Join {phoenix} [0] (~dirk@p57AA7122.dip.t-dialin.net) 23.09.39 Quit kadoban (Ping timeout: 240 seconds) 23.10.52 # qqqqqqq 23.18.46 # amiconn: I did "dd if=/dev/zero of=bigfin.bin; rm bigfin.bin" (as root, per soap's and gevaerts' recommend) 23.19.19 # jhMikeS: the lack of sync may be important actually 23.19.46 # how important, hell if I'm uploading that again! lol 23.20.20 # 'couse I can try locally and see how much it actually changes it 23.20.44 # Well, it tells the system to write all outstanding stuff 23.21.09 # Without that, it's possible (depending on amount of RAM) that most of those zeroes never hit the disk 23.21.16 Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 23.21.22 # well, er, presumably you shut it down 23.21.41 # which will sync the buffer cache :) 23.21.42 Quit Buschel (Ping timeout: 260 seconds) 23.21.43 # sys poweroff, but not before rm 23.21.59 # er, just "poweroff" 23.22.08 # oh, yeah 23.23.00 # if you don't do poweroff, it has to do recovery on boot 23.25.47 Join moos [0] (moos@rockbox/staff/moos) 23.26.00 Quit TheLemonMan (Quit: free(me)) 23.34.17 Quit JesusFreak316 (Ping timeout: 240 seconds) 23.34.34 Quit slooopy (Ping timeout: 255 seconds) 23.44.49 Quit Keripo (Quit: Leaving.) 23.48.12 Quit bertrik (Quit: :tiuQ) 23.54.35 Quit petur (Quit: Leaving)