--- Log for 05.07.112 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 20 days and 0 hours ago 00.01.00 Quit aevin (Ping timeout: 246 seconds) 00.02.13 Join mystica555 [0] (~Mike@70-58-26-12.hlrn.qwest.net) 00.05.33 Quit prof_wolfff (Ping timeout: 246 seconds) 00.06.19 Quit mystica555 (Read error: Connection reset by peer) 00.26.16 Quit bipton (Quit: CGI:IRC (EOF)) 00.28.30 Join Scromple [0] (~Simon@119.225.209.134) 00.41.55 Quit Wardo (Quit: Blarglarg) 00.47.39 Quit domonoky (Read error: Connection reset by peer) 01.02.06 Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 01.02.58 Quit mgottschlag (Ping timeout: 244 seconds) 01.06.04 Quit fs-bluebot (Ping timeout: 264 seconds) 01.09.53 Join fs-bluebot [0] (~fs-bluebo@g224237137.adsl.alicedsl.de) 01.18.20 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 01.23.13 Quit nathris2 (Ping timeout: 265 seconds) 01.26.43 *** Saving seen data "./dancer.seen" 01.36.31 Join Thra11_ [0] (~thrall@84.93.161.58) 01.36.55 Join pacovila [0] (~fravd@193.pool85-59-107.dynamic.orange.es) 01.37.18 Quit Thra11 (Ping timeout: 246 seconds) 01.38.04 Part pacovila 01.39.05 Quit Rower85 (Quit: Hmmm...) 01.41.28 Quit pamaury (Remote host closed the connection) 01.53.01 Quit liar (Ping timeout: 245 seconds) 01.53.24 # <[Saint]> What does my client need to advertise to say it can complete a manual build? 01.53.30 # <[Saint]> (I've tested, and, it can) 01.53.56 # <[Saint]> I notice its not included in -archlist...so 02.05.15 Quit ender^ (Ping timeout: 272 seconds) 02.05.38 # ? 02.05.45 # you need to specify all the compilers you have 02.08.13 # <[Saint]> apparently not. 02.08.25 # <[Saint]> logs may have answered me, though: " What should a build client advertise to do manual? latex?" 02.08.41 # <[Saint]> " AlexP: yes. That might change though" 02.09.03 # oh woops, didnt read "manual" 02.09.16 # <[Saint]> creepy similarity between AlexP's wirding and mine is creepy. 02.09.24 # <[Saint]> *wording too 02.11.13 Quit Xerion (Quit: ) 02.22.47 Join ender| [0] (krneki@foo.eternallybored.org) 02.33.42 Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 02.33.48 Quit tchan (Changing host) 02.33.48 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 02.47.35 Quit BHSPitMonkey (Read error: Connection reset by peer) 02.59.55 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 03.11.41 # <[Saint]> JdGordon: the only testing I managed to give 284 (how are we 'sposed to format that so the bot picks it up?) before I fell asleep was making sure everything "just worked" if I turned it off for all the bars my skin was using and specifying touch areas manually still worked. 03.12.24 # thats pretty much it 03.12.31 # did you like the padding that got added? 03.12.35 # That might need some tweaking 03.12.45 # and g#284 is how you get the bot to pick it up 03.12.47 # 3Gerrit review #284 at http://gerrit.rockbox.org/r/284 : skin_engine: Automatically create touch regions for skin bars by Jonathan Gordon (changes/84/284/5) 03.15.09 # <[Saint]> I like the fact that there's a padding added, but I can imagine it might be non-obvious. 03.16.55 Quit anewuser (Read error: Connection reset by peer) 03.17.05 # <[Saint]> And, as I said last night, I say so without understanding the implementation...but I'm not a fan of the default to 'touch' and having to pass 'notouch' as a param if its not wanted. 03.17.37 # <[Saint]> purely because I don't think its a nice default, nothing at all code related. 03.18.15 # <[Saint]> It doesn't really bother me an ounce either way to be honest, but its my "ideal world" scenario :) 03.18.33 # yeah, im gonna just disgaree there 03.19.11 # Commit d336eb3 in rockbox by 03Jonathan Gordon: skin_engine: Automatically create touch regions for skin bars 03.19.25 Join anewuser [0] (~anewuser@186.93.234.141) 03.19.25 Quit anewuser (Changing host) 03.19.25 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 03.19.35 # having it on by default means it will always "just work" 03.21.46 # d336eb3 build result: 0 errors, 6 warnings (Jonathan Gordon committed) 03.24.15 # Commit c413591 in rockbox by 03Jonathan Gordon: fix build warnings 03.26.06 Quit Thra11_ (Ping timeout: 246 seconds) 03.26.45 *** Saving seen data "./dancer.seen" 03.26.52 # c413591 build result: All green 04.03.13 Join TheSphinX^ [0] (~briehl@p5B321857.dip.t-dialin.net) 04.06.05 # <[Saint]> Frankly, I don't think thats important at all. 04.06.18 # <[Saint]> The author needs to make that descision. They need to allow for it. 04.06.22 Quit TheSphinX_ (Ping timeout: 240 seconds) 04.07.30 # <[Saint]> If the docs clearly say "weird shit you might not expect could possibly happen with the touch areas, as although you can specify them manually, ...don't, because unless you turn it off they'll be created for you" then all is well and good. 04.07.42 # <[Saint]> I just don't think defaulting on is very nice. 04.09.01 Quit MethoS- (Ping timeout: 265 seconds) 04.09.03 # <[Saint]> Its *great* that the skin engine can do this, but, I think it should be a choice the author makes as opposed to just trying to make it "just work" with existing themes. 04.09.17 Join mystica555 [0] (~Mike@70-58-24-46.hlrn.qwest.net) 04.11.33 # * JdGordon had an insnae idea last night 04.11.46 # allow the bar tag to show setting values generically 04.11.53 # (unless we already can do that?) 04.12.10 # if that is possible you could then implement the graphical EQ in the skin engine entirely! 04.14.00 # <[Saint]> "(unless we already can do that?)" <-- nup, not that I know of. 04.14.53 # doing a bar for the repeat mode might be look a bit stupid :) 04.14.59 # but i dont see why it shouldnt work 04.15.05 Quit mystica555 (Ping timeout: 264 seconds) 04.17.09 Join mystica555 [0] (~Mike@70-58-24-46.hlrn.qwest.net) 04.18.55 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.18.56 Quit amiconn (Disconnected by services) 04.18.59 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.19.46 Quit pixelma (Disconnected by services) 04.19.47 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.19.49 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.23.05 Quit mystica555 (Read error: Operation timed out) 04.51.49 Join kevku [0] (x@heaaqi4aafadxhbmjetojeoiftm.dyn.reverse.name) 04.57.18 Quit TheSeven (Disconnected by services) 04.57.28 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.02.48 # <[Saint]> Can someone help me to understand why I keep seeing: "Uploading foo";" ; "No upload" in my client's build log? 05.03.35 # <[Saint]> I assume that means the upload started, but another client beat me to it? 05.06.13 # possibly 05.06.27 # or you did bootloader builds which dont need an upload 05.06.41 # <[Saint]> a bunch of WPSes it seems. 05.06.50 # ok 05.07.31 # <[Saint]> If they didn't need to be uploaded, I assumed the curl magic wouldn't be there...or am I giving the script too much credit? 05.21.13 Join soap [0] (~soap@cpe-76-181-67-213.columbus.res.rr.com) 05.21.14 Quit soap (Changing host) 05.21.14 Join soap [0] (~soap@rockbox/staff/soap) 05.26.49 *** Saving seen data "./dancer.seen" 05.34.01 Quit tchan (Quit: WeeChat 0.3.7) 05.40.56 Join rockdoom [0] (~32714c74@www.haxx.se) 05.42.18 # Hi. Doom runs really really fast on my MP3 player and it's basically unplayable. Is there a way to fix it? 05.43.44 Join tchan [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 05.43.44 Quit tchan (Changing host) 05.43.44 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 05.49.31 Quit rockdoom (Quit: CGI:IRC (EOF)) 05.58.02 Quit tchan (Quit: WeeChat 0.3.7) 05.58.33 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 06.22.33 Join Thra11 [0] (~thrall@87.112.231.26) 06.27.21 Quit anewuser (Read error: Connection reset by peer) 06.46.49 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 06.54.19 Join nathris [0] (~nathris@S0106602ad08244eb.gv.shawcable.net) 06.54.20 Part nathris 06.56.44 Quit soap (Quit: soap) 06.58.53 Quit [Saint_] (Ping timeout: 264 seconds) 07.02.56 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 07.06.47 Quit T44 (Ping timeout: 245 seconds) 07.10.38 Quit [Saint_] (Remote host closed the connection) 07.12.28 # * [Saint] has a horrible thought... 07.13.23 # <[Saint]> Just because I (foolishly? ;)) started this cabbie-touch stuff, does that mean I have to kludge it into the vuild system too? 07.13.32 # <[Saint]> *build, even. 07.26.13 Join Topy44 [0] (~Topy44@f048198133.adsl.alicedsl.de) 07.26.50 *** Saving seen data "./dancer.seen" 07.27.42 Quit factor (Read error: Connection reset by peer) 07.45.34 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 08.07.00 Quit tchan (Quit: WeeChat 0.3.8) 08.15.37 Join tchan [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 08.15.41 Quit tchan (Changing host) 08.15.41 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 08.17.51 Join jlbiasini [0] (~metaphys@lns-bzn-26-82-254-122-10.adsl.proxad.net) 08.18.51 Part jlbiasini 08.34.23 Join ender` [0] (krneki@foo.eternallybored.org) 08.35.51 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 08.36.12 Quit mshathlonxp (Ping timeout: 252 seconds) 08.39.08 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.16.36 Join pacovila [0] (~fravd@193.pool85-59-107.dynamic.orange.es) 09.20.03 Join polemon [0] (mcp@polemon.org) 09.20.26 # how do you guys actually taylor Rockbox to the chipsets of so many devices? 09.20.31 # are they that similar? 09.24.02 # lots of hard work 09.24.08 # by many people 09.24.14 # over a long period of time 09.25.08 Join mgottschlag [0] (~quassel@HSI-KBW-091-089-250-086.hsi2.kabel-badenwuerttemberg.de) 09.25.08 Quit mgottschlag (Changing host) 09.25.08 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 09.26.52 *** Saving seen data "./dancer.seen" 09.31.48 Join petur [0] (~petur@rockbox/developer/petur) 09.32.04 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 09.32.05 Quit pamaury (Changing host) 09.32.05 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.35.56 # <[Saint]> polemon: some targets share hardware, or have similar (slightly older/newer, etc.) hardware, which makes things easier. But generally speaking pretty much everything needs to be reverse engineered. 09.38.33 # <[Saint]> Sometimes you might get lucky and find a datasheet for the component(s), but even then it may not be complete (undocumented registers, for example). 09.42.37 Quit pacovila (Remote host closed the connection) 09.56.57 Quit mgottschlag (Read error: Operation timed out) 10.18.59 Quit Scromple (Read error: Connection reset by peer) 10.19.48 Quit pamaury (Ping timeout: 246 seconds) 10.48.04 Join jlbiasini [0] (~metaphys@lns-bzn-26-82-254-122-10.adsl.proxad.net) 10.48.09 Part jlbiasini 10.49.01 Join mgottschlag [0] (~quassel@2a00:1398:200:200:8439:f60b:5fdd:fb96) 10.49.01 Quit mgottschlag (Changing host) 10.49.01 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 11.03.22 # * [Saint] considers editing runclient.sh to be a bit smarter 11.04.16 # In what way? 11.04.47 # <[Saint]> by way of having the archlist blank by default, and offering a menu (similar to the toolchain compilation prompt) allowing you to specify the arch(s) you want to broadcast support for. 11.05.00 Join Tanguy [0] (~tanguy@2a01:e34:ee8f:150:208:9bff:febe:e3d3) 11.05.21 # * gevaerts wonders why this would be better 11.06.11 # <[Saint]> easier is better, isn't it? I mean, sure, its essentially a one-time thing but I just thought it would be nice to do it this way. 11.06.53 # You mean we'd have to add another script to run runclient.sh? 11.06.59 # How is that easier? 11.08.16 # <[Saint]> Why would it need to be another script? It could just perform the checks itself could it not? 11.08.34 # * gevaerts is confused 11.08.38 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 11.11.06 # I guess I have no idea what you're proposing 11.11.47 Quit tmzt_ (Ping timeout: 248 seconds) 11.14.58 # <[Saint]> I was just thinking on the first run of runclient.sh a menu similar to rockboxdev.sh would be nice, showing a list of arch its possible to broadcast support for and the character(s) you should type in a space separated list to edit the arch list so you don't have to. Then enter the client name, your name, etc. 11.15.39 # <[Saint]> More work for essentially little gain, but its something I could potter on that I thought might be nice. 11.16.45 # You'd essentially have to move to a separate config file then 11.17.01 # I'm not convinced it's worth the effort 11.20.37 # Hello. 11.21.08 # I am looking for a player model to buy, preferably to run Rockbox on it. :-) 11.22.48 # The Sandisk Sansa Clip Zip has two qualities I would be interested in: standard micro-USB, micro-SD card reader. But it is tiny, which is not something I am specifically looking for. 11.24.28 # Do you know if there is another /current/ model that I should consider? Imperatively with micro-USB or possibly mini-USB (I shall not buy anything with a poprietary cable), and preferably with an SD or micro-SD reader. 11.26.22 Join pamaury [0] (~quassel@sphinx.lix.polytechnique.fr) 11.26.22 Quit pamaury (Changing host) 11.26.22 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.26.56 *** Saving seen data "./dancer.seen" 11.28.41 # mgottschlag: ping 11.28.49 # pong? 11.28.59 Quit einhirn (Ping timeout: 250 seconds) 11.29.45 # yeah, I forgot to tell you something very important about the stmp3710: it is not the same as the imx233, the registers are differents in some places 11.30.39 # I'm doing a port for a stmp3760 based player (which is basically the same as the stmp3710) so you might want to wait a bit before trying to reuse our code 11.31.14 # " yeah, I forgot to tell you something very important about the stmp3710: it is not the same as the imx233, the registers are differents in some places" - I already thought so, some register writes/reads simply didn't make sense, thanks for the notice :) 11.31.43 # you can use this: http://amaury.pouly.free.fr/Images/stmp37xx.pdf 11.32.11 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.32.13 # it's a pdf I generated containing the register list of both chips and the differences. I'm in a process of producing a better one but it's already a good start 11.33.50 Join tmzt [0] (~tmzt@76.244.156.141) 11.33.57 # and if you are interested, I can send you some code which can run on the stmp37xx which allows to poke at random registers/memory via usb 11.40.05 # *that* indeed would be awesome 11.40.38 # ok, I need to leave right now, be back in one hour, I'll publish on my repo the stuff so you can use it 11.56.39 # <[Saint]> so, sorry...what is it I add to my client(s) archlist(s) to advertise support for building manuals? 11.56.41 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 11.56.55 # <[Saint]> I have checked, and I can indeed build the manuals. 11.57.57 # <[Saint]> I think I found it answered in the logs earlier, but it wasn't actually confirmed so I'm sot sure. 12.05.27 # <[Saint]> "android15,arm-eabi-gcc444,arm-ypr0-gcc446,latex,mipsel,m68k-gcc452,sdl,sh", that's all of 'em, yes? 12.06.13 # rbclient.pl has the list 12.06.59 # <[Saint]> right, but the entry for the manuals isn't included it doesn't seem. 12.07.13 # sure it is 12.07.18 # <[Saint]> as? 12.07.50 # latex 12.08.04 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 12.08.13 # <[Saint]> right, that's not in there when you download it initially. 12.08.46 # It is 12.10.06 # <[Saint]> No, its not. 12.10.19 # It is 12.10.41 # <[Saint]> I had to add it, it just so happened I found AlexP asking the same question this morning (my time) 12.11.03 # * gevaerts thinks he sees where the confusion comes from 12.11.04 # <[Saint]> I just re-downloaded it to be sure, and "latex" is *not* in the archlist. 12.11.08 # 12:06:14 rbclient.pl has the list 12.11.15 # runclient.sh doesn't, no 12.11.28 # <[Saint]> Ahhhhhh....shit, sorry man. 12.12.07 # <[Saint]> I did in fact see "12:06:14 rbclient.pl has the list" as well, but my mind replaced it with runclient.sh 12.13.12 # <[Saint]> Sorry, uuugh. That felt like ramming my head against a wall :) "I can *seeeeee* its not there, dammit! Don't tell me it is!.....ohh..ok, whoops..." 12.14.55 Join T44 [0] (~Topy44@f048204092.adsl.alicedsl.de) 12.15.26 # * evilnick hands [Saint] some glasses 12.16.35 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 12.19.17 Quit Topy44 (Ping timeout: 264 seconds) 12.23.45 # gevaerts: what "intresting" things can you tihnk of with making a bar capable of showing setting? 12.24.40 # JdGordon: that depends. I'd say your repeat mode example would actually be nice, *if* there's a way to put proper labels next to it 12.25.14 # repeat mode makes absolutly no sense :) 12.25.23 # i shold probably work on auto rtl-ing though 12.25.27 # something thats actually usefu;l 12.25.43 # Sure it does. You could make it like one of those selector sliders 12.25.58 # I'm not sure what to call them, really 12.26.06 # ? 12.26.40 # oh, if you're tihnking what im thinking then a couple of bitmaps would be a better way to do that specific example :) 12.27.03 # You can't slide bitmaps! 12.36.16 # JdGordon: I'll agree that most people use rotary selector switches or a row of pushbuttons for this, but there are some sliding ones, and I don't think those are easy to do in the skin engine right now (neither are the rotary ones of course) 12.48.45 # did my patch to allow the shortcuts menu to be the quickscreen ever get merged? 12.49.18 # ah yes, /me can nuke that git branch 13.00.06 Join anewuser [0] (~anewuser@186.93.234.141) 13.00.06 Quit anewuser (Changing host) 13.00.06 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 13.06.40 # have you guys ever thought of porting RockBox to one of those portable DVD player? 13.06.53 # s/r\?/rs?/ 13.06.59 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 13.09.48 # polemon: Ports happen by those with the hardware who want to spend a lot of time working out all the problems, but to the best of my knowledge that hasn't been attempted 13.10.18 # a friend of mine got one of those things 13.10.23 # they're actually pretty awful 13.10.40 # I can well believe that :) 13.10.41 # no HDMI, MP3, WMA, and WAV, as for audio 13.11.01 # very few codecs 13.11.20 # it has only composite out, and only stereo audio 13.11.36 # pretty horrible OSD, too 13.16.21 # Well, the code is open source, but I'm not sure that there's a lot of crossover between Rockbox and a portable DVD player 13.17.31 # I believe there is... 13.17.49 # I mean, the audio formats alone 13.17.57 # plus playing videos 13.20.44 # This might help: http://www.rockbox.org/wiki/NewPort 13.21.46 # "The Rockbox developers can and will try to help out with development, advice, hints and other general things, but only as much as they can and if they have the time." is one of the most important parts 13.24.45 # yeah, well, it's not like I want to, since I don't even have that kind of player 13.25.02 # I was just wondering, if people were discussing that already 13.25.21 # polemon: you're aware that rockbox *only* supports mpeg1 and mpeg2 for video? 13.25.36 # yeah, I know 13.25.43 # I use Rockbox on my iPod Nano 13.26.57 *** Saving seen data "./dancer.seen" 13.30.15 # whats the trick to make gdb not barf on the USR1 signals? 13.31.56 # handle USR1 pass IIRC 13.32.03 # Or just configure --sdl-threads :) 13.33.21 Quit petur (Ping timeout: 246 seconds) 13.34.26 # what file does that go in? 13.34.51 # That's a gdb command 13.35.09 # yeah, it can go in a gdb load script 13.35.09 # but i dont r 13.35.12 # emember the filename 13.35.31 # No idea 13.37.51 # handle SIGUSR1 nostop in ~/.gdbinit 13.38.20 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 13.52.23 Join petur [0] (~petur@rockbox/developer/petur) 13.57.07 Quit einhirn (Ping timeout: 246 seconds) 14.01.53 Quit petur (Remote host closed the connection) 14.02.07 # c413591 was nicely catched by the build system. very useful 14.12.36 Quit factor (Quit: Leaving) 14.20.55 Quit evilnick (Quit: Leaving) 14.22.32 Join MethoS- [0] (~clemens@134.102.106.250) 14.43.27 # gevaerts: I got the setting bar working, you want to test it, or should i just commit it? 14.47.10 # Commit 4c94b98 in rockbox by 03Jonathan Gordon: skin_engine: Fix a obscure parser bug 14.49.29 # 4c94b98 build result: All green 14.56.29 # fast_readline() has an annoying bug 14.56.39 # it doesnt handle \r very well... or at all even 15.00.31 Join mortalis [0] (~mortalis@176.60.137.174) 15.01.24 # does osx use \r for new lines? 15.02.12 # wikipedia says no 15.02.58 # Commit f6d6a46 in rockbox by 03Jonathan Gordon: Fix fast_readline to handle windows line endings (\r\n) 15.03.37 Quit Torne (Quit: moving to a new shell) 15.04.33 # JdGordon: feel free to commit (as far as I'm concerned anyway). I want to test it, but I'm not in a hurry and I don't know when that will happen... 15.05.01 # f6d6a46 build result: 3 errors, 0 warnings (Jonathan Gordon committed) 15.06.13 Join stoffel [0] (~quassel@pD9E43A4A.dip.t-dialin.net) 15.09.15 # * JdGordon *thought* he had it working :/ 15.12.02 # ... it helps to be on the right git branch :p 15.12.04 Quit mgottschlag (Ping timeout: 264 seconds) 15.13.50 # gevaerts: [Saint]: should I bother trying to reuse %St for the bar and normal type? or is it ok to use 2 different tags? 15.14.02 # using the one works but might be a bit more error prone 15.15.00 Join mgottschlag [0] (~quassel@2a00:1398:200:200:58da:8332:954e:77dd) 15.15.01 Quit mgottschlag (Changing host) 15.15.01 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 15.15.34 # JdGordon: shouldn't the \r check come before \n? 15.18.52 # no, because the \n check \0's it and sets the next to after, then leaving the \r as the last char which can be safely \0'ed 15.19.00 # it probably coiuld go first but this works 15.19.23 # this also works with \r as the only EOL char (which apparently only os9 does) 15.21.25 Join soap [0] (~soap@cpe-76-181-67-213.columbus.res.rr.com) 15.21.25 Quit soap (Changing host) 15.21.25 Join soap [0] (~soap@rockbox/staff/soap) 15.26.59 *** Saving seen data "./dancer.seen" 15.30.07 Quit mortalis (Ping timeout: 245 seconds) 15.30.13 Join Torne [0] (~torne@rockbox/developer/Torne) 15.30.29 # Commit 65f9df3 in rockbox by 03Jonathan Gordon: skin_engine: Allow the %St() (setting) skin tag be used as a bar 15.30.44 # * JdGordon hopes someone has some fun with that ^ 15.32.45 # 65f9df3 build result: All green 15.34.16 Quit mgottschlag (Ping timeout: 264 seconds) 15.38.03 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.43.31 Quit stoffel (Remote host closed the connection) 15.51.25 Join mgottschlag [0] (~quassel@2a00:1398:200:200:6df5:e407:2d4c:51e) 15.51.26 Quit mgottschlag (Changing host) 15.51.26 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 15.58.00 Quit GeekShadow (Remote host closed the connection) 15.58.15 Join GeekShadow [0] (~antoine@83.117.197.77.rev.sfr.net) 15.59.28 Quit mgottschlag (Ping timeout: 264 seconds) 16.01.41 # JdGordon: if the first line is \r\n then the \r will missed, no? 16.02.12 # perhaps I'm reading it wrong 16.14.55 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 16.31.01 Part belak 16.31.16 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 16.34.12 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 16.46.41 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 16.47.45 Join mshathlonxp [0] (msh@84.237.140.236) 17.12.07 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.27.01 *** Saving seen data "./dancer.seen" 17.30.00 Join einhirn [0] (~Miranda@p4FC7450F.dip0.t-ipconnect.de) 17.34.06 Quit einhirn (Ping timeout: 240 seconds) 17.34.40 Join n1s [0] (~n1s@nl118-174-190.student.uu.se) 17.34.41 Quit n1s (Changing host) 17.34.41 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.36.09 Part amayer 17.49.44 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 17.49.57 Quit perrikwp_ (Ping timeout: 244 seconds) 17.51.10 Join amayer [0] (~amayer@mail.weberadvertising.com) 17.59.10 Join mgottschlag [0] (~quassel@HSI-KBW-091-089-250-086.hsi2.kabel-badenwuerttemberg.de) 17.59.11 Quit mgottschlag (Changing host) 17.59.11 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 18.07.26 Join megal0maniac [0] (~megal0man@196.213.53.210) 18.31.55 # mgottschlag: https://github.com/pamaury/rockbox-1/tree/creativezenxfi/utils/imxtools/hwemul 18.38.16 Quit mgottschlag (Disconnected by services) 18.43.19 Quit pamaury (Read error: Operation timed out) 18.51.59 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.52.37 Join lebellium [0] (~chatzilla@e179141233.adsl.alicedsl.de) 18.52.44 Join prof_wolfff [0] (~prof_wolf@82.159.1.234.dyn.user.ono.com) 19.02.19 Join andai [0] (~andai@82-171-107-230.ip.telfort.nl) 19.02.54 # Hello! When I plug my [rockbox enhanced] iPod into my solar USB charger, it switches to USB charging mode and doesn't let me listen to music. Can I make it not-do that? 19.03.17 # ( I remember the standard firmware let you charge it while playing, without switching into brick mode ) 19.04.31 Join WalkGood [0] (~4@unaffiliated/walkgood) 19.04.37 # andai: there is a way 19.04.49 # you can set it to Car Mode 19.05.06 # Mir: car adapter mode has *nothing* to do with that 19.05.22 # yes it does 19.05.29 # No it doesn't 19.05.44 # andai: You can hold a button to stop it charging, check the manual for which one 19.05.52 # if he selectws car mode it will allow him to listen to music when plugged into his solar charger 19.05.58 # Not necessary 19.06.08 # Mir: first of all there is no such thing as "car mode" 19.06.09 # Just hold the relevent button when attaching USB 19.06.22 # yes there is 19.06.27 # There is "car adapter mode", but that does entirely different things and has nothing to do with this 19.07.21 Join mortalis [0] (~mortalis@176.60.162.254) 19.07.21 # gevaerts: you need to read 19.07.23 # Hello! When I plug my [rockbox enhanced] iPod into my solar USB charger, it switches to USB charging mode and doesn't let me listen to music. Can I make it not-do that? 19.07.30 # that was the question 19.07.50 # yes, and you hold a button when inserting USB to stop that 19.08.28 # or you say yes to car adapter mode 19.08.31 # Mir: http://download.rockbox.org/daily/manual/rockbox-sansafuze/rockbox-buildch8.html#x11-1420008.5.4 19.08.35 # That is car adaptor mode 19.08.40 # yes 19.08.50 # i have several FUZEs and C240's 19.09.03 # and a E260 in front of me plugged into the wall 19.09.07 # And gevaerts and I are core Rockbox members 19.09.15 # With probably 30 targets between us 19.09.20 # i also have an ipod with the feature he is speaking about in stock firmware 19.09.47 # OF is irrelevent 19.10.14 # ok 19.10.20 # at least he has a choice 19.10.27 Quit mortalis (Remote host closed the connection) 19.10.39 # he/she/it 19.11.40 # all i know is that the car adapter mode alows me to play music while its charging on either a wall, car or my solar charger 19.12.03 # hence why i thought m y situation was the answer 19.12.48 # * Mir waves at gevaerts and AlexP and then lurks off to lunch 19.17.06 # AlexP: which button is the famous any button now IIRC (for a while already). Checking the manual doesn't hurt though 19.18.14 # Car adapter mode doesn't work on the iPod, does it? 19.18.32 # I see you can tell it not to charge while USB connected, but on a USB that *only* charges that wouldn't really solve my problem :D 19.20.00 # Actually, upon rephrasing my problem ( I need battery outside for about 12 hours ) on a sunny day ( hence USB charger ) I realized that my iPod's battery is excellent and lasts longer than that 19.20.42 Join mortalis [0] (~mortalis@176.60.162.254) 19.20.46 # but it would be nice to know for future reference 19.25.13 Quit bluebrother (Disconnected by services) 19.25.18 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.27.03 *** Saving seen data "./dancer.seen" 19.27.12 Quit fs-bluebot (Ping timeout: 246 seconds) 19.27.28 # Mir: please show me eitehr official documentation or code that supports your claim 19.28.09 # andai: I don't understand what you mean by "on a USB that *only* charges that wouldn't really solve my problem" 19.28.30 Join fs-bluebot [0] (~fs-bluebo@g231120159.adsl.alicedsl.de) 19.28.54 # gevaerts: on the car adapter mode it works on the Sansa models 19.29.19 # if someone has said "oh that doesnt work on the ipod" then i would have shut the fuck up 19.29.21 # Mir: please show me either official documentation or code that supports your claim 19.29.49 # Car adapter mode has *nothing* to do with USB or charging 19.30.02 # then what does it do 19.30.30 # AlexP linked you to the relevant part of the manualk 19.30.35 # car adpter mode is to allow for charging and playing through the car stereo at the same time 19.30.45 # No 19.30.58 # Please stop trying to deliberately mislead people *now* 19.31.43 # it doesnt work like that then on my E260 19.32.54 # Then you're either not observing correctly, or you're not running rockbox 19.32.59 # so i guess its broken on my mp3 players 19.33.13 # 3.11 19.33.36 Join PRETTY_FUNCTION [0] (~sigBART@123.252.214.223) 19.34.02 Quit Thra11 (Remote host closed the connection) 19.34.37 # i think the manual is miswritten then 19.34.49 # i will have to make a video to prove my point 19.34.57 # will do that when i get back from work 19.36.01 # so no i dont have any official support to my claim gevaerts 19.36.11 # Just in case, showing that it doesn't go to USB mode if you connect while in car adaper mode won't prove your point 19.36.24 Join Thra11 [0] (~thrall@87.112.231.26) 19.36.36 # what? 19.36.42 Quit Thra11 (Remote host closed the connection) 19.37.05 # showing that plugging into a car adapter and then playing music while it charges wont prove my point? 19.37.25 # If that would prove your point, you could just as well claim that it won't go to USB mode if the volume is not muted 19.37.27 # i am sorry gevaerts but you are confusing me pretty bad now 19.37.51 # huh? 19.38.00 # i never said anything about mute 19.38.16 Join Thra11 [0] (~thrall@87.112.231.26) 19.38.16 # That was an analogy. Please learn to read 19.38.39 Join saratoga [0] (~saratoga@wl-west2-pat.netcom.duke.edu) 19.39.00 # Car adapter mode doesn't change how charging works 19.39.10 # it still charges 19.39.20 # And if that's *still* not clear, you have to prove that car adapter mode makes a *difference* 19.39.23 # It just pauses music when you unplug 19.39.27 # but you dont get that USB HID thing in the way 19.39.37 # saratoga: thank you 19.39.46 # USB HID is a completely different setting 19.39.56 # Mir: nothing to do with what you are thinking 19.40.02 # If you don't want HID, you can disable that separately 19.40.03 # Mir: saratoga just disagreed with you... 19.40.13 # Oo 19.40.20 # wait 19.40.52 # * Mir gives up 19.41.02 # Mir: was there something about the manual that made you think it was related to USB ? If so we should fix that 19.41.08 # pixelma: thanks, didn't realise that 19.41.56 # car adapter mode allows one to charge and listen to music right? 19.42.02 # No 19.42.08 # am i incorrect on how that feature functions? 19.42.12 Quit liar (Ping timeout: 245 seconds) 19.42.18 # no? 19.42.34 # Like I said it just pauses music after charging 19.42.43 # you just said it pauses the track 19.42.43 # Nothing else 19.42.49 # and one can always unpause 19.42.56 # Sure 19.42.57 # right? 19.42.59 # ok 19.43.05 # It pauses for you 19.43.16 # And unpause begins with a U, so it must be related to USB? Is that your point? 19.43.28 # Saves you from having to turn off the player 19.43.29 # no 19.44.28 # If you don't mind turning off the player yourself it does nothing for you 19.44.35 # Make sense ? 19.45.08 # Basically its a way to turn off the player when a car turns off 19.45.50 # oh 19.46.12 # Does anyone have opinions about my new logging patch ? 19.46.16 # but this *has* to affect charging and usb! 19.46.20 # * bluebrother^ ducks and runs 19.46.34 # haha 19.47.01 # * Mir started playing something on his E260 and when he plugged it into the wall it did not pause or stop playing 19.47.09 # I want to have logging enabled on all swcodec targets 19.47.17 # Were you pressing a button? 19.47.21 # or go to the screen that says "CHARGING" 19.47.24 # nope 19.47.30 # You don't need to press a button 19.47.30 # no button was pressed 19.47.44 # Rockbox always charges 19.47.53 # saratoga: oh, did that change? 19.47.55 # Doing otherwise would be dumb 19.47.59 # For many years it has gone to USB 19.48.00 # Mir: was it Tuesday when you plugged it in? 19.48.08 # today 19.48.14 # well, there's also this charger detection thing ... 19.48.19 # ah right 19.48.23 # gevaerts: i am sorry if i have pissed you off 19.48.24 # If it goes to USB from a charger that's a broken USB driver 19.48.24 # In that case, it must be that it doesn't go to USB mode on Tuesdays 19.48.25 # I was assuming aUSB connection 19.48.29 # Not a wall charger 19.48.40 # So yeah 19.49.25 # if that solar charger makes Rockbox go into USB mode it can't detect the charger as charger. 19.49.38 # Anyway does anyone care what I call the logf and debugf replacement 19.49.50 # saratoga: looks like a nice idea to me 19.49.52 # bluebrother^: you have a point there 19.50.06 # bluebrother^: might be a nano2g. Charger detection isn't properly up to spec there yet 19.50.09 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 19.50.10 Quit pamaury (Changing host) 19.50.10 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 19.50.21 # Right now I just call it logdiskf 19.50.23 # maybe make that some kind of hidden option, so we can ask people to enable it on development builds in case of errors? 19.50.37 # Yeah that will happen 19.50.40 # gevaerts: sorry is i annoyed angered or pissed you off in anyway 19.50.59 # gevaerts: my mini2g doesn't detect my older Apple charger either. IIRC there was something newer chargers do to identify themselves as charger 19.51.05 # * Mir now goes to work 19.51.12 # I'm going to have a int argument that says what the message is 19.51.29 # Like error warning or debug 19.51.55 # Stock builds will compile only with error enabled 19.52.05 # bluebrother^: there are basically three different kinds of connection: a USB host, a thing that provides 5V on the power lines and has unconnected data lines, and a proper charger that has the data lines shorted 19.52.34 # saratoga: I like the idea (and the future plans), but I haven't looked properly at the implementation yet 19.52.46 # The implementation is crap 19.52.54 # But I'll improve it 19.53.07 # OK :) 19.53.23 # The hit should be very small from this 19.53.25 # saratoga: an alternative approach is to have a number first in the string, as then basically all existing invokes can get the default 19.53.38 # like "[1] moo" 19.53.47 # Couple KB at most 19.54.04 # And parse the string to get the level ? 19.54.09 # iirc, the linux kernel does something like that 19.54.13 # I'd say we should use buflib for the buffer, so we can increase it at runtime if we need that 19.54.14 # right 19.54.24 # I was just going to do some preprocessor magic 19.54.38 # Bagder: that means we can't let the compiler throw away debug output 19.54.38 Quit WalkGood (Quit: ♪ ♫ ♪ ♫ ♪ ♫ ♪) 19.54.46 # saratoga: right, that is probably better 19.54.58 # yeah, bad idea 19.55.05 # I want to avoid compiling debug info 19.55.18 # * Bagder says no more 19.55.19 # Since it may waste a lot of space 19.55.41 # But yes if people have ideas please tell me 19.55.57 # Ideally you will all be forced to use this thing 19.56.11 # I think the level selection we discussed a few days ago is fine 19.56.44 # Right now the system is built into logf which is kind of ugly 19.57.05 # But I want to get rid of logf 19.57.40 # If we want to fully replace logf with this, a bit of preprocessor magic can help with rstricting the lower levels to particular files 19.57.55 # (and yes, I think having a single system is good) 19.58.50 # gevaerts: What I meant was, I found an option to make it NOT charge the battery when you connect it by USB... if you're connecting it to a laptop with limited battery, for example 19.59.17 Quit saratoga (Read error: Connection reset by peer) 19.59.31 # gevaerts: considering my device can ONLY charge it ( it is basically a brick with a solar panel and Li-ion battery glued to it ) that wouldn't help me :D 19.59.33 Join saratoga [0] (~saratoga@wl-west2-pat.netcom.duke.edu) 19.59.40 # andai: ah, ok. That's unrelated. 19.59.50 Join saratoga__ [0] (980329b4@gateway/web/freenode/ip.152.3.41.180) 20.00.12 # gevaerts: Yeah, but I meant it's the most relevant thing I could find in the iPod's Rockbox manual. I guess Car Mode is only supported on the sansa fuze? 20.00.15 # isn't there some gcc magic to print the source file name ? 20.00.30 # andai: car adapter mode is even more unrelated 20.00.37 # saratoga__: __FILE__ 20.00.41 Quit saratoga (Client Quit) 20.00.41 # gevaerts: isn't that exactly the thing I needed to solve all my problems? 20.00.48 # saratoga__: actually standard C 20.01.03 # Oh, oh I see 20.01.15 # so we could in theory have the log prepend each entry with the file it came from and then filter it afterwards 20.01.17 # andai: no, absolutely not. Car adapter mode is to make audio pause when you stop the engine 20.01.41 # ok if some c wizard who remembers more then matlab programming wants to help that would be nice 20.01.51 # andai: which ipod is this? 20.01.59 # iPod Classic 160GB ( new one ) 20.02.04 # not yet fully supported, I think 20.02.08 # I was lucky in getting it to work apparently 20.02.32 # basic goals i think should be to properly set this up using the preprocessor so that regular builds only print errors and ignore warnings and debug statements, and then figuring out how to format the log so that it can be parsed and read easily 20.02.40 # andai: OK, that explains why you see the USB screen at all. Most players have better USB/charger distinction logic now 20.03.10 # andai: if you want to play audio while charging, hold any button while connecting 20.04.33 Quit Thra11 (Ping timeout: 252 seconds) 20.04.46 # saratoga__: seeing how many logf statements we have, I'd say we need to keep the compile-time selection of which files/subsystems to log for debug logging 20.06.30 # there's also __line__ 20.06.36 # (or was it __LINE__?) 20.06.59 # __LINE__. I don't think that's as useful for filtering purposes though 20.07.16 Quit PRETTY_FUNCTION (Quit: bb all have fun) 20.07.43 # not for filtering, true :) 20.09.06 # * gevaerts recommends staying away from #line though 20.09.58 # gevaerts: Hey, it works! Thanks :) 20.10.07 # Good :) 20.10.43 # for the ata delayed write mechanism, is it safe to assume that it won't call during USB and stuff like that? 20.11.04 # right now my callback doesn't check for USB or anything, it just blindly open's and write()s 20.11.04 # I'm fairly sure, yes 20.11.05 # Also, could someone change the status of the iPod Classic from "Unusable" to "Unstable"? Apart from occasional bugs and crashes ( less than once a day! ) it's been working just fine for me! 20.11.25 # i think we were waiting for a proper bootloader mechanism for the classic 20.11.32 # but maybe we don't really need that 20.11.43 # andai: "unusable" means (in part, but this is the main one for the classic) that you can't install using just rockbox tools 20.12.04 # It doesn't actually have anything to do with how buggy it is 20.12.12 # gevaerts: Oh that's right, i did have to boot into recovery mode, then run an .exe file... and then wait 5 minutes! 20.12.30 # Yes, and the exe file isn't from rockbox.org 20.12.40 # I... see 20.12.46 # but it makes Rockbox work! 20.12.52 # shouldn't this be endorsed by the project? :D 20.13.01 # is it closed source 20.13.16 # Not that we dislike the freemyipod people of course, it's just that we can't support outside code 20.13.34 # And support issues are kind of important 20.13.40 # is EMCore not usually a part of the rockbox bootscreen? 20.13.43 # No 20.13.46 # ahhh 20.14.10 # EMCore is a separate project, run by the freemyipod people (some of whom are also rockbox developers, by the way) 20.14.17 # It's all a bit complicated :) 20.14.38 # :D 20.15.01 # * [7] being one of those 20.15.18 # <[7]> emCORE is basically our development platform that we use to figure out how all the hardware works 20.15.26 # I guess we could technically change that port from being for the ipod classic to being for the ipod classic with emcore, which would remove that particular obstacle 20.15.38 # But that would be even more misleading for most people 20.15.41 # lol 20.15.46 # <[7]> and because there's no other bootable code for the ipod classic yet, we're using emcore as a bootloader on the ipod classic 20.16.12 # no i'm really loving Rockbox... after the first week of frustration ( expecting the interface to be more iPod-like ) it's been great :D 20.16.16 Quit perrikwp (Ping timeout: 264 seconds) 20.16.19 # how much work would it be to create a Rockbox bootloader for the classic? 20.16.27 # <[7]> gevaerts: the port itself doesn't really rely on emcore - it's just that there's no rockbox bootloader and rockbox installer yet 20.16.46 # [7]: I know. We need to fix that, really 20.16.55 # <[Saint]> "was it Tuesday when you...." 20.16.56 # <[7]> bluebrother^: the bootloader isn't much of a problem, the installation method is 20.17.00 # <[Saint]> Bwahahahahaha! 20.17.11 # hmm. So nothing similar to the nano2g? 20.17.23 # <[7]> nope 20.17.27 # it felt a lot like flashing my android device ( cheap off-brand eBook reader ) 20.17.30 # <[7]> the classic is basically the nano3g platform 20.17.48 # <[7]> and they have patched all the known holes in their bootloader 20.17.57 # Also, wasn't there some kind of protection that Apple put on it which made it impossible for Rockbox to work on it? At least that's what i remember reading like 5 years ago 20.17.59 # <[7]> and switched to asymmetric crypto 20.18.08 # <[7]> so we can't just inject our bootloader like on the nano2g 20.18.08 # andai: yes, but then [7] turned up 20.18.13 # haha 20.18.23 # too bad. 20.18.36 # <[7]> we currently have to rely on a DFU exploit to bootstrap this 20.18.40 # We also need to fix that USB detection thing on the nano2g and the classic one of these days, so charger detection works properly 20.18.47 # <[7]> this works slightly like iphone jailbreaking 20.18.49 # I'm trying to understand how it is _ever_ a good thing to specifically limit the kind of things people can do with the device you sell 20.19.09 # you can make people buy the next generation next year? 20.19.42 # <[7]> andai: DRM concerns, warranty concerns, and most importantly, using it as a playground platform to test out the iphone security strategy before launching that 20.19.52 # <[Saint]> andai: I actually have a skin floating around (that I need to fix) that mimics the iPod OF entirely, but it confused the hell out of people because I did it too well. 20.20.01 # <[7]> we have some pretty hard evidence of the nano2g being apple's iphone security guinea pig 20.20.09 # <[Saint]> It made it almost impossible to tell if you were in Rockbox or the OF :) 20.20.58 # [Saint]: you need to put that on the theme site :) 20.20.58 # gevaerts: is it not worth printing the line number in debug statements? 20.21.01 # <[7]> gevaerts, bluebrother^: for first-generation classics that have never been updated we can in fact boot through apple's bootloader, similar to how it works on the nn2g 20.21.08 # and then we need to make it the default theme on ipods :) 20.21.29 # <[7]> but for everything more recent we need to attack the bootrom directly because they fixed all bugs that they could patch on flash 20.21.37 # <[7]> so we *have* to flash the NOR on that device 20.21.38 # [Saint]: LINK 20.21.59 # <[Saint]> bluebrother^: I need to fix it first, there was one or two skin breaking changes since I stopped poking at it (and several new skin toys allow me to improve on it) 20.22.01 # [Saint]: I spent the first few days trying to make it as much like the iPod as possible, but most of the attempts at themes i found were just really depressing 20.22.05 # <[Saint]> But you're right, I should. 20.22.13 # also, does __FILE__ print the entire path from the machine compiling rockbox, or the path relative to our source tree? 20.22.16 # saratoga__: maybe. I'm not sure. That's a detail though, easy to change any time we like 20.22.22 # <[7]> saratoga__: I think the latter 20.22.24 # <[Saint]> I had Nano and Color versions up, but I was always slack about the Video port. 20.22.34 # It's also been fun showing off to friends: Hey, look, my iPod does fractals! 20.23.30 # wasn't it the path as passed to the compiler? 20.23.33 # saratoga__: "The presumed name of the current source file (a character string literal)" is what the standard says. Not very helpful :) 20.24.20 # awesome 20.24.37 Part andai 20.24.46 # void _logdiskf(const char* file, const char *format, ...) ATTRIBUTE_PRINTF(2, 3); 20.24.53 # that look right with the ATTRIBUTE statement? 20.24.56 # is there an overall codec that uses the least battery life? 20.24.59 # i looked at the ipod runtime wiki page but the numbers seem to be all over the place and alot of the data is old(6 years or so). 20.25.01 # i use alot of mp3's but i listen to alot of podcasts that also offer ogg feeds. 20.25.03 # so i was wondering if there is a better audio format i should be useing? 20.25.37 # amayer: http://www.rockbox.org/wiki/CodecPerformanceComparison might help (or not, it's not a simple question :) 20.26.10 # mpc, vorbis, wma are probably very slightly more efficient then mp3, and most other things will be less efficient 20.26.25 # amayer: I'm not sure if there are results for the classic on there, but you can probably use the nano2g numbers 20.26.44 # thats the one i was looking at 20.26.50 # if hes talking about 6 year old results its probably not hte classic? 20.26.52 # which ipod 20.27.04 # the classic on the site is the 80gb version, i have the 120 20.27.23 # ok then you're probably looking at results for different mp3 players then you own 20.27.30 # since we've only had a classic port for a little while now 20.27.45 # but yes i was looking at all the apple ipod results to see if (for exampe) ogg had better performace across the board 20.27.53 # thats not the best idea 20.27.58 # IIRC the classic gets something like 30 hours in rockbox 20.28.10 # amayer: the classic and the other ipods have rather different CPUs 20.28.24 # oh really? 20.28.40 # * gevaerts nods 20.28.57 # so different cpu's work better with different codecs? 20.29.18 # Yes, for more or less subtle reasons 20.29.44 # thank you very much for your help. I will keep this in mind when doing research in the future 20.29.57 # For instance, on the "old" ipods mp3 is better than anything else because it makes use of both CPU cores while other codecs don't. The classic is single-core 20.30.14 # That's one of the less subtle differences :) 20.31.07 # ok... so ogg files would do better(slightly) then mp3 on my 120Gb classic? 20.31.55 # I think they're going to be very close 20.32.03 # these are podcasts close to an hour long(does buffering come into play here?). so i wasnt sure if a "real time" codec or "buffered"? would be better 20.32.13 Quit evilnick (Remote host closed the connection) 20.32.43 # or am i way off in my thinking? 20.33.02 # Buffering always comes into play on HDD players, but mp3 and vorbis bitrates for the same quality aren't going to differ hugely 20.33.31 # So that won't make a big difference either. You'll run into that when you start comparing e.g. mp3 and flac 20.34.50 # so flac saves battery? not likely more flash reads 20.35.19 # kevku: no, rather the opposite, although on flash-based devices the effect is a lot less than on hdd 20.37.34 # gevaerts: so then its personal preference mp3 vs ogg not really performance. Is there a sound quality difference or something? i read that they are both lossy. 20.38.21 # amayer: they will sound different (up to a point, not everyone's hearing is that good), and you can get into fights over which is better 20.39.27 # *zips bullet proof vest* 20.39.29 # well thank you for your help. 20.39.31 # Ill try ogg and see how i like it compaired to mp3 20.40.10 # Just don't transcode between them. That *will* hurt the quality 20.41.59 # im not sure how the podcast sites handle that. but they offer mp3 and ogg feeds 20.43.01 # They have the original lossless recordings 20.43.10 # You can transcode from those 20.43.26 # good enough 20.43.44 # so something like flac would have better sound quality but use more battery to play? correct? 20.43.56 # (assuming it wasnt transcoded) 20.44.02 # It mainly takes a lot more space 20.44.12 # but not better quality? 20.44.43 # flac is actually a more efficient codec from what i understand, but those gains are offset by the quantity of reads due to enlarged size 20.44.47 # Maybe. For podcasts probably no noticeably better quality. For music, it depends on the kind of music, the bittrate you use for the lossy codec, and your ears 20.45.02 # amayer: well, flac is lossless - you are comparing it to many lossy codecs... 20.45.46 # by definition, lossless is better sound quality, but that depends on the source and just because it has better "sound quality", that doesnt mean you can perceive the difference 20.46.26 # scorche|sh: thank you very much 20.46.27 # You guys are very helpful 20.52.06 # gevaerts: crap, it prints the whole machine path from the build client 20.52.33 # is there some simple way to correct that or am i going to have to parse through strings 20.52.45 # Hm 20.54.44 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 20.55.36 # there is the __func__ option, which would just print the function name and could be grepped for i guess 20.57.05 # I don't think there's a good way to shorten __FILE__, unless we overhaul the build system 20.58.09 # Well, you can change what __LINE__ and __FILE__ are using #line, but that's not going to be trivial at all 20.58.21 # i guess the init function could parse the string once and figure out how many bytes to clip 20.58.27 # wouldn't be much overhead 20.59.06 # For dev builds that's fine I guess, but I don't think we want that for release builds 20.59.11 # since it knows that it will be in /firmware/logf.c it could count how many bytes to get to /firmware and then just truncate 20.59.24 # are release builds different? 21.00.03 # If we have a lot of messages, the RAM overhead might add up 21.01.07 # I'd expect the toolchain to only keep a single copy per file, but still, I think we need to check before deciding it's fine 21.01.26 # not sure i understand what you mean? 21.02.54 Quit megal0maniac (Quit: megal0maniac) 21.03.06 # I mean, if you use __FILE__ twice in one file, I expect only one string in the binary 21.03.35 # ah ok 21.03.38 # yeah probably 21.03.44 # But the bit of path we don't want is still there once per file, which might add up 21.04.06 # hmm this is going to mean that the binary size changes for each build client 21.04.08 # We could demand that all build clients run in / :) 21.04.18 # Right, that too... 21.04.45 # can the preprocessor somehow do the clipping before its compiled? 21.05.15 # A quick web search says no 21.05.27 # i mean could we write code in the preprocessor to do it 21.05.42 # like CLIP(__FILE__) 21.05.45 # where clip truncates __FILE__) 21.08.24 # googling this i feel like i'm heading into a bad place 21.09.41 # The only way I can think of is changing the build system to use relative paths from the source root, but that's going to be rather tricky 21.10.05 Quit tchan (Read error: No route to host) 21.10.06 # how tricky? 21.10.07 # Hmmm, there's one thing to try 21.10.23 # Hard to say 21.10.33 # actually it strikes me as odd that the build clients include their full paths in the first place since they're variable 21.10.50 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 21.10.59 # The problem is that we build in a separate directory from the source 21.11.07 # hmm 21.11.13 # so it would have to be ../ 21.11.15 # rather then / 21.12.08 Join JohnML [0] (~john1@frnk-590d8409.pool.mediaWays.net) 21.12.40 # In theory we can run gcc from the source root directory and be careful with -o (which we have to be anyway, but not as strictly in all cass I think) 21.13.29 # ok well how about for now we just use the __func__ define for now 21.13.47 # its not ideal but its better then nothing and we can change it later if we find a solution 21.14.04 # * gevaerts nods 21.14.40 # hmm editing my new logdisk.h file doesn't trigger a rebuild 21.14.51 # do i have to do some magic to get the makefile to recognize it as changed? 21.15.02 Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 21.15.08 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 21.15.17 # Hmmmm 21.15.23 # do we really have not a feature for a sansa clip+ to remove duplicates from a playlist? 21.16.04 Quit mgottschlag (Read error: Connection reset by peer) 21.16.22 # i doubt it 21.16.51 # saratoga__: so i do a feature request ? 21.16.55 # saratoga__: there *is* a way 21.16.56 # you don't 21.17.05 # ah what do you have? 21.17.58 # the function magic works ok, although just testing it the funciton name i'm in is "init" is is a little ambiguous ... 21.17.59 # just doing stuff right in the first place? 21.18.15 # Hm, not entirely 21.19.40 # saratoga__: if you put "#line 1 MYFILENAME" at the top of the file, and then add -DMYFILENAME=\"something.c\", __FILE__ will be something.c 21.19.59 # Now I'm trying to figure out how to do that without adding that line 21.20.12 # we could put it in the logdisk.h header file i guess 21.20.34 # although you'd still have to figure out a way to truncate the string so maybet hat doesn't work 21.20.43 # No. That doesn't work, it only overrides __FILE__ as used from logdisk.h 21.20.53 # ah 21.20.59 # smarter then i assumed 21.21.11 # Also you have to be careful with that "1". It resets __LINE__ 21.21.50 # surprising the gcc people have figured out a better solution yet 21.21.53 # And __LINE__ and __FILE__ are also used for compiler warnings and errors 21.22.08 Join Thra11 [0] (~thrall@87.112.231.26) 21.22.16 # i guess in our makefiles we process those strings ? 21.22.31 # to CC apps/main.c or whatever 21.22.34 # So if you get those wrong, you're going to be confused for a while before you understand error messages again 21.22.37 # yes 21.22.49 # that is infuriating 21.22.59 # is there some way to pass that argument directly to CC in the make file 21.23.13 # i guess that is the -D thing you were looking at? 21.23.25 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.24.04 # * gevaerts nods 21.26.12 # ok i am beginning to understand 21.27.05 *** Saving seen data "./dancer.seen" 21.30.01 # Hmmm 21.32.56 # * gevaerts decides to have a look at the build system instead 21.32.57 Quit mortalis (Quit: Leaving) 21.34.00 # alright, i set it to log the calling function name for now, and introduced a error levels 21.34.05 # i'll push to gerrit 21.36.46 Part JohnML ("Konversation terminated!") 21.40.03 # g#288 if anyone is interested 21.40.05 # 3Gerrit review #288 at http://gerrit.rockbox.org/r/288 : Introduce logging to disk feature into rockbox. by Michael Giacomelli (changes/88/288/4) 21.41.09 # i guess with some preprocessor magic we could just convert all LOGF macros into logdiskf(LOG_DEBUG, ...) calls 21.41.39 # although there would be no way (yet) to specify that you only want logs from certain files, other then to filter the resulting text file 21.53.27 # saratoga__: something like http://paste.debian.net/177877/ seems to do the trick, *but* that needs to be done for every single CC invocation in the makefiles, and disabling -Wbuiltin-macro-redefined also doesn't seem very nice 21.55.40 # Hm, if we decide to do something like that, we don't have to use __FILE__... 21.55.58 # So no need to undefine anything 21.57.14 # But still, having to add magic to every CC line in all makefiles is error-prone 21.59.35 Join Scromple [0] (~Simon@119.225.209.134) 22.28.15 Quit Thra11 (Read error: Connection reset by peer) 22.29.49 Join Thra11 [0] (~thrall@87.112.231.26) 22.34.25 Join nosa [0] (~m00k@adsl-74-235-42-61.clt.bellsouth.net) 22.35.28 Quit nosa-j (Ping timeout: 264 seconds) 22.35.29 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-61.clt.bellsouth.net) 22.37.44 # gevaerts: that sounds good to me 22.39.25 Join nosa [0] (~m00k@adsl-74-235-42-146.clt.bellsouth.net) 22.40.59 Quit nosa-j (Ping timeout: 246 seconds) 22.41.04 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-146.clt.bellsouth.net) 22.41.39 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 22.42.48 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 22.45.59 # do we want error logging enabled for Android builds, or do they have their own system for debugging? 22.57.33 Part amayer 23.01.02 # JdGordon: fwiw, I'm not happy how you outright ignored [Saint]'s and my opinions 23.09.57 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.17.55 Join nosa [0] (~m00k@adsl-74-235-42-146.clt.bellsouth.net) 23.18.01 Quit nosa-j (Ping timeout: 245 seconds) 23.18.04 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-146.clt.bellsouth.net) 23.18.10 # saratoga__: logcat ? 23.25.15 # <[Saint]> does Rockbox offer anything logcat wouldn't wrt: error logging? 23.27.08 *** Saving seen data "./dancer.seen" 23.30.26 Join mgottschlag [0] (~quassel@HSI-KBW-091-089-250-086.hsi2.kabel-badenwuerttemberg.de) 23.30.26 Quit mgottschlag (Changing host) 23.30.26 Join mgottschlag [0] (~quassel@reactos/tester/phoenix64) 23.30.32 Quit perrikwp (Ping timeout: 255 seconds) 23.33.19 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 23.35.03 Join factor [0] (~factor@r74-195-219-241.msk1cmtc02.mskgok.ok.dh.suddenlink.net) 23.35.45 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 23.43.49 # alright i'll leave alone android for now, but i guess eventually we want to redirect logs to its mechanism 23.44.20 Quit mgottschlag (Ping timeout: 246 seconds) 23.44.27 # is it possible to have a preprocessor macro check if the argument to a function is equal to a certain value (assuming its known at compile time)? 23.44.36 # yes 23.44.41 # well no 23.44.45 # but you can pretend 23.44.51 # token paste the argument to something 23.44.53 # i saw your solution the other day, but its not great if we want to have the threshold change i think 23.45.47 # why not> 23.46.11 # i was hoping to define a minimum warning level for different builds and have everything below it be removed by the preprocessor 23.46.15 # yes 23.46.21 # but that is hard if we're just prepending strings right? 23.46.22 # you can trivially do that by token pasting the level onto the macro name 23.46.37 # can you give an example? 23.46.38 # no, you paste the log level such that it becomes the name of another macro 23.46.49 # which can be conditionally defined to either log something or do nothing 23.48.23 # i'm assuming you mean to have 0_log, 1_log, 2_log functions and then just define some of them to be blank based on the warning level right? 23.49.02 # no, macros 23.49.15 # and the levels don't have to be numbers, names are nicer :) 23.50.24 # so #define DEBUGF(prio, args) DEBUGF_ ## prio ## (args) 23.50.49 # then #define DEBUGF_ERROR function_name 23.51.04 # and I guess put that in an IF block that checks to see if that level of warning should be printed? 23.51.07 # no 23.51.15 # #define DEBUGF_ERROR(args) 23.51.22 # such that you can make the macro expand to nothing 23.51.29 # anyway. 23.51.34 Join amayer [0] (~amayer@72.25.21.171) 23.51.39 # the token pasting trickery is not even really important 23.51.47 # let me try that and pastebin what i get 23.51.50 # chromium logging uses it to fuck about with C++ stream macros 23.51.58 # you can just use DEBUGF_ERROR() to start with 23.52.17 # or whatever you feel like calling it 23.52.38 # make the level part of the name of the macro you call at the callsite, instead of a parameter 23.52.39 # yeah i was thinking about that 23.52.44 # then you don't need to do naything special at all 23.53.50 # this needn't be complicated 23.53.58 # :) 23.56.31 # Torne: http://pastebin.com/zBNYBuXG 23.56.51 # yup 23.56.59 # i would use much shorter names though 23.57.09 # probably just ERROR() WARN() etc :) 23.57.20 # yeah that sounds good 23.57.22 # the mechanism is not important 23.57.27 # in fact you may have more than one mechanism 23.57.56 # i bet DEBUG is going to be a name collision 23.58.01 # Torne: can you think of a good way to make __FILE__ (or a similar macro) produce short names by magic without having to change *every* CC invocation in the makefiles? 23.58.52 # saratoga__: LOG_DEBUG or something?