--- Log for 02.12.113 Server: holmes.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 13 hours ago 00.11.19 # Build Server message: 3Build round completed after 698 seconds. 00.20.16 Quit pamaury (Ping timeout: 265 seconds) 00.33.39 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 00.35.03 *** Saving seen data "./dancer.seen" 00.43.40 Join solrize [0] (~solrize@unaffiliated/solrize) 00.47.24 Join SYSTEM_ [0] (~chatzilla@adsl-99-120-25-217.dsl.dytnoh.sbcglobal.net) 00.47.37 Nick SYSTEM_ is now known as Water (~chatzilla@adsl-99-120-25-217.dsl.dytnoh.sbcglobal.net) 00.47.54 Quit Water (Client Quit) 00.50.20 Quit ender` (Quit: Any technology distinguishable from magic is insufficiently advanced. -- Gehm's Corollary to Clarke's Third Law) 01.08.24 Join Guest11127 [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net) 01.10.34 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 01.30.53 Join treaki_ [0] (48330dfd0e@p4FF4A473.dip0.t-ipconnect.de) 01.33.22 Quit treaki__ (Ping timeout: 246 seconds) 02.14.20 Quit amayer (Quit: Leaving) 02.35.07 *** Saving seen data "./dancer.seen" 03.09.35 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131125215016]) 03.52.08 Quit Mir (Read error: Connection reset by peer) 04.35.08 *** Saving seen data "./dancer.seen" 04.35.23 Join Mir [0] (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) 04.49.10 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.49.10 Quit amiconn (Disconnected by services) 04.49.10 Quit pixelma (Disconnected by services) 04.49.10 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.49.13 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.49.13 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 05.56.02 Quit TheSeven (Disconnected by services) 05.56.16 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.15.38 Quit nosa-j (Ping timeout: 260 seconds) 06.17.53 Join nosa-j [0] (~m00k@66.233.224.206) 06.20.23 Part anewuser 06.35.10 *** Saving seen data "./dancer.seen" 07.04.56 Join mortalis [0] (~kvirc@213.33.220.118) 07.43.19 Quit solrize (Remote host closed the connection) 07.46.41 Join solrize [0] (~solrize@unaffiliated/solrize) 07.54.04 Quit solrize (Ping timeout: 272 seconds) 07.55.36 Quit [Saint] (Remote host closed the connection) 07.56.49 Join [Saint] [0] (~saint@rockbox/user/saint) 07.58.57 Join solrize [0] (~solrize@unaffiliated/solrize) 08.23.12 Join ender` [0] (krneki@foo.eternallybored.org) 08.25.31 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.26.25 Quit dfkt (Remote host closed the connection) 08.26.34 Join dfkt [0] (OxO29A@unaffiliated/dfkt) 08.29.04 Join einhirn [0] (~Miranda@2001:638:605:4:9488:6ea6:8781:5fc7) 08.35.11 *** Saving seen data "./dancer.seen" 08.43.25 Quit solrize (Ping timeout: 252 seconds) 08.58.01 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 08.58.26 Join LinusN [0] (linus@giant.haxx.se) 09.01.51 Join bertrik_ [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 09.01.51 Quit bertrik_ (Changing host) 09.01.51 Join bertrik_ [0] (~quassel@rockbox/developer/bertrik) 09.02.28 Quit nosa-j (Ping timeout: 272 seconds) 09.02.38 Quit bertrik (Ping timeout: 260 seconds) 09.05.07 Join nosa-j [0] (~m00k@66.233.224.206) 09.07.14 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 09.08.43 Quit dfkt (Ping timeout: 252 seconds) 09.14.31 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.16.17 Join petur [0] (5bb7304d@rockbox/developer/petur) 09.28.54 Quit bertrik_ (Ping timeout: 245 seconds) 09.37.18 Quit JdGordon| (Ping timeout: 272 seconds) 09.38.32 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.45.28 Join solrize [0] (solrize@2604:180:1::4d3d:d2e0) 09.45.30 Quit solrize (Changing host) 09.45.30 Join solrize [0] (solrize@unaffiliated/solrize) 10.03.07 Join rela [0] (~x@pdpc/supporter/active/rela) 10.03.26 Quit rela (Client Quit) 10.29.45 Quit nosa-j (Ping timeout: 246 seconds) 10.35.14 Join nosa-j [0] (~m00k@66.233.224.206) 10.35.15 *** Saving seen data "./dancer.seen" 10.39.41 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 10.47.05 Join rela [0] (~x@pdpc/supporter/active/rela) 10.47.14 Quit nosa-j (Ping timeout: 260 seconds) 10.54.39 Join nosa-j [0] (~m00k@66.233.224.206) 10.59.33 Quit nosa-j (Ping timeout: 245 seconds) 11.03.17 Join nosa-j [0] (~m00k@66.233.224.206) 11.10.14 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.20.02 Join lebellium [0] (~chatzilla@80.215.204.38) 11.37.53 Quit dfkt_ (Ping timeout: 265 seconds) 11.39.15 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.40.27 Quit krnlyng (Ping timeout: 246 seconds) 11.54.50 # good, the fuze+ power regression is now solved 11.57.58 # there was only one responsible commit? 11.59.12 # pamaury: nice! 12.00.13 Quit wodz (Ping timeout: 264 seconds) 12.00.46 # yeah, I made the battery bench and I have the same time with HEAD + reverted commit and with the revision with the best known running time 12.00.59 # I only get 37h because my battery is a bit old now 12.01.15 # one good thing done, thanks 12.12.25 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 12.20.16 # would someone object against converting battery_bench to pluginlib or at least using pluginlib as a fallback if no other keymap is defined ? that seems like a reasonable solution at at the moment 12.24.30 Quit nosa-j (Ping timeout: 272 seconds) 12.24.41 # It would be great if ALL test plugins use pluginlib only 12.25.12 # and also it would be great to have easy switch to build test plugins only as well 12.26.41 # or many it could be great if all or most plugins could use pluginlib as a fallback 12.26.55 Join nosa-j [0] (~m00k@66.233.224.206) 12.27.01 # pamaury: afaik that is impossible 12.27.02 # many one couldn't use all the feature but that would greatly simplify the work 12.27.16 # or display a message saying that's impossible 12.27.31 # because at the moment, you cannot ship *any* plugin without fixing all of them... 12.28.03 # Yeah. Another soultion would be to have per target whitelist 12.28.21 # I will send a mail to see 12.32.20 # pamaury: good job! Is the offending commit Fuze+ only? 12.32.30 Quit nosa-j (Ping timeout: 265 seconds) 12.32.37 # (and, what was it?) 12.32.55 # copper: When the sd is in TRAN state it cannot enter sleep mode 12.32.57 # no it's imx233 generic 12.33.15 # wodz: and what's that in english? :P 12.33.56 # copper: SD card has a bunch of states it can be in. One of them is TRAN state which is the state in which you conduct actual transfers from/to card 12.34.25 Join nosa-j [0] (~m00k@66.233.224.206) 12.34.29 # copper: If you keep card in TRAN state, card's internal controller doesn't allow to enter sleep mode 12.34.31 # but I ran my benchmarks without an SD card inserted 12.34.41 # copper: internal flash is sd also 12.34.53 # internal flash is mmc, which is the same 12.34.58 # I see 12.35.15 # so that wouldn't affect the iPod Classic, I take it? 12.35.19 *** Saving seen data "./dancer.seen" 12.35.29 # no :( 12.35.30 # this particular commit cannot 12.35.33 # ok 12.36.05 # copper: if you have a good commit and a bad commit for the classic, I can lookup the commit list (if it's not too big) and tell you if I see anything suspicious but that's all 12.36.24 # thanks, but I only tried two builds a year apart 12.36.32 # I have to do more tests, I'm curious whether we can save more powers by 1) use the sleep/wake command on MMC 2) powering down SD/MMC completely after some inactivity 12.37.11 # copper: I guess the classic doesn't have many commits but if you could, say, reduce this a bit, maybe to six months that would help a lot 12.37.27 # noted 12.37.29 # pamaury: Did you finish benchmark/bisecting? Are you confident there are no other factors? 12.37.55 # pamaury: You latest bench didn't hit 40+ mark 12.39.29 # copper benchmarked a commit and got 41h, on mine the same commit gives 37h and I get 37h with HEAD 12.40.10 # If someone with a brand new Fuze+ wants to benchmark HEAD to double-check he is welcome 12.40.41 # pamaury: My point is that the 'very old' and HEAD seems to not be inline still 12.44.52 # pamaury: absolutely not! pluginlib actions is preferred 12.46.08 # pamaury, wodz: perhaps the plugins configure could be made to work like "all,none,pla" (where pla compiles/ships only those that use pluginlib actions) 12.46.44 Join krnlyng [0] (~liar@83.175.90.24) 12.47.11 # kugel: that is one of possible solution 12.47.33 # kugel: But from my perspective for the initial port days it would be easier to have whitelist file 12.50.13 Quit nosa-j (Ping timeout: 240 seconds) 12.53.01 # kugel: what do you mean by "absolutely not" ? to what are you referring ? 12.53.14 # "would someone object against converting battery_bench to pluginlib" 12.53.20 # ah yeah :) 12.54.36 # I've sent a mail to rockbox-dev about this issue 12.54.38 # wodz: why? in the initial days you create a single pla and disable all other plugins that require more work 12.55.42 Join Karrde- [0] (alucard@karrde.kiserai.net) 12.56.14 Quit rela (Read error: Connection reset by peer) 12.56.18 Join Zagor_ [242] (~bjst@rockbox/developer/Zagor) 12.56.27 Join nosa-j [0] (~m00k@66.233.224.206) 12.56.33 # kugel: It is cumbersome when you start do define more complicated keymaps and you have to either 1) define fake keymaps for all or 2) compile the plugin you are working on by hand 12.56.49 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 12.56.56 # and hacking in SOURCES is not great either 12.57.38 Quit Karrde (Ping timeout: 240 seconds) 12.57.40 Quit Zagor (Ping timeout: 240 seconds) 12.58.13 Quit solrize (Ping timeout: 240 seconds) 12.58.51 Join solrize [0] (solrize@2604:180:1::4d3d:d2e0) 12.58.51 Quit solrize (Changing host) 12.58.51 Join solrize [0] (solrize@unaffiliated/solrize) 13.00.42 # hm, does anyone know speex? 13.01.08 # it seems to trip over chunked talk clips 13.01.24 Quit ps-auxw (Ping timeout: 245 seconds) 13.02.50 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 13.08.12 Quit TBCOOL (Ping timeout: 272 seconds) 13.11.47 # pamaury: NWZ-E340 and 440 are very close! The few differences spotted: miniUSB (E340) vs WM-Port (E440), voice and FM recording on E440, more video formats supported on E440 (H.264, MPEG-4). 13.12.48 Nick Zagor_ is now known as Zagor (~bjst@rockbox/developer/Zagor) 13.12.49 # quite possible, however the E440 is quite boring because it uses raw NAND and I haven't reverse the FTL yet 13.13.10 # Looks like the E340 has been released in Russia only, but I'm not sure 13.13.27 # But they have exactly the same design, I don't know why there are not in the same series 13.13.59 # crazy Sony marketing ^^ 13.16.13 # The cube plugin could clearly be converted to pluginlib 13.16.44 # it only has one more action than standard plugin has which could either be not mapped (the "pause" mode) or mapped to repeated select (which could be "mode") 13.17.32 # I'm sure chessclock too can be mapped to pluginlib 13.18.32 Join stoyan [0] (~io-headqu@77.70.0.98) 13.18.56 Quit stoyan (Client Quit) 13.21.40 Quit ikeboy (Quit: ikeboy) 13.23.44 # pamaury: is g#490 ready to be committed? 13.23.46 # 3Gerrit review #490 at http://gerrit.rockbox.org/r/490 : 3 by Lorenzo Miori (changes/90/490/15) 13.27.08 # lebellium: undo chmod in powermgmt-imx233.c 13.29.45 # mortalis: I assume you are talking to pamaury or lorenzo. I have nothing to do with that :P 13.41.14 Join rela [0] (~x@pdpc/supporter/active/rela) 14.07.00 # yeah it's lorenzo92 who should do that 14.07.12 Quit rela (Read error: Connection reset by peer) 14.07.25 # lebellium: nand is not working on the z5 yet. We will commit this one very soon but it's basically not working without hacks 14.08.32 # pamaury: I know that, Rockbox has been running on my Z5 for 1 year now. But it needs to be plugged to computer :) 14.10.10 Quit ps-auxw (Ping timeout: 260 seconds) 14.11.45 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 14.23.54 Quit cmhobbs (Ping timeout: 245 seconds) 14.29.12 Quit chrisjj (Quit: Page closed) 14.30.53 Join TBCOOL [0] (~tb@c-2691e555.09-273-73746f44.cust.bredbandsbolaget.se) 14.35.22 *** Saving seen data "./dancer.seen" 14.38.25 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 14.39.29 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.47.17 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 14.56.41 # hum, providing pluginlib fallback will prove more difficult than expected, there is a *wide* variety in how plugins handle butttons 14.56.49 # I even discovered button_status() ! 14.58.41 # the main problem is that most plugins assume buttons form a keymap 14.58.47 # which is not true with pluginlib 14.59.18 # so basically I would need to enhance pluginlib with a "fake button" API which behaves exactly like buttons: buttons are bitmak, repeat is part of the bitmask, so on 15.04.36 Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) 15.11.04 # pamaury: the easy cases have been converted already :p 15.12.33 Join Narod [0] (Narod@p5DDDB44D.dip0.t-ipconnect.de) 15.14.45 # kugel: well yeah, I guess it's easier to just replace some with pluginlib entirely rather than provide pluginlib as replacement 15.14.59 # on the other hand, provide pluginlib as fallback avoids changing much of the code if done properly 15.15.05 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 15.15.49 Quit wodz (Quit: Leaving) 15.16.07 Quit petur (Quit: Page closed) 15.22.49 # pamaury: if pluginlib can cover all functionality the legacy keymap should be dropped 15.24.29 # sometimes it can cover and sometimes it's borderline (cf my mail) 15.24.36 Quit cmhobbs (Ping timeout: 248 seconds) 15.25.54 # pamaury: btw, metronome.rock has a case where some targets add extra buttons (outside PLA) while the main buttons are handled via PLA 15.27.15 # you can create button maps on top of PLA so that it will chain down to the PLA context. these extra maps can be target specific 15.28.22 # ah interesting, seems much better this way 15.29.28 Quit chrisjj (Quit: Page closed) 15.29.30 # There something unclear about button handling: if pluginlib action is used and there is a system event, is it returned by the function ? or ignored ? or processed with default handler ? 15.30.00 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 15.30.33 # Out of interest, can anyone recall the cause of the big drop in ram suage at SVN v~27600? http://img18.imageshack.us/img18/6822/wxcq.png 15.31.16 # At random I would say buflib, ie that's not an actual decrease, it is dynamically allocated 15.31.32 # or any dynamical use of the audio buf actually 15.31.50 Quit ikeboy (Remote host closed the connection) 15.31.57 # chrisjj: did you try the build I posted on the forum ? did it change anything on your device ? 15.32.16 # chrisjj: by the way, I don't see how the bootloader could have charged before, it was disabled on the stmp3700 ! 15.34.40 # Trying now... 15.34.52 # pamaury: you have to call to the default handler, like with get_action in core 15.35.15 # Re the bootload, I have on ZEN charging right here on V1 Beta. 15.35.28 # plugin_ctr0.c provides a convinience wrapper, though, to quit the plugin for POWER_OFF and USB_CONNECTED 15.35.46 # see metronome.c:983 15.36.13 # ok I'll have a look at this later 15.36.39 # It says "Charging status: discharging" but "Battery: xx%" is rises and thn RB Settings, System, Info confirms. 15.37.47 # hum, ok that's by luck then because rockbox doesn't touch any power setting in the V1Beta bootloader and Creative must setup charging. Anyway now rockbox does handling charging correctly 15.37.54 # *handle 15.43.25 # "that's by luck" :) 15.46.04 # OK, re your added RB-own charging on 3f55f01-131201 , yes it is working. Well Done again Amaury! 15.49.17 # chrisjj: tentative lcd fix: g#688 15.49.18 # 3Gerrit review #688 at http://gerrit.rockbox.org/r/688 : 3 by Amaury Pouly (changes/88/688/1) 15.53.24 # I don't have any issue anymore with my ZEN lcd so it's hard to debug, maybe there are several variants of the ZEN but I couldn't find any trace of it in the OF disassembly either 15.54.08 Quit nosa-j (Ping timeout: 272 seconds) 15.56.13 Join nosa-j [0] (~m00k@66.233.224.206) 15.58.42 # Fingers crossed for g#688 imx233_dma_reset_channel :) I'll test this as soon as it reaches the daily build. Thanks. 15.58.43 # 3Gerrit review #688 at http://gerrit.rockbox.org/r/688 : 3 by Amaury Pouly (changes/88/688/1) 15.59.14 # pamaury: I remember the sansa e250 v1 boards and e250 v2 baords had similar LCD troubles if not exactly the same "white screen of death" 15.59.26 # P, when you say "I don't have any issue anymore with my ZEN lcd", do you mean that g#688 has fixed the black screen after bootloader, for you? 15.59.27 # 3Gerrit review #688 at http://gerrit.rockbox.org/r/688 : 3ZEN: new try at fixing the lcd by Amaury Pouly (changes/88/688/1) 16.00.10 # foolsh: the ZEN WSoD is gone TMK. We've got just a BSoD. 16.00.48 # chrisjj: I don't plan to commit g#688 unless someone reports any success with it 16.00.49 # 3Gerrit review #688 at http://gerrit.rockbox.org/r/688 : 3ZEN: new try at fixing the lcd by Amaury Pouly (changes/88/688/1) 16.01.41 # pamaury: I don't see any ZEN beta testers with a build system. 16.04.07 # chrisjj: even with HEAD I don't have any issue 16.04.26 # I can upload a build corresponding to this gerrit patch 16.05.02 # you still have troubles with HEAD right ? 16.05.53 # Most kind. I'll wait for that build. BYW, FYI re your "did you try the build I posted on the forum" I didn't see you post that on the forum. I got it later from Daily Builds. 16.06.58 Join lorenzo92 [0] (2e121b3e@gateway/web/freenode/ip.46.18.27.62) 16.07.14 # chrisjj: https://www.dropbox.com/s/scx4ya1jj1hgvq1/rockbox-zen-lcd-fix.zip 16.08.01 # Taking it now - thanks. 16.13.05 # Re HEAD, I've not tried HEAD specifically, but I do still have trouble with that latest daily build. 16.14.42 # ok, then tell me when you have tried with the build from my dropbox, let's hope 16.14.58 # Sorry to report rockbox-zen-lcd-fix.zip 9ff1819-131202 shows no improvement to the LCD BSoD. 16.15.54 # pamaury, to save your time, I suggest you sync your test with mine, and if that fails, I mail you a unit showing the test fail. 16.16.17 # well my tests are pretty actually: they all work ! 16.16.23 # *pretty easy 16.16.38 # What is your test procedure: reboot until it BSoD ? 16.16.45 # Well, that shows those tests are not good enough :) 16.16.59 # not necessarily, units may vary from each other 16.17.18 # Yes my test procedure is reboot until BSoD. But perhaps sensitive to conditions. 16.17.24 Quit nosa-j (Ping timeout: 248 seconds) 16.17.53 # and you confirm it is not the bootloader which fails 16.18.12 Join nosa-j [0] (~m00k@66.233.224.206) 16.18.36 # Hang on, that last test was with the V1Beta bootloader. Trying again with V1Beta2... 16.18.59 # pamaury, what model is yout ZEN? 4GB? 8Gb? 16.19.12 # 2GB 16.19.52 # OK, I'll add a 2Gb to the suite. 16.22.49 # Meanwhile, 4Gb is the nearest I have to yours, so retesting with that. 16.23.24 # it seems that git code viewer strips last empty line...does someone confirm? 16.23.36 # I don't think the storage size is relevant, there could many more differences like the SoC ROM version for example 16.24.18 # I will add a debug screen to display the exact chip version, that's a useful information 16.25.00 Quit [Saint] (Ping timeout: 246 seconds) 16.25.11 # Sorry, again no improvement - BSoD remains Conditions: ZEN 4Gb "J"; Bootloader version V1Beta2_fb8faa1; RB version rockbox-zen-lcd-fix.zip 9ff1819-131202; default settings. 16.25.54 # so the bootloader displays a few lines of text and then you get a BSoD ? 16.26.07 # Useful indeed. I'll wait for that, and then we'll resync the test. 16.26.25 # do you get a BSoD in the bootloader itself sometimes ? (ie the device stays black and doesn't even display the few lines of text) 16.30.21 Join lebellium_ [0] (~chatzilla@80.215.204.38) 16.30.23 # Have I seen a BSoD after the CREATIVE logo but before "Boot version:... "? No never (in thousands of cycles). 16.31.28 # hum interesting 16.31.57 # Another thought about conditions, could OF version be relevant? 16.32.36 Quit Zagor (Quit: Clint excited) 16.33.13 Quit lebellium (Ping timeout: 246 seconds) 16.33.16 Nick lebellium_ is now known as lebellium (~chatzilla@80.215.204.38) 16.33.27 # Probably not, however the fact that it never fails in the BL is a very interesting fact 16.33.47 Join [Saint] [0] (~saint@rockbox/user/saint) 16.34.10 # I will need to verify something, I have a new idea 16.34.34 # Interesting agreed, since lcd.h is used in both. 16.35.03 # But re OF, why "Probably not" not "Definitely not"? 16.35.09 Quit kevku (Ping timeout: 245 seconds) 16.35.25 *** Saving seen data "./dancer.seen" 16.35.36 # Probably not as in "No except if you already had BSoD in OF" 16.36.26 # Every unit in this test suite is certified free of OF BSoD! 16.37.19 # so definitely not 16.39.00 # chrisjj: could you do me a favor and try a new bootloader: https://www.dropbox.com/s/lylxog0szynnxtm/firmware-zen-v3.nk 16.39.17 # basically this is the current bootloader (HEAD as of now) 16.39.27 # Just use it normally, torture it as you wish 16.40.11 # And tell me if you manage to get a BSoD in the bootloader, ie you see the Creative logo but not "Boot version: ..." 16.42.13 Quit mortalis (Ping timeout: 264 seconds) 16.43.19 # Trying bl v3 now... 16.44.04 Quit lebellium (Ping timeout: 246 seconds) 16.45.32 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 16.49.05 Join lebellium [0] (~chatzilla@80.215.204.38) 16.49.13 # No change so far - BSoD remains. Conditions: ZEN 4Gb "J"; Bootloader version V1Beta3_3f555f01; RB version rockbox-zen-lcd-fix.zip 9ff1819-131202; default settings. 16.50.32 # FAOD: No BSoD before bootloader ... so far. I will continue testing. GTG now. 17.04.30 Part LinusN 17.07.49 Quit shamus (Ping timeout: 246 seconds) 17.08.32 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 17.15.26 Join rela [0] (~x@p57B7428D.dip0.t-ipconnect.de) 17.15.28 Quit rela (Changing host) 17.15.28 Join rela [0] (~x@pdpc/supporter/active/rela) 17.17.35 Quit lorenzo92 (Ping timeout: 250 seconds) 17.24.08 Join solrize_ [0] (solrize@2604:180:1::4d3d:d2e0) 17.24.08 Quit solrize_ (Changing host) 17.24.08 Join solrize_ [0] (solrize@unaffiliated/solrize) 17.26.38 Quit solrize (Ping timeout: 260 seconds) 17.29.34 Quit solrize_ (Ping timeout: 246 seconds) 17.30.29 Quit pixelma (Quit: No Ping reply in 120 seconds.) 17.30.55 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 17.33.04 # pamaury: Even though I don't have the hardware to test them, if the simulators are working I can help with some keymaps. I need the experience anyway. 17.33.38 Join solrize_ [0] (solrize@2604:180:1::4d3d:d2e0) 17.33.38 Quit solrize_ (Changing host) 17.33.38 Join solrize_ [0] (solrize@unaffiliated/solrize) 17.39.18 # foolsh: I am in the process of converting some plugins to our pluginlib action framework first, but after that you can definitely give a hand 17.41.36 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 17.54.41 # pamaury: Cool, can't wait 17.57.52 Join solrize__ [0] (solrize@2604:180:1::4d3d:d2e0) 17.58.37 Quit solrize_ (Ping timeout: 246 seconds) 17.59.32 Quit ikeboy (Quit: ikeboy) 17.59.46 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.13.19 Quit Elfish (Ping timeout: 246 seconds) 18.13.33 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 18.15.15 # after the kind of "desaster" (too many contexts with increasing amount of overlaps where you couldn't tell if you break another target when trying to fix one) with the first incarnation of pluginlib actions I'm very sceptical about this :\ 18.17.13 Join pretty_function [0] (~sigBART@123.252.215.137) 18.20.19 Quit Elfish (Ping timeout: 246 seconds) 18.20.24 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 18.21.37 # pixelma: I don't know if you had a look at the plugins recently but many of them could just use pluginlib action, they don't need any more button or just one extra button 18.22.12 # have specific keymap for them is a waste of time, and a maintenance burden 18.22.48 # and my initial approach is to say that we could (and should) provide a reasonable pluginlib action fallback when it's possible to help new ports 18.24.40 # and it's not only about this, it's about the more general question of how can we select only a subset of plugins to provide for a particular target because we are missing keymaps for the others 18.26.47 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.27.30 # not sure but not being able to fix the keymap for any one existing target without the often well hidden possibility to break others was a maintenance burden too (as I said that was the problem with the first version of this). Since I had a target with one of the least possible buttons and combos (the Ondio), I keep being sceptical. E.g. if you now say "some only need one additional button" I'm not sure if that's possible on all targets. 18.27.47 Join krabador [0] (~krabador_@unaffiliated/krabador) 18.29.04 # just saying, cleaning up the code and unifying the way plugins handle buttons (even if it's not PLA) is still a good idea I guess. 18.35.28 *** Saving seen data "./dancer.seen" 18.36.28 Join Szczepancio [0] (5309df3b@gateway/web/freenode/ip.83.9.223.59) 18.37.01 # pamaury: Hi, is there any progress on e370 (that non-linux based mp4)? 18.37.39 # Szczepancio: there is new keymapping and improved battery life, check the latest builds :) 18.38.59 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 18.40.46 # lebellium: The plugin's are not working, still? 18.41.23 # are still not working*? 18.43.09 # no 18.45.11 # They won't be working as long as the keymapping is not done 18.45.29 # pamaury has probably not much time for that and I'm not interested doing it 18.47.26 # lebellium: meh, sounds shitty. 18.48.34 # which plugin do you need? 18.50.05 # pixelma: My proposition at the moment is the following: 18.50.06 # 1) keep the current keymap for all plugins 18.50.06 # 2) enhance pluginlib action to provide a button-like interface 18.50.06 DBUG Enqueued KICK pamaury 18.50.06 # 3) in all plugins where it's possible, provide a default keymap based on this new interface 18.50.06 # That way we do not break any target and we provide reasonable default for the new ones. At the same time it allows one to cleanup the code 18.51.48 # what do you mean with "button-like interface"? 18.53.16 # the current pluginlib action returns things like PLA_SELECT_REPEAT which obviously doesn't work when the code is matching for button | BUTTON_REPEAT. So the idea is to have a little wrapper to translante X_REPEAT to X | BUTTON_REPEAT and X_REL to X | BUTTON_REL. that way the same code ca handle both normal button and pluginlib action 18.54.50 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.59.16 # lebellium: It should be nice to play some games on it, but I found that it having small screen enough for plugin's. 18.59.30 # But my sansa clip zip was good enough to play mario, by the way. 18.59.47 # Also, doom and other's. 19.00.59 # ok 19.01.08 # feel free to set the keymapping then :) 19.03.41 # lebellium: i know i can do it, but... i still waiting for someone to hack a e470. It's my main player, so u know, i can do with it everything. What I said, e380 is my dad mp4, and i don't wanna do not anything with it. I can exchange, but I think e470 is better for me. 19.04.06 # (Bigger screen, etc.) 19.04.22 # I asked for progress on e370 because i am partially interested in it, but not fully. 19.07.35 # ok 19.09.15 # I wanted to buy a E474 but the seller did not reply and actually I don't have much money right now. pamaury was also interested in buying one but he's currently abroad 19.09.41 # I tried on leboncoin but didn't an answer 19.09.50 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 19.10.35 # lebellium: I should donate you to get faster work, but I am so young and i don't spend money on internet thing's, u know. 19.11.15 # pamaury: the one in Nantes? we asked the same guy I think :D I could have asked the other seller in Paris but I should not spend too much right now 19.12.52 # lebellium: I don't remember, anyway I didn't an answer 19.13.04 # Szczepancio: I'm not sure that would really speed up things. pamaury is working on 36 000 players at the same time, so he doesn't have much time :D 19.13.25 # lebellium: That not an work, that a passion really :D 19.13.33 # That not hobby* 19.15.15 # lebellium: Do us other work than RE? :>? 19.15.31 # Sometimes I think about just stopping but no other project is as cool :) 19.15.44 # OSDev is cool :) 19.16.06 # But it's hard and developer do at it slow progress. 19.16.36 # Also, finding exploit at psp games to get usermode access on ps vita can be cool. 19.17.37 # The only projects I find very cool are the graphic cards RE but really that's not rewarding to work against manufacturers which try so hard to f*** you 19.19.07 Quit pretty_function (Remote host closed the connection) 19.19.17 # lebellium: do you know the nwz-e585 ? 19.19.29 # pamaury: yes 19.19.58 # what is your opinion ? 19.21.06 # It's the very first non-Android Sony player to support FLAC! :) 19.21.54 # up to 77hrs audio playback 19.22.06 # Looks great 19.22.13 # but the price.... 19.22.50 # there is one at 50€ on leboncoin 19.22.59 # 16GB 19.23.27 # whaouh! 19.23.47 # if you want it, ask now or I might :p 19.24.42 # arf scratches 19.24.46 # I hate scratches 19.25.25 Quit Szczepancio (Ping timeout: 250 seconds) 19.26.56 # I let it to you :) 19.27.01 # everyone hates scratches ;) 19.27.10 # ok 19.28.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 19.35.07 Join lebellium_ [0] (~chatzilla@80.215.32.217) 19.36.50 # even though there are a few scratches, 50€ is a very good deal for it. But I don't have money right now, and I don't really need the Noice Cancelling since I wouldn't use the Sony earphones. 19.37.54 # the E475 would be enough for me 19.38.01 Quit lebellium (Ping timeout: 246 seconds) 19.38.03 Nick lebellium_ is now known as lebellium (~chatzilla@80.215.32.217) 19.39.36 Quit GodEater (Ping timeout: 272 seconds) 19.41.30 Join lorenzo92 [0] (~chatzilla@46.18.27.62) 19.42.15 # if anyone wants to review g#490 before it goes it, it's right now 19.42.16 # 3Gerrit review #490 at http://gerrit.rockbox.org/r/490 : 3Initial commit for the YP-Z5 port by Lorenzo Miori (changes/90/490/16) 19.43.09 Join GodEater [0] (~whoknows@176.26.0.97) 19.43.09 Quit GodEater (Changing host) 19.43.09 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 19.43.37 Quit Elfish (Ping timeout: 246 seconds) 19.44.47 Join alexisisis [0] (~alex@186.176.51.35) 19.44.50 Join lebellium_ [0] (~chatzilla@80.215.8.170) 19.46.04 Quit lebellium (Ping timeout: 246 seconds) 19.46.15 Nick lebellium_ is now known as lebellium (~chatzilla@80.215.8.170) 19.49.00 # Hi everyone. I trying scrobble my scobble.log from my Clip+ with qtscrobbler in linux. QTScrobbler isn't allowing me to load the log though, I can browse to the device and can see the log but it is greyed out and won't allow me to select it. I'm not sure what I'm doing wrong and don't really know where else to ask about it so any help would be very much appreciated. 19.50.02 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 19.50.05 # Does drag and drop to your HD work? 19.50.12 # I'm sorry, I'm an idiot, I thought it was asking to locate the log, not the device 19.50.37 # chrisjj, I was going to try that but I just realized what it was asking for and now it's loaded the log fine 19.51.06 # You're not an idiot. That's a reasonable thing to expect - you might have two logs! 19.51.11 # Glad you're fixed. 19.51.47 # that's true! Well all good now, thanks anyway. 19.52.46 Join lebellium_ [0] (~chatzilla@80.215.33.153) 19.54.04 Quit lebellium (Ping timeout: 246 seconds) 19.54.11 Nick lebellium_ is now known as lebellium (~chatzilla@80.215.33.153) 19.59.44 # Build Server message: 3New build round started. Revision 9dab30a, 243 builds, 35 clients. 20.00.01 Quit lebellium (Ping timeout: 246 seconds) 20.04.04 # Build Server message: 3Build round completed after 260 seconds. 20.06.21 Quit solrize__ (Remote host closed the connection) 20.06.38 Join solrize__ [0] (solrize@2604:180:1::4d3d:d2e0) 20.10.17 # Build Server message: 3New build round started. Revision 23c6421, 243 builds, 35 clients. 20.11.36 Quit gelraen (Ping timeout: 264 seconds) 20.14.05 # Build Server message: 3Build round completed after 228 seconds. 20.17.28 Join toehser [0] (~tom@Connqueror.Toms.NET) 20.20.09 Quit SuperBrainAK (Quit: you broke it :P) 20.21.35 Join SuperBrainAK [0] (~andy@2001:470:8:a61::5f92:59a1) 20.21.59 # Build Server message: 3New build round started. Revision 15155ed, 243 builds, 35 clients. 20.22.30 Quit alexisisis (Remote host closed the connection) 20.25.26 Quit fs-bluebot (Remote host closed the connection) 20.25.42 Join fs-bluebot [0] (~fs-bluebo@g224239121.adsl.alicedsl.de) 20.25.52 # Build Server message: 3Build round completed after 233 seconds. 20.34.51 # Neither %?pv<|dr(1,1,1,1)||> nor %?if(%pv,<,0) does what I expect - which would be the rectangle appearing/disappearing as the volume passes 0db - but %?if(%pv,<,0)<%Vd(x)|%Vd(y)> DOES work - is this a bug? Something special about drawRectangle? Something I'm conceptually missing? Note, it _will_ draw the rectangle when it goes to the next song... or at some point... but not real-time, the way it will with the views... what am I misunders 20.35.10 Quit SuperBrainAK (Ping timeout: 260 seconds) 20.35.31 *** Saving seen data "./dancer.seen" 20.38.57 Quit rela (Read error: Connection reset by peer) 20.40.36 Join SuperBrainAK [0] (~andy@2001:470:8:a61::5f92:59a1) 20.44.01 # toehser: why so many ||| in the first example? 20.44.09 Join lebellium [0] (~chatzilla@80.215.8.203) 20.44.33 # what about %?if(%pv,<,0) 20.44.55 # anyway, using viewports is better 20.45.19 # It has the weird lag - doesn't take effect right when the volume changes - but does when I skip the song to next 20.45.31 # with viewports? 20.45.47 # The ||| are because I want the symbol on negative, but not mute or 0 or + 20.46.06 # viewports work if I only do the dr once, first, and swap them 20.46.31 # so with defining 2 viewports and doing <%Vd(x)|%Vd(y)> works... 20.46.47 # but doing directly _doesn't_ 20.47.03 # as if it doesn't think the dr needs to be actually executed when it changes 20.47.07 # or something with refresh 20.47.41 # it works "late"... that is, I change the volume, it doesn't seem to take effect, but then skipping to next song or other actions, it appears... 20.48.21 # Build Server message: 3New build round started. Revision 1deab73, 243 builds, 35 clients. 20.49.24 # pamaury: thanks for merging and for all the help :) 20.49.42 # we are not done yet ;) 20.50.04 Quit fs-bluebot (Remote host closed the connection) 20.53.44 Join fs-bluebot [0] (~fs-bluebo@g224239121.adsl.alicedsl.de) 20.56.25 # lorenzo92: is there anything ypr0 related that I can have a look at? 20.58.04 Quit pamaury (Ping timeout: 245 seconds) 20.59.26 Quit efyx (Ping timeout: 260 seconds) 20.59.52 Join efyx [0] (~efyx@91.176.67.84) 21.00.19 # kugel: g#634 :D 21.00.21 # 3Gerrit review #634 at http://gerrit.rockbox.org/r/634 : 3 by Lorenzo Miori (changes/34/634/2) 21.02.17 Quit KotH (Ping timeout: 260 seconds) 21.02.28 Join KotH [0] (~attila@lou-outside.kinali.ch) 21.02.57 Join benedikt93_ [0] (~benedikt9@frbg-5d84e95d.pool.mediaWays.net) 21.03.26 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 21.06.16 Quit benedikt93 (Ping timeout: 242 seconds) 21.06.24 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.08.20 Quit benedikt93_ (Quit: Bye ;)) 21.09.05 Join Synergist [0] (~synfn@node1.customhost.org.uk) 21.09.05 Quit Synergist (Changing host) 21.09.05 Join Synergist [0] (~synfn@unaffiliated/synergist) 21.10.48 Quit synergst` (Ping timeout: 250 seconds) 21.10.50 Quit KotH (Ping timeout: 260 seconds) 21.11.14 Join alexisisis [0] (~alex@186.176.51.35) 21.11.53 Quit y4n (Quit: PANTS OFF!) 21.15.04 Quit krabador (Quit: Sto andando via) 21.16.52 Quit ikeboy (Remote host closed the connection) 21.17.17 Join KotH [0] (~attila@lou-outside.kinali.ch) 21.17.20 Join krabador [0] (~krabador_@unaffiliated/krabador) 21.24.58 Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) 21.36.06 Quit eyfour (Quit: WeeChat 0.3.7) 21.37.04 Join eyfour [0] (~eyfour@176.76.202.84.customer.cdi.no) 21.41.26 Quit solrize__ (Ping timeout: 260 seconds) 21.54.21 Quit alexisisis (Ping timeout: 246 seconds) 22.08.00 Quit bluebrother (Disconnected by services) 22.08.06 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.11.19 Join Narod- [0] (Narod@p5DDDB44D.dip0.t-ipconnect.de) 22.11.20 Quit fs-bluebot (Ping timeout: 272 seconds) 22.12.50 Join fs-bluebot [0] (~fs-bluebo@g226068030.adsl.alicedsl.de) 22.15.46 Quit onder` (Remote host closed the connection) 22.16.11 # g#689 Do other targets use a touchpad besides the fuzeplus? 22.16.12 # 3Gerrit review #689 at http://gerrit.rockbox.org/r/689 : 3Docs: Manual entry for touchpad sensitivity. by Benjamin Brown (changes/89/689/2) 22.16.55 # I see gigabeat in some places but I haven’t a real clue 22.17.52 # foolsh: the gigebeat has a sensitivity setting but it's not handled the same as the Fuze+ 22.18.19 # either it should be updated to use the same infrastructure or it uses another way, I don't remember 22.19.13 Join nosa [0] (~m00k@66.233.224.206) 22.19.19 # let me check this 22.19.44 # ok the gigebeat has a touchpad setting but which is boolean 22.20.36 Quit nosa-j (*.net *.split) 22.20.37 Quit Narod (*.net *.split) 22.20.37 Quit amayer (*.net *.split) 22.21.07 # it uses the same setting as the Fuze+ expect there are two modes: boolean (normal & high) and range (A..B where A and B are target specific, A=-25 and B=25 on the Fuze+) 22.22.36 Join bertrik_ [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 22.22.36 Quit bertrik_ (Changing host) 22.22.36 Join bertrik_ [0] (~quassel@rockbox/developer/bertrik) 22.22.49 Quit bertrik (Ping timeout: 246 seconds) 22.22.57 # Ok, I'll use the sim to help me flesh it out more. thanks 22.23.45 Quit n1s (Quit: Ex-Chat) 22.26.14 # If one day someone had told me there were such crazy backlight systems, I would not have believed it 22.26.23 Join amayer [0] (~amayer@mail.weberadvertising.com) 22.35.33 *** Saving seen data "./dancer.seen" 22.37.55 # pamaury: Is the gigabeat's bool (normal & high) setting an exported hardware function? Just a general question, since it's bit of a strange way to write it. 22.38.20 # yes, touchpad_set_sensitivity 22.38.53 # which in this case is in firmware/target/arm/s3c2400/gigabeat-fs/button-meg-fx.c 22.41.22 # I am not crazy, OLED displays don't have backlight right ? 22.43.31 # kugel: what lebellium pointed to you is legacy stuff, I had a more clean code BUT the result is the same 22.44.01 # what is the result? 22.44.03 # kugel: there is a bug in the kernel driver, so there is little chance to make it fully working without touching the kernel I fear 22.44.30 # the problem is that sound card is initialized only once. Either recording or playing works. 22.44.46 # did you look at the kernel driver code? 22.44.54 # so if you start recording, again playback is impossible and the other way round 22.45.21 # yes I guess i found the reason: but I'm unsure and I did not have much time to look at it unfortunately 22.45.50 # well, if we can identify the bug we can ship a fixed driver, like with radio 22.48.37 # hum 22.48.42 # i'm not sure we can 22.48.49 # it is not a module 22.48.58 # but perhaps i'm wrong and that could be done 22.49.43 # the module could perform some hacks to prevent the in kernel driver from being used i think 22.50.25 # what happened about your microsd work? 22.55.56 Join alexisisis [0] (~alex@186.176.51.35) 22.58.54 Quit kevku (Ping timeout: 260 seconds) 23.13.30 Join solrize__ [0] (solrize@2604:180:1::4d3d:d2e0) 23.19.11 Quit alexisisis (Remote host closed the connection) 23.20.21 Join alexisisis [0] (~alex@186.176.51.35) 23.25.41 Part alexisisis ("Leaving") 23.38.56 Quit Narod- () 23.42.30 Quit lorenzo92 (Remote host closed the connection) 23.43.44 # yeah lcd working on the sansa express 23.43.54 Join alexisisis [0] (~alex@186.176.51.35) 23.44.48 Part alexisisis 23.45.06 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.45.06 # * gevaerts considers asking if there are players pamaury is *not* working on :) 23.47.25 # I swear this is the last I have work in progress at the moment 23.47.32 # at least serious work in progress... 23.47.45 # and this one is very easy 23.48.22 # plus now one owns this player anymore so it's just for fun I guess 23.48.25 # *no one 23.48.54 # We need to keep up the tradition of supporting stuff you can't even get second-hand any more :) 23.50.30 # exactly 23.50.44 # I had to wait one year to see one second-hand so it clearly qualifies 23.51.02 # You probably got the very last one 23.51.14 Quit [Saint] (Remote host closed the connection) 23.53.32 # damn this SSD1303 display controller must have been designed by a devil 23.54.16 # seriously who organises the pixels in bank of 8 vertical pixels so that each byte represents 8 *vertical* pixels in a horizontal manner ?! 23.55.58 Join Horscht [0] (~Horscht@xbmc/user/horscht) 23.56.52 # and also who has the crazy idea to have N banks: the N-1 first one have 8 pixels whereas the last one has more ?! 23.58.02 Quit nosa (Ping timeout: 264 seconds) 23.58.25 Quit Horscht (Client Quit) 23.58.38 Join Horscht [0] (~Horscht@xbmc/user/horscht) 23.59.01 # pamaury: It's just like the tiling done in current GPUs :).