--- Log for 24.11.113 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 17 days and 18 hours ago 00.00.27 # we pretty much need "put framebuffer on display" 00.00.39 # decoding codecs on it would be pretty cool though 00.01.06 # <[Saint]> When they "opened" the display driver, they really just releaed an open shim to a closed source binary - which is still _something_ I guess, but yeah. 00.01.27 # <[Saint]> There's some painfully slow going on reversing the videocore binary. 00.01.55 # <[Saint]> Not going terribly fast, or far, though. Perhaps they need a pamaury. ;) 00.03.11 Quit ender` (Quit: Space, the last best hope for peace. These are the voyages of the Millenium Falcon. Its five-year mission: to find technology to defeat the Goa'uld.) 00.03.20 # <[Saint]> And while doing codecs on the GPU would be very cool - I think we're fast enough on ARM with most codecs now to not make that a major worry at all. 00.03.30 # <[Saint]> s/now/for a long time/ 00.05.49 Quit onder` (Quit: leaving) 00.06.28 # is this videocore thing common or just on the rspi ? 00.06.40 # rpi also has the (in)famous videocore stuff like the ipod video? 00.06.46 Join onder` [0] (~onder@dyn-dsl-to-76-75-106-228.nexicom.net) 00.07.59 # amiconn: yeah, but a much older one 00.09.53 # * [Saint] is somewhat surprised that the raspberrypi hasn't restarted a new boom in the "Lyre" project... 00.10.30 # <[Saint]> You could sell kits. Raspi, PicoPSU, generic project box, bunch of buttons wired for a GPIO header, and a 7" composite LCD. 00.11.30 # <[Saint]> roll a tiny distro based on Arch or something suitable tiny. bam. 00.11.46 # but it would be quite big 00.12.57 # <[Saint]> You could add a keyboard! :) 00.14.44 Quit lorenzo92 (Ping timeout: 248 seconds) 00.14.56 # pamaury: hwstub for rk commited :-) 00.16.34 # good 00.17.11 # now the challenge is hwstub for atj :-) 00.19.36 # I have two: hwstub for rknano and tcc 00.20.26 # pamaury: I was wondering how usb connected debuggers inform gdbserver about hitting breakpoint? I was thinking that we could patch mem to jump into hwstub but then it needs to somehow inform gdbserver that breakpoint is hit 00.22.05 # pamaury: with rknano I would start from porting hwstub to amsv2 00.22.28 # then you will have some means of feedback from target during development 00.22.39 # usually you rather write an undefined instruction and capture this undef instr handler 00.23.06 # pamaury: we could use swi as well. That part really doesn't matter 00.24.09 # so what is your question then ? 00.24.39 # how the gdbserver knows the breakpoint was hit 00.25.01 # polling or we define an interrupt endpoint 00.25.28 # it would be preferrable to implement transport over bulk anyway, for speed reasons 00.26.24 # Current implementation has BIG benefit of being very simple. Only control transfers. 00.26.34 # yes I know 00.26.49 # that's why I wrote it this way 00.27.33 # but to support remote debugging we would need to enhance hwstub quite a bit 00.27.43 # we would need to intercept the irq handler and hide usb from the running code 00.30.55 Quit n1s (Quit: Ex-Chat) 00.37.27 Quit wodz (Quit: Leaving) 00.47.50 # [Saint]: sadly, raspi nearest competitor (in my opinion) beaglebone black is minus an audio interface 00.49.05 # what are the differences ? 00.49.21 # raspi has jack and hdmi audio ? 00.51.24 # raspi has 3.5mm type audio jack; bbb has none and it also has audio output through hdmi 00.51.52 # <[Saint]> so does raspi 00.51.56 # <[Saint]> (audio over hdmi) 00.51.59 # ah, yes 00.52.47 # not an expert myself, but bbb is also fully documented 00.52.51 # oh really, no jack ? 00.54.52 # jack exists on BegaleBone and BeagleBone XM ; those are also about $100 usd more costly 00.59.16 Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 00.59.34 Quit mikroflops (Ping timeout: 245 seconds) 01.00.33 Join mikroflops [0] (~yogurt@s208h18o1esc1.dyn.tyfon.se) 01.07.15 Quit shamus (Read error: Connection reset by peer) 01.07.55 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 01.21.29 Quit bertrik (Remote host closed the connection) 01.39.14 *** Saving seen data "./dancer.seen" 01.39.43 Join treaki_ [0] (bc31053766@p4FDF7E84.dip0.t-ipconnect.de) 01.42.12 Quit treaki__ (Ping timeout: 248 seconds) 01.51.33 Quit Tukeke (Quit: Tukeke) 02.04.33 Join Narod- [0] (Narod@p5DDDAE6A.dip0.t-ipconnect.de) 02.06.12 Quit Narod (Ping timeout: 246 seconds) 02.08.13 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 02.19.56 Quit Gallomimia (Quit: Gallomimia) 02.22.20 Quit Narod- () 02.38.51 # [Saint]: I'm looking at the videocore project, they made a lot of progress recently 02.41.04 # <[Saint]> pamaury: #raspberrypi-internals is where most of the IRC stuffs happens afaik 02.42.05 # anyway I don't really plan to work on this, not in the near future 02.42.25 # or someone would have to find a very good reason for it 02.51.27 Join Gallomimia [0] (~gallomimi@216.232.233.122) 02.54.30 Join impossible [0] (~impossibl@user-1087s8g.cable.mindspring.com) 03.12.45 Quit Gallomimia (Quit: Gallomimia) 03.15.41 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 03.32.35 # pamaury: very good financial reason? do you mean that? 03.39.16 *** Saving seen data "./dancer.seen" 03.53.22 # i installed rockbox on my fuze and I'm missing one song. 03.53.38 # it was in flac. Does rockbox play flac? 03.57.45 # Whoops. Turns out I deleted the file. Loving rockbox though 04.04.29 Quit cmhobbs (Ping timeout: 265 seconds) 04.30.11 Quit amiconn (Disconnected by services) 04.30.11 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.30.14 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.30.18 Quit pixelma (Disconnected by services) 04.30.19 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.30.21 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.32.42 Quit nosa-j (Ping timeout: 272 seconds) 04.34.03 Join nosa-j [0] (~m00k@66.233.224.206) 04.41.52 Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) 04.42.53 Join Gallomimia [0] (~gallomimi@S0106000f6690b14a.ca.shawcable.net) 04.51.25 Quit Gallomimia (Ping timeout: 272 seconds) 05.00.15 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 05.03.25 --> "oper #nsfw" received from thequux (~thequux@tx-67-77-76-133.dyn.embarqhsd.net) 05.03.45 --> "help" received from thequux (~thequux@tx-67-77-76-133.dyn.embarqhsd.net) 05.04.35 Quit TheSeven (Disconnected by services) 05.04.50 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.06.09 --> "test" received from thequux (~thequux@tx-67-77-76-133.dyn.embarqhsd.net) 05.18.26 Quit nosa-j (Ping timeout: 245 seconds) 05.22.07 Join nosa-j [0] (~m00k@66.233.224.206) 05.26.10 Quit cmhobbs (Ping timeout: 246 seconds) 05.39.08 Quit [Saint] (Remote host closed the connection) 05.39.20 *** Saving seen data "./dancer.seen" 05.40.14 Join [Saint] [0] (~saint@rockbox/user/saint) 05.43.37 Quit K1773R (Excess Flood) 05.43.57 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 06.03.17 Quit impossible (Remote host closed the connection) 06.10.02 Quit foolsh (Quit: foolsh) 06.39.13 Quit mc2739 (Quit: leaving) 06.42.56 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 07.00.56 Quit copper (Ping timeout: 252 seconds) 07.13.02 Quit thegeek_ (Ping timeout: 264 seconds) 07.33.10 Join mortalis [0] (~kvirc@213.33.220.118) 07.39.24 *** Saving seen data "./dancer.seen" 07.43.21 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 08.01.50 Quit Maxdamantus (Ping timeout: 260 seconds) 08.10.38 Join Maxdamantus [0] (~Maxdamant@2001:470:f078::dead:beef:cafe) 08.11.33 Quit shai (Quit: Leaving) 08.15.52 Join copper [0] (~copper@unaffiliated/copper) 08.17.14 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 08.26.56 # battery benchmark with a recent revision on the Clip+, with lossyFLAC: https://outpost.fr/tmp/d6V.txt 08.46.38 Join n1s [0] (~n1s@rockbox/developer/n1s) 08.51.20 # <[Saint]> Whoah. 08.51.35 # <[Saint]> SO much different looking at a target where the estimated runtime is even vaguely correct. 08.53.29 # [Saint]: is there any chance that the reason is that the Clip+ is never "unboosted"? 08.53.43 # (if I recall correctly?) 08.54.30 # <[Saint]> ...huh? 08.54.44 # <[Saint]> I'm not sure how those would relate to each other, even if it were true. 08.55.47 # just some bit that I remember from the test_codec benchmarks that saratoga asked me to run some time ago 08.56.15 # dunno if the "boosting / unboosting" thing only concerned the test_codec plugin 08.56.38 # <[Saint]> I think you may be misremembering. The CLip+ certainly is "never unboosted", it very rarely boosts. And this doesn;t have anything to do with estimated runtime. 08.57.01 # * copper greps his logs 08.57.14 # <[Saint]> Errr, dammit. I worded that very oddly. The Clip+ has very little reason to ever boost. 08.57.37 # <[Saint]> Except if you're running some truly insane codec and to fill the buffer., 08.58.30 # <[Saint]> You can run run an unboosted test_codec run, and that would result in awful runtime...perhaps that's what you're thinking of? 08.59.02 # yeah the clip+ has boosting disabled 08.59.24 # 2013/07/28 20:28:43 UTC 08.59.47 # but that related to the test_codec plugin 08.59.52 # I don't see that option on the Clip+ 09.00.12 # it was a bit unstable and we never figured out why 09.02.44 # [Saint]: I'm just talking out of my ass, like most of the time ;) 09.02.59 # <[Saint]> Hmmm..I see. I don't remember that sticking. I thought that was only temporary. 09.03.07 # trying to related bits and pieces I know nothing about and don't understand :-P 09.03.17 # relate* 09.03.58 # anyway… my Clip+ is charging, and then I'll run the year old build like the Classic 09.04.14 # since the Clip+ battery is so much smaller, I'll be able to get the results today 09.04.21 # <[Saint]> I think I recall the Clip+ not getting terribly much out of running an unboosted clock anyway. But now I'm struggling to recall because I thought it still had boosting enabled. 09.05.53 # <[Saint]> Well, my apologies. I really thought that was only temporary, I certainly recall it having boosting once upon a time. 09.08.36 # <[Saint]> Maybe I'm mixing things I think I recall about the CLip+ and the ClipV1 09.12.06 # <[Saint]> So much variance in the SansaRuntime Clip+ stats its pretty much impossible to gain anything useful from it. 09.12.55 Join thegeek [0] (~thegeek@60.36.34.95.customer.cdi.no) 09.13.17 # <[Saint]> 9h in 2010, to 17h in 2010, 14h in 2011, to 10h in 2013, and now your 15h in 2013. :-/ 09.14.34 # I guess you can only reliably compare benchmarks on the same unit, at about the same time 09.14.45 # like what I'm doing now 09.15.20 # <[Saint]> I'll dig up and charge a Nano2G this evening when the So goes to bed. 09.15.24 # same unit at the same time = same battery at the same age 09.15.35 # <[Saint]> Since tests there will take changing builds and looking at a screen. 09.15.42 # <[Saint]> Rather than waiting ~20h 09.15.51 # <[Saint]> + 09.15.53 # what is the So? 09.16.10 # <[Saint]> Significant Other - Ms [Saint] :) 09.16.14 # ah 09.16.26 # and what's special about the Nano 2G? 09.16.49 # <[Saint]> Its the only target that can display its exact power usage. 09.16.57 # nice 09.16.58 # <[Saint]> (to my knowledge) 09.18.08 # <[Saint]> There's about what, ~300 commits to cover in the period you're testing from? 09.18.27 # <[Saint]> git bisect should have that done in no time. 09.19.12 # <[Saint]> for reference for me later on, what is the closest "good" commit? 09.19.53 # iPod Classic: 3e1c492 09.20.07 # Fuze+: c4f2a46 09.20.20 # first is from november 2012, second is from July 2013 09.20.45 # but right now I have no idea if there is any relation between the two in terms of battery life 09.20.45 # <[Saint]> So its variable by device, or those are just builds you happened to have laying around? 09.21.11 # I chose the Classic commit from 2012 because that's what I tested a year ago 09.21.37 # pamaury chose the Fuze+ commit because he knew that one was supposed to have long battery life, but I think that was Fuze+ specific 09.22.16 # <[Saint]> Ok, nevermind. I'll pick an arbitrary point in time that predates both. Easier. 09.22.25 # I'll be testing the Clip+ with the same year old commit as the Classic, to see if the battery life difference is target-agnostic or not 09.23.08 # <[Saint]> I would find it hard, but not impossible, to believe that a bunch of device-specific regressions were introduced. 09.23.20 # and yeah, it's a pain to test, but that year old commit was my only known reference 09.24.01 # <[Saint]> Looking over the commits from that period, there's no immediate show-stopper that jumps out and says "test me". 09.24.07 # <[Saint]> But, there;s a few I could try. 09.24.16 # <[Saint]> I'll let git biscet descide. 09.24.37 # if it was more or less obvious, I suspect someone else would have found out about it already ;) 09.25.29 # like I told GodEater the other day, a 25% drop in battery life is not necessarily obvious when you're casually using your DAP 09.25.32 # <[Saint]> You'd think. But stranger things can happen. 09.25.48 # <[Saint]> And, no. It isn't. 09.26.12 # <[Saint]> I charge all the time, whenever I can. 09.26.28 # <[Saint]> So I wouldn't ever notice it unless battery time dipped below ~5 hours. 09.27.16 # <[Saint]> Hmmmm...there _was_ a really big playback engine reshuffle.... 09.28.33 # [Saint]: btw, the battery life difference with the Fuze+ is rather interesting: 09.28.37 # https://outpost.fr/tmp/laE.txt 09.28.40 # https://outpost.fr/tmp/LUN.txt 09.29.01 # 41 hours in july 2013 vs 30 hours now 09.29.25 # so if the problem is target-agnostic, there may be a chance that it came after july 2013 09.30.06 # though the Fuze+ is a slightly different beast, since there has been a lot of work semi recently to improve its battery life 09.30.17 # but the drop is large enough to be worth mentionning 09.30.50 # a Fuze+ build from late 2012 would also likely run for 30 hours, because the improvements came later 09.31.15 # the more devices we collectively test, the better, I guess 09.39.25 *** Saving seen data "./dancer.seen" 09.40.07 # <[Saint]> After July? 09.40.15 # <[Saint]> Well..that's my candidate excluded than. 09.40.22 # <[Saint]> *then 09.40.23 Join Gallomimia [0] (~gallomimi@99.199.8.77) 09.42.31 # <[Saint]> g#479 ? 09.42.33 # 3Gerrit review #479 at http://gerrit.rockbox.org/r/479 : 3 by Michael Sevakis (changes/79/479/9) 09.44.34 # my config sets 44.1 kHz 09.46.12 # <[Saint]> If I assume target has nothing to do with it, and take your "July-ish" feeling into account...that seems like the likliest change to accidentally balls something up - though it shouldn't, to my knowledge. 09.49.01 # <[Saint]> I initially suspected the playback engine rework, but with the data you've given that is ruled out. 09.49.28 # that means running two more benchmarks on any given target: one with that revision, and one with the revision before that one 09.50.21 # <[Saint]> I'm not going to go with any gut hunches on this one, I'll end up leading myself astray. 09.50.56 # <[Saint]> I'll pick an arbitrary point in time in the "known good" region and let observation and git bisect decide. 09.51.41 # <[Saint]> If I don't manage to sneak away tonight I should have all day tomorrow. 09.52.10 # hmmm, but that commit predates the 40 hours Fuze+ revision 09.53.03 # <[Saint]> When it was committed to gerrit, yes. 09.53.07 # <[Saint]> To Rockbox, no. 09.53.57 # <[Saint]> It was committed between the 2nd and 5th of July 2013 09.54.09 # git log puts it online 3112, while the Fuze+ revision is on line 2536? 09.54.27 # the Fuze+ revision was committed on July 23 09.54.54 # <[Saint]> Ahhh, well. Shit. 09.55.25 # unless that IS indeed the offending commit, and instead of 40 hours, the Fuze+ should have gone 50 hours! 09.55.38 # <[Saint]> Hahahaha :) 09.55.48 # <[Saint]> ...possible. 09.56.20 Quit soap (Ping timeout: 272 seconds) 09.56.26 # * [Saint] now ses where he misread a datestamp 09.56.32 Quit kevku (Read error: Connection reset by peer) 09.56.33 # <[Saint]> *sees 09.56.47 Join ender` [0] (krneki@foo.eternallybored.org) 09.56.58 # <[Saint]> Serve's me right for going looking again for possibly-suspect commits. 09.57.41 Quit mortalis (Read error: Operation timed out) 09.58.42 # <[Saint]> Knowing my luck I'll test on N2G when I get a chance and everything will be kosher. 09.59.12 Quit ender` (Client Quit) 09.59.38 # ugh, that is a big commit 10.01.38 # <[Saint]> But if one assumes your F+ revision is "good" it can't be the offender. 10.02.29 # <[Saint]> Disregarding that info, it certainly looks like a suspect. It walks over enough things. 10.03.14 Join lorenzo92 [0] (~chatzilla@host214-107-dynamic.40-79-r.retail.telecomitalia.it) 10.03.16 # <[Saint]> I'll take off the speculation hat until I can do something about it. Thinking about possibilities is driving me nuts. 10.03.25 # [Saint]: the Fuze+ revision is special because it includes work on saving battery; there's no telling if the improvements were so large that they would absorb the regression. 10.04.41 # If the clip+ with the year old revision shows better battery life, I'll try the sampling rate commit on it right after 10.05.42 # I'd rather test the Clip+ over my Fuze+ and Classic because 1) I don't use it, and 2) its battery is smaller and thus the benchmark last half as long 10.05.47 # benchmarks* 10.07.21 Join soap [0] (~soap@rockbox/staff/soap) 10.09.12 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 10.10.28 Quit lorenzo92 (Ping timeout: 248 seconds) 10.10.43 Join ender` [0] (krneki@foo.eternallybored.org) 10.12.12 # er 10.12.25 # that wouldn't explain the Fuze+ regression 10.12.47 # if it lasted 40 hours WITH the regression, then its later regression would not be related 10.12.59 # sigh 10.13.26 Quit soap (Ping timeout: 272 seconds) 10.19.33 Join lorenzo92 [0] (~chatzilla@host214-107-dynamic.40-79-r.retail.telecomitalia.it) 10.43.48 Join markun [0] (~markun@rockbox/developer/markun) 10.49.30 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 10.54.26 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 10.54.26 Quit bertrik (Changing host) 10.54.26 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 11.04.46 Join Narod [0] (Narod@p5DDDAE6A.dip0.t-ipconnect.de) 11.12.17 Nick SuperBrainAk is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 11.19.07 Quit Wardo (Quit: Blarglarg) 11.39.28 *** Saving seen data "./dancer.seen" 12.09.20 Quit lorenzo92 (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) 12.59.45 # copper: how is the clip+ doing ? finish ? 13.00.12 # One on my fuze+ finished the after 7h ! That the fuze+ I only rarely use, maybe the battery is dead :( 13.00.17 # 07:26:57 UTC battery benchmark with a recent revision on the Clip+, with lossyFLAC: https://outpost.fr/tmp/d6V.txt 13.00.35 # 15 hours 13.01.19 Quit K1773R (Read error: Operation timed out) 13.03.49 # is that good or bad ? 13.04.25 # that's fairly normal I think 13.04.42 # except I'm using (lossy) FLAC, which is very efficient 13.05.01 # right now I'm running another benchmark on the Clip+ with the same year old revision that I ran on my Classic 13.05.08 # we'll see if there is a significant difference 13.08.18 # for reference, FLAC on the Clip+ decodes nearly 4 times faster than LAME 13.08.33 # and my lossyFLACs are barely twice the size 13.09.31 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 13.28.01 Join lorenzo92 [0] (~chatzilla@host214-107-dynamic.40-79-r.retail.telecomitalia.it) 13.39.30 *** Saving seen data "./dancer.seen" 14.12.21 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.30.49 Quit kugel (Ping timeout: 252 seconds) 14.34.04 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 14.38.54 Join krabador [0] (~krabador_@host235-196-dynamic.181-80-r.retail.telecomitalia.it) 14.38.54 Quit krabador (Client Quit) 14.39.15 Quit lorenzo92 (Ping timeout: 248 seconds) 14.51.39 Quit mc2739 (Quit: leaving) 15.01.31 Join soap [0] (~soap@rockbox/staff/soap) 15.05.25 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 15.05.48 Quit mc2739 (Remote host closed the connection) 15.13.28 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 15.23.00 Join rela [0] (~x@pdpc/supporter/active/rela) 15.24.24 Join krabador [0] (~krabador_@unaffiliated/krabador) 15.39.33 *** Saving seen data "./dancer.seen" 15.49.59 Quit soap (Ping timeout: 272 seconds) 15.52.56 Join soap [0] (~soap@rockbox/staff/soap) 15.54.47 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 16.00.23 Quit soap (Ping timeout: 245 seconds) 16.03.21 Join soap [0] (~soap@rockbox/staff/soap) 16.29.06 Quit rela (Read error: Connection reset by peer) 16.37.39 Quit cmhobbs (Ping timeout: 248 seconds) 16.40.58 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 16.40.58 Quit cmhobbs (Changing host) 16.40.58 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 16.45.45 Quit cmhobbs (Ping timeout: 252 seconds) 17.27.56 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 17.39.34 *** Saving seen data "./dancer.seen" 17.47.36 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 18.08.55 Join Guest81512 [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net) 18.12.35 Quit Guest11127 (Ping timeout: 272 seconds) 18.39.04 Quit krabador (Quit: Sto andando via) 18.46.47 Join linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 18.48.43 Quit ikeboy (Ping timeout: 245 seconds) 19.01.06 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.05.48 Quit cmhobbs (Ping timeout: 245 seconds) 19.10.18 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 19.34.52 Quit cmhobbs (Ping timeout: 265 seconds) 19.39.39 *** Saving seen data "./dancer.seen" 19.42.11 Quit markun (Ping timeout: 248 seconds) 19.42.23 Join markun [0] (~markun@rockbox/developer/markun) 19.43.27 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 19.43.29 Quit cmhobbs (Changing host) 19.43.29 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 19.43.46 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.53.23 Quit cmhobbs (Ping timeout: 248 seconds) 20.08.23 Quit kugel (Ping timeout: 246 seconds) 20.18.05 # pamaury: clip+ currently at 22%, but that's expected: I started the benchmark somewhat late 20.18.26 # er, I'm replying to the same question for the second time 20.18.31 # backlog 20.18.32 Join Strife89 [0] (~Strife89@adsl-98-80-218-160.mcn.bellsouth.net) 20.19.28 Nick DormantBrain is now known as SuperBrainAk (~andy@2001:470:8:a61::5f92:59a1) 20.21.17 # copper: on my fuze+ I think I will reach 30h but no more 20.26.35 Join Cultist [0] (~CultOfThe@c-24-12-53-28.hsd1.il.comcast.net) 20.26.36 Join saratoga [0] (123e1c08@gateway/web/freenode/ip.18.62.28.8) 20.26.43 # Hello 20.27.29 # I wondered if anyone could recommend a music player with good rockbox support, something 16 or 32gb with good build quality in the $100~ range 20.27.31 # if you want to test battery life a lot, i'd recommend a DMM and a USB cable 20.27.39 # total cost on Amazon.com is less than 10 USD 20.28.43 # Cultist: probably a sandisk player and a microsd card 20.28.55 # pamaury: is your current Fuze+ revision older or newer than the 40 hours one? 20.29.18 # I've got a Sandisk zipclip with rockbox on it, but it keeps freezing up and crashing when I try to play ogg files 20.30.14 # does it always happen with the same files? 20.30.16 # Cultist: any ogg files or sepcific ones? 20.30.21 # i'm surprised, ogg support is quite stable 20.31.01 # happens with all the ones I've tried 20.31.24 # all converted from flacs, I guess it's possible something was going wrong with the conversion 20.31.27 # but they play fine on mycomputer 20.31.36 # at the same place in each file? 20.31.42 # or is it random 20.31.42 # before they start 20.31.47 # I open the file, everything freezes 20.31.50 # ah thats probably bad files than 20.32.07 # except they work on my computer's media player 20.32.13 # we still shouldn't freeze 20.32.21 # try this file and see if it works: http://download.rockbox.org/test_files/vorbis_128.ogg 20.32.54 # gotta dig up a microsd card, misplaced the one I had in there (I haven't messed with it in a while) 20.35.20 # copper: all revisions we are testing are older than the 40hours one 20.42.39 # hm 20.42.42 # it works now 20.42.55 # Could the filenames cause a problem? 20.43.08 # things with overly long names, or with accented characters? 20.44.07 # no those won't matter 20.44.34 # so that test file works, but your files do not? 20.45.54 # cheap DMM: http://www.amazon.com/gp/product/B005EK3NRS/ref=s9_simh_gw_p60_d0_i1 20.46.09 # Large vorbis comment stuff, maybe? 20.46.15 # or perhaps weird/overly large metadata 20.47.07 # the problem with huge metadata is supposed to be fixed 20.47.52 # anyway i'd be interested in a file that freezes the player with a recent version of rockbox 20.48.04 # wow someone actually makes a USB power meter: http://www.amazon.com/PortaPow-Monitor-Multimeter-Ammeter-Chargers/dp/B00DF2485S/ref=sr_1_1?s=hi&ie=UTF8&qid=1385322439&sr=1-1&keywords=usb+power+meter 20.48.12 # wonder if its any good 20.49.02 # "now accurate to 0.01A" doesn't sound super useful 20.49.31 Quit y4n (Quit: Today is the perfect day for a perfect day.) 20.49.45 # ah yeah too low to be that useful 20.49.51 # err, our currents are too low 20.50.49 # a real DMM is cheaper and more versatile anyway 20.51.56 Join onder`_ [0] (~onder@dyn-dsl-to-76-75-119-170.nexicom.net) 20.55.21 Quit onder` (Ping timeout: 272 seconds) 20.55.27 Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-119-170.nexicom.net) 21.01.10 # went afk 21.01.23 # saratoga, yeah. Or at least, they used to not 21.01.36 # so they work now? 21.01.36 # I need to go get a new higher capacity microusb card, biggest one I can find at home is 8gb 21.01.46 # I must have misplaced my old one with my music 21.02.04 # I'll rebuild the set on a new card and see if they work now 21.03.29 Join Szczepancio [0] (~Patryk@acfl132.neoplus.adsl.tpnet.pl) 21.04.09 # pamaury: Did you make anything on linux based sony players? 21.05.59 # not yet 21.06.02 # pamuary: I mean, did you anything after my absence. 21.06.35 # Meh, bad. 21.07.18 # I know it's not your fault, but it's bad that nobody take interest in sony linux mp4 player's. They are great. 21.08.58 # it's not that nobody is interested, it is that nobody has time 21.09.54 # yeah, there are a lot of mp3 players out there 21.23.14 Join kugel [0] (~kugel@46-127-48-168.dynamic.hispeed.ch) 21.23.14 Quit kugel (Changing host) 21.23.14 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.27.50 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 21.29.31 Quit saratoga (Quit: Page closed) 21.35.16 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 21.36.09 # pamaury: I have problems compiling qeditor http://pastie.org/8505799 21.37.12 # wodz: give me 5/10 minute and I'll be available 21.39.43 *** Saving seen data "./dancer.seen" 21.41.39 Quit Szczepancio (Quit: Leaving) 21.50.13 # wodz: it compiles fine here :-/ 21.51.19 # ah I see, I'm using a gcc extension syntax 21.51.58 # qmake emitted warning also: "Project MESSAGE: Warning: unknown QT: widgets" 21.52.29 # wodz: change the offending lines to this: http://paste.pm/c59.c 21.55.15 # pamaury: works, thanks 21.59.52 Join SYSTEM_ [0] (~chatzilla@adsl-99-120-26-33.dsl.dytnoh.sbcglobal.net) 22.00.00 Part SYSTEM_ 22.00.14 Join Water [0] (~chatzilla@adsl-99-120-26-33.dsl.dytnoh.sbcglobal.net) 22.02.14 # Hey guys. Anyone in here use a Fuze+? 22.03.19 # plenty 22.03.51 # Is this a known bug: turn on Fuze+ (start screen set to "Resume Playback"), as soon as playback starts, long-press the "Play/Pause" button. RB now hangs for 20 seconds and nothing can be done. 22.03.54 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 22.03.57 Quit bluebrother (Disconnected by services) 22.04.26 # I'm guessing it has something to do with the bookmark file. 22.04.46 # that rings a bell but I'm note sure 22.05.01 # I'll try it when my fuze+ has finished my battery bench 22.05.17 # Cool. Ty. 22.05.23 Quit fs-bluebot (Ping timeout: 245 seconds) 22.06.42 # pamaury: qeditor doesn't work for me. With my xml file it spits "parser error : Extra content at the end of the document " loading stmp files crashes the whole thing "GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument. Aborting." 22.06.44 Join fs-bluebot [0] (~fs-bluebo@g225254033.adsl.alicedsl.de) 22.06.59 # hum 22.07.01 # weird 22.09.05 # pamaury: my description file: http://pastie.org/8505850 22.13.27 # google chrome doesn't like your file either 22.14.18 # ah, you don't need to close the tag 22.14.46 # actually you must not close it 22.16.10 # pamaury: that is contrary to what your XML.txt file states :-) 22.17.12 # pamaury: after removing from my file it crashes qeditor the same as your stmp xml description files 22.18.02 # can you run valgrind ? 22.18.20 # or gdb 22.18.40 # by the way, if you put your xml file into utils/regtools/desc/ 22.18.47 # it will automatically be loaded 22.18.57 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 22.18.58 Quit cmhobbs (Changing host) 22.18.58 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 22.19.46 # it should be named regs-rk27xx.xml probably, for this to work 22.20.21 # I have no idea why it crashes though 22.20.24 # backtrace of the crash: http://pastie.org/8505870 22.20.56 # not very helpful I guess 22.23.30 Quit Strife89 (Ping timeout: 240 seconds) 22.25.12 # indeed 22.25.16 # maybe ask bluebrother^ 22.25.22 # he knows a lot about QT 22.30.02 # valgrind summary: http://pastie.org/8505890 22.33.50 # so the program is not doing anyway strange 22.33.56 # I mean appart from crashing ^^ 22.35.04 # yeah, without that minor detail it works great :P 22.35.14 # *besides 22.35.42 # I never pretended that it actually works ! 22.35.57 # I just pretended that it does things on my computer :p 22.36.04 Join Strife89 [0] (~Strife89@adsl-98-80-219-190.mcn.bellsouth.net) 22.40.10 # wodz: maybe it's a problem with QT ? 22.40.24 # or maybe it's related to this warning in qmake 22.40.49 Quit benedikt93 (Quit: Bye ;)) 22.40.58 # pamaury: I don't know C++ and don't know QT so can't say 22.41.18 # pamaury: which version of qt do you have on your machine? 22.41.30 # i'm not QT expert some maybe I did something wrong 22.41.32 # QT4 22.42.22 # 4.8.5 iirc 22.44.05 # 4.8.1 here 22.56.35 Quit markun (Ping timeout: 272 seconds) 23.06.13 # copper: fuze+ ran for 26h :-/ 23.07.21 Quit kugel (Ping timeout: 272 seconds) 23.10.11 Quit n1s (Quit: Ex-Chat) 23.11.11 Quit Gallomimia (Quit: Gallomimia) 23.13.16 # pamaury: What file type/bit-rate? I got 33 hours 6 months ago when mine was brand new. 23.13.40 # ~224 kb/s mp3 23.14.05 # Water: we are bisecting a power regression, this test does not represent the current status 23.14.15 # ah 23.14.19 # the best we have obtained is ~40h with high quality mp3 23.14.36 # wow cool! 23.15.30 # but we have regressed since then and we trying to find why 23.15.49 # Could I help with my Fuze+? 23.16.44 # pamaury: 23.17.17 # I'm waiting for the results of copper but yeah definitely 23.17.48 # best you can do is pop up tomorrow, I'll send you the files for a specific revision and explain you the procedure 23.17.53 # if you don't mind :) 23.17.59 # Glad to help. 23.18.16 # Around what time tomorrow? 23.19.02 # Send the links. 23.19.06 # any time, I'll always connected during the day (GMT time) 23.19.10 # *I'm 23.20.56 # Oops, i misunderstood. I'll pop in tomorrow ready to go. 23.21.51 # ok thanks 23.22.00 Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) 23.23.21 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 23.24.14 # I have a vague memory of some commit comment months ago with words something like "remove all frequency scaling". I didn't actually read the code. We do scale CPU frequency on the Fuze+ though, right? 23.25.21 Quit lebellium (Ping timeout: 272 seconds) 23.25.32 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 23.27.44 Join pubwsli [0] (44bf2bb6@gateway/web/freenode/ip.68.191.43.182) 23.28.18 Quit pamaury (Ping timeout: 245 seconds) 23.32.28 Quit bertrik (Remote host closed the connection) 23.35.00 # Hello, I'm experimenting with addons in rockdoom and I keep encountering the same error. While Doom runs fine, my addon does not. I downloaded the .wad I wanted and put it in .rockbox/doom/addons. 23.35.18 # I loaded Rockdoom, selected my addon, and pressed play game. Every time I do this, the lines of text flash as usual, but it says in one of them that something is wrong with my shareware and then it gets stuck on a line about sprites, duplicating it every second until it's been about 30 seconds, then rockdoom quits. 23.35.45 # Does anyone know what could be the issue? 23.38.37 Quit cmhobbs (Ping timeout: 252 seconds) 23.39.46 *** Saving seen data "./dancer.seen" 23.43.33 Join JdGordon [0] (cb1380e2@rockbox/developer/JdGordon) 23.43.43 # Water: Yes the Fuze+ does frequency scaling. You probably remember this (Tue Sep 4 00:35:58 2012 "imx233: disable cpu frequency scaling") it was disabled but on (Fri Jan 18 18:59:08 2013 "imx233: enable cpu frequency scaling on all targets") it was enabled 23.44.21 # I figured I had a bad .wad so I found another, but I got the same result. Where did I go wrong? 23.47.05 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 23.56.05 Join kugel [0] (~kugel@rockbox/developer/kugel)