--- Log for 19.05.109 Server: Not connected Channel: None joined --- Nick: No nick Version: Dancer V4.16 Started: 0 seconds ago 07.32.10 *** Started Dancer V4.16 07.32.10 *** Connected to irc.freenode.net on port 6667 07.32.10 *** Logfile for #rockbox started 07.32.18 *** Server message 501: 'logbot :Unknown MODE flag' 07.32.18 Mode "logbot :+i" by logbot 07.32.19 Join logbot [0] (n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-7d6b80f89d7e4e36) 07.32.19 Join _lifeless [0] (n=lifeless@188.16.106.64) 07.32.19 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 07.32.19 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 07.32.19 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 07.32.19 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-371062c27b6426f5) 07.32.19 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-0b679d89a6917535) 07.32.19 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 07.32.19 Join bubsy [0] (i=Bubsy@unaffiliated/bubsy) 07.32.19 Join killan [0] (n=nnscript@c-5ef170d5.06-397-67626721.cust.bredbandsbolaget.se) 07.32.19 Join pixelma [50] (n=pixelma@rockbox/staff/pixelma) 07.32.19 Join amiconn [50] (n=jens@rockbox/developer/amiconn) 07.32.19 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 07.32.19 Join timc [0] (n=aoeu@116.3.0.210) 07.32.19 Join parafin [0] (i=parafin@paraf.in) 07.32.19 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 07.32.19 Join krazykit [0] (i=josh@c-76-119-147-106.hsd1.ma.comcast.net) 07.32.19 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 07.32.19 Join arohtar [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 07.32.19 Join GodEater [0] (n=yeahrigh@rockbox/staff/GodEater) 07.32.19 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 07.32.19 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 07.32.19 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 07.32.19 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 07.32.19 Join avacore^ [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 07.32.19 Join barrywardell [0] (n=barry@rockbox/developer/barrywardell) 07.32.19 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 07.32.19 Join Rob2222 [0] (n=Miranda@p4FDCF816.dip.t-dialin.net) 07.32.19 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 07.32.19 Join tvelocity[a] [0] (n=tony@adsl20-86.her.forthnet.gr) 07.32.19 Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 07.32.19 Join Ridayah [0] (n=ridayah@173-19-228-175.client.mchsi.com) 07.32.19 Join bagawk [0] (n=lee@c-98-232-168-140.hsd1.or.comcast.net) 07.32.19 Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 07.32.19 Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 07.32.19 Join HellDragon [0] (i=jd@Wikipedia/HellDragon) 07.32.19 Join DataGhost [0] (n=dataghos@unaffiliated/dataghost) 07.32.19 Join J-23 [0] (n=zelazko@unix.net.pl) 07.32.19 Join R[a]ndom [0] (n=random@bas1-toronto09-1279336053.dsl.bell.ca) 07.32.19 Join alexbobp [0] (n=alex@adsl-75-63-0-19.dsl.austtx.sbcglobal.net) 07.32.19 Join Galois [0] (i=djao@efnet.math.uwaterloo.ca) 07.32.19 Join markun [50] (n=markun@rockbox/developer/markun) 07.32.19 Join Lss [0] (n=Lss@cm49.delta93.maxonline.com.sg) 07.32.19 Join TheDJACR [0] (n=TDJACR@Wikipedia/Thedjatclubrock) 07.32.19 Join antil33t [0] (n=Mudkips@119.224.12.185) 07.32.19 Join Chex_ [0] (n=Stefan@bas1-montreal48-1176172475.dsl.bell.ca) 07.32.19 Join rasher [50] (n=rasher@rockbox/developer/rasher) 07.32.19 Join jordan` [0] (i=gromit@78.235.252.137) 07.32.19 Join _Auron_ [0] (n=DarkAuro@ppp-70-242-123-180.dsl.rcsntx.swbell.net) 07.32.19 Join evilnick_home [0] (n=evilnick@pool-173-52-140-75.nycmny.east.verizon.net) 07.32.19 Join jmillikin [0] (n=jmilliki@c-24-130-227-85.hsd1.ca.comcast.net) 07.32.19 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 07.32.19 Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) 07.32.19 Join lightbulbjim [0] (n=jim@203.171.93.108.static.rev.aanet.com.au) 07.32.19 Join courtc [0] (n=court@unaffiliated/courtc) 07.32.19 Join fyrestorm [0] (n=nnscript@cpe-68-173-233-205.nyc.res.rr.com) 07.32.19 Join jon-kha [0] (i=jon-kha@kahvi.eu.org) 07.32.19 Join dionoea [0] (n=dionoea@videolan/developer/dionoea) 07.32.19 Join suom1 [0] (i=markus@viitamaki.net) 07.32.19 Join Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) 07.32.19 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 07.32.19 Join spyder [0] (n=spyder@lirhost.net) 07.32.19 Join n17ikh [0] (n=n17ikh@host-64-234-48-99.nctv.com) 07.32.19 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 07.32.19 Join fred_2 [0] (i=fred@hpc-cluster.hamburgnet.de) 07.32.19 Join blithe [0] (n=blithe@blakesmith.me) 07.32.19 Join Bagder [241] (n=daniel@rockbox/developer/bagder) 07.32.19 Join Hadaka [0] (i=naked@naked.iki.fi) 07.32.19 Join shadearg [0] (i=arg@ipv4.panoptix.net) 07.32.19 Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) 07.32.19 Join crwll [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 07.32.19 Join fuzzie [0] (n=fuzzie@twinsen.warpedgames.com) 07.32.19 Join rwong [0] (n=ricky@www.roflwaffle.com) 07.32.19 Join lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 07.32.19 Join Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) 07.32.19 Join tmzt [0] (n=tmzt@adsl-99-164-62-86.dsl.akrnoh.sbcglobal.net) 07.32.19 Join tarbo [0] (n=me@unaffiliated/tarbo) 07.32.19 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 07.32.19 Join Bombe [0] (n=droden@freenet/developer/Bombe) 07.32.19 Join yosafbridge [0] (n=yosafbri@ludios.net) 07.32.19 Join planetbeing [0] (n=planetbe@67-207-128-206.slicehost.net) 07.32.19 Join CIA-38 [0] (n=CIA@208.69.182.149.simpli.biz) 07.32.19 Join crashd [0] (i=foobar@lostnode.org) 07.32.19 Join webmind [0] (n=webmind@shell.puscii.nl) 07.32.19 Join pabs [0] (n=pabs@xor.pablotron.org) 07.32.19 Join freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 07.32.19 Join fxb__ [0] (n=felixbru@h1252615.stratoserver.net) 07.32.19 Join trisiak [0] (n=tree@chello089078243195.chello.pl) 07.32.19 Join FOAD [0] (n=dok@dinah.blub.net) 07.32.19 Join wookey_ [0] (n=wookey@stoneboat.aleph1.co.uk) 07.32.19 Join Foxx [0] (n=Foxx@pool-141-157-246-7.ny325.east.verizon.net) 07.32.19 Join msi [0] (i=msi@shell.noname-ev.de) 07.32.19 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 07.32.19 Join Bawitdaba [0] (n=Sphinx@cpe-74-70-40-135.nycap.res.rr.com) 07.32.19 Join bittin```` [0] (i=bittin@anapnea.net) 07.32.19 Join Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) 07.32.19 Join vedlith [0] (n=ved2@137-mi2-1.acn.waw.pl) 07.32.19 Join andy` [0] (i=andy@cassarossa.samfundet.no) 07.32.19 Join ze [0] (i=ze@76.91.72.105) 07.32.19 Join SUSaiyan` [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 07.32.19 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 07.32.19 Join AlexP [0] (n=alex@rockbox/staff/AlexP) 07.32.19 Join Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 07.32.19 Join soap [50] (n=soap@rockbox/staff/soap) 07.32.19 Join maraz [0] (i=maraz@xob.kapsi.fi) 07.32.19 Join ufoman [0] (n=ufoman@whiterabbit.rz.uni-mannheim.de) 07.32.19 Join goffa [0] (n=goffa@216.220.23.105) 07.32.19 Join flux [0] (i=flux@jolt.modeemi.cs.tut.fi) 07.32.19 Join jfc [0] (n=john@dpc691978010.direcpc.com) 07.32.19 Join Beta2K [0] (i=1000@d36-124-26.home1.cgocable.net) 07.32.19 Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 07.32.19 Join preglow [0] (i=thomj@rockbox/developer/preglow) 07.32.19 Join scorche|sh [50] (n=scorche@rockbox/administrator/scorche) 07.32.19 Join @ChanServ [0] (ChanServ@services.) 07.32.19 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 07.32.19 Join liiwi [0] (i=liiwi@idle.fi) 07.32.19 Join feisar-- [0] (n=jljhook@irkki.fi) 07.32.23 Ctcp Version from freenode-connect!freenode@freenode/bot/connect 07.32.23 *** Server message 477: 'logbot #rockbox :[freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup' 07.33.09 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.33.32 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.51.25 Join bzed [0] (n=bzed@devel.recluse.de) 07.56.29 Join matsl [0] (n=matsl@dhcp86.contactor.se) 08.03.44 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.18.09 Quit kachna|lappy (Read error: 113 (No route to host)) 08.18.59 Join webguest74 [0] (n=86478d2c@gateway/web/cgi-irc/labb.contactor.se/x-862422e43a601d8e) 08.22.23 Quit webguest74 (Client Quit) 08.25.22 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.35.45 Join B4gder [241] (n=daniel@rockbox/developer/bagder) 08.37.03 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.38.27 Mode "#rockbox +o Zagor " by ChanServ (ChanServ@services.) 08.38.32 Topic "Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community" by Zagor (n=bjorn@rockbox/developer/Zagor) 08.38.36 Mode "#rockbox -o Zagor " by ChanServ (ChanServ@services.) 08.41.28 Join BXCracer [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 08.44.54 Join Rob2223 [0] (n=Miranda@p4FDCD704.dip.t-dialin.net) 08.50.56 # Zagor: \o/ Was it simply a power outage - i.e. the server itself is fine? 08.51.29 Quit Rob2222 (Read error: 60 (Operation timed out)) 08.51.41 # as far as I know, yes. the outage was short, but the machine didn't power up itself after for some reason. 08.54.59 Quit Bagder ("*plopp*") 08.57.03 # seems like it wasn't up for the daily manuals build round yet 08.57.39 Join Bagder [241] (n=daniel@rockbox/developer/bagder) 08.57.47 # no, it came up just two hours ago 09.12.55 Quit Bagder ("*plopp*") 09.14.42 Join kugel [0] (n=kugel@rockbox/developer/kugel) 09.15.30 Join flydutch [0] (n=flydutch@host126-161-dynamic.0-79-r.retail.telecomitalia.it) 09.15.30 # pixelma: did you try if BUTTON_OFF|BUTTON_REL works? 09.16.00 # I mean without BUTTON_OFF_PRE at all 09.16.22 Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) 09.16.33 # that _PRE shouldn't be needed 09.20.57 Join kugel_ [0] (n=kugel@e178082106.adsl.alicedsl.de) 09.20.59 Quit kugel ("exit(0);") 09.21.25 Quit kugel_ (Client Quit) 09.21.31 Join kugel [0] (n=kugel@rockbox/developer/kugel) 09.21.45 Quit BHSPitMonkey ("Ex-Chat") 09.26.01 Quit bertrik (Read error: 60 (Operation timed out)) 09.26.46 Join petur [50] (n=petur@rockbox/developer/petur) 09.30.16 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.32.12 *** Saving seen data "./dancer.seen" 09.35.59 Quit kugel (Read error: 60 (Operation timed out)) 09.39.51 Join Bagder [241] (n=daniel@rockbox/developer/bagder) 09.45.40 Join shodanX [0] (n=shodanX@port-92-194-84-168.dynamic.qsc.de) 09.50.28 Quit Thundercloud (Remote closed the connection) 10.03.18 Join fyre^OS [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 10.04.25 Join kugel [0] (n=kugel@rockbox/developer/kugel) 10.04.39 Quit kugel (Client Quit) 10.04.54 Join Dillizar [0] (n=Elive_us@77.28.22.139) 10.05.00 Join kugel [0] (n=kugel@rockbox/developer/kugel) 10.05.02 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 10.06.08 # my player is PTP if i put rockbox it will act like a normal USB? and will my linux recognize 10.06.22 # it 10.06.27 # Dillizar: What player? 10.06.42 # gogear 10.06.43 Join ze0 [0] (i=ze@76.91.72.105) 10.07.31 # i know its not supported but i have some version of ot :) thanks to Toffe 10.07.41 Quit markun (Remote closed the connection) 10.07.51 # Dillizar: According to this table, yes - http://www.rockbox.org/twiki/bin/view/Main/TargetStatus#New_Platforms_Currently_Under_De 10.08.41 # (the "USB" column is ticked, which means Rockbox controls the USB, providing a standard mass-storage interface). 10.09.13 # YEAH 10.09.48 # More info, including some install instructions are here - http://www.rockbox.org/twiki/bin/view/Main/GoGearSA9200info 10.10.15 Quit ze (Read error: 113 (No route to host)) 10.10.15 Nick ze0 is now known as ze (i=ze@76.91.72.105) 10.10.34 # kugel: yes, it's needed to make a difference between the simple Off and Off+Menu. Otherwise you exit the plugin if you are slightlly quicker with the Off button in that combo... 10.11.21 # this won't happen now anymore 10.11.27 # pixelma: that shouldn't happen due to or'ing with |BUTTON_REL 10.12.20 # the button driver only returns X|BUTTON_REL if the button was released, not if it's hold down or used with another button 10.12.54 Join markun [50] (n=markun@rockbox/developer/markun) 10.15.07 # I try it now but you could do it too. At least the accidental Off is fixed now - and you could have seen it in first place... 10.15.36 # and the restart is in the manual 10.15.43 # I can only test in the sim. I'm not sure if there was a hardware-specific reason the _PRE was added 10.16.03 # yes, that's true, sorry about that 10.17.17 Join Zambezi [0] (i=Zulu@bnc.dotbnc.se) 10.18.19 Join mt [0] (n=MTee@41.233.149.37) 10.18.26 # kugel: it's needed 10.18.59 # otherwise if you hold the Off button slightly too long in that combo you also exit after the reastart 10.19.04 # or restart 10.19.34 # ah, that makes sense, but it shouldn't behave like that :( 10.20.05 Quit fyrestorm (Read error: 110 (Connection timed out)) 10.20.36 # why not? 10.21.23 # button_rel shouldn't come in after a combo imo 10.27.27 # how long do i need to wait for a activation code to registrate?? i am waiting for 20min now 10.27.55 # Dillizar: I would expect it to come immediately. But what activation code are you talking about? 10.28.33 # TWIKI 10.31.12 # * GodEater didn't think the wiki sent an activation code 10.31.27 # I thought you just registered, and then came here to ask for write access 10.33.49 # Dillizar: MarjanTrajkovski ? 10.34.00 # done 10.34.07 # yes i need to resend it again 10.34.46 # resend what ? 10.35.02 # Dillizar: someone here needs to give you write permission, it's not automated 10.35.25 # assuming MarjanTrajkovski is your wiki name, then you now have write access. 10.35.26 # no its ok 10.35.34 # now 10.35.40 # now what ? 10.35.45 # * GodEater is horribly confused 10.35.47 # :D 10.35.49 # :) 10.35.50 # well 10.35.58 # first i was waiting for email 10.36.06 # which it doesn't send you... 10.36.16 # so i press the backspace button of my keyboard and send me back 10.36.29 # and clicked again for a new mail 10.36.31 # and i got it 10.36.32 # :) 10.38.20 # so how do you install the rockbox if i dont have windows 10.38.21 # :) 10.40.45 # Dillizar: it's probably in the manual, did you check it? 10.41.16 # yes but i can read for utility tools smt like that 10.41.16 # markun: he doesn't have a supported device 10.41.28 # yes 10.41.34 # so i cant use the tools 10.41.59 # Dillizar: do you have a question of some sorts? 10.42.19 # well how to install rock box on gogear 10.42.20 # http://209.85.229.132/search?q=cache:ub1nZl3urHMJ:www.rockbox.org/twiki/bin/view/Main/GoGearHDD6330+site:rockbox.org+gogear&hl=en&client=firefox-a&gl=uk&strip=1 10.42.38 # you join the dev people who work on it 10.42.39 # i have used this but doesnt help a lot 10.42.57 # Dillizar: a new port is a lot of work: http://www.rockbox.org/twiki/bin/view/Main/NewPort 10.43.11 # markun: that port is however already pretty far down the road 10.43.19 # ah, sorry :) 10.43.23 # mi4 based PP 10.43.28 # iirc 10.43.57 # seems we have two gogear ports on the go 10.44.11 # right, I believe they are quite similar 10.44.29 # but have yet to hear which one Dillizar has :) 10.44.30 # i have compile the source and now i need to install it inside the gogear but because its ptp my lunux cant read it 10.44.46 Quit jmillikin (Remote closed the connection) 10.44.50 # ptp? you transfer pictures to it? 10.45.03 # that's handy 10.45.10 # yes 10.45.18 # i have a cable from the player to the camera 10.45.25 # camera? 10.45.25 # so i dont need a pc to put the pics 10.45.27 # :) 10.45.29 # photo 10.45.46 # photo? 10.45.54 # ok 10.46.06 # what? 10.46.10 # picture taking mashine 10.46.10 # :) 10.46.34 # aaah, that's what a camera is. ok then, I'm happy I could help. byebye 10.46.40 # Dillizar: could you please speak in complete sentences ? 10.46.42 # :D 10.46.47 # none of us know what you're asking 10.47.18 # well only windows xp can recognize my mp3 10.47.32 # * Bagder sighs 10.47.35 # your mp3? 10.47.40 # player 10.47.43 # as in your single mp3 song? 10.47.44 # Dillizar: first things first - WHICH GoGear do you have ? 10.47.52 # hdd6330 10.47.58 # 30gb 10.48.45 # ok - so the instructions for "Recovery mode" from the wiki don't work ? 10.49.07 # no cuz i cant access my mp3 player 10.49.21 # that's not the right answer 10.49.23 # stupid MTP 10.49.37 # Dillizar: please read GodEater's question and answer that 10.50.21 # GodEater, i cant go to recovery mode i dont know why i am asking the channel of my linux but no one is there :( 10.50.38 # syntax error 10.50.52 # Dillizar: installing rockbox on your player requires that you get recovery mode working. There is no other way. 10.51.04 # Dillizar: so you followed the steps in the wiki and those didn't work? 10.51.05 # if you can't make it work, we can't help you 10.51.30 # Bagder, well my grub is smt like -2 sec :) 10.51.37 # what? 10.52.03 # and please use complete words 10.52.07 # i need to press esc when the grub is booting so i can enter the recovery mode 10.52.10 # ?? 10.52.11 # yes 10.52.19 Join advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) 10.52.23 # whoa 10.52.25 # your GoGear has grub on it ? 10.52.32 # * GodEater finds this unlikely 10.52.49 # on my gogear?? wow i was thinking on my linux 10.52.50 # :D 10.52.53 # lol sorry mates 10.53.00 # Dillizar: then you aren't reading the wiki page 10.53.10 # Dillizar: please go away and read it 10.53.11 # not right it seems 10.53.24 # k sorry need to read it again 10.53.48 # really, you need to focus and pay attention 10.53.57 # :) 10.55.09 Quit B4gder (Connection timed out) 10.58.50 # kugel: button _REL always fires when a button is released, that's what it's for. If you need to distinguish short/long/combo, you need to check preconditions 10.59.59 # This is in no way hardware specific, it's how the generic part of the button driver works. The (only) exception are buttons without release handling (wheel, archos remote) 11.01.19 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 11.01.32 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-2d7451814eb225e4) 11.02.51 # amiconn: I think, if you pressed A+B, and hold B slightly longer, it should give B|BUTTON_REL, IMO 11.03.42 Join nibbler__ [0] (n=Nibbler@pD9E32A60.dip.t-dialin.net) 11.05.04 # It fires both A|BUTTON_REL and then B|BUTTON_REL 11.05.57 # even worse :( 11.06.23 # A|B|BUTTON_REL would make more sense imo 11.07.09 # can i install it in Service Mode? or i must in recovery mdoe 11.08.13 # kugel: Nope, it wouldn't, unless you release both buttons at *exactly* the same time (i.e. within a single tick) 11.08.31 # or just within whatever the current release timeout is 11.10.00 # or we enlarge that timeout for combos 11.10.05 Quit mt (Read error: 104 (Connection reset by peer)) 11.19.55 # Dillizar: the document is quite clear - the install must be done in recovery mode. 11.20.15 # GodEater, i cant enter :( 11.20.24 # then you're out of luck I'm afraid 11.21.03 # toffe82 has a gogear like mine i will wait for him to tell me how he went to recovery mode 11.21.51 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 11.23.40 # Dillizar: he's usually here every day 11.23.48 # yes i know 11.23.52 # but i am gmt +1 11.24.01 # and i dont know his gmt so 11.24.05 # i will just wait 11.24.05 # :) 11.24.13 # gmt is the same everywhere 11.24.49 # Dillizar: he's in the west of the USA I think 11.24.57 # yes 11.25.11 # and i am east of europe :) 11.25.21 # i think we are 12h apart 11.25.29 # hardly 11.25.47 # US and europe are never 12h apart 11.25.56 # unless you count hawaii perhaps 11.26.28 # maybe 11.26.34 # 8 then :) 11.26.47 # but he is west doe 11.26.48 # :D 11.32.14 *** Saving seen data "./dancer.seen" 11.32.47 # * Dillizar is away: Screenshot of Elive: http://elivecd.org/Main/Screenshots 11.33.00 # Dillizar: don't do that 11.33.04 # sorry 11.33.17 # it wasnt me is the xchat 11.33.24 # i will remove my away msg 11.34.13 # done 11.34.20 # this is clearly stated in the guidelines for this channel 11.35.19 # yes but this is the first time i used the /away command 11.35.31 # its just from my os 11.36.54 Join Mathiasdm [0] (n=Mathias@surfvtk.ugent.be) 11.54.04 Quit BXCracer ("Quit") 11.55.19 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.10.41 Quit _lifeless (Remote closed the connection) 12.10.57 Join _lifeless [0] (n=lifeless@188.16.105.142) 12.21.44 Join robin0800_ [0] (n=quassel@general-ld-216.t-mobile.co.uk) 12.25.08 Quit Mathiasdm ("Yuuw!") 12.32.11 Quit robin0800 (Read error: 110 (Connection timed out)) 12.33.28 Join funman [0] (n=fun@rockbox/developer/funman) 12.37.11 Join shodanX_ [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 12.37.20 Quit shodanX_ (Client Quit) 12.38.33 Quit Ridayah ("The Rise and Fall of the Heavens themselves is dependant upon Humanity's belief and disbelief.") 12.39.16 Join Ridayah [0] (n=ridayah@173-19-228-175.client.mchsi.com) 12.40.27 Quit shodanX ("leaving") 12.40.33 Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 12.41.42 # Yesterday's irc log is absent? 12.42.11 # Oh I see mentions of a power outage in the first logs of today :/ 12.43.18 Quit Horscht ("Verlassend") 12.48.17 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 12.48.39 Join kushalone [0] (n=kushal@12.169.180.178) 12.51.04 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.53.20 Quit daurn (Read error: 110 (Connection timed out)) 12.54.27 Quit robin0800_ (Read error: 110 (Connection timed out)) 12.59.52 Join Grahack [0] (n=chri@ppp-193.net-62-100-132.static.magiconline.fr) 13.00.12 Quit funman ("leaving") 13.02.19 Quit Grahack (Client Quit) 13.05.32 Quit kugel (Read error: 104 (Connection reset by peer)) 13.07.57 Join BXCracer [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 13.09.46 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 13.10.34 # Bagder, sorry for breaking the build table. 13.11.02 # I assume you my filesystem has /plenty/ of free room, the commit caught me "with my pants down". 13.11.27 # s/assume/assure/ 13.17.57 Join Grahack [0] (n=chri@ppp-193.net-62-100-132.static.magiconline.fr) 13.19.32 Quit Grahack (Client Quit) 13.20.32 Join Grahack [0] (n=chri@ppp-193.net-62-100-132.static.magiconline.fr) 13.20.58 Part Grahack 13.32.18 *** Saving seen data "./dancer.seen" 13.37.38 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 13.43.59 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 13.51.39 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 13.52.49 Quit arohtar (Client Quit) 13.53.03 Join faemir [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 14.06.23 Join froggyman [0] (n=187b533e@gateway/web/cgi-irc/labb.contactor.se/x-4d1068398e4d0b8e) 14.07.19 Join Mathiasdm [0] (n=Mathias@surfvtk.ugent.be) 14.23.15 Quit Horscht (Read error: 110 (Connection timed out)) 14.23.47 Quit kushalone (Client Quit) 14.25.07 Quit froggyman ("CGI:IRC") 14.26.32 Quit Mathiasdm (Read error: 104 (Connection reset by peer)) 14.26.33 Join mt [0] (n=MTee@41.233.149.37) 14.26.39 Join Mathiasdm2 [0] (n=Mathias@surfvtk.ugent.be) 14.29.06 Join Mathiasdm [0] (n=Mathias@surfvtk.ugent.be) 14.29.38 # I need a little help with ci->request_buffer(realsize, reqsize), My understanding is that it allocates of data from the file buffer to a pointer, as long as ( realsize > reqsize ). Correct ? 14.30.01 Quit Mathiasdm2 (Read error: 113 (No route to host)) 14.31.05 Join renke [0] (n=renke@g226225130.adsl.alicedsl.de) 14.33.43 # And after calling request_buffer(), advance_buffer() has to be called to advance the pointer to the file buffer by the amount of data used from request_buffer() - which would be reqsize ? 14.34.09 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 14.34.40 Join {phoenix} [0] (n=dirk@p54B4722E.dip.t-dialin.net) 14.36.28 Quit Horschti ("Verlassend") 14.43.30 Quit Mathiasdm (Read error: 113 (No route to host)) 14.43.54 Join Mathiasdm [0] (n=Mathias@surfvtk.ugent.be) 14.47.05 Quit nibbler__ (Read error: 110 (Connection timed out)) 14.48.29 Quit SirFunk (Read error: 110 (Connection timed out)) 14.49.31 Quit Mathiasdm (Read error: 113 (No route to host)) 14.49.41 Join Mathiasdm2 [0] (n=Mathias@surfvtk.ugent.be) 14.51.21 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 14.57.45 Join firedix [0] (n=firedix@201.254.107.47) 14.58.58 Quit {phoenix} (Remote closed the connection) 15.00.40 Quit Dillizar ("I ♥ Elive") 15.09.21 Quit Mathiasdm2 (Read error: 104 (Connection reset by peer)) 15.09.38 Join Mathiasdm [0] (n=Mathias@surfvtk.ugent.be) 15.11.08 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 15.14.24 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-442bc516b626933d) 15.25.36 # mt: If you look at flac.c as an example, it calls ci->request_buffer as follows - "buf = ci->request_buffer(&bytesleft, MAX_FRAMESIZE);" 15.26.35 # MAX_FRAMESIZE is the maximum size of a FLAC frame (in bytes). The function returns a pointer to the data (buf) and sets bytesleft (an integer) to the number of bytes it has given you (either MAX_FRAMESIZE, or smaller at the end of the file). 15.27.20 # You then process some (or all) of that data, and then call ci->advance_buffer() with the number of bytes you have consumed. You then call request_buffer() again. 15.32.19 *** Saving seen data "./dancer.seen" 15.33.48 Join footwork [0] (n=4af941c9@gateway/web/cgi-irc/labb.contactor.se/x-d8c70f3c4eac4b0e) 15.34.32 Quit footwork (Client Quit) 15.38.45 Quit CaptainKwel (Remote closed the connection) 15.39.14 Join evilnick_7 [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-4e3622584053af3d) 15.39.22 Quit kachna|lappy (Read error: 110 (Connection timed out)) 15.45.18 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 15.47.26 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 15.52.58 Join Strife89 [0] (n=michael@204.116.244.200) 15.55.01 Quit robin0800 (Remote closed the connection) 15.55.33 Quit SirFunk_ (Read error: 110 (Connection timed out)) 15.57.29 Join SirFunk_ [0] (n=Sir@208-15-25-145.netsync.net) 15.59.11 # hm... 16.01.05 # how can I increase the plugin cache so I can keep listening to music while playing pacman? 16.02.13 # thats not the issue 16.02.16 # Horschti: Music playback with Pacbox works on 64MB targets. 16.02.29 # * Horschti retries... 16.02.30 # My Gigabeast can play music and Pacbox at the same time. 16.02.58 Quit Mathiasdm ("Yuuw!") 16.03.59 # LambdaCalculus37: it's not a memory issue 16.04.16 # the 80GB ipod 5.5 won't play music at the same time as pacbox 16.04.33 # CPU too weak? 16.04.37 # yup 16.04.43 # the gigabeat F can do it 16.04.47 # and I think that's a 32MB target 16.04.52 # It is. 16.04.58 # GodEater: Thanks for clearing that up. 16.05.04 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 16.05.05 # any time :D 16.05.11 # Wasn't stripwax working on that though? The problem on ipods will also be that pacbox uses IRAM - and plugins and codecs cannot both use IRAM together. 16.05.18 # Ipod 5.5G is a 64MB target.. 16.05.22 Quit Horscht (Read error: 110 (Connection timed out)) 16.05.38 # linuxstb: no clue - that's not a project I was aware he was looking at 16.06.00 # I _think- stripwax was looking at using the second core for pacbox, but now that codecs are using the second core, that won't help... 16.06.42 Join Dillizar [0] (n=Elive_us@77.28.10.221) 16.06.54 # Horschti: yes, I know it's a 64MB target, as I was saying, it's not a memory issue 16.07.02 # http://www.rockbox.org/tracker/task/8226 16.07.23 # ah, missed the line about the Gigabeat F being able to do it 16.08.08 # The final comment on that task sums up the current situation... 16.08.18 # * GodEater bows before linuxstb's encyclopaedic knowledge of what's in flyspray 16.10.24 # Maybe a solution would be to make pacbox multi-threaded, with one thread on the main CPU, an one on the COP. That should hopefully make it play well with most codecs. But of course, someone who cares needs to do it... 16.12.11 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-8d448040fd9b2bab) 16.12.13 # forgive me if this is a stupid question but : 16.12.17 # ok, no biggie. I thought it was a memory issue and easily solvable. I see now that it is not and that's ok. I am not going to ask you to "fix it", I'll just do either or... 16.12.37 # thank you for the information :) 16.12.42 # when people say something like "Make X multi-threaded" - is it really that simple? I always thought you'd need to have a good idea of what needed a thread for itself each time. 16.13.14 # I'm not sure for instance in pacbox what lends itself well to multi-threading 16.13.16 # GodEater: What about "Make X multi-threaded" implies that it's simple. You're right, it's not. 16.13.39 # hehe - I didn't mean it would be simple at all :) 16.13.57 # It's just on the surface I'm not sure I'd know where to start 16.13.59 # It would need benchmarking, but I think splitting the CPU emulation and the screen updates would be fairly even. 16.14.27 # That's quite easy to benchmark - just disable screen updates and see how fast it goes. 16.16.32 # ah ha 16.17.38 # In fact, that could be a nice way to up the framerate in general... 16.25.09 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 16.25.40 Quit jfc (Read error: 104 (Connection reset by peer)) 16.26.03 Quit J-23 (Remote closed the connection) 16.26.07 Join J-23 [0] (n=zelazko@unix.net.pl) 16.29.28 Join jfc [0] (n=john@dpc691978010.direcpc.com) 16.30.26 Quit jfc (Client Quit) 16.30.43 Join jfc [0] (n=john@dpc691978010.direcpc.com) 16.32.29 Join toffe82 [0] (n=chatzill@74.0.180.178) 16.34.28 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 16.36.15 Join funman [0] (n=fun@rockbox/developer/funman) 16.37.33 Quit Strife89 ("Huzzah!") 16.43.30 DBUG Enqueued KICK CIA-38 16.43.30 # New commit by 03funman (r20986): Sansa Clip : ignore previous setting of CGU_DBOP (do not use ORR) 16.43.40 # New commit by 03funman (r20987): FS#10219 (AMSSansa Debug Clocks) by Jack Halpin ... 16.44.55 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 16.44.55 # * GodEater waits for the conversation to continue here 16.44.59 # * linuxstb spots some machine-gun committing... 16.45.12 # machine-gun? 16.45.23 # One commit quickly after another... 16.45.24 # rapid-fire 16.46.01 # thanks to git all my commits are committed to svn with one command 16.47.23 # Have any alternatives been suggested for the list of targets on the proposed new rockbox website, or are most people generally happy with it? 16.47.52 # * GodEater is not aware of any alternative proposals for it 16.48.57 # do you have an idea of how to redo it that sits well with the overall layout ? 16.49.01 # the problems I see with it are (a) it doesn't scale. Once we add two or three manufacturers the layout breaks (same problem if people want smaller windows), (b) it doesn't mention unsupported targets (sansa and ipod need those) 16.49.08 # * linuxstb repeats what he said in -community - that he would prefer a static list, and also for that list to indicate targets we don't support (e.g. the newer ipods and Sansas - with links to development status, if any), as well as ones we do. 16.50.24 # GodEater: the *current* way doesn't sit well with the overall layout :) 16.50.41 # unless you're happy with no new ports... 16.50.44 # I'm waiting to see the proposed better solutino 16.50.52 # GodEater: Not really... One idea that comes to mind is a table with manufacturers down the left, targets going across, and then colour-coding to say if they are supported (green?), in active development (amber?), or not supported (red?). But that wouldn't be a small table... 16.51.10 # indeed not 16.51.15 # I guess maybe we could simply move that info elsewhere, with a big "Supported devices" icon 16.51.17 # I don't think there's a nice way to get them all on the front page 16.51.24 # that might work better 16.51.38 # or perhaps "Can I use Rockbox?" 16.52.13 # * GodEater would really like to see the wiki template changes made as soon as possible 16.52.17 # while we're on the subject :) 16.52.26 # they're not very contraversial as I understand it 16.53.06 # Can they be done independently of the new main website? (I've no idea what you're talking about...) 16.53.31 # there were images in the forum thread for the proposed wiki pages design 16.53.49 # and I don't see why they couldn't be done independently 16.54.10 # I assume they change the colour scheme though? 16.54.26 # only a bit 16.54.30 # it's still predominantly blue 16.54.35 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 16.54.58 Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-17aae545cba28c9b) 16.55.32 # huh? The new proposal is almost white IIRC 16.55.47 # I'm trying to find it now 16.55.49 # I mean the background ;) 16.56.05 # http://forums.rockbox.org/index.php?action=dlattach;topic=12607.0;attach=3648;image 16.56.07 # looks blue to me 16.56.25 # ahem 16.56.41 # unless there was another one ? 16.56.46 # because I made it so 16.56.59 # yes... 16.58.10 *** SPY: Authentication failed for Zagor 16.58.17 *** Server message 901: 'logbot logbot n=bjst rockbox/bot/logbot :You are now logged in. (id logbot, username n=bjst, hostname rockbox/bot/logbot)' 16.58.17 Mode "logbot :+e" by services. 16.59.07 # his proposal was this: http://macku.to.pl/rockbox/html2/wiki.html 16.59.15 # yes it was - but yours was more popular was it not ? 16.59.21 # I plan on doing the wiki and other pages at the same time. I would have to split up the templates to do one without the other. 16.59.33 # ah ok 17.00.01 # Zagor: could we have all those things in svn somehow? 17.00.28 # not knowing whether you have the latest version is a bit annoying 17.00.36 # * GodEater thinks that's a stellar idea 17.00.47 # yeah I suppose we could simply branch the www module 17.01.02 # * gevaerts noticed that macku's latest zip isn't the same as new.rockbox.org 17.01.03 # cracking 17.02.17 # gevaerts: no I changed quite a bit in the css, stripping out the line heights etc. 17.03.40 Quit Zagor ("Don't panic") 17.07.09 # that .css is not easy to work with - many definitions to make sure it looks good in one size (fixed font sizes and whatnot) but not many things to take care of when someone does not use the browser at this size 17.07.40 # pixelma: I think I fixed most of that 17.09.19 # has anyone tried to track down a Gigabeat X image yet ? 17.09.43 # * toffe82 has a real one in his bag :0 17.09.55 # then you can take a nice picture of it for us! 17.10.33 # GodEater: http://gigabeatwiki.matritic.net/ 17.11.00 # http://gigabeatwiki.matritic.net/index.php?gigabeatX 17.11.20 # whoah 17.11.22 # the not completely tab-able menu is important IMO, had a try on changing that but wasn't completely successful yet (found whereabouts I need to change something, but somehow it didn't work yet) 17.11.25 # that looks a LOT like the S 17.11.30 # yes 17.11.38 # just missing the 2 buttons 17.11.44 # so it is 17.12.12 # GodEater: Tis a nice player indeed... if you can find one. 17.12.23 # I never tried looking ;D 17.12.51 # LambdaCalculus37: I will ship the gogear's this afternoon 17.12.53 # if those pictures are anything to go by though, the OF is a complete car crash 17.14.51 # toffe82: Thanks! :) 17.15.17 # * LambdaCalculus37 will start building up the GoGear manual pages 17.15.27 # GodEater: your car crash comparison reminds me of something... you are the first person (I think) who would call the wikipedia front page this way (which tries to look nice in a flexible way) 17.15.44 # toffe82: So as I understand it, the install process isn't quite finalized for the GoGears, correct? 17.16.08 # pixelma: I called the wikipedia front page a car crash ? 17.16.16 # * GodEater is clearly getting dementia 17.16.44 # LambdaCalculus37: there is not an easy install, you have to go in recovery to load the bootloader 17.16.51 # you called all pages that try to be flexible a car crash, something like that 17.17.20 # ah ok 17.17.24 # that makes more sense 17.17.52 # well, I still stand by that with your browser below a certain size 17.18.35 # LambdaCalculus37: I check quickly yesterday and when you connect to the usb , it reboot by himself, perhaps a last version of rockbox fix the proble 17.20.02 # toffe82: Okay, so since there's no finalized install method, I'll have to use the current method of install to describe the process. 17.20.09 # When it's finalized, we can have it edited. 17.20.12 # yes 17.20.25 # GodEater: the problems begin when "below a certain size" means "not exactly the same as the designer uses" 17.21.11 # LambdaCalculus37: the 1630 is the most usable, the 6330 needs tweaking on the touch pad, and the sa9200 doesn't have the touchpad 17.21.17 # enable 17.21.27 # gevaerts: I don't see any point try to design a page which works all the way down to 1x1 17.21.35 # you have to call it a day somewhere 17.22.36 # toffe82: How much tweaking on the touch pad? 17.22.58 # toffe82: Also, I have a friend who also owns an HDD6330, so maybe she can help me test it out and provide feedback. 17.23.20 # for the sa9200, you have to find the where it is connected 17.23.43 # so disassemble of the code 17.25.09 # Okay. 17.25.30 # saratoga: did you discuss with kugel why he disagrees that RBUtil support isn't mandatory for a SansaAMS release? 17.25.56 # LambdaCalculus37: I include the dock and remote for the 6330, it can be used also to charge the 3 , some connector 17.27.21 # toffe82, :D 17.27.23 # yeahhhhhhhh 17.27.31 # LambdaCalculus37: and also the japanese training I promise you a long time ago ;) 17.27.47 # question will an ipod fitted with a 240gig hdd be able to be rockboxed 17.28.04 # Lss: Yes 17.28.05 # toffe82, how to you put your hdd6330 in to recovery mode 17.28.15 # did* 17.28.26 # anything special that needs to be done? 17.28.49 # kind of like how the 30, 60/80 gig 5g ipods are not exactly the same 17.28.54 # Dillizar: http://www.rockbox.org/twiki/bin/view/Main/GoGearHDD6330 17.29.11 # Lss: Make sure it's a supported target (so iPod Video is the most recent), and you *might* have to use a special build with support for the larger (block sizes?) 17.29.22 # humm ok 17.29.30 # the 240gig hdd isnt exactly that cheap 17.29.37 # it would suck if i got it and it didnt work 17.29.42 # indeed it is not 17.29.51 # well, it does work. 17.29.59 # you have seen one? 17.30.10 # Lss: http://forums.rockbox.org/index.php?topic=20960.0 17.30.20 # no, but there are people reporting it to work. 17.30.36 # you need a custom build, that's all 17.30.52 # thats awesome 17.30.53 # thanks 17.30.56 # now to find one 17.30.57 # evilnick_7 was just emphasizing that you need an ipod that is "old enoiugh§" 17.31.30 # as in: don't go off buying a new ipod from the store, those are not supported. You need an Ipod Video, not an Ipod Classic 17.32.03 # no i already have an 80gig 5.5g 17.32.19 # rockboxed of course i cant stand using itunes 17.32.21 *** Saving seen data "./dancer.seen" 17.32.36 Quit petur ("work->...") 17.32.58 # if you got the money... go an strengthen the economy by buying a 240GB HD :p 17.33.14 # toffe82, ok in recovery mode i need just to unzip the rock box in to the player but what about the FWImage.ebn 17.33.56 # Dillizar: first is the bootloaderon the small partition, then unzip rockbox on the big partition 17.34.05 Quit matsl (Read error: 110 (Connection timed out)) 17.34.08 # k 17.36.33 Quit robin0800 (Connection timed out) 17.38.52 # GodEater: of course not, but designing a site for 1024 pixels wide and breaking at 980 isn't ok 17.39.12 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 17.39.34 # toffe82: I'll let you know when the package arrives. :) 17.39.38 # * LambdaCalculus37 has to go for now 17.39.46 Quit LambdaCalculus37 ("Fwump") 17.41.11 # toffe82, the recovery mode doesnt work :( 17.41.57 # Dillizar: try again.. are you connected to your computer... 17.43.13 Quit robin0800 (Remote closed the connection) 17.43.16 # yes toffe82 Disconnect the player from the computer and turn it off. 17.43.29 # Hold down the Volume + button and continue to hold it as you reconnect the player to the computer. 17.43.38 # but doesnt reconnect 17.43.41 # you don't have to disconnect if I remeber 17.44.26 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 17.44.26 # but then how can i tuen it off?? 17.44.31 # turn* 17.44.45 # Dillizar: http://forums.digitaltrends.com/showthread.php?p=73117 first comment and link to the video too 17.46.31 # FlynDice: ping 17.46.50 # funman: hi funman 17.47.16 # FlynDice: so, what are you working on, AMS hero ? ;) 17.47.25 # toffe82, so i need Philips Device Manager so i can go to recovery mode 17.47.31 # no 17.47.50 # just follow the procedure and it should appear as mass storage 17.48.19 # I did a bit of update/cleanup of SansaAMS & TargetStatus wiki pages, and now the only blocking issue is FS#10048 - where i'm a bit out of idea now. 17.48.27 # ha ha... I was going to look at your latest sd boundery thing. I've finally got some time now! I see you liked the patch ;) 17.48.45 # I want to play a bit with the pcm code, add some debug, but I fear that there is other problems than PCM 17.48.47 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.49.22 # sd bank boundary is simple, and after all it's only a problem for 8GB+ users (not me..!) 17.49.48 # toffe82, yes but that is Service Mode 17.51.05 # I've got the 8 gb e280, but I'm on-call for the paying job right now, how difficult is reconfiguring to return to a normal state after teesting? 17.51.37 # and i have only one partition 17.53.24 # Dillizar: I don't have so much time now , If you look the rockbox log and search for lowlight, you should find more information, I try to find out but need to work now.. 17.53.40 # ok 17.53.57 # FlynDice: as difficult as typing "mkfs /dev/sdb" (or formatting if you use windows) 17.57.15 # FlynDice: I still find a bit strange that using an uncached buffer for SD DMA transfers works fine, while using *_dcache() functions in mmu-arm.S doesn't. I suppose that we were doing something wrong there, since these functions work fine for other targets (when using correctly?) 17.58.49 # jhMikeS gave us some good advice, I don't know who else (experimented with caches on arm9tdmi) could have a look at our patch. 18.01.01 # Yes, strange is a word that keeps entering my mind every time I experiment with something it seems. The thought occurred to me that perhaps enabling the mmu somehow changed the clock freqs which got me onto finding something to check them 18.01.58 # I more think that it changed timing, and clock freqs need to be adjusted with more care 18.03.30 # The other thing I wanted to check was why simply mirroring the DRAM uncached seems to negate the need for the *_dcache() coherency routines. 18.04.27 Quit Grahack (No route to host) 18.05.01 Join JdGordon| [0] (i=46012a8c@gateway/web/ajax/mibbit.com/x-5b13d04d95f54385) 18.05.09 # Or pehaps it's a side effect of the last ata_sd patch 18.05.40 Quit JdGordon| (Client Quit) 18.05.57 # FlynDice: i told you that your patch has no effect ! 18.06.47 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 18.07.01 Join Strife89 [0] (n=michael@204.116.244.200) 18.07.10 # what if i dont coppy the FWImage.ebn! will it still work :P 18.07.19 # funman: questions about ARM cache behaviour? 18.07.35 Join l403 [0] (n=l@85.132.159.239) 18.08.02 # * Torne might be able to help if you point him at the problem :) 18.08.05 # funman: Not my embarrassing effort, but yours just before that. There were multiple errors in what I was trying to do but the code seemed to work well because I don't think it ever made it to my code 18.10.06 # what patch is this? 18.10.07 # Torne: yes, I think we are not maintaining cache coherency correctly during DMA transfers, are you willing to read a patch ? 18.10.07 # guys. I was building gcc following the steps in the guide setting up binutils and stuff and the make of gcc failed 18.10.14 # funman: sure 18.10.19 # funman: i'm an embedded kernel developer for a living 18.10.34 # funman: not done a lot of rockbox dev but i know how arm's caches work ;) 18.10.44 # http://www.rockbox.org/tracker/task/10048?getfile=19358 : ata_sd_as3525.c 18.10.52 # the config at the end of make failed. here's the log http://pastebin.com/m7dc0498c 18.11.37 # funman: lemme apply that to my tree and i'll have a look 18.11.48 # FlynDice: there are logical errors in your patch, look at my post of may 13th (fs 10048) 18.11.53 # Torne: do you own a Sansa AMS device ? 18.11.56 # no. 18.12.08 # so i can't actually test anything 18.12.19 # we tested for you, we only need understanding ;) 18.12.22 # heh 18.12.49 # starting a dma transfer from an uncached memory location works fine. 18.12.56 # so are you mapping it fully cached/buffered? 18.12.59 # starting a dma transfer from a cached memory location doesn't 18.13.08 # and your coherency updates are not seeming to work 18.13.09 # ? 18.13.19 # that's exact 18.13.29 # which direction does it go wrong in? or both? 18.13.41 # both 18.14.21 # well, maybe not for out, i didn't test extensively. The filesystem corruption could come from wrong transfer when reading 18.17.16 # heh. rockbox has yet another different set of terminology for cache ops 18.17.17 # hooray :) 18.17.33 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 18.17.38 # :) 18.18.13 # hum and the patch doesn't apply anymore, do you want an update? 18.18.18 # it applies to that file 18.18.19 # it's ok 18.19.01 # ok i'm suspicious that you are dumping the cachelines before *and* after DMA for the read 18.19.47 # I added cache dumping after DMA after - just to try. But no cacheline should have been fetched during the transfer 18.19.48 # that should only be needed if there is a risk someone might read the buffer while the dma is in progress 18.21.00 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 18.21.43 # but, yeah, it looks like you are doing the right ops there :) 18.22.05 # s'the same things any of our drivers do ;) 18.22.07 # ok .. i'm going to try again then. 18.22.21 # hm, actually 18.22.29 # i hope the functions drani the writebuffer 18.23.10 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.23.17 # yah 18.23.42 # also i assume that your buffer is cacheline aligned? :) 18.24.00 # hum it isn't necessarily 18.24.03 # funman: Oh yes, there are embarassing errors in that patch! It appeared to work when I did it though. But when I removed that code and removed the cache coherency routines I could still boot rockbox. Before that, without the *_dcache routines I couldn't get beyond the sd_init 18.24.08 # try cleaning/invalidating the entire cache 18.24.11 # it'll be slow 18.24.22 # but if that works and by-range doesn't then that points to the problem ;) 18.24.42 # funman: yeah kugel and i came to agree on his position and i updated the wiki to reflect it 18.24.58 # FlynDice: try removing the diff from ata_sd_as3525.c (using the uncached buffer) and it won't work for sure 18.24.59 # (also it may not actually be slower, large cache ops are slow as hell on ARM, over some threshold it's better to just kill the whole thing) 18.25.07 # we decided ams could be supported once the MMU, clock and write corruption problems are fixed 18.25.19 # and I guess the clip could be released without the write fix since its 4GB only 18.25.31 # saratoga: hillshum added the manual as a requirement (and i do agree with him) 18.25.43 # hum there's no 8GB Clipv1 ? 18.26.00 # not as far as I know 18.26.24 # funman: though having said that there's no dump_dcache(void); 18.26.35 # well, the write fix should be ready and only needs testing, right? 18.26.42 # yeah 18.26.58 # really we can put downloads up whenever the MMU issue is fixed even if we don't call it supported 18.27.04 # got to run 18.28.04 # funman: try if (write) clean_dcache(); else invalidate_dcache(); 18.28.09 # and nothing afterward. 18.28.21 # that will be a lot slower probably, but eliminates any alignment issues :) 18.28.52 # building.. 18.29.28 # the functions in arm-mmu.S make some effort to handle unaligned addresses, it looks like, but some of the comments imply it doesn't handle every possible case 18.31.28 Join Casainho [0] (n=chatzill@bl8-165-182.dsl.telepac.pt) 18.31.41 # Hello :-) 18.31.50 # NOR flash $2 for 32Mbit = 4Mbyte 18.32.16 # does anyone know if Rockbox bootloader + firmware + config files can be placed on a 4Mbytes? 18.32.30 # rockbox itself is under a meg 18.32.42 # codecs/plugins/etc are usually read from the storage fs, not flash 18.32.53 # (well, ok, that might also be flash) 18.33.10 # hum I disabled write (to not break my filesystem) and invalidate_dcache() instead of dump_dcache_range() sure fixes read transfers 18.33.26 # invalidate is doing more work, since it's writing back dirty lines 18.33.33 # but that doesn't matter, because you're about to overwrite it anyway 18.33.54 # Torne: but, all of it would be placed on 4Mbytes? 18.34.14 # Casainho: 4MB is going to be a bit tight 18.34.28 # so, 8mbytes ok? 18.34.40 # what're you trying to actually do? 18.34.48 # "base board will cost around $50 USD and have just RAM and MMC Card Connector, possibly some NOR Flash for the basic software as it is quite cheap - $2 for 32Mbit = 4Mbyte." 18.35.02 # a full rockbox for, say, ipod is 10mb 18.35.08 # but that's with all the codepages/languages 18.35.10 # games 18.35.10 # etc 18.35.13 # I am trying to choose 4Mbytes or 8Mbytes 18.35.26 # 8MB will hold a standard install, but if you want things like doom data or voices, which are also stored in .rockbox, that won't work 18.35.31 # ah, ok, so maybe 16Mbytes 18.36.02 # if you're going to put a regular FAT filesystem on the nor flash to hold .rockbox then you'll need an FTL for it, too.. 18.36.07 # And then at least double it to try and predict the future... 18.36.14 # which may or may not interfere with using it as an actual boot flash, depending how you do your FTL 18.36.21 # FTL? 18.36.26 # flash translation layer 18.36.30 # to make flash behave like a block device 18.36.51 # mcrrhs p15, 0, r1, r0, c6 @ Invalidate DCache range 18.36.55 # because memory card seems much cheaper than that memory.. 18.37.09 # i do not remember seeing that in arm922tdmi reference manual 18.37.22 # Casainho: you're much better off putting a bootloader and possibly the main rockbox binary in flash (in which case 4MB is enough) and use a "fixed" MMC/SD card for .rockbox 18.37.38 # it even says that we can access cp15 "only with mcr/mrc" 18.37.42 # yeah. only the rockbox bootloader actually needs to be in NOR flash 18.37.48 # gevaerts: ok, nice then. I want to save on money ;-) 18.37.53 # maybe the binary itself for boot speed 18.37.57 # but not the .rockbox folder 18.38.08 # in fact it is considerable effort to do so since you need an FTL then 18.38.10 # hum i'm not reading the correct implementation .. 18.38.12 # as FAT is not flash-compatible. 18.38.14 # wouldn't codecs in flash also help a bit? 18.38.16 # Casainho: can you put two MMC connectors on it? That would be about perfect I thingk 18.38.38 # dionoea: not a lot.. 18.38.43 # k 18.38.45 # dionoea: codec is only loaded when skipping between tracks that need different ones 18.38.48 # gevaerts: no, the board is already desingend and on prodution 18.39.14 # Casainho: in that case you'll have something that's not very usable... 18.39.19 # and I don't know yet if tthe MCU (LPC3130) can hold 2 memory cards... 18.39.23 # Casainho: if you don't know what an FTL is then you are not in a position to be deciding this, I have to point out.. putting a FAT filesystem in Flash is not entirely trivial 18.39.39 # and i don't think rockbox has any capacity to load rocks from anywhere other than FAT 18.39.39 # Torne: ok, thanks 18.39.49 Quit robin0800 (Remote closed the connection) 18.40.07 # Memory cards have their own FTL implemented in hardware 18.40.21 # if you are using raw flash chips you would have to do it yourself in software which isn't something rockbox has afaik :) 18.40.26 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 18.40.40 # also lots of FTL algorithms are patented up the wazoo, msotly by samsung (though the linux folks tend to just Pretend Not To Notice) 18.41.22 # anyway i need to head off for now 18.41.43 # funman: ping me at your leisure if you need any more help with cache stuff 18.42.11 # Torne: which comment lead you to think the functions don't handle every possible unaligned case? 18.42.26 # (i'm reading dump_dcache_range for arm9) 18.42.49 # dump_dcache_range says "will not do write back except for buffer ends not on a line boundary" 18.42.59 # i'm nto entirely sure what whoever wrote that meant :) 18.43.05 # it just generally makes me slightly suspicious 18.43.34 # well, i understand that we don't write back cachelines which are entirely in our buffer. 18.44.06 # but we do for cachelines which are half in our buffer, half somewhere else. 18.44.10 # ah 18.44.14 # that's.. interesting 18.44.22 # i would generally assume that was broken :) 18.44.51 # that has the potential to break stuff if buffers are close to each other and not line-aligned. 18.45.10 # though, er, idaelly they wouldn't be ;) 18.45.52 # you probably want your buffer to be 32-byte aligned. 18.45.59 # just because it's nicer :) 18.46.03 # anyway, gone now for rael :) 18.46.12 # thanks for your help ! 18.48.34 Join JdGordon| [0] (i=836b0070@gateway/web/ajax/mibbit.com/x-cc2dd66e442302cc) 18.52.54 # funman: On a slightly differnt note, do you have an opinion on the synchronous vs asynchronous clocking schemes? 18.53.38 # yes, I think we need to see what are the lowest frequencies we can use to minimize power usage 18.53.52 Quit Casainho ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 18.54.40 Join Llorean [0] (n=DarkkOne@ppp-70-245-71-9.dsl.hstntx.swbell.net) 18.58.06 Quit Tuplanolla (Read error: 60 (Operation timed out)) 19.03.57 Join miepchen^schla [0] (n=miepel@p579ECC48.dip.t-dialin.net) 19.04.50 # can mcr/mrc update the cpsr? 19.06.06 Join Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) 19.08.40 # what should the *modified* virtual address look like : like the virtual address, with bits 4:0 unset? or something additional? 19.09.09 Quit flydutch ("/* empty */") 19.11.55 # page 2-6 (page 32 of pdf) of arm922t technical reference manual says : "ProcID translates the Virtual Address issued by arm9tdmi core to a MVA, seen by MMU & Instruction cache". 19.16.19 Join BryanJacobs [0] (n=BryanJac@www.q3q.us) 19.16.53 # from google : "The VA is combined with the PID to form a MVA" : so I understand that the MVA may be different from VA only if FSCE is used 19.19.54 # Horschti: one more thing to try : in usb_storage.c, near the bottom, change "tb.inquiry->DeviceTypeModifier = DEVICE_REMOVABLE" to "tb.inquiry->DeviceTypeModifier = 0;" and see if it makes a difference 19.20.02 Quit bubsy ("Mrrrrreow!") 19.20.45 # sometimes i think i should keep the virtual machine running :D 19.21.26 # * amiconn still doesn't understand why the website would need a redesign 19.22.15 # * gevaerts can think of some ways to make usb_storage.c itself even faster, but he doesn't want it to get a reputation similar to that of the playback code 19.22.35 # what's the rep of the playback code? 19.23.03 # gevaerts, usb_storage.c in firmware/usbstack, correct? 19.23.28 # Horschti: yes 19.24.32 # Horschti: after that, be more careful about safely removing hardware :) 19.24.45 # i always remove safely 19.25.28 # wait... that makes me think of something that could have manipulated the results all along... gonna check something... 19.26.24 # * Horschti slaps forehead 19.27.04 # FlynDice: thanks to Torne I have some ideas on where to work.. see you later 19.28.08 # of course, setting the policy to "optimize for performance" should increase my writing speeds... Obviously the OF identifies differently to the OS therefore setting the policy only applies to the OF... 19.28.41 # Horschti: Interesting point. 19.29.18 # yes, ofc. OF shows up as "Apple Ipod USB Device" 19.29.41 # Rockbox shows up as the HD Name "Toshiba somethingtomethin" 19.30.22 # why the hell didn't i check that... All the rsults and test I made were futile. 19.30.27 # sorry gevaerts 19.30.56 # funman: so long I'll post any results I get from the boundery patch 19.30.59 # i'll try with the speed policy first now... 19.31.12 # Doesn't the OF show up as "Apple Ipod USB Device" and then again as the type of disk inside the ipod? 19.31.29 # not as far as I remember 19.31.32 # no, it shows up as "Apple Ipod USB Device" in hardware 19.31.43 # Ah, okay. 19.31.44 # FlynDice: don't forget to post your method as well! (patch + dd command) 19.32.22 *** Saving seen data "./dancer.seen" 19.32.55 # sure thing.. hey i'm looking at the debugclocks patch and it's not "live info anymore. Was that on purpose? 19.33.08 # er "live" 19.33.35 # hum what do you mean? 19.34.18 # the while loops just enclose the get_button calls and not the actual frequency calculations 19.34.38 # the buttons are reading much better though... ;) 19.35.27 # oh .. yes, i wanted to make button reading realtime (too fast presses were ignored) 19.35.53 # yes that's the problem I was having too 19.36.05 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 19.36.30 # do we really need realtime data? there's no clocks changing on the fly except i2so (and i2si) 19.37.30 # gevaerts, enabling the speed policy profile resulted in slightly faster writing speeds of 7.8Mbyte/s and read speeds of 13.2 19.37.41 # so I'll try the other thing you posted 19.38.06 # well I found it useful to see what was changing when and in what relationship. It gave me a better feel for what was going on 19.38.13 # well, 6.3 vs 7.8 isn't "slightly" :) 19.38.28 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.38.41 # I was bouncing between sync, async and fastbusses 19.38.43 # not as much as I expected. I always thought there was a realy big difference between the profiles 19.39.03 # I'd be interested in the speeds you'd get on a fully defragmented drive, but that's not really practically doable... 19.39.20 # i think it is pretty much defragmented... 19.39.36 # oo defrag mentions a fragmentation of only 3% 19.40.08 # FlynDice: you mean with cpu boosting? 19.40.19 # bertrik: hi! have some minutes to speak about i2c on sansa ams? 19.40.31 # yes you can tell what is being changed on the fly 19.40.59 # Horschti: I get 14.2 read and 9.4 write on the raw device (30GB ipod). You're going to get slightly different speeds of course (80GB, right?), but I expect slower write than read at this point. 19.41.15 # yes, 80GB 19.41.51 # i just compiled with the change you made above (and UDMA 4)... I'll test again 19.43.17 # FlynDice: i can't think of a solution with live update and realtime button handling 19.43.30 # funman: I just modified it slightly and the "live" part and buttons work fine. 19.43.32 # if you think live update is more important, then it should be changed 19.43.40 # cool ! 19.44.28 # it'll take a few minutes to figure out the clip parts, you want me to post it on the forum or email it? 19.44.53 # whatever is the fastest - i really need to go 19.45.03 # gevaerts, "tb.inquiry->DeviceTypeModifier = 0;" did not have any effect on speeds 19.45.04 # see ya 19.45.22 # 7.8 write, 13.3 read 19.46.04 # ok. I'm experimenting a bit here 19.46.06 Nick Horschti is now known as Horscht (n=Horscht@xbmc/user/horscht) 19.49.07 Quit funman ("long life vlc") 19.54.34 # hm, I can increase write speed by 1.3MB/s. About half of that comes from *reducing* the transfer buffer size, and half from not waiting for the disk I/O (which of course makes error reporting break, so I won't do it in an official build) 19.54.35 # FlynDice, my impression so far is that we've mostly been "tinkering" with all the clock and bus related settings 19.54.51 # We just need to sit down and put some design into it I think 19.56.49 # AFAIK the datasheet is quite clear about the limits of the clocks and the conditions for the various bus modes. I haven't really looked into this myself, so probably it's easier said than done 19.58.29 # bertrik: I agree with that assessment, that's why I tried to come up with something I could look at to see just what was going on with the clocks! 19.58.44 Join xnyhps [0] (n=xnyhps@2001:470:1f14:da:219:e3ff:fed7:c57c) 20.00.06 # The thing is that some things that are not supposed to work do indeed work... 20.00.20 Quit crwll (jordan.freenode.net irc.freenode.net) 20.00.20 NSplit jordan.freenode.net irc.freenode.net 20.00.20 Quit bittin```` (jordan.freenode.net irc.freenode.net) 20.00.21 # Horscht: for some extra speed, look for BUFFER_SIZE near the top of usb_storage.c and change it from 65536 to 32768 (i.e. halve it) 20.00.22 NHeal jordan.freenode.net irc.freenode.net 20.00.22 NJoin bittin```` [0] (i=bittin@anapnea.net) 20.00.50 NJoin crwll [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 20.03.33 # k 20.04.58 Quit Rob2223 (Read error: 104 (Connection reset by peer)) 20.05.35 Join Rob2222 [0] (n=Miranda@p4FDCD704.dip.t-dialin.net) 20.06.20 Join antitrons [0] (n=Mudkips@119.224.12.185) 20.06.27 Quit antil33t (Nick collision from services.) 20.06.50 Join Lear [0] (i=chatzill@rockbox/developer/lear) 20.07.52 Join bubsy [0] (i=Bubsy@94.139.72.137) 20.11.03 Join juane414 [0] (n=chatzill@119.149.14.227) 20.12.00 # Hey all just finished my new WPS... anyone willing to test it out and let me know what they think?? 20.12.19 # you know... 20.12.28 # Was this the one for the iPod Video? 20.12.30 # it would be helpfull if you mentioned what target ;) 20.12.43 # yes ipod video 20.12.53 # * evilnick_7 spins the roulette wheel and wins 20.13.05 # still haven't made the .cfg for it yet but the wps works 20.13.20 # any one here has a gogear?? 20.13.23 # spent the last 3 days on it and i'd love some feedback 20.14.00 # o could ttry it 20.14.07 # juane414: I'm at work now, but can test it on target in a few hours 20.14.08 Join dfkt_ [0] (i=dfkt@chello062178002170.1.11.univie.teleweb.at) 20.14.14 # where can i find manual for installing rockbox on gogear 20.14.21 # sounds cool 20.14.33 # juane414, i can try it right now... 20.14.33 # evilnick_7: i'll actually be in bed then... 20.14.50 # Horscht: great how can i send the files to you? 20.14.55 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 20.14.55 Quit perrikwp (Read error: 104 (Connection reset by peer)) 20.15.13 # juane414: I'd like to see it as well :) 20.15.21 # upload it to some 1-click hister or something 20.15.26 # i need some help with manual install 20.15.31 # know any good ones? 20.15.35 # rapidshare or similar 20.16.28 # juane414: can you dcc it to me? I hate downloading things from those 1-click things... 20.16.28 # gevaerts: Smaller buffer is faster? /me puzzled 20.16.28 # or even mail, if you prefer 20.16.46 # oh email would work 20.16.56 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 20.16.58 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-605504ac14236f9b) 20.17.00 Join fyrestorm [0] (n=nnscript@cpe-24-90-81-8.nyc.res.rr.com) 20.17.08 # can you guys just pm me your email address? 20.17.16 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.17.34 # amiconn: that's because of this double buffering scheme. A 64k buffer means read 64k from usb, write 64k, and so on. 32k means read 32k from usb, write it to disk while getting the next 32k, write 32k. 20.18.49 # ok i'll send out the files in a minute 20.19.08 # just to warn you guys i haven't tested any fonts so it might look goofy depending on what font you try 20.19.44 # should we have closed all the out standing feature requests? 20.20.01 # juane414: Which font did you design it with? 20.20.02 # Dillizar: You can't find a manual as it isn't supported yet 20.20.13 # saratoga: Yes, I think so - I was just about to have a look 20.20.17 # gevaerts, halfed the buffer, read: 8,06 MByte/s write: 8,52 MByte/s 20.20.21 # i'll do it now 20.20.33 # still UDMA 4 20.20.33 # OK 20.20.42 # Horscht: ok. I'll probably end up using different buffer sizes for read and write 20.20.51 # oh theres no way to close multiple tasks at once 20.20.58 Quit dfkt (Nick collision from services.) 20.21.01 Nick dfkt_ is now known as dfkt (i=dfkt@chello062178002170.1.11.univie.teleweb.at) 20.21.11 # AlexP, but they already did and i have the rock box for hdd6330 i put it in to recovery mode but i have only one partition 20.21.20 # the GNU Unifont is what I was using 20.21.24 # seems to work well with ti 20.21.35 # and i dont know where to put the FWimage.ebn 20.21.38 # Dillizar: I was telling you that there is no manual, and no support for it yet 20.22.01 # juane414: Can you include that info on the email? I won't get chance to look at it for a while and will no doubt forget which font it was! 20.22.09 # amiconn: we could still double-buffer with 64k transfers by lying about write completion, but I really don't want to do that 20.22.15 # sure 20.22.30 # AlexP, but toffe82 has rockbox on his hdd6330 20.22.42 # Dillizar: And he is a developer 20.22.50 # also one more warning... gmail isn't going to let me attach the bitmaps in a folder so they are all individual files, so you'll have to make a folder to put the bitmaps in 20.22.54 # :) 20.22.54 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 20.22.55 # Dillizar: It has not been released, and is unsupported 20.23.05 # he gave it to me 20.23.06 # :) 20.23.06 # juane414: zip it 20.23.07 # juane414, zip it up :D 20.23.09 # Dillizar: just wait for someone to answer you and stop spamming the channel 20.23.14 # haha lol good point 20.23.16 # Dillizar: None of this changes that it is unsupported 20.23.28 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-4b7c942f8802ddf3) 20.23.35 # :) saratoga spamming?? 20.23.44 Join high-rez [0] (n=gus@carrera.bourg.net) 20.24.26 # I'm trying to install rockbox onto my 5th generation 30g ipod... But the rockbox util won't detect the device (under os x) 20.24.53 # high-rez: It needs to be a winpod 20.25.02 # linuxstb: you there? 20.25.10 # AlexP: Doh. 20.25.33 # high-rez: The easiest way to achieve this is to recover it with itunes on Windows, but there is a manual method outlined on the wiki where you can convert from a Mac and without losing data 20.25.54 # high-rez: But it is highly recommended to have a back up of everything before starting 20.25.54 # I don'ty mind losing data. I don't even really use the thing. :) 20.26.23 # high-rez: You can install fine to a winpod from OSX, and a winpod works fine with OSX, but Rockbox only supports FAT32, not HFS+ 20.26.34 # high-rez: And just reformatting won't do it :) 20.26.35 # okay guys files are sent 20.26.47 # let me know what you think of it and any suggestions for improving it 20.26.53 # high-rez: If you have access to a Windows PC with itunes by far the easiest way is to use that to restore it 20.26.56 # AlexP: Ok i'll go look for this howto 20.27.01 # hmm 20.27.01 # ok 20.27.07 # I have windows insalled under virtual box 20.27.12 # so it shouldn't be a problem 20.27.13 # :) 20.27.48 # high-rez: http://www.rockbox.org/twiki/bin/view/Main/IpodManualRestore 20.28.16 # high-rez: I assume that works on a Mac too, but I don't know 20.29.04 # gevaerts: There is no way to delay the acknowledge? 20.30.10 # hey guys it's possible that the album art isn't working either 20.30.15 # i didn't really test that out 20.30.19 # so if it's not let me know 20.30.41 # linuxstb: Does the mac allow to format a partition as fat32 (i.e. on mac-partitioned hdd, not mbr)? 20.30.48 # amiconn: I think we could tell the OS that we cache things, and implement the various cache flush methods. I'm not sure if it's worth it though 20.31.33 Join Strife1989 [0] (n=michael@204.116.244.200) 20.31.48 Quit fyre^OS (Read error: 110 (Connection timed out)) 20.32.00 # juane414, album art works. 20.32.02 Nick evilnick_7 is now known as How_unfortunate_ (i=0c140464@gateway/web/ajax/mibbit.com/x-4e3622584053af3d) 20.32.11 # cool 20.32.27 # just the playlist position seems wrong... 20.32.42 # amiconn: you could always use mkfs.vfat if there's no native method 20.32.51 # MacOS is a UNIX 20.32.52 # playlist position? 20.33.00 # gevaerts: I'm curious whether the OF(s) are doing this 20.33.20 # juane indicating the current position of the track in the playlist. 20.33.40 # ah gotcha 20.33.41 # it should say 2/9154, but instead it say 2/10 20.34.43 # hmmm... one sec 20.35.42 # ah that's not playlist position 20.35.50 # thats %in 20.35.52 # track number 20.36.00 # ah! 20.36.02 Quit Strife89 (Read error: 110 (Connection timed out)) 20.36.13 # yeah, that makes sense.. 20.36.23 # i intend on adjusting the info a bit 20.36.35 # i'd like to add next track info 20.36.38 # and a few others 20.36.38 # right... i should have skipped to the next track to notice that :D 20.37.08 # are the graphics final? 20.37.23 # no 20.37.28 # nothing is final 20.37.30 # :) 20.37.53 # I like the idea of the .wps, but the graphics could have a more "clean" feel to it. 20.37.53 Quit blithe ("Lost terminal") 20.38.04 Join blithe [0] (n=blithe@blakesmith.me) 20.38.28 # yea i can try messing with colors and contrast to try and smooth it out 20.38.43 # i used some sharply contrasting colors 20.39.21 # yeah, make it look a little bit more like a real dashboard 20.40.13 # I can try :) 20.40.30 Nick How_unfortunate_ is now known as evilnick_7 (i=0c140464@gateway/web/ajax/mibbit.com/x-4e3622584053af3d) 20.40.37 # BTW... does album art need to be .bmp? 20.40.56 # or jpg 20.40.57 # no, it can now be .jpg 20.41.02 # huh 20.41.07 # i can't seem to get it working... 20.41.16 # folder.jpg works 20.41.21 # well 20.41.26 # in the same folder as the music files 20.41.30 # depending on your build number 20.41.41 # okay i had cover.jpg 20.41.43 # it has only been implemented ~3 weeks ago 20.41.58 # cover.jpg should work 20.42.00 # cover.jpg *should* work too 20.42.07 # hmmm 20.42.28 # well, how old is your rockbox build? 20.43.19 # 3.2 20.43.27 # it works on the sim... but not on my ipod... 20.43.29 # strange 20.43.38 # so not a SVN build just the 3.2 release? 20.43.46 # you have to update to a current build 20.43.47 # yea the 3.2 release 20.44.09 # http://build.rockbox.org/ 20.44.24 Join tessarakt [0] (n=jens@e180070119.adsl.alicedsl.de) 20.44.49 # juane414: 3.2 is a while old now - jpg album art was added after that 20.45.00 # okay that must be the problem then 20.46.03 # do i just copy-past the .rockbox folder to my iPod? 20.46.19 # yes, overwriting all files 20.47.07 # funman, if you're reading the logs, yes I have some minutes. I experimented a bit with ams i2c yesterday and can reproduce the same behaviour as having high clocks. Can't fix it yet though (hoped to fix it by looking at interrupt status instead of the "busy" bit in the SR) 20.48.21 # BryanJacobs: If you have questions about stuff it is best to ask the channel - there are often other people about that can help 20.48.42 # Horscht: any other suggestions you have for improving the theme? 20.48.50 # AlexP: I was just going to tell linuxstb about some results from a conversation from yesterday 20.49.05 # if anyone is interested, I discovered that WavPack blocks are routinely ~16k 20.49.14 # and the correction blocks can be 40+k 20.49.38 # meaning that the current buffer space is insufficient to hold a "normal" WV+WVC block pair 20.49.44 # BryanJacobs: It is often useful to just share - you never know who has what knowledge :) 20.49.44 # linuxstb will likely read the from the logs :) 20.49.52 # all righty then 20.49.58 # besides, we're ALL interested in the GSOC projects :) 20.50.03 # very much 20.50.32 # well, that's what I found out by writing a little wavpack file parser and trying it out on the "Bad Horse Chorus" encoded using -b256 -c 20.51.00 # right now I'm seeing what the pattern of metadata blocks looks like 20.51.09 # New commit by 03gevaerts (r20988): Use different read and write buffer sizes. Due to interaction between common transfer sizes used by most OSes (64k) and the double-buffering system we ... 20.51.21 # * gevaerts looks at Horscht for more testing :) 20.52.30 # what's the best way to convert uchar[3] into uint32_t architecture-independently? 20.52.36 # I don't want to test for endianness 20.53.01 # * GodEater assumes amiconn will have a good idea about that 20.53.03 # or, really, to fseek(... , SEEK_CUR) based on the amounts in a little-endian uchar[3] 20.53.47 # uchar[2] << 24 | uchar[1] << 16 | uchar[0] ? 20.53.59 # that's not arch independent, right? 20.54.09 # I mean, what if the platform we're on is big endian 20.54.09 # sure it is 20.54.23 # with different shifts ... 16, 8 and 0 20.54.38 # hm? 20.54.54 # on little endian, should be [2] << 16 | [1] << 8 | [0] 20.55.05 # on big endian, should be [0] << 16 | [1] << 8 | [2] 20.55.23 # that depends on where that uchar[] comes from 20.55.32 # I got it backwards 20.55.33 # BryanJacobs: metadata_common.c in Rockbox contains some different versions you could look at. 20.55.43 # the uchar[] is always little endian, no matter what 20.55.44 # * Horscht stares at gevaerts :) 20.55.48 # BryanJacobs: if blocks are that big in wavpack, i guess you'll need to split them 20.56.00 # Lear: will look 20.56.14 # do you know how many time domain samples wavpack needs to decode one PCM sample? 20.56.15 # saratoga: yeah, not looking forward to that - why is the buffer 32k? 20.56.26 # Horscht: that last commit is the best I can do without overhauling usb_storage entirely :) 20.56.27 # saratoga: sampling rate 20.56.41 # BryanJacobs: to save memory and because for most formats thats a lot of data 20.56.44 # oh, you mean NEEDS 20.56.50 # juane414, no, appart from the colors/graphics it's a nice theme. Allthough I prefer bigger album art myself (huge, 200x200) 20.57.02 # gevaerts, as in reverting to default? 20.57.07 # let me check how many are necessary - I think it's theoretically up to the whole block 20.57.15 # oh wait 20.57.28 # i should read what people write more carefully 20.57.31 # saratoga: doesn't an iPod 5.5G have 64MB of RAM? 20.57.41 # Yea there is not that much space for huge album art 20.57.42 # isn't 32k a little ... spartan for that platform? 20.57.45 # BryanJacobs: since this is a time domain coder (I assume anyway) it probably looks at some number of past samples are used to try and predict the next sample, but its probably a relatively small number otherwise decoding would not be possible on CPUs as slow as we have 20.57.45 Quit Dillizar ("I ♥ Elive") 20.57.49 # thanks for the feedback i appreciate it 20.58.14 # saratoga: I need to look at the reference decoder b/c that's not in the docs 20.58.22 # juane414, yeah. I understand that. Huge album art simply doesn't fit the concept. 20.58.37 # BryanJacobs: do you have a link handy to the docs? 20.58.47 # http://www.wavpack.com/file_format.txt <-- file format 20.58.47 # juane414: looks nice :) I'd like to see smaller intervals, but you're probably already near the image buffer limit I guess 20.59.25 # http://www.wavpack.com/wavpack_doc.html <-- user docs 20.59.31 # Horscht: what I committed should be as fast for read as before, and slightly faster on write than the last one you tested 20.59.39 # gevaerts: not necessarily, I was planning on trying to make smaller intervals for at least the song progress dial 20.59.48 # i'll give it a whirl, gevaerts 20.59.58 # gevaerts: maybe not for the battery and volume though 21.00.04 # "it is possible to decode regular stereo (or mono) WavPack files without buffering an entire block, which allows the memory requirements to be reduced to only a few kilobytes ifdesired." 21.00.07 # sounds good . . . 21.00.14 Quit xnyhps ("Leaving.") 21.00.39 Quit juane414 ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 21.01.03 # /me cannot seem to find docs on exactly HOW 21.01.03 # is there a doc explaining the format it self and not just the bitstream? 21.01.29 # saratoga: I'm searching but all I'm pulling up other than those two links is the library_use.txt file; how to use the library 21.01.37 # JdGordon|: if you want to go to the limit, you could make short line images, and use more than one for each needle 21.01.50 # I think the reference decoder is the only place to go for how decoding is actually performed 21.01.53 # hm, juane414 left :\ 21.02.46 # wikipedia has a very nice overview 21.04.03 # it seems the author has designed this format with very low memory usage in mind, so I do not think you will have serious problems getting it to work 21.04.17 # I just don't know the bounds on the requirements... 21.04.27 # I'm sure it can be done, I'm just not yet sure how much must be pulled in 21.05.00 # that wiki article isn't technical enough 21.05.21 # "An adaptive algorithm continuously determines the most efficient of the three to send based on the changing balance of the channels" 21.05.41 # it seems to imply that there's a one-frame lookbehind, but then there's that line 21.06.04 # that could be unbounded state 21.06.18 # this will likely be of use for you: http://www.wavpack.com/WavPack.pdf 21.06.19 # BryanJacobs: Just to say that I'm not around, but will check the logs later... 21.06.29 # thanks for sharing 21.08.58 # prediction seems to be quite simple needing only a few bytes of stored samples 21.10.44 Join {phoenix} [0] (n=dirk@p54B4722E.dip.t-dialin.net) 21.10.54 # so then what we do is store the block header+metadata somewhere in the codec memory, and repeatedly buffer frames rathen than whole blocks? 21.12.25 # from the sound of it you could just interleave the lossy and correction blocks in arbitrarily small blocks (say 256 bytes) 21.12.35 Join arohtar [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 21.12.51 # so let's try that first, before tackling the thrash-seeking issue, eh? 21.12.59 # i think the trick will be figureing out how to sync them, if the block size is very large it might be difficult to figure out which byte in the correction file goes with which byte in the lossy file without decoding it first 21.13.25 # it's OK as long as we know when we've run out of one or the other 21.13.27 # i think figuring out how to do this from a simple command line decoder program on your PC would be a great first step 21.13.37 # that's what I'm doing right now, actually 21.13.45 # I've got the wavpack parsing for both WV and WVC 21.13.52 # its more complicated thent hat because if you get too far ahead of one then it may not be buffered in time 21.13.53 # hm, optimal write buffer size seems to vary between devices. Not entirely unexpected of course... 21.14.01 # I was thinking next I'd try to get some sound 21.14.26 # So... My iPod shows up as a disk drive when I plug it into windows, but its not really accessible... 21.14.44 # E.g. if I try to open the disk itself I get an error. 21.14.46 # gevaerts: what? optimal values for parameters vary between different embedded devices? never! 21.14.51 # while buffering you'll need to dynamically watch the position in both the correction and lossy files to keep blocks sorted in time (i.e. make sure you don't put a correction file block 10 minutes away from the lossy block it needs) 21.15.02 Part Grahack 21.15.12 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.15.14 # high-rez: Have you set it to Disk-Mode in iTunes? 21.15.17 # BryanJacobs: exactly! Why should they be different? :) 21.15.33 # evilnick_7: that may be what I'm missing... :) 21.15.55 # saratoga: so, how about we at first fill the buffer 25/75 lossy/lossless, since that seems to be the approximate ratio 21.16.12 # and then as one depletes we refill it 21.16.36 # our time lag can't ever be too great because we only fill up to some preset high-water mark of readahead 21.16.52 # thats a good first start but for large block sizes you'll eventually get more then 32KB apart and fail (though maybe large enough blocks for that to happen aren't used in practice) 21.16.58 Quit faemir (Read error: 104 (Connection reset by peer)) 21.17.09 # how would we get too far apart? 21.17.17 # evilnick_7: Just "enable disk use" right ? 21.17.22 # gevaerts, read: 13,3 MByte/s write: 8,85 MByte/s 21.17.33 # imagine two distinct virtual buffers 21.17.36 # you don't know the bitrate of the correction blocks in advance, so if you assume a value eventually you'll be very far off 21.17.57 # so, as you projected, slight increase in write speed. 21.18.04 # but we know how many frames were actually unpacked 21.18.12 # because they're put into the PCM buffer 21.18.16 # imagine trying to buffer a 10MB block and you get the bitrate wrong by 1%, by the end the correction file will be 100KB off and decoding will fail 21.18.28 # high-rez: It's been a *long* time since I did it but I think it's literally just a check-box when you first connect the iPod 21.18.31 # why do we need this "bitrate"? 21.18.39 # we can read whenever we need to 21.18.48 # read speed stays the same. Since I have FS 9708 i.e. UDMA enabled, wouldn't the ipod also use less power during filetransfers? 21.19.13 # event: the codec has finished with what I read from disk (or at least one stream of it) action: read some more 21.19.47 # see what I mean? 21.20.14 # since we, as you pointed out, don't know how many bits we need per frame, don't even try to keep a constant flow from the disk 21.20.50 # the WV stream can be traditionally buffered, and the WVC stream can be a run-dry system 21.21.02 # BryanJacobs: you can't read whenever you want, it all has to be buffered before decoding begins 21.21.20 # understood. Let me explain more clearly: 21.21.48 # sequence of events: 1) buffer is preliminarily filled 2) codec is invoked and decodes as much as possible 21.22.08 # 3a) codec runs out of WV frames first 4a) disk reads more WV frames 21.22.21 # 3b) codec runs out of WVC frames first 4b) disk reads more WVC frames 21.22.36 # why do we need to know the bitrate for this procedure? 21.23.13 # as long as our buffers don't clobber eachother... 21.23.39 # while that is one solution it will lead to reduced battery life 21.23.57 # i was under the impression that the solution we wanted was to interleave the two files into a common buffer during load time 21.24.02 Quit Strife1989 ("Huzzah!") 21.24.19 # define "interleave" 21.24.30 # in order to get an AVI-style interleaving we need sync 21.24.49 # what we really want is to keep the amount of WV and WVC frames available approximately constant to reduce spinups 21.24.54 # Horscht: I don't know about power. I'd guess most of the power goes to keeping the disk spinning anyway 21.24.57 # that could be done by an adaptive algorithm 21.25.10 # * gevaerts decides that he has done enough usb work for the day 21.25.20 # "if we fall behind on WVC frames, next time buffer a greater WVC:WV ratio" 21.25.23 # right? 21.25.59 # gevaerts, just for the record, I cleaned the table a bit: http://horscht.googlepages.com/rockboxbench 21.27.02 # i removed all old results, which were not representative at all since they were not using the speed profile of windows anyways, so they were not a fair comparison to the OF results 21.28.52 # Horscht: maybe it would be interesting to have pure svn there, as well as udma1 (as that's probably most likely to get in) 21.28.55 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 21.29.15 Quit hd (Read error: 104 (Connection reset by peer)) 21.30.16 # ok, gonna do that 21.32.25 *** Saving seen data "./dancer.seen" 21.35.25 # BryanJacobs: I'm not sure, you should probably ask linuxstb since he knows the buffering code better 21.35.50 # eh, I'm going to watch Doctor Who now, I'll finish this tomorrow 21.35.55 # ttyl all 21.36.09 Part BryanJacobs 21.40.41 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 21.41.11 Quit BXCracer (Remote closed the connection) 21.41.17 Join moredhel [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 21.41.30 # oooh, a feist fan 21.41.55 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 21.44.00 Quit Grahack (Client Quit) 21.44.05 Quit arohtar (Read error: 104 (Connection reset by peer)) 21.44.09 Join BXCracer [0] (n=bxcracer@78-56-8-132.static.zebra.lt) 21.45.25 Quit HellDragon (Success) 21.45.37 # gevaerts: No big change in Rockbox install time with the latest USB change on my e200... :) 21.46.57 # Lear: unfortunately on e200 speed is mostly limited by the sd driver 21.47.00 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 21.47.15 Quit Grahack (Client Quit) 21.47.26 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 21.47.37 Join froggyman [0] (i=47ba0b80@gateway/web/ajax/mibbit.com/x-5d380f720f443207) 21.47.40 Part Seed 21.47.45 # gevaerts: Well, the previous change did make a big difference at least. 21.47.48 # Lear: actually, my latest commit may have made writes a bit slower on e200... 21.48.47 # do faster classes of SD card write faster in rockbox on the sansa or is it limited by the controller? 21.49.15 # My quick one-off test was a little faster, but by less than 1 percent. The install seem more limited by number of files than amount of data though. 21.49.19 Quit Grahack (Client Quit) 21.50.03 # gevaerts: ? 21.50.12 # saratoga, do the sansas use 1-bit or 4-bit mode? 21.50.28 # well, that's a FAT32 issue... afaik, specifialy FAT32 is a lot slower in writing several small files than few big ones... 21.50.41 # JdGordon|: I wanted to talk to someone else with a j, but he left... 21.50.56 # ah ok :) 21.51.02 # i'm not sure 21.55.42 Join Grahack [0] (n=chri@ip-120.net-89-2-70.rev.numericable.fr) 21.56.25 # Horscht: OF is noticeably faster though; half the time compared to Rockbox. 21.56.51 # ok.. 21.59.49 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 22.00.50 # Lear: try reading. My measurements say that we're a lot faster there :) 22.02.46 # The install themes stuff is broken - at least when using a proxy... It requests "http://rbutilqt.php?" .... 22.07.50 # high-rez: seems to work fine for me, (at least without proxy) :-) 22.08.01 # on which OS is this ? 22.08.18 # gevaerts: Well, I rarely do that... :) 22.08.50 # domonky: windows (which runs under virtual box on an os x host) 22.09.49 Join webguest83 [0] (n=ad2180dd@gateway/web/cgi-irc/labb.contactor.se/x-cd2a224d96ec276d) 22.10.39 # high-rez: then please open a bug report, with as much details as you can.. 22.10.49 Quit webguest83 (Client Quit) 22.10.58 # and why dont you use the mac version ? 22.11.44 # domonky: I needed to firmat the device with fat32 first... 22.12.23 # high-rez: thats true, but you dont need rbutil for that :-) 22.12.54 # high-rez: Once you have a winpod, you can use the Mac native tools 22.15.59 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 22.16.13 Join SirFunk__ [0] (n=Sir@208-15-25-145.netsync.net) 22.17.52 # domonky: I'll validate with the mac client now... 22.18.30 # indeed, there is something broken with theme installation using a proxy 22.18.55 # (linux, current svn) 22.19.11 # Everything worked on windows, except the themes. 22.19.49 Part Grahack 22.21.04 Join MuscleNerd [0] (i=eric@adsl-75-31-138-204.dsl.irvnca.sbcglobal.net) 22.24.34 # Ditto on OS X - the themes part is broken when using a proxy: 22.24.35 # 1242764655.501 45 172.30.2.6 TCP_MISS/503 2150 GET http://rbutilqt.php? - DIRECT/rbutilqt.php?target=ipodvideo& text/html 22.24.46 # (that's from squid) 22.27.30 Join Mathiasdm [0] (n=Mathias@vpnd032.ugent.be) 22.30.15 # bluebrother: about the manual - would you have an idea what's causing the insertion of blank lines that _sometimes_ happens after \opt or \nopt (something to check for at least)? 22.30.42 # gevaerts: if the plugins alone don't work, i've put up a full test build + the three plugin versions here: http://looking-glass.us/~chshrcat/rockbox/x5_scaler_benchmark_full.zip 22.31.04 Quit SirFunk_ (Read error: 110 (Connection timed out)) 22.34.09 Quit bubsy ("Mrrrrreow!") 22.34.23 # pixelma: well, I could imagine them causing double linefeeds, thus creating a new section in LaTeX. Have you tried adding trailing comment marks to each opt? 22.35.24 # i assume putsxy clips correctly/safely? could the hang for the scaler benchmark on gevaerts' x5 be due to writing past the end of the LCD framebuffer? 22.35.30 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.35.52 # it doesn't get near wrapping 22.36.31 # it freezes after printing the very first line, which fits. Anyway, I'm now trying your build 22.37.20 # Does anyone have the iPod nano 2G SST flash dump here? 22.38.43 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.5b5pre/20090517065612]") 22.39.03 # um 22.39.08 # linuxstb might 22.39.27 # bluebrother: \opt and \nopt sometimes don't, sometimes do. I experienced this before (or additional spaces, especially with \nopt) and then the % trick helped but yesterday just reordering the list helped. What puzzles me the most is that the behaviour seems to be so unforseeable, at least I couldn't find a pattern... 22.39.30 # Unhelpful: http://pastie.org/483270 22.39.30 # All right. 22.39.55 # gevaerts: thanks a ton! so, my build hates your build, or something? 22.40.07 # probably :) 22.40.23 # BTW, I just looked and the newer nano 5G firmware stuff have nearly the exact same format as the 8900 format, which we do have a vulnerability for. 22.40.25 # planetbeing: I do 22.40.38 # would you mind loading an oversized bitmap into sliding_puzzle? that should confirm that the coldfire asm in the core scaler for that build is correct :) 22.40.38 # I think, lemme check closer 22.40.41 # Not sure if Apple fixed the implementation on the nano though. 22.40.53 Join arohtar [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 22.41.08 # Also, I'm 99% sure that those things aren't signature checked. 22.41.31 Quit JdGordon| ("http://www.mibbit.com ajax IRC Client") 22.41.35 # http://daniel.haxx.se/rockbox/nano2g-bootloader.bin 22.41.38 # Since where the offset for the RSA signature should be is a number that points exactly past the end of the firmware file. =P 22.42.24 # * pixelma wonders whether daily built manuals for today are available now 22.42.37 # pixelma: no, we didn't trigger any new ones 22.42.48 # Huh, that thing has a Syscfg partition like on the iPhone. 22.43.20 # I see, will wait for tomorrow then. I guess it's not that important 22.43.24 Quit moredhel (Read error: 104 (Connection reset by peer)) 22.44.52 # Unhelpful: "Failed to load bitmap" 22.44.59 # Bagder: thanks 22.47.04 # gevaerts: weird. thanks for testing, i think i'll give that coldfire emu a go and see if i can slap together a bit of a test framework for the thing :) 22.47.31 # Unhelpful: I'll try to load the same images on another player 22.48.17 # are there any guides to syncing source files (.c)? 22.49.07 # i'd probably best build a complete install for lambacalculus as well, if he still wants to test that 22.50.26 # froggyman: There is no practical way to write a guide for it. 22.50.42 Quit bmbl ("Woah!") 22.50.43 # You need to read the file, figure out what's wrong by understanding the source, and update it. 22.50.48 # Unhelpful: they also fail on a new gigabeat f build 22.51.03 # * gevaerts guesses that he has a collection of "interesting" jpg files 22.51.13 # wait, did you say jpg? 22.51.24 # oh wait... 22.51.25 # oh dear, it appears that alex wallis took kugel's (bad) advice 22.51.26 # sliding_puzzle isn't using load_image yet :) 22.51.39 # Llorean: i mean like adding a new plugin, that doesnt have a patch yet 22.52.25 # AlexP: huh ? 22.52.42 # GodEater: dev mailing list 22.52.58 # Unhelpful: it's your fault for not having touched the scaler for weeks so I instinctively think about jpg whenever you say something 22.53.45 # yes, of course, that's it. ;) 22.53.49 # wow 22.53.56 # GodEater: yep 22.54.06 # whatever is in that email is causing firefox to crash when it displays it in gmail 22.54.17 # froggyman: It's still the same issue. You need to understand how it works, what has changed that prevents it from working, and fix it 22.55.46 # So will iPod accessories work with rockbox? E.g. my car has an ipod adapter - will it work? :) P.S. sweet software :D 22.56.02 # Some, yes 22.56.13 # That's just friggin neat. 22.56.14 # high-rez: You'd have to try it to be sure, there is limited support 22.56.17 # Unhelpful: it looks broken. Most of the screen keeps its background colour, and there's a white vertical line on the right of the image display area 22.56.29 # high-rez: It depends on what commands the accessort tries to use 22.56.36 # *accessory 22.56.55 # What is the "proper" place for me to put my music ? E.g. should I just create a new directory under the devices root called mp3 or is there a preferred location? 22.57.20 # high-rez: Anywhere you damn well want 22.57.23 # high-rez: Anywhere you want, (but not in the .rockbox directory) 22.57.24 # gevaerts: that sounds broken. at least we know the rework of the C math isn't a loss on coldfire. :) 22.57.34 # high-rez: Although the .rockbox directory isn't a good plan 22.57.40 # It's all about freedom eh ? :D 22.57.46 # yup :) 22.57.49 # Abso-bloody-lutely! 22.58.10 # You guys rock. Thanks for freeing my ipod from apples evil grip. :D 22.58.36 # no worries :) 23.04.44 Join Mathiasdm2 [0] (n=Mathias@vpnh086.ugent.be) 23.04.46 Quit tessarakt ("Client exiting") 23.04.54 Quit firedix ("Ex-Chat") 23.06.38 Quit {phoenix} (Read error: 104 (Connection reset by peer)) 23.07.26 # * Zagor is having second thoughts about the new web design :-( 23.08.29 # * bluebrother wonders what those second thoughs are 23.09.51 # as we have discussed before, I'd like to make the index page more user (non-dev) oriented. that means moving a lot of the content to the dev page, so the front page is cleaner. but the new design was not made for that, so it means I'd have to re-design parts of it. which I suck at... 23.10.24 # New commit by 03bluebrother (r20989): Clean up and improve themes install window debug messages. 23.11.06 # as in new design not made for a dev page? 23.11.22 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 23.11.58 # the new design was made to make room for basically everything the current frontpage has, and then some. 23.14.11 # so? Wouldn't it be sufficient to have a link to the dev page and use a different layout on the development pages? 23.14.22 # (i.e. something more developer-friendly)? 23.15.13 # yes. but it means I have to design a new front page. or at least refactor it substantially. 23.15.57 # ...when the whole point of the prolonged process with macku was to avoid that 23.16.12 # well, I've made up something a while back using some layout someone posted on the forums 23.16.27 # something I'd consider both user- and dev-friendly :) 23.16.32 Join _fml [0] (n=4fd3ccda@gateway/web/cgi-irc/labb.contactor.se/x-67d8ffeeb014022d) 23.16.41 # in case you want to give it a look: http://www.alice-dsl.net/dominik.riebeling/rockbox/ultimate-3-column-holy-grail-ems.htm 23.17.45 # I like the polished feel of the new design. and we have sort of reached consensus about it. 23.18.03 # * froggyman likes the design 23.18.15 # that's why I'm having a "doh" feeling about having to change it before we even start using it 23.18.58 # * bluebrother doesn't like the new design. It distracts too much 23.19.29 # the front page is cluttered, yes. that's my point. 23.20.09 Quit jfc (Remote closed the connection) 23.20.49 # how can it be clean when it's cluttered? 23.20.52 Join jfc [0] (n=john@dpc691978010.direcpc.com) 23.21.39 # I didn't say it is clean. I said I want to make it cleaner by moving dev stuff to a separate page. 23.21.53 Quit evilnick_7 ("http://www.mibbit.com ajax IRC Client") 23.21.59 # I think this full 3 columns layout is one of the main reasons it looks cluttered 23.22.04 # I don't think it is possible to make a non-cluttered combined dev+user page 23.22.35 # pixelma: I think it is a combination of that and the lack of a central focus point 23.22.57 Quit Mathiasdm (Read error: 110 (Connection timed out)) 23.23.40 # and my main grep currently is that the dropdown menu is not navigatable with tab (unless you turn off css) 23.24.09 # to be more precise - it isn't fully navigatable, you can reach the top level things 23.24.51 # yeah I imagine our blind users might be less than thrilled about that... 23.25.14 # * pixelma should have a look at it the cleaned up css, if it is available somewhere 23.25.31 # http://new.rockbox.org/media/css/rockbox.css 23.26.19 # thanks, will try to look at it tomorrow 23.26.28 # it's my cleanup plus gevaerts' size-dynamics changes 23.26.47 # not sure what will come out of it though... 23.27.24 # I seem to remember the buttons to jump to two lines if you made it narrow enough with my changes 23.27.51 # the download buttons? 23.28.24 # yes 23.28.35 # not anymore. I modified some % values. 23.28.50 # * bluebrother really hates websites that use that much of javascript 23.29.05 # that was actually on purpose :) 23.29.38 # gevaerts: haha, ok. since nothing else wraps I felt it strange that they would. 23.30.14 # It still looks good if they are aligned (which I did IIRC), and it gains you another 200 pixels or so in narrowness without breaking everything 23.30.49 # hmm no, I didn't change that. I changed values for the announcements/about/support columns. 23.32.28 *** Saving seen data "./dancer.seen" 23.33.09 # http://www.evonet.be/~gevaerts/rockbox-new/front.html 23.33.36 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-7331a9638f2d1315) 23.34.09 # that looks good. I seem to have missed a few things in my merge. 23.34.28 Quit BXCracer (Remote closed the connection) 23.34.31 # The two main breakages on that when narrowing are the manufacturer menu and the announcement section 23.35.36 # at least with firefox. I haven't tested anything else with it 23.36.04 # what breaks in the announcements? it looks fine to me? 23.36.24 # it vanishes behind the buttons 23.36.53 # ah 23.36.56 Join spyder_ [0] (n=spyder@lirhost.net) 23.37.09 Part spyder_ 23.38.03 # the mechanism it uses for making only one appear at a time assumes a fixed height 23.38.34 Join itcheg [0] (i=62db4c46@gateway/web/ajax/mibbit.com/x-ab8f2c642ede5ba4) 23.39.05 # did those buttons work in his version? 23.39.33 # yes, they work on new.rockbox.org too. only I mucked up the css so it doesn't look right. 23.39.59 # hm, I don't remember breaking them... 23.41.38 # Tab navigation doesn't seem to work at all with the new design, neither in firefox nor in IE8, Opera 9 or SRware Iron 23.41.51 # and why again is the font in the more blueish text part smaller than above (in the white)? 23.41.55 # gevaerts: I think you are missing a # on line 487? 23.42.22 # amiconn: it does - but the frame is surpressed and the links are just unnamed anchors # 23.42.36 # all of them, so you can't see where you at 23.42.44 # pixelma: because macku liked to set different sizes and spacing everywhere. that's one of the things I've been changing. 23.43.09 # the links will be normal. they are just # now because it's a mockup 23.43.26 # amiconn: except the dropdown menu 23.43.40 # Zagor: fixed 23.46.04 Quit renke ("leaving") 23.52.21 Quit matsl (Read error: 110 (Connection timed out)) 23.56.11 # New commit by 03alle (r20990): Add emdash, endash and ellipsis to 12-Nimbus, 13-Nimbus, 14-Nimbus and 19-Nimbus (FS#10213 with additions by me) 23.57.25 # the new page will also look weird in browser that don't support transparent png. I know those become rare and you can't make it work in every browser... looks *nice* in Opera 6...