--- Log for 14.03.111 Server: anthony.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 13 hours ago 00.15.59 DEBUG EOF from server (Connection timed out) (snapshot: netstuff.c line 545) 00.15.59 *** Cleanup 00.15.59 *** Cleanup 00.15.59 *** Saving seen data "./dancer.seen" 00.15.59 *** Exit 00.16.01 *** Started Dancer V4.16 00.16.01 DEBUG connect(2) failed on socket 3 (Connection timed out) (snapshot: netstuff.c line 150) 00.16.01 *** Connected to irc.freenode.net on port 6667 00.16.01 *** Logfile for #rockbox started 00.19.15 Mode "logbot :+i" by logbot 00.19.16 Ctcp Version from frigg!~frigg@freenode/utility-bot/frigg 00.19.19 *** Server message 501: 'logbot :Unknown MODE flag' 00.19.19 Join logbot [0] (~rockbox@giant.haxx.se) 00.19.19 Join Zambezi [0] (Zulu@80.67.9.2) 00.19.19 Join olejorgenb [0] (bronner@caracal.stud.ntnu.no) 00.19.19 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 00.19.19 Join casainho [0] (~chatzilla@bl17-240-239.dsl.telepac.pt) 00.19.19 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 00.19.19 Join [Saint] [0] (S_a_i_n_t@203.184.0.30) 00.19.19 Join brightspark [0] (~spark@dhcp-128-146-122-43.osuwireless.ohio-state.edu) 00.19.19 Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) 00.19.19 Join evilnick [0] (18bcf602@rockbox/staff/evilnick) 00.19.19 Join Topy44 [0] (~Topy44@f048237196.adsl.alicedsl.de) 00.19.19 Join FoH [0] (~foh@adsl-71-69-118.bhm.bellsouth.net) 00.19.19 Join DerPapst [0] (~Alexander@p5DE5A5DD.dip.t-dialin.net) 00.19.19 Join CaptainKwel [0] (~jason@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 00.19.19 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 00.19.19 Join merbanan [0] (~banan@c-62-220-165-78.cust.bredband2.com) 00.19.19 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 00.19.19 Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) 00.19.19 Join m1k3y [0] (~m1k3y@unaffiliated/m1k3y) 00.19.19 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 00.19.19 Join esperegu [0] (~quassel@145.116.15.244) 00.19.19 Join akzfowl [0] (~akzfowl@1.186.11.76) 00.19.19 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 00.19.19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.19.19 Join user890104 [0] (~Venci@6bez10.info) 00.19.19 Join kkurbjun [0] (~kkurbjun@rockbox/developer/kkurbjun) 00.19.19 Join soap [0] (~soap@rockbox/staff/soap) 00.19.19 Join balintx_ [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 00.19.19 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 00.19.19 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 00.19.19 Join antil33t [0] (~antil33t@124-197-51-80.callplus.net.nz) 00.19.19 Join Hadaka [0] (~naked@naked.iki.fi) 00.19.19 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 00.19.19 Join MethoS- [0] (~clemens@134.102.106.250) 00.19.19 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 00.19.19 Join kevku [0] (~kevku@2001:7d0:0:f9af:babe:feed:dead:beef) 00.19.19 Join sideral [0] (~sideral@rockbox/developer/sideral) 00.19.19 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 00.19.19 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.19.19 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 00.19.19 Join Horscht [0] (~Horscht@xbmc/user/horscht) 00.19.19 Join sasquatch [0] (~username@df01ppp187.eplus-online.de) 00.19.19 Join Rob2223 [0] (~Miranda@p4FFF3D5A.dip.t-dialin.net) 00.19.19 Join pixelma [0] (quassel@rockbox/staff/pixelma) 00.19.19 Join amiconn [0] (quassel@rockbox/developer/amiconn) 00.19.19 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 00.19.19 Join Barahir [0] (~jonathan@frnk-4d0091b1.pool.mediaWays.net) 00.19.19 Join kugel [0] (~kugel@rockbox/developer/kugel) 00.19.19 Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) 00.19.19 Join ender| [0] (krneki@foo.eternallybored.org) 00.19.19 Join fkhodkov [0] (~fedor76@ppp-78-24-25-163-bras0.istra.ru) 00.19.19 Join Bagder [0] (~daniel@rockbox/developer/bagder) 00.19.19 Join cjcopi [0] (~craig@charon.craig.copi.org) 00.19.19 Join kkit|sh [0] (~kkit@li135-248.members.linode.com) 00.19.19 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 00.19.19 Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) 00.19.19 Join factor [0] (~factor@75.108.68.114) 00.19.19 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 00.19.19 Join bthomson [0] (~bthomson@pool-71-114-64-197.washdc.dsl-w.verizon.net) 00.19.19 Join ej0rge [0] (~alhaz@alhaz.fttp.xmission.com) 00.19.19 Join timccc [0] (~timccc@112.166.15.141) 00.19.19 Join literal [0] (hinrik@w.nix.is) 00.19.19 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 00.19.19 Join Robdgreat [0] (~rob@unaffiliated/robdgreat) 00.19.19 Join JackWinter [0] (~jack@vodsl-9173.vo.lu) 00.19.19 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 00.19.19 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 00.19.19 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 00.19.19 Join Elfish [0] (~amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 00.19.19 Join ranmachan [0] (~ranma@yumi.tdiedrich.de) 00.19.19 Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) 00.19.19 Join Dreamxtreme [0] (~Dre@92.18.110.105) 00.19.19 Join froggyman [0] (~seth@unaffiliated/froggyman) 00.19.19 Join pjm0616 [0] (~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net) 00.19.19 Join knittl [0] (~knittl@unaffiliated/knittl) 00.19.19 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 00.19.19 Join maraz [0] (maraz@kapsi.fi) 00.19.19 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 00.19.19 Join alexbobp [0] (~alex@75.60.183.54) 00.19.19 Join scorche [0] (~scorche@rockbox/administrator/scorche) 00.19.19 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 00.19.19 Join [fred] [0] (~fred@ircop.efnet.at) 00.19.19 Join JesusChrysler [0] (~JesusChry@c-69-253-15-232.hsd1.pa.comcast.net) 00.19.19 Join rasher [0] (~rasher@rockbox/developer/rasher) 00.19.19 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 00.19.19 Join guymann [0] (~charles@66-159-148-187.adsl.snet.net) 00.19.19 Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net) 00.19.19 Join linuxguy3 [0] (~timj@adsl-76-202-220-107.dsl.emhril.sbcglobal.net) 00.19.19 Join Strife89 [0] (~Strife89@168.16.226.187) 00.19.19 Join MarkTraceur [0] (~marktrace@cpe-76-174-115-122.socal.res.rr.com) 00.19.19 Join Buganini [0] (~buganini@security-hole.info) 00.19.19 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 00.19.19 Join FOAD [0] (~dok@83.161.135.61) 00.19.19 Join mystica555 [0] (~Mike@71-33-147-209.hlrn.qwest.net) 00.19.19 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 00.19.19 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 00.19.19 Join useer [0] (~quassel@dsl-63-249-22-9.zipcon.net) 00.19.19 Join ved [0] (ved@209.123.234.207) 00.19.19 Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) 00.19.19 Join Loto [0] (~nfs@xbmc/user/Loto) 00.19.19 Join iq [0] (~iq@unaffiliated/iq) 00.19.19 Join zu [0] (~zu@ks355000.kimsufi.com) 00.19.19 Join pikytcus [0] (~bigd@failbox.co.cc) 00.19.19 Join amee2k [0] (~thomas@ve504.cugnet.net) 00.19.19 Join teapot [0] (uno@host135-126-dynamic.20-79-r.retail.telecomitalia.it) 00.19.19 Join feisar-_ [0] (jljhook@ihq.in) 00.19.19 Join Kuitsi [0] (~Kuitsi@a88-113-118-171.elisa-laajakaista.fi) 00.19.19 Join yawny [0] (user36@pr0.us) 00.19.19 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 00.19.19 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 00.19.19 Join Battousai [0] (~bryan@gentoo/developer/battousai) 00.19.19 Join markun [0] (~markun@rockbox/developer/markun) 00.19.19 Join AlexP [0] (~alex@rockbox/staff/AlexP) 00.19.19 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 00.19.19 Join parafin [0] (parafin@paraf.in) 00.19.19 Join CIA-2 [0] (~CIA@208.69.182.149) 00.19.19 Join Torne [0] (~torne@rockbox/developer/Torne) 00.19.19 Join plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 00.19.19 Join Rondom [0] (~rondom@nonmodosedetiam.net) 00.19.19 Join ack [0] (~ack@mingbai.org) 00.19.19 Join aevin [0] (eivindsy@unaffiliated/aevin) 00.19.19 Join tmzt_ [0] (~tmzt@76.211.0.152) 00.19.19 Join preglow [0] (thomj@rockbox/developer/preglow) 00.19.19 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 00.19.19 Join bzed [0] (~bzed@devel.recluse.de) 00.19.19 Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) 00.19.19 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 00.19.19 Join simabeis_ [0] (~simabeis@lobmenschen.de) 00.19.19 Join Ypsy_ [0] (~ypsy@geekpadawan.de) 00.19.19 Join jae [0] (~jae@dedicated.jaerhard.com) 00.19.19 Join ehntoo [0] (~ehntoo@lug.mtu.edu) 00.19.19 Join Utchy [0] (~Utchy@rps6752.ovh.net) 00.19.19 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 00.19.19 Join @ChanServ [0] (ChanServ@services.) 00.19.19 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 00.20.18 Quit domonoky (Read error: Connection reset by peer) 00.21.32 Quit pamaury (Remote host closed the connection) 00.25.09 Join Keripo [0] (~Keripo@dhcp0101.kin.resnet.group.upenn.edu) 00.29.24 Quit mshathlonxp (Quit: fall into [short] sleep) 00.32.18 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 00.32.36 Quit domonoky (Read error: Connection reset by peer) 00.33.53 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 00.37.49 Quit stripwax (Read error: Connection reset by peer) 00.39.37 Quit mudd1 (Ping timeout: 260 seconds) 00.45.27 Quit simonrvn (Ping timeout: 260 seconds) 00.45.55 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 00.46.51 Quit JesusChrysler (Quit: JesusChrysler) 00.51.11 Quit kevku (Read error: Operation timed out) 00.59.34 Join Galois [0] (djao@efnet-math.org) 01.01.23 Quit robin0800 (Quit: Leaving) 01.01.25 Quit MagusG (Ping timeout: 276 seconds) 01.18.37 Quit sideral (Quit: Leaving.) 01.21.54 Join soap_ [0] (~soap@rockbox/staff/soap) 01.22.17 Quit soap (Disconnected by services) 01.22.20 Nick soap_ is now known as soap (~soap@rockbox/staff/soap) 01.22.46 Join soap_ [0] (~soap@rockbox/staff/soap) 01.26.50 Quit casainho (Remote host closed the connection) 01.36.53 Quit merbanan (Quit: Leaving) 01.40.22 # <[Saint]> kugel: Just discovered something wrong in convttf. 01.40.50 # <[Saint]> addig ascent/descent adds to the total font height, instead of respecting the max font height param. 01.40.54 # <[Saint]> *adding. 01.41.59 # <[Saint]> ./convttf -p 12 -Ta -2 -Td -2 fontfile.ttf outputs a font that is 16px high, instead of 12. 01.42.44 # <[Saint]> ascent/descent is supposed to be added to the font without increasing the fonts total height. 01.49.20 Quit TheSeven (Ping timeout: 252 seconds) 01.53.12 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 02.00.35 Quit soap (Read error: Connection reset by peer) 02.01.04 Join soap [0] (~soap@rockbox/staff/soap) 02.07.22 # <[Saint]> AlexP: I see you asked about committing the line spacing patch for RaaA. 02.07.41 # <[Saint]> IMO, this needs to be configurable, or optional...which might be difficult. 02.07.53 # <[Saint]> it looks balls on lower res screens. 02.09.15 # <[Saint]> the way it "hides" lines is also weird...if a singular pixel of the added space cannot be displayed in the UI viewport, it won't draw the whole line...which makes it look like some menus are cut off, or mising items, or don't extend any further than they actually do. 02.09.28 # <[Saint]> this "hiding" also seems to mess up the scroll bar. 02.10.21 # <[Saint]> (if a singular pixel of the added area can't be displayed in the Ui viewport, the scrollbar ends at the last "fully" displayed line...making the scrollbar shorter than the list, which also looks weird. 02.10.39 # <[Saint]> I suspect kugel needs a highlight there too: ^ 02.11.06 # <[Saint]> possibly JdGordon| also...no idea. 02.13.32 # no point hilighting me... the patch isnt on flyspray so meh 02.13.58 # <[Saint]> just wondering if you know how it might be done....errr, "well"? 02.14.11 # <[Saint]> I'm not sure that's quite the right word, but it'll do. 02.14.53 # like i said, i havnt looked at the patch, but by the sounds of it I would be against it being commited seen as it sounds like a massive broken hack 02.15.38 # <[Saint]> I think it's just only been tested on "high" res devices, so suffered the same fate as the widget. 02.15.41 Join madalu [0] (~matt@unaffiliated/madalu) 02.16.03 *** Saving seen data "./dancer.seen" 02.16.10 # <[Saint]> I like the look of it, but I immediately uninstalled the .apk when I found out how it acted. 02.21.19 Join jpt9 [0] (~jpt9@unaffiliated/jpt9) 02.21.40 # Hey. I think I've found an odd bug on Rockbox. Either that or I have an oddly-corrupted MP3... 02.21.56 # I'm running Rockbox 3.8 on my Sansa Clip, and if I play the first file from this album: 02.21.59 # http://www.jamendo.com/en/album/85427 02.22.33 # At some point Rockbox freezes... sort of -- it still plays, but it doesn't update the display or respond to input. Holding down the power button for several seconds still turns the device off, of course. 02.25.40 # <[Saint]> only the first file, of that one album? 02.26.10 Quit simonrvn (Read error: Operation timed out) 02.26.29 # Well, I have tried the other ones in that album... 02.26.33 # And it's never done this before... 02.26.34 # <[Saint]> it might pay to check for wierd metadata tags, or excessively large embedded album art...and/or FS corruption. 02.28.13 # 25kb 400x400 album art... 02.28.21 # Wait... 02.28.26 # 3 embedded images... 02.28.41 # Is that weird? 02.29.10 # <[Saint]> that might do it...possibly, it's a clip right? there's no point in having embedded AA that's larger than the physical height of your DAP. 02.29.15 # Yeah. 02.29.25 # And higher bit depth, too. 02.29.31 # (Yeah, I know, temporal dithering, etc.) 02.30.04 # <[Saint]> "very large" AA has been known to trip things up before, but I'm not aure what constitutes "very large". 02.30.05 # Also, thanks to the devs for catching up with the latest Clips. It's great knowing that if mine breaks, I can just buy a Clip+ and Rockbox it. 02.30.10 Join simonrvn_ [0] (simon@2001:470:8c85:11fe::c0a8:195) 02.30.17 # <[Saint]> *sure 02.30.46 # <[Saint]> s/AA/embedded AA/ 02.32.44 Join JimmyJ [0] (~prolp@c-98-203-129-5.hsd1.wa.comcast.net) 02.33.31 # On the plugin index, why is it that almost none of the plugins have a check for the Sansa Clip, despite working on it? 02.34.04 # <[Saint]> neglect? 02.34.12 # <[Saint]> that's my guess. 02.34.16 # Just ran the Windows disk check. In the process, it wiped out my .rockbox folder... 02.34.21 # * jpt9 sighs... have to redo my WPS... 02.34.28 # <[Saint]> the wiki is a vast place, where things can be overlooked. 02.34.55 # <[Saint]> jpt9: well, at least you now know it was FS corruption... 02.35.15 # <[Saint]> bugger about no backups though. 02.35.29 Join soap__ [0] (~soap@nl1.pointtoserver.com) 02.35.57 # <[Saint]> thankyou, though for pointing out the descrepency in the plugin index, I shall add that to my virtual ToDo list. 02.39.25 Quit soap (Ping timeout: 255 seconds) 02.40.51 Quit soap__ (Ping timeout: 276 seconds) 02.50.05 # Anyone happen to know the screen res of the Clip? 02.50.38 # Never mind. 02.55.13 Nick simonrvn_ is now known as simonrvn (simon@2001:470:8c85:11fe::c0a8:195) 02.57.51 Quit timccc (Quit: Leaving.) 02.58.13 Join timccc [0] (~timccc@112.166.15.141) 02.59.38 # Okay... so it wasn't the album art. Also, it still responds to keypresses to wake up the screen. 03.01.01 # AA works on the clip? 03.01.15 # Yes. At least in PictureFlow. 03.08.26 # * jpt9 is going to grab the Ogg version of the album instead. 03.08.33 # With any luck, that won't freeze it. 03.09.08 Quit evilnick (Quit: Page closed) 03.12.37 Join simonrvn_ [0] (quasselcor@2001:470:8c85:11fe::c0a8:195) 03.15.23 Quit milk (Quit: baaaiiii) 03.17.15 Quit simonrvn_ (Quit: n'multes) 03.27.11 Quit brightspark (Quit: Leaving) 03.27.35 Quit MethoS- (Remote host closed the connection) 03.30.00 Quit DerPapst (Quit: Leaving.) 03.30.54 Quit liar (Ping timeout: 276 seconds) 03.35.23 Quit JimmyJ (Quit: Leaving) 03.35.40 Join JimmyJ [0] (~JimmyJ@unaffiliated/jimmyj) 04.16.06 *** Saving seen data "./dancer.seen" 04.23.45 Quit simonrvn (Read error: Operation timed out) 04.27.29 Join japc [0] (~japc@bl21-168-102.dsl.telepac.pt) 04.30.18 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 04.30.52 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 04.32.31 Quit kugel (Read error: Operation timed out) 04.33.04 Join Barahir_ [0] (~jonathan@frnk-590f4296.pool.mediaWays.net) 04.33.47 Join JdGordon1 [0] (~jonno@vl10.gw.ok-labs.com) 04.33.47 Quit JdGordon1 (Changing host) 04.33.47 Join JdGordon1 [0] (~jonno@rockbox/developer/JdGordon) 04.33.53 Quit TheSeven (Ping timeout: 264 seconds) 04.36.17 Quit Barahir (Ping timeout: 250 seconds) 04.37.50 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.41.02 Join brightspark [0] (~kyle@dhcp-128-146-122-74.osuwireless.ohio-state.edu) 04.45.21 Quit amiconn (Disconnected by services) 04.45.21 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.45.41 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.47.54 Quit pixelma (Disconnected by services) 04.47.56 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.47.58 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 05.01.58 Join Rob2222 [0] (~Miranda@p4FFF1F3C.dip.t-dialin.net) 05.03.21 Quit brightspark (Read error: Connection reset by peer) 05.05.52 Quit Rob2223 (Ping timeout: 276 seconds) 05.10.55 Quit kkit|sh (Ping timeout: 250 seconds) 05.25.41 Join webguest17 [0] (~8984fa0a@giant.haxx.se) 05.26.14 Quit webguest17 (Client Quit) 05.30.01 Quit CaptainKwel (Read error: Connection reset by peer) 05.37.33 Quit antil33t (Read error: Connection reset by peer) 05.39.39 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 05.42.55 Quit Horscht (Quit: Verlassend) 05.43.12 Quit timccc (Ping timeout: 252 seconds) 05.46.27 Quit antil33t (Ping timeout: 250 seconds) 05.49.21 # <[Saint]> JdGordon1: the timeout for %Tl seems to always be ~2 seconds. 05.49.28 # <[Saint]> no matter the setting. 05.49.51 # oh? 05.49.55 # <[Saint]> also...does the slider offset a bar by any value? 05.50.08 # <[Saint]> I have weird bar behaviour, and I can't explain why. 05.53.14 # <[Saint]> JdGordon1: the slider bar tag offsets the bar by the width of the slider image also. 05.53.27 # by half the width... 05.53.59 # <[Saint]> it seems to be the whole width...and, why does it do that? as it leaves a very ugly black box. 05.54.18 # by design we shifted it a bit 05.54.24 # show me example of suckage though 05.54.26 # <[Saint]> couldn't it just draw the full image at the start/end of the bar like "same" sliders? 05.54.52 # <[Saint]> suckage == "the offset is a hideous black box" 05.55.02 # <[Saint]> *sane 05.55.05 # aye 05.55.57 Join timccc [0] (~timccc@112.166.15.141) 05.56.04 # <[Saint]> I mean, couldn't the slider only be drawn in the bar area, and not extend past it? 05.57.18 # <[Saint]> I expected the x,y position of the bar to be exactly that...not offset by some magic number because I'm using a slider that behaves like no other slider I have ever seen. 05.58.34 # <[Saint]> using a block of transparency fixed the issue with the volume bar backdrop though, but that's no longer relevant anymore for the default theme as we won't be using it...I just thought it was worth a mention. 05.58.43 # what bar area? 05.59.36 Join Rob2223 [0] (~Miranda@p4FFF1328.dip.t-dialin.net) 05.59.49 # <[Saint]> in the VP where the bar is drawn, the bar is offset by X, and the offset is completely black. 06.00.10 Join timccc1 [0] (~timccc@112.166.15.141) 06.00.38 Quit timccc (Client Quit) 06.02.18 # <[Saint]> hmmm...HotKey crashes RaaA on my target with "*PANIC* Stack Underflow... Viewportmanager" 06.02.29 Quit TheSeven (Ping timeout: 250 seconds) 06.02.38 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 06.02.55 Quit Rob2222 (Ping timeout: 250 seconds) 06.04.56 Quit Zarggg (Excess Flood) 06.05.27 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 06.06.49 Quit madalu (Ping timeout: 250 seconds) 06.11.53 # <[Saint]> BLARGH! 06.12.10 # nice 06.12.12 # <[Saint]> this whole "use the native volume" in RaaA thing has really messed me up. 06.12.17 # to the panic 06.14.09 # <[Saint]> I have *NO* idea what to do with the popup tab now...previously, I was using two of them, one for the menu popup, and one for the volume popup....curring it out totally messes up the symmetry I had going on there. 06.14.25 # <[Saint]> *cutting 06.14.32 # why cut it? 06.14.53 # <[Saint]> because two volume popups would be weird? 06.15.20 # <[Saint]> using the native volume means we get the nice Android media volume popup, no? 06.15.50 # <[Saint]> or, are we doing it transparently? 06.16.07 *** Saving seen data "./dancer.seen" 06.16.11 # <[Saint]> I had assumed the former, but...if the latter, it can stay. 06.18.12 # no idea, i havnt tried svn 06.18.32 # <[Saint]> Nor I since the volume changes started. 06.19.48 # <[Saint]> the keyboard leads me to believe that popping up the native volume window wouldn't be hard, so I assume that's what's going to happen. To better integrate RaaA to the Android OS. 06.20.21 # I wouldnt be so sure of that 06.20.26 # <[Saint]> which I don't mind, it's just a lot of work sorting out how to handle volume withthe default theme out the window. 06.20.42 # sure it might poppup if you actually press the hardware volume buttons, but not with the skin button 06.21.14 # <[Saint]> well, it basically has to be all or nothing IMO. 06.21.28 # <[Saint]> doing this halfway makes it worse than it was to begin with. 06.22.11 # <[Saint]> ie. if HW buttons pop up the media volume window, but the screen touch area "button" (if we even have one) does not...well, that just sucks. 06.30.09 Quit ender| (*.net *.split) 06.36.34 Join ender| [0] (krneki@foo.eternallybored.org) 06.39.08 Quit Topy44 (*.net *.split) 06.39.09 Quit FoH (*.net *.split) 06.39.09 Quit fkhodkov (*.net *.split) 06.39.09 Quit n17ikh (*.net *.split) 06.47.02 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 06.49.19 Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) 06.51.38 Quit japc (Read error: Operation timed out) 06.52.57 Join slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de) 06.52.58 Join Topy44 [0] (~Topy44@f048237196.adsl.alicedsl.de) 06.52.58 Join FoH [0] (~foh@adsl-71-69-118.bhm.bellsouth.net) 06.52.58 Join fkhodkov [0] (~fedor76@ppp-78-24-25-163-bras0.istra.ru) 06.52.58 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 06.55.41 Join japc [0] (~japc@2.82.168.102) 07.02.48 Quit JdGordon1 (Quit: leaving) 07.05.46 Join T44 [0] (~Topy44@f049237069.adsl.alicedsl.de) 07.05.48 Quit Topy44 (Ping timeout: 255 seconds) 07.11.09 Join stoffel [0] (~quassel@p57B4BB13.dip.t-dialin.net) 07.23.57 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 07.28.24 Quit sasquatch (Ping timeout: 240 seconds) 07.28.30 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 07.33.59 Join [Saint] [0] (~st.lasciv@203.184.2.119) 07.33.59 Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) 07.34.13 Quit stoffel (Remote host closed the connection) 07.36.22 # [Saint]: Androids volume pop up isn't shown currently and doesn't look it's going to be 07.36.23 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.36.58 Quit factor (Ping timeout: 250 seconds) 07.38.57 Join factor [0] (~factor@75.108.68.114) 07.42.44 Quit akzfowl (Ping timeout: 240 seconds) 07.55.24 Join akzfowl [0] (~akzfowl@1.186.5.16) 07.55.37 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.01.35 Join JdGord [0] (~AndChat@122.110.120.61) 08.07.23 Join ender` [0] (krneki@foo.eternallybored.org) 08.16.10 *** Saving seen data "./dancer.seen" 08.17.05 Quit [Saint] (Ping timeout: 252 seconds) 08.17.39 Join [Saint] [0] (S_a_i_n_t@203.184.2.119) 08.18.49 Join kevku [0] (~kevku@2001:7d0:0:f9af:babe:feed:dead:beef) 08.20.08 Quit bluebrother (Disconnected by services) 08.20.10 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 08.23.15 Part JimmyJ ("Leaving") 08.25.13 Join sasquatch [0] (~username@109.250.36.122) 08.27.29 Quit simonrvn (Ping timeout: 260 seconds) 08.28.41 Quit fkhodkov (Read error: Connection reset by peer) 08.30.46 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 08.34.03 Quit antil33t (Ping timeout: 255 seconds) 08.46.46 Join LinusN [0] (~linus@giant.haxx.se) 08.46.46 Quit LinusN (Changing host) 08.46.46 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.48.50 Quit simonrvn (Read error: Operation timed out) 08.53.25 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 08.55.32 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 08.58.31 Join esperegu_ [0] (~quassel@145.116.10.163) 08.59.15 Quit esperegu (Ping timeout: 252 seconds) 09.01.29 # <[Saint]> JdGordon|: barring the %Tl timeout, I have the volume and browser/context menu/quickscreen popups working nicely...but the conditional viewports are kicking my ass. 09.02.05 # <[Saint]> I'll port the changes (I was working on my phone) to the 480x800 version shortly, then it's skin var time. 09.02.23 # <[Saint]> I may/may not get the images I need finished tonight though. 09.03.01 Quit antil33t (Read error: Connection reset by peer) 09.03.09 # <[Saint]> oh...and there's the issue of the slider looking crap. 09.03.17 Quit bertrik (Ping timeout: 252 seconds) 09.03.29 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 09.03.35 # <[Saint]> so I changed it to just a plain bar for now, but the images are still all there. 09.04.38 # [Saint]: did you stop working on the icons? 09.05.49 # <[Saint]> not stopped, side-tracked I think you'd call it ;) bluebroth3r found a way to generate the bitmap strips needed with a script...but they need to be cleaned by hand. 09.06.00 # I can send you some xcf files I used for cabbiev2 if you want 09.06.46 # <[Saint]> and some of them worked very well, others look terrible and need redoing...I'm trying to get the default theme sorted out presently. 09.06.52 # <[Saint]> sure: It couldn't hurt. 09.08.05 # <[Saint]> I have a nice popup volume slider working in my "cabbie" presently...but to get it working properly skin variables really need to be added so I can meet conditions that can't be met with %if or the current conditional tags. 09.09.17 Quit simonrvn (Quit: Reconnecting) 09.09.24 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 09.15.02 Join B4gder [0] (~danielx@2a00:1a28:1200:9::2) 09.15.02 Quit B4gder (Changing host) 09.15.02 Join B4gder [0] (~danielx@rockbox/developer/bagder) 09.18.33 Join DerPapst [0] (~Alexander@p5DE5B5B7.dip.t-dialin.net) 09.18.51 Quit DerPapst (Client Quit) 09.23.06 Quit akzfowl (Ping timeout: 252 seconds) 09.26.18 # What's the story with %Tl? 09.26.34 # <[Saint]> it seems to igone the timeout param 09.26.34 # Is it for all regions or just labeled/non-labeled? 09.26.44 # File with more detail 09.26.58 # <[Saint]> will do, but I can't for a while. 09.33.34 Quit Keripo (Quit: Leaving.) 09.42.01 Part LinusN 09.49.35 # Why does the I have a 1 pixel border but i doesn't in this font? 09.50.06 # Actually vlooks like all caps have a pixel border that lower doesn't have 09.51.35 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.53.28 Join n1s [0] (~n1s@sb-fw.bmc.uu.se) 09.53.28 Quit n1s (Changing host) 09.53.28 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.08.57 Quit JdGord (Quit: Bye) 10.16.11 *** Saving seen data "./dancer.seen" 10.21.04 Join esperegu [0] (~quassel@145.116.10.163) 10.21.45 Quit esperegu_ (Ping timeout: 252 seconds) 10.27.46 Quit simonrvn (Read error: Operation timed out) 10.30.27 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 10.30.48 # does someone know why the needed Android SDK version was upped? 10.33.20 Join Kitar|st [0] (~Kitarist@BSN-182-72-197.dial-up.dsl.siol.net) 10.34.57 Join esperegu_ [0] (~quassel@145.116.10.163) 10.35.21 Quit kevku (Ping timeout: 248 seconds) 10.35.54 Quit esperegu (Ping timeout: 250 seconds) 10.39.41 # * [Saint] wonders who Maurus Cuelenaere is on IRC... 10.39.58 # <[Saint]> I suspect he knows why the version was bumped, as it was his commit. 10.41.37 # <[Saint]> pixelma: my guess is that it plays a role in the following commit "29562 uture-proof the RunForegroundManager code to Honeycomb" 10.41.52 # <[Saint]> *future 10.43.17 Join pamaury [0] (81680b01@rockbox/developer/pamaury) 10.45.17 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 10.56.17 # [Saint]: mcuelenaere though not around so often anymore 10.58.08 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 10.58.22 # New commit by 03wodz (r29584): slightly modified FS#11531 by me: WM8750/51 driver rework 10.58.47 # * wodz crossing fingers 11.00.18 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 11.02.26 # r29584 build result: All green 11.04.51 # global mods or forum admins - winw93451l wants a ban 11.06.21 # (AlexP, scorche, soap_ ?) 11.07.01 # Is there a page describing how to use langtool? I don't want to sync all lang files to english.lang by hand 11.08.07 # wodz: adding strings to targets that previously didn't have them breaks the string/voice clip order for those targets so i think it's nice to mentio that in the commit message 11.09.40 # wodz: langtool has a built in usage help if you run it with no args, you want --changetarget 11.09.52 # n1s: Probably. Unfortunately I wasn't aware of this. 11.10.43 # n1s: thx 11.10.51 Join MethoS- [0] (~clemens@134.102.106.250) 11.12.34 # i wonder if we should drop the whole string exclusion mechanism to make the order more stable at the price of some wasted space 11.13.53 # hmm, or maybe it could be improved at no cost if the ids don't need to be continual 11.14.02 Quit useer (Ping timeout: 250 seconds) 11.14.44 # the string inclusion thing was explicitly added and saved quite a lot of space IIRC (langv2, you worked on it too) 11.15.04 # if that would work, deprecated ids would not waste space either 11.15.24 Quit mudd1 (Ping timeout: 240 seconds) 11.15.36 # pixelma: yes, although i think this system is too fragile and people don't know about it 11.15.42 Join useer [0] (~quassel@dsl-63-249-22-9.zipcon.net) 11.16.16 # If something is changed that breaks order, version should be bumped 11.16.30 # This is very similar to the plugin api 11.16.42 # and I guess one other factor is quick access to the needed string (I can't tell though what difference another implementation would make) 11.16.52 Part Zagor 11.17.07 # i don't remember why the ids need to continual currently but if that restriction could be removed we could enable previously skipped id's and the voice clip would just be missing 11.17.48 # The're accessed using an array 11.18.23 # amiconn: that is one way but we don't currently have such a version field, only a "format version" field or whatever (which i suggested we use for this at one point but that idea was sot down) 11.19.32 # *and* people tend to not update such versions anyway 11.20.01 # Each unused clip or string included wastes several bytes (iirc 4 bytes for voice clips, 5 bytes for lang strings (8 on SH1 due to padding)) - and there are hundreds 11.22.06 # yes, with the current format, since the ids need to be continuus, but if we could have discontinuus ids in the lang and voice files this could be avoided but it was a long time since i looked at the code so it might not be possible 11.22.25 # (btw see fs#8886 for the version field discussion) 11.23.08 # hmm, i 11.23.27 # 'm probably ovelooking something or the discuntinuus ids would already be used 11.24.24 # it's just that this system is very fragile and i don't like it 11.27.23 # where is the version thing I should bump? 11.28.28 # wodz: there isn't one 11.28.49 # New commit by 03wodz (r29585): Update lang files to be inline with changes in r29584 11.29.48 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 11.29.57 # wodz: you could have taken the chance to mention the voice file thing now... ;) 11.30.44 Quit esperegu_ (Read error: Operation timed out) 11.30.48 # pixelma: I thought mentioning lang update is enough :-/ 11.32.11 # r29585 build result: All green 11.32.50 Quit wodz (Quit: Leaving) 11.33.02 Join esperegu [0] (~quassel@145.116.10.163) 11.41.06 # right, so to use discontinuus ids we would either need gaps in the lang strings table, to store the ids or to parse the lang and voice files at the same time 11.42.34 # hmm, i wonder if that could work when we don't load the complete voice file... 11.43.52 # this scheme would also need a version field of course but it wouldn't need to change so often 11.54.27 Quit simonrvn (Read error: Operation timed out) 11.57.06 Quit B4gder (Remote host closed the connection) 12.02.22 Join B4gder [0] (~danielx@2a00:1a28:1200:9::2) 12.02.23 Quit B4gder (Changing host) 12.02.23 Join B4gder [0] (~danielx@rockbox/developer/bagder) 12.04.51 Quit robin0800 (Quit: Leaving) 12.05.07 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 12.08.11 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 12.09.08 Quit japc (Ping timeout: 260 seconds) 12.14.40 Quit timccc1 (Ping timeout: 252 seconds) 12.16.12 *** Saving seen data "./dancer.seen" 12.24.50 Join kkit|sh [0] (~kkit@li135-248.members.linode.com) 12.26.06 Join timccc [0] (~timccc@112.166.15.141) 12.38.17 Join JdGord [0] (~AndChat@pa58-109-194-92.pa.vic.optusnet.com.au) 12.38.20 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 12.39.03 Join niekie [0] (~niek@2001:470:9326::3) 12.39.06 Quit niekie (Changing host) 12.39.06 Join niekie [0] (~niek@CAcert/Assurer/niekie) 12.40.19 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.41.26 Quit robin0800 (Remote host closed the connection) 12.43.29 Join leavittx [0] (~lev@89.221.199.187) 12.47.45 Join japc [0] (~japc@bl16-4-215.dsl.telepac.pt) 12.53.17 Quit japc (Ping timeout: 250 seconds) 12.59.59 Part Zagor 13.02.49 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 13.19.45 Quit JdGord (Quit: Bye) 13.23.52 Quit [Saint] (Quit: back soon, restarting) 13.23.52 Quit user890104 (Ping timeout: 248 seconds) 13.25.51 # New commit by 03zagor (r29586): Listen to and follow external Android volume changes. (Based on FS#11914 by Maurus Cuelenaere) 13.28.12 Join [Saint] [0] (S_a_i_n_t@203.184.0.75) 13.31.30 # r29586 build result: All green 13.34.11 Quit Llorean (Read error: Connection reset by peer) 13.36.56 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 13.39.36 Quit robin0800 (Remote host closed the connection) 13.39.45 Quit bluefoxx (Ping timeout: 240 seconds) 13.40.20 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 13.50.02 Quit robin0800 (Remote host closed the connection) 13.50.31 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 14.01.56 Join japc [0] (~japc@194.65.5.235) 14.10.19 Join akzfowl [0] (~akzfowl@1.186.11.8) 14.16.13 *** Saving seen data "./dancer.seen" 14.21.53 Quit akzfowl (Ping timeout: 255 seconds) 14.24.38 Quit robin0800 (Remote host closed the connection) 14.26.40 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 14.30.34 Quit n1s (Quit: Lämnar) 14.32.43 Join sideral [0] (~sideral@rockbox/developer/sideral) 14.36.30 Join akzfowl [0] (~akzfowl@1.186.11.8) 14.45.30 Join user890104 [0] (~Venci@6bez10.info) 14.48.58 Quit simonrvn (Ping timeout: 260 seconds) 14.49.31 Quit m1k3y (Remote host closed the connection) 14.49.58 Join m1k3y [0] (~m1k3y@unaffiliated/m1k3y) 14.50.44 Quit akzfowl (Ping timeout: 252 seconds) 14.51.00 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 14.57.37 Join AndroUser [0] (~androirc@62.40.36.13) 15.02.49 Join akzfowl [0] (~akzfowl@1.186.11.8) 15.04.08 Quit AndroUser (Quit: AndroIRC) 15.05.59 Part LinusN 15.06.57 Join LinusN [0] (~linus@rockbox/developer/LinusN) 15.18.40 Quit kugel (Read error: Operation timed out) 15.21.11 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 15.21.15 Join casainho [0] (~chatzilla@2.83.242.140) 15.21.37 # hello 15.21.55 # can someone tell me what is the target with IMX233 ARM? 15.22.03 # I believe pamaury is working on it... 15.23.16 # http://www.rockbox.org/wiki/SansaFuzePlus 15.23.29 Join n1s [0] (~n1s@nl118-175-108.student.uu.se) 15.23.29 Quit n1s (Changing host) 15.23.29 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.23.44 # B4gder: thanks 15.24.17 Quit pamaury (Ping timeout: 245 seconds) 15.25.04 # B4gder: do you know if there is some code on SVN for it? I am looking for interrupt code, for kernel(); 15.25.44 # B4gder: the only sources provided by FreeScale are for Linux and I don't know where to find there the interrupt code... 15.26.13 # I don't think we have any imx233-specific code yet, no 15.29.15 # ok 15.29.35 Part jpt9 15.33.35 Join kugel [0] (~kugel@g231233117.adsl.alicedsl.de) 15.33.35 Quit kugel (Changing host) 15.33.35 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.35.41 Quit T44 (Ping timeout: 255 seconds) 15.36.49 Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) 15.37.02 Quit akzfowl (Ping timeout: 255 seconds) 15.41.02 # kugel: regarding albumart in the widget, I get the following messages in ADB on track change: 15.41.16 # I/System.out( 1276): resolveUri failed on bad bitmap uri: file:///sdcard/rockbox/.temp_albumart_261.jpg (for embedded albumart) and 15.41.35 # I/System.out( 1276): resolveUri failed on bad bitmap uri: file:///sdcard/music/folder.jpg (for a folder.jpg that is there) 15.44.48 # a Rockbox logo as fallback is for no albumart is shown though (guess it is built-in) - if an image should be shown, the space stays empty 15.48.25 Join Topy44 [0] (~Topy44@f049237069.adsl.alicedsl.de) 15.55.07 # pixelma: it looks like a very common problem, possibly being 2.1/2.2 related 15.55.08 Join mcuelenaere [0] (~quassel@rockbox/developer/mcuelenaere) 15.55.08 Quit mcuelenaere (Client Quit) 15.56.37 Join mcuelenaere [0] (~quassel@78-22-96-2.access.telenet.be) 15.56.37 Quit mcuelenaere (Changing host) 15.56.37 Join mcuelenaere [0] (~quassel@rockbox/developer/mcuelenaere) 15.56.49 # running 2.1, true 15.57.36 # http://stackoverflow.com/questions/3004713/get-content-uri-from-file-path-in-android 15.57.38 # pixelma: the version bump wans't necessary per se, it just started out as a bump to r9 (which moved some tools to a different directory, hence the commit) 15.57.51 # ^^^ contains a suggestion worth trying 15.57.56 # wasn't* 15.58.16 Quit sideral (Quit: Leaving.) 15.59.31 # Zagor: looks interesting, but I don't think I can do the necessary changes myself and I'm not able to build currently :\ 16.00.36 # * B4gder makes Zagor aware of the rockbox-dev mail 16.01.14 # New commit by 03zagor (r29587): Fixed a typo. (Thanks Jeff!) 16.02.11 Join Keripo [0] (~Keripo@SEAS037.wlan.seas.upenn.edu) 16.02.36 Join sideral [0] (~sideral@213.165.85.248) 16.02.36 Quit sideral (Changing host) 16.02.36 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.04.05 # mcuelenaere: I'd like to at least know these things in advance and I'm actually not sure what to think about it if it wasn't necessary yet 16.04.35 # pixelma: I don't see how much trouble this is? It's just upgrading your local dev environment 16.04.38 Join pamaury [0] (81680b01@rockbox/developer/pamaury) 16.05.02 Quit bluefoxx (Quit: Can we, should we, will we?) 16.05.05 # does maemo have a similar volume resolution issue as android? 16.05.15 Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) 16.05.21 # pixelma: the necessity of it is debatable, once we upgrade to r9 or higher android.make still needs to be changed 16.05.23 # I don't have access to the setup of it myself, I am just allowed to build 16.05.34 # you can do an upgrade over CLI 16.05.37 # casainho: there is no code in the svn yet, I've not started development 16.05.49 # mcuelenaere: no, it's not my system 16.05.58 # II don't have the permissions 16.06.17 # you don't have permissions from the owner or you don't have permissions on the PC? this shouldn't require root permissions 16.06.26 # (on Linux, that is) 16.06.27 # r29587 build result: All green 16.07.12 # and we don't up necessary gcc versions just like that either 16.07.14 # also, the build server should really start to build the android port 16.07.47 # pixelma: do you want me to revert the change? 16.07.57 # pamaury: do you know were we can find examples code for imx233? I am looking for interrupt example code... 16.08.24 Part LinusN 16.08.52 # also, that change was reviewed by kugel and approved (not sure if that's a valid point) 16.08.56 # mcuelenaere: I don't know... guess as long as it seems to be just me who doesn't like it (or the way it was done), then probably not 16.09.18 # casainho: no idea, I there is a linux "port" for imx233 so you can have a look at it, it's probably in the arm/mach/ subfolders 16.09.25 # * I think 16.09.27 # pixelma: can't you setup a local build? 16.10.00 # maybe 16.10.15 # mcuelenaere, pixelma: was the change announced on the mailing list? 16.10.17 Quit Kitar|st () 16.10.43 # pamaury: I were looking at Linux sources already... it is difficult for me to understand... we need from there the SDCard drivers! 16.11.24 Join linuxstb [0] (~linuxstb@131.231.19.95.dynamic.jazztel.es) 16.11.24 Quit linuxstb (Changing host) 16.11.24 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 16.11.33 # gevaerts: I didn't see it (putting it carefully as it was a change on Saturday on which I didn't have much time to follow it) 16.11.40 # you can always rewrite it, and you'll need to partially do it because linux drivers are too complicated for what rockbox needs, and too bloated too :) 16.12.12 # gevaerts: no, it wasn't 16.12.25 # That probably should be done 16.13.00 # mcuelenaere: I think that's probably the thing that should be improved. just let everyone know that they need to upgrade the sdk before being able to build next time. 16.13.59 # ok, I'll send out a mail to rockbox-dev 16.16.17 *** Saving seen data "./dancer.seen" 16.20.56 Quit sideral (Ping timeout: 248 seconds) 16.21.43 Quit antil33t (Read error: Connection reset by peer) 16.21.52 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 16.24.26 Join sideral [0] (~sideral@213.165.85.248) 16.24.26 Quit sideral (Changing host) 16.24.26 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.24.58 # casainho: in the linux source, I think you'll find some code in arch/arm/mach-stmp3xxx/ 16.25.02 Quit casainho (Remote host closed the connection) 16.25.32 Quit B4gder (Quit: Konversation terminated!) 16.25.48 # pamaury, jhMikeS: The infamous transient Clip filesystem corruption over USB bug is back. I had one recent occurrence with r29506 on my ClipV2 and a few occurrences with r29583 on a Clip+ I had available for testing for a day 16.25.48 # jhMikeS' commit r29492 could be a possible candidate for having reintroduced this problem 16.27.22 # I found no other change fiddling with the AMSv2 USB driver 16.27.25 # sideral: this commit was supposed to not change anything 16.27.35 Join esperegu_ [0] (~quassel@145.116.15.244) 16.27.38 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.27.56 # or else there is still some concurrency problem somwhere 16.28.28 Quit esperegu (Read error: Operation timed out) 16.28.28 # pamaury: maybe the underlying semaphore mechanism has a problem? Sounds unlikely though... 16.29.51 # right now I can't reproduce this reliably. When I can, I'll try bisecting the change history 16.33.42 # pamaury: BTW, using an extended version of your log-open-files patch, I still haven't found a single case of a file accidentally left open _for writing_ 16.34.20 # so filesystem corruption cannot occur due to this 16.34.26 Quit sideral (Remote host closed the connection) 16.35.03 Join sideral [0] (~sideral@213.165.85.248) 16.35.04 Quit sideral (Changing host) 16.35.04 Join sideral [0] (~sideral@rockbox/developer/sideral) 16.35.19 # right 16.35.29 # are there still filesystem corruption cases ? 16.36.55 # In short, no. I've had some, but I think these were cases where the host wrote out stuff that already was corrupted during the USB read 16.37.42 # But I observed file-handle leakage due to current audio file + font not having been closed on USB connect 16.38.26 # this happens when connecting / disconnecting multiple times when the DB is committing and thus not responding to the USB events for a while 16.38.37 # even if left open files don't corrupt the disk they are a problem due to the file handle being possibly invalid after usb disconnect 16.38.48 Join bmbl [0] (~bmbl@unaffiliated/bmbl) 16.39.28 # the handles aren't touched again AFAICT (font + audio files are reopened with new handles), but they leak a handle slot 16.40.40 Join akzfowl [0] (~akzfowl@1.186.2.43) 16.42.22 # JdGordon|: any chance a somewhat recent change could overwrite current_vp, triggering a data abort in clear_pixel? 16.42.58 # the value of current_vp seems to be completely garbage, but always the same 16.43.14 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 16.44.08 Quit pamaury (Quit: Page closed) 16.46.18 # JdGordon|: nevermind, it isn't current_vp, but rather a pointer to it (in a local constant pool) that gets trashed 16.48.39 Quit simonrvn (Ping timeout: 248 seconds) 16.48.59 Join kevku [0] (~kevku@2001:7d0:0:f9af:babe:feed:dead:beef) 16.50.44 Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) 16.51.04 Quit akzfowl (Ping timeout: 276 seconds) 16.54.44 Quit Keripo (Quit: Leaving.) 16.55.21 Join akzfowl [0] (~akzfowl@1.186.2.43) 17.00.00 Part Zagor 17.01.39 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.09.12 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.09.16 Quit timccc (Ping timeout: 276 seconds) 17.17.16 Join L-Strife89 [0] (~Strife89@207.144.201.128) 17.29.46 Join Keripo [0] (~Keripo@SEAS037.wlan.seas.upenn.edu) 17.32.37 Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) 17.43.50 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 17.52.11 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 17.52.12 Quit bertrik (Changing host) 17.52.12 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 17.52.43 Join LambdaCalculus37 [0] (~3f74f70d@rockbox/staff/LambdaCalculus37) 17.56.04 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.58.53 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 17.59.03 Quit pamaury (Changing host) 17.59.03 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.01.34 Join efyx_ [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 18.01.44 Quit efyx (Read error: No route to host) 18.05.25 Join GeekShadow [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) 18.05.26 Quit GeekShadow (Changing host) 18.05.26 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 18.10.29 Quit factor (Quit: Leaving) 18.11.10 Join factor [0] (~factor@75.108.68.114) 18.12.21 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 18.12.52 # ok, further analysis suggests that said data abort seems to only occur with unicode languages 18.13.05 Quit n1s (Quit: Ex-Chat) 18.13.06 # (japanese, korean, ...) 18.13.15 # ideas? 18.14.21 # TheSeven, I didn't follow the discussion, but I guess unicode languages experience buffer overflow much more easily because the unicode takes more space 18.16.20 *** Saving seen data "./dancer.seen" 18.16.59 # hm, and I still can't reproduce it myself 18.28.41 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.29.09 Quit mshathlonxp (Read error: Connection timed out) 18.29.52 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 18.30.02 Quit LambdaCalculus37 (Quit: CGI:IRC 0.5.9 (2006/06/06)) 18.33.12 Join esperegu [0] (~quassel@145.116.10.163) 18.33.47 Quit esperegu_ (Ping timeout: 252 seconds) 18.35.24 Quit esperegu (Read error: Connection reset by peer) 18.38.33 Join esperegu [0] (~quassel@145.116.10.163) 18.40.15 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.53.37 Quit MethoS- (Read error: Operation timed out) 18.54.23 Join MethoS- [0] (~clemens@134.102.106.250) 18.55.10 Quit esperegu (Remote host closed the connection) 18.56.22 Join madalu [0] (~matt@unaffiliated/madalu) 19.05.37 # sideral: if r29492 caused a regression then there's a bug for all targets most likely 19.06.37 # jhMikeS: possibly, but it sounds unlikely. Do you have any other idea on what might have reintroduced the issue? 19.07.21 # r29492 was just a guess because it touches the AMSv2 USB driver in a nontrivial way 19.08.03 # and because it addresses an area that was known to cause the problem before (synchronization) 19.10.14 # jhMikeS: BTW & unrelated, I found another person who has trouble with the r29169 SD driver changes: See FS#11965 19.10.55 # functionally r29492 is utterly equivalent, assuming nothing wrong with the sem implementation. I'm giving that another look just to be sure. 19.11.11 # Thanks! 19.12.04 # sideral: is that SD stuff something sporadic? btw, did you try upping those counts to see what it takes to make it function again? 19.12.32 # what I meant was: all clip+ or just some particular units? 19.12.45 # The SD problem was highly reproducible, not sporadic. No, I didn't have time yet to dive into this with any depth. 19.13.20 # Don't know whether it's specific to my ClipV2. 19.13.34 Join tuma [0] (~tuma@halava.cc.jyu.fi) 19.13.36 # It may depend on the SD storage medium that's put into the device 19.14.01 # by the manufacturer or (on devices with an SD slot) by the user 19.14.11 Quit tuma (Client Quit) 19.15.26 # FS#11965 was about an external SD on a FuzeV2 19.15.57 # or was it? Checking... 19.16.04 # I recall at the time with e200, JdGordon had an SD card that needed unusually long delay before using it, so yeah, they can vary. 19.16.26 # No, FS#11965 is about the internal SD of a FuzeV2 19.17.43 Join tuma [0] (~tuma@halava.cc.jyu.fi) 19.18.07 # might be nice to know if it's a variant thing. mine's a variant 0. 19.19.10 # You could ask the FS#11965 OP 19.19.15 # any android users around? Have anyone found similar behaviour as I in http://www.rockbox.org/tracker/task/12006 19.19.36 # jhMikeS: The r29169 changes don't look very variant-dependent 19.23.10 # They're not but why the need for the infinite loop? v1 doesn't have it. I try my v2 fuze with code like the v1 and all is fine. 19.23.17 # jhMikeS: Re delays... There's also FS#11870, in which user report success with a simple workaround patch that introduces a delay in the AMSv2 SD driver 19.23.28 # s/user/users/ 19.24.18 # jhMikeS: Perhaps it just needs a few more retries / longer delays. Very probably not an infinite loop, or otherwise it wouldn't ever work :) 19.24.30 # moving too quickly on init can be a problem, yes 19.24.57 # I seem to remember from earlier IRC discussions that Rockbox's implementation of SD wasn't quite complete? 19.25.17 # the problem on v1 was that in wait_for_tran_state, the first would succeed but it would get stuck forever failing just before doing DMA 19.25.41 # s/v1/v2/ 19.26.54 # One curious observation I made with r29169 was that reading sectors with high sector counts was more likely to fail 19.26.57 # perhaps. I haven't gotten too deep myself actually. One thing is, both v1 has the same bug as far as inititializing a card when USB is connected. 19.27.09 # How much memory does your FuzeV2 have? 19.27.22 # 4gb 19.27.35 # my failing ClipV2 has 8 GB 19.27.36 # I noticed bank switching isn't implemented 19.27.44 Quit t0rc (Remote host closed the connection) 19.28.12 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.28.35 # Never heard of bank switching in the context of SD. Care to explain or point me somewhere to read up? 19.30.10 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 19.30.23 Quit factor (Read error: Connection reset by peer) 19.30.25 # if it's not SDHC, then yes you need to bank switch. the pp and v1 drivers do it. 19.30.30 # on amsv1 the sd is implemented a bunch of 2GB SD-not HC banks 19.35.10 # I see. But w/o r29169 it just works, so that doesn't seem to be the issue 19.35.33 Quit mcuelenaere (Remote host closed the connection) 19.36.40 # presumably they updated the AMSv2 chips with SDHC support 19.37.54 # yeah -- as evidenced by their support of SDHC cards (Clip+, FuzeV2) 19.38.23 # thats not the same thing 19.38.40 # they had an SDHC driver on AMSv1 too, but the underlying SD bridge chip was still plain SD 19.38.53 # I see 19.39.38 # still, why would high-numbered sectors fail with higher likelihood when retrying less? sounds like a weird timeout problem 19.39.51 # sideral: Incidentally, have you seen the various database bugs in 3.8 reports/on forum? 19.39.59 # It is something since 3.7.1 19.40.35 # sideral: what's interesting is that it's not limited to USB 19.40.39 # AlexP: No, I haven't. I don't follow the forums as much :( But I have helped two people with DB problems here, and in each case it wasn't the DB that was at fault 19.41.08 # there have been quite a few reports of it failing, and working fine on 3.7.1 19.41.13 # AlexP: In each case, an unrelated problem that made the DB crash 19.41.46 # AlexP: The DB is the 1st thing to do some nontrivial computation after boot, so I guess it typically fails first if something's wrong 19.42.10 # http://forums.rockbox.org/index.php/topic,27339.0.html for instance 19.42.48 # ah, I see you have seen the bug report linked from there 19.43.03 # So anyway, I guess all the reports from the forums are this same bug 19.43.05 # In the two cases I've been handholding here, one was the PP ATA DMA problem, and the other was the r29169 change we're discussing right now. In each case, the DB crashed during commit 19.43.23 # OK 19.43.57 # AlexP: I would follow the forum if it was exported via NNTP :) 19.43.58 Quit liar (Ping timeout: 276 seconds) 19.44.09 # or mailing list 19.44.49 # jhMikeS: right, the SD problem is not USB-specific. I just triggered it with an fsck run on the host, via USB 19.46.15 # AlexP: The DB is better than its reputation ;) 19.46.17 # anybody know how large of an SD card the sansa clip+ can take? 19.46.19 # sounding more and more like timing is an issue :\ 19.46.31 # sideral: Hmmm :) 19.47.17 # alexbobp: I've heard people report success with 32 GB 19.47.32 # it's like Chuck Norris? 19.47.48 Join factor [0] (~factor@75.108.68.114) 19.47.57 Quit niekie (Read error: Operation timed out) 19.47.58 # jhMikeS: in which way? 19.48.09 # better than its reputation :) 19.48.15 # ah :) 19.50.24 Join niekie [0] (~niek@CAcert/Assurer/niekie) 19.50.54 Quit benedikt93 (Quit: HIP-HOP sounds best when you listen to METAL instead.) 19.52.15 # sideral: is the SD issue expected to be specific to newer devices? 19.52.23 # i haven't been able to reproduce any disk trouble at all 19.52.33 Quit niekie (Read error: Operation timed out) 19.53.23 # saratoga: I have no good idea, but as it affects my ClipV2 (which is older than the Clip+), I'd say No 19.53.50 Quit japc (Ping timeout: 276 seconds) 19.54.07 Join niekie [0] (~niek@CAcert/Assurer/niekie) 19.54.20 Quit Keripo (Quit: Leaving.) 19.56.11 Quit GeekShadow (Read error: Connection reset by peer) 19.59.34 Quit mshathlonxp (Ping timeout: 276 seconds) 20.00.52 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 20.02.30 Quit saratoga (*.net *.split) 20.04.05 Join Keripo [0] (~Keripo@law055.wireless-pennnet.upenn.edu) 20.04.22 Join u42p [0] (~v35b@d053198.adsl.hansenet.de) 20.07.31 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 20.12.36 Join Lear [0] (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net) 20.14.54 Join Buschel [0] (~chatzilla@p54A3B2DD.dip.t-dialin.net) 20.16.19 Join afk [0] (~Dre@92.18.110.105) 20.16.23 *** Saving seen data "./dancer.seen" 20.16.45 Nick afk is now known as Guest18558 (~Dre@92.18.110.105) 20.17.07 Quit Ypsy_ (Ping timeout: 276 seconds) 20.19.43 Quit Dreamxtreme (Ping timeout: 276 seconds) 20.19.59 Join niekie_ [0] (~niek@CAcert/Assurer/niekie) 20.20.03 Quit niekie (Ping timeout: 264 seconds) 20.21.20 Join Ypsy [0] (~ypsy@geekpadawan.de) 20.21.31 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 20.26.41 # * [Saint] finds "rocklock" due to a forum post and has a play. 20.27.12 # <[Saint]> ....it'd be really nice to not only launch it with autorock, but also on idle timeout...if I can get that working, I'll be pretty pleased with myself. 20.27.59 # <[Saint]> it seems it could easily be subverted by anyone with a clue about rockbox, though. 20.28.24 # <[Saint]> I guess the idea is to protect against those without a clue. ;) 20.32.04 Quit niekie_ (Quit: No Ping reply in 180 seconds.) 20.32.11 Join niekie [0] (~niek@CAcert/Assurer/niekie) 20.32.38 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.40.16 Join n1s [0] (~n1s@nl118-175-108.student.uu.se) 20.40.16 Quit n1s (Changing host) 20.40.16 Join n1s [0] (~n1s@rockbox/developer/n1s) 20.43.49 Quit stripwax (Read error: Connection reset by peer) 20.48.33 Quit L-Strife89 (Ping timeout: 246 seconds) 20.48.43 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.48.51 Join NightStar3 [0] (~NightStar@216-58-30-122.cpe.distributel.net) 20.48.59 Part NightStar3 20.54.16 Quit stripwax (Ping timeout: 255 seconds) 20.57.13 Quit kugel (Remote host closed the connection) 20.57.14 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 21.01.32 Join TheLemonMan [0] (~lem0n@ppp-89-130.98-62.inwind.it) 21.13.16 Quit sideral (Quit: Leaving.) 21.13.33 # kugel_: have you noticed my android bug ( http://www.rockbox.org/tracker/task/12006 ) 21.14.19 # I am wondering if anyone else caught this bug. 21.16.31 # <[Saint]> tuma: I believe this is a known problem, it should have been resolved iiuc though. 21.16.55 Quit mshathlonxp (Ping timeout: 276 seconds) 21.17.55 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 21.18.10 # tuma: is it really that playback doesn't start or "only" that you don't hear anything (maybe playing time and progress bar doesn't move either, not sure about that)? 21.18.29 # <[Saint]> Zagor: http://www.datafilehost.com/download-613bfad5.html <-- 14~30ox DroidSans/-Bold.ttf converted to .fnt 21.18.47 # thanks 21.18.50 # pixelma, playback is not advancing 21.18.54 # <[Saint]> Zagor: Please let me know if you need a larger size, this was all I had time for lasty night. 21.19.00 # <[Saint]> *last 21.19.09 # tuma: but the WPS is shown, right? 21.19.58 # pixelma, yes 21.20.46 # I guess that's the same thing I see too 21.21.21 # [Saint]: oh, yes I do. 30px is too small. 21.22.25 # <[Saint]> Zagor: I suspected so, how large exactly? 21.22.43 # I don't know, 40-50 perhaps 21.23.05 # <[Saint]> I will convert sizes 30 through 50 presently, and then ping you when I'm done. 21.23.13 # ok 21.23.20 # pixelma, is there any workaround, fix suggestion/anything? 21.23.38 # tuma: how old is your build? 21.23.59 # zagor, not old.. from last friday 21.26.30 Quit Keripo (Quit: Leaving.) 21.27.58 # tuma: how many different mp3 files have you tried with? 21.28.20 Part u42p ("Leaving") 21.28.27 # if it's a problem with the tag reading code, files encoded by different programs might differ 21.28.29 # it's not specific to certain files 21.28.35 # Zagor: I tried mostly SPX and OGG files, several of them 21.28.36 # in my case 21.28.53 # it's just that audio stops working out of the blue 21.29.06 # stops, or does not start? 21.29.45 # the bug report says they never start 21.29.47 # maybe doesn't start as I usually see it after manual track skips 21.31.18 Join Don_Ferro [0] (~eric@pool-108-2-179-220.phlapa.east.verizon.net) 21.31.57 # zagor: I have faced both. stopping suddenly and not even starting 21.32.25 # (today I faced sudden stopping, that's why there is nothing about that in bug report) 21.33.26 Join fkhodkov [0] (~fedor76@ppp-78-24-25-163-bras0.istra.ru) 21.34.36 # Hello 21.38.05 # tuma: any chance you can supply a short sample file that triggers this? 21.38.27 # I have a 1.6 and a 2.3 phone and neither show this problem 21.39.27 # Zagor: I can supply a file, but to me it seems that any file causes this.. wait a moment. 21.40.01 # tuma: yes, it's just a precaution to avoid chasing the wrong bug. 21.41.30 Join merbanan [0] (~banan@c-62-220-165-78.cust.bredband2.com) 21.42.07 Quit bmbl (Quit: Verlassend) 21.44.45 Join Keripo [0] (~Keripo@eng066.wireless-resnet.upenn.edu) 21.45.06 # Zagor: that was the only thing I noticed so far when playing around with adb logcat - http://www.rockbox.org/irc/log-20110312#13:51:34 - but I couldn't reproduce today when I wanted to repeat the experiment 21.45.43 # I believe bluebroth3r reported that problem too with some stock Android version and vanishing with cyanogenmod 21.45.58 # Sorry to bother you guys but are some players better with rockbox than others? 21.47.18 # pixelma: I see that too, but don't have any problems 21.48.15 # ok, have to try again then. Maybe I was missing something 21.48.25 # Don_Ferro: some objectively so, others it depends on your priorities I guess 21.49.18 Join JesusFreak316 [0] (~JesusFrea@pool-173-65-71-72.tampfl.fios.verizon.net) 21.49.43 # "AudioHardwareInterface serves as the glue between proprietary audio drivers and the Android AudioFlinger service." 21.49.53 # So bassically it depends on the features I am looking for? 21.50.10 # so the message might just mean the driver was being slow 21.50.51 # TheSeven: i got rockbox installed and working now via booting a rockbox image in the dfu bootstrap thing but usb is still not working (ipod seems to lock up when connecting usb in rockbox now) 21.50.52 # Don_Ferro: more or less, so long as the port is mature enough it depends on the hardware capabilities 21.51.15 # pixelma: yes, this sounds pretty much like the issue I was experiencing 21.51.19 # usb after a reboot that is, it works fine when started from the dfu thing 21.51.48 # dammit 21.51.56 # so that's the same problem that the other guy had... 21.52.19 # and i have absolutely no clue what's going on 21.53.31 # the vcore is the same as OF in the new iloader? 21.54.00 # no, but I doubt that this is the cause 21.54.11 # is it easy to test? 21.54.19 # well, it needs recompiling 21.54.20 # How well does the clip+ work on it? I need something to play MP3s/OGGs/FLACs in my car since my fuze broke. 21.54.59 # TheSeven: could it be set inside rockbox as a test? 21.55.08 # in theory, yes 21.55.17 # you just need to write to an i2c device 21.55.36 # the beast seems it could have a hw bug in the charger, just yesterday I booted with it plugged and the charge current was _way_ over what it should be for the vbatt yet the register setting were correct. In a few minutes the charging code detect a problem and errored. 21.56.02 # otherwise, look for pmu_init in emcore/trunk/target/ipodnano3g/pmu/pmu.c and comment the i2c writes for Vcore and Vmem 21.56.36 # then, if you never did that before, do a "make" in tools/ucl and tools/elf2emcoreapp 21.56.52 # after that, cd to apps/installer-ipodclassic 21.56.56 Join salty-horse [0] (~ori@bzq-79-183-2-196.red.bezeqint.net) 21.57.00 # TheSeven: ok, i don't even have a checkout of that stuff yet 21.57.03 # run the following: 21.57.10 # http://users.jyu.fi/~tuma/Jer34.spx 21.57.11 # Buschel, thanks for the mp3 parsing work :) 21.57.24 # Zagor, that's the example spx file 21.57.28 # thanks 21.57.33 # ../../tools/ucl2e10singleblk flashfiles/rockbox.ipod.ucl 21.57.37 # make flashfiles 21.57.38 # make 21.57.39 # salty-horse: thanks, but it's not finished yet :) 21.57.58 # during the "make flashfiles", you need to have an ipod connected, running emcore (for example the boot menu) 21.58.16 # er, for the classic that's during "make", not "make flashfiles" 21.58.42 # after that process, you should find a file called apps/installer-ipodclassic/build/installer-ipodclassic.ubi 21.59.45 # Oh and another question, is rockbox based on linux/bsd? Just wondering for curiosity's sake. 21.59.53 # nope 22.00.03 # it has its own kernel that was written from scratch 22.01.33 # ok cool. 22.02.39 # hmm. What does happen if TTSSapi::voice() is called from two different threads? 22.02.48 # domonoky: ping 22.03.00 # pong 22.03.46 # domonoky: I'm trying to understand the multicore TTS issue. TTSSapi::voice() looks quite suspicious to me. 22.04.02 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 4.0/20110303194838]) 22.04.34 # I'm considering to rewrite the voicing part: decide how many cores to use, then create that number of threads. Use a function that does both voicing and encoding in the same run. 22.05.24 # by splitting up into multiple lists before starting the processsing we shouldn't need any synchronization. I'm assuming that voicing each string takes the same amount of time (which is obviously not true, but shouldn't be too much of either) 22.05.31 # TheSeven: the elf2emcoreapp configure complains about missing bfd.h but tells me i shouldn't use the system header so what should i use? 22.05.47 # also, create a separate TTS and encoder object for each thread instead of sharing one. 22.05.53 # oh, forgot about that one 22.05.59 # do you see a problem with creating multiple TTS objects? 22.06.02 # you need to steal that from rockboxdev.sh's build process 22.06.05 # that's a bit nasty 22.06.14 # see the README for the exact configure command 22.06.21 # I just got the bug, and log message "W/AudioTrack(25741): obtainBuffer() track 0x29c4c8 disabled, restarting" repeating 22.06.40 # you need bfd.h and libbfd.a from the binutils build_dir 22.06.42 # bluebroth3r: its very likly that it will fail if it is called concurrently... but TTSSapi doesnt give the RunInParallel flag in capabilites.. so it should be called single-threaded.. 22.07.14 # the "pre-forked" approach? guess you'd need that if the TTS can't handle it. 22.07.25 # TheSeven: aha 22.07.50 # well, looking at Process Explorer clearly shows that both cores are maxed out. The only explanation I have for that is that QtConcurrent is creating multiple threads. 22.08.10 # bluebroth3r: i am not sure if all TTS system can cope with creating multiple TTS objects.. 22.08.29 # I'm unable to trigger it again though 22.08.29 # bluebroth3r: well that means the limiting somehow doesnt work ? 22.09.02 # domonoky: looks so to me at least. 22.09.40 # it should set the maxThreadCount to 1 ẃith TTSSapi voices.. 22.10.19 Quit ender` (Quit: Kids. You gotta love them. I adore children. A little salt, a squeeze of lemon--perfect. -- Harry Dresden) 22.10.31 # though interestingly then printing the thread ID in the processing function it always show the same id. 22.10.35 # the rbutil system log should have a line saying how many threads are used.. 22.10.41 # hmm, i'll do this tomorrow 22.10.41 # maxThreadCount is set to 1 :/ 22.11.14 # my local copy has such a line :) 22.11.29 # its probably using the main-thread and one worker thread... the main-thread uses all idle-time on one cpu in the while loop (with processEvents) 22.11.31 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 22.11.37 # jhMikeS: ping 22.11.50 # quite possible. 22.12.10 # urgh, segfault when running it with external espeak in the debugger :( 22.12.36 # wodz: pong 22.13.05 # zagor did you try the file? 22.13.16 # tuma: yes, it works. but it's full of gibberish ;-) 22.13.43 # :D 22.14.09 # but feel free to try to improve the voicing system, just be carefull with all those different voice engines :-) 22.14.14 # jhMikeS: in wm8978 driver there is attenuation at dac level due to 3d function but there is no gain raise at output stage - is it intentional? 22.14.37 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 22.14.41 Join ender` [0] (krneki@foo.eternallybored.org) 22.14.46 # domonoky: I think fixing the TTS issue would be a good thing :) 22.15.30 # bluebroth3r: yes it would be a good thing. I just dont have any time to help with it. 22.15.30 Quit ender` (Read error: Connection reset by peer) 22.15.34 # zagor, so the conclusion is? I am the only one facing this bug? 22.15.39 # too bad :( 22.15.46 Join ender` [0] (krneki@foo.eternallybored.org) 22.16.06 # tuma: no, it appears others get it. I got something like it a few minutes ago, but I can't repeat it 22.16.25 *** Saving seen data "./dancer.seen" 22.16.48 # wodz: yes, it would clip if I didn't do that, so I picked the attenuation to what sounded like to me a constant volume regardless of the setting 22.16.54 # so the difference is that I get it very often as some other people like you get it less often 22.18.48 # before moving from eclair to froyo I don't remember ever having this problem 22.19.09 # wodz: Does the wm8751 clip if 3d is turned way up? 22.19.25 # jhMikeS: yes 22.21.05 Join DerPapst [0] (~Alexander@p5DE5B5B7.dip.t-dialin.net) 22.22.56 Quit Keripo (Quit: Leaving.) 22.28.42 Join L-Strife89 [0] (~Strife89@168.16.236.89) 22.29.03 # tuma: I'm running 2.1 and see it quite often too, considering the time I actually use Rockbox on the phone 22.29.20 # * Buschel needs some testers for FS#12007 22.32.24 # Buschel: I have some VBR files that report as 3-4 times too long as well 22.32.31 # Buschel: I saw one odditiy with MP3 tag parsing on my Ondio - the title tag wasn't read (my WPS fell back to the "missing title tag" line) on files that had itunes gapless tags (which hwcodec probybly couldn't deal with correctly anyway). I know it's possible the parsing goes different ways than on swcodec and only ask if you have an idea because you started looking into metadata recently 22.33.27 # jhMikeS: is this an effect of the patch or is it happening with plain svn? 22.33.50 # plain SVN 22.34.06 # might this address that too? 22.34.07 Join Jerom [0] (~jerome@79.132.59.245) 22.34.16 # pixelma: might be hard to figure out... 22.35.18 # jhMikeS: depends... if this is an effect of a vbr file w/o vbr-header the patch will not fix it 22.35.28 # I'm guessing it might be underestimating the actual bitrate 22.35.48 # They were encoded on the same encoder as all my other stuff 22.36.26 # jhMikeS: yes. just check the patch with your file and file a (new) bug report if it is not fixed. 22.37.41 # I'll try it out. Just have to patch and build. 22.39.40 # If I did somehow end up without the headers, I have no clue how that happened 22.40.22 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.40.55 # I get failed hunks in mp3data.c 22.41.15 # you patch against current svn? 22.41.37 # hold, on...maybe not :D 22.41.44 # I submitted two changes yesterday as preparation 22.42.14 Quit Stummi (Quit: Bye!) 22.46.02 # heh, that one checkout was way farther behind than I thought 22.49.23 # pixelma: can you check the v07 patch in FS#12007 on your Ondio as well? It does some changes to mpeg.c 22.49.41 Join japc [0] (~japc@bl21-168-102.dsl.telepac.pt) 22.49.53 # (which is only compiled for !SW_CODEC) 22.52.14 Quit efyx_ (Quit: Quitte) 22.57.45 Quit TheLemonMan (Quit: Destructor called) 22.58.29 # it looks like the obtainBuffer log message is caused by pcm buffer underrun 22.58.30 Join Keripo [0] (~Keripo@eng066.wireless-resnet.upenn.edu) 23.07.49 Join JdGord [0] (~AndChat@pa58-109-194-92.pa.vic.optusnet.com.au) 23.08.18 Quit Don_Ferro (Remote host closed the connection) 23.09.31 # gotta get some sleep now. jhMikeS, pixelma: just leave me a message in the logs if you have any observations or remarks regarding FS#12007 23.09.34 # bye 23.09.40 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.15/20110303024726]) 23.13.09 Quit domonoky (Read error: Connection reset by peer) 23.13.25 # <[Saint]> Zagor: JdGordon|: pixelma: kugel_: and anyone else that wants it: http://www.datafilehost.com/download-324015f4.html <-- Anti Aliased font pack, 14-50px (in 2px increments (14-16-18...etc.)), 'DroidSans/-Bold.ttf'. 23.17.07 # <[Saint]> Zagor: Can you let me know if any of those fonts look particularly crappy for some reason so I can fix it please? 23.17.14 # jhMikeS: how does 3d setting is shown on beast? 0-100% or 0-15 ? 23.17.34 # wodz: 0-100% 23.18.35 Quit [Saint] (Quit: BRB, restarting comp) 23.18.38 # hmm, I can't figure out where the conversion takes place 23.19.11 # in sound_val2phys 23.19.27 # yes, but where it is called 23.19.43 # in the menu api somewhere 23.19.52 Join [Saint] [0] (S_a_i_n_t@203.184.0.75) 23.20.34 # the setting function, rather (forgot what it's called) 23.21.36 Join stoffel [0] (~quassel@p57B4B2AF.dip.t-dialin.net) 23.21.39 # apps/gui/option_select.c 23.23.48 # [Saint]: they look ok. not perfect kerning, of course, but ok. 23.24.08 Quit japc (Read error: Operation timed out) 23.24.32 # <[Saint]> Zagor: Is the spacing between characters ok? 23.24.44 # <[Saint]> that's my major concern. 23.24.55 # I'd say it's as good as can be expected without kerning 23.25.03 # jhMikeS: Why the code duplication in sound_val2phys - one is defined in wm8978 the second in sound.c. Only one is compiled but both have cases for this codec 23.27.30 # wodz: that one handles the sim because the actual audio driver isn't compiled for a sim (yes, it's a been a bit of a mess for awhile). 23.29.19 # <[Saint]> Zagor: Ok, thanks. Good to know. I had to adjust the command line options for each individual font, both to adjust ascent/descent and to adjust the character spacing. The default for convttf is to use no character spacing at all, which makes things *very* hard to read. 23.29.44 # jhMikeS: it is extremely hard to follow in current form :/ 23.29.44 # that's a rather odd default 23.30.12 # <[Saint]> well...I guess there's no way of knowing how much spacing to apply. 23.30.38 # no, but 1 pixel seems a saner default than 0 23.33.28 Quit bertrik (Quit: :tiuQ) 23.34.33 Quit JdGord (Read error: Connection reset by peer) 23.37.03 Quit mshathlonxp (Quit: Leaving) 23.37.14 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 23.39.10 Quit mshathlonxp (Client Quit) 23.39.24 Join mshathlonxp [0] (~msh@5acba089.bb.sky.com) 23.44.17 Join japc [0] (~japc@2.82.168.102) 23.49.34 Quit iq (Read error: Operation timed out) 23.59.00 Quit GeekShadow (Read error: Connection reset by peer)