--- Log for 06.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 5 hours ago 00.00.42 # ahhh 00.00.45 # too long! 00.00.58 # ah the abstract only 00.01.35 # kugel: if I understand the documentation correctly, it shouldn't be public. I'm not entirely sure though 00.02.42 # gevaerts: works great. thanks 00.03.03 # gevaerts: will add the tool to my music sync-script 00.03.26 # kwbr: you can also do it using sg3-utils and hand-assembling the SCSI packet :) 00.03.38 # amiconn: how do you figure? 00.03.41 Quit RadicalR (Read error: Connection reset by peer) 00.03.42 # * S_a_i_n_t was fairly certain thata restore with itunes synced the time on an iPod. 00.04.01 # S_a_i_n_t: most people try to avoid restoring too often 00.04.12 # Well, I've only ever set the timezone on mine, and the time is always right. 00.04.28 # S_a_i_n_t: itunes syncs the clock every time 00.04.32 # saratoga: ldm reduces code size -> better caching, and if the code memory is uncached, same thing - fetching fewer instructions 00.04.36 # As do I, but what would cause it to reset the time? 00.04.55 # amiconn: but a loop will be entirely cached regardless, its only 1-2 cachelines long 00.05.00 # S_a_i_n_t: what? 00.05.21 # Sure, but there's not *only* that loop, there's other code around it 00.05.26 # * kugel shorts the abstract a bit, the full version is still in the proposal 00.05.34 # gevaerts: Ha! I'll check to code... 00.05.39 # (well, unless you're timing just that loop of course... 00.05.53 # yeah we're just timing that loop, its a memory benchmark after all 00.05.58 # kwbr: http://www.rockbox.org/wiki/IpodItunesCommunication#Setting_the_clock has the full details. ipod-time-sync was based on that 00.05.59 Join Doleo [0] (~cc320953@giant.haxx.se) 00.06.00 # Errr, bad wording. I mean, why would the time be incorrect in the first place? 00.06.11 # If the battery ran completely dead...? 00.06.32 # ever heard of clock drift? 00.06.53 # No. 00.06.58 # * S_a_i_n_t googles. 00.07.29 Quit Doleo (Client Quit) 00.07.45 Quit captainkewllllll (Quit: Page closed) 00.08.27 Quit bertrik (Ping timeout: 265 seconds) 00.08.31 Join Doleo [0] (~cc320953@giant.haxx.se) 00.09.51 Quit Doleo (Client Quit) 00.11.48 # submitted! 00.12.52 # saratoga: There's also the possibility that the cache isn't completely single cycle, or not properly initialized somehow 00.13.37 # * amiconn would in fact be very surprised if the PPs would be the only SoCs with bugs like this 00.13.41 Join anewuser [0] (anewuser@201.209.93.62) 00.13.48 Quit anewuser (Changing host) 00.13.48 Join anewuser [0] (anewuser@unaffiliated/anewuser) 00.13.50 # performance is really good so I think cache is working 00.14.10 # though it could be some bug specific to this loop, but i think me making a mistake is more likely :) 00.14.45 # probably cache bugs are less likely on ARM9 and higher since the cache is designed by arm and theres onboard hardware for things like TCM 00.14.49 # so less to screw up 00.15.10 # tcm is only on arm9e 00.15.36 Join Doleo [0] (~chatzilla@d83.u1.csystems.net) 00.18.36 Quit Schmogel (Ping timeout: 265 seconds) 00.18.42 Quit shai (Quit: Leaving) 00.21.16 Quit GeekShadow (Quit: The cake is a lie !) 00.24.23 Quit xiainx (Ping timeout: 252 seconds) 00.30.29 Quit kwbr (Quit: Leaving) 00.32.54 # saratoga - mm, my tremor timings seem unchanged so it seems an accurate measurement -- i.e. old rockbox mdct_arm.S negligable benefit on whatever the nslu2 is, versus about 9% faster with FasterMdct 00.34.50 Join xiainx [0] (xiainx@wpa062091.Wireless.McGill.CA) 00.36.43 # stripwax_: well a lot of the improvement was probably just the ldm/stm stuff, so maybe thats reasonable 00.36.43 Quit antil33t (Read error: Connection reset by peer) 00.37.04 # i don't know if we ever benched it on ARM9, back in those days we only had the GBF 00.37.04 # maybe 00.37.32 Quit ender` (Quit: I went to a restaurant that serves "breakfast at any time." So I ordered French Toast during the Renaissance.) 00.37.50 Quit slck (Ping timeout: 240 seconds) 00.43.02 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 00.45.11 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 00.45.43 Quit domonoky (Read error: Connection reset by peer) 00.47.59 Quit TheSeven (Read error: Connection reset by peer) 00.49.30 Quit Battousai (Ping timeout: 240 seconds) 00.49.44 Join slck [0] (Venci@shellbgcom-1-pt.tunnel.tserv6.fra1.ipv6.he.net) 00.49.54 Quit stripwax_ (Quit: http://miranda-im.org) 00.49.57 Join Battousai [0] (~bryan@gentoo/developer/battousai) 00.50.41 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 00.52.31 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 01.03.00 *** Saving seen data "./dancer.seen" 01.06.54 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 01.09.41 Join TillW [0] (~Till@192.197.54.26) 01.12.47 Join fejfighter [0] (~fejfighte@C-61-68-102-68.hay.connect.net.au) 01.13.35 Quit leavittx (Ping timeout: 240 seconds) 01.13.42 Quit leavittx_ (Ping timeout: 265 seconds) 01.13.42 Quit n17ikh (Ping timeout: 245 seconds) 01.16.02 Quit jacekowski (Killed (idoru (Spam is off topic on freenode.))) 01.19.26 Quit anewuser () 01.19.26 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 01.23.11 Join leavittx [0] (~leavittx@89.221.199.187) 01.24.42 Quit Doleo (Quit: ChatZilla 0.9.86 [Firefox 3.5.6/20091201220228]) 01.25.16 # * flyback taking a nap, bbl 01.26.38 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 01.26.38 Join leavittx_ [0] (~leavittx@89.221.199.187) 01.26.41 Join leavittx__ [0] (~leavittx@89.221.199.187) 01.27.44 Join jacekowski [0] (jacekowski@jacekowski.org) 01.28.44 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 01.28.52 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 01.28.58 Quit arbingordon (Ping timeout: 258 seconds) 01.32.00 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 01.48.21 Quit TillW (Quit: This now concludes our broatcast day.) 01.48.36 Join TillW [0] (~Till@nat026.dc-uoit.net) 01.56.19 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 01.56.55 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 01.57.12 Join arbingordon [0] (~w@unaffiliated/arbingordon) 02.02.55 Quit xiainx (Ping timeout: 268 seconds) 02.12.57 Quit toffe82 (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 02.15.53 Join robin0800 [0] (~robin0800@genkt-050-078.t-mobile.co.uk) 02.18.43 Join cjcopi [0] (~craig@charon.craig.copi.org) 02.27.16 Quit TillW (Ping timeout: 246 seconds) 02.27.43 Join komputes [0] (~komputes@ubuntu/member/komputes) 02.38.47 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 02.42.32 Join TillW [0] (~Till@nat026.dc-uoit.net) 02.48.07 Quit robin0800 (Read error: Connection reset by peer) 02.54.04 Join robin0800 [0] (~robin0800@genkt-050-078.t-mobile.co.uk) 02.58.41 Quit moos (Ping timeout: 276 seconds) 03.00.57 Quit kugel (Remote host closed the connection) 03.03.03 *** Saving seen data "./dancer.seen" 03.08.06 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 03.16.38 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 03.20.00 # Hah! Try this out for size... Modified bookmark.c to write optional tokens to bookmarks and at the same time remain backward compatible with existing bookmarks and bookmarks with other optional tokens. Plus it adds pitch and timestretch tokens by default. 03.21.50 # Make a patch for Flyspray. :) 03.22.56 Quit robin0800 (Remote host closed the connection) 03.24.01 Join robin0800 [0] (~robin0800@genkt-050-078.t-mobile.co.uk) 03.30.15 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 03.33.53 # And it's at FS#11178. Enjoy! 03.34.40 # * flyback wishes there was test code for c140/c150 03.39.00 Part froggyman 03.42.26 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 03.43.27 Quit shaggy-h (Client Quit) 03.45.03 Quit adnyxo (Quit: Leaving) 03.46.01 Quit planetbeing (Read error: Connection reset by peer) 03.46.18 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 03.46.55 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 03.49.34 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 03.49.40 Quit adnyxo (Remote host closed the connection) 03.50.02 Quit TillW (Quit: This now concludes our broatcast day.) 03.53.47 Join robin0800_ [0] (~robin0800@genkt-057-078.t-mobile.co.uk) 03.53.49 Quit robin0800_ (Remote host closed the connection) 03.54.04 Quit robin0800 (Ping timeout: 240 seconds) 03.57.40 Join robin0800 [0] (~robin0800@general-ld-216.t-mobile.co.uk) 03.58.18 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 04.03.29 Quit Chronon (Ping timeout: 265 seconds) 04.08.41 Quit LambdaCalculus37 (Quit: Fwump) 04.08.49 Quit Strife89 (Quit: Going to bed.) 04.11.07 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 04.11.55 Join TillW [0] (~Till@h74-net09.simres.netcampus.ca) 04.22.50 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 04.25.12 Join bieber [0] (~bieber@132.170.44.81) 04.27.49 Join Rob2223 [0] (~Miranda@p4FDCBBF8.dip.t-dialin.net) 04.29.31 Join webguest62 [0] (~5f2277b3@giant.haxx.se) 04.31.30 Quit Rob2222 (Ping timeout: 265 seconds) 04.33.26 Quit webguest62 (Client Quit) 04.41.44 Quit fejfighter (Ping timeout: 248 seconds) 05.00.13 Quit Barahir (Ping timeout: 260 seconds) 05.00.29 Quit bieber (Quit: Leaving) 05.01.53 Join Barahir [0] (~jonathan@gssn-5f75676c.pool.mediaWays.net) 05.03.07 *** Saving seen data "./dancer.seen" 05.04.24 Join CGL [0] (~CGL@190.207.232.170) 05.06.39 Quit komputes (Ping timeout: 246 seconds) 05.14.16 Quit mikroflops (Ping timeout: 248 seconds) 05.15.40 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 05.31.05 Join froggyman [0] (~me@unaffiliated/froggyman) 05.34.47 Part flyback ("Leaving") 05.35.02 Quit froggyman (Read error: Connection reset by peer) 05.35.18 Quit Horscht (Quit: Verlassend) 05.35.42 Join Rob2222 [0] (~Miranda@p4FDCA5BA.dip.t-dialin.net) 05.37.00 Join froggyman [0] (~me@unaffiliated/froggyman) 05.38.49 Quit evilnick (Ping timeout: 246 seconds) 05.38.50 Quit Rob2223 (Ping timeout: 245 seconds) 05.39.10 Quit mikroflops (Ping timeout: 246 seconds) 05.40.24 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 05.46.40 Quit planetbeing (Read error: Connection reset by peer) 05.47.31 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 05.49.59 Quit robin0800 (Ping timeout: 268 seconds) 05.51.08 Join blairb_ [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 05.52.30 Quit mikroflops (Ping timeout: 246 seconds) 05.52.55 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 05.53.27 # Hi everyone 05.54.45 Quit blairb (Ping timeout: 258 seconds) 06.02.26 Part froggyman 06.09.05 Join robin0800 [0] (~robin0800@genkt-057-207.t-mobile.co.uk) 06.22.21 Quit xiainx (Quit: Good Bye) 06.25.47 Quit mikroflops (Ping timeout: 264 seconds) 06.26.46 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 06.36.51 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 06.42.16 Quit phanboy4 (Ping timeout: 258 seconds) 06.44.11 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 06.45.43 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 06.49.27 Quit phanboy4 (Ping timeout: 276 seconds) 06.52.08 Quit robin0800 (Remote host closed the connection) 06.57.13 Quit saratoga (Quit: Page closed) 06.58.32 Quit mikroflops (Ping timeout: 264 seconds) 06.58.43 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.3.179) 06.58.57 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 06.59.56 Quit S_a_i_n_t (Ping timeout: 252 seconds) 07.02.51 Quit phanboy_iv (Quit: Leaving) 07.03.10 *** Saving seen data "./dancer.seen" 07.05.04 Quit CGL (Quit: Saliendo) 07.07.48 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 07.10.18 Quit panni__ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 07.29.11 Quit mikroflops (Ping timeout: 248 seconds) 07.29.36 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 07.46.29 Quit planetbeing (Read error: Connection reset by peer) 07.46.50 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 08.09.21 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.13.42 Join r2k000 [0] (~r2000@130.166.243.18) 08.14.08 Join Boldfilter [0] (~Boldfilte@adsl-82-103-24.jax.bellsouth.net) 08.22.31 Quit Boldfilter (Quit: Boldfilter) 08.35.50 Join ender` [0] (krneki@foo.eternallybored.org) 08.38.04 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 08.38.19 Quit amiconn (Disconnected by services) 08.38.22 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 08.38.41 Join mitk [0] (~mitk@195.117.162.130) 08.38.43 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 08.39.24 # FuzeV2, latest SVN. I'm experiencing random screen corruptions - boot loader showed corrupted colors in the RB logo (only once), WPS seems to "move to the left" part of the screen (as if it was missing some pixels) 08.39.34 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 08.39.34 Quit pixelma (Disconnected by services) 08.39.53 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 08.40.10 # now I had the same corrupted colors problem in the WPS too 08.48.06 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 08.50.23 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.53.49 Quit mikroflops (Ping timeout: 245 seconds) 08.55.04 Quit drostie (Remote host closed the connection) 08.55.04 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.3.179) 08.56.52 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 08.59.26 # Blargh! FS#11101 stops sim-builds from compiling....I *really* like the behaviour the patch offers (though, the menu/wording for it is *awful*), but it's just not done as well as it could be by someone who actually knows what they're doing. ie. Not me. 08.59.36 # Good idea, bad implementation. 09.00.16 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 09.00.28 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 09.00.55 # S_a_i_n_t: Is there a comment on the task about that problem? 09.03.13 *** Saving seen data "./dancer.seen" 09.03.50 # There are several about the crappy wording, But I'm just going to add a comment to it now alog the lines of "should use 'charging only mode' and 'mass storage device mode" (or similar) instead of a rather sonfusing 'yess/no' selection, and btw this patch also makes the bootloader complain and messes up sim-builds" 09.04.05 # It's a nice idea, just not very well done. 09.04.37 # sonfusing? "Ahem....*con*fusing" 09.07.45 Quit arbingordon (Quit: `) 09.11.48 Quit freddyb (Ping timeout: 265 seconds) 09.18.09 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.23.09 Join Eugenpaul [0] (~ugnpaul@117.7.32.95.dsl-dynamic.vsi.ru) 09.28.25 Quit bertrik (Ping timeout: 252 seconds) 09.28.44 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 09.29.44 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.32.08 Quit mikroflops (Ping timeout: 264 seconds) 09.42.29 Join Bagder [0] (~daniel@rockbox/developer/bagder) 09.46.47 Quit planetbeing (Read error: Connection reset by peer) 09.46.55 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 09.53.36 Quit pamaury (Read error: Operation timed out) 09.53.44 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 09.53.50 Join pamaury [0] (~pamaury@sphinx.lix.polytechnique.fr) 09.53.52 Quit pamaury (Changing host) 09.53.52 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.55.29 Join arbingordon [0] (~w@unaffiliated/arbingordon) 10.13.37 Quit Luca_S (Quit: CGI:IRC (EOF)) 10.23.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.27.45 # It looks like fuze v1 was broken by r25491. It frozes during startup. Anyone tried fuze v1 with build higher than 25490? 10.30.19 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.30.47 Join m3dlg [0] (~m3dlg@212.183.140.51) 10.34.09 # mitk: I'm not sure how but I'll have a look 10.35.47 Quit BHSPitMonkey (Quit: Ex-Chat) 10.37.07 # kugel: my fuze lasts with yellow rockbox logo, sbs status bar loaded and wheel led on. Clean config and default theme. 25490 is working 10.40.03 Quit m3dlg (Quit: RAGE QUIT) 10.41.47 # re: RaaA. I've looked into gnu pth a bit (a cooperative thread library) and it looks pretty straight forward to replace our own implementation with it 10.45.27 # linux and android only offer pthread, android also java threads, neither is guaranteed to be cooperative, so we're basically forced to a) port over our threads or b) use a third party library which offers cooperative threads explicitely 10.47.49 # Or c) fix the apps/ code to work with pre-emptive threading 10.48.25 # fix *all* code 10.48.43 # It's not just apps 10.48.49 # How much firmware/ code will be left in a true RaaA? 10.49.12 # Or how much firmware code where threading is an issue? 10.50.11 # I don't think it's a good idea to switch threading models *only* for RaaA 10.52.18 # and I'd assume that *all* code has issues. Everything that uses global state needs locking, which in rockbox basically means that everything needs locking 10.52.49 # I'm not saying it's the best solution, but should we definitely rule it out? 10.53.11 # I think within the scope of a RaaA project, yes 10.53.13 # Isn't it only things which can be changed by multiple threads? 10.53.33 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 10.53.51 # isn't that basically everything? 10.54.41 # * gevaerts points JdGordon to FS#11175 to see if he has ideas 10.54.50 # * JdGordon just oened that email 10.55.03 # changing the threading model would be an extremely tedious task 10.55.20 # I'm not sure it would be _that_ tedious 10.55.27 # I don't know. But that's my point - is it _definitely_ a huge undertaking? 10.55.37 # we already have locking on several places due to system calls' own yieldings 10.56.07 # gevaerts: the theme causes the wrong track to start?! thats bloody retarted 10.56.46 # the problem is that debugging thread problems is hard, even more with preemptive threads. I do think it would be a very tedious task 10.56.50 # JdGordon: yes, I know, but it's even worse. It causes the wrong track to start, but with the correct resume info so if you restart playback it changes... 10.57.37 # B4gder: don't underestimate it, debugging threading is extremely tedious, even when you right the code with preemptive model in mind 10.57.42 # I probably wont get a chance to look at it tonight, but we'll see... 10.58.00 # to me, it's about where Rockbox is heading, where the future lies 10.58.06 # SoC isn't meant to be fun, it's a job... ;) 10.58.11 # haha 10.58.24 # I don't want to rule it out completely, but I think it might be a bit too much work for a single gsoc summer. 10.58.52 # why preemptive threading would be the future ? 10.58.55 # yes, it's a huge undertaking to consider it for gsoc 10.58.57 # but if it's required I shall give it a try, I guess? 10.59.17 # This is also why I've been saying that the SoC project shouldn't be focused on a target device - it should be laying the foundations. 10.59.20 # pamaury: because I see raaa as the future and thus getting out of the way for such "basic" things such as threading models 11.00.28 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.00.45 # Preemptive threading might of course also make multi-cpu support *slightly* easier 11.00.51 # Bagder: I don't agree RaaA is _the_ future. Rockbox as a firmware will still be relevant for a long time, as long as manufacturers keep making dedicated DAPs. But I agree it's _part_ of the future. 11.01.31 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.01.41 # linuxstb: do you think I should focus on making preemptive threads work over porting to a device? 11.01.49 # yes, I'm not suggesting we'd drop anything of what we do now, but I do see a future where users such as myself will not be using dedicated DAPs anymore 11.02.23 # Don't get it wrong, raaa is fundamentally different, first of all, nearly all the code in firmware/ becomes useless and you can thus rely on the OS features, which are thread-safe. Then, the relevant code in apps/ can probably be 'fixed' for preemptive threading 11.02.37 # Rockbox works very well with cooperative threads, so I don't see a need to make preeptive threads work. they have also drawbacks 11.03.09 # kugel: but so does cooperative... :-) 11.03.14 *** Saving seen data "./dancer.seen" 11.03.20 # "change is bad"..... :< silly argument 11.03.36 # the proper argument is, rather, "multithreading is hard" 11.03.47 # kugel: I'm just trying to keep an open mind. i.e. there are lots of things to discuss and consider. I just added "use pre-emptive threading" as a third option to your list... 11.03.55 # but it certainly looks like we need to bite this bullet 11.04.10 Quit bluebroth3r (Ping timeout: 264 seconds) 11.04.21 # multithreading _is_ hard 11.04.37 # if we are talking RAAAaaaa wouldnt it be better to talk about splitting apps into logical modules and make them not talk to eachother how they do now? 11.04.55 # pull the playback engine out into a seperate library, ditto drawing, etc 11.05.05 # that'd make sense, yes 11.05.30 # a bit like librbtag has been started 11.05.31 # I'd consider the project more successful if we have an installable app at the end (for a platform we didn't target before), not so much if we work with preemptive threads 11.06.02 # kugel: you could get an installable app in a week... 11.06.54 # with sdl and without fixing it to work with the target tree, yes 11.07.04 # for the project, the foundation is more important than a single gsoc project though 11.07.18 # imo 11.07.25 # of course, but those are also just foundation things, just like threading :) 11.07.54 # also, for Raaaa, going for a real target for gsoc is stupid.... linux+sdl is the obvious porper first step, then maybe replace sdl with qt or something 11.09.21 # well, I followed the project idea on SummerOfCode2010 which mentions porting to an actual device and no threading. but if we now decide that being independant on the underlying thread library is more important I can change my proposal to reflect this 11.09.28 # * linuxstb wants linux+ncurses, keeping charcell alive ;) 11.10.20 # * gevaerts wants to separate the GUI from the rest better, so keeping charcell alive becomes a non-issue :) 11.10.27 # gevaerts: I just found a library for usb analyzing, it didn't use it yet but it seems interesting: http://vusb-analyzer.sourceforge.net/ 11.11.03 # so what has the higher priority? 11.11.07 # gevaerts: I agree. The apps/ code definitely needs changing in the long-term, but it's definitely something to do after the lower-level stuff. 11.11.26 # kugel: find a healthy mix :) 11.13.27 # I think it will depend a lot on the choices made, and the problems that are found along the way. So any timeline needs to be flexible. As a minimum, a "desktop" linux+sdl target could be a successful outcome, assuming the right amount of work has been done to get there. 11.19.38 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 11.21.05 # re: raaa, but not exactly what you guys are discussing, i've been out of the loop for a while and just read Bagder's blog post about it yesterday, and while i agree that raaa is *a* future of rockbox i wondered a bit about the part about relying on the device's OF/OS for stuff like networking. How do we feel about more advanced players like the zune for example, which has wifi, are we against rockbox gaining its own network stack? if so do we port linux 11.21.06 # f.e. and run raaa on top? 11.22.15 # my personal feeling is that linux is proably the way to go for more complex code such as networking 11.22.22 # I agree 11.22.22 # btw, i am not saying replacing the firmware entirely is feasible on phones and the like but on the more featured daps and pmps which lack an open os 11.23.06 # interesting 11.25.10 # ok, I'll add "explore possiblities to run under preemptive multithreading", I propose I have a try but if it turns out too hard I move the focus onto later items on the list. I think it's not really possible to give an estimate on the work needed for preemptive threads 11.25.17 # ok? 11.26.16 # kugel: i see no reason why you have to deal with all the problems raa brings up at once, i's suggest focusing on a few and getting them right 11.26.24 # s/i's/i'd/ 11.26.39 # I fear that if I concentrate on the thread issue too much then, no matter of the outcome, porting will fail 11.26.46 # kugel: I'd mainly add a note that lots of details and steps could change after discussion 11.27.29 # * n1s is curious to see how the raaa gui will turn out 11.27.52 # not much different from the current one 11.28.14 # which is why a desktop is actually a suboptimal target 11.28.30 # i'd like to run raa on a desktop/laptop 11.29.00 # s/to run/to be able to run comfortably/ 11.29.21 # of course nothing prevents different UI's to be available 11.30.11 # sure, but a complete ui overhaul is too much for gsoc imo 11.31.08 # maybe if it was *only* the ui overhaul but there are a lot of prerequisites for that 11.33.39 # yeah, i'm not saying you or anyone else should do it 11.37.08 # but pthread isn't really more native than pth, so if I'd have to choose one I would pick the one I know rockbox will work with 11.39.41 # I'd even say pth is more portable 11.41.06 # Well, we'd keep our current abstraction layer for threads anyway I think, so in the end different targets can have their own thread.c 11.43.13 # I'm thinking that even if we manage to run under preemptive threads, it doesn't have a real advantage 11.45.14 # Isn't the advantage that Rockbox is doing what the underlying OS expects applications to do? So it should be more efficient, and in a way, simpler. 11.46.12 # and using plain ansi c library calls (make/swapcontext or set/longjmp) is not what the OS expects? 11.46.15 # But yes, "explore possiblities to run under preemptive multithreading" seems a sensible thing to do first. The decision can be made after that. 11.49.08 # with rockbox r25494 i get 'undefined instruction at 3077C450' on my fuze v1 11.49.30 # after the rockbox logo, before entering the main menu 11.50.10 # how many threads will raaa use anyway?, UI, playback, codec, buffering? Does multithreading even bring a benefit? 11.51.20 # linuxstb: pth doesn't use an underlying thread library. it's a self-contained library, so basically the same as pthread (just cooperative). so I don't think it's less efficient than pthread 11.52.23 # besides, pthread isn't completely implemented on android 11.54.50 # same problem mitk describes i suppose. did you have a chance to have that look, kugel? 11.55.14 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 11.57.19 Quit kugel (Ping timeout: 264 seconds) 11.58.27 Join JdGordon_ [0] (~jd@rockbox/developer/JdGordon) 12.01.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.08.30 # kugel: Linux isn't the only kernel RaaA could run on though. There's WinCE, Symbian, OSX, ... I don't know what threading models they use. 12.09.02 # Maybe targetting something non-Linux would be beneficial, to introduce diversity. Or at least thinking about them. 12.10.01 # sure, but I wanted to focus on unix like devices 12.10.32 # but as I mentioned in the proposal, the final decision on the target device hasn't been made yet, I suggested a decision deadline for july, so I'm still open 12.12.08 # I would prefer android or maemo because that's the devices I'm interested in. as the gsoc project most probably involves buying one I would rather buy one which I'm interested in outside of gsoc too 12.15.03 # I'm just saying that it would be useful to at least read about a diverse selection of targets, as the aim (IMO) is to lay the groundwork for new ports. 12.15.56 # pth looks interesting 12.18.05 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 12.20.01 # topik: I think I can imagine the problem 12.20.36 # kugel: just posted a bug report on flyspray. i didn't select the right options though, so feel free to correct or remove it 12.22.00 # New commit by 03funman (r25495): Revert unrelated part of r25491 : fuzev1 init code works again 12.24.37 Quit Eugenpaul (Ping timeout: 248 seconds) 12.25.56 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 12.30.02 # thanks funman. works like a charm 12.30.40 # * JdGordon 's ipod isnt turning on after doing a batt bench :( 12.31.01 Part LinusN 12.31.36 # fuzev2 screen corruption is much more frequent when boosted - i quite expected the opposite 12.33.14 # 18h sitting in the "hw info" debug screen (so no skining running at all)... so either its all bad, or the theme engine doesnt affect runtime at all (anymore) 12.34.48 # shouldn't panic messages turn on backlight? 12.37.50 # funman, it wasn't really an unrelated change 12.39.40 Quit JdGordon_ (Quit: Bye) 12.44.09 # thank you too kugel, for looking 12.44.48 # I edited my proposal to reflect the comments made and our thread discussion 12.46.21 # is there any possible RaaA target device you already have your eye on, kugel? 12.46.40 # htc desire seems nice :) 12.46.44 # Raaa by definition sholdnt be targete to a specific device! 12.47.06 # no, but i read he plans to buy one as a test target 12.47.19 # so i was wondering if there was a leading candidate 12.48.43 # JdGordon: the point is of course laying the groundwork application port that is easy to port to a specific device (or rather, a specific host OS) 12.49.02 # JdGordon: It has to target specific devices at some point... 12.49.11 Join watto [0] (~watto@193.203.81.165) 12.49.56 # htc desire is a shiny device. the raw power will be unusual for rockbox to experience 12.53.10 # the port to a specific platform is rather to prove and ensure the resulting application is really portable straight-forward. I think the port doesn't desperatively need to run flawless but it should show the groundwork that has been laid is useful 12.54.28 # kugel: That's something else to think about - how to target different devices running the same OS. e.g. do we want to create many Android ports, or a univeral "run-anywhere" binary. 12.57.37 # other android music devices could be inspiration for an answer to that question 12.57.42 # music apps even 12.58.20 # The problem is that Rockbox currently expects to know everything about the target device at compile-time. 12.58.38 # (or most things...) 12.58.49 # Exceptions are some optional hardware, such as FM tuners. 12.59.34 # most importantly, display resolution 12.59.38 # But I guess with Android we don't even know exactly what CPU we'll be running on... 13.01.05 # kugel: "and the skin engine   where I was the first to use it outside of the WPS with the base skin." <- no you wasnt :) 13.02.07 # I meant "in svn", I didn't count the various dirty hacks before that 13.02.53 Join mikroflops_ [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 13.03.18 *** Saving seen data "./dancer.seen" 13.09.19 Quit liar (Quit: Verlassend) 13.09.31 Quit planetbeing (Quit: planetbeing) 13.09.33 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 13.12.50 Part watto 13.15.49 # gevaerts: did you ever think that there might be something wrong with usb string descriptors ? I was sniffing usb packets for usb audio under windows when I noticed it: even in Linux with svn head, most string descriptor response are ill-formed, I'm not sure if it's a 13.16.01 # problem with wireshark or a real problem 13.21.16 Quit blairb_ (Quit: Leaving) 13.21.40 # gevaerts: re that broken theme... if its being caused by the playlist viewer then its a dupe (reported int he forums though i tihnk)... I cant imagine how that causes things to break, but ill have a looky anyway 13.27.32 Quit mikroflops_ (Ping timeout: 245 seconds) 13.28.47 Join Eugenpaul [0] (~ugnpaul@cache.vsu.ru) 13.37.26 Quit lpereira (Read error: Connection reset by peer) 13.37.34 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 13.40.40 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 13.40.42 # hello! I'm a one more student wishing to participate in gsoc 13.40.54 # Welcome! 13.41.17 # I think I'll be able to optimize mp3 codec 13.43.27 # Can someone give me some advices? Like where can i find current rockbox decoder algorithm 13.43.55 # anyone*) 13.44.02 # You'll need one of our codec people then 13.44.06 # * gevaerts looks around 13.44.32 # linuxstb, stripwax: ping 13.44.57 # the "algorithm" would be in the source 13.46.06 # kugel: re SBS updating more often. according to my batt benchs the theme engine wastes no additional cpu, so I dont see any reason to not drop that update delay to something like HZ/10 or faster even 13.46.26 # I understand its wasteful updating every button press (pretty much only when scrolling anyway) 13.46.28 # gevaerts - pong, but I'm heading off ... 13.46.40 Quit mikroflops (Ping timeout: 246 seconds) 13.46.49 # stripwax: ok, you can't help then. You know about codecs, right? :) 13.47.02 # Eugenpaul - in the rockbox svn code, take a look at the apps/codecs tree 13.47.04 # Eugenpaul: All our codecs are in the apps/codecs/ directory in the Rockbox source. 13.47.15 # JdGordon: why does the SBS vanish while certain things are happening? 13.47.23 # mp3 is implemented using libmad, in apps/codecs/libmad 13.47.24 # JdGordon: i can understand it not updating but disappearing is weird 13.47.35 # Torne: specific example? 13.47.39 # JdGordon: splashes 13.47.39 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 13.47.52 Quit stripwax (Read error: Connection reset by peer) 13.47.55 # Eugenpaul: Do you have experience with audio codecs, or embedded programming? 13.47.58 # well, i know) 13.48.09 # what is probably happening is the theme is disabled which causes a full screen clear, then it is reneabled which shuold cause an update 13.48.33 # JdGordon: committing db does it over and over again eveyr second or so, i presume because it's looping and doing splashes repeatedly 13.48.44 # makes the status bar flash on and off crazily the whole time 13.48.46 # IIRC splashes always disable the theme 13.49.00 # hm 13.49.01 # which might be stupid... 13.49.02 Quit TillW (Quit: This now concludes our broatcast day.) 13.49.03 # it just looks weird :) 13.49.30 # ah, yeah, we had the problem where if we didnt disable it we need to somehow clear the splashed area after it shuold be removed 13.49.33 # which isnt so easy 13.50.00 # fair enough. as long as there's a good reason :) 13.51.01 # JdGordon: as I said, we can consider lowering it to HZ/10 13.58.29 Join hebz0rl [0] (~hebz0rl@dslb-088-065-061-253.pools.arcor-ip.net) 13.58.41 # linuxstb: sorry for delay, i don't have real experience in this, but i know basics of mp3 decoding, 13.59.39 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 13.59.51 # Eugenpaul: so without experience in this field, why or how do you think you can optimize the mp3 codec? 14.00.14 Join froggyman [0] (~me@unaffiliated/froggyman) 14.00.39 # I guess that's what your application would need to include :-) 14.01.42 Quit mikroflops (Ping timeout: 245 seconds) 14.02.01 # i have experience in c, assembler, know about signal processing, love rockbox) and really want to do it 14.02.13 # Eugenpaul: If you don't have any experience, then your best choice would be to start work on it now - i.e. download the Rockbox source, and try and identify areas for improvement. Also, just working on the mp3 codec alone may not be an entire summer's work. 14.02.20 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 14.04.01 # * amiconn still thinks that RaaA can't be the future of rockbox 14.04.35 # can't be? 14.05.00 # Imo being a firmware in its own right is what makes rockbox rockbox 14.05.35 # RaaA wouldn't be rockbox anymore, but just one among dozens of music player programs 14.05.38 # Bagder: Do you see it as the _only_ future for Rockbox? I can't imagine us dropping support for running Rockbox natively... 14.05.39 # JdGordon: couldn't the update freq be um, smart, so it updates as fast as it needs, for example using the smallest time of a set max time (like 1/5s and smallest alternating subline delay and the delay of any scrolling text) or would that be too complicated 14.05.41 # ? 14.06.00 # I don't see as the _only_ future, no. 14.06.15 # amiconn: i see it as *a* future for rockbox 14.06.25 # we still even support charcells, I don't think we need to drop anything 14.06.30 # n1s: lines are only redrawn if they are dynamic lines. the update freq isthe time between checking if lines should be updated 14.06.34 # I'd really like a usable raaa on my netbook 14.07.10 # No, as long as devices running rockbox as a firmware still exist, rockbox probably will as well 14.07.13 Join Zagor_ [0] (~bjst@2a00:801:f5:fff8:216:6fff:fe3b:5ef5) 14.07.46 # but to me personally, I won't be using Rockbox unless it can continue as an app... 14.07.50 # JdGordon: but wasn't the updatefreq discussion triggered by a user with an animation that used alternating sublines with shorter delay than 1/5s? 14.07.56 # So we all agree that the future is Rockbox running as both an application and as a native firmware? 14.08.07 # rockbox.rock! 14.08.17 # * amiconn doesn't see a point in RaaA 14.08.18 # linuxstb: i do at least 14.08.45 # n1s: well yes, but the sublines times change depending on which are enabled at any time... I dont tihnk adding those smarts is a good idea 14.08.57 # ok 14.09.06 Join watto [0] (~watto@193.203.81.165) 14.10.10 # well, at least not untill we have a single timeout for all skin-enalbed screens 14.10.21 # all button loops use mostly rnadom timout values 14.10.26 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 14.10.29 # ah 14.11.47 # The devices which potentially *could* benefit from RaaA can't run it, and the devices which could can also run another music player of choice 14.11.47 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 14.12.48 # Which devices can't run it? 14.13.11 # But I think the point is that no other music player of choice has Rockbox's features. 14.13.20 Join TillW [0] (~Till@nat028.dc-uoit.net) 14.13.47 # foobar2000? VLC? Just to name two 14.14.06 Quit mikroflops (Ping timeout: 264 seconds) 14.14.42 # And they run on the devices we're talking about? 14.14.46 # And the devices which can't run it I was thinking of are those mobile phones only capable of running java stuff 14.15.13 # But then those don't have much storage either 14.16.02 # I personally see no point in RaaA as I hate mobile-phones-that-do-everything but my opinion can change, and I understand people have an interest in that 14.16.11 # android phones have no equivalent music player, just to mention one platform 14.17.07 # pamaury: I agree, I have no desire to play music on my phone. But lots of people just have (or want) one device... 14.17.22 # amiconn: foobar is windows only and i personally don't like vlc as a music player (altough i can't give any concrete arguments) 14.18.04 # * evilnick_B would dearly love Rockbox on the iPhone 14.18.29 # anyway, the specialized DAP's will not go away i think, there will always be people that don't have smartphones or want to have massive storage for lossless 14.19.00 # Furthermore, mobile phones will never reach the battery autonomy of a DAP ! And mobile phones are huge, heavy, not very practical in some situations 14.19.20 # Sure, foobar is windows only. That's because I just named two, and I'm more of a windows user than a linux user 14.19.52 # amiconn: I haven't found any music player on Linux I like as much as Rockbox... 14.19.56 # VLC is cross platform though, and it's quite good 14.20.33 # mobile phones will soon be so powerful that you will be able to run foobar with wine with a linux emulator on your iPhone... 14.20.49 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 14.20.55 # * linuxstb wonders how Rockbox would cope with other processes adding/removing files during playback... 14.21.13 # linuxstb: someone will find out :) 14.21.15 # should work fine 14.21.22 # playback just skips missing tracks 14.24.54 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 14.25.11 # could anyone who knows coldfire take a quick look at this, http://pastie.org/905470 looks like yet another gcc bug to me 14.26.46 # n1s: whats the problem with that? 14.28.09 # wodz, isn't the upper half of a0 any junk that was there before after the move.w? 14.28.28 # a0 is not cleared so this may have side effects in my opinion 14.28.35 # so then doing cmp.l on that will um, be bad= 14.28.36 # ? 14.29.50 # yes You may have junk in upper word of a0 and doing cmp.l is not good idea here 14.30.06 # ok, so gcc is buggy, yay 14.30.50 # of course, i should test a newer version 14.30.57 # n1s: I don't know coldfire assembly but if the move.w doesn't clear upper part, this is buggy 14.31.10 # pamaury: it doesn't 14.31.30 # n1s: maybe gcc knows that a0 will be 0 when SATURATE() is called 14.32.05 Join froggymana [0] (~187b533e@giant.haxx.se) 14.32.08 # wodz: sounds unlikely, since i compiled the function in its own file 14.32.24 # maybe i should try a better testcase 14.32.37 # How would gcc know ? Try to compile it with "extern" so gcc can't make any assumption, I doubt zeroing a0 is part of the calling convention 14.32.46 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 14.33.11 Quit Bagder (Quit: It is time to say moo) 14.33.42 Quit S_a_i_n_t (Ping timeout: 260 seconds) 14.35.07 Quit mikroflops (Ping timeout: 265 seconds) 14.37.21 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 14.44.23 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.44.56 Quit n17ikh (Read error: Connection reset by peer) 14.45.18 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 14.47.54 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.49.40 Join m3dlg [0] (~m3dlg@212.183.140.22) 14.54.55 # seems to be doing it in cases where it definitely gets called when a0 != 0 14.55.21 # * n1s puts "tet bug on new gcc on todo list" 14.55.47 # s/tet/test/ 14.56.12 # s/gcc on todo list"/gcc" on todo list 14.59.08 Quit TheSeven (Read error: Connection reset by peer) 15.03.22 *** Saving seen data "./dancer.seen" 15.04.32 Quit antil33t (Read error: Connection reset by peer) 15.04.38 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.17.11 Quit m3dlg (Ping timeout: 260 seconds) 15.20.19 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 15.39.40 Join Barahir_ [0] (~jonathan@gssn-5f756823.pool.mediaWays.net) 15.43.52 Quit Barahir (Ping timeout: 258 seconds) 15.44.35 Quit FlynDice (Remote host closed the connection) 15.48.26 Quit Adubb (Ping timeout: 252 seconds) 15.49.20 Join Schmogel [0] (~Miranda@p3EE21D72.dip0.t-ipconnect.de) 15.50.18 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 15.50.51 Quit mikroflops (Ping timeout: 276 seconds) 15.51.07 Quit froggymana (Quit: CGI:IRC) 15.51.51 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 15.52.09 Join Adubb [0] (~aldubuc@67.201.160.144) 15.53.19 Quit pamaury (Quit: Quitte) 15.54.18 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 15.54.34 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-sjqlvdmdwtxrdoip) 15.54.41 # Eugenpaul: ping 15.54.55 Join freddyb [0] (~chatzilla@pool-68-238-8-141.chi.dsl-w.verizon.net) 15.57.03 # Eugenpaul: i have to step out for a few minutes, but we should discuss the mp3 project, I have a lot of ideas about it 15.57.08 # will you be online later? 15.57.50 Quit mitk (Quit: Leaving) 15.58.40 # saratoga: yes? 16.00.00 # saratoga: i will be online now for few minutes and about 2 hours later once again 16.03.40 Quit freddyb (Remote host closed the connection) 16.05.25 Join Lixun [0] (~8984fa0e@giant.haxx.se) 16.07.01 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.11.59 # Hi, I'm a student interested in participating in GSOC. How is the workload rockbox expecting me to commit? 16.12.25 # is it like a full-time internship or part-time? 16.12.40 # It's supposed to be full-time. 16.12.51 # (I think that's google's advice) 16.13.32 Quit wodz (Quit: Leaving) 16.14.03 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 16.14.09 Quit n1s (Ping timeout: 258 seconds) 16.14.28 # thank you. because i have another part-time job during vacation so I'm wondering whether I can balance two or not 16.16.09 # I think it would depend on the hours you were working in the part-time job, and what kind of work it was (and of course, how many hours a day you are personably able to work effectively each day...) 16.16.56 Quit Eugenpaul (Remote host closed the connection) 16.17.53 # the job is like 20hrs per week 16.17.58 Join n1s [0] (~n1s@rockbox/developer/n1s) 16.18.38 # it's about C# coding 16.19.35 # for rockbox, I think I should be able to guarantee 30hrs at least per week 16.21.40 Join CGL [0] (~CGL@190.207.231.184) 16.23.40 Quit anewuser () 16.24.27 # Lixun: Feel free to apply, but all other things being equal, I think we are probably more likely to choose an applicant who doesn't have other commitments. A full-time job is about 35-40 hours per week. 16.28.04 # I see. Thanks. 16.28.10 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 16.29.15 Quit saratoga (Changing host) 16.29.15 Join saratoga [0] (~9803c6dd@rockbox/developer/saratoga) 16.29.33 # Of course, depending on your application, all other things might not be equal 16.32.06 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 16.32.26 Quit pamaury (Quit: Quitte) 16.34.13 Quit mikroflops (Ping timeout: 276 seconds) 16.34.52 Quit JdGordon (Quit: Leaving.) 16.34.53 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 16.35.14 # how strange. FuzeV2. I was sitting in the debug > buffering info screen while playing a song, when I moved the scrollwheel: playback skipped to the next song o_O is this the intended behavior? 16.35.38 # I think it is, so that you can watch what happens to the buffer on track change 16.35.43 # its a debug screen afterall 16.36.15 Quit TillW (Remote host closed the connection) 16.36.42 # yes, it is intentional; the buttons that normally scroll lists are mapped to next/prev track in the buffering screen 16.36.52 # interesting - indeed it makes sense. i was surprised because it was using the scrollwheel and not the next/prev buttons, but the prev button is used to exit the screen so it might be reasonable 16.37.09 # Yeah, it's reusing the list context iirc 16.37.18 # so it has the same button mappings as other lists/menus 16.38.02 # thanks for the explanations 16.39.12 Join anewuser [0] (anewuser@unaffiliated/anewuser) 16.42.57 # Hum. 16.43.06 # Is there a way to get the database viewer translated? 16.43.52 # Things like Artist, Album Artist, Album, Genre, Composer, Track, Year, User Rating . . . etc are not translated currently. 16.44.32 # Seems the language files aren't used for it, but tagnavi.config 16.46.44 Quit n1s (Ping timeout: 258 seconds) 16.48.18 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.48.36 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 16.50.57 Quit Lixun (Quit: CGI:IRC (EOF)) 16.54.10 Join archivator [0] (~archivato@77.70.28.57) 16.54.56 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 16.59.51 Quit Zagor_ (Quit: Leaving) 17.01.56 Quit kugel (Ping timeout: 248 seconds) 17.02.25 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 17.03.25 *** Saving seen data "./dancer.seen" 17.05.46 Join TillW [0] (~Till@nat026.dc-uoit.net) 17.07.07 # Is there any interest in a self-sustained minimalistic maintenance app for Rockbox? Rbutil Lite - something that can be put on your DAP Autorun-style and do basic maintenance every time your player connects to a pc - purge the database of expired entries (last time I checked, rockbox only marks them as expired), check for newer versions and run a file system check? I was thinking of something sub-1MB that just works. I remember distinctly a project to 17.07.07 # merge elf and pex executables into one file, that could be pretty sweet. 17.07.18 Join Blue_Dude [0] (~chatzilla@64.25.25.6) 17.07.53 Join pamaury [0] (~c2c7a50a@gateway/web/freenode/x-qtznnlcxrpbjnmuk) 17.08.15 Quit pamaury (Changing host) 17.08.15 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 17.09.56 # Please check out FS#11178 - bookmark update. It needs a little tweaking to remove an unused token but it's more or less ready to go. 17.10.49 Join m3dlg [0] (~m3dlg@212.183.140.23) 17.17.30 Quit toffe82 (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 17.21.18 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 17.23.49 Join togetic [0] (~togetic@c-71-228-184-130.hsd1.al.comcast.net) 17.23.50 Quit togetic (Changing host) 17.23.50 Join togetic [0] (~togetic@unaffiliated/ibuffy) 17.24.06 Quit mikroflops (Ping timeout: 260 seconds) 17.24.47 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 17.24.59 Join webguest88 [0] (~59f7a0aa@giant.haxx.se) 17.25.46 Join TopyMobile [0] (~topy@xdsl-78-34-73-239.netcologne.de) 17.25.47 Quit robin0800 (Remote host closed the connection) 17.26.52 Quit m3dlg (Ping timeout: 252 seconds) 17.27.59 Join webguest48 [0] (~59f7a0aa@giant.haxx.se) 17.27.59 Quit webguest88 (Client Quit) 17.28.06 Quit lpereira (Quit: Leaving.) 17.29.00 Quit webguest48 (Client Quit) 17.30.39 Join funman [0] (~fun@rockbox/developer/funman) 17.31.00 Join toffe82 [0] (~chatzilla@12.169.218.14) 17.31.25 Quit mikroflops (Ping timeout: 276 seconds) 17.31.50 # whilst RaaA on the iphone is probably interesting for a niche crowd, I'm still against using EmbeddedOSX as a target given the problems we'd face ever getting it accepted into the app store. It would only ever run on jailbroken devices and we cannot guarantee that JBing will always be possible. 17.32.16 # Android desperately needs a decent music player - the one on the N1 is barely adequate 17.32.23 # you're concerned about official support for a rockbox port? 17.32.31 # when has that even been an issue for us in the past? 17.32.39 # it hasn't of course 17.33.07 # but the audience of iphone users that JB is much smaller than the audience of Android users who wouldn't have to 17.33.28 # GodEater: I don't think anyone thinks embedded OS/X is the priority target (or one we should ask a student to do). Or do they? 17.33.34 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 17.33.51 # linuxstb: I was just commenting on evilnick_B's statement earlier 17.34.07 # well its very unixy and has very nice dev tools and wide library support 17.34.20 # so its probably at least as good a target from a technical stand point as Android 17.34.20 # I was also about to say I agree with your statement about lack of decent media players on linux in general 17.34.27 # I'd love RaaA as a native desktop app 17.34.49 # saratoga: apart from in the GUI.. 17.34.52 # saratoga: the dev environment is nearly all Objective-C isn't it? 17.34.57 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 17.34.57 # where you are more or less required to use Cocoa Touch 17.35.06 # verses android and java :) 17.35.20 # porting the UI of an existing app to iphoneos is pretty hard 17.35.27 # imo objective c using gcc is a bit closer to what we want then java 17.35.29 # * linuxstb also isn't keen on Android, but we have to choose something... 17.35.52 # linuxstb: you already said you're not interested in running RaaA on a mobile at all ;) 17.36.02 # I think OSX is probably the easiest target followed closely by pure linux phones and then android 17.36.09 Quit xiainx (Ping timeout: 260 seconds) 17.36.12 # GodEater: Oh yeah... I'll shut up then. ;) 17.36.17 # mostly because theres so much information available and it uses gcc 17.36.29 # Wouldn't maemo be easier? 17.36.38 # Android has a native development kit, right? 17.36.39 # the other big issue with the iPhone as a target means you ideally need OSX as a dev platform 17.36.49 # setting up the iPhone tool chain on linux, whilst possible, is not fun 17.36.57 # (speaking as a man who's done it) 17.37.03 # i think the linux tool chain is adequate though 17.37.15 # saratoga: did you ever set it up? 17.37.24 # archivator: yep, there's the NDK for android 17.37.42 # and probably not much worse then setting up embedded tools for most linux phones which typically involved pirating various libraries . . . 17.37.59 # GodEater: no but I've read about people using it in the distant past 17.38.00 # yep, you definitely need to do that 17.38.15 # Nico_P and I both set it up, and it's really not fun 17.38.16 Quit mikroflops (Ping timeout: 265 seconds) 17.38.21 # Well, that's pure C with a way to communicate with the dalvik layer, isn't it? Sounds reasonable to me, given that most of the stuff can be kept outside of dalvik. 17.38.37 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 17.38.55 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 17.39.33 # the toughest bit is extracting some of the libs from the the X-Code image files on linux 17.40.03 # i don't think you're pirating anything, IIRC the SDK is freely available from Apple, you're just misusing it a bit 17.40.15 # sure - pirating is a strong term 17.40.18 Quit r2k000 (Quit: r2k000) 17.40.19 # you're violating the EULA 17.40.48 Join killan [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 17.41.02 Join hd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 17.41.02 Quit hd (Changing host) 17.41.02 Join hd [0] (~jd@Wikipedia/HellDragon) 17.41.32 # for the moto smartphones I think you actually have to BT stuff they never officially released to the public, i.e. actual piracy not just ignoring a EULA clause 17.41.38 Join ender [0] (krneki@foo.eternallybored.org) 17.41.52 Quit Schmogel (*.net *.split) 17.41.52 Quit Barahir_ (*.net *.split) 17.41.52 Quit ender` (*.net *.split) 17.41.52 Quit jd (*.net *.split) 17.41.52 Quit parafin (*.net *.split) 17.41.52 Quit killan_ (*.net *.split) 17.41.52 Quit Topy44 (*.net *.split) 17.42.03 Join Kitr88 [0] (~Kitr88@89.142.93.152) 17.42.33 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 17.42.41 Quit TopyMobile (Ping timeout: 258 seconds) 17.42.45 Join Schmogel [0] (~Miranda@p3EE21D72.dip0.t-ipconnect.de) 17.42.45 Join Barahir_ [0] (~jonathan@gssn-5f756823.pool.mediaWays.net) 17.42.45 Join ender` [0] (krneki@foo.eternallybored.org) 17.42.45 Join jd [0] (~jd@Wikipedia/HellDragon) 17.42.45 Join parafin [0] (parafin@paraf.in) 17.42.45 Join Topy44 [0] (~topy@my.fastsh.it) 17.42.58 Quit jd (Max SendQ exceeded) 17.44.35 Quit Schmogel (Ping timeout: 270 seconds) 17.44.35 Quit ender` (Ping timeout: 270 seconds) 17.45.02 Quit Kitar|st (Ping timeout: 246 seconds) 17.46.24 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.47.18 Quit Kitr88 (Ping timeout: 276 seconds) 17.48.34 # at least with android the SDK is very easy to acquire 17.48.42 # can't speak for maemo 17.50.06 # regarding gsoc, is it a problem if I work at a slow pace till the end of June? I have exams (quite a few, and all difficult at that) and would hate to choose between gsoc and actual academics :) 17.50.56 # GodEater: Maemo is supposed to be easy to develop for, although I don't think there's an off-the-shelf sdk such as you might find with android. I think it's just the editor/IDE you prefer + Qt libs 17.51.15 # or GTK+ 17.51.23 Join Kitar|st [0] (Kitr88@BSN-142-107-175.dial-up.dsl.siol.net) 17.51.38 # there's "hildon" although i don't know if it's just a set of gtk+ widgets or something else 17.52.10 # geertvdijk: there's this: http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/Platforms/Maemo/ 17.52.29 # funman: Hildon I believe is indeed just a set of GTK+ widgets designed for mobile 17.52.32 Nick ender is now known as ender` (krneki@foo.eternallybored.org) 17.52.39 # archivator: didn't know that, thanks! 18.04.25 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.04.30 Join TopyMobile [0] (~topy@f048209066.adsl.alicedsl.de) 18.05.03 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.08.35 # Maemo is currently GTK+ with the Hildon widgets if you want them, yeah. Qt is not until the next version of the OS 18.10.59 # You can do Qt right now if you want though 18.13.15 # it only integrates nicely fairly recently, though, i believe 18.13.21 # the migration path is only just getting going 18.15.10 # I don't know the details very well 18.15.14 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.15.20 # pressing buttons have no effect on Clip+ when running test_boost 18.15.33 # same with http://pastie.org/905840 unless i mark action as volatile 18.15.58 # and then going by the disassembly (of the .rock) the only difference is r0 (return of get_action) is stored on the stack then read back immediately after 18.16.47 # maemo would also be an interesting target imo 18.16.48 Quit mikroflops (Ping timeout: 258 seconds) 18.17.13 # plus, I'd actually like to learn how I can make it run on my mini2440 ;) 18.18.04 # ah nevermind now it works 18.18.14 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 18.18.15 Join stoffel [0] (~quassel@p57B4A2BC.dip.t-dialin.net) 18.18.34 # * funman adds that to the "random bug" list 18.19.06 # is that the same one as the mind blow list? :) 18.19.39 # probably, perhaps with enough tests (power off+power on) we would see the good value 18.19.56 # do we know why test_codec doesn't work if the codec is in RAM on the clipv2/+? 18.20.43 # i didn't know it didn't work anymore let me look 18.21.02 # saratoga: it should be in iram now 18.21.08 # kugel: btw why did you make this change in app.lds (and do you know why it didn't work on fuzev1?) 18.22.05 # with your change the init code would just be in plugin ram instead of codec ram 18.22.12 # I somehow thought putting the init code in the iram (where codec is now) clashes with the rockbox' portion of the iram 18.22.42 # don't ask me why I thought that, and don't ask me why it didnt work (actually I was just about to ask you the same) 18.22.58 # ah :\ 18.23.02 # right, I remember why 18.23.12 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.23.32 # init calls loads skins at some point, and skin loading uses the plugin buffer for caching the .wps/.sbs files 18.23.44 # metadata parsing fails according to the error message 18.24.01 # saratoga: ah i had the same problem but didn't find the reason 18.24.08 # metadata parsing works fine in the wps 18.24.22 # saratoga: did you do a clean recompilation (nuking the build dir)? that often helps if linkage-related stuff changed 18.24.46 # that happens with clean build, i had seen that when i tried to put the codec buffer in iram 18.25.30 # well not the 'failed' message but metadata length was 0 18.25.35 Join Eugenpaul [0] (~ugnpaul@221.199.32.95.dsl-dynamic.vsi.ru) 18.25.59 # i'll try md5sum to see if file reading is really reliable 18.26.46 # maybe that could explain the WPS backdrop sometimes disappearing on fuzev2? bitmap failing to load? 18.26.47 # domonoky: I have updated FS#11160 as per our discussion. I can't think of anything else to fix/do. The rest is making SAPI and Carbon thread-safe, really. 18.27.05 # Luca_S: come on, that's the only problems you can think of ? there's more :) 18.28.17 # not as many as it may seem! today I reorganized all my music in a single folder so I could play it in rockbox as fine as in the OF :) 18.28.23 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 18.35.47 # * bertrik wonders how many jpeg implementations we have 18.36.17 # 4 runs boosted, 4 runs unboosted, md5sum OK for the same 4.2 Mb file 18.36.33 Quit anewuser (Quit: http://xrl.us/Renoise Like renoise + like music? 3 days to submit your entry!) 18.38.08 # archivator: looks good. 3 comments: 1. what is this strange comment in encodeList ? (the list is surely used later). 2. The skipping of empty toSpeak values seems to have got lost (or is it not needed anymore ?) 3. There are TABS instead of spaces in this patch. 18.38.44 # ah but the plugin boosts 18.40.19 # md5sum still OK on 2 runs 18.41.27 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 18.42.54 # well playing with test_boost doesn't make the Clip+ crash faster (it is boosting/unboosting several times already when it uses a codec) 18.43.32 # today I noticed that when boosting the fuzev2 has frequent screen corruptions (missing pixels, color shift) 18.43.50 # when unboosted they're still there, but less frequent 18.43.55 # i see corruptions too 18.45.45 # are the display data pins still shared with other functions on the fuze v2? 18.46.01 # domonoky: 1) Yes, it is, but as far as I can tell, we can safely delete the entries we're not going to process from it. Duplicates would point to the same file as another entry, so they can go. Unvoiced entries never created a file, so they can go as well. That's all I meant by "not used" - that the cleanup routines won't mind us deleting a few things from it (especially *these* things) 18.46.58 # domonoky: 2) It's right there: line 154 in the patched file - "if (!entry.voiced && !entry.toSpeak.isEmpty())" 3) damn, I thought I had gotten vim to behave! Will fix and reupload. 18.47.21 Join Lear [0] (chatzilla@rockbox/developer/lear) 18.48.00 Quit Luca_S (Quit: CGI:IRC) 18.48.23 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 18.49.55 Quit scorche (Ping timeout: 252 seconds) 18.50.39 Join scorche [0] (~scorche@rockbox/administrator/scorche) 18.51.24 # bertrik: you mean buttons? 18.51.46 # funman, yes, for example 18.51.51 # doesn't seem so 18.52.37 # archivator: about 1) the list is used later by the filecopiing from talkfile.cpp, but it probably doesnt need the invalid entrys. 18.52.53 # funman: in svn there is a file called usb-drv-as3525.c, it contains some init code for a usb driver. What is this usb driver ? Of which device(s) I mean. 18.53.56 # domonoky: well, yes, exactly - we basically make the list have distinct entries filename-wise. I'll change the comment to reflect that, I can see how it can be confusing. 18.54.09 # archivator: removing the dublicates might get you problems with talkfiles. 18.54.11 # pamaury: i tested it on Clipv1 or Fuzev1 (don't remember which one) but it doesn't work at all 18.54.22 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 18.54.48 # pamaury: there might be dublicate strings to talk, but they could exist in different directorys, so the filecopiing needs all entrys. 18.54.49 # i have some more code here which i tested on Fuzev1 but it works randomly, some times i have an USB interrupt, some times I see that Linux saw the device in dmesg, sometimes nothing happens 18.55.22 # bertrik: Re dbop, you said you had an idea what might cause the button readout noise on C200v2? 18.55.31 # ups, archivator instead of pamaury :-) 18.55.43 # ranma, yes, it goes away if we disable the tristate between accesses 18.56.00 Join Lear [0] (chatzilla@rockbox/developer/lear) 18.56.45 # archivator: removing entrys where voicing failed might be fine, but the dublicates are a problem. 18.57.35 Join Slim [0] (~56b21310@giant.haxx.se) 18.57.41 # afternoon .. 18.58.38 # domonoky: I'm not sure I follow. The talkfiles are duplicated, not the encoded filenames. I haven't looked at the actual values but I always assumed they held the whole path. I'm not sure I understand how having two identical entries contributes anything to the process. 18.58.58 Quit scorche (Ping timeout: 258 seconds) 18.59.11 Join scorche [0] (~scorche@rockbox/administrator/scorche) 18.59.17 # Oh, sorry. 18.59.26 # funman, I'm checking if those buttons are actually not sharing pins with DBOP 18.59.33 # domonoky: I was confusing wav and talk, I see now. 18.59.54 # bertrik: you have a fuzev2 ? 19.00.01 # no 19.00.06 # Can anyone tell me how to determine if a DB initialisation is complete? I have an 80G video iPod running the latest build, and 540 albums. Just don't want to reboot it until it's finished. 19.00.19 # I suppose this part is the same as on the as3525 19.00.38 # Yeah, that makes sense, but how would I skip them (assuming they've been voiced successfully)? I would need yet another flag to check.. 19.00.58 # bertrik: Ok, I'll try that. 19.01.31 # kugel: itcm/dtcm registers read as 0 on Clip+ 19.01.35 # (disabled) 19.03.28 *** Saving seen data "./dancer.seen" 19.03.53 # archivator: couldnt you just set the status of the dublicate entry to encoded=true ? then the encoderstep can skip it. 19.04.28 Quit antil33t (Read error: Connection reset by peer) 19.04.34 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 19.04.57 # just check the encoded flag before encoding, similar to how its done for voicing. 19.05.38 # funman, on as3525, GPIO port C is shared with the DBOP data pins, which also are connected to most of the buttons on the fuze v2. So if some interrupt routine is switching these to input to read them, it might disturb display writing and explain the screen corruptions 19.05.38 # domonoky: yeah, that would work. Will fix it tonight. 19.05.45 # archivator: good :-) 19.06.06 # of course I'm not sure if this is the same for the SoC in the fuze v2, since I don't know the pin map of that 19.06.11 # bertrik: I changed dbop_read_input to not tri-state, but I'm still seeing the noise. 19.06.12 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.06.32 # weird, that seemed to fix it for me 19.06.55 # saratoga: ping 19.07.29 # bertrik: ok, I don't know if kugel tried to read the buttons from dbop 19.07.54 Join mitk [0] (~mitk@chello089078013146.chello.pl) 19.08.29 # saratoga: it's me again with mp3 project 19.09.36 # FWIW: Baseline (music or no music, no display updates): almost zero noise, about 20% during display updates (HW info), abou 27% during display updates (HW info) while playing music. 19.10.25 # (Used this patch to check for noise and show percentage in HW info: http://uguu.de/~ranma/rockbox-c200v2/rockbox-c2x0v2-backlightpatch-20100407-patchset/dbop_noise_check.patch) 19.10.26 # did you try to force boosting? 19.12.25 # ok, thanks anyway - I guess it's a hard one. 19.12.33 Quit Slim (Quit: CGI:IRC) 19.13.10 Quit Adubb (Ping timeout: 240 seconds) 19.13.53 # ranma: btw about the backlight, any problem with setting both pins? 19.15.42 # 20% while playing with forced boost. 19.15.53 # funman: Yes, A5 is buttonlight on mine. 19.16.40 # funman: (or any other Samsa folks)My head is exploding with v2 #ifdef's, do you have a problem with splitting set_cpu_frequency() into a v1 and v2 like this: http://pastie.org/905915 19.17.11 # ranma: and D7 is nothing? 19.17.35 # FlynDice: no problem 19.17.35 # D7 is the second buttonlight (menu text below power button) 19.17.49 # there are 2 button lights? Oo 19.17.55 # But A5 is the main one (with 4 leds aparently) 19.18.07 # hm ok 19.18.15 # I don't even know if both are enabled by D7, bertrik ? 19.18.22 # => on the other model 19.18.44 Join Adubb [0] (~aldubuc@67.201.160.144) 19.19.19 # both on c200v1 and c200v2, they are both enabled 19.19.21 Join mikroflops_ [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 19.20.51 # ranma: did you find how the OF decides which one to use? 19.21.39 # Yes, it's switching A7 to input and reads the value to decide which one to use. 19.21.42 Quit mikroflops (Ping timeout: 265 seconds) 19.22.38 # didn't I post that information here already on IRC some time ago? 19.22.47 # New commit by 03FlynDice (r25496): SansaAMS: Only use INT_MCIO with as3525v1, it is unused in as3525v2. 19.22.53 # New commit by 03FlynDice (r25497): AS3525v2: Set XPD to SD-MMC interface in sd_init() for HAVE_MULTIDRIVE. ... 19.22.56 # ok, what do we need for it to be in svn ? 19.22.58 # New commit by 03FlynDice (r25498): Sansa AMS: Split set_cpu_frequency() into 2 separate functions for as3525v1/v2 as the code is quite different for each model. 19.23.05 # funman: http://pastie.org/905957 19.24.02 Quit mikroflops_ (Ping timeout: 246 seconds) 19.24.23 # ranma: looks good, D7 just needs to be set unconditionally of the variant? 19.24.53 # do we ask bertrik to test, or commit and see if someone reports problems in the forum? 19.26.06 # bertrik: Did you test the rockbox binary I sent you? 19.26.25 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 19.26.26 # no 19.26.41 # If not yet, please do rather test http://uguu.de/~ranma/rockbox-c200v2/rockbox-c2x0v2-backlightpatch-20100407.zip 19.28.11 # funman: I'd vote for committing ;) 19.28.25 # I see the red on r25498 but its not my doing..... 19.28.26 # BTW the OF does the check in init_hardware at 0x8000 19.29.35 # Does sd access generate events that cause _buttonlight_on() to be called? 19.29.40 # * funman slaps FlynDice with an archos player 19.29.45 # hm that's heavy :/ 19.30.11 # If not, sd access is so noisy that it defeats my noise check in dbop_read_input()... 19.30.21 # * FlynDice rubs eye and swears he didn't touch nuthin over there..... 19.30.23 # ranma: no but since sd accesses yield() there could be another thread doing it 19.31.26 # But another thread should only be calling it if there is some button action, right? 19.33.01 # ranma, your zipfile works, I can control the backlight brightness now 19.33.34 # I've half-added the buttonlight to backlight pwm in that patch so that the buttonlight brightness is increasing a bit when _buttonlight_on() is called and during initial buffering I see heavy buttonlight flicker. :) 19.33.50 # ranma: grep only shows drivers/button.c and plugin api 19.34.01 Join mt [0] (~chatzilla@41.233.147.253) 19.34.09 # bertrik: The working part is where it detects the variant correctly ;) 19.34.58 # bertrik: It should show 'C200v2 variant 0' in HW info 19.35.31 # (And if it would missdetect you should have a dark backlight anyway) 19.35.54 # yes it does say variant 0 19.36.23 # I can see the display flicker a bit if I move the player around 19.36.37 # I'll check if this is also present in the OF 19.36.44 # bertrik: Yeah, that's because of the software pwm. Looks the same in OF 19.36.57 # If you increase brightness to max it should be constant on. 19.37.49 # that's why I set it to exactly half brightness :) 19.38.16 # ranma: did you run battery_bench already ? 19.38.38 # Ok, so I suppose I'll commit the backlight variant detection real soon now :) 19.38.45 # nice 19.38.55 # funman: I did one once 19.39.04 # you remember the runtime? 19.39.40 # Should be in the forum thread, IIRC about 8-9 hours. 19.39.48 # do you think the backlight has its own variant, or is it the whole player that has two variants? 19.39.52 Join Luca_S [0] (~5712526b@giant.haxx.se) 19.40.11 # I can confirm the OF flickers too, but it seems a bit less obvious than rockbox 19.40.54 # Hmm, make that 4:17 19.41.08 # ranma: hm did you run it after my fix for FM radio? 19.41.20 # I was about to say that was before your FM radio fix :) 19.42.26 # bertrik: It's most likely a higher frequency. The current one uses the 100Hz timer and doesn't increase frequency for PWM. 19.46.02 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 19.46.47 Quit TillW (Remote host closed the connection) 19.53.08 Quit kugel (Ping timeout: 240 seconds) 19.53.17 Join Strife89 [0] (~michael@168.16.237.214) 19.57.37 Quit leavittx__ (Read error: Operation timed out) 19.57.40 Quit leavittx (Read error: Operation timed out) 19.58.50 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 19.59.55 Quit leavittx_ (Ping timeout: 258 seconds) 20.00.42 Join freddyb [0] (~chatzilla@pool-68-238-8-141.chi.dsl-w.verizon.net) 20.01.09 Quit Luca_S (Quit: CGI:IRC (EOF)) 20.01.19 Quit hd (Read error: Connection reset by peer) 20.01.46 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 20.01.47 Quit jd (Changing host) 20.01.47 Join jd [0] (~jd@Wikipedia/HellDragon) 20.02.04 Quit funman (Quit: free(random());) 20.03.36 Join Luca_S [0] (~5712526b@giant.haxx.se) 20.04.02 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.05.19 Join saratoga_lab [0] (~9803c20d@gateway/web/freenode/x-hhgpfavtipetxiki) 20.05.28 # Eugenpaul: ping 20.05.40 Join leavittx_ [0] (~leavittx@89.221.199.187) 20.06.35 Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) 20.06.36 # saratoga_lab: i'm here 20.08.40 # Eugenpaul: i suggested the mp3 project 20.08.57 # the idea was to look at libmad and other open source decoders and figure out how fast they could be made 20.09.08 # then make improvements in libmad until it was as fast as possible 20.09.26 # at present we have ideas about how to improve libmad, but no solid idea how good the codec itself is compared to other decoders 20.09.57 Quit stoffel (Remote host closed the connection) 20.10.13 # the project would involve learning about mp3 decoding and going piece by piece through the codec comparing to other implementations 20.10.50 # yes 20.11.55 Join leavittx [0] (~leavittx@89.221.199.187) 20.12.48 # its a difficult project in that we don't have a good idea how much improvement is possible 20.12.54 Join leavittx__ [0] (~leavittx@89.221.199.187) 20.13.13 # you said you had done some DSP before, but never any codec stuff right? 20.13.59 Join wodz [0] (~wodz@chello087206240004.chello.pl) 20.14.07 # yes, i know about dsp from university 20.16.39 # what stuff have you learned about? 20.18.51 Join _zic [0] (~user@91-165-239-13.rev.libertysurf.net) 20.19.50 Quit n1s (Ping timeout: 258 seconds) 20.19.58 # Did some testing on Fuze v2 recording and the FIFO runs out in the do_sw_pwm function. I tried changing the INT_TIMER2 so that it stacks do_sw_pwm in front of whatever was executing on return so that do_sw_pwm would be interruptible but I don't know ARM well enough. (The linker called me some very bad names.) 20.21.59 # freddyb: can you try http://www.rockbox.org/tracker/task/11172 ? it removes the scrollwheel portion of the button read 20.24.14 # saratoga_lab: i'm trying to remember... it was something like fourie transform, multiplexing... 20.24.45 # Eugenpaul: can you be more specific, DSP is something you can take a class in or a doctorate, knowing where you are along that line is helpful 20.25.06 Quit _zic (Quit: Leaving) 20.25.33 # freddyb: is the fifo so small? I find it strange that it doesn't surive the tick tasks 20.26.30 # we could do it like the of, it blocks button reading if the display is busy but I would rather avoid that 20.28.27 # kugel: i'm compiling your scrollwheel patch now 20.29.15 # saratoga_lab: it was classes 20.29.40 # FIFO is 32 words 20.29.54 Quit TillW (Ping timeout: 248 seconds) 20.30.44 Quit mitk (Quit: Leaving) 20.31.20 # I found out that to play mp3 on my MPIO hd200 it runs at ~100MHz while other coldfire based DAPs needs ~30MHz. Could it be that difference comes from generic ata code vs. asm optimized reads? 20.31.32 # is there some fifo almost empty interrupt? maybe it's possible to run that in the fiq so it's possible to refill it during the timer isr 20.31.35 # unlikely I think 20.31.56 # wodz: i would check that you have IRAM properly defined and that you are enablign all the coldfire ASM code in the codecs 20.32.11 # missing either of those would result in a huge decrease in performance on coldfire 20.32.26 # wodz: you probably need to go through the codec files and look for IRAM defines which are not yet enabled for *your* cf target. coldfire's ram is slow 20.32.49 # New commit by 03ranma (r25499): Detect C200v2 variant by reading A7, use A5 or A7 to control backlight and buttonlight depending on the result. 20.32.51 Quit flydutch (Quit: /* empty */) 20.32.54 # I think IRAM should be all or nothing, very few defines are target dependent 20.33.14 # saratoga_lab: whats strange ogg decoding is realtime ~120MHz 20.33.16 # check the .map file for libmad and see if it links to IRAM 20.34.02 # Kugel: We interrupt on half full, almost full, and full. I tried adding almost empty yesterday without any difference. 20.34.03 # or vorbis if you prefer 20.34.22 Quit TopyMobile (Ping timeout: 246 seconds) 20.34.41 # freddyb: we'd need the fiq in order to interrupt irqs 20.34.52 # saratoga_lab: maybe i understand you incorrect? what should i say? my knowledge is not deep enough, but i think i have basics and i am ready to learn 20.35.13 # Eugenpaul: no I just want to know what you've already learned about DSP 20.35.39 # i believe it's currently used for the pcm callback, but audio playing (with pcm involved) and recording at the same time is not possible so it should be possible to use it for the recording callback 20.36.58 # Kugel: I don't think it would take much to use fiq instead of irq but the way we do irq's the fiq will not trump it. I think the whole do_sw_pwm is in uninterruptible irq mode. I tried some changes based on the sample code in PL190 datasheet but didn't have any luck. 20.37.37 # the fiq is a special interrupt on arm which can interrupt irqs 20.41.00 # Kugel: I like the patch, can the same thing be done for the buttons? It seems stable for recording at 44kHz but still crashes on 96kHz. 20.41.16 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 20.41.46 # I dont think it can, the button pins don't change without setting some other pins before 20.42.13 # saratoga_lab: from vorbis.map part is linked to dram part to iram 20.42.31 # wodz: that should be fine then 20.42.55 Join TillW [0] (~Till@h92-net09.simres.netcampus.ca) 20.43.27 # can you also verify that it defines "CPU_COLDFIRE" in the codecs? 20.43.51 # that enables EMAC instructions in libmad, which are very important for performance 20.44.03 # if that is defined, I would also check that ICACHE is properly enabled 20.44.30 # also that you've clocked the CPU as high as you think you have :) 20.44.41 # gevaerts, does the IO priority commit also apply to flash targets? 20.44.43 # freddyb: how do you like the scrollwheel behavior with it? 20.44.58 # Very much. 20.45.05 # bertrik: it's enabled for flash. Whether or not it helps much is a different matter 20.45.15 # did it get slower or faster? 20.45.19 # saratoga_lab: hmm where should be CPU_COLDFIRE defined? 20.45.26 # freddyb: better than before? 20.45.56 # wodz: config.h probably 20.46.42 # The scroll speed seems the same but much more responsive. 20.47.44 # ok I definitely have CPU_COLDFIRE defined than 20.47.58 Join TopyMobile [0] (~topy@f048210034.adsl.alicedsl.de) 20.48.03 # * archivator just found about Cepstral LLC and their fabulous voices 20.48.14 # Perhaps we should add their engine to rbutil? 20.48.38 # CC apps/codecs/libmad/imdct_mcf5249.S makes me think it takes the correct one 20.49.21 Join fml [0] (~53ecea55@giant.haxx.se) 20.50.12 # Wouldn't the sansa C200v2 variant checking code an ideal candidate for the init func (recently introduced)? 20.50.52 # I think so 20.51.09 # ranma: I'm not sure we want " /* vim:set ts=4 sw=4 et: */" in our files 20.52.51 # I'm pretty sure we don't want it 20.54.49 # kugel: I have no SVN access now so if you want you can introduce the attribute 20.55.08 # what init func? 20.55.51 # bertrik: function that's only run once during the initialisation and then overwritten 20.56.06 # ah ok 20.56.50 # gevaerts, I'm not noticing any obvious delays or speedups on my e200 20.57.36 # bertrik: well, I don't think it can cause delays at all, and speedups will be limited due to flash already being fast 21.01.28 # I'd like to repeat a question from earlier today: is there any interest in a small cross-platform maintenance utility to be run Autorun-style? I'm thinking database purging, file system checks and updating as part of the functionality. Something small that runs everytime you connect the player to a PC.. 21.02.27 # archivator: if you want to do that, go ahead, but personally I think it's not a wonderful idea 21.03.31 *** Saving seen data "./dancer.seen" 21.03.51 # Well, if I'll be doing it, I'd like it to be more than a long script. I see it as an rbutil extra, updated as part of the tree. 21.05.26 # I don't really understand what you mean by database purging, filesystem checks can't really work if the tool to run them is on the same filesystem (and I think automated filesystem checks on plugin are a bad idea anyway), and I think automatic updates are a bit dangerous 21.06.17 Quit fml (Quit: CGI:IRC) 21.08.18 # gevaerts: last I checked, rockbox doesn't really delete entries from the database, it just sets a flag to skip them. That's what I mean - actually removing the deleted entries. A filesystem check can check for errors (and, on Windows, fix some of them). A warning along the lines of "Your filesystem is corrupted, fix it!" can be quite helpful. Automatic updates can be dangerous but they can also be something the user wants. 21.13.41 # Wouldn't a host-side thing be better? i.e. a set of udev scripts, a windows service, that sort of thing? 21.16.17 # Could be, I'm just brainstorming at this point. A windows service is a clumsy thing, though. I doubt I can get it to be notified on device insertion (I think you need a window for that). Plus, it would mean maintaining 3 projects instead of one cross-platform one (Qt-based, for example). 21.16.45 # archivator: I'm not too fond of such an idea. 21.17.43 # you can already install Rockbox Utility on the player. Why not include a new "cleanup" task group that can do such stuff? 21.18.29 Join Sergio [0] (~fake@h49-net159.svil.netcampus.ca) 21.18.33 # also, adding command line parameters to Rockbox Utility is something that's on my todo list since ages. Unfortunately the current design makes such a thing rather hard to implement (one of the issues I hope to address when reworking the UI) 21.19.10 # bluebrother: RockboxUtility is not exactly small. Plus, it would need a way to do things on startup (which it lacks). Also, I'm not sure how it handles being on the player but will changing mount points affect it? 21.19.47 Quit freddyb (Remote host closed the connection) 21.19.52 # archivator: yes, but I'm planning to change this (i.e. check if we have a portable installation and if yes automatically adjust the mountpoint) 21.20.02 # it seems portable installation is rarely used, though. 21.20.07 Nick adnyxo is now known as needhelp (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 21.20.51 # the problem with the size of Rockbox Utility is Qt -- linking it statically simply makes it big. So I don't think it's possible to create such a maintainance utility with less than 1MB if it's Qt based. 21.21.22 # however, the ~4MB it has on Windows is acceptable IMO 21.21.45 Nick needhelp is now known as adnyxo (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 21.22.07 # bluebrother: in any case, a new utility would be far smaller than Rockbox Utility (which, imho, contains far too many things to be considered adequate for the task). Plus, you can use UPX on Windows. 21.22.48 Quit Sergio (Ping timeout: 240 seconds) 21.23.06 # we already upx Rockbox Utility ;-) 21.24.32 # but what about maintainance for such a new utility? Given how many people actually work on Rockbox Utiltiy I don't think there will be a lot of people working on such a tool either. 21.26.05 # Well, there won't be much to maintain. It would only need to reflect changes in download locations and database structure. 21.27.20 # Both seem pretty stable and can be made incredibly easy to change (actually, the database bit can be taken from core rockbox - similar to how the database utility works) 21.27.53 # hmm. Well, feel free to work on such a thing. I'm not really convinced though. 21.29.49 Part watto 21.32.04 Quit RadicalR (Ping timeout: 245 seconds) 21.32.53 Join Sergio [0] (~fake@nat027.dc-uoit.net) 21.37.43 # New commit by 03bertrik (r25500): Make array static const in apps/recorder/jpeg_load.c 21.41.51 Join kugel_ [0] (~kugel@e178108105.adsl.alicedsl.de) 21.42.07 Quit kugel (Disconnected by services) 21.42.11 Nick kugel_ is now known as kugel (~kugel@e178108105.adsl.alicedsl.de) 21.42.15 Quit kugel (Changing host) 21.42.15 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.45.46 # domonoky: any thoughts on a new rbutil release? I think we have a nice bunch of fixes now. 21.45.59 # domonoky: I uploaded a new version of FS#11160 21.46.08 # unfortunately there was less response on my call for translators than I hoped :/ 21.48.49 # bluebrother: no problem with a new release. should we commit this tts/encoder paralellising now, or after the release ? :-) 21.49.35 # IMO doing it after a release would be better -- it gives us more time to try and fix possible issues :) 21.50.29 # hm, noone uses svn builds but developers, so putting it into the release will probably give faster reports of broken things :-) 21.50.47 # I think it should be left for after release if only so we can get the other engines parallelized as well. 21.50.50 # * bluebrother hopes for moos to look after the french translation soon 21.51.13 # domonoky: well, I do provide svn binaries for non-developers. 21.51.43 # maybe I should implement something to count downloads of those files. Too bad I don't have access to the server logs 21.52.35 # :-) 21.53.05 # in case it needs testing on MacOS 10.4... 21.53.39 # pixelma: not currently, TTSCarbon isnt currently paralelizied. 21.54.16 # but general rbutil testing on Mac 10.4 before release would be surely good :-) 21.54.58 # SAPI would be tricky, though. I can't think of a way to parallelize it without serializing access to the script's stdin (which would effectively serialize the entire process, more or less) 21.56.08 # well, I helped testing the voice fixes and remember having installed a theme to test back then and a build (I believe). I did not try a bootloader install though - neither separately nor wirh a "complete installation" 21.56.27 # or with 21.58.01 Quit xiainx (Ping timeout: 246 seconds) 21.58.34 # the theme was a 160x128 grey one for my M5 which reminds me of a specific feature request/bug report for RbUtil and another idea we discussed a while ago 21.59.29 # * bluebrother just pushed the weblinguist code to github, in case someone is interested. It isn't really nice code right now, though. 22.00.36 # hmmno - the feature request/bug report would actually be for the theme site 22.00.51 # saratoga_lab: I'm about my dsp experience. So, this is what i can remember from lectures (and what i think is useful in project): modulation, discretization, quantization, multiplexing by everything, coding (includes and Huffman coding), masking. Is it still too abstract? 22.01.19 # Eugenpaul: no thats a fine description 22.02.15 # saratoga_lab: and should i know anything else? 22.02.54 # well the application should be specific and convince us that you're qualified for the task 22.02.57 Quit Xerion (Ping timeout: 252 seconds) 22.03.11 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 22.03.15 # Is there anything special I have to think of when committing a language patch? 22.03.32 # maybe having secondary goals would be a good idea (working on aac decoding or some other codec) in case the mp3 stuff goes quickly 22.03.35 Quit hebz0rl (Quit: Ex-Chat) 22.04.42 # ok, thank you 22.05.10 # bertrik: a new language or an update? 22.05.10 Join robin0800 [0] (~robin0800@149.254.182.243) 22.05.21 Quit bmbl (Quit: Bye!) 22.05.26 # an update, from flyspray 22.06.05 Nick shaggy-h is now known as chrism (~kiwi@78-86-164-31.zone2.bethere.co.uk) 22.07.23 # a language which is spoken natively by a committer? Other than that... check if the translator is in CREDITS and also translators are usually mentioned in the lang file heade 22.07.24 # r 22.10.49 Quit pamaury (Quit: Page closed) 22.11.19 Quit kugel (Ping timeout: 265 seconds) 22.11.39 Quit Strife89 (Ping timeout: 268 seconds) 22.15.54 Quit ender` (Read error: Connection reset by peer) 22.16.28 Join ender` [0] (krneki@foo.eternallybored.org) 22.20.49 # New commit by 03bertrik (r25501): Slovak language update ... 22.22.52 # domonoky: I'm starting to think the parallelization should be user-controlled. At least there should be an option to turn it off. I have reason to believe festival splits the work into two processes already and with things like multisyn voices we might be slowing down the process rather than speeding it up. 22.23.29 # that* 22.25.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.27.03 Quit wodz (Quit: Leaving) 22.29.04 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) 22.29.26 Quit Zarggg (Quit: Zarggg) 22.29.29 # Hi just tried the latest build on the clip+ oh dear ;) 22.31.36 # notlistening: Is that a "This is all screwed up" oh dear or a "this is fantastic" oh dear? 22.32.57 Quit kugel (Remote host closed the connection) 22.33.19 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 22.35.43 # it's a wow this is screwed up oh dear and now it is a can not get it to screw up again oh dear just trying to reproduce the problem 22.36.20 # the inability to write to disk is a bummer 22.37.18 Join bieber [0] (~bieber@132.170.135.186) 22.38.03 # Are Summer of Code applications publicly visible as they're submitted, or do they just get shown after decisions are made? 22.38.49 # The abstracts for ones that are selected will be shown after the decisions 22.41.38 # I'm thinking about the show settings and the "show music" option specifically 22.41.52 # perhaps it would make sense to change it to "show media" so that mpg files are included as well 22.42.29 # it seems like more people would rather see both then see just one, and it can be quite confusing to new users 22.42.30 Quit scorche (Ping timeout: 264 seconds) 22.43.12 # at least my understanding is that the option is mostly to keep you from seeing playlist files and album art, so it seems like seeing mpg files would be useful as well 22.43.28 # that makes sense I guess 22.43.39 Quit mikroflops (Ping timeout: 260 seconds) 22.44.16 # makes sense to me to 22.44.22 # the use case that would be impacted negatively by this would be people who have mpg files mixed in with their music and do not want to see the mpg files 22.45.04 Part froggyman 22.45.11 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 22.45.29 # I'd say that "Show Media" shouldn't be an option until we have videos in the playlist system, and then it should be an additional option rather than replacing "Show Music" 22.45.50 # Perhaps "Show Music," "Show Videos," and "Show Media" settings would be best? 22.45.50 # With the third being the union of the first two, of course 22.46.00 # I can't imagine why "Show Music" is confusing to new users, though 22.46.08 # It's a quite explicit name, and it's not the default. 22.46.35 # people seem to ask about it 22.46.38 Join BdN3504 [0] (~5ce228ae@giant.haxx.se) 22.46.42 # Media might actually be confusing. Does that include images? Text? 22.46.44 # i think that option tends to get toggled without people thinking about it 22.46.51 # saratoga_lab: People have honestly asked "I've set it to show music and can't find my videos?" 22.46.56 # yes 22.46.59 # in the forums just now 22.47.11 # He knew he'd set it to show music? 22.47.14 # no 22.47.18 # Or it was set to show music without him knowing (something we can never solve) 22.47.26 # well if he did he didn't mention it, but he set it to music at some point 22.47.35 # That's my point - as long as there's *any* setting that can hide their music (such as "Show Playlists") then it can't be solved. 22.47.36 # presumably because he didn't realize that would exclude video 22.47.51 # if i restore an ipod on a pc using the "software version 1.3" for apple ipod gen 5, will i be able to rockbox it? or do i need to manually choose a different version of the apple software? 22.48.02 # saratoga_lab: I'd bet he accidentally set it due to the quickscreen's bad controls 22.48.10 # It's hard to leave the quickscreen without changing the "show files" option 22.48.14 # hmm well that should be fixed then 22.48.22 # maybe the show files option should be a little harder to find 22.48.26 # It's not the setting that's the problem, but the fact that you can set that setting without even knowing it. 22.48.27 Quit robin0800 (Read error: Connection reset by peer) 22.48.35 Join robin0800 [0] (~robin0800@149.254.182.243) 22.48.38 # * Llorean has said "show files" shouldn't be on the quickscreen for a while. 22.48.51 # i still think its odd that show music doesn't show mpg files, which are quite off music videos and such 22.49.04 # But anything on the vertical axis on the quickscreen is going to trigger accidental changes. You hold "Menu" on iPods to get there, but can't tap "Menu" to leave it (like you can many other things) 22.49.11 # i do agree with it not being on the quickscreen FWIW 22.49.24 # BdN3504: I'm not aware of any specific version required when restoring an Ipod with Itunes. 22.49.24 # saratoga_lab: Change "Show Music" to "Audio Files" 22.49.55 # bluebrother: i am more concerned about rb compatibility 22.50.00 # bluebrother did you manage with the wine detection bit for rbutil? 22.50.02 # it still seems more natural to me to group video and audio together since mpg contains audio 22.50.20 # Games contain audio too... 22.50.26 # one thing I really *hate* about the 4th option on the quickscreen: you can't leave the Quickscreen with the same button you entered it (something that worked before, and it's *really* annoying on an ipod) 22.50.37 # bluebrother: I just mentioned that. :) 22.50.57 # saratoga_lab: There should definitely just be a setting for "formats that can be played while in the WPS" whatever it's called. 22.51.16 # Or "formats that can be playlisted" 22.51.26 # Llorean: ok, I'm obviously too slow then :) 22.51.29 # well i think in the long term those limitations on video are kind of annoying and should be removed 22.51.40 # so i don't really see that as an argument for the setting now 22.51.59 # IMO we should really consider dropping the quickscreen completely and replace it with a user customizable menu (now the Quickscreen is customizable) 22.52.00 Join scorche [0] (~scorche@rockbox/administrator/scorche) 22.52.05 # saratoga_lab: Until this limitations are removed, though, the setting can clean up a directory view for people only wanting to see things they can insert in their playlist. 22.52.07 Quit Sergio (Ping timeout: 240 seconds) 22.52.22 # It'd be silly to make a mess of things now on the *hope* a feature will exist in the future that we've been saying should exist for years now. 22.52.32 # notlistening: yes, see r25471 22.52.52 # bluebrother: i also like that idea 22.52.58 # bluebrother: Personally, I think the quickscreen should show the "load .cfg file" screen, in which the user can have as many .cfgs of their favorite settings and combinations of settings as they like 22.53.01 # i.e. just replace the quickscreen with a list a user can put any option in he likes. 22.53.08 # No complication creating custom menus (or a UI to create them) but all the power of it, and more. 22.53.21 # like "my menu" various devices have these days 22.53.33 # i don't know about cfg files, but i do dislike hwo the current quick screen works 22.53.41 # i tend to get into it by accident and then change settings trying to get out of it 22.53.48 # Llorean: well, IMO a simple list should be rather straight forward 22.53.50 # its just ackward, at least on the players i've used 22.54.00 # the quickscreen was nice. Until it got changed 22.54.11 # bluebrother: I just think .cfg files would actually be quicker to change (more like the current quickscreen) 22.54.39 # But since the quickscreen is not likely to ever support the old Archos Rockbox quickscreen functionality, I'd say it should be dumped for some sort of list-based menu now. 22.54.56 # Llorean: probably, but it requires more work to set it up (and that might be quite problematic for average users) 22.55.43 # bluebrother: Add to the context menu of each setting "add current value to .cfg" like inserting things into the playlists in playlist catalog? 22.55.46 # yep, that's my point. If we get the old way back (didn't that work on h100 at some point?) there's no much point in keeping it as such a special case it is 22.56.00 # But a single customizable menu in place of the quickscreen also isn't bad. 22.56.18 # I'm pretty sure the H100 is the reason it stopped working - button combinations necessary for it to work weren't available. 22.56.42 # It was some reason like that, for some player at or shortly after. 22.56.50 # Llorean: that of course makes it easier. However, you still have to enter a filename which seems awkward for creating a customizable menu. 22.57.25 # iirc Mode + Joystick can get recognized on h100. Unless my memory serves me wrong. 22.58.05 # from my understanding the reason is that it broke at some time, and few developers knew (and know) how that feature was intended to work in the first place 22.58.14 # wasn't it Play which you could use with other buttons on the H100ß 22.58.43 Join Strife89 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) 22.58.48 Quit Eugenpaul (Quit: Eugenpaul) 22.58.51 # hmm. Probably play, yes. 22.58.55 # there are no (usable) button combos on the Iaudios though 22.59.54 # speaking of buttons: why does the jpegviewer plugin not invoke the menu on long Select on Ipods? Pressing a combo is awkward when plain Select does nothing 22.59.57 # Rockbox works fine, if an ipod 5.5g gets restored to the apple ipod software version 1.3 23.00.39 # BdN3504: there is no dependency between Rockbox and the apple firmware version. If the bootloader runs Rockbox will run. 23.02.51 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.03.29 Quit scorche (Ping timeout: 264 seconds) 23.03.33 *** Saving seen data "./dancer.seen" 23.04.10 Join scorche [0] (~scorche@rockbox/administrator/scorche) 23.04.19 Quit Zagor (Quit: Clint excited) 23.06.03 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 23.06.38 Quit notlistening (Remote host closed the connection) 23.07.44 Quit BdN3504 (Quit: CGI:IRC (EOF)) 23.11.19 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 23.13.06 Quit chrism (Ping timeout: 240 seconds) 23.14.17 Quit dockimble (Quit: WeeChat 0.2.1) 23.14.48 Join dockimble [0] (~dockimble@77.227.1.24) 23.19.04 Quit liar (Quit: bye boomshanka) 23.27.32 Join Surge97 [0] (~fake@h49-net159.svil.netcampus.ca) 23.28.13 Quit goffa (Ping timeout: 276 seconds) 23.32.41 Join goffa [0] (~goffa@70.33.8.114) 23.33.02 Join froggyman [0] (~me@unaffiliated/froggyman) 23.40.57 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.43.36 Quit bieber (Quit: Leaving) 23.47.48 Quit planetbeing_ (Quit: planetbeing_) 23.48.07 Quit bertrik (Quit: Leaving) 23.48.13 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 23.48.20 Quit GeekShadow (Quit: The cake is a lie !) 23.48.28 Quit evilnick_B (Quit: Page closed) 23.49.35 # New commit by 03Blue_Dude (r25502): Bookmark.c cleanup, still no functional changes... yet 23.54.52 Quit archivator (Quit: sleep time!) 23.56.52 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])