--- Log for 02.12.112 Server: sturgeon.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 11 days and 21 hours ago 00.00.24 Join KiwiCam [0] (~quassel@101.98.163.139) 00.03.29 Join webguest36 [0] (~57709af6@www.haxx.se) 00.03.51 # i don't understand why pushes don't implicitly update the source they pulled from 00.04.19 # I think recent git version do this 00.04.19 Quit webguest36 (Client Quit) 00.05.28 # huh? 00.05.34 # saratoga_: you mean, why the push url is different? 00.05.40 # that'sjust an optimisation for our server 00.05.48 # you can use the saem url for both 00.05.54 # i mean, why do i have to tell it theres a push URL? 00.05.55 # as long as it's one of the authenticated protocols 00.06.00 # because the url you cloned from is read only 00.06.29 # if you just cloned the other url to start with you don't have to do it 00.07.50 # but the read-only one is faster, and doesn't require you to have already created a gerrit account 00.08.02 # so it's what we have at the start of the instructions 00.09.04 # <[Saint]> Is requiring a gerrit account to clone the repo that big a deal? If they have no intention of contributing back, don't we have a github they can pull from? 00.09.40 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 18.0/20121128060531]) 00.09.44 # it works fine cloning from the git:// protocol 00.09.52 # and it's faster 00.09.57 # [Saint]: Yes, it is that big a deal. 00.10.20 # <[Saint]> ...do tell. 00.11.19 # [Saint]: what would requiring a gerrit account to clone actually buy us? 00.11.33 # Anything you do to raise the activation energy required will cause significant fractions of people not to bother. 00.11.43 *** Saving seen data "./dancer.seen" 00.12.04 # * gevaerts nods 00.12.13 # You know why things like "Login with Facebook" are so popular? 00.12.29 # <[Saint]> gevaerts: nothing, and I wasn't implying it would. I just wondered why it was mentioned specifically. 00.12.36 # Because site owners know that whenever they ask users to make an account just for their site, most of them simply won't. 00.13.00 # <[Saint]> yeah, thankfully...there's Oauth..so, yeah, no. 00.13.08 # <[Saint]> not for gerrit at least. 00.13.23 # I mean, this is largely the reason that oauth exists. 00.13.58 # <[Saint]> Argh, yes. I parsed that incorrectly. 00.14.44 # <[Saint]> I just thought that since the main idea of gerrit (only idea?) it review and contribution that creating an account for it wouldn't be a big deal. 00.14.46 # <[Saint]> That's all. 00.14.56 # <[Saint]> *is review. 00.15.09 # [Saint]: we *do* require an account for gerrit 00.15.18 # We don't require one for git cloning 00.15.48 # <[Saint]> I know, but, it's not like there's nowhere else to clone from. 00.16.04 # [Saint]: This is not how human psychology works. 00.16.25 # When someone has written a patch and is looking for a place to upload it, they will happily make an account. 00.16.37 # When they want to browse some code or run git blame... not so much. 00.16.52 # And unless those "other places" are the _first_ place you're pointing to, they won't go looking for them. 00.16.59 # I don't see the point of shutting down services for *zero* advantage if there are reasons to keep them, even if you think those reasons aren't very strong 00.22.06 # trying to follow the backlog of conversation here 00.23.30 # <[Saint]> Don't try too hard. It's fairly non-interesting. :) 00.24.03 # [Saint]: should 'badblocks -n' work on Rockbox in usb mode? 00.24.59 # <[Saint]> It _should_. 00.25.20 # okay hmm, it bailed on my Fuze v1 with 3.8.1 00.25.58 # in MSC mode the device is just a normal hard disk, so you can do normal hard disk things 00.26.42 # the suspicion that 3.8.1 is "good" for Fuze v1 and USB may prove false 00.26.53 # <[Saint]> And while it _should_ work, 3.8.1 is a whole barrel full of ancient, so I'm not too sure how meaningful it not working there is. 00.27.04 # <[Saint]> (without knowing if it is functional in HEAD) 00.27.04 # ah, copy. 00.27.26 # anyone with a more or less known working USB mode care to try vs. head, and vs 3.8.1 ? 00.27.43 # I'm trying to hunt down where Fuze v1 USB fail comes from 00.27.46 # i don't know if USB ever worked perfectly on the fuze 00.29.05 # if it can't be fixed for next stable release, then perhaps disable it for stable? 00.29.33 # is there any point in doing that? 00.29.41 # prevent data loss 00.30.42 # transferring data from host to rockbox on sansa fuze v1 tends to corrupt existing unrelated files 00.30.54 # for some people 00.31.06 # <[Saint]> That suggests that the FS would already be hosed, to me. 00.31.31 # I have 3 different Sansa V1's to test with 00.34.42 # before each test, I use the oem firmware to "format", load rockbox, sync and unmount 00.35.08 # the only thing that would hose the filesystem is data corruption from rockbox usb transfer 00.35.24 # do you really need to format? 00.35.59 # no, but it remmoves doubt of filesystem corruption; to your point 00.45.30 # would it be easier to just DD something over and then read it back and see if it matches? 00.46.57 # that way you don't need to care about the file system 00.47.34 Quit melmothX (Quit: bau) 00.55.30 # when copying lots of data to the sd card via usb my fuzev1 almost always hangs at some point, i think it'sw always donr that 00.55.51 # i just use the c200 as a card adaptor (when i remember) 00.56.10 # but it's never hosed the filesystem worse than fsck.vfat being able to fix it 00.56.50 # not sure if it applies to internal storage too, unzipping an rb build usually works fine and i don't use it for music 01.00.02 # * [Saint] just got grilled for spending $500 on a GFX card. 01.00.48 # <[Saint]> Raedeon HD7950 01.01.15 # * [Saint] remembers being one of the first in NZ to get an AGP FX5200, lol. 01.01.23 # Now you're playing with power. 01.01.29 Nick the-kyle1 is now known as the-kyle (~kyle@cpe-024-211-185-030.nc.res.rr.com) 01.01.54 # <[Saint]> shit. this, is the wrong channel entirely... 01.06.38 Quit Robin0800 (Read error: Connection reset by peer) 01.12.18 Quit ender (Quit: I strap on the body armor, which feels tough enough, but closes with Velcro strips. I know this is state-of-the-art gear, but I'd feel more confident if it wasn't held together with the same stuff they use to fasten kids' sneakers. -- Richard Kadrey: Sa) 01.17.34 Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) 01.32.15 # fuze v1 usb mode 3.6 does endless reboot, interesting 01.32.46 # <[Saint]> I don't think that's that interesting at all. 01.32.47 Quit pamaury_ (Ping timeout: 265 seconds) 01.32.57 # <[Saint]> iirc, that's a modern bootloader combined with old USB behaviour. 01.33.08 # ah yes 01.33.28 # so old bootloader would be needed to test old 3.6? 01.34.07 # sorry I am so naive 01.34.09 # <[Saint]> I _think_ so, but, an AMS guru really needs to weigh in here. 01.34.27 # <[Saint]> I was never really quite sure exactly how the bootloader tied into the USb behaviour in the first place. 01.35.08 # better question would be, should I update the bootloader to something other than HEAD when testing older versions of rockbox, how old, and so on? 01.35.11 # <[Saint]> But I do distinctly recall a big mess got created when we stopped relying on the OF for USB, and I seem to recall the bootloader having a lot to do with this. 01.35.14 Quit bertrik (Remote host closed the connection) 01.36.39 # Back then there wasn't any usb support 01.36.50 # So there's no point in trying to test it 01.37.20 # aye so ... what point release was usb included? 01.37.50 # <[Saint]> release notes should tell you that. 01.38.06 # I don't know, but it definitely was one that works with a current bootloader :) 01.38.16 # thanks gevaerts 01.38.59 # The issue is that a current bootloader boots rockbox when it sees USB, and old rockbox reboots (to get to the OF) when it sees USB 01.39.42 # <[Saint]> Ah, it's less technical than I thought. 01.39.44 # okay I see, that does make sense it would reboot like I just obvserved then 01.40.49 # [Saint]: it's *very* simple. The difficult bits appear when you try to figure out migration plans between OF-for-USB and rockbox-for-USB 01.41.23 # looks like USB rockbox started with 3.7 01.43.09 Quit n1s (Quit: Ex-Chat) 01.50.27 Join breakfastsquid [0] (~quassel@ip68-224-121-213.lv.lv.cox.net) 01.50.59 Quit brkfstsqd (Ping timeout: 250 seconds) 01.58.42 # g#363 looks good to me 01.58.45 # 3Gerrit review #363 at http://gerrit.rockbox.org/r/363 : tagnavi: Add clause for comparison of multiple tags with same value in DB search by Eliran Levi (changes/63/363/1) 01.58.55 # anyone want to review it? i'm not too familiar with the DB but it looks safe and sensible 02.01.37 Quit Rower85 (Quit: Hmmm...) 02.11.45 *** Saving seen data "./dancer.seen" 02.33.57 Quit sakax (Read error: Operation timed out) 02.35.45 Quit ruskie (Quit: ...) 02.36.52 Join sakax [0] (~sakax@d8D862498.access.telenet.be) 02.49.45 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 02.53.31 Quit sentriz (Ping timeout: 252 seconds) 03.06.46 Quit efyx__ (Ping timeout: 245 seconds) 03.14.55 Quit Clear_runway (Ping timeout: 265 seconds) 03.20.28 Join efyx__ [0] (~efyx@91.179.18.218) 03.29.18 Quit the-kyle (Ping timeout: 246 seconds) 03.32.36 Quit Gallomimia (Read error: Connection reset by peer) 03.33.15 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 03.44.32 Quit [Saint] (Remote host closed the connection) 03.50.57 Join sentriz [0] (~Senan@78.143.151.93) 03.55.09 Quit scorche (Disconnected by services) 03.55.13 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 04.10.51 Quit sentriz (Quit: Leaving) 04.11.47 *** Saving seen data "./dancer.seen" 04.13.56 Quit Poodlemastah (Quit: ZNC - http://znc.in) 04.17.57 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.17.57 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.17.57 Quit amiconn (Disconnected by services) 04.17.57 Quit pixelma (Disconnected by services) 04.51.07 Join TheSphinX_ [0] (~briehl@p579CC445.dip.t-dialin.net) 04.54.11 Quit TheSphinX^ (Ping timeout: 245 seconds) 05.31.09 Quit TheSeven (Disconnected by services) 05.31.17 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.32.36 Quit GodEater (Ping timeout: 264 seconds) 05.33.09 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 05.33.09 Quit GodEater (Changing host) 05.33.09 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 05.40.39 Join [Saint] [0] (~saint@rockbox/user/saint) 05.43.58 # * [Saint] wonders about the USB requirement for "stable" anyway... 05.44.09 # <[Saint]> saratoga_: ^ 05.44.47 # <[Saint]> I mean, if the iPod mini is stable, and has no support for firewire, isn't that fairly similar? 05.47.16 # <[Saint]> I'm unsure, as my mini is currently non-functional and I have a bad memory...but I seem to recall it doesn't reboot to the OF on Firewire plug either and just sits there and charges. 05.47.47 # <[Saint]> Meaning it'd be in pretty much exactly the same position as the Nano2G if we disabled Rockbox USB. 05.48.11 # <[Saint]> #musingsabouthingswhileIwaswalking 05.49.48 # <[Saint]> gevaerts: (log) did you ever get any further with USB reboot on detect for the N2G? 05.50.09 # <[Saint]> (I'm aware of what exists on gerrit currently) 05.54.38 # <[Saint]> Ahhhhhh, herp-derp. No Firewire != No USB. Yeah, ...whoops. 06.11.51 *** Saving seen data "./dancer.seen" 06.34.34 Quit breakfastsquid (Remote host closed the connection) 06.50.58 # [Saint]: so far, I see failure mode from "badblocks" with firmware 3.8 which was reportedly okay in the fuze v1 bug report 06.51.23 # doing some more thrashing of 3.7 which has completed okay w/ badblocks a few times yet 07.02.12 Quit Gallomimia (Read error: No route to host) 07.02.28 Quit prof_wolfff (Ping timeout: 246 seconds) 07.03.24 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 07.30.58 Quit [Saint] (Remote host closed the connection) 07.33.09 Join [Saint] [0] (~saint@rockbox/user/saint) 08.11.55 *** Saving seen data "./dancer.seen" 08.13.54 # [Saint]: how to know, what git revision corresponds with a point release (say 3.7) 08.23.06 Join _jhMikeS_ [0] (~jethead71@50.4.240.19) 08.23.07 Quit _jhMikeS_ (Changing host) 08.23.07 Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) 08.23.07 Quit jhMikeS (Disconnected by services) 08.23.07 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@rockbox/developer/jhMikeS) 08.29.59 Quit Prodicus (Read error: Connection reset by peer) 08.30.26 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 08.35.00 # <[Saint]> jnc: I'm fairly sure there's easier ways (or ways to do this more directly that aren't necessarily any harder nor easier), but you can look up the revisison from which the release was tagged from fairly trivially. 08.35.09 # <[Saint]> http://git.rockbox.org/?p=rockbox.git;a=tags for example 08.35.23 # * [Saint] hand typed that url, so he hopes he got the syntax right. 08.36.56 # <[Saint]> Then you can do "git reset --hard HEAD~XXXXXXX where XXXXXXX == the revisions unique hash 08.37.21 # <[Saint]> *"git reset --hard HEAD~XXXXXXX" 08.38.52 # <[Saint]> If you have any local changes you need kept, stash them first with "git stash" and then re-apply them (if desired/needed) after the new checkout with "git stash pop". 08.39.25 # * [Saint] suspects someone will now chime in and rail me on my horrible git workflow :P 08.40.40 # <[Saint]> Now, I'm even less sure about this one, but, I'll try: 08.42.15 # <[Saint]> If the revision you need to check out was before the git transition and you know the specific svn revision you can do "git log 1 --grep=@rXXXXXX" where rXXXXXX == the known subversion revision. 08.42.48 # <[Saint]> errr, "git log -n --grep=@rXXXXXX", rather. 08.43.15 # <[Saint]> That should return the commit description and the hash identifier. 08.43.36 # <[Saint]> You would then pass the has identifier to the command listed above. 08.43.44 # <[Saint]> *hash 08.46.05 # thanks 08.47.14 # <[Saint]> So, for example, you could look at http://git.rockbox.org/?p=rockbox.git;a=tags and see that the 3.12 release was tagged from 2ee456528104451945c2e8370eea513e1831f55b by clicking on the commit description. 08.48.08 # before your suggestion, I was grepping through git log 08.48.17 # <[Saint]> We'd then pass the first seven digits (this is almost always enough for a unique identifier) of that hash to the "git reset --hard HEAD~XXXXXXX" command. 08.48.23 # much better to do it the right way now :) 08.49.18 # <[Saint]> So, "git reset --hard HEAD~2ee4565" would checkout the 3.12 release over you current repo. 08.50.11 Join stoffel [0] (~quassel@pD9E41193.dip.t-dialin.net) 08.50.26 # <[Saint]> you should also be able to grep the git log for "Tag Release" 08.52.24 # [Saint]: "Tag Release" not appearing in git log? I don't know 08.53.33 # browsing the tags on the web tool looks better to me 08.55.46 # <[Saint]> Hum, grepping the log for 'Tag Release' was just a guess I suspected /may/ work, sorry. 08.56.07 # <[Saint]> I assumed grepping the log would include the commit description 08.56.51 # it does say some things like "bumping to version 3.7" but not about the final tag and point release 08.57.09 # I am glad you explain to me how to find out the real commit relation 08.57.12 # * jnc :) 08.57.45 # <[Saint]> iirc, the commit description for tagging a release should always be "Tag Release *.*" 08.57.50 # * [Saint] shrugs 08.58.11 # <[Saint]> or Tag *.* Release 08.58.16 # <[Saint]> ...something like this. 09.01.27 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 09.03.27 # <[Saint]> But, yeah. I shouldn't have just guessed it'd work like that, sorry. I know enough in git to do the things I need to do, but I'm certainly no git guru, heh. :) 09.07.11 Join the-kyle [0] (~kyle@24.211.185.30) 09.18.12 Quit sakax (Ping timeout: 264 seconds) 09.20.58 Join kevku [0] (x@2001:470:28:773::3) 09.25.56 Quit Prodicus (Ping timeout: 248 seconds) 09.30.09 Join sakax [0] (~sakax@d8D862498.access.telenet.be) 09.35.12 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 09.37.55 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 09.38.04 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 09.38.40 Quit akaWolf (Client Quit) 09.57.54 Quit the-kyle (Read error: Connection reset by peer) 09.58.20 Join the-kyle [0] (~kyle@24.211.185.30) 09.59.15 Quit Gallomimia (Quit: I am likely going to change locations) 10.05.06 Join lorenzo92 [0] (~chatzilla@host49-110-dynamic.17-79-r.retail.telecomitalia.it) 10.07.44 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.07.44 Quit pamaury (Changing host) 10.07.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.11.56 *** Saving seen data "./dancer.seen" 10.15.18 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 10.15.18 Quit n1s (Changing host) 10.15.18 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.15.24 Quit lorenzo92 (Quit: ChatZilla 0.9.89 [Firefox 17.0/20121120062532]) 10.27.19 Join ender [0] (krneki@foo.eternallybored.org) 10.30.07 # anyone run rockboxdev.sh on OSX recently? 11.02.49 Join B4gder [241] (~daniel@rockbox/developer/bagder) 11.04.09 Quit Bagder (Read error: Operation timed out) 11.04.16 Join Horscht [0] (~Horscht@xbmc/user/horscht) 11.05.41 # saratoga_: you are the one who looked at the RMMA results of the fuze+ last time right ? 11.09.15 Quit sakax (Remote host closed the connection) 11.13.43 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 11.22.54 Join lebellium [0] (~chatzilla@g231222003.adsl.alicedsl.de) 11.24.25 Quit sciopath (Quit: Quitte) 11.30.08 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 11.31.40 Quit B4gder (Read error: Connection reset by peer) 11.31.47 # anyone know how to build gcc-sh on osx? getting errors building stmp-multilib (i tihnk) 11.33.53 Join Bagder [241] (~daniel@rockbox/developer/bagder) 11.41.59 Quit akaWolf (Quit: my exit) 12.07.22 Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) 12.10.37 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 12.11.58 *** Saving seen data "./dancer.seen" 12.12.39 Quit sciopath (Ping timeout: 260 seconds) 12.14.16 Quit [Saint] (Read error: Connection reset by peer) 12.16.39 Join [Saint] [0] (~saint@rockbox/user/saint) 12.17.19 Join Topy44|2 [0] (kvirc@f048012242.adsl.alicedsl.de) 12.17.28 Quit stoffel (Remote host closed the connection) 12.20.32 Quit Topy44 (Ping timeout: 252 seconds) 12.22.02 Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) 12.30.03 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 12.31.28 Quit fs-bluebot (Ping timeout: 246 seconds) 12.32.40 # hmm, why cant my build client build the checkwps? really old (or too new??) gcc? 12.32.46 Join fs-bluebot [0] (~fs-bluebo@g224239199.adsl.alicedsl.de) 12.33.39 Quit bluebrother^ (Ping timeout: 260 seconds) 12.34.59 Quit Provel (Read error: Connection reset by peer) 12.36.09 # [Saint]: historically we haven't treated USB as a strict requirement for stable 12.36.37 # And the USB detection change on nano2g somewhat depends on USB working at all... 12.37.27 # Also, I suspect you're never going to see tags and branches in regular git log. They don't change the code 12.47.40 Quit the-kyle (Quit: Leaving.) 12.47.40 Join the-kyle1 [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 12.52.43 Quit jhMikeS (Ping timeout: 256 seconds) 12.53.41 # can the build clients be told to not build checkwps? 12.53.46 # apparently my gcc is busted 12.54.51 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 13.23.16 Quit [Saint] (Remote host closed the connection) 13.33.04 Join Guest44874 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 13.33.52 Quit Rower85 (Ping timeout: 256 seconds) 13.47.48 # saratoga_: just as a note - the Iaudios do have dual boot for a while now (since DevCon IIRC). I believe the Gigabeats still don't have though 13.53.45 # if that's the case, all documentation on rockbox website is outdated 14.11.59 *** Saving seen data "./dancer.seen" 14.15.40 Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) 14.18.08 Join Poodlemastah [0] (~Poodlemas@h-253-206.a218.priv.bahnhof.se) 14.24.51 # That is no surprise 14.37.21 # <[7]> saratoga_: I don't really see a roadblock on making a classic RB bootloader 14.37.33 # <[7]> there's no real difficulty there 14.37.41 # <[7]> the problem is getting that bootloader installed 14.38.06 # <[7]> we currently use the emcore kernel for the bootloader because we currently need the emcore kernel to handle the installation of the bootloader 14.38.17 # <[7]> because the bootloader needs to be flashed to the NOR on the classic 14.38.51 # <[7]> we can only boot from the firmware partition with very old apple bootloader versions on the first generation classic that still have a buffer overflow vulnerability 14.39.36 # <[7]> sure, we could make the emcore installer install a rockbox bootloader 14.39.57 # <[7]> but I don't see a way to get completely rid of emcore without much effort 14.40.33 # <[7]> we'd not only need a bootloader, but also an installer, because we cannot directly flash a classic, but instead have to write a flasher that we boot on it 14.40.49 # <[7]> sure, that could be done in a much more simple way than emcore does it 14.42.00 # <[7]> and then we still need rbutil to handle booting that flasher somehow, i.e. it needs to instruct the user how to enter DFU mode, and connect to DFU (which requires either itunes to be installed, but several itunes processes/services to be stopped, or a custom driver that conflicts with itunes) 14.42.59 # <[7]> Within the amount of time that I have available I'd do my best to support whichever route you choose 14.43.26 # <[7]> but tbh I think that time would be better spent on nailing down this nasty usb breakage 14.44.04 # * gevaerts agrees 14.45.38 # If the problem is "emcore/freemyipod might go away", we could just mirror the relevant bits. We could even provide our own "official rockbox" emcore builds if we want to 14.48.35 # <[7]> it might make sense to make a "rockbox bootloader" app on top of emcore, which replaces the (more fancy, but more bloated) emcore bootloader 14.48.57 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 14.49.50 # <[7]> that app would probably be a 5-liner or something like that :) 14.49.50 # <[7]> because the kernel and libboot handle most of what it needs 14.50.36 # <[7]> basically removing the whole graphical UI and boot options, making it try to boot rockbox if possible, and fall back to a flashed rockbox if not 14.50.50 # <[7]> if the flashed rockbx is missing as well for some odd reason, just bail out on the console 14.51.42 # <[7]> that would remove the complexity that the boot menu introduces, but has some disadvantages as well: you have no way to access storage except through rockbox 14.51.42 # * gevaerts hasn't seen emcore in action, so he doesn't really know *how* fancy the emcore bootloader is 14.52.28 # I think we should try to keep the storage bits 14.52.28 # <[7]> so by dropping in a broken rockbox binary you could screw things up badly 14.53.16 # Anyway, that still requires emcore, so let's start by making emcore acceptable for rockbox 14.53.25 # <[7]> emcore doesn't do usb mass storage either, the emcore bootloader merely has options to manually boot the flashed rockbox fallback image, and to nuke the database and settings in case those prevent rockbox from booting 14.53.39 # scorche`, gevaerts: To expand upon gevaerts query on the 26th asking if there was a way to require active moderator approval for someone's first posts and scorche` replying that moderation appears to be board based not user group based: Couldn't we just block ALL normal boards from the "New User" group and require an obviously human post from someone in the "New User" group to whatever board we give them access to before they get manually added to the " 14.53.39 # Regular User" group? 14.54.26 # soap: that's actually outdated. We *can* require moderator approval for first post (or any number of first posts) if we want to 14.54.32 # <[7]> fyi, emcore shares the (old) usb lowlevel driver, as well as the storage/fat subsystems with rockbox, but has a different kernel below that (preemptive multitasking, memory allocator) 14.55.18 # [7]: so basically USB storage means booting the flashed rockbox image? 14.55.27 # <[7]> yes 14.55.46 # OK. I assume detecting a button to do that wouldn't be too hard 14.56.09 # <[7]> (you can also access storage through the emcore kernel debugging interface, but that's not targeted at end users) 14.56.36 # <[7]> sure, that can be done, but there's still the problem with a corrupted config/database/whatever making the fallback image lock up during boot 14.56.41 # <[7]> I've seen that happen several times 14.56.51 # Right 14.57.15 # <[7]> ideally we'd just fix dualboot and boot into disk mode when some button is pressed 14.57.31 # Yes, of course, but that depends on unknowns 14.57.52 # <[7]> it depends on figuring out what on earth we're doing that locks up the OF's i2c driver 14.58.08 # <[7]> probably not all that complicated, but debugging that is a bitch 14.58.44 # and sorry for interrupting again, but so bans still bog down the forums, but not for quite as long. 14.59.26 # I'd say one realistic option would be to make a traditional rockbox-style bootloader that does USB on button or failed boot, have that as the flashed image, and always boot that from emcore 15.00.44 Join TheSphinX^ [0] (~briehl@91.50.41.57) 15.00.49 Quit TheSphinX_ (Read error: Operation timed out) 15.01.09 # soap: I haven't noticed that, but then I've only banned one account in the past week.. 15.01.26 # I'd say that as long as we're at the current banning rate, it's not a problem 15.02.09 # I agree with that unless the fix is as simple as adding an index to the DB as Zagor postulated. 15.02.37 # <[7]> gevaerts: shouldn't be too hard to flash that directly, and just rely on emcore loader to do the HW init and install it through an emcore installer 15.02.38 # And, to be clear, the lag is less, but the test I just ran froze forum access for 50 seconds. 15.03.35 # soap: ok. I'd say that as long as scorche hasn't found time to look into that, it's not a problem :) 15.04.57 # <[7]> currently the boot process looks like this: bootrom loads emcore loader from nor and sigchecks it, emcore loader escapes through an exploit. then emcore loader initializes i2c, pmu, sdram, lcd and spi, and loads the emcore kernel from NOR 15.06.07 # <[7]> then the emcore kernel parses its embedded boot configuration, and locates the file to be booted on the nor, which is the emcore boot menu. that in turn tells the kernel to load libui, libpng and libboot, and displays the boot UI. once the user has selected an option, the binary for that is loaded from NOR or HDD, and executed 15.06.56 # <[7]> if we jump in at the emcore boot menu stage, we can make a 5 liner that loads something else and runs it like rockbox 15.07.44 # <[7]> but actually booting the emcore kernel is already somewhat similar to booting rockbox, so we could just drop in a rockbox bootloader instead of the emcore kernel 15.07.53 # right 15.08.09 # So we'd only borrow the emcore loader 15.08.18 # (and installation stuff) 15.08.55 # <[7]> yes, and the installation process 15.08.55 # <[7]> and IMO the installation process is currently the most annoying part from a user's perspective, not the boot menu... so maybe we should tackle that first 15.09.20 # Maybe 15.09.34 # <[7]> the emcore loader is much smaller than emcore, it's some selfcontained assembly blob 15.10.26 # On the other hand, the boot stuff would (I think) allow us to get rid of the "unstable" stigma, which might help find more people to work on the rest 15.10.29 # *unusable 15.14.43 # <[7]> well, but that's a purely artificial problem 15.15.22 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 15.15.44 # It is, yes 15.15.56 # <[7]> I don't see how having a flaky, complicated, non-automated method of installation is any better than using a well-working 3rd-party bootloader 15.16.05 Quit Guest44874 (Ping timeout: 256 seconds) 15.16.35 # <[7]> you could of course write your own flasher to get rid of emcore during installation as well 15.17.08 # <[7]> isn't that complicated, but would drop the on-device installation confirmation and status UI. the question is whether we want that or not. 15.17.24 # <[7]> which would remove all freemyipod stuff except for the emcore loader 15.17.34 # I think any solution that involves actually rewriting stuff isn't a good idea 15.18.02 # <[7]> well it isn't that much stuff that needs to be rewritten. it's more like throwing out 90% of the existing stuff 15.18.05 # * gevaerts personally doesn't think relying on freemyipod stuff is that much of a problem 15.18.45 # <[7]> well I don't view it from that aspect at all, I'm looking at it from a bloated vs. simplified aspect 15.19.11 # <[7]> because 90% of what happens during installation isn't really required at all and only related to UI 15.19.21 # <[7]> the actual flashing is like 50 lines of C code 15.19.51 # <[7]> and there isn't really anything that can go wrong during this process, so we don't really need status feedback 15.20.06 # <[7]> emcore just seems overkill for that purpose 15.21.25 # <[7]> the emcore installer could handle unpacking a rockbox zip to the hdd during installation, but we currently don't use that feature either 15.28.10 Quit ender (Read error: Operation timed out) 15.31.00 Join Prodicus [0] (~chatzilla@69.169.144.239.provo.static.broadweavenetworks.net) 15.33.29 Join ender [0] (krneki@foo.eternallybored.org) 16.01.43 # i agree that it's the installation process, rather than the bootloader that's the bigger problem 16.11.49 Quit nateloaf (Quit: Leaving.) 16.12.03 *** Saving seen data "./dancer.seen" 16.23.03 # <[7]> but I don't see how we could make the installation process much easier 16.23.41 # <[7]> it's fairly easy on linux but the usual driver nightmare on windows - maybe write some tool that uses setupapi or DIFx to automate driver installation 16.24.19 # <[7]> then again umsboot is causing a lot of issues on some pcs, we might want to get rid of that 16.24.46 # <[7]> if we decide to go for an emcore-less setup, we could probably squeeze it all into the DFU binary and skip that step 16.25.20 # <[7]> but OTOH it would be better to finally nail down the root cause of this usb problem... 16.28.50 # <[7]> it's fairly easy on linux but the usual driver nightmare on windows 16.28.58 # yeah I didn't manage to do it on Windows 16.29.09 # I tried many times 16.30.04 # <[7]> copper: did you fail at 1. bringing the device into DFU mode, 2. getting the tool to recognize the ipod, or 3. getting UMSboot to mount to copy the installer? 16.30.42 # 1) succeeded but nothing was happening in Windows 16.30.53 # <[7]> with or without itunes installed? 16.30.58 # and the tool didn't find the device 16.31.02 # both 16.31.23 # without iTunes, the "device" driver always failed to install properly 16.31.50 # but then I had a crappy Asus Windows install at the time 16.31.56 # I didn't try again on my clean Win 7 install 16.34.18 # the Asus Windows install was Windows 7 as well, just loaded with a shitload of crapware 16.38.50 Join TheSphinX_ [0] (~briehl@p5B323222.dip.t-dialin.net) 16.40.32 Quit TheSphinX^ (Ping timeout: 245 seconds) 16.41.48 Join Ward [0] (~Mirandaha@109.190.120.176) 16.42.12 Nick Ward is now known as Guest38219 (~Mirandaha@109.190.120.176) 16.42.35 Quit XavierGr (Ping timeout: 265 seconds) 16.42.51 Join pedro_angelo [0] (~pedro_ang@201.19.138.6) 16.47.50 Join TheSphinX^ [0] (~briehl@p579CCDC9.dip.t-dialin.net) 16.48.59 Join SuperBrainAK [0] (~Andy@97-124-80-200.phnx.qwest.net) 16.49.40 Quit TheSphinX_ (Ping timeout: 248 seconds) 16.54.21 Join TheSphinX_ [0] (~briehl@p579CC0D0.dip.t-dialin.net) 16.57.11 Quit TheSphinX^ (Ping timeout: 264 seconds) 17.00.08 Quit lebellium (Ping timeout: 256 seconds) 17.13.09 Join LjL [0] (~ljl@unaffiliated/ljl) 17.14.26 Quit ender (Quit: 9% of lawyers give the rest a bad name.) 17.14.48 # hello. i was looking at the Sansa Clip Zip (i have a Clip+ currently), and while i gather that RockBox is still unstable, i don't seem to find very detailed information, like there are for other players, on what works and what doesn't. i seem to get the general impression it's marked unstable but, basically, everything works fine, is this accurate? 17.14.52 Join ender [0] (krneki@foo.eternallybored.org) 17.15.43 # yes, it's about as stable as the clip+ 17.15.55 # which is quite similar in hardware too 17.16.49 # some themes make the clip zip behave weirdly, but that likely not a player-specific problem 17.17.11 Quit ender (Client Quit) 17.17.19 # I think also some colours are a bit off for some clip zips with a particular type of display 17.18.05 # and perhaps one of the snake plugins doesn't quite work, but I can't remember if this was fixed already 17.18.59 # well, seems like nothing serious. the one thing i've read on the wiki is that the USB may have problems, with two bug reports about file corruption... but it doesn't exactly look like those two reports are filled with comments confirming the issues 17.19.07 Join ender [0] (krneki@foo.eternallybored.org) 17.35.51 Join sentriz [0] (~Senan@78.143.151.93) 17.51.29 Join lazer [0] (~lazer@212.90.156.52) 18.05.38 Join lebellium [0] (~chatzilla@92.231.222.3) 18.08.08 Quit Rower85 (Ping timeout: 265 seconds) 18.09.19 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 18.12.06 *** Saving seen data "./dancer.seen" 18.14.36 Quit Buglouse (Read error: Connection reset by peer) 18.33.49 Quit Guest38219 (Read error: Connection reset by peer) 18.40.06 Quit SuperBrainAK (Ping timeout: 260 seconds) 18.41.25 Join trees_ [0] (~orionaai3@66.130.233.244) 18.42.14 # wondering about something 18.43.23 # what format would you recommend to get best audio-quality vs compression; nothing that sounds weaker than a 256mp3 but ideally nothing as big as flac files I have already 18.43.51 # Vorbis -q 5 (~160 kbps) is generally transparent 18.43.56 # I have only got experience working with mp3 and FLAC (well and shit like wav n stuff) 18.44.40 # vorbis eh? Never used it, is free/easy to acquire codecs needed for conversion? 18.44.40 # there's lossyFLAC if you're anal about being 100% sure that you won't get any artifacts - they're about half the size of FLACs (~440 kbps) 18.44.53 # yes Vorbis is free 18.44.58 # Free as in Speech 18.45.02 # and as in beer 18.45.02 # I use f2k for conversion so am assuming it'd be easy 18.45.03 # :D 18.45.35 # lossyFLAC eh? Sounds a bit redundant 18.46.05 # thank you, am looking forward to pretending my 1Gig ipod nano has enough room for music 18.46.24 # is it rockboxed? 18.46.28 # ofc 18.46.33 # rockbox to the end 18.46.38 # :D 18.46.46 # you could maximize space by using Opus at 96-128 kbps 18.46.51 # with a dev build of rockbox 18.46.53 Quit radio23 (Remote host closed the connection) 18.46.55 # if any devs are here btw, this big ugly cap-locked THANKU is for you 18.47.00 Join radio23 [0] (radio23@newelite.bshellz.net) 18.47.09 # \umm... 96-128 sounds aweful tho 18.47.15 # not with Opus 18.47.17 # oh? 18.47.28 # Opus is the latest lossy codec 18.47.31 # Never even heard of Opus 18.47.47 # Ill check it out.... thanks :> 18.50.02 # Opus is not very fast on rockbox yet so it will suck more battery than mp3/vorbis 18.50.59 # oh. 18.51.01 # this is relevant 18.51.23 # as this ipod is a pos and the battery is more deteriorated than not at this point I get 1hr MAX listening time 18.51.43 # what it comes down to is that I need to get a sansa w the SD expansion slot 18.53.38 Nick the-kyle1 is now known as the-kyle (~kyle@cpe-024-211-185-030.nc.res.rr.com) 18.53.51 Quit Horscht (Quit: Verlassend) 18.54.00 # Musepack is the most battery efficient lossy codec I think 18.54.26 # but it's tuned for transparency at about 170 kbps 18.54.29 # hmmm.... Musepack eh? hows the compression quality? 18.54.52 # at the default quality setting (~170), it's great 18.55.13 # as it stands all that I have loaded on the rockbox is 320mp3s so that would be on par? 18.56.09 # * gevaerts thinks that all of this is subjective enough to make testing one's own music a requirement 18.56.47 # am thinkin the same thing. Or that I should just upgrade hardware and get somethin w SD expansion 18.56.53 # if you can distinguish musepak at 170 from MP3 @ 320 from MP3 @ half that average bitrate I'll give you a 4GB Nano. This really is drifting far from #rockbox 18.58.10 # 'from mp3 at half that average bitrate'.... meaning somethin like 160mp3? 18.58.30 # assuming VBR, yes. 18.59.15 # okay well that is something of a moot point but I can take the hint. One last question tho 18.59.20 Quit sentriz (Ping timeout: 252 seconds) 18.59.42 # Ive been needing to upgrade hardware for quite some time now... what SD card supporting rockbox supporting player do you advise? 18.59.48 # You mentioned foobar already. Use the ABX plugin for it. I'll be shocked if you can successfully ABX a 320kbps MP3 from a -V5 (~128kbps VRB) MP3. There. I more than doubled your storage for you. 19.00.13 # umm 19.00.20 # Any which takes SD cards and is "supported" is good-to-go. 19.01.12 # okay soap not gonna debate with you but for what its worth 128s sound weak and dull compared to 320s. Particularly when theres organic sounding basslines 19.01.43 # anyways, thanks for the info guys. Take care and fare well... 19.01.46 # There is no basis for that claim. basslines are the easiest thing to encode. Blind test with the ABX comparator. 19.01.59 # placebo is a powerful thing. 19.03.04 # there is no basis for opinion and hearing. We all hear differently, I wouldnt be clogging up what little storage I have w clunky 320s if I didnt mind hearing my tunes in 128 but like I said I dont want to get into a debate about codecs so lets agree to disagree. Ciao. 19.03.13 Quit trees_ (Quit: pz) 19.17.12 # he didn't get your message 19.17.53 # expectation bias and ABX tests are surprisingly hard to explain to people 19.20.01 Join Ward [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 19.20.26 Nick Ward is now known as Guest20990 (~Mirandaha@176-120-190-109.dsl.ovh.fr) 19.21.59 # it's very hard for people to let go of the complete trust they have in their own ears 19.22.26 Quit KiwiCam (Remote host closed the connection) 19.42.16 Quit Guest20990 (Quit: Blarglarg) 19.52.02 # copper: I've been mucking about with Opus, and I cannot tell the difference (with headphones) between my source 44.1KHz/16-bit music and the Opus encoded output ; while I do notice differences with say Vorbis or MP3 even at higher bitrates 19.52.23 # for me it sounds good enough 19.52.48 # by doing ABX tests? 19.52.54 # yeah 19.53.32 # what's you're threshold on MP3/Vorbis? 19.53.35 # your* 19.54.01 # well I go to 320kbps and MP3 is almost the same, but I still somehow always pick it out 19.54.16 # p value < 0.05? 19.54.19 # and Vorbis has a few corner cases where it does not encode well, and I can pick that out 19.57.02 # don't know about p value, did it with a shell script and compared notes after 5 runs 19.57.14 # probably not statistically interesting :) 19.57.32 # er 19.57.43 # you need proper ABX software and like 12 runs 19.58.15 # foobar2000 with the ABX comparator component on Windows, squishyball on linux 19.58.37 Join webguest95 [0] (~5770a861@www.haxx.se) 19.58.38 # interesting, will take note of "squishyball" 19.58.47 Join pretty_function [0] (~sigBART@123.252.212.97) 19.59.14 # anyone looking for a cheap Samsung Z5? http://www.ebay.co.uk/itm/Samsung-Yepp-YP-Z5-1-GB-Digital-Media-Player-/170950103817?pt=UK_AudioTVElectronics_PortableAudio_MP3Players&hash=item27cd6b9309 19.59.34 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 19.59.34 Quit webguest95 (Client Quit) 20.00.45 # copper: do you know, how should I proceed to find out what broke between v3_7 and v3_8 ? git bissect won't work 20.01.20 # I'm not a Rockbox developer 20.01.24 # oh okay 20.02.01 # btw, 5 good guesses out of 5 is the required minimum 20.02.06 # 4 out of 5 doesn't cut it 20.02.30 # but 12-16 runs is best 20.03.19 # AlexP: now it works... :) 20.03.20 # jnc: in what way doesn't git bisect work? 20.03.40 # lazer: Glad to hear it 20.05.05 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 20.05.10 # I had to install the new bootload v7pre4 and to install the the firmware to rom and ram 20.06.14 # I can now boot from rom or ram but not from compact flash... but it works. When the player runs it detects the compact flash. 20.08.09 # gevaerts: it's saying that v3_7 is a branch, and head is not; something like that 20.08.21 # gevaerts: 'merge base' 20.08.26 # OK, so you basically need to find the branch points 20.09.09 # gevaerts: yes, could use a little help understanding what that means. I researched and found a picture that explains, but I don't know what to do about it 20.09.45 # also I'm unfamiliar with how rockbox git and svn correlate "back then in time" 20.10.33 # jnc: f1fd602 is the last revision before the 3.7 branch, 48b1a2d is the last one before 3.8 20.10.59 # There's a better way I can't remember, but I found those using git log --graph --oneline --all 20.11.38 # * jnc pokes keyboard some more 20.12.08 *** Saving seen data "./dancer.seen" 20.12.45 # gevaerts: FYI though 3.7 final was okay and I can't make it crash in usb mode on fuze v1 ; maybe a fluke? badblocks is pretty good at triggering failure mode 20.13.51 # Hard to say. You never know... 20.22.00 Join SuperBrainAK [0] (~Andy@97-124-80-200.phnx.qwest.net) 20.26.18 # gevaerts: is the theory that all 3.7 branch should have been merged in before making 3.8 branch? 20.26.41 # No. The 3.7 branch shouldn't have anything that's not in master 20.26.47 # ah okay 20.35.29 # we basically just take all the master, declare ti stable and branch for releases 20.35.33 # nothing really gets merged 20.36.11 # then maybe a couple fixes go in before we release the binary 20.36.44 # pamaury: yes, but i have no idea whats with those RMAA graphs you posted, never seen that before 20.37.28 # Bagder, Zagor: could one of you update the website with the Clip Zip stable? 20.37.30 # it's weird that the frequency response has such a behaviour in the 10K range 20.37.33 # i pushed it last night 20.37.58 # pamaury: link? 20.38.29 # is it stable? 20.38.31 # see the fuze+ forum thread or this http://amaury.pouly.free.fr/Images/Comparison3.htm 20.39.14 # wth? 20.39.49 # saratoga_: should we declare it stable outside of a release? There's no 3.12 for it... 20.39.55 # That might confuse people 20.40.19 # do we usually wait for a release? i don't remember doing that 20.40.39 # copper: are you familiar with such graphs ? 20.40.43 # I *think* we do, but I'm not sure now 20.41.23 # pamaury: I'm familiar with RMAA yes 20.42.45 # and what's the forum thread? 20.43.07 # http://forums.rockbox.org/index.php/topic,26284.570.html 20.43.58 # those noise levels are pretty bad 20.44.35 # we are comparable to the OF though 20.44.45 Quit Gallomimia (Read error: No route to host) 20.44.49 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 20.44.56 Nick ukleinek_ is now known as ukleinek (~ukl@port-212-202-120-50.static.qsc.de) 20.45.05 # I just wonder if it's the Fuze+ or the sound card 20.45.19 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 20.45.25 # I'm guessing it's the soundcard 20.45.35 # pamaury: Where to look for usb_state problem? 20.46.11 # copper: this http://amaury.pouly.free.fr/Images/Comparison.htm for the test with my sound card as reference 20.46.27 # might come from my sound card 20.46.53 # wodz: wait a minute, I'll give you pointers in a sec 20.47.15 # so the Fuze+ is really that bad?? 20.47.28 # copper: those noise levels are very good 20.47.40 # I don't call it bad 20.47.47 # mostly because thats an unloaded test though 20.47.54 # yeah of course 20.48.06 Quit akaWolf (Ping timeout: 265 seconds) 20.48.18 Quit pretty_function (Ping timeout: 260 seconds) 20.48.23 # they're way higher than the Clip+ 20.48.51 # http://outpost.fr/rmaa/Clip.htm 20.49.10 # 3 dB difference 20.49.35 # probably just due to differences in the volume level between the tests 20.50.13 # I was looking at the OF figures 20.50.20 # again those are both unloaded tests though, so basically meaningless 20.51.07 # IIRC a sine wave at-70 dBFSS is audible 20.51.28 # hmmm my term screwed up 20.51.34 # I mostly did the test because there was a noticable noise on the fuze+ which revealed a problem, now that should be better 20.51.41 # -70 dBFS isn't really a volume 20.51.57 # so its hard to evaluate what that statement means 20.52.15 # you'd need to know what FS is 20.52.39 # a sine at -70 dBFS played back at my usual listening volume 20.52.53 # Interesting that before the changes FR was the same between OF and RB, as was crosstalk. Noise THD went way down with the changes, crosstalk improved, and FR got a bit wonky. 20.53.32 # wodz: so you said that usb_state stays as USB_EXTRACTED ? 20.54.28 Join cela [0] (~cela@87.112.168.97) 20.55.14 Join sakax [0] (~sakax@d8D862498.access.telenet.be) 20.55.24 # pamaury: yes 20.56.30 # wodz: you can either remove #define USB_STATUS_BY_EVENT is config.h for rk27xx target OR implement status by interrupt in usb-drv-rk27xx.c by call calling usb_status_event(USB_INSERTED); on connection and usb_status_event(USB_EXTRACTION); on disconnection. I think interrupt 7 of the udc is connection status (even though it's marked as reserved) 20.57.08 # I get a crash after I unplug the usb on Fuze+ when in bootloader transfer mode, my bootloader states version 1.0. Is there an update to fix this issue? 20.58.35 # cela: commonly reported problem, looking at flyspray reports 20.59.15 # unfortunately it's not clear that the bootloader in the trunk is much better w.r.t to this issue, we could release a new version though 21.00.35 # pamaury: How do you know about int 7? Have you tested this on your rk27xx? 21.00.55 # iirc yes and I had a look at the rom to notice that 21.01.06 # but check my yourself, I'm not 100% sure 21.01.58 # Interesting, will check. Ok the other route is to remove USB_STATUS_BY_EVENT define. Do I need something special in this case? 21.02.06 # Is there a newer bootloader version than 1.0 for Fuze+ , the main Fuze+ port itself is much more stable than it used to be , thank you for all the good work. 21.03.22 Part cela 21.04.03 # no there is none but I want to do a release (yes I've said this for a long time I known). 21.04.13 # pamaury: ^ 21.04.13 # wodz: iirc no, it will poll usb_detect in a thread 21.04.18 # ah ok 21.04.33 Quit y4n (Quit: Today is the perfect day for a perfect day.) 21.05.09 # int 7 is triggered on connection, don't know if it retriggers on extraction. 21.10.25 # pamaury: according to SDK this irq should trigger both on connect and disconnect - will check 21.11.20 Quit Gallomimia (Read error: Connection reset by peer) 21.11.51 # * pamaury leaves for a moment 21.12.07 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 21.15.20 Join Robin0800 [0] (~quassel@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 21.17.09 Quit Gallomimia (Ping timeout: 260 seconds) 21.21.05 Quit n1s (Quit: Ex-Chat) 21.34.45 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 21.37.16 # ok this int triggers both on usb connection and disconnection 21.39.57 Quit lazer (Read error: Connection timed out) 21.40.36 Join lazer [0] (~lazer@212.90.156.52) 21.41.04 # hmm, wrong it trigger on connect only 21.41.26 # wodz: perhaps there is one for disconnection ? 21.42.45 # wodz: manual states it is triggered on connection (and says nothing about disconnection) 21.43.03 # hmm, it seems to trigger for disconnection but I can't distinguish it from connection. 21.43.05 # in this case you should use the usb_detetc mechanism 21.43.26 # ok, lets see 21.48.46 # I am too tired to analyze this properly but with USB_STATUS_BY_EVENT commented out it is not any better 21.49.22 Quit wodz (Quit: Leaving) 21.50.27 Join sentriz [0] (~Senan@78.143.151.93) 21.50.41 # wodz (logs): perhaps usb_detect needs to return different values, i'll have a look later 21.55.52 Quit saratoga_ (Ping timeout: 245 seconds) 22.08.17 Quit lazer (Quit: Verlassend) 22.12.12 *** Saving seen data "./dancer.seen" 22.14.17 Quit Buglouse (Ping timeout: 245 seconds) 22.37.00 Join Buglouse [0] (~Buglouse@unaffiliated/Buglouse) 23.01.29 Quit Gallomimia (Read error: Connection reset by peer) 23.11.03 Quit Rower85 (Quit: Hmmm...) 23.12.13 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 23.15.27 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 23.33.58 Quit sentriz (Ping timeout: 252 seconds) 23.39.20 Join jhMikeS [0] (~jethead71@50.4.240.19) 23.39.20 Quit jhMikeS (Changing host) 23.39.21 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 23.42.11 Quit Belzebub (Ping timeout: 264 seconds) 23.53.16 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 18.0/20121128060531]) 23.53.23 Quit bertrik (Remote host closed the connection) 23.55.55 Join Guest44874 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 23.58.33 Quit Rower85 (Ping timeout: 256 seconds)