--- Log for 19.12.108 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 10 days and 15 hours ago 00.00.20 # It is very possible that the sd driver works fine when unboosted, but causes error when boosted 00.00.49 # WAV needs virtually no cpu, hence no boosting. Flac needs a little more, but most likely still no boosting 00.00.50 # yea could be 00.01.03 # but it's boosting upon rebuffering 00.01.07 # Ogg is more demanding than flac, and mp3 in turn is more demanding than ogg (on arm) 00.01.32 # Using dsp adds to that, and it matches the observations... 00.01.36 # mp3 needs more than vorbis? 00.01.46 # on non-multicore yes 00.01.47 # Yes, on arm it does 00.02.16 # then why did the rio karma get more battery life from mp3 than from ogg? 00.02.28 # * ameyer wanders back on-topic 00.02.29 # What architecture does the karma use? 00.02.30 # It depends on the decoder, the architecture, ... 00.02.59 # Besides, isn't the karma rather old? 00.03.11 # They may have had an effecient mp3 decoder, inneficient ogg decoger, ... 00.03.15 # amiconn: flac is also fine when forcing boost 00.03.25 # amiconn: I think it has a PP5003. Some sort of PortalPlayer dual-core ARM thingy 00.03.31 # * BigBambi can't type or spell :( 00.03.55 # and it depends on your definition of old. 2003. 00.03.58 # I was thinking more about which codecs were available at that time. 00.03.58 Join einhirn [0] (i=Miranda@p5B033776.dip0.t-ipconnect.de) 00.04.50 # (1) When was Tremor released? and (2) Rockbox has optimised Tremor a lot... 00.05.59 # is there some way i can get an idea (order of magnitude is probably close enough) of how much memory is available in the plugin_buffer for various targets? the sim seems to fake it and I only have one player 00.06.37 # 512KB on anything higher than 2MB total ram 00.06.51 # I think 8KB on <= 2MB 00.06.56 # 32KB 00.07.06 # perfect, thanks 00.07.08 # oh sorry, 32KB 00.07.31 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 00.07.36 # That is, 32KB on the old Archoses. Not sure how big it is on the low-mem ams Sansas 00.07.57 # maybe the sim isn't faking it too hard then, i just assumed there would be more variation 00.08.07 # that's not finally decided I guess. It'll likely depend on what's going to happen with the flash buffer patch 00.08.51 # mud-rb: given that we try to have the plugins running similar on all targets I see no reason for variation 00.09.00 # The sim tries be fairly correct, just that it gives you exactly that amount *in addition* the plugin binary (which is a shared object/dll in the sim) 00.09.37 # On target, this buffer is shared between the binary and what you can request 00.10.08 # kugel: I'd the flash buffer patch has nothing to do with that. 00.10.12 # I'd say 00.10.37 # Zagor: why? I think it's a valuable option to free ram for plugins, isn't it? 00.11.27 # no 00.11.28 # no, because it breaks so many other things. we can simply reduce the buffer size on flash targets and gain the same effect without changing any code 00.11.41 # Plugins are always allowed to stop playback if they want 00.11.52 # iirc the watermarks are a problem 00.12.26 # The watermarks are a problem on anything swcodec, just that problem doesn't hit as hard on bigmem targets 00.13.32 # hmm, i wonder if that watermark bug is still possible ro trigger 00.13.41 # I mean (I remember some talk) that due to the watermarks there needs to be at least 512KB or so audio buffer, which isn't really given on our 2MB ams sansas 00.14.03 # and that the flash buffering doesn't have to mess with those 00.14.15 # amiconn: btw, is that "dreaded shuffled playlist resume bug" you mentuioned earlier in FS? 00.14.19 # kugel: But we can set the watermark much, much lower, though. 00.14.27 # It's not like any of this is set in stone. 00.14.32 # (1) The anti-skip buffer setting is meant as an *additional* safeguard against skipping. It should be possible to set it to 0 without ill effects if the disk is in good shape and the player is sitting on top of the table, i.e. not shaking 00.14.39 # kugel: the proper solution is to fix the watermarks, not add code that avoids them 00.14.50 # ok 00.15.32 # (2) Hwcodec calculates watermarks dynamically depending on bitrate and measured (!) spinup time (if available, otherwise uses a safe default). It does so for ages. Swcodec still doesn't afaik 00.15.49 # n1s: Not sure 00.17.05 # the only one i can find that sounds remotely like it is FS#9531 00.18.30 # amiconn: i think swcodec does adjust the watermark based on bitrate but it isn't working 100%, I remember being able to cause it to underrun before managing to spin up using flac 00.18.54 # * Zagor found http://sourceforge.net/projects/gdbstubs 00.19.08 # this bug is FS#6479 00.20.22 # i really should retest that 00.22.04 Quit ender` (" Variables won't. Constants aren't.") 00.24.46 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 00.25.51 Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) 00.27.32 # http://sourceware.org/rda/ might also be interesting for Mr Someone writing a gdb stub 00.30.33 Quit bluebrother ("leaving") 00.31.55 # just out of curiosity, how would you hook it up to a computer? can it be done over USB? 00.32.25 Quit Nico_P (Remote closed the connection) 00.37.28 # n1s: I think so, yes. as long as the loaded images don't touch usb. 00.38.09 # ah, then it sounds like a pretty nice thing indeed :) 00.40.31 *** Saving seen data "./dancer.seen" 00.43.37 Join Tangent1 [0] (n=asher@c-98-219-162-69.hsd1.pa.comcast.net) 00.43.58 # i think there's an error in the ipod video rockbox manual 00.44.31 # the commands for select + menu and Menu are reversed for the cube app in 11.2.3 00.47.43 Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") 00.50.06 # heh, postage is cheaper than I thought to send international 00.50.26 # I sent a Sansa Clip to kugel and the postage was less than $3usd 00.50.40 # it is a really tiny thing though 00.50.58 # I was worried it'd cost 10 bucks or something 00.51.16 # lucent: This is the sort of thing that belongs in -community. 00.51.38 Quit petur ("Zzzzz") 00.52.58 Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net) 00.53.59 Quit Zagor ("Clint excited") 00.54.19 Quit tessarakt ("Client exiting") 00.59.15 Quit herrwaldo ("Konversation terminated!") 01.00.48 Quit miepchen^schla () 01.03.47 Join miepchen^schlaf [0] (n=miepel@p579EC91E.dip.t-dialin.net) 01.03.48 Join mib_f8zilifj [0] (i=d8ef55ba@gateway/web/ajax/mibbit.com/x-55e8e49684aee3ea) 01.04.01 Nick mib_f8zilifj is now known as MarcGuay (i=d8ef55ba@gateway/web/ajax/mibbit.com/x-55e8e49684aee3ea) 01.04.37 # Tangent1: You can report a bug here in flyspray if you like. 01.05.13 # Missing link: http://www.rockbox.org/tracker/ 01.13.10 Join HBK- [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 01.13.45 Quit HBK (Read error: 110 (Connection timed out)) 01.13.46 Nick HBK- is now known as HBK (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 01.15.09 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.16.58 # kugel: Is this comment on the VMWareDev wiki page "The image should be prepared for everything with rockbox. This includes having the 7zip (debian package p7zip) preinstalled, since the Rockbox sourcecode is in a 7z archive." a suggestion or...? 01.18.06 # did someone else already move fixes over that should be in the release branch too? Maybe the updated translations, rasher? 01.18.41 Quit einhirn (Read error: 104 (Connection reset by peer)) 01.19.11 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 01.23.59 Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") 01.24.54 # hmm... those were before the branch 01.25.31 # or not... 01.26.20 # pixelma: they were commited to both branch and trunk in rev 19471 and 19472 01.26.40 Join _Auron_ [0] (n=DarkAuro@ppp-70-244-161-118.dsl.rcsntx.swbell.net) 01.27.02 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 01.27.48 # ah thanks, it was already dropped off the "most recent" list on the frontpage 01.28.15 # i think the frontpage only displays commits to trunk 01.28.43 # yeah, but you can follow the gaps in the revision numbers 01.29.02 # as an indicator 01.29.10 # yes 01.29.45 # MarcGuay: yes 01.29.46 Quit t0mas ("Leaving") 01.30.51 # Unhelpful: what do you think about my latest pf comment? 01.31.38 # about zoom? i'm probably leaving it alone for now, unless somebody wants to work out how to rebuild cache on-the-fly 01.31.56 Quit TMM (Remote closed the connection) 01.32.06 # I don't 01.32.22 Join TMM [0] (n=hp@5ED10264.cable.ziggo.nl) 01.32.29 # zoom is sufficient imho if the album art is preresized to lcdheight/2 01.33.22 Quit ZincAlloy ("CGI:IRC (Ping timeout)") 01.33.31 # i'd prefer to never touch the zoom, if it's going to keep working by moving the camera. the result is equivalent to NN scaling, and is not pretty. 01.33.36 Join CaptainKewl [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) 01.35.26 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 01.35.31 # pixelma: c200 is landscape, right? what's wrong with the tracklist there, is it just about space, or is there something else? 01.35.44 Part Tangent1 01.35.51 # Unhelpful: keymap issue 01.35.55 Quit aneqrs () 01.36.05 # ohhh.. that i don't know if i want to touch 01.36.33 # * n1s would guess you don't :) 01.37.42 # Unhelpful: you might want to checkout FS#8335 how I "implemented" a working resizing in pf, you'll maybe have a better overview 01.37.55 # IMHO, unless someone steps forward and wants to work on getting PLA working, we should drop it and go back to regular keymaps were it's used currently 01.38.33 # pla is working 01.38.38 Quit robin0800 (Remote closed the connection) 01.38.39 # yep, "down" is also used as "menu" so you can't move down because you call the menu instead. And since it's using pluginlib actions it's not easy to find a fix - without either breaking other targets or breaking other plugins that use this system or invent exceptions (which the PLA system wanted to avoid) 01.39.01 # kugel: i've got that part working just fine, though... what i'm doing now is to get rid of the preferred sizes stuff entirely, in favor of scaling to LCD_HEIGHT/2 on load, and letting the user use zoom if they don't like that 01.39.04 # kugel: for various degrees of "working" ? :) 01.39.26 # but the variety of targets make it difficult to have a "all-in-one" keymap of course 01.39.39 # ...now i *know* i don't want to be in this 01.39.42 # kugel: not practically and not when combining contexts as so many (almost all) do 01.39.53 # n1s: name me an issue with pla except pf? I don't know of any other 01.40.02 # metronome 01.40.18 # yeah, afaik metronome isn't usable at all on c200 01.40.33 # and Ondio and Player 01.40.34 # c200 seems to be a special breaker for pla :) 01.40.39 # also bubbles had some issues but i think they finally got fixed 01.40.55 # bubbles has stupid exceptions - that being the first plugin which used it 01.41.19 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 01.41.45 # you basically can only use it for demos as of now, and not even for all 01.41.52 # I think using the core actions where they fit and defining your own keymaps where they don't would be sensible 01.42.37 # the breaker IMO is combining contexts which will always cause "overlapping" for some buttons for one or the other targets 01.42.45 # (not sure if plugins can use core actions currently though) 01.43.07 # text editor does 01.43.47 Quit n1s () 01.44.05 # maybe pla should be reworked to export core actions which are available on all targets 01.44.28 # instead of defining dozens of contexts intefering each other 01.47.22 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 01.47.37 # fdinel: hey 01.48.14 # kugel: or maybe only one "active" context at a time? 01.48.40 Part toffe82_ 01.53.11 # Unhelpful: in the current pla each context contains very few actions 01.53.15 # pixelma: 19476 is pretty wordy for something rather insignificant. I'm tempted to suggest we swing back the other way and take it out completely but maybe that's not great, either. I think it was Chronon who put it in? 01.53.41 # kugel: hi, I'll be back later, I gotta go ;) 01.55.18 # lol 01.56.16 # pixelma: wasn't the consensus to move wiki text into the manual (and delete the wiki pages after) instead of the manual linking to wiki pages? Sorry if I'm wrong 01.57.07 # kugel: feel free to write the album art paragraph as there is none currently... ;) 01.57.42 # MarcGuay: it was the result of a discussion earlier here when someone asked about it again (could be that i's already in yesterday's log). Explanation by Llorean, I'm too sleepy for discussing that now 01.57.56 # pixelma: I understand. 01.58.00 # not sure who first put it in 01.58.15 # No, I don't want to get the manual people jobless ;) 01.58.27 # Wordiness is part of the RB tradition, it won't be out-of-step with the rest of the project. 01.58.53 # also it sounds like a rather messy job to me, as the albumart wiki page is already kinda messy imho 01.59.15 Quit Thundercloud (Remote closed the connection) 01.59.33 # * kugel doesn't want to admit that he's latex newb 01.59.57 # also, I think there are some things that should stay in the wiki (not sure that's a good example but different encoding tools for mpeg come to my mind currenty - that would make a looong paragraph in the manual and is ever changing) 02.00.42 Join massiveH [0] (n=massiveH@ool-44c4781b.dyn.optonline.net) 02.00.51 Quit massiveH (Read error: 104 (Connection reset by peer)) 02.01.10 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") 02.03.26 # *mpegplayer 02.05.07 Quit robin0800 (Remote closed the connection) 02.05.28 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 02.12.40 Quit PaulJam (".") 02.16.26 Quit MarcGuay ("http://www.mibbit.com ajax IRC Client") 02.20.04 Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-04e6630a46a9c880) 02.26.35 Quit MethoS- (Remote closed the connection) 02.27.20 Join massiveH [0] (n=massiveH@ool-44c4781b.dyn.optonline.net) 02.27.58 Quit massiveH (Client Quit) 02.30.11 # hrm... 02.32.03 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 02.37.14 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-8cfcb76605a2b216) 02.38.24 Quit Seed ("cu, Andre") 02.40.35 *** Saving seen data "./dancer.seen" 02.42.24 Quit moos ("Rockbox rules the DAP world") 02.50.34 Quit faemir (Remote closed the connection) 03.04.43 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 03.04.59 Quit mc2739 ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") 03.05.55 Quit thegeek_ (Read error: 104 (Connection reset by peer)) 03.10.24 Quit BlakeJohnson86 (Remote closed the connection) 03.15.24 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 03.17.52 Quit BlakeJohnson86 (Read error: 104 (Connection reset by peer)) 03.18.18 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 03.20.29 Join Torne [0] (i=torne@lil.wolfpuppy.org.uk) 03.22.02 # i'm trying to create a new plugin, as a subdirectory like some of the others. I've added it to SUBDIRS and copied one of the other makefiles with the names adjusted, and it only compiles my sources, it doesn't actually link the plugin 03.22.23 # i'm wondering what i can possibly have done wrong. it adds itself to ROCKS in the makefile 03.23.52 # did you place your plugin's name into CATEGORIES? 03.24.06 # yes 03.25.39 # here's my makefile: http://pastebin.com/d2bffa132 03.25.47 Quit lasser (Read error: 110 (Connection timed out)) 03.25.55 # i presume it's getting included, because make all does actually compile the source files 03.26.22 # but it doesn't produce the .elf or .rock and there are no messages about them in the make process :) 03.37.33 Nick Bensawsome is now known as pacman (n=Bensawso@unaffiliated/bensawsome) 03.37.48 Part pacman ("The awsome is gone :(") 03.40.28 Quit vertic39 () 03.40.49 # make -d believes it *has* made the file 03.40.55 # but it did so by executing no commands 03.42.34 # aha. plugins.make doesn't work if none of your sources have the same name as the plugin 03.43.00 Quit robin0800 (Read error: 60 (Operation timed out)) 03.47.11 Part Torne 03.57.53 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 03.58.13 Part Bensawsome ("The awsome is gone :(") 04.09.37 # Anyone interested in getting "live" results of the sansa c200v2 disassembly? :) 04.10.52 # fdinel: lol, maybe? 04.11.15 # fdinel: I want to learn / observe more about how arm disassembly is done 04.11.58 # well the LCD init routine is at 0x429C from what I can tell 04.12.18 # it uses DBOP as for the other ams targets 04.15.51 Join ajonat [0] (n=ajonat@190.48.102.173) 04.18.03 # fdinel: there's a big need to figure out the remaining GPIO pin usage on Fuze target at least 04.18.20 # the scrollwheel, and "hold" "home" buttons 04.18.30 # yeah though it seems quite harder because of the wheel 04.18.41 # I'm kinda lost in there :/ 04.18.43 # brb 04.20.57 # okay 04.21.33 # fdinel: really there's some issue with accessing data from Flash above a certain sector, this is caused by an unknown factor 04.21.45 # it may be that we don't select the chip or something else 04.26.41 Join webguest55 [0] (n=7b72fc36@gateway/web/cgi-irc/labb.contactor.se/x-497f2167ecfed540) 04.28.31 Join blkhawk- [0] (n=blkhawk@f051198140.adsl.alicedsl.de) 04.28.35 # is FS9662 really a bug? i assumed the sansa was supposed to work like that 04.29.27 Join toffe82 [0] (n=chatzill@99.146.80.191) 04.29.54 # saratoga: how do you mean? the behavior just seems inconsistent unless there is activity on the SD 04.30.32 # oh my mistake 04.30.38 # saratoga: I looked at the wrong bug 04.31.11 # saratoga: I don't have a comment on bug 9662 04.36.25 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 04.37.09 # hi all im a total newbie to rockbox,and i wonder what the rockbox is and used for. 04.37.29 # http://www.rockbox.org/wiki/WhyRockbox 04.38.35 # scorche:thanx. 04.38.51 Join planetbeing [0] (n=planetbe@c-71-235-96-172.hsd1.ct.comcast.net) 04.40.38 *** Saving seen data "./dancer.seen" 04.43.55 # wow Rockbox really rocks! 04.45.00 Quit blkhawk (Read error: 110 (Connection timed out)) 04.45.04 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-c3d22858be2c2e6a) 04.45.29 Nick blkhawk- is now known as blkhawk (n=blkhawk@f051198140.adsl.alicedsl.de) 04.46.49 # lucent: with the fuze, how are buttons read? 04.46.59 # I thought we needed to use DBOP for that... 04.49.33 # DBOP is mostly for writing, it has only limited ability to read pins, and cannot use interrupts, so its not so good for buttons 04.50.07 # fdinel: some of the buttons seem to have direct GPIO 04.50.11 # we thought it might be used for the wheel, just because we couldn't find it on the GPIO, but that seems somewhat unlikely since theres no obvious way to get interrupts out of it and you'd probably need interrupts to read the wheel 04.50.23 # up/down/left/right/select work with direct GPIO 04.51.20 # hmm 04.51.42 # that strange I didn't manage to see those in the OF :/ probably lookking at the wrong place 04.54.26 # fdinel: what command do you like to use to disassemble the OF? 04.54.39 # are you cutting out the arm code first or working with the OF bin? 04.54.44 # Does iPod Classic support Rockbox? 04.56.13 Quit jhulst (Read error: 110 (Connection timed out)) 04.56.36 # * ameyer facepalms and says "assuming you're talking about the 6th gen ipod, no" 04.57.38 # if you're applying the new-ish term "iPod Classic" to an older iPod that wasn't called that when it came out (1st-5.5th gen), yes 04.58.29 # webguest55: the devices rockbox supports are on the front page.. 04.58.59 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 04.59.16 # i find model classic is not listed 04.59.40 # exactly. 05.00.08 # actually it is listed, mostly because people kept asking 05.00.17 Part toffe82 05.01.05 # we didn't used to list it though 05.02.07 # "Apple: 1st through 5.5th generation iPod, iPod Mini and 1st generation iPod Nano (not the Shuffle, 2nd/3rd/4th gen Nano, Classic or Touch) " seems pretty explicit, webguest55 05.02.24 # i insist that some models be missing 05.03.10 # well, it's pretty clear about the Classic 05.03.17 # perhaps it is you who is missing something 05.03.22 # how ironic 05.04.34 # webguest55: talking about these "missing" models is not going to make them supported any more than not being listed and not being supported ;) 05.06.02 # yup,maybe it is my fault 05.06.44 # yes we know 05.06.53 # webguest55: the list shows what DOES work...anything missing doesnt work...this is the entire point of the chart 05.08.58 # webguest55: also we don't have any particular model to suggest that runs rockbox because none of the supported targets are in production 05.12.18 # they are all very old and outta stock for a long time 05.13.23 Quit _lifeless (Remote closed the connection) 05.13.59 # you're a little late to the party 05.14.54 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 05.15.58 Quit BHSPitLappy ("Ex-Chat") 05.16.05 Join _lifeless [0] (n=lifeless@90.151.223.50) 05.24.36 # for the logs: ReadHold on the c200v2 is located at 0x3FD4 05.34.01 Quit saratoga ("CGI:IRC (EOF)") 05.34.55 Quit Horscht ("Snak 5.3.3 Unregistered copy. Evaluation period is over. Program will now quit. Thanks for using Snak.") 05.39.53 # webguest55: you can get supported players on the aftermarket or the SansaV2 players are going to be supported some time in the near future 05.40.14 # perhaps for questionable values of "near future" 05.46.41 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 05.48.05 Quit XavierGr () 05.53.45 Quit Aurix_Lexico (Read error: 110 (Connection timed out)) 05.57.43 Quit webguest55 ("CGI:IRC (EOF)") 06.00.30 Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) 06.00.50 # ameyer: I'm pretty confident it'll be "not so far" :P 06.01.10 # anyway, see ya peeps. 06.01.15 Quit amiconn (Nick collision from services.) 06.01.17 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 06.01.52 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.02.00 # neat 06.02.41 Quit pixelma (Read error: 110 (Connection timed out)) 06.14.28 Join TouchOdeath [0] (n=TouchOde@adsl-75-33-104-158.dsl.ltrkar.sbcglobal.net) 06.17.50 # I am wanting to access the hidden files/firmware in my insignia sport player in hopes of being able to modify them, whats the best way to approach this? 06.20.20 # TouchOdeath: please talk about it on other channels. This is for Rockbox only. 06.23.36 # TouchOdeath: um, there was a forum post about something similar 06.23.58 # TouchOdeath: http://forums.rockbox.org/index.php?topic=13961.msg119167#msg119167 06.24.20 # TouchOdeath: anyways it's kind of off-topic since rockbox should read these files as I mention them, no problem 06.24.51 # ty very much lucent, you the man 06.25.34 # should i get some opinions/consensus on my current scaler work before committing? i consider everything before the hq-for-greyscale part to be fairly trivial... but that last chunk is not so trivial 06.30.28 Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) 06.31.40 Join alexbobp_ [0] (n=alex@69.149.25.200) 06.39.05 Quit alexbobp (Read error: 145 (Connection timed out)) 06.40.40 *** Saving seen data "./dancer.seen" 06.44.07 Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) 06.54.52 Quit parafin (Read error: 113 (No route to host)) 07.15.19 Nick alexbobp_ is now known as alexbobp (n=alex@69.149.25.200) 07.17.24 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 07.17.32 Quit jhulst_ (Remote closed the connection) 07.22.18 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 07.33.25 Quit jhulst (Read error: 113 (No route to host)) 07.49.12 Nick jhulst_ is now known as jhulst (n=jhulst@unaffiliated/jhulst) 07.51.03 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 07.53.02 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 08.06.01 Quit jhulst (Remote closed the connection) 08.06.23 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.08.05 Quit J-23 (Nick collision from services.) 08.08.17 Join J-23 [0] (n=kvirc@a105.net128.okay.pl) 08.11.47 Join Rob2222 [0] (n=Miranda@p4FDCF95D.dip.t-dialin.net) 08.13.30 Quit ajonat () 08.15.09 Join __lifeless [0] (n=lifeless@83.219.11.225) 08.15.37 Quit _lifeless (Remote closed the connection) 08.22.50 Join midgey [0] (n=tjross@c-71-205-31-207.hsd1.mi.comcast.net) 08.23.57 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 08.28.12 Join fredddy [0] (n=freddy@p3E9E1C07.dip0.t-ipconnect.de) 08.28.41 Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") 08.30.07 Join Martyn [0] (n=martinb@adsl-70-231-242-168.dsl.snfc21.sbcglobal.net) 08.30.40 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.31.26 Quit BigBambi (Read error: 113 (No route to host)) 08.33.16 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 08.33.33 # What is the least-capable Rockbox device? 08.33.54 # Absolute simplest, smallest image .. lowest number of buttons, etc... 08.34.04 # if I had to guess? Sansa Clip 08.34.06 # no 08.34.12 # that's actually pretty badass for what it is 08.34.18 # archos player 08.34.24 # lucent: clip is not a rockbox device... 08.34.45 # Okay, I need to buy one and have it as a reference platform. One of the old Archos 20's? 08.35.04 # Martyn: reference for what? 08.35.12 # Martyn: the least capable is the player, which actually has a charcell display (not bitmap) 08.35.36 # lucent: as i have said before, please do not reference the a 08.35.40 # scorche : Reference platform for UI development. 08.36.04 # for bitmap targets, I'd say the archos ondio is a good choice. b/w lores screen and limited set of buttons. 08.36.06 # AMS devices until they are on the front page unless you are referring to development stuffs 08.37.12 # on the other hand, I've been spotted saying I think the archos targets are due for abandonment 08.37.15 # scorche: got a better suggestion than the Clip? tell Martyn 08.37.30 # I'm willing to learn 08.37.41 # Well, as long as they are supported for the moment, it makes a good target for "keeping things simple" 08.38.08 # And I can get an ondio for less than $20 from Wierd Stuff 08.38.12 # * JdGordon chants "kill off the charcell targets" 08.38.13 # Martyn: also if you're looking to purchase, what's your budget? Maybe I could help find a deal on something 08.38.44 # lucent : I'm in the San Francisco / Bay Area .. cheap gadget central 08.38.46 # lucent: the point of this is that the clip is STILL not a supported target, so suggesting it blah blah.. 08.39.12 # doesnt the c200 have a button limitation also? 08.39.14 # Okay. I like the Ondio .. looks GOOD and simple. 08.39.19 # JdGordon: there's actually only one charcell target. I'm more in the "kill of the hwcodec targets" camp 08.39.38 # off even 08.39.43 # I'm hoping to have the Flash mockups finished by next week, and get some feedback on the look and feel 08.39.47 # killing hwcodec would be nice, would let us get rid of the button bar also 08.39.58 # If the mockups are in the realm of 'acceptable', I'll code up a framework. 08.40.14 # Martyn: I'm looking forward to it. Prepare for long discussions. :-) 08.40.19 # *nod* 08.40.42 *** Saving seen data "./dancer.seen" 08.40.53 # Wow .. the ondio is also -very- limited in other ways. Firmware size... 08.41.03 # yeah 08.41.20 # I'm not a huge fan of abandoning anything, to be honest? 08.41.39 # Learn from Python .. at some point it's worthwhile to deprecate 08.41.48 # Java didn't, and they are paying for it in bloat. 08.41.53 # why not abandon greyscale targets so you can ditch all the grayscale cruft 08.42.08 # lots more greyscale targets than hwcodec 08.42.36 # also its not about the display, its about the compeltly different audio mechanism (and the display for the charcell) 08.43.00 # pardon my not knowing, what is "charcell" mean in rockbox context? 08.43.05 # yeah, and probably many more grayscale targets still in use 08.43.15 Quit GodEater_ (Remote closed the connection) 08.43.16 # lucent : Non bitmap display 08.43.21 # oh 08.43.32 # lucent : Literally, a display with two lines of characters (or more) 20-40 characters wide (sometimes) 08.43.44 # I mean, if the archoses got ditched, I can't see a fork. If you ditch grayscale, I can see a fork happening. 08.43.47 # that's scary 08.43.49 # so it can only display certain characters, which can sometimes (but not always) be programmed on the fly. 08.44.03 # does anyone still use the archoses? 08.44.12 # ameyer: I do, in the car 08.44.15 # Easy way to tell -- check the downloads :) 08.44.34 # I'd be interested in seeing those statistics, actually ... #downloads of different platforms during an update 08.44.47 # Gives a good indication what platforms to concentrate on 08.44.57 # not really... 08.45.14 # the general feeling here is we work on what we want, not by how many downloads we get 08.45.29 # especially because the download stats are so rediculously inacurate 08.45.38 # Martyn: so, Clip display is a tiny monochrome OLED display, maybe 128x64 pixels, but that's not charcell? 08.45.48 # are the archoses the only sh target? 08.45.50 # lucent: no, that's bitmap 08.45.54 # ah 08.45.58 # thanks for clearing that up 08.46.06 # (I assume sh == Super H) 08.46.19 # ameyer: yes 08.46.30 # JdGordon : Heh, since I come from a corp programming background (deadlines, etc) I'm used to things being the other way around. 08.47.10 # Martyn: refreshing, eh? :) 08.47.22 # Well, yes and no. 08.47.32 # Some of the principles of structured programming -are- good. 08.47.37 # Even in an open source / open dev project. 08.47.38 Quit lucent ("bbl") 08.48.05 # lucent: http://www.crystalfontz.com/products/index-std.html are charcell displays 08.48.17 # when was the last supported archos target discontinued? 08.48.23 # e.g. I'll pick something to work on, get some consensus, and then actually still work the way I always have. Plan it out, architect it, look at the potential impact on other codepaths, then code. 08.48.33 # well, most rockbox devs do programming for a living too 08.48.55 # ameyer: we have never discontinued a target 08.48.58 # Martyn: what is this "plan it out" you speak off? 08.49.03 # JdGordon : I have one of Crystalfontz wonderful USB bitmap displays. Good LORD I love those things. 08.49.17 # * JdGordon got 3 of them for free a few years ago :) 08.49.23 # JdGordon : Heh... when working with OOP .. I even do *gasp* UML diagrams 08.49.28 # Zagor: I mean discontinued by archos 08.49.32 # :O 08.49.48 # ameyer: ah. that was quite a few years ago... 08.50.03 # Oh, I love being a Geek sometimes. 08.50.04 # afaict, 2003? 08.50.26 # My housemate -has- an Archos Ondio ... awesome. 08.50.34 # * Zagor looks into the time machine 08.50.39 # We'll have to see if we can get it working. 08.50.51 # not sure about the Jukebox Recorder, FM Recorder, Recorder v2, or Ondios 08.50.57 Join n1s [0] (n=nils@rockbox/developer/n1s) 08.51.26 # gah, "access to http://www.archos.com has been blocked by the site owner via robots.txt." 08.51.43 # ah well, not important 08.51.54 # Wow, this thing is ... tweaky 08.51.57 # ameyer: The Ondios are the newest. Btw, the Ondios are in no way more restricted than the other archoses 08.52.00 # Reminds me of the old Jukebox 08.52.17 # amiconn: don't they have fewer buttons? 08.52.17 # The first 20G PMP 08.52.19 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 08.52.39 # Martyn: yeah those are quite alike 08.52.40 # amiconn: come on.. really? small screen, almost no storage, hwcodec... no buttons,.. 08.52.50 # Zagor: I mainly thought of size restrictions 08.52.53 # JdGordon: "than the other archoses" 08.52.54 # so, what are the odds of any swcodec targets getting ditched any time soon? 08.53.05 # * JdGordon really should read whole sentences 08.53.16 # Zagor: The Ondios have the same number of buttons as the Player 08.53.24 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.53.24 # ameyer: ziltch.... 08.53.58 # amiconn: right, I disqualified the player ince it has no bitmap. 08.54.30 # ameyer: why would we? 08.54.32 # JdGordon: The screen is the same size as the recorders. I already mentioned the buttons. And they are hwcodec the same way as the other archoses 08.54.53 # And an MMC slot is a useful thing (regarding storage) 08.55.26 # amiconn: he didnt see the " than the other archoses" part and assume you were talking about for all targets 08.57.02 # amiconn: yeah sorry, missed the last part of the senatcne 08.58.15 Quit bertrik (Remote closed the connection) 08.58.33 # Zagor: you could ditch some grayscale cruf by ditching some of the targets, although I can't see rockbox ditching over half of its targets, some of which (iPods, h1x0) are fairly popular. 09.00.08 # I think forking off the hwcodec stuff and going into bugfix-only mode might not be the worst idea 09.00.25 Join petur [0] (n=petur@ip-212-239-214-166.dsl-static.scarlet.be) 09.00.37 # greyscale doesnt make things any more difficult than colour... a reason to kill off hwcodec is because the playback engine is entirly different, so its almost 2 codebases 09.00.44 # same with charcell display 09.00.59 # the only changes for greyscale is the low level lcd drivers 09.01.09 # Imo we shouldn't ditch any target unless (1) we want to introduce a fundamental technical change which requires it (imo very unlikely, and even then branching would be better) or (2) the target is abandoned (no active dev has one anymore, and it's unlikely that one will show up again) 09.02.04 # * JdGordon would have thought that any "killing off" would really be forking anyway 09.02.04 # JdGordon: aren't there libraries required for things like color->gray conversion? 09.02.20 # but that'd be minor, I'd think. 09.02.36 # probably, but anything high up doesnt need to know about it 09.02.43 # amiconn: when I say "abandon" I really mean "branch" 09.02.56 # "draw a blue circle" is going to be the same for both 09.03.34 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 09.03.54 # and, for what it's worth, I don't think there's any feature rockbox doesn't have that I really want, other than perhaps better video support. 09.03.58 Part midgey 09.04.03 Join midgey [0] (n=tjross@rockbox/developer/midgey) 09.04.31 # JdGordon : And frankly it's "Draw a circle" 09.04.49 # I think an argument for branching is that hardly any of the new features added are useful on the archos targets so we could keep a branch around and backport fixes to it untill we reach amiconn's (2) 09.04.58 # JdGordon: Green, blue, blinking, all those things are attributes of circle. As long as the platform supports some kind of bitmap display ... 09.05.22 # * pixelma wonders when the last time was JdGordon had to take care of the hwcodec playback engine 09.05.27 # (god help me doing that on a char display ... imagine reprogramming the programmable chars to "draw" a circle. LOL) 09.05.36 # yeah yeah... the blue was to show that there is no different 09.06.07 # Martyn: we do that already... 09.06.11 # n1s: I disagree 09.06.18 # n1s: but branching makes it so that someone has to do the backport 09.06.28 # well, if the number of cells is <= the number of programmable characters, you can "do" graphics... though there will probably be some lines through it. 09.06.59 # from what I can tell, the color->grayscale conversion probably could use some tweaking, though. 09.07.29 # it's a bit on the dark side and seems to have some sort of weird flickering-style issue 09.07.45 # Branching means additional effort to keep things up to date. Keeping the archoses means we have a greater variety of targets regarding memory, colour depth, display size etc which help keeping code universal 09.08.52 # Besides, there are new lowmem targets in the works, so dropping the archoses because of lowmem won't be an advantage, rather the opposite 09.09.12 # *cough* If I may interject... 09.09.31 # Martyn: this is IRC...you wont be talking over anyone ;) 09.09.35 # lowmem targets are a question of not including certain amounts of code.. 09.09.41 # vector graphics on charcell display: http://download.rockbox.org/manual/rockbox-player/rockbox-buildch10.html#x13-13600010.2.2 09.10.23 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 09.10.24 Quit gevaerts (Nick collision from services.) 09.10.29 Join gevaerts_ [0] (n=fg@195-144-092-183.dyn.adsl.xs4all.be) 09.10.33 # Zagor : Heh, I did that on a watch for Fossil a couple years ago. Amazing what you can fit into a microcontroller + char display when you REALLY need to. 09.10.42 # Martyn: Not only. Lowmem means also thinking about how to implement a feature in a memory conserving way so that it can be included on lowmem targets 09.10.46 Quit J-23 (Read error: 104 (Connection reset by peer)) 09.11.10 # amiconn: i think the things people would like to crop them for in the code is charcell, buttonbar and the hwcodec engine basically, which can all be seen working nicely now but constantly needing to be taken care of when changes are done in areas that affect them 09.11.19 # s/crop/drop/ 09.12.21 # amiconn : Sure, but then it's usually easier to have #ifdef statements sitting in the code to branch the compilation one way for lowmem, and another for other targets. 09.12.32 # Since a lowmem target is likely going to trade speed for code size 09.12.51 Join J-23 [0] (n=kvirc@a105.net128.okay.pl) 09.12.57 # amiconn: actually the only thing unique to archos is the hwcodec and very low resolution. neither of which is likely to return in new target. 09.13.14 # (reading the cube demo code now .. it's actually pretty code) 09.13.28 # how much more resolution is there on the Clip? 09.13.45 # is the clip the one with the tiny OLED display? 09.13.47 # ameyer: flickering? i don't see how color->greyscale can "flicker", the values are calculated once 09.13.59 # Martyn: yes 09.14.12 # and the m200 09.14.21 # pixelma: only a little more: 128x64 vs 112x64 09.14.24 # Zagor: Huh? The clip has almost the same resolution... 09.14.42 # Zagor: really? ;) 09.14.42 # Unhelpful : Often 'greyscale' on an otherwise monochrome display is a question of the display controller changing the duty cycle on a pixel 09.15.03 # Unhelpful : The human eye then "sees" it as a greylevel, but it's actually 'flickering' 09.15.04 # amiconn: exactly, which means the archoses are in no way contributing "uniqueness" 09.15.18 # Zagor: Pixel aspect... 09.15.32 # Martyn: we have a library for doing that in plugins, for ~7-8bit "greyscale", but i don't know if any of the 2-bit greyscale targets are doing it in hardware 09.15.34 # amiconn: haha 09.15.43 # and if they are, it's not resolvable on our end, probably. 09.16.01 # also, i'm working on color->grey quality ;P 09.16.04 # And they're contributing a different cpu architecture 09.16.18 # Unhelpful : Very likely not. The Sharp 128x64 monochrome display only has 1 black and 4 'grey' levels 09.16.43 # Unhelpful : Which is good for text display (you can kind of antialias text on it) .. but horrid for just about anything else 09.19.24 # Unhelpful: it's not really "flicker" It's hard to accurately explain 09.19.40 # AFAIU the greyscale library is fully software even on greyscale targets which provide 4 levels of "grey" (including white and black) but those "native" greys are used for most things, except jpg viewer, mpegplayer (plugins that use the greylib) 09.20.03 # we're using bayer dithering to deal with reducing 256 levels -> 4 levels, in the "native" 2bit case 09.20.09 # it's kinda like what happens when you point a video camera at a CRT display, although there's more to it than that. 09.20.23 # Zagor: Oh, and I forgot another thing they contribute: a slow CPU, so they help in checking the efficiency of e.g. gui stuff 09.20.33 # anyone with a v1 sansa who feels like trying some builds? /me left my players at home 09.20.44 # ameyer: I guess you saw it on a Mini? 09.20.49 # Zagor: Sure. I've got one. 09.20.59 # Although it's the 250R 09.21.06 # amiconn: we can call it the "amiconn" branch ;-) 09.21.08 # But I've already got the bootloader working... 09.21.10 # pixelma: indeed 09.21.47 # pixelma: what's so special about the mini in this case? 09.22.27 # Zagor : Which build? 09.22.30 # (FWIW, the only grayscale targets I have are the mini and the clip. I won't be watching anything on the clip any time soon.) 09.22.32 # Martyn: On the mini it's indeed a bit flickery, for 2 reasons: The lcd is rather fast, and its "natural" gamma curve is bent the wrong way 'round, so that the greylib has to do quite a bit of correction 09.22.50 # well, it looks differently depending on the actual display, Mini is the worst I've seen 09.23.01 # ^ ameyer 09.23.10 # Martyn: a lowmem build, to see if that causes similar bugs as on clip. hang on a minute 09.23.56 # wait, we're having this "flickery" look only in greylib stuff? 09.24.05 # On iriver H1x0 it works best across all mono/grey targets I own: slow panel, and less gamma correction 09.24.20 Quit martian67 (Remote closed the connection) 09.24.53 # the darkness issue might have to do with having to jack the mini's contrast way up to have a usable screen 09.25.07 # Unhelpful: jpegviewer and mpegplayer. 09.25.31 # mandelbrot too 09.25.43 # and plasma 09.25.56 # and I think the cube 09.26.01 # ameyer: i believe you're basically seeing greylib at work, then. 09.26.04 Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) 09.26.45 # pixelma: (reply for a while ago) my motives for forking hwcodec is gui based.. i was just using the playback engine as an example of why they should be (gui based as in the buttonbar and the charcell) 09.27.05 # and on that note, /me is off... have a good w/e all 09.27.09 Nick JdGordon is now known as JdGordon|afk (n=jonno@rockbox/developer/JdGordon) 09.27.25 # then... "good" example 09.27.27 Join krazykit` [0] (n=kkit@69.219.233.220) 09.28.30 # Martyn: http://bjorn.haxx.se/testing/e200lowmem.zip 09.29.00 # downloading and installing 09.29.13 # What's the bug you're looking for? 09.29.14 # Unhelpful and/or pixelma: what exactly causes the flicker? Is the CPU too slow or something? 09.29.40 # Martyn: failure/crashing while playing mp3 09.30.04 # ameyer: cube uses it on mono targets only, and native greys on 2bpp targets. fire also uses the greylib, as well as doom 09.30.06 # I still think buffering is screwy on the clip 09.30.08 # should it matter at all that this a Rhapsody model? 09.30.12 # (It's still a V1) 09.30.15 # ah yes, doom 09.30.17 Quit krazykit (Read error: 60 (Operation timed out)) 09.30.22 # Martyn: afaik no 09.30.29 # I'm not 100% sure about the cube. 09.30.32 # ameyer: the flickering is delibrate, it's how we get more than 4 levels on greyscale targets at all, by changing the display contents back and forth between different values 09.30.40 # allright, backing up my .rockbox 09.30.45 # Martyn: not at all...they are essentially the same 09.30.52 # that's how the greylib works - it's cheating the eye by quickly turning the pixel black and white. If you have a fast display you'll see that 09.31.03 # ameyer: As I said, native greys on 2bpp, greylib on mono targets. Cube needs black, white and 2 greys 09.31.07 # nah, cube's a bit blurry 09.31.43 # Unhelpful: that doesn't really explain the "video camera pointed at a CRT" issue 09.32.07 # pixelma: It's not only how the greylib works, but also how the 2bpp lcds produce their native greylevels (internally) 09.32.25 # Installed and rebooting 09.32.27 Join krazykit [0] (n=kkit@adsl-69-219-233-220.dsl.ipltin.sbcglobal.net) 09.33.19 # r14980M, corrent? 09.33.32 # r19480M rather 09.33.59 # yup 09.34.23 # ameyer: do you also mean a row (or a bit wider) of distortion that sometimes moves up or down through the pictures? 09.34.50 # Martyn: could you check the buffer size under System -> Rockbox info ? 09.35.01 # crashed 09.35.01 # that's probably due to greylib's display switches happening while the LCD refreshes, i would think? 09.35.28 # Martyn: how? 09.35.39 # Buffer : 0Kb 09.35.41 # seems quite a bit wider. It's almost like it's got white pixels that shouldn't be there. 09.35.46 # ! 09.35.57 # I'd guess... 10 rows? 09.35.58 # Unhelpful: I can't remember the technical details but yes it has to do with the LCD refresh rate and can't be compensated for 09.36.13 # Yep, Buffer = 0KB 09.36.35 # yes, that will likely cause problems 09.36.41 # Zagor, I also don't see any DB .. files yes, but the usual "album/playlist/etc" is missing 09.36.45 # ameyer: yeah, that's what I mean, just couldn't explain it better... 09.37.06 Quit planetbeing (Read error: 104 (Connection reset by peer)) 09.37.17 # Martyn: yes I disabled db in this build. it won't fit without more tweaks. 09.37.20 # Battery: 7% 09.37.36 # Int: 395MB/1.84GB 09.37.53 # MSD: 7.41GB/7.41GB 09.37.59 # Buffer: 0KB 09.38.04 # Album Art: No 09.38.14 # Version: r19480M-081219 09.38.33 # ameyer: this effect is more or less visible, even depending on temperature. Sometimes it's almost not noticeable for me 09.38.46 # Zagor : Trying to play any MP3 file crashes 09.38.50 # ah, the pcm buf is allocated from audiobuf isn't it? 09.38.56 # Zagor : HARD crash ... screen fades away 09.39.03 # Zagor: think so yes 09.39.22 # I had to do the "two fingered reboot of death" (with the hold switch slide) to get it back 09.39.24 # * pixelma wonders whether we could drop the "Album Art" line in the info screen, now that resizing is in 09.39.43 # * n1s was just wondering the same 09.39.44 # <-- will now restore his favorite players original .rockbox 09.39.49 # Martyn: yeah, thanks. I have to free up some more memory. 09.40.09 # Oh, question... 09.40.12 # pixelma: seems sensible. also, cleaning out the search-by-size stuff probably is, as well 09.40.32 # On the current 3.0 build, why does the Sansa have to boot BACK into the original firmware to do USB sync? 09.40.59 # there was some debate as to whether we might want to let WPS load a "customized" AA via that mechanism, but i think that if we do that, it should be via a string in the tag, and not sizes. 09.41.02 # Unhelpful: you mean when searching for the bmp? 09.41.08 # I noticed that sometimes, If I unexpectedly plug/unplug the USB cable I can see a rockbox USB image .. but then the whole thing is frozen 09.41.31 # pixelma: yes, it still looks for cover.WxH.bmp 09.41.38 # Martyn: usb is software-based and our usb stack isn't stable yet 09.41.59 # Ahh... 09.42.13 # So you simply call into the original firmware instead 09.42.17 # Martyn: that's a known bug that in some builds the automatic reboot into the originl firmware doesn't work properly 09.43.25 # I noticed .. it's interesing that when the usb cable is unplugged, it reboots :) 09.43.53 # Okay, back to r19469 09.44.03 # buffer = 28Mb :) 09.44.07 # :) 09.44.47 # now, all I want for Xmas is a Sansa that can -charge- play music at the same time. LOL 09.44.54 Quit krazykit` (Read error: 110 (Connection timed out)) 09.46.45 # ever tried to hold Select while plugging and Rockbox is running? 09.47.00 Join Bger [0] (n=Bager@78.90.78.107) 09.47.03 Quit Bger (Remote closed the connection) 09.48.03 # not sure how well it charges though 09.48.14 Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) 09.48.15 # Unhelpful: I could imagine that someone wants different sized albumart (maybe with different aspect ratio, combining back and front cover etc.) for different WPS, or trusts a PC app more to do the resizing 09.49.22 # pixelma : Nice trick, thanks :) 09.49.26 # pixelma : Charging :) 09.49.26 # for aspect ratios, like i said, extend the %Cl tag to have a string label for the AA, and try to load cover.