--- Log for 16.10.107 Server: calvino.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 14 days and 18 hours ago 00.02.32 Quit Bagder_ (Read error: 110 (Connection timed out)) 00.02.38 # markun - You gotta love a greetings that means something like "did you eat well today?" ... :D 00.03.26 # WalterEgo: you are refering to a greeting common in beijing, right? 00.04.32 Quit midkay ("Leaving") 00.04.37 # Well, I know nothing of Mandarin but I've been told that's about what 'ni hao' meant.. With the 'ma?' being the more intimate version.. But I may be totally mistaken. :p 00.05.41 # WalterEgo: "ni chi le ma" is a way of greeting which literally means "have you eaten?" 00.05.56 # ni hao ma = "you good?" 00.06.40 Quit davina (Remote closed the connection) 00.06.41 # Oh well thanks for putting that straight. :) 00.07.07 # I just started learning the basics myself :) 00.07.12 # but now: sleep 00.07.28 # get as much as you can, sleep is invaluable. :p 00.07.46 Quit kkurbjun ("leaving") 00.09.14 Quit _Bagder_ (Read error: 110 (Connection timed out)) 00.11.24 Quit bertrik ("bye") 00.12.44 Quit bluebrother ("leaving") 00.14.22 # argh, just the moment I wanted to ask bluebrother a question 00.19.30 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 00.19.58 Part ddalton 00.20.40 Quit WalterEgo () 00.28.17 # * preglow tries to think of how to make a decent limiter without too much lookahed :/ 00.28.46 # ohh ohh what for you thinking about making a limiter? 00.28.54 # * Davide-NYC excited 00.30.37 # Davide-NYC: mainly to be able to listen to very silent stuff, like .spc files 00.31.03 # oh, not a live limiter for recording 00.31.05 # limiter is probably the wrong word, thinking more about automatic gain control 00.31.10 # dunno why i said limiter :/ 00.34.29 # It'd be nice to figure out some way to level out SPC files to match replaygained music 00.35.31 Quit ]RowaN[ (Read error: 110 (Connection timed out)) 00.35.38 # that'd require realtime replaygain processing... 00.35.44 # I gotta run. amiconn, I'm going to test while on the train. If I discover anything I'll let you know. 00.35.48 # not impossible in any way, btw, but don't know i care 00.35.53 Quit Toxicity999 (Read error: 104 (Connection reset by peer)) 00.35.56 # preglow: I'm not talking about replaygain specifically 00.36.04 Quit Davide-NYC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 00.36.24 # Just like, for formats like SPC, where most of the songs are the same amount of "quiet", the ability to add a pre-amp by-format or something. 00.36.34 # *shrug* 00.36.40 # i'm thinking agc so i can just enable it and stop caring 00.37.08 # tracks that have silent parts and louder parts will suffer, but i can't think of any better solutions 00.39.02 # Aaah 00.40.30 # i'm thinking a simple thing that smoothly adjusts the volume to the desired level, while quickly limiting the gain factors if clipping is detected on the output 00.40.45 # that last might be tricky since clipping doesn't happen until late in the dsp chain, though 00.41.22 # hmm, no, that should be doable 00.42.28 # * Llorean wonders if Foobar can write SPC metadata. 00.42.44 # i really don't want to use any lookahead to smoothly vary volume if clipping will happen since that'll need a largish buffer which will need runtime allocation 00.42.55 # the spc format DOES have a gain factor in the metadata, but i don't tihnk too much uses it 00.43.06 # and i don't want to require people to preprocess their files for use 00.43.21 # I was just thinking for my own use, there. 00.43.26 # preglow: you're saying SPC rippers don't set it? 00.43.35 # Your feature would be useful for other formats too, anyway. 00.45.45 # * amiconn would like to see a better resampler :/ 00.45.47 Quit obo ("bye") 00.46.09 # amiconn: me too, but i can't be bothered 00.46.12 # * jhMikeS would prefer to hear a better resampler :p 00.46.22 # hehe, of course 00.46.27 # much work, will need tons of optimizing and tuning 00.46.37 # and: i will almost never need it 00.46.58 # i'm keeping a steady eye on that speex resampler 00.46.59 # it looks pretty good 00.47.21 # jmspeex says it's pretty fast, but even that will be tons slower than the one we have now 00.48.11 Quit ender` (" There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S) 00.48.40 # hahah 00.48.42 # ender strikes again 00.49.56 # * amiconn considers this low level optimisation stuff a major part of the fun 00.51.40 # i consider it fun to a certain degree, but it really depends on what i'm doing 00.52.29 # * jhMikeS just wants to get the scheduler updates committed and worry about some size or simplicity issues later. Some size increase on all to add robustness and responsiveness to everything and keep the API somewhat unified. 00.53.35 # well, go on :> 00.53.40 # this stupid delta table make me too neurotic and there's probably better things to save bytes on anyway rather than compromizing integrity 00.54.50 # hehe. it's one of those you need to be on standby about if there are problems but it's been run on all the ipod variants so issues might be minor at best. 00.56.20 # ...at worst? eh, I think the point is understood. 00.56.35 # did kkurbjun check out the mini1g packed i2s stuff? 00.56.48 # he said he would later 00.57.35 # I'd like to reduce that stuff to #ifdef CPU_PP502x already :P 00.58.17 # me too 00.58.46 Join antgel_ [0] (n=antony@82-68-107-174.dsl.in-addr.zen.co.uk) 01.00.42 Join midkay [0] (n=midkay@rockbox/developer/midkay) 01.00.47 # did you get the swp replacement stuff going yet, btw? 01.01.15 # preglow: that's done and swp is used when it works otherwise sw corelock 01.01.43 # ipod color played dual-core SPC files just fine (and H10 of course) 01.01.44 Quit scorche|w ("CGI:IRC (EOF)") 01.02.04 Join kugel [0] (i=kugel@unaffiliated/kugel) 01.04.59 # sounds good 01.05.16 # how much slower would you expect the sw implementation to be? noticable at all? 01.07.03 # measureable in tests - not noticeable for playback. straight-up queue_sends run at about 75% the speed of the SWP version. ~46000 vs. ~61000 per second. 01.08.14 # those weren't gotten from a pure test loop either...there was checking that data echod back from COP was correct. 01.08.48 # I try a svn update and the answer is Skipped '.' , what is wrong ? 01.10.05 # i would expect it to be measurable in tests, yeah 01.10.19 # ignore what I said :) 01.10.27 # jhMikeS: so, what's left? just optimization? 01.10.52 Quit antgel (Connection timed out) 01.11.13 *** Saving seen data "./dancer.seen" 01.12.30 # preglow: Perhaps. The 45000 is faster than the initial implementation using SWP so not too bad there. 01.12.44 Join mark__ [0] (n=mark@c-67-186-189-56.hsd1.ct.comcast.net) 01.13.26 Quit kugel ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 01.14.07 # Buffering times are noticably shorter and even mpegplayer runs faster (on Gigabeat of all things) 01.14.09 # does anyone know what "svn: Delta source ended unexpectedly" means when I update my repository? 01.14.25 # jhMikeS: so no reason not to commit? 01.14.49 # i see no reason to keep the half-assed stuff in svn in any longer than we need to 01.14.50 Join kugel [0] (i=kugel@unaffiliated/kugel) 01.14.51 # not that I can think of other than my delta table neurosis:) 01.15.06 # is the size increase that huge? 01.15.38 # ~700 bytes on SH, ~1200 on CF, ~6000 on PP DC 01.15.41 # something like that 01.16.01 # well, the sh targets are the only ones where we should really care much 01.16.26 Quit mark__ (Remote closed the connection) 01.17.32 # all swcodec gets the fancy sync objects too. but I want certain things like thread waits and creating threads frozen to be unified or else things will get awkward with too many api variations. SH might even save bytes by using more advanced things. 01.19.38 Quit Arathis ("Bye, bye") 01.20.33 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.21.14 Join Toxicity999 [0] (n=bryan@cpe-76-179-68-20.maine.res.rr.com) 01.21.48 # * jhMikeS should probably just get a stiff drink first :p 01.22.54 # * preglow would like a stiff drink :/ 01.23.53 # * preglow goes to squeeze his ardbeg bottle 01.23.56 # one thing, if some other target has a problem with SWP (haven't found anything but PP5020), change one #define and it switches it. 01.24.07 # jhMikeS: got a patch hanging around? 01.24.15 # yeah, one sec 01.24.45 # my tree doesn't included the codec but I have one on my FTP with all that...hold 01.25.53 Quit spiorf (Remote closed the connection) 01.25.54 # ftp://jhmikes.cleansoap.org/dual-core-scheduler.patch.zip 01.26.03 # hope it applies still 01.26.19 # woops, use http:// 01.27.14 # i was starting to wonder if the patch really was one meg zipped... 01.27.27 # lol 01.29.58 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 01.30.26 # arghghg 01.30.34 # i need to reboot before i can use usb, apparently 01.30.45 # It applied ok? 01.31.16 # haven't tried, just tried ocpying the spcs 01.32.00 # i think i need to put this off until tomorrow anyway 01.32.02 # just saw the time :> 01.32.12 # gnight 01.32.24 # ok, night 01.36.20 Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) 01.36.30 Quit barrywardell (Remote closed the connection) 01.36.48 Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) 01.36.48 Part toffe82 01.36.57 Part barrywardell 01.38.01 Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) 01.38.52 Part [IDC]Dragon 01.41.39 Join ramon8 [0] (i=DontFuCk@adsl-71-146-167-52.dsl.pltn13.sbcglobal.net) 01.44.38 Join zajacattack [0] (i=4261723c@gateway/web/cgi-irc/labb.contactor.se/x-54681b44840a6edd) 01.50.46 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 01.52.36 Join kkurbjun [0] (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) 01.53.22 # wow 2.5 fps gained with amiconn's commit for the mpegplayer 01.56.26 Join Rob2222 [0] (n=Miranda@p54B14E96.dip.t-dialin.net) 01.58.01 # that's pretty good, what player? 02.02.58 # H300 02.03.51 Quit linuxstb ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 02.05.04 Join kkurbju1 [0] (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) 02.06.43 Quit hcs ("Leaving.") 02.07.11 Join Soap [0] (n=Soap@74-140-137-77.dhcp.insightbb.com) 02.11.43 Quit Thundercloud (Remote closed the connection) 02.12.52 # amiconn: I'm testing the H10 ADC on low battery. It's still ~0x14 different depending on PLL 02.15.34 Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) 02.17.29 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 02.18.22 Join Hartwell [0] (n=christia@24-107-45-230.dhcp.stls.mo.charter.com) 02.19.37 # any zune support in the future? 02.20.06 # the future is a very long time 02.20.10 # probably not 02.20.18 # dang 02.20.35 # JdGordon: hi 02.20.47 # hey 02.21.10 # I hope to have fixed at least some of the bugs you, pondlife and GodEater mentioned 02.21.17 # cool 02.21.23 # and pondlife set up a wiki page for testing 02.21.34 # http://www.rockbox.org/wiki/MetadataOnBufferTesting 02.21.35 # yeah i saw that.. 02.21.49 # I think i should setup git for it so i dont have to keep downloading 16mb archives :p 02.22.00 # indeed you should :) 02.22.05 # I can help if you want 02.22.06 # Hartwell: you can see the work on the zune port at http://forums.rockbox.org/index.php?topic=6848.60 02.22.48 # JdGordon: I'd be thankful if you could try reproducing your crash on shutdwon when buffering... I couldn't even whith the same version as yours 02.22.57 # but hopefully it's fixed 02.23.13 Quit kkurbjun (Connection timed out) 02.23.27 # doh! didnt see karl was here 02.23.37 # Nico_P: i only had it once.. but illgive it a go 02.24.08 # ok 02.24.11 # ok, how to i get git going? 02.24.20 # you have it installed ? 02.24.26 # * jhMikeS is going to take the DC plunge tonight to get the API disruption over with and let it sit for awhile 02.24.46 # dc plune? 02.24.51 # Dualcore 02.24.55 # Nico_P: i do now 02.25.00 Nick antgel_ is now known as antgel (n=antony@82-68-107-174.dsl.in-addr.zen.co.uk) 02.25.21 Quit Mouser_X (Read error: 110 (Connection timed out)) 02.25.32 # JdGordon: ok, so first you need do do "git clone git://repo.or.cz/Rockbox.git". This will clone the repo in a Rockbox subdir 02.25.42 # Nico_P: create_thread with have a flags param, no fallback param. struct event will become struct queue_event 02.26.13 Part zajacattack 02.27.59 Join toffe82 [0] (n=chatzill@adsl-71-132-81-224.dsl.sntc01.pacbell.net) 02.28.24 # indexing objects.... slowly... 02.28.38 # JdGordon: it's quite a big repo 02.29.08 # JdGordon: after that you can do the rest of the steps of http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl#The_public_Rockbox_git_repositor 02.29.09 # ok, done 02.29.10 # thanks zajacattack 02.29.20 # but what's important is to checkout the mob branch 02.29.58 # git checkout -b my-mob origin/mob 02.30.51 # ok then? 02.31.13 # after checking out you have the mob code and you're on the branch 02.31.28 # nothing left to do fo now but compile and test ;) 02.31.49 # * JdGordon is good at tha 02.31.52 # that* 02.32.52 Quit Hartwell (Remote closed the connection) 02.33.15 # ok 02.33.24 # to update: "git pull origin +mob:my-mob" (while on the my-mob branch), then "git remote update" if it wasn't a fest-forward update (it tells you when it is one... if it's not it means I've rebased) 02.34.20 # one very cool thing is git bisect 02.34.46 # going up one in he playlist viewer doesn crash it now, but playback stops 02.35.59 # and its not crashing on shutdown while buffering 02.36.20 # ill leave this build on my sansa and let you know if anything comes up 02.36.37 # ok, cool 02.37.15 # playback doesn't stop for me in the sim when going up in the playlist... I did notice it on my player last time I tried though... forgot about it 02.37.44 # pressing skip back like a madman works fine :) 02.37.50 # JdGordon: I'll be off soon. if you find a bug and have a bit of time, git bisect helps you find the commit that caused the bug 02.37.53 # no gap between tracks 02.37.53 Quit bb (Nick collision from services.) 02.37.58 Join bb_ [0] (n=bb@unaffiliated/bb) 02.38.14 # I hope that soon doing that won't even need to trigger a rebuffer 02.38.41 # it iwll if you go before the bufered tracks.. 02.38.46 # it already works quite well except when you let it just play the codec thread ends up starving 02.39.05 # sure but currently it always rebuffers 02.39.30 # I want to avoid discarding tracks so that skipping back to them is instantaneous 02.39.39 # ah ok 02.39.50 # so this version sticks the tracks id3 info on the buffer? 02.40.12 # let's see what changes soon with that stuff 02.40.21 # yes, except that it copies current and next track info into static buffers 02.50.27 Join Calcipher [0] (n=Calciphe@ool-18bab657.dyn.optonline.net) 02.51.00 # bed time 02.51.04 # cya 02.51.26 # * pixelma agrees 02.51.59 # * Nico_P hopes to see lots of bugreports when he wakes up :p 02.52.15 # really? 02.52.22 # mine? 02.52.22 # you mean you want to see none, so its working 02.52.43 # I want to see reports about bugs that were there but were fixed 02.52.49 # I'm curious, has anyone here had success with the rockbox install for the Sansa E200R series using the e200rpatcher.exe under windows XP 02.52.58 # but that's asking a bit too much at this point :) 02.53.09 Part pixelma 02.53.33 # Calcipher: whats the problem? 02.53.43 Quit Nico_P (Remote closed the connection) 02.54.08 # I tried the instructions, attempted to go into manufacture mode, was prompted for drivers 02.54.21 # and the drivers were used from the links provided 02.54.36 # and they didnt work? 02.54.37 Quit kkurbju1 (Read error: 110 (Connection timed out)) 02.54.41 # then I launched the e200r tool 02.54.52 # and it gave me a fail error 02.55.02 # which gave you a fail error? 02.55.34 # now my players wheel light has been lit since 02.55.57 # the e200rpatcher 02.56.26 # which gave you a fail error? 02.56.54 # the patcher said it failed to write 02.57.00 # ok 02.57.12 # unplug the sansa and power it off (hold power untill it turns off) 02.57.24 # ok 02.57.28 # start e200rpatcher and then plug it in in manufac mode 02.57.49 # apparently some are finiky about being in m mode for too long before something happens 02.58.01 # ah 02.58.26 # ok let me first boot into the regular firmware 02.58.33 # just to be safe 02.58.47 # good 02.58.57 # ...wait 02.59.01 # not so good 02.59.36 # false alarm, that was just the hold message 03.00.00 # I just bought this off my friend 03.00.28 # he went for an Ipod touch, I wanted this since I have trouble with my vision 03.02.22 # Ok 03.02.39 # so its in manufacture mode 03.02.58 # where in device manager is it listed? 03.03.01 # so press ener in e200rpatcher 03.03.26 # dunno, under usb devices maybe 03.03.38 # wow 03.03.59 # that was the smoothest tech support I've ever encountered 03.04.12 # It worked 03.04.54 # So I'll continue with the regular intructions. This method will allow dual booting correct? 03.05.09 # yes 03.05.27 # glad I didn't have to pull out my linux cds, I use a screen magnifier in windows 03.05.47 # Ubuntu has accesability features, but sometimes its iffy 03.06.24 # beautiful, thank you both for being patient, I bet you get this alot hmm 03.07.02 # the frameworks method on this page sounds like a good way to build rbutilqt on the mac in the future: http://doc.trolltech.com/4.3/deployment-mac.html 03.07.10 # I just tried it and it works 03.07.54 # As I was reading through the forums I noticed mention of sdhc support, and something about the implementation causing issues on some of the boot loaders 03.08.45 # Since there is so much info, what is the actuall status of the sdhc support, or even the usb support, and also is the sdhc support only when your in rockbox ? 03.09.20 # sdhc works 03.09.25 # only in rockbox 03.09.37 # and atm you have to use the OF for usb 03.09.53 # wow, you guys are definitely talented 03.09.56 # the issues with bootloaders and sdhc are fixed 03.10.33 # I was on the phone with sandisk tech support before buying this 03.11.01 # asking about any firmware updates they may make for the e200s 03.11.15 *** Saving seen data "./dancer.seen" 03.11.15 # the guy sounded scared to answer 03.12.03 Join kkurbju1 [0] (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) 03.12.12 # Ok I have another question before I proceed 03.12.19 Nick kkurbju1 is now known as kkurbjun (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) 03.12.45 # now just to let you know, I can't see very small print 03.13.31 # and after the e200r patcher successfully applied the patch 03.13.58 Join amanda99 [0] (n=aspiniou@ool-43575a8f.dyn.optonline.net) 03.14.05 # I have not unplugged the player, and I can tell there are a couple of lines of text 03.14.11 # on the screen 03.14.15 Nick amanda99 is now known as Aspiniou (n=aspiniou@ool-43575a8f.dyn.optonline.net) 03.14.33 # :D:D:D:D:D:D 03.14.37 # akuku 03.14.40 # :D 03.14.46 # cipa cipa chuj 03.14.48 # ;d;d;d 03.14.49 # djkijwidjaiw'djw'iekd 03.14.49 # qw 03.14.50 DBUG Enqueued KICK Aspiniou 03.14.50 # edqekopq3k3qe3 03.14.50 # 32 03.14.51 *** Alert Mode level 1 03.14.51 # 564 03.14.51 *** Alert Mode level 2 03.14.51 # 654 03.14.53 # 45 03.14.55 # rgf 03.14.57 # dsg 03.14.57 # Aspiniou: you can stop now 03.14.59 # dsg 03.15.01 # d 03.15.03 # gfds 03.15.05 # g 03.15.07 Mode "#rockbox +o scorche " by ChanServ (ChanServ@services.) 03.15.07 # ds 03.15.08 # Calcipher: can you count how many lines there are? 03.15.09 # gdsfgd 03.15.11 # sfg 03.15.13 # dsgd 03.15.15 # sgsdg 03.15.34 Part Aspiniou 03.15.45 # :) 03.15.48 Join aliask [0] (n=chatzill@c58-109-97-210.eburwd4.vic.optusnet.com.au) 03.15.53 # he's back! 03.15.54 # ban him 03.16.02 # haha 03.16.04 Join psycho_maniac [0] (i=psycho_m@ppp025.hk.centurytel.net) 03.16.52 # Calcipher: it didnt definatly work... can you read the text on the screen? or at least how many lines of textt there are? 03.17.53 # Actually I used a magnifier, and it is the rockbox installer confirmation 03.18.04 # and says to continue with step 2 03.18.12 # ok then it worked 03.18.19 # unlock hold and press a button 03.18.24 # then continue with the steps on the wiki 03.19.53 # ok 03.20.10 Mode "#rockbox -o scorche " by ChanServ (ChanServ@services.) 03.20.23 # i really need to set some aliases so i cna do that quicker... 03.22.38 # isnt there an autoop thing so you can kick/ban without actually being oped? 03.23.06 # there is, but autoop is discouraged on freenode, and i agree with that 03.23.37 # Hmm, so after the e200r tool I still need to run the sansapatcher? 03.23.47 # the opping isnt the slow part...it is manually typing "/mode #rockbox +b %nick!*@*" 03.24.24 # Calcipher: follow the instructions... iirc you have to put a e200 firmware on first, then sansapatcher 03.24.52 *** Alert Mode OFF 03.25.12 # Ah ok, If I lose rhapsody support I wouldn't care 03.25.49 # Just checking since I had to take the R detour on the instructions 03.25.55 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 03.25.55 # * jhMikeS guesses alot of fingers may point to r15134 for a bit :p 03.26.16 Join webguest37 [0] (i=46403811@gateway/web/cgi-irc/labb.contactor.se/x-41df1ef3c9df9bdc) 03.26.53 # Yay! The record feature on the c200 has been implemented! Thankyou! 03.27.27 # jhMikeS: cool, so does the cop do anything yet? 03.27.51 # What do you mean? 03.27.56 # we'll just keep things low for now. it should be able to be used like anything else now though. 03.28.49 Quit webguest37 (Client Quit) 03.29.06 # hrm...it says i dont have permissions to view that task 03.29.52 Join TypeleveN [0] (n=Typeleve@67.63.89.141) 03.30.56 # * jhMikeS wonders what the score will be here 03.31.02 # I tried the rbutil install method 03.31.47 # I'm guessing the player isn't in MSC mode, so autodetect didn't work, let me see if thats the case 03.32.13 # did you put the vanialla pp5022.mi4 on it yet? 03.32.42 # no, so far I have only ran the R patcher 03.32.51 # and just tried rbutil 03.32.54 # READ THE WIKI INSTRUCTIONS 03.33.05 Quit TypeleveN (Client Quit) 03.33.16 # nice work jhMikeS 03.33.50 # lostlogic: thanks...I hope the build server didn't stick on me :P 03.34.01 # hehe, I'm reading the diff now 03.34.02 Join TypeleveN [0] (n=Typeleve@67.63.89.141) 03.34.09 # na, a big commit like that makes sense to take a while longer 03.34.25 # the builds sent to my server have already completed 03.35.17 # not bad on the red considering 03.35.32 # your lucky amiconn is alseep :D 03.36.03 # heheh...do some more commits so he doesn't see that...please :) 03.36.04 # ouch on the delta 03.36.35 # I'll get to trimming things where possible of couse. 03.37.08 # oh, red is only sim.. not so bad 03.37.10 # The archos deltas are higher than what I measured 03.37.49 # my player builds only went up about 750 bytes ... hmmm 03.38.38 # well it boots :-P 03.38.41 # and plays 03.38.53 Join meoblast001 [0] (n=meo@dynamic-acs-24-239-93-241.zoominternet.net) 03.38.57 # hello 03.39.28 # does anyone know a good place where i can find rockbox themes for Sansa c200 03.39.37 # lostlogic: normally a good thing indeed :) 03.39.42 # i know its newly supported but i know some site has to have a few 03.40.04 # i could only find 1 on the whole internet 03.40.08 # specially since my build is a little bit special (no tagcache, no dircache, codec on COP and codec has no yields) 03.41.50 # so, jhMikeS - what are the implications of your commit? 03.42.06 # hopefully not a mob with torches 03.42.20 # i guess not... ok ill bbl 03.43.16 # I've been reading a lot of your conversations prior to this commit - and I'll admit, as a layman, I'm not 100% sure what differences a user should expect to see... 03.43.27 # users shouldn't see any yet :-P 03.43.30 # You can use COP threads just like threads anywhere else using queues, mutexes, and whatever safely...and a general speedup for all things. The playback engine and other things can use it freely. 03.43.58 # can threads swap between cores? 03.44.02 # yes 03.44.08 # so you've only opened the door? 03.44.40 # at the moment yes. to include a playback rewrite to enable it now would be going way too far. 03.45.09 # could somebody please explain the new big comment in svn? something about mulitcore support. 03.45.15 # ok, cool, that's what I was ASSuming looking at the diffs, but I wasn't sure. 03.45.48 # psycho_maniac: the kernel is multiprocessor safe in a general way now 03.46.01 Quit jhulst ("Konversation terminated!") 03.46.25 # does this effect how rockbox runs on the 502x players? 03.46.52 Join kkurbju1 [0] (n=kkurbjun@c-67-166-49-171.hsd1.co.comcast.net) 03.47.05 # it will. I just laid the groundwork to be able to use the other cores which will make things run much better. 03.47.43 # and this is for the 80gig ipods? i connected my ipod before i could check the info on it. 03.48.06 Quit kugel (Read error: 110 (Connection timed out)) 03.48.13 # psycho_maniac: his changes impact all multicore targets, which includes all currently supported ipods 03.48.29 # psycho_maniac: all PP502x devices. PP5002 is on the TODO list. 03.48.46 Quit kkurbjun (Read error: 110 (Connection timed out)) 03.49.06 # so that means NOT my player? 03.49.19 # 80gig is a PP502x target 03.49.53 # aye, "no newline at end of file" ?? how lame :P 03.50.03 # what is a pp5002 ? 03.50.39 # an older portal player chip found in iPod 1g/2g/3g 03.51.04 # oh ok i see. 03.51.06 Join webguest34 [0] (i=4cb431de@gateway/web/cgi-irc/labb.contactor.se/x-daa27e5c49b69068) 03.51.14 # jhMikeS: do we have no multicore support at all on 5002? 03.52.30 # nope, it's built as single core only 03.52.33 # Will Rockboy be optimized to take advantage of the multicore support? 03.52.56 # if someone decides to do it, sure 03.53.25 # * jhMikeS wonders why his compilter didn't complain about the newline 03.54.33 # * jhMikeS should probably update the gcc for x86 03.54.34 # so far on my H10 20gb with the new build, the only major difference I've noticed is Brickmania having a smooth framerate while music is also playing 03.54.36 # wow man, this is a huge body of work you've done. 03.54.50 # before, Brickmania was jerky while music was playing 03.55.17 # IIRC nothing is actually running on core2 at this point in the official builds. 03.55.33 # aye...been working on it a few months. using Peterson's algorthm on PP5020 chips where SWP is broken finally got it going. 03.55.45 Quit qweru ("moo") 03.56.30 # well thank you fo your work :) 03.57.00 # you're welcome. you might notice some benifits right off, yes. 03.57.24 # jhMikeS: unless I'm hallucinating, I got a 1% speedup on ogg decoding 224% vs 223% realtime 03.57.33 # theoretically not noticeable to a human though 03.58.23 # switch_thread is smaller. lags that would happen because the scheduler didn't detect the thread wakeup should be gone. 03.58.25 # im back 03.59.16 # does anyone know where Sansa c200 themes can be found? i only found 1 on the whole net 03.59.24 # timeout list removal is very lazy and timeouts are only checked when the earliest thread is due to wake up 03.59.25 # meoblast001: there really just might nto be any posted online yet 03.59.31 # oh 03.59.37 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 03.59.48 # lostlogic: any good sites you know of that generally have a lot? 04.00.00 # meoblast001: rockbox WPSs and themes are pretty easy to make, I suggest making your own that suits your needs 04.00.08 # meoblast001: if it's not on our wiki WPSs page then no. 04.00.33 # now that thread.c is cozy 2595 lines, I'm sure I'll get to hear later endless lectures on complexity :) 04.00.47 # lostlogic: whats the difference between a theme and a wps? 04.00.50 # jhMikeS: my statement huge body of work was code for a lecture :-P 04.01.17 # meoblast001: a theme changes font and color and other system attributes, a wps is just a layout for the while playing screen 04.01.18 # I _try_ to do as little as I can while meeting my goals. 04.02.01 # lostlogic: is there a way to get the layout (like the battery) to appear everywhere on the system... i dont like the default 04.02.07 # But really I'd rather 1% of the code support simplifying the other 99% 04.02.08 # no 04.02.27 # lostlogic: was that no to me? 04.02.32 # jhMikeS: yeah, better to have the complexity in the kernel where few have to work on it 04.02.36 # meoblast001: yes 04.02.51 # jhMikeS: it's definitely harder to read thread.c now :( 04.02.59 # i have a question. now i have 3 folders in my networking thing. this happend after my last svn up, i now have filesystem, and homes, what is this? 04.03.01 # lostlogic: should i request that feature? 04.03.13 # I was hoping the comments helped somewhat? no? Maybe it should be split? 04.04.13 # meoblast001: doesn't make sense to me to have a customizeable status bar outside of the WPS, but request anything you want :-P 04.04.25 # k 04.04.40 # jhMikeS: yeah, it's understandable, I just always have some difficulty mentally ifdefing ;) 04.04.43 # Question - in the database uner "A to Z" - why isn't there a subfolder for "Track"? - It would be much easier to search for songs by title if they were sorted in folders marked A to Z 04.05.19 # lostlogic: Well, it would be nice to see a few things. Time, date, perhaps battery, outside the WPS screen (I thought there was a theme that did that though?) 04.05.36 # Mouser_X: the status bar shows those things... ... 04.05.43 # Ah, well then. 04.05.49 # I thought meoblast001's question was about customizing the status bar 04.05.54 # I guess I either missed them, or my theme removed them. 04.06.05 # Sorry. 04.06.32 # jhMikeS: I'm definitely stil lreading though, specially since I'm such a bystander these days ;) 04.06.39 # lostlogic: my question was about being able to customize features like the battery icon outside of the now playing window 04.06.47 # if thats what your wondering 04.06.52 # meoblast001: ok, cool. 04.07.10 # lostlogic: so thats not currently possible? 04.07.20 # meoblast001: correct, afaik. 04.07.46 # afaik??? 04.07.52 # as far as i know 04.07.57 # ok 04.09.36 # lostlogic: should give some reading enjoyment for awhile :) 04.10.50 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.11.48 # FUCK 04.11.53 # lostlogic: are you sure because i dont want to sound stupid 04.12.00 # someone was just casing my house with me home! 04.12.12 # jhMikeS: did you find out that SWP was broken by test? 04.12.14 # meoblast001: You could alway try, and see what happens. 04.12.57 # JdGordon: My brother's place was broken into while he was home (it's small place. I don't think they were too bright. He shot at them..) 04.13.00 # lostlogic: difficult to test directly actually but it's removal or addition would make or break it for H10 04.13.10 # Alright, rockbox is running, very nice 04.13.14 Quit webguest34 ("CGI:IRC (Ping timeout)") 04.13.36 # jhMikeS: gotcha 04.14.29 # Thanks again, I had originally thought that after the R bootloader patch process I had to continue with the original install, thats where my confusion came from, but I looked it over and saw I had to follow a different set of instructions, sorry for the trouble. 04.14.42 # any dual core test plugin would simply lock up instantly using it 04.15.26 # on pp5022/24 it's quite fine and preferred since it's faster and smaller 04.15.41 # * Soap can tell a diff between 224 and 223 04.17.32 # soap: ie it feels faster with jhMikeS's commit? 04.17.55 # it's 1 faster, isn it? 04.18.07 # /sarcasm 04.18.12 # *rolleyes* 04.18.14 # ricer 04.18.25 # you don't have to get mean 04.18.37 # it goes to 11 now :P 04.18.38 # ahahaha :) 04.19.49 # now that you have this offloaded, a week of rest and squashing, and you should be ready to receive my Nano ;) 04.20.04 # I'll never ask for status updates, I promise. 04.20.25 # ah...why not. gotta be something that can be done. I just have no clue what atm. 04.20.48 # Soap: what's he need your nano for? 04.21.31 # it's the type that freezes when warm 04.21.36 # lostlogic - my Nano is one of the minority which suffers freezing and data corruption with the recent clock reworking Amiconn did based upon his RE of the Apple OF. 04.21.45 Join shnee [0] (n=CurtyD13@cpe-65-24-210-155.insight.res.rr.com) 04.21.55 # ahh, sweet! 04.22.05 # just keep some lN2 in your pocket with it. 04.22.07 # and yes, the firmware misbehavior can be mitigated by cooling. 04.22.22 Quit troxor ("leaving") 04.22.39 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.22.44 # the strap-on peltier kills the battery-life. 04.22.49 Join miepchen^schlaf [0] (n=hihi@p54BF6D22.dip.t-dialin.net) 04.23.01 # problematic indeed. 04.23.13 # Heh. 04.26.53 # * jhMikeS looks at the diffs more closely since the colored ones always show the debugging crud accidentally left laying around 04.28.47 # ugh, left a whole bunch of NOCACHEBSS stuff that's really not nescessary. :\ 04.29.50 # lostlogic: if themes only do colors and stuff... how is mine able to do linear colors.... thats generally not a color related thing 04.30.05 # although it is colors 04.30.18 # I don't think lostlogic said "only" 04.31.31 # so can it change the generic black battery icon? 04.31.40 # themes can address all the eyecandy of rockbox - from icons, to backdrops, to pretty gradient selector bars, to colour-by-file-extension, to WPS screens, to colours in general. 04.31.52 # WPSs are the While Playing Screens. 04.32.12 # so is there anyway to change the bar at the top of my screen with the battery and the time and the volume 04.32.53 # Do you mean the default status bar at the top of the screen? IIRC the status bar itself is NOT current themeable, except by a tracker-hosted patch. 04.33.06 # s/current/currently/ 04.33.24 # whats a tracker hosted patch? 04.33.41 # a patch hosted in the tracker :) 04.34.04 # do you know where one might be that allows me to do this? 04.34.24 # as the name says...int he tracker 04.35.17 # ??? 04.35.22 # What I ment by "a tracker hosted patch" was a patch, that while unofficial - and currently deemed unworthy of inclusion into "mainstream" Rockbox, nonetheless is hosted in the official patch tracker (flyspray) and not floating around in the ether on somerandombody's website. 04.36.49 # jhMikeS: Ipod Mini G1 packed I2S works :) 04.37.35 # I really am amazed at how well all these things work together, the rockbox dev community is definitely good at what it does 04.37.57 # I changed the define to CPU_PP502x, do you want me to commit it? 04.38.11 # My suggestion would be to search flyspray with the keywords "status bar", and expand out from there if you do not find what you are looking for. That being said - I am not aware of one of the "Unsupported Builds" from the forum grouping of the same name which are using this patch...leading me to believe that it is hopelessly out-of-date. tdtooke has been doing a very impressive job of... 04.38.11 # Right now I'm using the rbutil on my E280r with speech enabled, and some new larger fonts 04.38.12 # ...keeping all the rejected eyecandy patches current, and if he hasn't done so with this one - it either still works, or it might never work again. Calling this one a macro, scorche? 04.38.21 # hell yes 04.39.58 # thank you all yet again, you made my damn good mp3 player, into a serious little feature filled bastard 04.40.44 # kkurbjun: with LE16_2? You can pull the selection in i2s-pp.c entirely then. So yeah. 04.41.59 # kkurbjun: dump the 2nd fifo format (halfword as well). Not needed now either. 04.42.02 Quit Lambuntu (Remote closed the connection) 04.42.20 # In pcm-pp.c 04.42.35 # eh, I'll let you simplify it 04.42.49 # ok, np. 5 min to that. 04.43.28 Quit TypeleveN (Read error: 110 (Connection timed out)) 04.43.53 # * jhMikeS will start trying to use DMA there 04.45.06 Join Lambuntu [0] (n=bleh@wbr-2310.student.iastate.edu) 04.54.00 Quit animeloe ("Leaving") 04.55.37 Join animeloe [0] (n=animeloe@unaffiliated/animeloe) 04.58.40 Quit aliask ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007073113]") 05.00.26 Join webguest42 [0] (i=424b3cb2@gateway/web/cgi-irc/labb.contactor.se/x-b8d7dc3f084d51b9) 05.00.30 # . 05.01.05 # hey where can i download the actual tool for putting the themes and fonts and games on my ipod at? 05.01.52 # Try the Wiki. RockboxUtilityqt? 05.01.56 # (Is that right?) 05.03.09 # ya, thanks ive been trying to find it it got earased from my pc and i forgot where to download it from. 05.04.25 # hey i keep aplying the base wad file to doom and it loads but it always freezes as soon as i get to the games play 05.05.10 # Sorry, I've only used DOOM like, twice. I can't help 05.05.37 # ok 05.06.21 # is there anyone else in here who can help me 05.08.38 # have you also searched the forum? 05.10.16 # ya 05.10.23 # it wasnt very helpful 05.10.29 # it wasnt cleer 05.11.13 # i just want to know what files i need to get in order to run doom on my ipod video 05.11.18 *** Saving seen data "./dancer.seen" 05.11.27 # the wiki tells you what files you need 05.11.45 # i followed the wiki and doom worked no problem. 05.13.01 # ya ive downloaded it but do i just extract it to the ipod and the file will find its way or where do i put it 05.13.33 # ? 05.13.35 # the wiki tells you. 05.13.58 # it specifically tells you where to put each file 05.14.02 # heh 05.14.12 Quit Mouser_X (Read error: 104 (Connection reset by peer)) 05.15.38 Join bb [0] (n=bb@unaffiliated/bb) 05.16.23 # webguest42, in fact, i don't know what you're extracting, as the wiki tells you to put two files into the right place, neither of which is zipped. 05.17.33 Join eigma [0] (n=cat@216.48.162.210) 05.18.44 # ok i got the three files it said to put on there and added them, is that it i dont understand what the addons are? 05.18.53 # for doom 05.19.02 # does the standard game work? 05.19.34 # addons go where the wiki says: .rockbox/doom/addons 05.20.51 Join webguest54 [0] (i=dce9d1f6@gateway/web/cgi-irc/labb.contactor.se/x-2607d0bd69641759) 05.21.16 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 05.21.38 # do i need prboom? 05.22.32 Quit webguest54 (Client Quit) 05.22.37 Join webguest54 [0] (i=dce9d1f6@gateway/web/cgi-irc/labb.contactor.se/x-6d8fe2c45544ada5) 05.24.09 # webguest42, no, you don't need prboom. all you need is specified in the wiki, which, at minimum, is 2 files. 05.25.26 # ever since i installed rockbox on my ipod it seems to consume more battery life than with the normal apple firmware why is that? 05.26.39 # because, as is discussed several times in the forums, it's not known how to put some of the hardware to sleep and other power-saving modes. 05.26.47 # No work has yet been done to optimise power consumption on other models. 05.27.11 # psycho_maniac: that's a lie. 05.27.23 # well i got that from the wiki 05.27.37 # Where in the wiki does it say *no* power optimization has been done? 05.27.42 Quit bb_ (Read error: 110 (Connection timed out)) 05.27.48 # And, more importantly, when is this dated? 05.27.52 # i should of changed the words aroudn a bit. this is only for the ipod. 05.28.04 # My question still stands 05.28.08 # in the ipodport wiki page. 05.28.12 # can someone pls tell me if there are any other alternatives to rockbox? I want to play flac files on my 80g video ipod. I gather that rockbox will not run on it from discussions i have read on the forum.... 05.28.46 # psycho_maniac: It's certainly not on that page 05.28.56 # alright then 05.29.02 # psycho_maniac: And the IpodStatus page says "more work could be done" which very clearly requires that some work has been done. 05.29.10 # I'd very much like to know which page you got it from so that I can correct it. 05.29.22 # ok doom still doesnt work it loads to the first level then it just freezes as soon as the level starts the controls dont work. i have installed all three files that the forum told to install and it still doesnt work. is there something that im missing? 05.29.38 # http://www.rockbox.org/twiki/bin/view/Main/IpodStatus#Known_issues_4G_models_and_highe 05.29.46 # webguest54, which 80gb ipod? if it's a 5.5g ipod, rockbox will run on it. if it's the ipod classic, you're out of luck, as no 3rd party software runs on the device. 05.29.53 # webguest54: Rockbox runs on All HD based iPods except the "iPod Classic" recently released 05.30.33 # its the 5.5 released in late 2006 05.30.57 # then rockbox runs on it 05.30.59 # psycho_maniac: That's actually in reference to a very specific set of fixes made to 1st through 3rd generation, whoever wrote it managed to phrase it very poorly 05.31.05 # i am not sure about the latest classic but I bought mine in HongKong 4 months ago 05.31.07 # thx 05.31.17 Quit eigma () 05.31.40 # then why is it under 4th gen and higher? 05.31.57 # Because that fix can't be made to 4th gen and higher yet 05.32.26 Quit meoblast001 ("Leaving") 05.32.46 # hi krazykit.....wht is a 5.5g ipod (excuse my poor understanding) 05.32.59 # what is a 5.5g ipod? 05.33.14 # its the 80 gig video released in late 200p 05.33.20 # 2006* 05.33.32 # oh ok...then i may be in luck 05.34.22 # Excuse me folks, I have a quick question for anyone using the sansa e200 series players and rockbox 05.34.35 # ask it 05.35.17 # Oh and also on the windows platform, I just wanted to know what the most compatible non annoying program for transfering and maintaining music on the player is 05.35.42 # I just got one today and got it rockboxed, I never even installed the cds 05.35.51 # any file manager you choose to use 05.36.42 # I was going to use Winamp 5, but I noticed it reads the player as USB mass storage L: and K: 05.36.44 # Calcipher, i do it by hand, personally, but i hear good things about mediamonkey's sync options. winamp and foobar probably have plugins for this too 05.37.12 # hmm 05.37.31 # Oh and winamp was just dropping folders on the root 05.37.38 # so thats not very organized 05.37.59 Quit webguest42 ("CGI:IRC (EOF)") 05.38.45 # correct me if im wrong, but you can play FLAC files in rockbox? 05.38.53 # yes, you can 05.39.16 # there's a codec page on the wiki for reference 05.39.35 # yes i looked at that. 05.39.35 # Now I'm wondering if setting the player on MTP mode will make it more compatible with winamp 5, but will this cause problems with rockbox? 05.39.44 # webguest54: you can play FLAC on rockbox. so what is the problem? 05.40.05 # Calcipher, shouldn't cause problems, as long as the files get on there. 05.40.10 # rockbox is fuckin amazing, so many formats supported 05.40.47 # Yes. 05.40.57 # ah ok, then I'll give it a try, sounds like I may have to switch back to msc mode if I want to add stuff to rockbox 05.41.07 # It's why I have a portable player now (the formats I use are rather wonky to most players.) 05.41.53 # Calcipher, just note that in MTP mode, only Sansa-supported files can be transported, so not vorbis, flac, etc 05.42.09 # dont use mtp 05.42.39 # So what I have been doing since installing rockbox is turning the player off then connecting to the USB 05.43.04 # psycho_maniac....I was asking if rockbox runs on my ipod....now i found out that my ipod is a 5th generation 80gig ipod with video that was made late 2006...so, I guess it runs rockbox...and I am ready to study the manual etc 05.43.12 # then it loads the original firmware and quickly goes into docked mode with the usb transfer image displayed 05.43.44 # so to get into the normal firmware I need to hold down the left button when booting correct? 05.43.58 # yes 05.44.04 Quit Lambuntu (Remote closed the connection) 05.44.08 # Oh ok, so scratch fucking everything up in MTP mode haha, forget I asked 05.44.30 # I think I'll listen to JdGordon 05.44.35 # another question for you seasoned guys: 05.45.02 # once i start using rockbox is it goodbye to Itunes? or can i have both running on my ipod? thx 05.45.11 Join Lambuntu [0] (n=bleh@wbr-2310.student.iastate.edu) 05.45.25 # You can, but Rockbox won't use iTunes database at all. 05.45.36 # Nor will it be able to play the DRM stuff. 05.45.53 # what drm stuff 05.45.56 # hehe 05.45.56 # webguest54, if you choose to sync with itunes, you MUST use the rockbox database to play music 05.46.25 # DogBoy, the itunes music store purchases, except the more expensive drm-free ones 05.46.26 # Oh yes. I forgot. Itunes *mangles* the filenames. 05.46.44 # thx krazykit 05.46.51 # krazykit, I was kidding, I refuse to buy that stuff 05.51.38 # thx to all for your answers...really appreciate it 05.52.56 # Can I ask what I might be avoiding by not using MTP mode, I noticed a large amount of forum posts all over mentioning the player working with winamp and WMP10 and 11 easier 05.54.09 # you cant transfer ogg and flac among others to use in rockbox 05.55.05 # I don't use Winamp to transfer files. I use Windows Explorer, and simply dump the files where I want them. 05.56.03 # You could do the same (though, depending on how you have your music setup, there might be something that's more useful to you. Mine is a mess, so it's probably better organized on my Gigabeat, than it is on the PC). 05.57.54 # I see, well I was just looking to use my normal music player to do all my music tasks, I don't have much music in other formats other than mp3 so I don't mind not having that ability in MTP mode 05.58.44 # I get the feeling theres more to avoiding MTP mode than just the music file types limitation, when dealing with a rockbox set up 05.59.25 # its the limitation of files that can be transfered 06.00.04 Join kubiix [0] (n=Miranda@mos-81-27-201-28.karneval.cz) 06.00.26 # Man, so each time I reboot this thing its going to rebuild the db?? 06.00.38 # even if no changes were made to the music? 06.01.17 # yep 06.01.33 # we know how to stop it for 3 OF verions 06.01.37 # versions. 06.01.45 # I'm brand new to the player, so I don't know if theres a sleep or power save mode, instead of powering off to avoid the loading time 06.01.47 # but the later ones changed their system so it doesnt work anymore 06.01.58 # no sleep 06.02.01 # just poweroff 06.02.47 # damn bastards, and I bet the other additions to the newer OFs are worth having? 06.03.03 # * JdGordon wouldnt know... 06.03.12 # i only use the OF for usb 06.03.32 # actually that doesn't happen in rockbox 06.03.45 # so your right its no so bad if its only for USB transfers 06.04.03 # Hey why do you suggest I stay away from MTP mode? 06.04.13 # because mtp sucks 06.04.28 # Seems like it would make using the player with certain programs smoother 06.04.42 # then use it 06.04.57 # does the SD card still show up when your in MSC mode? 06.05.11 # yes 06.05.21 # so then I can add random non supported formats to the sd card probably 06.06.22 # thanks for all the help jd 06.06.40 Quit ramon8 (Read error: 110 (Connection timed out)) 06.07.56 # another question: will I be able to keep and update my itunes podcasts on the rockbox? 06.09.38 # podcasts are a good reason _not_ to use itunes 06.10.03 # also, if there were 2-3 major reasons to use rockbox on the ipod, what would they be....(i just want to make sure i am doing the right thing) 06.10.19 # why dogboy? 06.11.08 # from what I understand (not using itunes) the feed urls are difficult to sus out of itunes 06.11.15 # beautiful, now syncing with winamp is running perfectly 06.11.22 # obfuscation 06.11.23 # DogBoy: Most modern podcasts are just a standard RSS feed 06.11.27 # webguest54: see the WhyRockbox page and choose your own "major reaons" 06.11.38 # exactly Llorean 06.11.44 # but try finding them in itunes 06.13.01 # Ah, plenty of Deep purple and Maiden...making me happy I bought this thing, and that Rockbox rocks so much! 06.15.21 # thx scorche...i will 06.16.38 # also, is there a specific mp3 player that rockbox runs better than on anything else? 06.17.48 # depends on what features you want, really 06.20.37 # Rockbox runs like a dream on the Gigabeat... 06.20.46 # (I have a Gigabeat F40) 06.21.59 # krazykit...i was used to minidisk players....i want crystal clear music...i may be crazy but this is what i like and i have not seen an mp3 player able to do this....flac files sound great on my pc...if i could do the same on the ipod that i have that would be nice....but then i am open to suggestions...gigabeat oh yes 06.22.32 # webguest54, http://www.rockbox.org/twiki/bin/view/Main/BuyersGuide 06.22.37 # The iPod is not the player you want then. I've heard from many people that its audio hardware is terrible. 06.23.09 # well, that also depends on your headphones... 06.23.36 # However, I've heard many people say that the Gigabeat sounds really good, and very clear (I'm not one to ask. I don't pay attention to those things. I'm just saying what I've heard.) 06.23.58 # scorche: I have $15 earbuds. 06.24.02 # :P 06.24.14 # i've been happy with the sound quality on higher-end phones 06.24.35 # Mouser_X: well, i was referring to the issue of sub 32 ohm headphones 06.24.40 # I was saying that a while back but then... 06.25.01 # what issue is that scorche 06.25.06 # I don't know about it 06.25.26 # Soap will tell you all about it ;) 06.25.52 Quit webguest54 ("CGI:IRC") 06.25.59 Join webguest54 [0] (i=dce9d1f6@gateway/web/cgi-irc/labb.contactor.se/x-2f3d2d9ec1739bc9) 06.26.05 # ok thanks 06.26.33 # DogBoy: there are threads in the forum about it if you are interested enough to search 06.26.51 # seems like we've been here before 06.27.01 Quit lazka_ (Remote closed the connection) 06.28.20 # I... I couldn't help it, I had to put Dio on there... 06.28.32 # King Diamond next! 06.28.40 # Calcipher, please keep it on topic 06.28.50 # ah, sorry 06.28.55 # don't forget the slim whitman 06.50.40 Quit kkurbju1 (Read error: 110 (Connection timed out)) 06.57.36 Quit Calcipher ("—I-n-v-i-s-i-o-n— 2.0 Build 3515 with A Pack Fix By www.ircmadeasy.com") 07.00.54 Join EnterUse1Name [0] (n=dave@ip-218.55.99.216.dsl-cust.ca.inter.net) 07.04.08 Part toffe82 07.05.15 Quit Toxicity999 ("Leaving") 07.08.11 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 07.11.20 *** Saving seen data "./dancer.seen" 07.12.24 Quit EnterUserName (Read error: 110 (Connection timed out)) 07.22.31 Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- IRC with a difference") 07.25.14 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.29.52 Quit tchan (SendQ exceeded) 07.31.22 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 07.34.43 Join advcomp2019_ [0] (n=advcomp2@66.172.231.192) 07.35.11 Quit advcomp2019 (Nick collision from services.) 07.35.17 Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@66.172.231.192) 07.36.15 Quit webguest54 ("CGI:IRC") 07.38.26 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.41.58 Quit jhulst (Read error: 113 (No route to host)) 07.46.05 Quit parafin|away (Read error: 101 (Network is unreachable)) 07.54.01 Quit Mouser_X (Read error: 110 (Connection timed out)) 08.12.10 Quit Seed ("cu, Andre") 08.12.41 Join Rob222241 [0] (n=Miranda@p54B14410.dip.t-dialin.net) 08.19.35 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 08.19.42 Join Seed [0] (i=ben@bzq-84-108-237-178.cablep.bezeqint.net) 08.23.17 # Quite a big red delta :( 08.23.42 # jhMikeS: The delta for SH1 is larger than what you got because it's not only binary size change 08.24.01 # It's (binary_size_delta + ram_usage_delta) / 2 08.24.13 # Hover over the cell to see the details 08.24.35 # amiconn: I figured that out after a closer look. I do think it's a good deal more than it should be as well. 08.24.51 # jhMikeS: One reason for the increase is probably the extra argument to create_thread() (the flags) 08.25.12 # Now it has 5 arguments on SH instead of 4, meaning it is now a stackparm function... 08.25.43 # What are those flags used for, btw? I've only ever seen zero when looking at the diffs... 08.25.47 # hmmm....I was under the impression that SH used 8 regs for regparms 08.25.54 # No, it uses 4 08.25.58 # r4...r7 08.26.02 # hmmm... 08.26.15 # It has 8 scratch regs though, r0..r7 08.27.06 # a) to extend functionality without adding more parameters. b) right now there's a flag that keeps a new thread from actually running until you thaw it. This functionality is rather small itself. 08.28.36 # Why introduce functionality that isn't used (unless you have plans to use it *soon*)? 08.28.39 # I had thought about just using a struct that can be statically initialized and just a pointer passed to create_thread. Probably would save size and be less awkward. 08.28.57 # I do have plans to use it. playback.c is already using it. 08.29.11 Join ramon8 [0] (i=DontFuCk@adsl-71-146-144-50.dsl.pltn13.sbcglobal.net) 08.29.54 # Eh, one single thread... 08.30.07 # Does that make sense to have on hwcodec then? 08.30.38 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.30.55 # How much thread variation and behavioral difference should be tolerated? 08.32.09 # For plugin devs they'll constantly have to watch their back for it and code around it here and there. A wait to condense the function call nicely would save more than the 68 bytes that takes. 08.33.07 Join Thundercloud [0] (n=thunderc@resnet12.nat.lancs.ac.uk) 08.33.34 # I don't think having a struct instead of several arguments will save code size. Then the struct needs to be filled with values instead of the stack 08.35.47 # Hmm, if the struct is pre-filled (static const) it might. Maybe that should be tested... 08.36.19 # * amiconn started a compile cycle 08.36.19 Join henfon [0] (n=ircap8@201.196.84.234) 08.36.20 # exactly. I saved a ton doing that with recording and most (all) threads are create with static parms. 08.36.47 Part henfon 08.37.29 # audio_set_recording_options was nearly always used with global_settings values only. so one function to fill in the struct and just modify the ones that are different. worked nicely. 08.37.31 Quit BigBambi (Read error: 110 (Connection timed out)) 08.37.42 # Didn't you say you moved thread structs from iram to dram? 08.38.07 # not the thread structs. switch_thread itself. 08.38.15 # ah 08.39.00 # dual core _must_ have them in IRAM of couse. switch_thread should be there as well because cache fills could throw off the time-critical cop/cpu mailbox code 08.40.31 # I realized this little thing later anyway. 08.40.45 # Well, on single core it doesn't make that much sense to have it in iram. Thread switching is used constantly, but the time spent in there is way less (or at least should be) than in the actual application code 08.41.19 # So the precious iram should be saved and used for tight, time critical loop stuff 08.41.49 # far, far, less, yes though data is more commonly accessed than any particular function 08.42.22 # On coldfire it makes sense to keep the thread structs in iram as it has no data cache, but on SH I would probably even put the structs in dram 08.42.46 # * amiconn will need some spare iram soon(ish) on SH 08.43.26 # I did arrange them to be both packed and aligned by sorting member size so no gaps should exist within them. 08.44.48 Join chris_mt [0] (n=chatzill@host-69-145-134-192.grf-mt.client.bresnan.net) 08.45.18 # I just needed this big stuff taken care of...work out some details later and refine it. Somehow it's easier to see what to do after getting a break. 08.46.07 # hehe.. commit and abandon == a break ? 08.46.27 # I doubt that's what he meant 08.46.34 # * JdGordon was joking btw 08.47.06 # haha...when's the last time you saw me do that on any big project? 08.47.30 Join parafin|away [0] (i=parafin@paraf.in) 08.47.47 # :D 08.48.38 # JdGordon: if you were referring to switching cores as "the thread x switches cores all by itself problem". No it's not that. A thread can hop deliberately. 08.50.11 # Now we need dual core on PP5002... 08.51.49 # jhMikeS: yeah, i did mean automatically switching, but thats probably not so good anyway 08.51.52 # And some code that takes advantage of it for playback. :-P 08.52.13 # is there any limitation to what threads can go on the cop? 08.52.20 # multi-core doom! 08.52.20 # Isn't that what this commit was mainly about? 08.52.30 # I mean, is there any reason to not put scolling, backlight onto the cop to free up the cpu a bit? 08.53.11 Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) 08.53.33 # JdGordon: no techincal limit 08.53.48 # I'd rather keep most threads on cpu, and only put a few selected, computing intensive ones on the cop 08.53.57 # Just extreme caution 08.54.56 Quit midkay ("Leaving") 08.55.49 # JdGordon: if you kill a cop thread from the CPU in Debug OS Stacks, the main thread hops to the COP to kill the thread and hops back. that's just a minor use though. 08.56.20 # that sounds reasonable 08.57.28 # Hmm, codec thread is on cpu still... 08.57.50 Quit shnee ("Konversation terminated!") 08.57.59 # and moving it across causes playback to crash 08.58.27 Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 08.59.24 # backlight is fine on the cop 08.59.28 # scrolling doesnt work though 08.59.34 # * JdGordon assumed that thread was self contained? 08.59.54 # Scrolling has a tick task that sends messages 09.00.25 # And accessing the framebuffer from both cores is a bad idea 09.00.45 # yeah, i tihnk ive seen some artifacts because of that presumably 09.01.19 # playback need some real thread sync before you can plop codec on COP 09.03.07 # lcd drivers can be secured. really mutexes are fast now and should really be used. spinlock should become a dual core true spinlock which can be used to sync interrupts and threads on both cores at the same time. 09.04.01 # lcd would have to flush cache all the time... 09.04.15 # And we don't want the framebuffer to be uncached for sure 09.07.21 # well, it can be accessed as both. even switched by changing the base on the fly if some plugin wants to use it that way. 09.07.49 # I cannot imagine why we would want that 09.08.01 # Uncached access is slower by factors 09.08.45 # mpegplayer didn't seem to suffer for using the uncached address 09.08.58 # For code I measued a factor of around 7 iirc 09.09.20 # (running a tight loop from sdram with cache disabled vs. cache enabled) 09.09.24 # I think MrH's experiments revealed code is far more imporant to cache than data. 09.09.44 # by uncached do you mean writing directly to lcd_framebuffer? 09.10.03 # No, writing to its uncached alias address 09.10.04 # lcd_framebuffer + 0x10000000 vs. just lcd_framebuffer 09.10.56 # so which one is cached? i used lcd_framebuffer for a patch to the ines port but it would be great to speed it up further 09.11.24 *** Saving seen data "./dancer.seen" 09.12.45 # lcd_framebuffer is cached 09.12.59 # I see. 09.13.01 # thanks. 09.13.51 # I haven't looked at the driver code - does this then get moved to the real frame buffer in batches? 09.14.54 # in whatever rectagle is specified by lcd_update_rect. it's not batched. 09.14.55 # Coldfire buffers so incredibly fast compared to PP... 09.15.13 # H10 is horribly slow at buffering 09.15.45 # jhMikeS: small h10 became a lot better due to the fast lcd driver, especially when using a wps with peakmeters 09.16.19 # I think the peakmeter fps needs to be adjusted to the target's lcd. Slow lcd updates needs less fps in peakmeter, or it will take forever 09.16.27 # big H10 took forever since I've had the thing. 09.17.00 # Buffering on 2nd gen with default wps takes almost one minute with default wps, but around 20s with iCatcher 09.17.07 # we must be leaving some clock running too slowly 09.17.17 # On small H10 I now get 20-ish seconds even with peakmeter 09.18.19 # But on both H180 and H340, buffering takes around 6 seconds for mp3... 09.18.46 # sounds reasonable. about 12-ish on big H10 though 09.18.58 # I think we will get close to that when we can put codec on the cop 09.19.16 # I think what we see here is just the difference in mp3 decoder efficiency 09.19.45 Join petur [0] (n=petur@rockbox/developer/petur) 09.19.48 # I think SWCODEC peakmeters should just wait on the queue and not sleep() 09.19.51 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.20.12 # Then they would suck even more power... 09.20.34 # Or maybe I misunderstand what you mean... ? 09.20.36 # hardly, they'd spend 1/20 sec doing nothing. I could test this. 09.20.59 # Hmm, but sleep() achieves the same, no? 09.21.32 # Just wait on the queue for the entire peakmeter frame duration instead of polling it and doing sleep() 09.21.42 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 09.22.00 Part ddalton 09.24.55 # SWCODEC just needs to be highperf always false 09.26.08 # Both the highperf business and polling every single tick (as a compromise) is only needed on hwcodec 09.26.19 # then you'll still make 40x more trips through the threading code every second 09.26.39 # or no it's 1/20 second 09.26.58 # so 10x more 09.27.01 # 5* 09.27.35 # the get_action + the sleep call each loop 09.27.39 Quit bertrik ("bye") 09.28.48 # I'll try that anyway - just a switched #if and a changed condition... 09.29.55 # It's in fact not 10x or 5x more 09.30.06 # The big loop is just executed twice 09.30.39 # ...because next_big_refresh is HZ/10 and next_refresh is HZ/PEAK_METER_FPS which is HZ/20 09.31.11 # button = get_action(CONTEXT_RECSCREEN, HZ/PEAK_METER_FPS); 09.34.22 # * jhMikeS wonders why /player and /recorder still exist :) 09.35.11 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 09.45.05 Quit chris_mt ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 09.45.24 Join CaptainSquid [0] (n=Miranda@proxy17.netz.sbs.de) 09.47.40 Quit Mouser_X (Read error: 110 (Connection timed out)) 09.51.12 Join qweru [0] (n=kvirc@bb-87-80-66-156.ukonline.co.uk) 09.52.26 Join ivoreus [0] (n=Miranda@impex.8ka.mipt.ru) 09.53.12 Quit ivoreus (Client Quit) 09.54.32 Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) 09.55.27 Quit qweru (Client Quit) 09.59.34 Quit atsea-34 (Read error: 104 (Connection reset by peer)) 09.59.35 # eek 09.59.44 # Got an undefined instruction on 2nd gen :( 10.00.35 # Now a prefetch abort... 10.01.25 # ...a stkov... 10.02.18 # stkov where? 10.02.23 # youve alsmot got the whole set! 10.02.48 # jhMikeS: It's strange - it just showed an address (iram area) instead of the thread name... 10.03.13 # hmmm...idle stack. those should be big enough 10.03.13 # The undefined instruction was in iram as well 10.03.44 # The prefetch abort was at 0xc0000002 - no code should ever jump there 10.04.13 # of course not 10.04.49 # what was running to get that one? 10.04.53 # *those 10.05.29 # I just booted. It happened at the end of the dircache scan 10.06.10 # Another crash ("just" freeze this time) 10.06.17 # hmmm...could be one of those hidden overflows? 10.06.34 # or is swp broken on that model too? 10.06.38 # Strange - it worked at the first boot with latest svn, but now it crashes every time :( 10.06.45 Quit rasher (Read error: 145 (Connection timed out)) 10.07.11 # after running dircache? 10.07.52 # As long as dircache is scanning, I can scroll around the browser. As soon as dircache is done, it freezes or crashes 10.09.37 # Now I forced a foreground scan by removing nvram bin 10.09.53 # AFter the foreground scan I got an undefined instruction :( 10.10.47 # ...ad another one 10.10.48 # Does not scaling affect anything? 10.10.51 # It's unusable :( 10.11.11 # which processor is that? 10.11.15 # 5002 10.12.28 # I'll double check things for a stupid mistake. 10.12.34 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 10.13.53 Join spiorf [0] (n=spiorf@host115-227-dynamic.8-87-r.retail.telecomitalia.it) 10.14.18 # what if dircache is shut down? 10.16.15 # Then it crashes right away on boot 10.16.24 # meh, usb docs are soo vague. 10.16.30 # The addresses are different each time 10.16.31 Join obo [0] (n=obo@rockbox/developer/obo) 10.16.50 # hmpf 10.16.57 # would you say this means in/out can or can not have the same endpoint number? "A stream pipe to a device is bound to a single device endpoint number in the appropriate direction (i.e., corresponding to an IN or OUT token as defined by the protocol layer). The device endpoint number for the opposite direction can be used for some other stream pipe to the device." 10.17.24 # I'd say it can 10.17.42 # Sounds like a "can" to me, because it sounds like it's saying you can choose not to, suggesting you don't have to choose not to. 10.17.43 # Afaik, the IN endpoints are numbered independently of the OUT endpoints 10.17.54 Join bluebrother [0] (i=5SXq1MdZ@rockbox/staff/bluebrother) 10.18.10 # but I've never seen them with the same number... 10.18.42 # (windows & windows CE) 10.19.18 # Llorean: yeah that's what I'm reading too. and in another place it says endpoints are uniquely identified by their number _and_ their direction. 10.19.37 # but as you say, no devices seem to do that. so I'd better go with the reality instead of over-interpreting the map... 10.19.55 # * amiconn recompiles the core with sw corelock... 10.20.17 # Yeah, de facto tends to trump de jure. 10.20.50 # jhMikeS: Hmm, could a broken swp influence PP5002 at all? 10.20.58 # We don't run dual core yet... 10.21.36 # * amiconn found that his change for 5002 in config.h was useless... 10.21.44 # amiconn: it could...plus I made an error 10.22.20 # Didn't you want to get that firewire card? ;) 10.23.37 # yeah, it's about time. I think I can fix this now though. 10.25.20 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 10.29.16 # Llorean: Do you think it'd be a good idea to lock one of the two "Nano not working" threads? They may have started out as different symptoms (audio glitch vs crash?) but that seems to have been lost now. 10.31.14 # wow 10.31.45 # Disabling highperf in the swcodec peakmeter cuts buffering time in half on G5 with peakmeters enabled 10.31.51 Quit spiorf (Remote closed the connection) 10.31.55 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 10.32.14 Part ddalton 10.32.33 Join GregoryHouse [0] (n=bof@host7-100-dynamic.183-80-r.retail.telecomitalia.it) 10.33.53 # amiconn: See if that does it? 10.33.55 # pondlife: I was thinking the same thing this morning 10.34.25 # Well, go for it.. I'd do it myself but I've not been involved in the discussion so it seemed a bit heavy-handed. 10.34.42 # no - I think I'll let Llorean do it - he's been *more* involved 10.34.55 # he can decide which one can go 10.35.13 # jhMikeS:? 10.35.37 # just made a commit. SVN up and see if that clears it. no swp unless specified. 10.38.19 # Just 18 seconds buffering time on G5 with default wps now 10.42.03 Join random_desu_is_s [0] (n=chatzill@inet-out.dsl-nat.sura.ru) 10.42.19 # bluebrother: Don't suppose you could provide an updated RbUtilQt for Windows that I could test? 10.42.38 # pondlife: sure, gimme some minutes 10.42.40 Quit random_desu_is_s (Client Quit) 10.42.42 # No rush 10.44.38 Join random_desu_is_s [0] (n=chatzill@inet-out.dsl-nat.sura.ru) 10.44.49 Quit random_desu_is_s (Client Quit) 10.45.10 # jhMikeS: Looks like it's working now... 10.45.48 # However, in one try I managed to start playback and it did only output silence. WPS was moving etc. Stopping and restarting playback fixed it 10.46.22 # guess that answers that for swp on PP5002 10.46.48 # * jhMikeS goes to the FW card store 10.48.32 # they're rather niched 10.49.39 # jhMikeS: It's broken? 10.51.30 Quit Soap (Read error: 110 (Connection timed out)) 10.51.31 # amiconn: if it's working now, it sounds like it. That's the only change there. 10.51.39 # aha 10.52.17 # Okay, so PP5004 fixed the cache bug of the 5002. 5020 added new stuff. 5022 fixed swp 10.52.55 # I wonder what bugs there were in PP5000 (which presumably existed) then... 10.52.57 Quit CaptainSquid ("Miranda IM!") 10.53.10 # * jhMikeS wonders if ARM told them they're not going to do any more half-a$$ed core hardening work for PP 10.53.40 Join lee-qid [0] (n=liqid@p549658D7.dip.t-dialin.net) 10.54.23 # there was a PP5000? it's probably just a bug all over. 10.57.20 # * amiconn likes it when a bug fix means a green delta... 10.58.08 Join aliask [0] (n=chatzill@c58-109-97-210.eburwd4.vic.optusnet.com.au) 10.59.23 # * jhMikeS actually prefers those as well 11.01.01 # pondlife: at the usual location ... http://www.stud.uni-karlsruhe.de/~uhcn/rockbox/rbutil/rbutilqt.zip 11.04.40 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 11.05.03 # bluebrother: Thanks 11.05.25 Quit pondlife ("disconnected has pondlife") 11.11.27 *** Saving seen data "./dancer.seen" 11.13.09 # wow 11.13.27 # another speedup? 11.13.30 # * amiconn just found that the jpeg viewer now has dithering 11.14.15 # markun: No, not yet, but there will be a couple soon, hopefully 11.14.21 # * jhMikeS put that in there oh so long ago :p 11.15.15 # jhMikeS: It's probably because of that menu which always annoys me so that I just click 'Quit' immediately without reading further 11.15.41 # jhMikeS: did I read something in the logs about buffering being faster on the Gigabeat? Or is that not committed? 11.15.50 # We really should make the exit button actually exit plugins, and put the menu on a separate button, preferably the usual menu button 11.16.11 # markun: it's just faster because of the scheduler. 11.16.46 Join ddalton_ [0] (n=Daniel@203-214-50-20.dyn.iinet.net.au) 11.16.47 # not hugely but there's a small improvement 11.16.59 # I keep forgetting but how do I log ddalton off? 11.17.24 # ddalton_: /ns ghost ddalton password 11.17.58 Nick ddalton_ is now known as ddalton (n=Daniel@203-214-50-20.dyn.iinet.net.au) 11.18.13 # ok thanks 11.19.10 # amiconn: r12987 added the gray and dither stuff to jpeg.c 11.21.15 Quit idnar (Nick collision from services.) 11.21.17 Join idnar_ [0] (i=mithrand@unaffiliated/idnar) 11.22.47 # The test_fps results for 1st gen and 2nd gen are interesting. First one would expect exactly the same results, as they have the same CPU and LCD controller 11.23.32 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 11.23.35 # But the 1st gen is ~0.5% slower. These are the 0.5% sacrificed to the 'Wheel Power God' on 1st gen... 11.24.17 # Wheel Power God? 11.24.36 # The mechanical wheel on 1st gen draws quite some power when enabled (12 mA) 11.25.00 # It is switchable (via gpio). 11.25.35 # So we just enable it for a short time every tick in order to check whether it moved, and only keep it enabled when it moved 11.26.01 # When hold is enabled, the whell is kept disabled of course 11.26.24 # no int is available to activate it when needed? 11.26.40 # How would the wheel fire an interrupt when it's disabled? 11.27.28 # The button+wheel driver uses interrupts for the actual readout 11.27.34 Quit bluebrother ("reboot") 11.27.38 # wouldn't nescessarily come from the wheel controller itself 11.28.01 # jhMikeS: was the scheduler improvement committed? 11.28.33 # markun: you missed that enormous things on the from page? :) 11.28.49 # The wheel has no controller. 11.29.23 # guess it disappeared from there already 11.29.39 # jhMikeS: the multicore commit? 11.30.23 # It's probably just a LED, 2 photo transistors and a sectored wheel 11.30.24 # yeah 11.30.42 # ...working like a opto-mechanical mouse 11.31.02 # 12mA sounds like a LED draw 11.31.13 # yup 11.31.35 # The wheel needs a minimum time to get stable readout after enabling it 11.31.51 # jhMikeS: didn't miss that one :) 11.31.57 # 11.32.09 # My tests got stable readings after 20..30 us. I settled for 50 us to be on the safe side 11.32.19 # That's the 0.5% - 50 us per tick 11.32.25 # so I think I can either just include the shift and shift all values in powermgmt-h10.c correspondingly 11.32.26 # you'd think some kind of hall-effect sensor would have been used 11.32.31 # or forget about the shift altogether 11.33.34 # amiconn: does OF just poll it? 11.33.49 # I didn't check, but I doubt it 11.34.08 # For getting the actual movement, polling would always be too slow 11.34.22 # We use interrupts for this 11.34.34 # the h10 scrollpad sounds similar, but we know when to enable it because a gpio bit gets set 11.35.18 # Polling misses steps when the wheel is moved fast, and then it loses direction 11.35.43 # We had that before I switched to using interrupts... which required to stabilize clock scaling (sic) 11.37.34 # barrywardell: That shift is a strange thing... it means that zero isn't true zero 11.37.54 Join rasher [0] (n=rasher@rockbox/developer/rasher) 11.38.01 # e200 had that problem before interrupts. It could have even moved the list in the wrong direction if turned too quickly. 11.38.06 # I wonder what state delivers the correct zero value - pll disabled or pll enabled 11.38.22 # jhMikeS: yup, exactly that thing... 11.38.26 # pll disabled gives steadier readings 11.38.58 # I don't mean stability, but what situation gives a zero reading when the input voltage is zero 11.40.40 # yeah, I know. but if it's more unstable with pll disabled, then maybe it gives a wrong zero reading too 11.40.58 # hmm 11.41.08 # I think we should apply it if it is a true offset 11.42.22 # it's also possilbe that I just couldn't see the change since the range of voltages is quite small compared to the total 11.42.29 # and the readings are still jumpy 11.43.06 Join CaptainSquid [0] (n=Miranda@proxy17.netz.sbs.de) 11.43.13 # amiconn: I think the reversal is called "aliasing". Nyquist sampling applies there as well. 11.43.35 # ah, yes 11.43.36 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 11.44.01 # any objections to changing a couple of the defines in pp5020.h, like so: http://pastebin.ca/738428 11.44.51 # Looks ok to me 11.45.50 Join Redbreva|work [0] (i=c1713011@gateway/web/cgi-irc/labb.contactor.se/x-f1450905736107c0) 11.46.25 Join jba [0] (n=jba@c211-30-160-138.blktn3.nsw.optusnet.com.au) 11.48.40 Quit jba (Client Quit) 11.48.43 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 11.48.55 # yeah, always update that as meanings become clearer 11.50.41 # Anyone object If we raised the max playlist size from 20000 to 30000? No impact on existing users, is there? 11.50.50 Quit Redbreva|work ("CGI:IRC (Ping timeout)") 11.51.29 # Who would use such insanely long playlists?? 11.51.34 # how bout 32768 so it's a nice round number? 11.51.39 # * GodEater_ was thinking that 11.51.59 # amiconn: shufflers 11.52.00 # There is no impact on existing users as the actual limit, and hence the reserved ram, is a user setting 11.52.25 # amiconn: I'm insane right now, then :) 11.52.30 # rasher: How? Putting the whole contents of the player multiple times into the same list? 11.52.43 # No, only once 11.52.48 # Database > Tracks 11.53.09 # I can't fit more that ~3000 tracks on a 20GB target 11.53.36 # 1) A 80gb target exists 2) not all songs are multiple megabytes 11.53.40 # (with usable quality, that is) 11.54.00 # Lots of short 128k MP3s here 11.54.04 # Okay, maybe with sid or so... but then you'll run into dircache trouble ;) 11.54.13 # Oh? 11.54.28 # Do you use dircache? 11.54.29 # 21591 tracks here, what's the dircache limit? 11.54.37 # The dircache limit is 6MB 11.55.00 # yeah, I want my HVSC in one playlist 11.55.04 # How many files fit there depends on average dirname/filename length 11.55.25 # Check dircache status in the debug menu to see how much is taken 11.55.34 # So dircache quietly fails? 11.55.42 # use 8.3 filenames internally? 11.55.51 # It fails, but then tries to scan every boot 11.56.20 # jhMikeS: No, that wouldn't work reliably 11.56.21 # oh were talking dircache, heh. not database. 11.56.36 Join miepchen^schlaf [0] (n=hihi@p54BF6D22.dip.t-dialin.net) 11.56.57 # * jhMikeS is a bit exausted 11.57.02 # Hmm, indeed, it's not working here ion sim... but no sign of a scan taking place either 11.57.05 # on sim 11.57.54 # I don't know what dircache is supposed to do in the sim 11.58.07 # Same as the target, I'd have thought 11.58.16 # does dircache hold paths in a tree by component? 11.58.37 # jhMikeS: I think it does, but I'm not sure. It's Slasheri's work 11.59.17 # I have ~6800 files on my H180, and dircache takes ~430KB 11.59.57 # I wonder about other data structures that might effectively compress it nearly no overhead 12.00.12 # *with nearly 12.02.45 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.05.08 # amiconn: I seem to recall you saying you didn't use dircache. 12.09.24 Join spiorf [0] (n=spiorf@host115-227-dynamic.8-87-r.retail.telecomitalia.it) 12.09.32 Quit spiorf (Read error: 104 (Connection reset by peer)) 12.10.27 Join spiorf [0] (n=spiorf@host115-227-dynamic.8-87-r.retail.telecomitalia.it) 12.17.12 # * preglow does the big commit dance 12.17.56 # jhMikeS: Meanwhile I do, but only on targets with >= 32MB ram and slow spinup 12.18.20 # (the latter means that I don't use it on ipod mini, as its microdrive needs only 500ms spinup time) 12.18.52 # preglow: you missed the party 12.18.59 # jhMikeS: any fun? 12.19.13 # Dircache doesn't help much when using directory talk clips though 12.19.42 # amiconn: I definitely wouldn't bother using it on sansa 12.20.13 # preglow: lots of fun...except I didn't score so well :( 12.20.54 # YES! 12.20.55 # the only reason to enable dircache on sansa is for the auto update for database 12.20.58 # \o/ 12.21.01 # amiconn: You still get crashes using dircache +.talk? 12.21.03 # Zagor: success? 12.21.12 # bulk transfer is alive 12.21.13 # Zagor: gogogogogogo! 12.21.13 # pondlife: Didn't get any recently... 12.21.29 # Zagor: What was the problem? 12.21.29 # w00000t 12.21.33 # wooohoooo 12.21.33 # turns out the controller was picky about when the registers were inited. I couldn't do them all in the beginning. 12.21.44 # amiconn: Just wondered, I never had that problem. 12.21.47 # Ah, init order matters... 12.21.53 # congrats Zagor :) 12.22.01 # Reminds me of the H300's otg controller... 12.22.20 # not only order, but I have to wait for the connection interrupt before configuring bulk endpoints 12.22.22 # a common afliction datasheets neglect to ever talk about 12.22.35 # Hmm, maybe we'll be revisiting the H300 OTG at some point.... ;) 12.23.02 # Zagor: much work needed to make this stuff work on ipods too? 12.23.12 # Gigabeat supports OTG too. 12.23.21 # jhMikeS: The data sheet in fact mentions those limitations, but it wasn't very clear. In case of the OTG controller it is that not all status transitions are valid 12.23.29 # jhMikeS: thunderbird labeled your commit mail as spam :P 12.23.33 # jhMikeS: well, USB host at least 12.23.35 # preglow: I don't know what/if the differences are. those with the same controller should need very little modification 12.23.41 # ...and if you try one that isn't allowed, it's simply not executed... 12.23.45 # preglow: ummm...it's probably right :P 12.23.46 # not sure if we can do the OTG auto negotiation 12.23.51 # Zagor: i thought most of the usb stuff was on the pp chip 12.24.01 # yeah I mean those with the same pp as the sansas 12.24.20 # or perhaps all PP work the same regarding usb. I just don't know. 12.24.26 # i don't expect they've changed that too much 12.24.30 # preglow: On pp502x it should be all the same. Maybe the 5020 has a bug that's fixed in 5022 though 12.24.31 # markun: for gigabeat? 12.24.42 # * amiconn really doesn't trust pp anymore in that respect 12.24.43 # amiconn: wouldn't surprise me... 12.25.09 # at least we know what register accesses to look for in disassemblies 12.25.26 # preglow: That would mean it should be easily ported to mini G2, Nano and Video. G4, Color and Mini G1 could be problematic, but hopefully just work too 12.25.28 # jhMikeS: yes 12.25.43 # markun: why not? (not that I know atm what that is) 12.25.54 # this will be so cool 12.26.00 # G3 is a whole different thing, as (1) the PP5002's internal USB controller is different and even (2) it's not used, because it would be USB1.1 only 12.26.15 # The G3 has an external USB controller which is not (yet) known 12.27.15 # lunch 12.27.43 # * barrywardell congratulates Zagor 12.27.52 # jhMikeS: I'm not too familiar with OTG myself, I'll read up on it a bit 12.28.13 # The tetrahub seem to handle that stuff 12.28.30 Join bagawk_ [0] (n=lee@unaffiliated/bagawk) 12.28.31 # but I'm more interested in normal USB host and device support than supporting OTG 12.28.49 # yeah 12.29.11 # Hmm, doesn't the gigabeat already have device support, as that is a hardware bridge? 12.29.25 # I think a good deal is just handled by the tetrahub from an i2c ROM and we just handle packet on target. 12.30.45 # * amiconn is undecided what to try next :/ 12.31.01 Quit Thundercloud (Remote closed the connection) 12.31.02 Join japc [0] (n=japc@194.65.5.235) 12.31.35 # amiconn: sure, but we could use the device also for other things besides UMS (audio playback, serial port for debugging) 12.32.12 # Audio playback? 12.33.39 Quit bagawk (Read error: 110 (Connection timed out)) 12.33.41 # well, maybe not so useful 12.34.25 # a friend was working at an office where the PC's didn't have a sound card 12.34.43 # AH, using it as a sound card 12.34.48 # perhaps a Gigabeat could be used as a USB sound card 12.34.51 # yes, sorry 12.35.09 # For some reason I was thinking about the opposite - connecting a pair of USB speakers to a rockbox target 12.35.22 # why not :) 12.35.39 # Using it as a sound card would also allow using it like streamripper 12.36.56 Nick idnar_ is now known as idnar (i=mithrand@unaffiliated/idnar) 12.37.15 # are there USB clocks, so we can sync the time? :) 12.37.34 Join bluebrother [0] (i=CCblBtlP@rockbox/staff/bluebrother) 12.37.48 # gigabeat could record using an external adc 12.38.25 # if only we could find some foxconn connectors :( 12.38.45 # We could also implement MTP ;) 12.39.01 # and the ipod protocol :P 12.39.01 # ^^ _BAD_ joke 12.39.16 # amiconn: you know some people will ask for it ;) 12.39.22 # * bluebrother still wants a coffee plugin *g* 12.39.25 # I guarantee we'll get feature requests for MTP at some point. 12.39.25 # add that to the 3.0 realease TODO list 12.39.27 # Yay drm! 12.39.40 # Easy syncing with WMP and other such things, and a host aware of the formats the DAP can play, etc. 12.39.54 # jhMikeS: maybe we should skip 3.0 and just release 4.0 12.40.04 # I think were MTP not so closed, it might not be such a bad idea. 12.40.18 # sure - 3.0 was a NULL release :) 12.40.34 # wenn do we release 3.0.1? 12.40.42 # after 4.0? 12.40.49 # good idea. 12.40.51 # :) 12.40.53 # Llorean: but then you also need to implement building the itunes database... ;) 12.41.17 # pixelma: Building the iTunes database, no thanks. Transparently building ours as files are synced to the device? Maybe. 12.41.19 # :-P 12.41.20 # Rhapsody support too 12.41.39 # urgh 12.41.57 # and ITM support :) 12.41.59 # * amiconn still fails to understand how MTP / itunes could be "easier" than plain UMS access 12.42.07 # If it exists, we're _obligated_ to support it :) 12.42.10 # depends what you're used to 12.42.26 # * preglow likes the stack usage debug screen :> 12.42.34 # oh, and I'm _desparately_ missing proprietary sound effects. 12.42.37 # amiconn: With the proper host application, MTP "just works". You put your CDs in, say "Do your thing" and don't need to think. Perfect for people who wish they didn't own a computer, but want to listen to music anyway. :) 12.42.54 # jhMikeS: wouldn't "View OS Stacks" be better renamed to "Thread list" or something now? 12.42.56 # preglow: don't go killing threads willy nilly now 12.43.25 # Yeah, thread list sounds better 12.43.30 # what's this idle business? 12.43.33 # preglow: I agree, but now there's two items that aren't threads 12.44.01 # that's what i'm asking about, i guess 12.44.36 # and how do i kill a thread? :P 12.44.50 Quit linuxstb ("Leaving") 12.44.51 # preglow: 1) when COP threads exit plugins and the COP idles, it continues to idle on the stack of the last thread that ran. problem is, the plugin in not technically loaded anymore. 12.45.13 # you need to enable it in debug_menu.c 12.45.28 # think i'll just not do that, then 12.45.30 # preglow: they're also the stacks used when switching cores 12.45.43 # ok, so the percantage is still just plain old stack usage? 12.45.47 # yeah 12.46.06 Join petur2 [0] (n=petur@rockbox/developer/petur) 12.46.09 Quit petur (Nick collision from services.) 12.46.09 # pretty easy to interpret that as cpu idle percenage... 12.46.11 Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) 12.46.23 # if you don't use idle stacks when switching cores, both cores will be using the same stack at the same time for a bit...crash 12.46.46 # rename it "Idle Stack"? 12.46.51 # sounds good 12.47.23 # I thought it would be understood by the context though but that's np 12.47.46 # well, context currently is that the screen is named "stack view", but mostly seems to just display thread info 12.47.53 # not too clear 12.48.49 # what does T status mean? 12.48.58 # T=timeout 12.49.29 # BLOCKED_W_TMO more accurately 12.49.54 # ahh 12.50.36 # is rockbox capable of blocking on read(), or does it pretty much only block on queue reads? 12.50.58 # blocking on read? 12.51.25 # like other oses do when reading from a network socket, for example, i don't really know if we use read() for any fancy stuff or do stuff explicitely 12.51.29 # you mean background I/O? 12.51.38 # jhMikeS: are you intending to change the SVN playback code to make it use the new sync features ? It would be a waste of time IMHO 12.52.06 # Nico_P: I only did things to be compatible there 12.52.44 # mutexes cannot be used in the manner they were for codec swapping. semaphores have to be used and are more proper for that. 12.52.45 # ok 12.53.32 # jhMikeS: and now you recommend using mutexes and semaphore to sync things as much as possible ? 12.54.46 # as much as nescessary. no more of course. 12.55.14 Join Thundercloud [0] (n=thunderc@resnet13.nat.lancs.ac.uk) 12.55.31 # they pretty much should be used where they should be used, i guess, when commicating between threads :> 12.55.33 # for threading to be advantagous, you really need to sync as little as possible 12.55.40 # hello preemptive threading! :D 12.56.00 # yay! 12.56.07 # * jhMikeS hugs preemtive threading 12.56.52 Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) 12.58.44 # jhMikeS: typically, in the playback code, what would need sync ? 12.58.59 # jhMikeS: lemme guess, you don't use an editor with a 80 char wide window? :> 13.02.55 # preglow: um nooo 13.03.32 # Nico_P: not sure specifically right now. sort of depends on the MoB layout and stuff. 13.04.11 # yeah of course 13.04.33 # I would think the handle allocation would 13.04.58 # how ? 13.05.00 # Isn't that called directly by many threads? 13.05.17 # yes, that's true. two threads could call bufopen at the same time 13.06.03 # currently the only user is the audio thread though 13.06.37 # how does the WPS get the metadata? 13.07.08 # in most cases it accesses the static struct for the current or next track 13.07.17 # in some cases it might use bufgetdata 13.08.55 # jhMikeS: I have a question regarding your comment here: http://www.rockbox.org/tracker/task/5995?histring=idct 13.08.59 # (all the way down) 13.09.34 # I think mac and msac are equally fast, and there is just a mistake in the timing table in the mcf52xx user manuals 13.10.20 # jhMikeS says he's done tests 13.10.23 # I actually tried msac in the SPC codec and the boost change was quite high 13.10.23 # i thought it was just a mistake too 13.10.48 # eh? Really odd then 13.11.08 # it's really weird if that is so, it's pretty unheard of in dsp circles for those two to have different timinig 13.11.12 # mac.w, mac.l, msac.w are all listed as single cycle 13.11.13 # just negating one parameter and using mac was faster. I could verify again by changin two instructions. 13.11.28 *** Saving seen data "./dancer.seen" 13.11.42 # and mac.w, mac.l msac.w and msac.l with parallel load are all listed 2 cycle 13.11.56 # Only msac.l (without parallel load) is listed as 3 cycles... 13.12.54 # I'll check again and make sure nothing else factored in. I have a hard time accepting it myself. 13.13.19 # Otoh, the mcf5249 and scf5250 manuals agree on this... weirdo 13.14.03 # I'll make sure I try a full 8-voice SPC so that it gets a nice workout 13.14.17 # wow, that new mpegplayer menu was annoying 13.14.17 # jhMikeS: Btw, the yuv conversion for cf also uses emac saturation for clamping 13.14.46 # (for quite a while now, but doing two-line zig-zag is even better :) ) 13.14.59 # preglow: I agree. It could very much use banishing. 13.15.57 Quit advcomp2019 ("Leaving") 13.16.02 # amiconn: it makes nice quick work of that indeed 13.16.39 # jhMikeS: seems to me mpegplayer is more stable after your commit 13.16.42 # preglow: I don't know why it shouldn't just play something like a normal viewer 13.17.04 # Well, if there's something to resume, it should ask 13.17.17 # But _only_ then 13.17.46 # Yeah, if there's a resume point, some button that's not "Select" or "Right" should cancel, and any other button resume. 13.17.51 # it should ask about resume when exiting if anything unless it plays to the end 13.18.27 # preglow: are you saying it's been unstable still? 13.18.38 # jhMikeS: i've had some weirdness with hanging 13.18.45 # ah, no 13.18.47 # not unstable now 13.18.50 # works just fine 13.19.06 # i don't get why i can only seek at the start menu... 13.19.12 # odd...could be the fact the kernel object are actually dual-core safe 13.19.30 Join jac0b [0] (n=jac0b@gifn3.fpl.com) 13.19.36 # I never did ask why the seeking is in 30 second increments. 13.19.44 # did any of the mpegplayer seeking implementors even visit irc? 13.19.45 # why? :) 13.19.50 # s/even/ever/? 13.20.14 # why should they...they're so 1337 13.20.19 # wow, mpegplayer is almost smooth on the h120 now 13.20.26 # What FPS? 13.20.52 # pondlife, can't see it. I think graylib interferes with printing the fps 13.20.54 # preglow: I also don't understand why they implemented it in this way 13.21.22 # I have a question about posting to the wiki. 13.21.23 # and duplicating code to generate the thumbnail 13.21.28 # some discussion on the matter would be sweet, they seem to have done good work 13.21.40 # jac0b: thanks for all your battery stuff btw! 13.21.47 # what's your question? 13.21.48 Quit jhMikeS (Read error: 104 (Connection reset by peer)) 13.22.11 # jac0b: btw, whas your last 26 hour benchmark without replacing the PCB? 13.22.23 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 13.22.56 # * preglow ponders making jpeg.c decode images in the background with another thread 13.22.59 # I was asked in the forum to post a how-to on the wiki, is that okay or should I make a post in the forum with the how-to 13.23.17 # The wiki is for things like how-tos. 13.23.21 # jac0b: static info should always be in the wiki imo 13.23.31 # The forum is, where possible, best kept for discussion and question/answer type things. 13.23.32 # markun: yes I didn't replace the PCB just the wires 13.23.44 # jac0b: I'll order one of those batteries as well then 13.23.59 # preglow: If you did that, how would it manifest itself when using the jpeg viewer? 13.24.13 # Isolinear: basically not making you wait when zooming in some cases 13.24.17 # preglow: excellent idea 13.24.25 # safetydan: The graylib doesn't allow printing the fps the normal way while it's active, due to how it works 13.24.34 # preglow: That was my guess.. I say go for it. :) 13.24.41 # llorean: so posting the how-to in the wiki is better than posting in the forum? 13.24.44 # * preglow needs to learn to start finishing stuff 13.24.45 # The fps would need to be printed using graylib functions 13.24.54 # jac0b: Yes. 13.25.10 # preglow: btw, maybe it would be possible to use the buffering API to store pictures in memory in advance 13.25.15 # amiconn, I was just going to print it to the lcd remote but that sounds better 13.25.15 # llorean: thanks 13.25.18 # preglow: That will only work if there's enough RAM 13.25.25 # While on the topic, why is it that my jpegs have a limited zoom when I view them with music playing? 13.25.25 # amiconn: sure, it will obey the usual limits 13.25.35 # Nico_P: For a slideshow like feature? 13.25.38 # safetydan: The unbuffered graylib functions have no text output 13.25.44 # preglow: on COP? :P 13.25.51 # Llorean: yeah for example 13.25.55 # Buffered has them, but would be slower for mpegplayer 13.25.56 # today I will be posting the how-to with the info on what battery I used 13.26.10 # jhMikeS: well, why the hell not. if you've done your stuff correctly, there shouldn't be too much hardship involved :P 13.26.15 # and how to put it together 13.26.16 # Hmm, mpegplayer is far from smooth on H300 sim. 13.26.46 # The current graylib isn't that suited for moving content anyway, because (1) all the bit shuffling is slow and (2) the content change interferes with the greylevel generation mechanism, so it becomes grainy 13.26.52 # only cache stuff, lord oh lord, how i wish the cache snooped the bus 13.26.56 # preglow: haven't had a problem myself with using it 13.27.03 # (not noticeable on H100 because of the dog-slow panel, but on others) 13.27.34 # I have plans for a way faster implementation with more greylevels, faster updates, and no graininess when changing content 13.27.39 # does anyone know if the gigabeat has a black front cover that is metal? 13.27.45 # and yeah, I hate that cache stuff. it's the worst part of this. 13.27.57 # h10 and ipod video people needed for testing: http://www.rockbox.org/tracker/task/7951 13.28.15 # jac0b: my friend's F10 has a black metal fron cover 13.28.28 # preglow: Ignore that patch, we'll go asm soon 13.28.34 # amiconn, I'm curious how you'd do that as I thought the current routines were as fast as they could get on the h120 lcd controller? 13.28.46 # amiconn: how soon is soon? 13.28.57 # amiconn: i don't see any harm in commiting it unless we're going asm tomorrow 13.29.09 # safetydan: The controller output has nothing to do with that. I'l switch from using planar data to 2 arrays of byte-packed data 13.29.28 # One holds the actual image, and the other holds the current phase for each pixel 13.29.29 # if more instructions were squeezed out, then e200 and gigabeat should get that too. 13.29.30 # markun: well people with the plastic black covers might not be able to use the 4G iPod batteries in their player 13.30.05 # preglow: Depending on how I proceed with the cf asm, it could be today for H10... 13.30.28 # pondlife, looks to be about 8 fps 13.30.59 # markun: my g/f has a black plastic front cover and I bent it when I put it in last nite but this morning the touchpad was non responsive again. 13.31.18 # jac0b: which player does she have? 13.31.24 # safetydan: Practically, my new idea will do what halftone.c does when generating .RVFs, just live, and of course without using floating point :) 13.31.25 # amiconn: sure, and what about the other targets in that patch? 13.31.28 # the F10 13.31.56 # I could have sworn my fried's was metal, I can check when I visit him on thursday 13.32.04 # so the battery is a bit big? 13.32.36 # yeah a bit 13.32.44 # preglow: you must mean small H10? 13.32.54 # you know the black rubber feet on the OEM battery 13.33.02 # jac0b: http://www.amazon.com/Battery-Toshiba-Gigabeat-S-MES30VW/dp/B000VJEGT6/ref=sr_1_3/105-1064860-1169264?ie=UTF8&s=home-garden&qid=1192534352&sr=8-3 13.33.06 # same company, right? 13.33.08 # amiconn, I'm always amazed at what people can squeeze out of these things. that will be interesting to see 13.33.14 # jhMikeS: and video and nano... 13.33.25 # * jhMikeS has big H10 13.34.09 # jac0b: no, don't really remember the rubber feet 13.34.10 # I ought to throw those optimizations in lcd-as-memframe.S and try it 13.34.27 # preglow: amiconn said yesterday that the c200 version won't work or at least won't have a noticeable effect because the bottleneck is somewhere else 13.34.31 # markun: same battery company but that battery is only a 1000mah and not a 1200mah like the iPod battery 13.34.41 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 13.34.44 # jac0b: hence the small size difference 13.35.04 # Any downside in upgrading my iPod battery to a high capacity one? 13.35.18 # Isolinear: longer charge times? :) 13.35.27 # lol 13.35.55 # And conversely, longer runtimes especially with Rockbox, yes? :) 13.35.59 # markun: well if you look at the OEM battery from the side with the rubber feet on it the iPod battery is about the same thicjness 13.36.02 Join TheRock [0] (n=bof@host7-100-dynamic.183-80-r.retail.telecomitalia.it) 13.36.05 # thickness* 13.36.10 # Isolinear: also, non official batteries have 'exploded' from time to time 13.36.20 # Hahaha. 13.36.38 # Any brands or sources I should avoid? lol 13.36.54 # amiconn: are you going to asm optimize the other targets that patch addresses too? 13.37.05 Quit ddalton ("leaving") 13.37.32 Quit spiorf (Read error: 110 (Connection timed out)) 13.37.45 # markun: these are the batteries I am suggesting people get http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=150167366382&ssPageName=STRK:MEWN:IT&ih=005 13.37.48 # Isolinear: jac0b should know more about sources to avoid (because they lie about the mAh value) 13.37.59 # jac0b: yes, saw that 13.38.11 # quite cheap 13.38.30 Join spiorf [0] (n=spiorf@host215-223-dynamic.1-79-r.retail.telecomitalia.it) 13.38.40 # isolinear: is yours a 4G ipod? 13.38.41 Quit safetydan ("Leaving") 13.38.47 # 5G. 13.39.07 Quit GregoryHouse (Connection timed out) 13.39.31 # Although I just got my girlfriend a 4G, so it's all applicable... :) 13.39.45 # markun: Yeah, manufacturers of cheap replacement LiIon batteries often lie about their capacity 13.39.52 # What are the stock capacities for 4G and 5G anyway? 13.40.14 # For my digicam, I have 2 batteries, a branded 800mAh one and an unbranded 1000mAh one. Guess which runs longer? 13.40.40 # amiconn: so far I was lucky with my no brand batteries 13.41.22 # at least the ones for my canon and h120 they last longer than the original batteries 13.41.56 # Can one use a multimeter to test the "actual" capacity of a LiIon battery? 13.42.22 # not in any matter that would be more efficient 13.42.31 # manner 13.42.41 # Still have to run the charge down? 13.42.54 # afaik, yes 13.42.59 # Thought so. 13.45.04 # preglow: I'm pretty confident Zagor's code will just work on ipods - I've tested austriancoder's code occasionally, and it's always done the same on my ipod as it did on his Sansa. 13.45.46 # * Llorean is excited with the thought of USB on the horizon. 13.46.13 # * preglow too 13.46.14 # * linuxstb is excited with the thought of hiding ipods from itunes 13.46.17 # amiconn: ping... 13.46.22 # Llorean: USB for what? 13.46.44 # Isolinear: usb stack for rockbox 13.47.07 # Isolinear: It means "My nano may not be bog slow, and I can finally nuke the OF" 13.47.29 # linuxstb: I hope anyone can show the gigabeat S guys what they need to change to get it working with their players 13.47.44 # Ahhh, we're still using Apple disk mode, aren't we? 13.48.01 # Isolinear: deedey 13.48.15 # markun: CameronSino seems to be a good brand of replacements... 13.48.42 # isolinear: I would just make sure it is a cameron sino 13.48.43 # Gotcha... Which probably also means that my iPod won't need to reboot every time I go from USB to playing music and back? :) 13.49.06 # Indeed 13.49.14 # markun: I'll second the CameronSino thing, at least my H120 one had a runtime along what it should with its capacity, and the battery hasn't exploded yet. :) 13.49.14 # my, that will be sweet 13.49.18 # jac0b: That a brand of battery? 13.49.41 # Guess so.. lol 13.49.43 # isolinear: yep 13.49.52 # sorry I am at work 13.50.03 # Yeah, I gathered it was from what Llorean said before you could respond.. ;) 13.50.38 # So how far off is USB for iPods then? 13.51.10 # "When it's done." 13.51.20 # Of course... :P 13.51.30 # Allow me to rephrase... 13.51.38 # Is someone working on it? ;) 13.51.42 # At least one. 13.51.48 # Cool. 13.51.48 # Llorean: but does Zagor intend to have it working soon? 13.52.00 # markun: Why wouldn't he? 13.52.04 # markun: Sounds like it. 13.52.16 # linuxstb: Just to mess with our heads.. :) 13.52.59 # linuxstb: perhaps it was more of a viewport/fontcache priority for him :) 13.53.29 Quit iamben (Read error: 104 (Connection reset by peer)) 13.53.31 # markun: it sounds like henearly has it working already 13.55.20 # I'm working as much as time permits. writing usb-storage code as we speak. 13.55.46 # Zagor: great! 13.55.48 # do you want it live? ;) 13.55.58 # inq_data.DeviceType = DIRECT_ACCESS_DEVICE; 13.56.03 # :) 13.56.13 # lol 13.56.35 # \o/ 13.56.55 Quit jac0b ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 13.58.12 Quit Nico_P (Remote closed the connection) 14.01.33 Join Arathis [0] (n=doerk@p508A6EEF.dip.t-dialin.net) 14.02.36 # Zagor: No webcam? ;) 14.02.46 # haha 14.03.46 # USB webcam, will be active when coding complete ;) 14.03.54 # Ah that vicious circle.. 14.03.59 # Including host support 14.04.24 # And of course USB->Ethernet and a webserver plugin... 14.06.45 # preglow: was there some upate to the mpegplayer seeking code that I missed? 14.07.44 # linuxstb: no, support for wireless usb stick and an ftp server to sync your music to 14.08.48 # markun: the sansa OF's stupid "database refresh" might give some more motivation to work on it 14.10.26 # preglow: I think you're right. It seeks movies that would just hang before. 14.10.51 # pixelma: yes, stupid behaviour of an OF can be very motivating :) A long list of motivations to port rockbox to the Gigabeat 14.14.08 # JdGordon: after your touchpad and mouse for sim commits a USB mouse could actually work :) 14.16.26 Join agm3nt [0] (n=opera@bartek.tu.kielce.pl) 14.26.40 Quit barrywardell () 14.27.15 # interesting commentary on the fs7510 again.. so maybe we do get a "rollback" of akind 14.31.14 # preglow: another ambisonics guy http://forums.rockbox.org/index.php?topic=13259.msg100277#msg100277 14.33.51 # markun: the gigabeats would be able to decode ambisonics for sure 14.34.01 # maybe even coldfire if the codecs are easy 14.36.08 # depends how much filtering one would want to do, though 14.36.41 Join barrywardell [0] (n=barrywar@host-194-46-226-143.dsl-ie.utvinternet.net) 14.36.46 # only thing i know for sure is i can both encode and decode a huge number of sources to a huge number of loudspeakers on this pc with a very nice cpu load 14.37.03 Join Morey [0] (n=bmorey@bhost-138-64-188-92.atk.com) 14.38.12 Join bluey- [0] (n=bluey@dslb-088-073-108-017.pools.arcor-ip.net) 14.39.21 # preglow: I'm one of the authors of the mpegplayer seek functionality. We have a plan to get seeking from within the player as well. Also the startup menu needs work, I just started a new patch that almost eliminates the delay in startup. 14.39.48 # Morey: only thing i feel strongly about is that i don't want a menu to appear when i would expect the thing to just start playing, everything else looks pretty good to me 14.41.00 # preglow: After the seek is moved to the play menu we should be able to just ask for resume (if a bookmark exists) on startup. 14.41.17 # goodie 14.41.34 # This is not an easy task and is taking me a little time to do, but it's in the works. 14.42.57 # As for now I think you will find my new patch less annoying. I worked out some of the delays and did some coding cleanup. 14.43.20 Quit barrywardell () 14.43.28 # Morey: good to see you on IRC 14.43.37 # easier to communicate 14.44.40 # markun: Can't stay on for long, but wanted to let ppl know I'm aware of the problems, complaints, and compliments. 14.46.13 # Task #7971 is the new patch. 14.48.10 # ok, great 14.48.39 # personally I don't we need such a special preview screen for seeking at all 14.48.55 # but I haven't looked at the mpegplayer since your patch got committed 14.49.03 # jhMikeS: The update to the seeking code fixed an issue where an mpeg got chopped off and the stream didn't start at time 0. Now it takes into account the stream start time as 0. 14.49.28 # markun: do gigabeats do digital out? 14.49.28 # Plus offsets the ending of course. 14.49.45 # preglow: No. 14.50.07 # preglow: Although I have a feeling there is I2S in the dock connector.. 14.50.32 # Morey: what about where looking ahead into the guard buffer when parsing can access garbage? 14.51.07 Quit ramon8 (Read error: 104 (Connection reset by peer)) 14.51.09 # linuxstb: there is 14.51.46 # preglow: is it possible to make a simple i2s -> s/pdif convertor? 14.52.41 # jhMikeS: There should be checks to handle that. 14.52.43 # hmmm...that sounds like a nice little kit project 14.52.53 Nick parafin|away is now known as parafin (i=parafin@paraf.in) 14.53.04 # markun: if you can get the proper chips it shouldn't be too hard 14.53.17 # might even get away with just one chip 14.54.30 Join roolku [0] (n=roolku@82-41-2-141.cable.ubr01.edin.blueyonder.co.uk) 14.56.37 # Morey: but what about further increment + lookaheads? I only see one. 14.56.51 Join kugel [0] (i=kugel@unaffiliated/kugel) 14.57.35 # preglow: http://www.wolfsonmicro.com/products/WM8804/ 14.58.39 # markun: looks like it'll do the trick 15.00.39 # markun: surface mount, though, prepare for soldering fun 15.00.49 # so we can mod the gigabeat cradle to output s/pdif? 15.01.00 # jhMikeS: Not sure, i'll have to ask Gwynne. He worked on that code. 15.01.45 # jhMikeS: either mod the cradle or make our own 15.02.25 # Morey: I only see one check. Everything else looks the same as before. Every increment could put a lookahead past disk_buf_end. Just my .02 15.03.13 # markun: well, just make a new pc board and nicely package it in there :) 15.04.22 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 15.09.22 # Morey: One change I'd like to make in there is to use the normal message queues instead of the hack that was there before the full COP support. Are you relying on the current code alot for anything? Will changing it be terrbly disruptive to anything? 15.09.29 Part hcs 15.11.05 # jhMikeS: it would be nice to get #7971 in svn first. then you would not disrupt anything. 15.11.33 *** Saving seen data "./dancer.seen" 15.13.45 # ok, I'm waiting a bit anyway before integrating tons of stuff 15.15.40 # jhMikeS: The start menu takes about 7 seconds to load in which it's determining the length of the mpeg. That new patch got that time delay down to about 3 seconds on my e200. 15.16.33 Quit CaptainSquid ("Miranda IM!") 15.19.01 Join nicktastic [0] (n=nick@unaffiliated/nicktastic) 15.19.24 # Morey: there's code in mplayer that does some figuring based on first/last timestamps and a few other heuristics. not much looking around is done. 15.21.48 # jhMikeS: One issue that I fixed was in alloc.c where mallocs were zero'ing out the data. This is not needed and was really slowing things down. 15.21.49 # does the statement between brackets meen that wav playback in not gapless? http://forums.rockbox.org/index.php?topic=13261.0 15.21.55 # s/in/is/ 15.22.09 # Morey: the calloc function? 15.22.59 # jhMikeS: No, calloc should zero out the data. Malloc should not, and it was. This may have been a mistake on our part, but I removed it in the new patch. 15.23.52 # * jhMikeS saw a small writeup clamining rockbox is gapless only because it inserts a small fade between tracks and wanted to correct this error but comment registration was closed. :\ 15.24.59 Join tictoc [0] (i=tabac@gateway/gpg-tor/key-0xB9002659) 15.25.17 # jhMikeS: where did you read it? 15.26.03 # on iaudiophile.net about rockbox and the m5 15.26.15 # I might have an account there 15.26.24 # http://iaudiophile.net/news.php?10 15.27.21 Quit Morey ("Ninja IRC v1.5.8.1(#1) exiting after 50m37s of use") 15.27.22 # It's a different login than the forums, or something 15.27.30 # I'm logged into their forums, but it tells me I must be logged in. 15.27.46 # * preglow thinks it's about time the ipod scrollwheel accel patch went in 15.27.51 # anyone have any objections? 15.27.51 # yeah, it works about as well as cowon support 15.28.20 # preglow: What settings does it add? 15.28.23 # not really. sansa settings range needs tweaks but that's about it. 15.28.35 # oh, there's that, we might not want the settings 15.29.02 # preglow: I think it's OK to add them initially, to give people chance to play with them, but later we may want to remove them. 15.29.13 # jhMikeS: I only have an account for the forums :( 15.29.21 # linuxstb: remove them after people have had the chance to tweak them? there will be complaints... 15.29.26 # preglow: I very much would prefer if the wheel settings where hard-coded. :) 15.29.38 # i.e. so we can work out what they should be for all the different targets (assuming they will need to be different). 15.29.42 # either we remove them now, or with great difficulty later 15.29.58 # Or... hide them in debug? 15.30.02 # preglow: We're dictators - just put a comment in the commit message saying the settings are temporary... Or just remove them now... 15.30.25 # ideally we would have a dev tweak each target, then just use that as a hardcoded value in the commit 15.30.27 # Debug menu might be a nice idea. 15.30.44 # i don't really think so, i think we should at least _try_ to go hard-coded 15.30.45 # Put them in debug, and have the commit comment say "Settings can be adjusted in the debug menu, with the intent to choose a final value" 15.31.20 # I like the Nano values of the last version of the patch I tested, which is I believe the second to last entry in the tracker. 15.31.24 # preglow, Llorean: For example, can the two of you agree on the values for the Nano? 15.31.24 # markun: usb mouse would be.. umm... interesting :p 15.31.42 # linuxstb: The default ones in the patch are good for the Nano, I think. 15.31.42 # i liked the last patch i tried, which i believe is v12, haven't tried the latest 15.32.03 # Yeah, v12 for Nano was fine by me 15.32.06 # i will however do so in ten minutes 15.32.09 # brb 15.32.12 Join barrywardell [0] (n=barrywar@dhcp-892b9bdd.ucd.ie) 15.32.17 # * linuxstb will try and test the patch this evening on his Color and Video 15.32.46 # excellent 15.33.24 # jhMikeS, Llorean: you could try to PM the author: http://iaudiophile.net/forums/member.php?u=4 15.33.31 # markun: Already did that. :) 15.33.54 # Explained that Rockbox had true gapless since before M5 or even X5 support, and that crossfade is actually an entirely separate feature. 15.34.05 # I was even polite. 15.34.30 # Llorean: wow, congratulations on that last bit :) 15.34.34 # hrmf. /me spots typedefs in the hotswap code. 15.35.06 # oh? 15.35.17 # * JdGordon doesnt remember adding any 15.35.36 # tCardInfo 15.35.43 # "svn blame" never forgets... 15.35.48 # :) 15.35.52 # and tSDCardInfo 15.36.17 # svn blame shows who commited it.. not who coded it :) 15.36.48 # with git it would show who codec it.. 15.37.07 # how that? 15.37.09 # markun: thanks. if Llorean doesn't get to it, I'll try later. 15.37.16 # jhMikeS: he already did 15.37.48 # bluebrother: because it makes a difference between the person who wrote it and the person who commit it 15.38.02 # markun: How? 15.38.06 # from what I understood during a discussion at the GSoC summit 15.38.17 # not if the person adding it to git was doing it for someone else.... 15.38.44 # svn blame will give you a revision number, and the commit message should indicate if the committer wasn't the author. 15.38.45 # well, assuming that it was pulled from the git repository of the person who wrote it 15.38.55 # instead of from the patch tracker 15.40.04 # but the guy who wrote it still needs to check it in -- even if it was a different repository ;-) 15.40.19 # is cid and csd the only textual information available about sd cards? 15.40.37 # iirc, yes. 15.40.40 Nick Tanuva|Zzz is now known as Tanuva (n=tanuva@83.220.128.10) 15.41.00 Join pondlif1 [0] (n=Steve@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 15.41.00 Quit pondlife (Read error: 104 (Connection reset by peer)) 15.41.08 # I finished the ata/scsi layer before I realized my target doesn't have ata :-) 15.41.19 # well done :) 15.41.30 # markun: ah, woops. didn't read enough. 15.41.44 # Zagor: I thank you on behalf of ipod and H10 users ;0 15.42.03 # linuxstb: yeah, to bad you guys will have to debug it ;-) 15.42.11 # bluebrother: no, it can be pulled, or what are you trying to say? 15.42.48 # markun: if the origin is a patch (e.g. from the tracker) you can't figure out who wrote it as that person didn't check it in to any repository 15.43.07 # Zagor: I thought the Sansas implemented the same ata_* API though/ 15.43.08 # ? 15.43.27 # linuxstb: yeah, almost. only the basic identification and capacity reporting differs. 15.43.55 # bluebrother: isn't that was I said? "well, assuming ... instead of from the patch tracker" 15.43.59 # so hopefully your debugging duty will be light 15.44.17 # markun: seems I missed the last part ;-) 15.44.35 # Zagor: Sounds like you're close to mounting... 15.44.48 # yeah, I'm an optimist :) 15.44.55 # * markun should play around with git a bit 15.45.31 # Zagor: what information do you need? 15.45.34 # * bluebrother is curious when he'll be able having the Ipod doing some usb stuff 15.45.54 # bluebrother: when it's done ;P 15.46.14 # damn. I feared that answer. Bastards! :P 15.46.14 # should have put quotes around it since it's llorean's line 15.46.15 # barrywardell: nothing really important. there is a vendor and prouct text field in the scsi protocol that would be nice to enter something in. 15.46.34 # <|Rain|> Zagor: you should probably just use whatever the OF for that platform uses 15.46.37 # csd and cid appear to be the candidates to use, but what are they? and in what bit order 15.46.54 # |Rain|: no this is information that is on the card/disk 15.47.17 # s/bit order/byte order/ 15.47.35 # <|Rain|> Zagor: you're talking about the vendor/model/revision info? or something else? 15.47.50 Join jgarvey [0] (n=jgarvey@cpe-069-134-102-044.nc.res.rr.com) 15.47.52 # Zagor: they're fully detailed in the SD specs 15.47.57 # |Rain|: yes, in the scsi INQUIRY struct 15.49.40 # <|Rain|> Zagor: 15.49.41 # <|Rain|> Inquiry command 15.49.41 # <|Rain|> --------------- 15.49.44 # <|Rain|> Vendor: SanDisk 15.49.44 # <|Rain|> Product: Sansa e280 15.49.44 # <|Rain|> Revision level: 15.50.40 # |Rain|: I'm still interested in reading it from the card. this is supposed to be a multi-platform driver. 15.50.58 # i think there are some makefile dep errors around with regard to lang file updates 15.51.07 # i needed to make clean before the patch built 15.52.37 # Zagor: any guesstimates on when you'll be copying files to your sansa via your own usb code? :> 15.52.44 Join |Rain|_ [0] (n=rain@blackhole.themuffin.net) 15.52.48 # <|Rain|_> grr 15.53.20 # preglow: possibly tonight 15.53.28 # :POPpPpPPpppPP 15.53.34 # * preglow crosses fingers 15.53.42 # <|Rain|_> Zagor: that's why I suggested just reporting what the OF does, although I doubt anything matches on that instead of the USB ID. I know it's supposed to be multi-platform, but you probably WILL want to match the OF USB ID, so you've probably already got some hardcoded platform-specific stuff 15.54.34 # <|Rain|_> Zagor: but I'm not against the idea of providing meaningful information, either (although -- what do you do for hotswap SD cards? the INQUIRY will probably only happen at device connection, unless I'm mistaken...) 15.55.04 # we support hotswap already. and so does usb-storage. 15.55.05 # Zagor: the CID has product name string, manufacturer id, oem id, ... I think that's the best to use 15.55.28 # <|Rain|_> Zagor: yes, but the INQUIRY happens whether there's a device inserted or not, and I don't believe it happens again when media is inserted 15.55.29 # barrywardell: do you have a link to a good spec? I only find partial ones. 15.55.34 # nice, rockbox shirt in China: http://linus.haxx.se/pekingblog/wp-content/uploads/2007/10/linus-pa-stan.jpg 15.55.43 # http://www.sdcard.org/about/memory_card/pls/ 15.55.47 Quit lee-qid ("aufwiederbyebientotsayonara") 15.55.52 # page 86 15.55.59 # <|Rain|_> s/a device/media/ 15.56.10 # |Rain|: I'm pretty sure we read it when new media is connected, but if not that is easy to fix 15.56.21 # Llorean: i'd say the latest patch is pretty good on nano 15.56.32 # <|Rain|_> Zagor: I'm talking about the host OS 15.56.44 # preglow: Pretty much the same as v12? 15.56.53 # didn't try v12, only v11, it seems 15.56.55 Quit |Rain| (Read error: 104 (Connection reset by peer)) 15.56.58 # Ah 15.57.00 # |Rain|_: the host OS has to support multiple inquiry. otherwise hotswap harddisks wouldn't work. 15.57.19 # anyway, let's deal with that when/if it happens 15.57.25 Nick |Rain|_ is now known as |Rain| (n=rain@blackhole.themuffin.net) 15.57.48 # <|Rain|> Zagor: for real hotswap SCSI drives, I always have to force a rescan -- but okay 15.57.59 # barrywardell: thanks 15.58.12 # |Rain|: maybe you're right. we'll see. 15.58.38 # <|Rain|> tbh I'm just anxious to see the code. the vendor could be "turkey" and the model could be "giblets," and I'd still be happy :P 15.58.46 # ouch, i think i've found a bug in dir browser limits here 15.59.52 # if i set the max entry limit low, try to open a dir with too many, increase the max entry setting, then look at the dir again, all of the new files can't be used, plus the "open with" menu is clobbered 16.01.28 # wtf, it seems like these settings need you to restart, but don't really tell you 16.03.02 # amiconn: what does the common H10 user (like me) have from the last commit? 16.04.10 # preglow: I thought increasing max files used to tell you. 16.04.12 Quit |Rain| ("unborking") 16.04.29 # doesn't anymore 16.04.47 # the tree code really shouldn't use the new value, but i think someone has blundered here 16.04.52 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 16.04.54 # Aaah 16.05.15 Join |Rain| [0] (i=rain@2001:440:eeee:fffb:42:0:0:2) 16.06.26 # the people who redesign menus aren't always so careful to retain old functionality either 16.07.39 # Arathis: which commit? 16.08.31 # i truly wish people would start using the code style in the file they're editing 16.08.38 # so preciously few even try to do this, it seems 16.09.33 # barrywardell: "Improved H10 ADC driver." 16.09.51 # gotta go. see you later. 16.09.52 Quit Zagor ("Client exiting") 16.10.10 # Arathis: it will hopefully make the readings from the ADC less jumpy (battery, remote, scrollpad) 16.10.24 Join midkay [0] (n=midkay@rockbox/developer/midkay) 16.11.06 # oh, cool :D 16.12.24 # preglow: Code style..? I only changed 2 characters... 16.12.32 # pondlif1: not talkinga bout you 16.14.32 Quit blithe (Read error: 104 (Connection reset by peer)) 16.14.52 Part pondlif1 ("disconnected has pondlife") 16.15.00 Join pondlif1 [0] (n=Steve@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 16.15.02 Join blithe [0] (n=blithe@stiletto.djblithe.com) 16.15.28 # Hmm, my IRC client's confused...sorry 16.15.30 Part pondlif1 ("disconnected has pondlife") 16.16.05 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 16.17.38 # problematic indeed. 16.17.40 # seems quite a few places use the new value with no realloc of buffer 16.17.42 # gah, sorry 16.19.16 Join Hammer89 [0] (n=soc_inte@static-host-24-149-229-197.patmedia.net) 16.22.42 # does the e200 bootloader need to be updated on my player? (haven't installed a new bootloader in months) 16.26.08 # Hammer89: probably not. Are you having problems? 16.26.55 # no.... but I haven't updated rockbox in months 16.27.11 # so I was just checking before I did, and got a nasty surprise ;) 16.27.29 Quit animeloe ("This computer has gone to sleep") 16.27.48 # I don't know anything about the sansa players, maybe someone else can answer 16.28.02 # alrighty 16.30.06 # if it is working for you, then there isnt really a need to change it, but it shouldn't hurt you if you do 16.30.16 # okay... thanks :) 16.30.51 # scorche|w: the gigabeat really needed a bootloader update a few times 16.32.55 # markun: aye...i /think/ this one is just to fix issues with OF loading 16.33.35 Quit JdGordon ("Konversation terminated!") 16.34.02 # urgs 16.35.09 # what is this warning in the x5 sim "oggmalloc.c:8: warning: dereferencing type-punned pointer will break strict-aliasing rules"? 16.35.17 # jhMikeS: new flyspray entry concerning you 16.35.18 Quit zicho (Read error: 104 (Connection reset by peer)) 16.35.23 # I didn't even touch that file? 16.35.48 # m5 sim 16.37.06 Join zicho [0] (n=martin@c-6a98e355.68-7-64736c14.cust.bredbandsbolaget.se) 16.38.47 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.40.06 # it's already there in previous commits - sims that were built on 64bit machines if I see correctly. First occurance in jhMikeS' commit but since there were other warnings as well and the usual 2 in sim builds, it's hard to spot 16.40.24 # okie 16.40.54 # first I see is the H120 sim in the big commit 16.47.43 # one other thing... does rockbox play m4a's? 16.48.13 # jhMikeS: Did you write the arm idct for mpegplayer, or is that something libmpeg2 already had, and we just didn't use it before? 16.48.33 # I wonder why it's asm-in-c instead of a proper .S file... 16.48.59 # amiconn: do you plan to write asm versions of nano and video yuv blit too? 16.49.09 # yes 16.49.18 # ok, i will ignore that flyspray entry, then 16.49.25 # In fact nano could use the same as H10 will, if we split out the driver 16.49.50 # (more efficient - doing the double-line zig-zag as already used for gigabeat, e200, and c200) 16.50.16 # ...and also for X5 and H300, although that's of course different asm ;) 16.50.58 # Color could for the type 1 lcd, but not for type 0, unless someone finds out what controller that actually is and we find a datasheet 16.51.15 # amiconn: btw, do you know anything about the limits menu? did those entries use to tell you that you have to reboot? 16.51.28 # yes 16.51.32 # then they are bugged 16.51.42 # currently i get corrupted entries when making it bigger 16.51.43 # Or, rather they didn't tell 16.52.02 # ...but the new value used to only apply after reboot 16.52.10 # Then someone messed them up 16.52.24 # both zagor an linus have put in uses of the .max_files_in_dir member 16.52.33 # afaik that value should only be used on boot, yes? 16.52.54 # tree.c does back it up to a separate variable, but other files don't see that 16.53.04 # Umm, I don't know the exact details of the implementation 16.53.26 # But you're probably right, and the settings member must only be used on boot 16.53.38 # anyway, right now the behaviour is messed up, if i increase the size, the "open with" menu gets seriously garbled, and new file entries don't work at all 16.54.05 # * amiconn is trying to get his head around idct :/ 16.55.25 # do the yuv blit asm first :> 16.55.36 # nah 16.55.53 # Which target(s) have worse video performance, coldfire or PP? 16.56.00 # coldfire, afaik 16.56.07 # exactly 16.56.43 # i never tried playing a video on coldfire 16.56.51 # and only do so on pp for testing 16.58.53 # i'm quite confused by this stuff, some of the .max_files_in_dir use is pretty old 16.59.31 # either the code has been rewritten in funny ways, or this bug has been in rockbox for a good while 17.00.52 # Probably a bit of both 17.01.37 # mostly zagor have touched the files, it seems 17.01.40 # think i'll ask him later 17.04.34 # * pondlife wonders where the MajorChanges link on the front page went... 17.05.43 # someone talked about RTC problems on the Gigabeat a while back. I also got some now (but don't know how to reproduce) 17.06.01 Quit TheRock () 17.06.02 Join mf0102 [0] (n=michi@85.127.182.13) 17.06.11 # markun, what, that the clock unsets itself sometimes? 17.07.32 # Hm, Slashdot says DRM-free iTunes music now costs the same as the encumbered stuff. 17.08.47 Part agm3nt 17.08.47 # markun/ krazykit: yes, happens to me occasionally usually after midnight? 17.10.09 # roolku, i've turned off my player only to turn it on 20 minutes later to have the time unset. i can't figure out the common factor in all of this. 17.11.36 # krazykit: I am not saying it is cause/effect. I just notice it most often when I want to listen to an audiobook before I go to sleep 17.11.38 *** Saving seen data "./dancer.seen" 17.14.44 Quit aliask ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007073113]") 17.18.04 Join ToHellWithGA [0] (n=ryan@d8-18.rb2.clm.centurytel.net) 17.18.35 # Llorean: what's the use of the encumbered stuff then? 17.18.38 Join random_desu_is_s [0] (n=chatzill@inet-out.dsl-nat.sura.ru) 17.19.03 # Is the Iriver H300 capable of a wake-up alarm? 17.20.01 # markun: As of this new pricing change? No clue at all 17.20.09 # iiuc the unencumbered stuff is even at a higher bitrate. 17.20.41 # maybe some people feel better using DRM-ed stuff :) 17.20.55 # "Hah, now nobody can steal MY music!" 17.20.57 # "Files you can trust" 17.21.01 # pondlife: I believe so but needs it enabled in the bootloader too IIRC, I think XavierGr played around with it - probably he knows more 17.21.07 Part bluey- ("Leaving") 17.21.23 # According to the wiki, the SVN bootloader supports it. 17.22.03 # Great. I was just so suprised about the new very smooth midi playback of my big H10 and than it crashes at playback. It's one specific file and a specific location in playback. :/ 17.24.09 Join sin613 [0] (n=single@71-217-183-28.farg.qwest.net) 17.24.33 # pondlife: could remember about a patch http://www.rockbox.org/tracker/task/7814?histring=alarm but that's all I know... 17.25.19 # pixelma: Thanks 17.25.41 # barrywardell: ever experienced such a midi crash? 17.36.54 Join AmbiquitY [0] (i=51f1b1f0@gateway/web/cgi-irc/labb.contactor.se/x-de18c9c09189f48d) 17.37.02 # hi.. 17.38.00 # I've got a question.. where could i find an older build for ipod nano? 17.38.00 # ..lo :) 17.38.17 # you couldn't - you'd have to make one yourself. 17.38.25 # we don't archive them for very long at all 17.38.48 Quit Thundercloud (Remote closed the connection) 17.38.54 # there are archived builds -- about the last 4 weeks. 17.39.03 # where can i find them? 17.39.10 # on the website. 17.39.39 # yes but where? i can only find the current builds 17.39.44 # http://www.rockbox.org/daily.shtml 17.39.51 # click the "old" link under the Nano 17.40.00 # * bluebrother wonders if it's that hard to find the "Daily builds" link on the "current build" page. 17.40.16 # depends how lazy you are 17.40.32 # yeah, reading can be quite difficult ;-) 17.40.52 # hmmmmmmmmmmmmmmmmmmmmmmmmmmmm 17.40.53 # huh i dont see a daily build link under current build..=s 17.41.33 # aah now i see.. sry about that =) 17.41.57 # didnt know daily builds where older builds then the current.. 17.42.46 # so uhm thx guys 17.43.09 Quit AmbiquitY ("CGI:IRC (EOF)") 17.44.38 Part Hammer89 17.45.03 # * GodEater_ wonders when he'll be back to say "it didn't help" 17.45.33 Join n1s [0] (n=nils@nl104-209-90.student.uu.se) 17.48.42 # Arathis: I've never played a midi file on my H10 17.49.35 # bluebrother: in jewels.tex the complete button table is within an opt for each keypad, thus multiplying the tables. I prefer one table with the "opts" in each row and already rewrote it this way, however I had a small problem to work around (but commented it) - care to take a look? 17.50.02 # or maybe you have a different opinion... 17.51.05 Quit Rob222241 (Read error: 104 (Connection reset by peer)) 17.53.11 # barrywardell: okay ^^ 17.53.18 # I'll try other files then 17.53.25 # other midi files 17.53.26 # pixelma: sure. 17.54.40 # http://pastebin.ca/738719 17.54.52 # would be the new jewels.tex 17.56.10 # Arathis: if it's only one file it could be the midi itself, e.g. I also have one midi that completely freezes my M5 17.56.31 # Arathis: do you have a link to that file or could you send it to me? 17.57.05 # and also does it crash with a message or just lock up? 17.57.37 # pixelma: it works on my pc though and I haven't tested less than three files till I updated rockbox today (after about two month) 17.58.26 # pixelma: I'd be interested in that too, might be able to work something out 17.58.39 # Arathis: it's the same here - the file plays on my computer and my cellphone too 17.58.57 # n1s: I could send it to you, but would like to further test some other files first. and it crashes while my screen is already black so I'd need to switch backlight to "on" and test again 17.59.01 # pixelma: plays on your computer as in the rockbox sim? 17.59.22 # for me "plays on pc" means plays with timidity 17.59.46 # haven't tried that yet - plays in errmm... mediaplayer 18.00.06 # windows mediaplayer 18.00.18 # I'm a bit busy right now so it could take some time to test and respond 18.02.24 Quit jhMikeS (Nick collision from services.) 18.02.30 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 18.03.36 # n1s: just discovered that it plays on my M5 but it struggles at the begining (but not throwing buffer misses), wasn't patient enough... but it doesn't play right. Will send it to you, I think that's easier than to try explaining it here... 18.03.38 Join inomiad [0] (n=th@84-253-196-64.satp.customers.dnainternet.fi) 18.05.43 # anyone have idea if there's anyone working on 2nd gen nano port? i've been checking the site every now and then for a year, but no progress i guess? 18.06.19 # no one is working on it currently 18.07.38 # sniff :I 18.08.57 # * markun wonders how many new DAPs Bageder and LinusN will bring back home from China to port rockbox to.. 18.09.50 Join Thundercloud [0] (n=thunderc@resnet16.nat.lancs.ac.uk) 18.09.54 # hopefully 2nd gen nano ;) 18.10.26 # Only if you can break into Apple HQ and snaffle the encryption details.. 18.10.28 # :) 18.10.30 Join Crash91 [0] (n=evil91@196.218.80.108) 18.10.45 # and a few datasheets too if you have the time 18.10.53 # (assuming they even have them) 18.11.36 # it's really that different hardware, huh? 18.11.59 # very 18.12.01 # inomiad: yes, very different 18.12.06 # XavierGr: around? 18.12.11 # markun: They need something to do on the flight home.. 18.12.26 # one each, maybe 18.12.43 # linuxstb: let's hope they didn't forget to compile a blackfin toolchain :) 18.13.07 # Telechips is popular in China... 18.13.37 # yes, also 18.13.42 # and rockchip? 18.16.36 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.17.11 # okay, thanks for the info anyway, guess i'll have to live with default ipod firmware ;) 18.17.31 Quit inomiad () 18.21.13 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 18.22.44 # n1s: okay, I'm getting Buffer miss! for that file. But I had a Data abourt with another file followed by Buffer miss! although the file should be at it's end where that happens. 18.23.37 Quit linuxstb ("Client Exiting") 18.23.39 # Arathis: Buffer miss! is a performance issue only and known about, however a "Data abort" is bad 18.24.24 # does the Data Abort happen at the same position in the same file every time? 18.25.10 # I'll test 18.26.16 # Arathis: Might be worth trying in the sim too, if you can repro the crash. 18.26.37 Quit obo ("bye") 18.28.13 Join Rob2222 [0] (n=Miranda@p54B14410.dip.t-dialin.net) 18.29.09 # pondlife: later perhaps. I'd need to run vbox and build it first and as said am a bit busy 18.29.32 # Or pass the file onto one of us to try? 18.29.47 # Flyspray would be a good place 18.29.48 # .. mised the buffer miss :/ but it was at the same location in the same file and I haven't found it in another file yet 18.30.27 # s/'buffer miss'/'data abort' 18.31.56 Quit Crash91 ("Bye Bye!") 18.32.16 Part pondlife ("disconnected has pondlife") 18.32.18 # Arathis: could you give me a link to that file or send it to me? 18.32.36 # in a second 18.33.41 Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 18.34.38 # * ender` yawns 18.35.00 # n1s: port seems to be closed .. 18.35.15 # which models have fm tuners? 18.38.07 # preglow: around? 18.39.55 # n/m, found the list 18.40.56 # n1s: I'm getting the data abort after the last notes/final chord and it says "at 400C16C (0)" 18.41.06 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 18.41.16 # Arathis: thanks, I'll look into it 18.42.01 # I've noticed this from many people, but isn't it generally better to just ask whatever question you have, rather than saying "ping" "around?" etc. That way, the person has a chance to answer when he gets back (and you might not be there anymore) (this is not directed specificly at you, amiconn) 18.44.24 # <|Rain|> some things demand interaction, though... something sufficiently complex is frustrating to both parties if the message is lost in scrollback or not completely understood by the recipient (when the sender is now away instead) 18.44.27 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 18.44.28 Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) 18.45.54 Quit midgey (Client Quit) 18.46.13 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 18.47.26 # |Rain|: then something along the lines of "I want to talk to you about " 18.47.48 Join Domonoky [0] (n=Domonoky@e179181135.adsl.alicedsl.de) 18.48.05 # rasher: but then you just scare them off ;) 18.48.23 # Seeing a "Are you there?" in your scrollback is rather frustrating when that person is no longer there 18.49.03 # <|Rain|> it can be even more frustrating if you know what they want and WANT to talk to them about it :P 18.50.17 Quit GodEater (Remote closed the connection) 18.52.57 Join lazka [0] (n=lazka@85-124-46-239.dynamic.xdsl-line.inode.at) 18.53.04 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.54.14 Quit gromit` (Read error: 104 (Connection reset by peer)) 18.55.54 Join Blindbricks [0] (i=519c1f9d@gateway/web/cgi-irc/labb.contactor.se/x-6ddfe84abb263a8f) 18.56.00 # Hi guys 18.56.05 # A really quick question 18.56.25 # How can I open the original Ipod firmware with rockbox installed? 18.56.29 # is it possible? 18.56.30 Join gromit` [0] (n=gromit@ras75-5-82-234-244-69.fbx.proxad.net) 18.56.45 # hold menü while booting, i think.. 18.56.49 # yes, and the manual explains how 18.56.55 # It does? 18.56.58 # Ah good thanks 18.57.10 Join GodEater [0] (n=bryan@rockbox/staff/GodEater) 18.57.26 # I just installed today rather good 18.57.33 # Although I need to look into mpeg games 18.57.36 Quit Blindbricks (Client Quit) 19.11.39 *** Saving seen data "./dancer.seen" 19.11.55 Nick EnterUse1Name is now known as EnterUserName (n=dave@ip-218.55.99.216.dsl-cust.ca.inter.net) 19.13.26 Quit random_desu_is_s ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 19.18.29 # amiconn: am 19.18.51 # Nm, found the place where I went wrong meanwhile 19.19.10 # I thought the coldfire idct asm would be different from the C code that should resemble it 19.19.34 # (other than the different intermediate storage method), but it isn't 19.20.09 # really? 19.20.11 # i thought it was 19.20.38 # In mirak's patch there is new C code that resembles his asm 19.20.49 # right 19.21.00 # Btw, I already spotted 4 instructions which can be collapsed into 2 19.21.44 Quit sin613 (Read error: 113 (No route to host)) 19.21.59 # (in one of the matrix muls, two parts of each stroke are identical, so with trivial reordering, I can use a move.l %accX, %accY) 19.22.16 # ...replacing two mac.w instructions each 19.22.36 # goodie 19.24.37 Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) 19.29.35 Join SirFunk [0] (n=Sir@cpe-74-71-205-222.twcny.res.rr.com) 19.36.59 Join linuxstb [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) 19.37.55 Join sin614 [0] (n=single@71-32-29-45.farg.qwest.net) 19.45.01 Quit spiorf (Read error: 104 (Connection reset by peer)) 19.45.12 # Some further reordering allows filling almost all emac latency, and saving a couple of instructions 19.45.53 Join spiorf [0] (n=spiorf@host215-223-dynamic.1-79-r.retail.telecomitalia.it) 19.48.18 Join styleism [0] (n=etm101@87-194-104-214.bethere.co.uk) 19.48.52 # #rockbox-community 19.48.56 # sorry 19.49.23 # The row loop is just 68 instructions now :) 19.50.11 Part styleism 19.50.28 Join kkurbjun [0] (n=kkurbjun@alamode.Mines.EDU) 19.55.17 Join mirak [0] (n=mirak@m207.net81-66-74.noos.fr) 19.57.20 Join Lars_G [0] (n=Lars@unaffiliated/lars-g/x-000001) 19.57.23 # pondlife: I am here now 19.57.24 # Hi all. 19.57.36 # ah crap he is not here 19.57.44 # These here who listen to podcasts. What do you use to fecth and sync them? 19.59.20 # amiconn: idct optimizations? 19.59.23 # Juice to fetch, manual sync (only listen to a few...) 19.59.54 # ok, thanks lear 19.59.54 # i stick to google reader, only download things with interesting descriptions 20.02.58 Join ilgufo [0] (n=matteo@host100-185-dynamic.54-82-r.retail.telecomitalia.it) 20.05.05 Join atsea-34 [0] (i=atsea-@gateway/tor/x-66aec4112b41a718) 20.06.47 Quit ilgufo (Client Quit) 20.07.58 Quit petur ("connection reset by beer") 20.09.10 Part Lars_G 20.12.25 Join ilgufo [0] (n=matteo@host100-185-dynamic.54-82-r.retail.telecomitalia.it) 20.12.26 Quit japc (Read error: 110 (Connection timed out)) 20.16.48 Quit mirak (Remote closed the connection) 20.18.54 Join hannesd [0] (n=light@gate-hannes-tdsl.imos.net) 20.23.43 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 20.23.55 # I'm trying to fix a bug, but I get a confusing error message during compile 20.24.13 # I added lang.h to apps/plugins/lib/playback_control.c 20.24.52 # This is what I get http://pastebin.ca/738865 20.25.57 # * I mean I added #include "lang.h" to apps/plugins/lib/playback_control.c 20.26.39 # It is a problem with the build environment, not the code 20.26.53 Join WalterEgo [0] (n=noneofye@modemcable228.133-82-70.mc.videotron.ca) 20.27.16 # Beyond that, *shrug* 20.28.50 # ok maybe I'll try it under Linux, I have little hope though 20.29.48 # nicktastic: why do you think so? 20.31.14 # rasher, Because it is a make error, not a compiler error 20.32.18 # Adding a header or otherwise changing some code shouldn't throw make errors, excepting some weird auto-header-dependency-resolution madness 20.32.24 # I'm concerned about the *** No rule to make target line, not the modification time in the future 20.33.12 # Well, lang.h isn't your typical include file. It is generated during build. 20.33.36 # Again I should just keep my mouth shut ;) 20.35.44 # bertrik: You can't include any .h files in plugins apart from plugin.h. If you want access to what's in lang.h, you will need to export it via the plugin API. 20.35.46 # I realise I haven't tried a clean build yet, I'll try that first 20.36.07 # linuxstb: thanks 20.36.31 Quit XavierGr (Nick collision from services.) 20.36.34 Join XavierGr [0] (n=xavier@ppp145-163.adsl.forthnet.gr) 20.36.44 # i wondered already how the main firmware and plugins interacted 20.37.32 Join Zagor [0] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 20.44.32 # Is there any support for internationalisation at all for plugins? 20.46.26 Part sin614 20.46.27 # bertrik: don't think there is right now 20.48.01 # bertrik: I'm still confused about this. Is every endpoint bidirectional? i.e. both IN and OUT endpoints can receive requests from the host? 20.48.43 # AFAIK, endpoints are always unidirectional, except for EP0 20.49.06 # I find the USB spec a bit vague on whether endpoint numbers or endpoint addresses need to be unique 20.49.20 # yeah that's what I have assumed all along, only both usbmon (linux kernel usb snoop module) and the imx31 docs conflict with this 20.49.21 # (endpoint address = endpoint number | direction bit) 20.49.53 # "if endpoint 3 (transmit direction) is configured as a bulk pipe, then we can expect the host will send IN requests to that endpoint." 20.50.21 # Zagor: do you know where the pp specific code in the USB driver is and what needs to be written for the i.mx31 to get it working with the Gigabeat S? 20.52.43 # Zagor: USB is basically a polled system, every transfer (from host to device or vice versa) is always initiated by the host 20.52.46 Quit desowin ("use linux") 20.53.00 # markun: I think only the interrupt vector is pp specific 20.53.33 # bertrik: yeah I know. but I expected all request to come in at the same OUT endpoint. but they don't... 20.53.58 # Zagor: and maybe some defines for the addresses of the USB hardware? 20.54.04 # markun: ah, of course 20.54.18 # * bertrik is confused 20.54.32 # bertrik: guess what I am... 20.54.47 # but if it's only that, then the Gigabeat S should have USB shortly after you got it working 20.55.22 # Zagor: what kind of request do you mean? 20.56.09 # first packet of CBW? 20.56.27 # btw, this diff here (http://pastebin.com/m7359de0f) , the stuff that makes people happy, see the difference between the speeds 20.56.43 # is CPUFREQ_MAX used anywhere but as a label? 20.56.55 # bc the two changes arent same valued 20.57.13 # pll setup says 75 MHz whereas MAX 78 20.57.39 # That patch contains at least 2 bugs 20.57.51 # The one that you mentioned, and the actual pll setup 20.58.29 # yeah that one is hairy so I cant even comment on that 20.58.44 # The pp5022 pll must be run at >= 96MHz, and the post divider needs to be used for lower frequencies 20.58.52 # Zagor: I'm not familiar with the freescale controller so I don't really know when you get an interrupt 20.58.56 # It's actually not really dfficult 20.58.56 # bertrik: hmm, perhaps my problem is the reversed. I get the request on the OUT ep and writes my response to the IN ep, and that fails. 20.59.32 # OUT is from host-to-device, IN is from device-to-host 20.59.39 # And it's not a bug fix, it's just a workaround that sacrifices speed 20.59.50 # no, that's not it 20.59.57 # but, that aside, it works for me as well, if only I also set MAX define to 75 21.00.27 # what kind of endpoint setup does the original firmware use? 21.00.34 # so the pll control bit is just a divisor for the base clock running at 96 megs or such 21.00.49 # bertrik: same type 21.01.39 Nick bagawk_ is now known as bagawk (n=lee@unaffiliated/bagawk) 21.02.53 # Ave: No, the base clock is 24MHz 21.03.05 Quit SirFunk (Remote closed the connection) 21.03.30 # The pll can be programmed to produce an (almost) arbitrary frequency, using a multiplication and a division factor. 21.03.40 # This frequency must be >= 96MHz on PP5022 21.03.58 # Then a post divider can be applied, dividing that clock by 1, 2, 4 or 8 21.03.59 # ok so the control word has a divisor and multiplier bits 21.03.59 # do you have a link to the lsusb output of a sansa (sorry, no libusb installed on windows)? 21.04.31 # Zagor: yo, you have any idea how the limits stuff in the menu is supposed to work? you seem to have touched the code, and right now, the code uses the current value here and there without checking to see if there's actually enough room buffer_alloced 21.04.46 # ok that makes sense now 21.05.13 # Yes, plus some more 21.05.20 # * bertrik is installing libusb-win32 21.05.54 # bits 0..7 are the pll divider, bits 8..15 the pll multilpier 21.06.08 # bit 20..21 choose the post-divider 21.06.26 # bit 31 enables the pll 21.07.05 # For 75MHz cpu clock, you need to run the pll at 150 MHz, and post-divide by 2 21.07.40 # bertrik: I'll throw it up 21.08.02 # preglow: as best I can remember they were to be used to the initial buffer allocation at boot. 21.08.09 # Ah, the sansa DOES use two endpoint numbers, 0x01 and 0x82 21.08.31 # oh yes 21.09.41 # my sandisk usb drive does not, however. it uses 0x01 and 0x81 21.10.42 # Perhaps the PP usb has a limitation (read: bug) that using the same endpoint number for in & out doesn't work? 21.11.37 # Zagor: yeah, exactly, and the limits at boot where supposed to be used until next boot, right, not the current values? 21.11.42 *** Saving seen data "./dancer.seen" 21.11.47 # preglow: yes 21.11.56 # Zagor: there's a bug here currently, memory is corrupted, and i suspect it is because the current numbers are used here and there 21.12.06 # aha, badness 21.12.24 # only tree.c saves the the current number, plenty of other spots use the current number, but i don't know if any of them are able to do so safely 21.13.53 # Hmm, tree.c:348 looks bad... 21.14.55 Part sheppard 21.15.20 # Lear: i tried changing that to max_files, didn't work out 21.15.28 # Oh? 21.15.30 # i think the bug is in some other place 21.15.41 # Lear: at least i thINK i did so, i sometimes mess up 21.16.48 Join merbanan [0] (n=banan@83.233.242.209) 21.16.52 Quit ompaul (Client Quit) 21.17.15 # And you don't have any usage scenario to clue in to what it could be? 21.17.18 # anyway, to reproduce, just start out with a lower limit, raise it, and see some dir 21.17.34 # all the new files will not function, and the "open with" menu will be busted 21.18.35 # That only reproduces the bug if you have dirs with more files than the previous limit, right? 21.18.36 # amiconn: er ok so.. mul 25, div 4 and post 2 would work 21.18.41 Quit barrywardell (Read error: 110 (Connection timed out)) 21.18.51 # preglow: Using database in that case? 21.18.53 # Lear: no 21.19.05 # amiconn: well, yeah, i don't expect the buffer will overflow if not 21.19.18 # Lear: i've got database files, but not loaded to ram, and using only the file browser 21.19.24 # Well, tagtree.c:1189 looks bad, regardless. 21.19.27 # * amiconn didn't manage to exceed the limits for ages... 21.19.43 # My largest dir has a little less than 300 files 21.19.43 # i set it low 21.19.46 # to 200 21.20.18 # Ought to be filetree.c:223 in this case... 21.20.36 # yeah, what does ft_load really do? 21.20.43 # it says it's dircache related, but it always gets called 21.20.50 # Load a directory, I think... 21.21.21 # That dircache is not the firmware/dircache.c, I'm pretty sure, but rather the internal buffer, allocated in tree.c... 21.21.27 # ahh, right 21.21.31 # then i got confused 21.21.39 # but yeah, i can't test right now 21.21.51 # will do later 21.23.30 # Looks indeed like the problem. It handles the name cache properly, but not the array pointing into the name cache. 21.23.46 # bertrik: perhaps I'm just confused. here's some output from usbmon and kernel.log: http://bjorn.haxx.se/usbmon.txt 21.23.47 # in that case, i think this has been a bug for a long time 21.24.30 # the first two lines show the sucessful reception and ACK of the INQUIRY command 21.24.38 # Indeed. But I guess most users don't go about changing those limits very often... :) 21.24.44 # Zagor: this is your code interacting with Linux usb-storage? 21.24.51 # bertrik: yes 21.25.26 # Lear: i don't really know what i think about those settings, but then i guess i don't really like wasting memory when it can be helped 21.25.26 # nice 21.25.34 # the next four lines is my failed attempt at reponding with the INQ struct and csw. 21.25.56 # What helped me a lot, was to run the USBCV utility from usb.org 21.26.10 # (you need a high-speed hub for that) 21.26.32 # ...and windows :) 21.26.40 Quit billytwowilly (Remote closed the connection) 21.27.25 # looks good though 21.28.28 # yes, looks good, current problem is probably in the BOT protocol. low-level USB comms should be quite OK if you get this far 21.29.33 Join webguest97 [0] (i=50d81efc@gateway/web/cgi-irc/labb.contactor.se/x-4934435111cdd2d8) 21.32.40 # it seems bulk IN still doesn't work 21.33.47 # yeah. i'll try a separate number 21.34.31 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 21.35.37 Join SkinInd95 [0] (n=chatzill@host-69-144-93-208.hln-mt.client.bresnan.net) 21.36.38 Quit SkinInd95 (Client Quit) 21.36.56 # Zagor: you should hold the code ransom for a fundraiser period once you get it working 21.37.03 # haha 21.38.57 Quit midgey () 21.40.37 # no improvement with different numbers 21.41.57 # mmm, hard to say what's wrong 21.43.03 # I'll have a go at it tomorrow 21.43.31 # I think I'll browse a bit more through the Linux freescale code 21.44.28 # Zagor: that is also the base you used for your code, right? 21.45.01 # I looked at it, but nothing is copied 21.46.13 # Zagor: Google would have paid you $4000 if you were a student... 21.46.46 Join webguest02 [0] (i=4c407df0@gateway/web/cgi-irc/labb.contactor.se/x-8c3708b390e27f8a) 21.46.56 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 21.46.59 # hello? 21.47.51 Quit webguest02 (Client Quit) 21.49.00 # is that a new record? 21.49.04 Quit linuxstb (Read error: 104 (Connection reset by peer)) 21.49.30 # pixelma: not unlikely 21.49.38 Join linuxstb [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) 21.50.05 # The cgi:irc login screen should have a short notice about having patience 21.50.09 Join webguest43 [0] (i=4c407df0@gateway/web/cgi-irc/labb.contactor.se/x-307904340951d49c) 21.50.25 # oh... welcome back 21.50.31 --> "help" received from wlw (n=wlw@gw-colo-pa.panasas.com) 21.50.40 --> "join #panfs-client-push" received from wlw (n=wlw@gw-colo-pa.panasas.com) 21.51.03 Quit mf0102 ("Verlassend") 21.51.44 # is anyone here? 21.51.48 # no 21.51.53 # wel, I am 21.52.03 # speak for yourself! 21.52.03 # can i get some help with my ipod? 21.52.10 # im having trouble rebooting it 21.52.14 # what kind of help do you need? 21.52.28 # webguest43: well, is it frozen, or do you just want to shut it down? 21.52.45 # well, i had just put on some new icons to my ipod. and i put it in my charger 21.52.54 # then when i went to turn it back on, it wouldnt boot 21.53.05 # hold select and menu 21.53.15 # tried that 21.53.23 # webguest43, might the battery be empty ? 21.53.35 # if its plugged it, i get the battery icons with a lightning bolt 21.53.39 # but i cant do anything 21.53.41 # turn hold on and off, then hold menu and select for up to a min 21.55.05 # i tried that, and it flashed the screen 4 times but still at the same screen 21.55.24 # i tried putting it into disk mode, but it went to the same screen 21.56.57 Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 21.58.19 # if I unplug the ipod, and go into the diaognostics menu, i can chose diskmode, but it just goes back to the same screen 21.58.35 # could it be a bootloader problem? 21.59.10 # define "same screen" 21.59.30 # screen that has a lightning bolt next to a battery icons 21.59.36 # but it doesnt seem to be charging 21.59.47 # its an ipod colour if that helps at all 22.00.56 Quit newbyx86 () 22.01.19 # ehe, if I stop being stupid bulk IN works when it gets a separate number 22.01.19 Quit webguest97 ("CGI:IRC (EOF)") 22.03.11 Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 22.04.25 Quit homielowe (Read error: 110 (Connection timed out)) 22.05.29 # any ideas what could have gone wrong? im suspecting the bootloader, because the rockbox firmware is default so the ipod would try that first, then if theres a rockbox error it just stops loading at the apple screen. however, if i have the hold switch on while i reboot, it just halfboots then tries that again, and again, etc 22.06.08 # Are you doing this with the charger connected? 22.06.27 # what i just said?, no 22.06.39 # Zagor: was just a silly mistake? 22.06.44 # yes.. 22.06.56 # webguest43: Have you tried this: " turn hold on and off, then hold menu and select for up to a min" without the charger connected? 22.06.56 # webguest43: if you cant get into disc mode, then something else is wrong 22.06.59 # the quick test hack was a bit too quick 22.07.33 Nick Tanuva is now known as Tanuva|Zzz (n=tanuva@83.220.128.10) 22.07.48 # so back to usb-storage fixing now 22.08.03 # ok, now it wont even do what i said 22.08.08 # if i unplug it 22.08.12 # and hold menu and select 22.08.36 # ...and turn the hold switch on and off? 22.08.40 # it shows an icon with a battery and an excelmation mark inside a trianglur box 22.08.41 # * preglow puts champagne in freezer 22.08.57 # webguest43: do it again then 22.09.44 Join major_works [0] (n=a08e9562@63.173.19.18) 22.10.09 # does the icon meen theres something wrong with my battery? 22.10.12 # or that its low power 22.10.45 # also, if i plug it into my computer, my pc wont recognise it, its not even shown under my computer 22.10.51 # linuxstb: eh, doesn't wma get the metadata in the usual way? 22.10.54 # webguest43: Have you tried this: " turn hold on and off, then hold menu and select for up to a min" without the charger connected? 22.11.01 # yes 22.11.13 # And you held menu and select for a long time? 22.11.16 # yes 22.11.23 # ill even try it agian 22.11.27 # plugged in or not? 22.11.32 # not 22.11.35 # k 22.11.37 # How long would your battery last on an average day, before this? 22.11.54 # preglow: What do you mean? 22.12.02 # linuxstb: i can't see any case for it in metadata.c 22.12.13 # in get_metadata() 22.12.14 # asf... 22.12.48 # i don't see any entries for that either 22.12.51 # 4hours, in rockbox doing games and stuff. in apple OS, not exactly sure (long time though) 22.12.53 # wtf 22.12.56 # it's here... 22.13.07 # * preglow looks at vim with suspicion 22.13.28 Join qweru [0] (n=kvirc@bb-87-80-66-156.ukonline.co.uk) 22.13.37 # as you should. 22.13.46 Nick parafin is now known as parafin|away (i=parafin@paraf.in) 22.13.58 # linuxstb: doesn't look like filesize member is filled 22.14.40 Join _michael [0] (n=michael_@S01060004ac9d9e11.su.shawcable.net) 22.14.41 Quit amiconn (Nick collision from services.) 22.14.43 Join amiconn [0] (n=jens@rockbox/developer/amiconn) 22.15.05 # preglow: Hmm... Will you fix? 22.15.15 Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") 22.15.42 # linuxstb: sure, i'll just stuff the usual filesize = line somewhere in get_asf_metadata 22.18.15 # arghghg 22.18.35 # i get a bloody error in settings_list.c when applying/unapplying the scrollwheel accel patch 22.18.46 # there is a dependency problem here somewhere 22.18.59 # a make clean fixes it 22.19.05 # Your dependency on beer? 22.19.06 # ah 22.19.07 # seems there's some trouble with voice ids 22.19.27 Quit nicktastic ("Leaving") 22.19.36 # hey, i can quit drinking anytime i want to!!!!11! 22.21.03 # but you don't want to of course :) 22.21.03 # should i just leave my ipod connected to the charger and see what happens in a couple of hours? 22.21.07 Quit merbanan (Remote closed the connection) 22.21.19 # preglow: did you see we had fun with belgian beers in NY? 22.21.36 # markun: i did not... 22.21.46 # http://www.rockbox.org/twiki/bin/view/Main/RockboxNYC 22.21.56 # the attached picture 22.22.17 # webguest43: try that 22.22.21 # daamn, i want one of those glasses :P 22.22.24 # been looking for them for ages 22.22.35 # stella or chimay? 22.22.51 Join petur [0] (n=petur@rockbox/developer/petur) 22.23.07 # petur: was is the beer trigger which brought you here? :) 22.23.11 # chimay 22.23.18 # s/is/it/ 22.23.30 # no, my car.. just got home 22.24.23 # so your car triggers on beer talk on irc now? :P 22.24.33 # yes 22.26.19 # ONTOPIC! :p 22.26.39 # should i just leave my ipod connected to the charger and see what happens in a couple of hours? 22.26.44 # devs always talk on tpic :p 22.26.57 # topic even 22.27.09 # isn't beer a topic in here? ;) 22.27.15 # damn straight it is 22.27.30 Join lee-qid [0] (n=liqid@p549646EB.dip.t-dialin.net) 22.30.01 Quit ompaul ("restarting client - new config") 22.30.36 Join ompaul [0] (n=ompaul@gnewsense/friend/ompaul) 22.31.20 # In PERL, can't you do this: my ($foo, $bar) = function(); sub function { return ("foo", "bar"); } #? 22.31.54 # I'm seeing some strange behavior 22.32.07 # you can, AFAIK 22.32.10 # yes you can 22.32.20 # oh right... I think I know.. It's something to do with lists collapsing in strange and frustrating ways 22.32.40 # That's come to bite me in my buttocks 22.33.20 Join newbyx86 [0] (n=newby@ip68-7-12-123.sd.sd.cox.net) 22.34.21 # really? what you're doing there is just fine 22.34.34 # Well my code is not quite as simple 22.35.09 # I'm trying to return two hashes and two scalars (really LibXML::Element objects) 22.35.25 # And perl is having none of it 22.36.09 # so guys, any idea what idea could be wrong with my ipod? 22.36.10 # you're returning them by reference? 22.36.17 Quit webguest43 ("CGI:IRC") 22.36.32 # preglow: I think not.. I'm on that lead.. how do I do that? 22.36.40 # i don't know that you can return several hashes or lists without doing so by reference 22.37.01 # know what, i don't really remember, i haven't used perl for years, even though i wished i had opportunity to do so :/ 22.37.10 # \%hash and \$element 22.37.19 # Well that's deceptively simple 22.37.34 # And how do I access them, then? 22.37.37 # yeah, then do my ($hash1, $hash2) = function(); and %$hash{element1}; 22.37.37 # i think 22.37.47 # $$elementref 22.37.51 # ahh 22.37.52 # of course 22.37.58 # i love perl, but i just haven't had anything to use it for :/ 22.38.25 # Looks like I can do \($element, %hash) 22.38.27 Quit kubiix (Read error: 104 (Connection reset by peer)) 22.38.30 # If I'm reading this right 22.38.39 # yes 22.38.40 # well, that just makes a reference to an anonymous list 22.38.44 # and returns that 22.38.58 # which is fine 22.43.20 Join BigBambi_ [0] (n=Alex@rockbox/staff/BigBambi) 22.43.49 Quit ompaul (Client Quit) 22.44.46 # preglow: the problem with lang/voice ids appears when the enabled features for a target is changed. that dependency would require rebuilding almost all of apps/ when either features.txt or the config-*.h fiel changed for your target 22.45.12 # But as makefiles don't cooperate with me... 22.45.28 # pixelma: sorry, didn't got around looking at the latex paste earlier 22.45.46 # feel free to improve :) 22.45.49 # but I haven't found a better solution. I guess opt is doing some things here. 22.46.35 # I should find the time to read the latex book completely and understand the opt package -- but I don't think I'll find time to do this 22.47.05 # I tried quite a few possibilities and most of the times the output of latex wasn't very helpful - the most out of it I got was something about the bottomrule 22.47.32 Quit spiorf (Read error: 110 (Connection timed out)) 22.47.49 Quit major_works ("major_works has left the building...") 22.48.15 # So now I get: Can't call method "getElementsByTagName" on unblessed reference at ./genlangxml line 231. 22.48.25 Join spiorf [0] (n=spiorf@host9-204-dynamic.0-87-r.retail.telecomitalia.it) 22.48.43 # I know I need to use bless($input, ), but what that something is.. 22.49.05 # (this is for my xml for language files experiment - not just any off-topic chatter) 22.49.42 # I've never bothered with object-oriented perl, so I can't help you there 22.50.04 # I'm beginning to understand that decision.. 22.51.05 # n1s: right 22.52.57 Quit davina (Remote closed the connection) 22.55.02 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 22.55.41 Quit _michael ("Kopete 0.12.4 : http://kopete.kde.org") 23.01.56 Quit BigBambi (Read error: 110 (Connection timed out)) 23.03.22 Quit hcs (Read error: 113 (No route to host)) 23.04.30 Join eigma [0] (n=cat@216.48.162.210) 23.04.36 Join contxt [0] (n=jac0b@user-1120iq8.dsl.mindspring.com) 23.05.00 Part contxt 23.05.19 Join jac0b [0] (n=jac0b@user-1120iq8.dsl.mindspring.com) 23.05.31 # phew, 575 lines asm file ... 23.05.49 # I am going to post my how-to for the gigabeat battery 23.05.58 # jac0b: looking forward to it 23.06.05 # should I make a new page or add it to the already gigabeat page 23.06.09 # new page 23.06.24 # GigabeatBatteryMod or something? 23.06.45 # do I have rights to make a new page? 23.06.45 # maybe Upgrade instead of Mod 23.06.51 # do you have write access? 23.07.01 # I have a wiki username 23.07.09 # well, you need write access too 23.07.13 # what's your wiki name? 23.07.31 # JacobBrooks 23.07.36 Quit eigma (Client Quit) 23.07.38 # ok, I'll add you to the list 23.07.42 Quit ToHellWithGA (Nick collision from services.) 23.07.44 # thanks 23.07.46 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 23.07.51 Join ToHellWithGA [0] (n=ryan@p1-33-rb5.clm.centurytel.net) 23.08.16 # Does anyone have a Gigabeat S series? 23.08.55 # jac0b: ah, you already are in the list.. 23.09.01 Quit davina (Remote closed the connection) 23.09.03 # jac0b: yes 23.09.43 # * preglow _finally_ has low-latency audio in linux 23.09.54 # markun: how do I create a page 23.10.09 Join eigma [0] (n=cat@216.48.162.210) 23.10.24 # jac0b: just enter the address you want to create 23.10.29 # jac0b: go to the URL and click "create" http://www.rockbox.org/twiki/bin/view/Main/GigabeatBatteryUpgrade 23.10.38 # does someone actually have the powers to correct commit messages (Zagor)? 23.10.38 # I was wondering if I could get a person with a S series to try out this battery thing I ahve done with the F series 23.10.58 # jac0b: why don't you ask toffe82? 23.11.07 # jac0b: the battery on the S is thinner 23.11.09 Join advcomp2019 [0] (n=advcomp2@66.172.231.192) 23.11.10 # pixelma: we all do, no? i think the svn admin command lets you 23.11.27 # It has to be enabled on the server side 23.11.29 # * rasher wrestles some more with perl refs 23.11.34 # ...but currently isn't 23.11.42 # I thought there was something not set up right? 23.11.44 *** Saving seen data "./dancer.seen" 23.11.48 # toffe82: hmm well on ebay they were saying a battery for the gigabeat could fit a S series and a F series 23.12.38 # jac0b: I don't think that the battery of the F fit in the S, I will have a closer look tonight if I have time 23.13.17 # preglow: do you know, if I have a reference to a hash, how do I get a specific value? $$hash{'foo'} doesn't seem to work 23.13.27 # jac0b: he has a big collection of various gigabeats :) 23.13.28 # jac0b: if one is good for the S, it is good for the F 23.13.33 # toffe82: okay cool, also check the description on this http://cgi.ebay.com/Replacement-for-Toshiba-GigaBeat-S30-Battery-1000mAh_W0QQitemZ320168639862QQihZ011QQcategoryZ118262QQssPageNameZWDVWQQrdZ1QQcmdZViewItem 23.14.16 # it says the F and S series 23.15.10 # perhaps it is a the same domension as the one of the S, so it fit on the F without problem 23.15.22 # rasher: it should 23.15.39 # markun: should I make a topic parent? 23.15.41 # rasher: $hashref->{'foo'} will also work 23.15.49 # rasher: but $$hashref{'foo'} should be just as fine 23.16.02 # jac0b: maybe GigabeatInfo ? 23.16.34 # rasher: so i guess you haven't really got a hash reference after all 23.16.53 # preglow: not entirely unlikely, I must admit 23.17.17 # try printing the reference variable 23.17.17 # Ah, there we go. 23.17.25 # it should say "HASH(XXXXX)" if it is a hashref 23.17.34 # A series of stupid mistakes lined up 23.17.42 # the best kind of lineup 23.17.45 # (such as not quoting a $ in a debug message) 23.18.28 Quit Domonoky ("Trillian (http://www.ceruleanstudios.com") 23.25.07 Quit petur ("Zzzzz") 23.25.12 Quit hcs ("Leaving.") 23.27.53 # I take it the order of strings in the binary languagefiles doesn't matter? 23.28.18 Quit eigma () 23.29.29 # It does matter 23.29.38 # Hmm, or not 23.29.50 # I'm probably confusing something here 23.30.25 # * amiconn is busy with cf asm 23.30.29 # Seeing as their ids are written into the languagefile, it seems reasonable that oder doesn't matter, but I'm a bit afraid of digging into the language-loading code, so if anyone knew, that'd be helpful 23.30.48 # (numeric ids, generated from the English language file) 23.30.57 # The good news is that the asm function already decodes well... :D just move the dct block to iram now 23.31.29 # amiconn: performance figures! :P 23.33.43 # Okay, I'm pretty certain order doesn't matter. I'll not waste my time trying to retrieve the elements from the xml document in a specific order, then - something libxml seems unwilling to do, unless I'm missing something 23.34.07 # language_strings[id] = ptr .. That looks reasonable 23.35.07 # rasher: as long as the ids correspond to the ones in lang.c i guess you should be safe 23.35.39 # n1s: that should happen automagically, with any luck 23.36.36 # that caused a couple of fun bugs with the v2 conversion where the binary file got a gap in the ids so it got out of sync at a certain id 23.36.41 # We'll see once I attempt building with this system.. 23.36.50 # Hmm, less than expected :/ 23.40.08 Join Diamondiceman200 [0] (i=c35d1584@gateway/web/cgi-irc/labb.contactor.se/x-492a7acc76b46148) 23.40.44 # Hi 23.40.47 Quit lee-qid ("aufwiederbyebientotsayonara") 23.40.53 Quit jgarvey ("Leaving") 23.41.31 # how do you use the recording function on the iPod 60g? 23.45.03 # jac0b: how's it going with the wiki? 23.45.42 # markun: just have to post some pic 23.46.02 # Hrr.. libxml is inexplicably converting my wonderful utf-8 into what I can only assume is latin-1 23.47.54 # rasher: libxml stores all strings as utf-8 - at least, that's my experience with it. Are you using the Perl wrapper though/ 23.47.56 # ? 23.48.03 Quit billytwowilly (Remote closed the connection) 23.48.24 # preglow: With just the idct buffer in iram I'm above realtime on X5 now 23.48.40 # (for widescreen) 23.48.41 # linuxstb: I am, yes. Anything I need to look out for? 23.48.43 Quit bertrik ("off to read a book") 23.48.46 # 32..33 fps 23.49.20 # I'll experiment with the whole decoder struct in iram, but I need to sacrifice some iram somewhere else then... 23.49.25 # Both $doc->encoding and $doc->actualencoding return UTF-8, but when I print a textnode it ends up as latin-1 23.49.31 # ...otherwise it won't compile for MCF5249 23.49.50 # And the actual file is indeed utf-8 23.50.11 # Fullscreen is around realtime (24..25fps) 23.50.56 # On H300, widescreen struggles... around 18fps 23.51.32 # amiconn: was the H300 OF 10 of 15fps? 23.51.37 # 10 23.51.48 # rasher: I don't know, I've never used the Perl wrapper, just the native C. 23.51.49 # Didn't try fullscreen on H300 yet 23.53.16 # linuxstb: dang.. it's really very strange. It's an xml file I wrote using libxml itself (constructed from a non-xml langfile) 23.55.59 # toffe82: do you have a good gigabeat F frontplate? 23.57.47 # Zagor, so I hear success? 23.58.43 Join freqmod [0] (n=freqmod@m050g.studby.ntnu.no) 23.58.44 Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 23.58.53 # keanu: yeah it's going ahead step by step.