--- Log for 25.08.114  Server: verne.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 5 days and 23 hours ago

00.04.01 Join    PaulFertser [0] (paul@paulfertser.info)
00.04.44 Quit    trampel (Quit: Leaving)
00.09.25 Quit    pamaury (Ping timeout: 245 seconds)
00.09.59 #       <[Saint]> Hmmmmm. Is it just me, or is git head Android not displaying embedded AA?
00.11.27 #       <RiD> brb
00.11.33 Quit    RiD (Quit: A good plan today is better than a perfect plan tomorrow.)
00.13.55 Quit    Cinos (Disconnected by services)
00.14.43 Join    Cinos [0] (Cinos@cinos.biz)
00.14.57 ***     Saving seen data "./dancer.seen"
00.24.29 Quit    TheGuyWhoIsTheGu (Read error: No route to host)
00.26.23 Join    TheGuyWhoIsTheGu [0] (~androirc@modemcable045.77-163-184.mc.videotron.ca)
00.35.04 #       <[Saint]> bah.
00.35.13 Quit    ender (Quit:  I think I remember an episode of MacGyver where he overthrew a violent dictator with a rubber band, 2 bottle caps, and some navel lint.)
00.35.16 #       <[Saint]> make install for the sdlapp is a bit braindead.
00.35.27 #       <[Saint]> not like the other "make *" commands.
00.35.48 #       <[Saint]> it won't issue a make itself if one wasn't issues explicitely.
00.38.54 #       <[Saint]> TheGuyWhoIsTheGu: just to make sure I wasn't inadvertently telling lies - I just made sure to recompile clean copies of both the sdlapp and android binaries.
00.39.01 #       <[Saint]> Everything works as expected.
00.41.09 #       <TheGuyWhoIsTheGu> I downloaded today's build of rockbox and I'm updating my database I'll apply the theme after
00.41.37 #       <franklin> Is it preferable to have for loops start counting at 1 and go to n, or from 0 to n-1?
00.41.52 #       <franklin> ... in the RB codebase
00.42.49 #       <[Saint]> Typically, in Rockbox, we'll start at 1 and count up to N and use 0 for an unknown.
00.43.07 #       <[Saint]> But you'll certainly be able to find contradictions to this.
00.43.32 Join    RiD [0] (~RiD@bl22-53-235.dsl.telepac.pt)
00.43.34 #       <franklin> hmm... so like for(int i=1;i<=num_loops;++i)?
00.43.49 #       <franklin> instead of the "sane" way of for(int i=0;i<num_loops;++i)?
00.44.47 #       <franklin> really?
00.45.18 #       <franklin> I can hardly find any 1-based counting... except superdom, which is a nightmare of a plugin
00.46.40 Quit    jhMikeS (Ping timeout: 260 seconds)
01.06.44 #       <[Saint]> RiD: you can't load a portrait theme on a landscape binary.
01.06.45 #       <[Saint]> No.
01.06.55 #       <RiD> hehe
01.06.59 #       <[Saint]> ~80% of it will be out of bounds and fail to parse.
01.07.10 #       <RiD> guess i'll have to recompile rockbox
01.07.16 #       <[Saint]> indeed.
01.07.17 #       <RiD> is it as easy as changing two valeus, though?
01.07.21 #       <RiD> values*
01.07.44 #       <RiD> not the recompiling part - but the making it "portrait" part
01.09.32 #       <TheGuyWhoIsTheGu> [Saint] : Don't fprget us on the community channel :)
01.09.57 #       <[Saint]> I'm trying to move all this offtopic talk out of here.
01.10.02 #       <[Saint]> *there
01.10.19 #       <TheGuyWhoIsTheGu> Oh ok good
01.11.26 Join    krabador [0] (~krabador_@unaffiliated/krabador)
01.12.27 #       <franklin> anything rockbox-related should be here
01.12.31 #       <franklin> for future reference
01.19.12 #       <TheGuyWhoIsTheGu> Oh ok
01.19.27 Quit    PaulFertser (Ping timeout: 272 seconds)
01.19.56 #       <franklin> and vice-versa
01.20.08 #       <TheGuyWhoIsTheGu> Well I found a simple name for the theme :Cabbie Touch
01.20.43 #       <[Saint]> kinda implies the existing cabbie isn't touch enabled.
01.20.48 #       <[Saint]> which is a fallacy.
01.20.56 #       <TheGuyWhoIsTheGu> This theme could be a standard for touch devices
01.21.14 #       <TheGuyWhoIsTheGu> Like Cabbie v2 is for most of the devices
01.21.28 #       <[Saint]> *all
01.21.50 #       <franklin> what about archos?
01.22.03 #       <[Saint]> What of them?
01.22.11 #       <franklin> do they use cabbie too?
01.22.22 #       <[Saint]> Yes.
01.22.35 #       <franklin> ah
01.22.56 #       <TheGuyWhoIsTheGu> Your theme is just amazing! It raises the bar for theme makers and how Rockbox is used.
01.25.02 Join    PaulFertser [0] (paul@paulfertser.info)
01.31.34 #       <[Saint]> RiD: also - no - no its not that easy.
01.31.41 #       <[Saint]> Sorry for the delayed answer.
01.31.55 #       <RiD> ok, thanks
01.32.05 #       <[Saint]> you can't just flip x and y around to make it portrait/landscape.
01.32.14 #       <[Saint]> you'll need to force it in the platform config.
01.32.33 #       <RiD> uh, where is that?
01.33.18 #       <[Saint]> firmware/export/config/android.h
01.33.22 #       <[Saint]> add:
01.33.29 #       <[Saint]> #define CONFIG_ORIENTATION SCREEN_PORTRAIT
01.33.45 #       <RiD> Eh, I got the 3.12 maemo port source code
01.33.58 #       <RiD> no android.h in that directory
01.34.07 #       <RiD> nvm. im blind
01.34.18 #       <RiD> forgive my inferiority!
01.34.49 #       <[Saint]> Ah, this is maemo?
01.34.52 #       <[Saint]> Sorry.
01.35.15 #       <[Saint]> firmware/export/config/nokian900.h
01.35.17 #       <RiD> but i foud 
01.35.18 #       <RiD> that
01.35.42 #       <[Saint]> yeah - sorry, I assumed Android. Editing the android config for maemo won't do squat.
01.36.05 #       <RiD> haha, i maybe thought it was named android just "because". anyways
01.36.15 #       <RiD> there's lcd width and height, flipping won't do?
01.36.53 #       <[Saint]> No. It'll keep the same orientation but fuck up because it'll be out of bounds.
01.37.08 Quit    xorly (Ping timeout: 250 seconds)
01.37.25 #       <RiD> Eh, i don't think that's the issue
01.37.41 #       <RiD> i can force the *current* maemo rockbox to portrait
01.37.49 #       <RiD> but obviously, only about half the screen is filled with stuff
01.40.51 #       <[Saint]> Either way, you'll need to pass this define to tell the host that we want Rockbox to run in a portrait orientation on this device.
01.41.13 #       <[Saint]> We use it for targets where we use a different orientation than the OF does.
01.41.52 #       <RiD> alright, any other change needed?
01.42.19 #       <[Saint]> Nope. That should be entirely sufficient.
01.42.28 #       <RiD> alright, let's see
01.42.31 #       <RiD> thanks for your help!
01.46.54 #       <[Saint]> don't thank me unless it works. :)
01.47.37 #       <RiD> hehe. First I need to find links to the maemo sdk that aren't 404d
01.47.54 Join    jhMikeS [0] (~jethead71@c-68-43-2-35.hsd1.mi.comcast.net)
01.47.54 Quit    jhMikeS (Changing host)
01.47.54 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
01.49.04 #       <[Saint]> Aha, yeah, it is as simple as I thought.
01.49.18 #       <[Saint]> #ifndef CONFIG_ORIENTATION
01.49.18 #       <[Saint]> #if LCD_HEIGHT > LCD_WIDTH
01.49.18 #       <[Saint]> #define CONFIG_ORIENTATION SCREEN_PORTRAIT
01.49.18 DBUG    Enqueued KICK [Saint]
01.49.18 #       <[Saint]> #elif LCD_HEIGHT < LCD_WIDTH
01.49.18 #       <[Saint]> #define CONFIG_ORIENTATION SCREEN_LANDSCAPE
01.50.09 #       <[Saint]> tl;dr version: if not set explicitely in the platform config, make (99% of the time valid) assumptions based on screen dimensions.
01.51.16 #       <RiD> i wonder what would happen if i set the lcd height bigger than it actually is
02.03.12 #       <franklin> RiD, it would look weird :)
02.03.38 #       <RiD> hehe. actually, i think one of the earlier rockbox ports to maemo was running on 640x480 or so
02.03.47 Quit    PaulFertser (Ping timeout: 272 seconds)
02.04.25 #       <RiD> so maybe if i made it 800x800, and then adjusted themes, switching between landscape and and portrait would work without different binaries
02.04.48 #       <RiD> but i'll have a lot of time to break rockbox tomorrow
02.05.09 #       <RiD> as long as building it doesn't take a whole day
02.06.19 #       <[Saint]> Or, more likely, the framebuffer will puke and it'll just never ever load.
02.06.34 #       <RiD> hehe
02.06.51 #       <RiD> a man can dream
02.09.12 Join    PaulFertser [0] (paul@paulfertser.info)
02.14.58 ***     Saving seen data "./dancer.seen"
02.23.25 Quit    PaulFertser (Ping timeout: 272 seconds)
02.38.15 Nick    franklin is now known as Franklin (~franklin@unaffiliated/franklin)
02.40.28 Join    ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249)
02.42.06 #       <ploco> how to abandoned an open gerrit change? 
02.43.34 #       <Franklin> log in, click "abandon change"
02.43.37 Nick    Franklin is now known as franklin (~franklin@unaffiliated/franklin)
02.44.00 #       <jhMikeS> 1) walk away from computer 2) never use it again
02.44.26 Join    PaulFertser [0] (paul@paulfertser.info)
02.44.27 #       <ploco> I just killed g922
02.44.30 #       <fs-bluebot> 3Gerrit review #922 at http://gerrit.rockbox.org/r/922 : 3two new DSPs by Chiwen Chang
02.44.37 #       <franklin> why
02.44.39 #       <franklin> ?
02.45.52 #       <ploco> cause from jhMikeS 's feedback " I wouldn't be caching the those values in global variables like that"  theres hidden risk
02.46.07 #       <ploco> whixh it might F the whole thing up
02.46.13 #       <jhMikeS> well, that can be corrected
02.46.29 #       <franklin> and that's the point of being able to upload new patch sets :)
02.47.14 #       <ploco> jhMikeS: you didn't point me to the potential errors in code man.  
02.47.45 #       <franklin> you can still open a new change
02.48.10 #       <franklin>                              
02.48.43 #       <jhMikeS> you should use the dsp parameter passed to the configure at the time, not a cached pointer and pass it to functions that are associated with that dsp instance
02.49.37 #       <jhMikeS> ploco: was trying to do that
02.52.47 #       <ploco> fout, id,  dsp_filter.  which one? 
02.53.03 #       <franklin> dsp_config pointer
02.54.04 #       <jhMikeS> dsp_filter is fine, it's the other two being cached that way that could cause issues
02.54.16 #       <franklin> ah never mind
02.54.17 Nick    SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73)
02.55.35 #       <ploco> aya, they are private functions.  but i can fix it up
02.56.22 #       <ploco> i mean the caller are private functions that only exist inside this dsp code 
02.57.24 #       <franklin> Superdom is ifdef spaghetti
02.57.25 #       <jhMikeS> true, but the framework calls configure, possibly for reasons not related to a particular DSP, like at boot
02.57.43 #       <jhMikeS> so, global inits and such
02.58.21 #       <jhMikeS> also, how will this handle mono?
02.59.05 #       <jhMikeS> maybe doesn't matter for this
02.59.59 Quit    AlexP (Remote host closed the connection)
03.00.09 #       <ploco> hmm...it's not mono ready
03.04.13 #       <franklin> jhMikeS, would you mind me pushing a massive patch that fixed superdom completely?
03.04.20 #       <franklin> or do it in little patches
03.05.12 #       <jhMikeS> I'm fine with big patches personally if it fixes a bunch of issues with something.
03.05.33 #       <franklin> tell saratoga :)
03.05.50 #       <jhMikeS> I'd describe just what is covered in reasonable detail though
03.05.56 #       <jhMikeS> in the commit message
03.05.56 #       <franklin> yeah
03.08.48 #       <jhMikeS> which reminds me I have an almost 1MB patch to push if I could get rid of the final issues with the bitswapping crap (conflicts in android).
03.09.24 #       <franklin> don't even remind me of g#908
03.09.31 #       <fs-bluebot> 3Gerrit review #908 at http://gerrit.rockbox.org/r/908 : 3Cleanup whitespace and made indentation consistent across the code by Franklin Wei
03.09.40 #       <franklin> ... 90KLOC patch
03.09.58 #       <jhMikeS> and what's really stupid is that the bitswap macros from the host can't be used in static initializers but ours can (I don't know why they goofed that one)
03.10.24 #       <franklin> soo... maybe 90KLOC patches aren't that good of an idea :)
03.10.32 #       <franklin> just impossible to review
03.10.39 #       <jhMikeS> sure they use __builtin_constant_p but then use statement expressions which really shouldn't be needed for that
03.12.33 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
03.12.33 #       * franklin is looking at a freeze in his modified superdom
03.13.07 #       <jhMikeS> but my patch isn't 90k loc but it looks bigger than it is because of a rename which then touches alot of files
03.13.19 #       <franklin> mine really was :)
03.13.32 #       <franklin> got rejected in /exactly/ 3 hours
03.16.43 #       <jhMikeS> ploco: you were declaring the array size as CODEC_IDX_AUDIO+1, which is an array size of 1 :)
03.17.03 Join    Misanthropos [0] (~Misanthro@frnk-5f742f9a.pool.mediaWays.net)
03.18.46 #       <franklin> macros are great sometimes... and downright annoying other times
03.18.55 #       <franklin> for example, in superdom!
03.19.58 #       <ploco> jhMikeS: did that cause looks fancy.lol
03.21.16 #       <jhMikeS> ploco: dsp_core.c is where to go if you want the gritty details of what's expected (and so it may be modified without breakage). it's only 527 lines, so not so much
03.28.21 Quit    franklin (Quit: Leaving)
03.35.11 Quit    HeadWhacker (Ping timeout: 246 seconds)
03.41.55 Quit    jhMikeS (Ping timeout: 240 seconds)
03.42.17 Join    ygrek [0] (~user@108.59.6.97)
03.43.29 Quit    ploco (Quit: Page closed)
03.44.50 Quit    krabador (Quit: Take the time.)
03.56.23 Quit    bcobco ()
04.11.42 Quit    pixelma (Disconnected by services)
04.11.44 Join    pixelma_ [0] (pixelma@rockbox/staff/pixelma)
04.11.46 Nick    pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma)
04.12.02 Join    amiconn_ [0] (quassel@rockbox/developer/amiconn)
04.12.02 Quit    amiconn (Disconnected by services)
04.12.06 Nick    amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04.14.59 ***     Saving seen data "./dancer.seen"
04.25.28 Quit    TheGuyWhoIsTheGu (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
04.35.12 Join    cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)
05.07.11 Quit    Misanthropos (Ping timeout: 255 seconds)
05.08.31 Join    steffengy [0] (~quassel@p57B49B87.dip0.t-ipconnect.de)
05.11.26 Quit    steffengy1 (Ping timeout: 246 seconds)
05.21.25 Nick    DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73)
05.42.22 Quit    the-kyle (Ping timeout: 245 seconds)
05.47.42 Quit    RiD (Quit: A good plan today is better than a perfect plan tomorrow.)
05.48.39 Quit    TheSeven (Ping timeout: 272 seconds)
05.49.46 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06.05.44 Join    the-kyle [0] (~kyle@kyle.tk)
06.15.00 ***     Saving seen data "./dancer.seen"
07.16.36 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
07.27.36 Join    mortalis [0] (~kvirc@213.33.220.118)
08.01.57 Quit    pamaury (Ping timeout: 250 seconds)
08.13.59 Quit    ygrek (Ping timeout: 250 seconds)
08.15.03 ***     Saving seen data "./dancer.seen"
08.17.15 Join    ender [0] (krneki@foo.eternallybored.org)
08.19.55 Quit    mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
08.25.31 Quit    ender (Read error: Connection reset by peer)
08.26.08 Join    ender [0] (krneki@foo.eternallybored.org)
08.39.27 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
08.40.58 Nick    SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73)
08.54.31 Join    ygrek [0] (~user@108.59.6.97)
09.30.06 Join    xorly [0] (~xorly@m180.dkm.cz)
09.33.04 Join    Zagor [242] (~bjst@rockbox/developer/Zagor)
09.44.34 #       <fs-bluebot> Build Server message: 3New build round started. Revision d3cf366, 253 builds, 28 clients.
09.52.07 #       <fs-bluebot> Build Server message: 3Build round completed after 454 seconds.
09.57.19 Join    LinusN [0] (~linus@giant.haxx.se)
10.15.07 ***     Saving seen data "./dancer.seen"
10.25.28 Quit    PaulFertser (Quit: bbl, upgrade time)
10.28.25 Quit    xorly (Ping timeout: 250 seconds)
11.42.18 Quit    burgobianco (Remote host closed the connection)
11.44.39 Join    burgobianco [0] (~viskestel@li607-220.members.linode.com)
11.46.53 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
11.47.28 Join    magnetbrain [0] (cbdbe455@gateway/web/freenode/ip.203.219.228.85)
12.15.11 ***     Saving seen data "./dancer.seen"
12.16.48 Join    kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka)
12.25.41 #       <[Saint]> magnetbrain: did it ever mount?
12.25.59 #       <magnetbrain> yep
12.25.59 #       <[Saint]> Ie. Did you manage to complete the installation?
12.26.04 #       <magnetbrain> on a different pc to my usual one
12.26.17 #       <magnetbrain> (have had rockbox on this thing for like 4 months now)
12.26.52 #       <[Saint]> If your host won't mount the fallback image, there's really nothing I can assist you with here.
12.27.26 #       <magnetbrain> i flicked through the installed usb drivers on the pc, nothing emcore related
12.27.47 #       <[Saint]> Nor need there be.
12.28.36 #       <magnetbrain> oh, read a thing on freemyipod (although for installing the firmware) that said it needed a usb driver
12.29.33 #       <magnetbrain> sorta improvised from it
12.29.34 #       <magnetbrain> http://www.freemyipod.org/wiki/EmCORE_Installation/iPodClassic/DFUNoiTunes
12.29.59 #       <[Saint]> Yes. That's not relevant to Rockbox at all though.
12.30.31 #       <magnetbrain> oh
12.30.33 #       <magnetbrain> what oops
12.30.35 #       <magnetbrain> :L
12.31.04 #       <magnetbrain> well anyway, if i try to mount the fallback image and work from there, will it erase the data currently on the ipod?
12.31.55 #       <[Saint]> No.
12.32.13 #       <magnetbrain> trying it now
12.32.47 #       <magnetbrain> popped up with "Apple Mobile USB Driver" installed successfully
12.32.59 #       <magnetbrain> still not mounting drive
12.33.44 #       <[Saint]> You can clear out all that leftover driver bullshit. Its irrelevant to you.
12.33.51 #       <magnetbrain> yup done
12.34.06 #       <magnetbrain> gonna leave the ipod to do its thing and come back in a couple minutes, see if it's mounted
12.34.10 #       <magnetbrain> will return with results
12.34.15 #       <magnetbrain> (thanks for the help btw)
12.35.40 #       <[Saint]> The leftover apple driver should affect us in any way, but its been seen to cause weirdness in the past.
12.36.04 #       <[Saint]> The no-itunes method is a bit of a clusterfuck really.
12.36.30 #       <magnetbrain> yeah, certainly does look like one
12.37.25 #       <[Saint]> Pretty much none of us use windows either. And those who do, and are involved with the project, rarely see issue.
12.37.41 #       <[Saint]> It "just works" with Linux hosts.
12.37.55 #       <magnetbrain> fair enough
12.38.29 #       <magnetbrain> i'm not the biggest fan of windows tbh, i just use it because it's what i'm used to - will probably make the change to a flavour of some sort soonish
12.40.30 #       <magnetbrain> and we have a mount!
12.41.01 #       <magnetbrain> thanks a bunch for the help, even though it wasn't really much haha
12.42.55 #       <copper> lol
12.43.25 #       <[Saint]> Freemyipod may be able to do more for you. I'm not about to go handing out their binaries personally due to want of avoiding licensing issues.
12.43.38 Join    lleeloo [0] (~lleeloo@178.125.84.192)
12.44.18 Quit    magnetbrain (Quit: Page closed)
12.44.34 #       <TheSeven> [Saint]: which binaries?
12.45.34 #       <[Saint]> I have a patched installer and 6g Rockbox binary I got from you a while back.
12.46.02 #       <TheSeven> you mean my USB fix tests?
12.46.57 #       <[Saint]> Among others. I don't have the sources for it anyway nor a means of compilation so I'd feel weird handing them out.
12.51.35 #       <TheSeven> http://theseven.homenet.org/~theseven/tmp/bootstrap-ipodclassic-with-all-patches.dfu
12.51.35 #       <TheSeven> http://theseven.homenet.org/~theseven/tmp/installer-ipodclassic-with-all-patches.ubi
12.51.35 #       <TheSeven> http://theseven.homenet.org/~theseven/tmp/rockbox-ipodclassic-with-all-patches.zip
12.51.35 DBUG    Enqueued KICK TheSeven
12.51.35 #       <TheSeven> feel free to link to those, they're my latest testing builds
12.51.52 #       <TheSeven> freemyipod-side stuff is just SVN head, rockbox stuff ist git master as of a few weeks ago + my patches on gerrit
12.52.13 #       <TheSeven> I'm very interested in feedback about these builds especially from people who have trouble with USB or disk access
12.52.31 #       <[Saint]> How permanent are those URLs?
12.53.04 #       <TheSeven> I'll try to keep those files up to date with the latest patches until they have all landed in official builds
12.53.33 #       <[Saint]> As want of not distributing the binaries directly kept me from doing so a few times now.
12.53.44 #       <[Saint]> The direct links are much appreciated.
12.54.07 #       <[Saint]> I wasn't ever sure of the permanence though. Good to know.
12.55.28 #       <[Saint]> TheSeven: I do have some feedback regarding the encore binary.
12.55.47 #       <[Saint]> Mine refuse to mount UMSboot.
12.55.57 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
12.55.57 #       * TheSeven tries
12.56.06 #       <[Saint]> And now I'm unsure how to up/downgrade
12.56.15 #       <TheSeven> oops, indeed
12.56.23 #       <TheSeven> mine just hung with a black screen
12.56.26 #       <TheSeven> need to look into that
12.56.27 #       <[Saint]> Yep.
12.56.36 #       <[Saint]> That's the one. Glad its not just me.
12.56.57 #       <TheSeven> hm, on the second try I now have the splash screen
12.57.14 #       <TheSeven> didn't mount though
12.57.31 #       <TheSeven> third try didn't even clear the screen, still showing the boot menu
12.57.40 #       <TheSeven> so this looks like some kind of IRQ race...
12.58.05 #       <[Saint]> Might the host play some timing factor?
12.58.13 #       <[Saint]> I always get the black screen.
12.58.16 #       <[Saint]> Always.
12.58.41 #       <TheSeven> also if you start it without USB connected?
12.58.50 #       <[Saint]> Yes.
12.59.23 #       <[Saint]> Oh. I...sorry. Clarification.
12.59.40 #       <[Saint]> I just figured what you meant. No. Indeed not.
12.59.54 #       <TheSeven> so yeah, makes a USB IRQ race even more likely
13.00.02 #       <[Saint]> I thought you meant if I start it without USB and /then/ plug USB.
13.00.08 #       <[Saint]> Which does hang.
13.00.21 #       <TheSeven> yeah, but I guess not with a black screen?
13.01.30 #       <[Saint]> It gets the black screen every time it hangs in UMSboot for me.
13.01.45 #       <[Saint]> Regardless of how I seem to trigger it.
13.02.01 #       <TheSeven> hm, this is weird
13.02.27 #       <TheSeven> I'll have a closer look into that later
13.02.52 #       <[Saint]> Glad you can at least kinda repro.
13.03.05 #       <[Saint]> Usually the weird shit like this just plagues me.
13.03.12 #       <[Saint]> :))
13.03.22 #       <TheSeven> anyway, you have two options to update:
13.03.43 #       <TheSeven> 1. emcore tools (emcore.py runfirmware 0x08000000 installer-ipodclassic.ubi)
13.03.48 #       <TheSeven> 2. run a working umsboot through DFU
13.05.10 #       <[Saint]> Aha. Right. Thanks. I couldn't remember the runfirmware syntax.
13.06.00 #       <TheSeven> hm, the DFU binary that I linked above seems to mount
13.08.54 #       <TheSeven> I just verified that both UMSboot binarys are exactly identical
13.09.08 #       <TheSeven> so this thing works when booted through DFU, but not when booted through emcore
13.10.43 #       <[Saint]> Curiouser and curiouser.
13.11.01 #       <TheSeven> this makes me conclude that the bug is actually quite likely in emcore itself
13.11.05 #       <copper> strange & weirder!
13.11.31 #       <TheSeven> and we've had a recent change in the runfirmware code for OF dualboot support...
13.11.50 #       <TheSeven> I can't see how yet, but this smells like it's related ;)
13.12.53 #       <[Saint]> What's holding back untethered dual boot presently?
13.13.26 #       <TheSeven> someone needs to do the required changes to the installer and the boot menu
13.13.44 #       <TheSeven> and then again I want to get rid of emcore altogether anyway, so I might as well implement that in the rockbox bootloader first
13.13.56 Quit    kuldeepdhaka (Ping timeout: 245 seconds)
13.14.09 #       <TheSeven> that rockbox bootloader still needs an installer though
13.14.22 #       <TheSeven> it's just all half-finished stuff
13.15.03 #       <[Saint]> Story of my life.
13.27.26 Join    krabador [0] (~krabador_@unaffiliated/krabador)
13.39.14 Quit    foolsh (Remote host closed the connection)
13.41.26 Quit    ygrek (Ping timeout: 245 seconds)
13.42.34 #       <copper> wow, the Fuze+ is gorgeous in red
13.43.20 #       <copper> picture from eBay http://outpost.fr/tmp/QXO.jpg/
13.43.33 #       <copper> sexy lady!
13.45.38 #       <copper> who said that Clip+ build quality was generally poor?
13.45.54 #       <copper> seems like there are tons of Sansa / SanDisk refurbs out there
14.06.04 #       <[Saint]> In not sure that means anything.
14.06.20 #       <[Saint]> They just slap new cases on em and fob them off again.
14.06.55 Join    ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249)
14.10.51 #       <ploco> found something odd in eq.c. https://github.com/Rockbox/rockbox/blob/master/lib/rbcodec/dsp/eq.c 
14.11.16 #       <ploco> line 164 /* Apply EQ filters to those bands that have got it switched on. */ but doesn't seems to be the case
14.11.29 #       <ploco>  FOR_EACH_ENB_BAND(b)         filter_process(&eq_data.filters[*b], buf->p32, count, channels);      
14.12.03 #       <ploco> where is the active band check???
14.12.03 Part    simpleuser ("WeeChat 1.0-dev")
14.15.14 ***     Saving seen data "./dancer.seen"
14.15.32 Quit    cmhobbs (Ping timeout: 240 seconds)
14.18.59 #       <gevaerts> ploco: the check seems to be before that
14.19.20 #       <gevaerts> FOR_EACH_ENB_BAND loops over eq_data.bands, and that one only seems to contain the active bands
14.21.10 #       <ploco> somehow i feel it contain every bands. 
14.23.12 #       <[Saint]> Nothing in this area has changed for ages and it definitely worked as intended when i poked at it last.
14.23.16 #       <gevaerts> The comment on line 52 says it doesn't, and line 143..146 (which is the only place I can find where eq_data.bands is written) looks like it does the right thing
14.23.45 #       <gevaerts> Not in an easy to understand way, of course :)
14.24.01 Join    wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
14.25.39 #       <ploco> thank you so much for the answer. :)
14.26.10 #       * gevaerts admits that he had to look around a bit before understanding this code
14.27.10 #       <[Saint]> Should be easily verifiable by watching the CPU hit on realtime playback with N bands enabled.
14.27.55 #       <[Saint]> But that's overkill indeed.
14.29.50 #       <[Saint]> There is a slight overhead hit for EQ enabled with no active bands. But its dramatically less than that of a single active band, and you can watch the additional overhead from adding additional active bands.
14.31.19 #       <ploco> 33+% cpu usage when using 8 bands. that's heavy. 
14.32.10 #       <gevaerts> Which device?
14.32.52 #       <ploco> RaaA Android on HTJ butterfly. someone please tell me this is a joke.
14.32.57 #       <gevaerts> 8 bands is a lot though. It's still not clear that supporting more than 5 was really desired
14.33.00 #       <ploco> HTC
14.33.37 #       <[Saint]> There's almost certainly no need for 8 simultaneous active bands.
14.34.21 #       <gevaerts> 33% at which frequency? At the full 1.5GHz, that's a lot, but for what I know it might be running at 100MHz at the time...
14.35.14 #       <[Saint]> Only testcodec is going to give meaningful data here really.
14.35.16 #       <ploco> under normal load is around 700mhz  
14.35.47 Join    RiD [0] (~RiD@2.83.53.235)
14.35.50 #       <[Saint]> ...Jesus.
14.36.07 #       <[Saint]> my testvdevice rarely ever clocks up past 400MHz
14.36.37 #       <[Saint]> Usually sitting on 100MHz running RaaA.
14.38.06 #       <ploco> [Saint]:  maybe something is running behind on my device.   
14.38.27 #       * [Saint] is reminded that he has a set of parametric eq presets sitting in a repo....somewhere.
14.38.37 #       <[Saint]> The worst case uses 4 bands.
14.38.49 #       <[Saint]> And I'm fairly sure I can get it to 3 if I tried.
14.41.26 #       <ploco> at gerrit? 
14.43.28 #       <[Saint]> No. Sitting in a local branch somewhere.
14.43.57 #       <ploco> In one stage I convinced some users not to use the full 30 band, yes,RCC has 30 band paramatric eq, but end up they don't turn on eq anymore. 
14.45.12 #       <[Saint]> Fuck it. Why not go for 128 bands? Make it a nice round number.
14.45.33 #       <[Saint]> ;)
14.45.56 #       <ploco> XD
14.47.15 #       <[Saint]> That RCC build has done some pretty crazy shit with DSPs and the PEQ 
14.47.40 #       <ploco> what's PEQ? 
14.47.42 #       <[Saint]> Its a clusterfuck of useful changes and snake oil.
14.47.54 #       <[Saint]> Parametric EQ.
14.48.13 #       <copper> <AStorm> it's decent, but not enough bands
14.48.21 #       <copper> <AStorm> nah, 40 is good for a decent approximation
14.48.27 #       <ploco> they actually has three close sourced dsp inbuild.
14.49.04 #       <[Saint]> ...closed?
14.49.10 #       <[Saint]> Oy.
14.50.22 #       <[Saint]> I guess if you're making a build with a 30 band parametric EQ it also stands to reason you don't care about license requirements either.
14.51.00 #       <[Saint]> And, its China...what could who realistically do about it anyway. Fun.
14.52.09 #       <[Saint]> "Hey, could you like...not do that? Otherwise I'll be forced to get mildly annoyed at you from a vast distance."
14.52.30 #       <ploco> copper: one actually want 64 bands that goes from 20hz to 48000hz, that's right 48000hz!!!!!
14.53.02 #       <ploco> no one can stop the chinese force.
14.53.09 #       <[Saint]> Is this user a bat?
14.53.30 Join    amayer [0] (~amayer@mail.weberadvertising.com)
14.54.06 #       <ploco> I wonder how he believe the Android phone can output anything more than 22050hz
14.54.37 #       <[Saint]> I wonder how he believes he'd be capable of hearing it even if it could.
14.54.47 #       <[Saint]> Its a physical impossibility.
14.55.04 #       <[Saint]> Fuck the hardware. The bodybis the limit here.
14.55.04 #       <copper> he probably doesn't understand the difference between frequency and sampling frequency
14.55.18 #       <[Saint]> ...or he's a bat.
14.55.30 #       <[Saint]> I'm going with him being a bat.
14.55.44 #       <ploco> I am with you, he is a bat! 
14.58.10 #       <ploco> to answer his request, I made a crazy mod to one of my dsp. boost 3db to any signals that between 20000hz and 22050hz
14.59.15 #       <[Saint]> Even that's above the generally accepted upper limit of the adult hearing threshold.
14.59.43 #       <[Saint]> A reason why 16000hz is more than adequate.
15.00.22 #       <ploco> that will generate "missing fundamental" which make everything sounds louder
15.00.27 Quit    Rower (Ping timeout: 260 seconds)
15.00.57 #       <[Saint]> IFF you have the magical unicorn poop hardware that can recreate those frequencies.
15.01.15 #       <[Saint]> ...which I'm going to put money on not being the case.
15.01.43 #       <ploco> they are just noise, that triggers some illusions
15.02.28 #       <[Saint]> Why do you cater to the requests of obviously retarded people?
15.02.52 #       <[Saint]> Coding practice?
15.05.06 #       <ploco> just for some fun. killing their hearing softly. 
15.05.46 #       * dfkt_ votes for an ABX plugin for rockbox... or a GTFO plugin.
15.06.26 #       <[Saint]> An ABX plugin would be dead trivial.
15.12.27 #       * [Saint] once made a cruel "ABX" test to pick on audiophiles and their ability to perceive differences that don't exist.
15.13.10 #       <[Saint]> (There was no B, nor X. Only ever an A. But that didn't stop people claiming otherwise.)
15.13.50 #       <dfkt_> hahaha
15.14.06 #       <gevaerts> I'd say that's not cruel
15.14.12 #       <pamaury> haha, very funny
15.14.17 #       <gevaerts> That's the first thing to do :)
15.17.30 #       <[Saint]> I'd say its somewhat cruel, as it is an expectation that you'll be comparing two samples in an ABX test. Not playing the same sample 3 times in a row and laughing when no one notices it.
15.18.46 #       <[Saint]> Funny as hell though, I agree.
15.19.00 #       <TheSeven> what about A=-B?
15.19.09 #       <TheSeven> just all samples negated?
15.19.16 #       <TheSeven> would anyone be able to tell that apart? :P
15.19.32 #       <[Saint]> :))
15.19.47 #       <jhMikeS> gevaerts: it just doesn't loop over bands with no gain, so creates an array of only bands that have an effect
15.20.02 #       <gevaerts> jhMikeS: yes, that's what I deduced
15.31.19 Quit    alexbobp (Ping timeout: 250 seconds)
15.33.02 Join    alexbobp [0] (~alex@capitalthree.pwnz.org)
15.39.37 Join    bcobco [0] (~bcobco@77.228.124.149)
15.41.43 #       <bcobco> jhMikeS: regarding resample in dsp path, it actually uses bsplines. what about other algorithms? lanzos? sinc?
15.49.14 #       <jhMikeS> catmull-rom more accurately
15.50.00 #       <jhMikeS> there are no others 
15.50.29 #       <jhMikeS> I doubt we're going to invest too much in resampling overhead
15.52.46 Join    Misanthropos [0] (~Misanthro@frnk-5f7444cb.pool.mediaWays.net)
15.52.53 Quit    Misanthropos (Client Quit)
15.53.16 #       <jhMikeS> bcobco: http://en.wikipedia.org/wiki/Cubic_Hermite_spline <== that what it was derived from
15.59.26 Quit    bcobco ()
16.07.27 Join    bcobco [0] (~bcobco@77.228.124.149)
16.08.29 Quit    the-kyle (Remote host closed the connection)
16.10.03 Join    the-kyle [0] (~kyle@kyle.tk)
16.11.47 Quit    bcobco (Client Quit)
16.15.16 ***     Saving seen data "./dancer.seen"
16.17.06 Quit    ploco (Quit: Page closed)
16.17.43 Quit    mikroflops (Read error: Connection reset by peer)
16.19.40 Join    ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net)
16.29.34 Join    RiDD [0] (~RiD@2.83.53.235)
16.31.06 Join    mc2739_ [0] (~mc2739@rockbox/developer/mc2739)
16.31.08 Quit    mc2739 (Disconnected by services)
16.31.11 Nick    mc2739_ is now known as mc2739 (~mc2739@rockbox/developer/mc2739)
16.31.11 Join    zoktar_ [0] (~zoktar@unaffiliated/zoktar)
16.31.13 Join    markun_ [0] (~markun@rockbox/developer/markun)
16.31.44 Join    scorche|1h [0] (~scorche@rockbox/administrator/scorche)
16.32.23 Quit    zoktar (Ping timeout: 260 seconds)
16.32.23 Quit    ivanf (Ping timeout: 260 seconds)
16.32.23 Quit    Elfish (Ping timeout: 260 seconds)
16.32.24 Quit    Ketturi (Ping timeout: 260 seconds)
16.32.25 Quit    Jinx (Ping timeout: 260 seconds)
16.32.25 Quit    akaWolf (Ping timeout: 260 seconds)
16.32.26 Quit    scorche|sh (Ping timeout: 260 seconds)
16.32.26 Quit    RiD (Ping timeout: 260 seconds)
16.32.27 Quit    charlie (Ping timeout: 260 seconds)
16.32.28 Quit    ps-auxw (Ping timeout: 260 seconds)
16.32.28 Quit    markun (Ping timeout: 260 seconds)
16.32.29 Quit    Jack87 (Ping timeout: 260 seconds)
16.32.29 Join    akaWolf [0] (~akaWolf@188.134.9.161)
16.32.30 Quit    akaWolf (Changing host)
16.32.30 Join    akaWolf [0] (~akaWolf@unaffiliated/akawolf)
16.32.35 Join    ivanf [0] (~ivan@pool-72-69-217-153.nycmny.fios.verizon.net)
16.32.35 Quit    ivanf (Changing host)
16.32.35 Join    ivanf [0] (~ivan@unaffiliated/kferdous)
16.32.39 Join    ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123)
16.32.48 Join    Ketturi [0] (ketturi@hilla.kapsi.fi)
16.33.05 Nick    zoktar_ is now known as zoktar (~zoktar@unaffiliated/zoktar)
16.33.05 Join    Rower [0] (~husvagn@h176n2-aeg-a11.ias.bredband.telia.com)
16.33.07 Quit    lleeloo (Ping timeout: 240 seconds)
16.33.24 Join    Elfish [0] (amba@2001:1608:12:1:13:3:3:7)
16.36.11 Join    Jinx [0] (Dojo@unaffiliated/jinx)
16.36.51 Join    Jack87 [0] (Jack87@nasadmin/admin/jack87)
16.37.38 Join    ygrek [0] (~user@108.59.6.97)
16.37.57 Join    charlie [0] (~c@unaffiliated/charlie)
16.38.34 Join    einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
16.41.32 #       <Zagor> *boink* flyspray is now back up
16.42.00 #       <gevaerts> Woo!
16.42.51 Quit    ikeboy (Quit: Leaving)
16.47.21 Quit    einhirn (Ping timeout: 245 seconds)
16.50.23 Join    akaWolf1 [0] (~akaWolf@188.134.9.161)
16.50.40 Quit    Jinx (Ping timeout: 260 seconds)
16.50.40 Quit    akaWolf (Ping timeout: 260 seconds)
16.53.54 Join    Jinx [0] (Dojo@unaffiliated/jinx)
16.55.17 Join    bcobco [0] (~bcobco@77.228.124.149)
17.07.03 Quit    Zagor (Quit: Clint excited)
17.10.32 Quit    ygrek (Ping timeout: 250 seconds)
17.34.42 Join    kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka)
17.41.20 Quit    kuldeepdhaka (Max SendQ exceeded)
17.42.58 Join    kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka)
17.46.06 Join    AlexP [0] (~alex@rockbox/staff/AlexP)
18.02.30 Join    bertrik [0] (~quassel@rockbox/developer/bertrik)
18.06.08 Join    ZincAlloy [0] (~Adium@pD9EEB3EF.dip0.t-ipconnect.de)
18.08.09 Join    ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net)
18.11.55 Quit    bcobco (Remote host closed the connection)
18.12.21 Join    bcobco [0] (~bcobco@77.228.124.149)
18.13.04 Quit    wodz (Quit: Leaving)
18.15.20 ***     Saving seen data "./dancer.seen"
18.15.28 Join    petur [0] (~petur@rockbox/developer/petur)
18.21.09 #       <fs-bluebot> Build Server message: 3New build round started. Revision 6ffb8ff, 253 builds, 29 clients.
18.25.05 Quit    ikeboy (Ping timeout: 260 seconds)
18.30.36 Join    ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net)
18.33.11 #       <pamaury> ikeboy: I committed the fuze+ brightness patch
18.33.23 #       <ikeboy> Noticed, thanks
18.34.09 #       <jhMikeS> hmmm...is buildy stuck
18.34.50 #       <bertrik> I just joined (late in the build) and got a sansam200v4 build
18.35.38 #       <jhMikeS> been almost 15 minutes
18.36.46 Quit    ivanf (Ping timeout: 246 seconds)
18.37.31 Quit    bcobco (Remote host closed the connection)
18.37.54 Join    bcobco [0] (~bcobco@77.228.124.149)
18.39.02 Quit    ikeboy (Ping timeout: 240 seconds)
18.39.11 #       <bertrik> meh, got a "Fatal build error: Missing log file. You have been temporarily disabled."
18.40.12 #       <bertrik> seems like it's proceeding into the last 10 builds now
18.42.42 Join    ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net)
18.42.49 #       <fs-bluebot> Build Server message: 3Build round completed after 1300 seconds.
18.43.46 #       <jhMikeS> quite a long round
18.44.20 #       <jhMikeS> thankfully the SDL app warning is unrelated to the changes
18.45.36 Quit    ikeboy (Client Quit)
18.53.02 Quit    Provel (Ping timeout: 255 seconds)
18.53.46 Join    Provel [0] (Provel@75-132-30-64.dhcp.stls.mo.charter.com)
18.54.16 Quit    Rower (Ping timeout: 255 seconds)
18.59.38 Join    Rower [0] (~husvagn@h176n2-aeg-a11.ias.bredband.telia.com)
19.17.25 Quit    pamaury (Ping timeout: 250 seconds)
19.18.40 Quit    Slasheri (Ping timeout: 272 seconds)
19.18.46 Join    Slasheri [0] (miipekk@rockbox/developer/Slasheri)
19.24.46 Join    n1s [0] (~n1s@rockbox/developer/n1s)
19.47.52 #       <jhMikeS> any good reason the the backtrace warning in android hasn't been silenced?
19.47.52 Quit    bluebrother^ (Read error: Connection reset by peer)
19.48.10 Quit    fs-bluebot (Read error: Connection reset by peer)
19.48.20 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.48.47 #       <gevaerts> I suspect not
19.53.44 Join    fs-bluebot [0] (~fs-bluebo@g231123018.adsl.alicedsl.de)
19.55.00 Join    wodz [0] (~wodz@89-67-6-182.dynamic.chello.pl)
20.00.50 #       <fs-bluebot> Build Server message: 3New build round started. Revision 2cb274c, 253 builds, 30 clients.
20.08.04 #       <saratoga> damn it, people let Zagor off without reminding him to fix building the manuals
20.08.35 #       <saratoga> HTML manuals that is
20.11.48 #       <jhMikeS> that's what holding it up?
20.11.56 Join    ikeboy [0] (~ikeboy@pool-108-29-132-68.nycmny.fios.verizon.net)
20.15.24 ***     Saving seen data "./dancer.seen"
20.17.25 #       <fs-bluebot> Build Server message: 3Build round completed after 994 seconds.
20.17.48 #       <fs-bluebot> Build Server message: 3New build round started. Revision bfbec3a, 253 builds, 30 clients.
20.18.05 Quit    user890104 (Ping timeout: 255 seconds)
20.18.17 Join    user890104 [0] (Venci@unaffiliated/user890104)
20.18.29 #       <megal0maniac> Wow the build farm is a busy place today
20.20.33 #       * jhMikeS should've just pushed the last two in one go
20.20.38 Join    lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr)
20.20.51 #       <megal0maniac> Why are builds taking so long lately?
20.21.37 #       <bertrik> something seems to be wrong with roolku's machines, they were doing a lot more before
20.21.41 Quit    bcobco (Remote host closed the connection)
20.21.59 #       <bertrik> maybe temporarily disabled, like I get disabled occasionally
20.22.04 Join    bcobco [0] (~bcobco@77.228.124.149)
20.22.16 #       <megal0maniac> Yeah, that's what I thought too. Mine is way up there now, which is cool, but also wrong :)
20.22.30 Quit    ikeboy (Ping timeout: 250 seconds)
20.23.21 #       <jhMikeS> nano 2g shed 1344 bytes because of 2cb274c ?? wtf is going on there?
20.24.32 #       <gevaerts> Alignment games?
20.24.44 #       <bertrik> a lot of panics perhaps?
20.25.12 #       <jhMikeS> 2g needs xanax if it panics that much
20.25.27 #       <megal0maniac> I'm trying to figure out what exactly 2cb274c actually does
20.25.57 #       <gevaerts> It gives the compiler some hints
20.26.17 #       <jhMikeS> __attribute__((noreturn)) tells the compiler the call doesn't return, which avoids alot of call state code in the paths that call it
20.27.06 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
20.27.53 #       <jhMikeS> it also saves prologue and epilogue code in the function itself since it never has to save callee-saved registers
20.28.09 #       <megal0maniac> Ah, clever :)
20.29.16 #       <megal0maniac> Ooh, while I'm thinking about it, is it possible to enable multi-threaded builds? The equivalent of -j3
20.29.27 #       <jhMikeS> if we had gcc 4.5 then __builtin_unreachable() could be used in places as well
20.30.05 #       <jhMikeS> megal0maniac: I do believe that works :)
20.30.55 #       <megal0maniac> Specifically for runclient.sh though. Although I'm looking at htop and everything is pinned at 90+%, so it must be automagic.
20.31.21 #       <megal0maniac> I learn so much from this project
20.31.21 #       <gevaerts> The build client should look for the number of cores you have
20.32.45 #       <jhMikeS> buildy's got the stiffles
20.33.39 #       <fs-bluebot> Build Server message: 3Build round completed after 952 seconds.
20.35.42 Quit    copper (Quit: ZNC - http://znc.in)
20.36.10 #       <wodz> hmm, interesting. The way we calculate crc for rockchip files is accepted by nand bootloader BUT looking at the content of OF BASE.rkw they do this differently
20.36.44 #       <jhMikeS> what's with recorder anyway? it can't use a compressed image but player can?
20.37.20 #       <gevaerts> It can, but even that is too large
20.37.53 #       <jhMikeS> yet player crunches down from a larger size...weird
20.37.59 #       <saratoga> anyone want to comment on this question in new ports:  http://forums.rockbox.org/index.php/topic,48058.msg229372.html#msg229372
20.38.27 #       <jhMikeS> nvm, I misread
20.38.29 Quit    shamus (Read error: Connection reset by peer)
20.38.40 Join    copper [0] (~copper@unaffiliated/copper)
20.38.46 #       <jhMikeS> it is doing that already
20.39.18 Join    shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net)
20.40.51 #       <jhMikeS> gevaerts: what is the limiting factor on that? branch limits or just finicky loader?
20.41.06 #       <gevaerts> The loader
20.41.47 #       <jhMikeS> split!
20.42.46 #       <gevaerts> Well, move to a regular bootloader model like everything else :)
20.42.55 #       <gevaerts> Someone has to do it though
20.43.19 #       <gevaerts> And the way things are, there will be some bad feelings if someone saves HWCODEC :)
20.43.26 #       <jhMikeS> haha
20.45.19 #       <jhMikeS> the red stripe of death...gotcha
20.46.47 Quit    shamus (Ping timeout: 260 seconds)
20.46.54 Join    shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net)
21.01.18 #       <jhMikeS> after you've worked on a branch for awhile, doing many changes, git sure ends up with bizarre looking file statuses
21.01.47 #       <jhMikeS> copy/rename this => totally apparently unrelated that
21.07.02 Quit    TheSeven (Ping timeout: 250 seconds)
21.08.25 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
21.11.20 Quit    Rower (Ping timeout: 264 seconds)
21.16.48 #       <saratoga> is the file system rework going in soon?  its been working fine for me for a while now
21.17.49 #       <jhMikeS> sure, anytime
21.19.25 #       <saratoga> are you making more changes?
21.19.32 #       <jhMikeS> except I had a few android compilation problems, only one remains (after the endian commit) so I'm deciding how to deal with that
21.19.39 #       <saratoga> ok
21.20.11 #       <jhMikeS> stuff that doesn't work now will build again, like database
21.20.25 #       <jhMikeS> assuming anyone cares
21.21.57 #       <jhMikeS> someone probably should check android after that. the SDL app works so it shouldn't be a big todo if there's something
21.23.11 Quit    shamus (Ping timeout: 245 seconds)
21.29.37 Quit    bcobco ()
21.43.09 Join    xorly [0] (~xorly@m180.dkm.cz)
21.55.25 Join    Dan_ [0] (c363ffc2@gateway/web/freenode/ip.195.99.255.194)
21.55.48 Nick    Dan_ is now known as Guest16154 (c363ffc2@gateway/web/freenode/ip.195.99.255.194)
21.55.49 #       <Guest16154> Hello! I've recently discovered RockBox (behind the times, I know!) and I've spent all week working on a theme in the simulator. One thing I've been unable to do though:
21.56.23 #       <Guest16154> I'd like to put the device in 'hold' mode but cannot work out how to do it. I'm using a laptop without a numeric keypad and I'm using the pre-combined windows binary for the simulator so I don't have source to hand.
21.56.39 #       <Guest16154> Can anybody tell me how I can go about putting the device (Clip Zip) into hold mode on the sim?
21.56.41 #       <Guest16154> Thank you! :)
21.59.10 #       <gevaerts> Does the clip zip actually have a hold switch?
21.59.16 #       <gevaerts> If not, the sim won't do it either
21.59.43 #       <Guest16154> Oh I thought it was a software feature (hold a certain button for example)
22.00.00 #       <gevaerts> right
22.00.09 #       <gevaerts> Yes, there is a software lock thing as well...
22.01.16 #       <n1s> Guest16154: pressing h does it on sims for players with the physical switch at least
22.01.27 #       <wodz> Is possible to get combo in sim?
22.01.56 #       <gevaerts> key lock on the clip zip is home+select, so in the sim that should be insert+space
22.02.24 #       <Guest16154> Excellent,insert + space worked
22.02.27 #       <Guest16154> Thanks a bunch! :)
22.02.27 #       <Guest16154> :)
22.02.36 #       <Guest16154> Now to tidy the last few details :)
22.02.39 #       <gevaerts> or keypad multiply + keypad 5, but that requires the keypad :)
22.02.56 #       <wodz> ok, so answer is yes, sim can do combos :-)
22.03.49 #       <Guest16154> I cannot believe I've not found Rockbox before... Wasted so long playing :)
22.03.54 #       <Guest16154> More time than listening to the music!!
22.04.48 Quit    n1s (Quit: Ex-Chat)
22.07.46 Quit    Xerion (Read error: Connection reset by peer)
22.09.01 Join    Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl)
22.09.10 Part    Xerion
22.09.19 Join    Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl)
22.10.20 Part    Xerion
22.10.23 Join    Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl)
22.10.27 Part    Xerion
22.10.31 Join    Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl)
22.14.58 Join    y4n [0] (~y4n@unaffiliated/y4ndexx)
22.15.27 ***     Saving seen data "./dancer.seen"
22.17.30 #       <xorly> Xerion: stay or leave, that is the question...
22.27.01 Quit    Guest16154 (Quit: Page closed)
22.27.07 Quit    y4n (Quit: PÆNTS ØLF!)
22.41.51 Quit    ender (Ping timeout: 240 seconds)
22.42.17 Quit    wodz (Quit: Leaving)
23.18.11 Quit    pamaury (Ping timeout: 245 seconds)
23.24.40 Join    sakax [0] (~sakax@unaffiliated/sakax)
23.24.51 Part    LinusN
23.27.31 Quit    sakax (Read error: Connection reset by peer)
23.29.16 Quit    petur (Quit: Leaving)
23.36.25 Quit    amayer (Quit: Leaving)
23.43.20 Quit    lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 32.0/20140822024446])
23.53.28 Quit    saratoga_ (Quit: Page closed)
23.56.47 Quit    amiconn (Read error: Connection reset by peer)
23.57.11 Quit    kuldeepdhaka (Quit: sleep())
23.58.43 Join    amiconn [0] (quassel@rockbox/developer/amiconn)