--- Log for 23.07.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 days and 4 hours ago 00.00.20 Join krazykit [0] (~krazykit@206.183.185.8) 00.01.09 Join Easior [0] (~Easior@27.115.42.251) 00.02.53 Quit Easior (Client Quit) 00.12.15 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 00.20.05 Join Strife1989 [0] (~Strife89@207.144.201.128) 00.24.48 # http://www.androidpolice.com/2011/07/21/developers-can-now-upload-multiple-apks-per-android-market-app-listing/ is this relevant for us? 00.25.22 # yes 00.26.37 # I now see that it is old news. Sorry if it's been discussed :) 00.27.18 # I don't know if it was discussed before 00.28.44 # I assume it means we don't need resolution-independence? 00.29.06 Quit mshathlonxp (Ping timeout: 240 seconds) 00.29.31 Join mshathlonxp [0] (~athlonmpp@5ad4ef88.bb.sky.com) 00.31.43 Join L-Strife89 [0] (~Strife89@207.144.201.128) 00.34.57 Quit robin0800 (Quit: Leaving) 00.35.30 Quit Strife1989 (Ping timeout: 258 seconds) 00.44.44 # not sure if it actually covers specific resolutions 00.44.55 # the market match expressions for screen sizes normally are categories, not numbers 00.48.09 Quit z180 (Ping timeout: 258 seconds) 00.53.59 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110713171652]) 00.59.29 Quit Thra11__ (Remote host closed the connection) 01.02.24 Join Strife1989 [0] (~Strife89@207.144.201.128) 01.05.57 Quit domonoky1 (Read error: Connection reset by peer) 01.06.05 Quit L-Strife89 (Ping timeout: 258 seconds) 01.07.14 Quit Unhelpful (Ping timeout: 252 seconds) 01.07.54 Join Thra11 [0] (~thrall@14.75.113.87.dyn.plus.net) 01.08.32 Quit simonlnu (Quit: .) 01.09.54 Join dhrasmus [0] (~dhrasmus@216.99.208.34) 01.11.49 Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) 01.12.01 Quit Poodlemastah (Client Quit) 01.12.54 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.17.50 Quit Unhelpful (Ping timeout: 260 seconds) 01.18.00 Quit drezon (Quit: So long and thanks for all the fish) 01.21.58 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.24.06 Quit keyb_gr (Ping timeout: 240 seconds) 01.27.15 Quit Unhelpful (Ping timeout: 252 seconds) 01.28.08 Quit bertrik (Quit: :tiuQ) 01.28.39 Join keyb_gr [0] (~chatzilla@p4FF0496D.dip.t-dialin.net) 01.34.27 Quit mudd1 (Quit: Ex-Chat) 01.35.19 Quit keyb_gr (Ping timeout: 252 seconds) 01.36.19 Quit dhrasmus (Quit: Leaving) 01.46.14 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 01.56.54 *** Saving seen data "./dancer.seen" 01.59.55 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 02.00.29 Quit Transformer (Excess Flood) 02.11.58 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 02.13.02 Quit Unhelpful (Remote host closed the connection) 02.21.37 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 02.28.25 Quit Unhelpful (Ping timeout: 260 seconds) 02.31.21 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 02.37.23 Quit Unhelpful (Ping timeout: 255 seconds) 02.40.35 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 02.43.35 Quit pamaury (Remote host closed the connection) 02.52.40 Quit Thra11 (Ping timeout: 240 seconds) 02.53.33 Quit Unhelpful (Ping timeout: 264 seconds) 02.56.37 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 03.04.54 Join mshz [0] (~athlonmpp@5ad4ef88.bb.sky.com) 03.05.02 Quit mshathlonxp (Disconnected by services) 03.05.05 Nick mshz is now known as mshathlonxp (~athlonmpp@5ad4ef88.bb.sky.com) 03.05.44 Quit fdinel (Ping timeout: 255 seconds) 03.10.54 Quit madskiny (Quit: Connection reset by a small mexican with wirecutters.) 03.13.25 Join madskiny [0] (dre@gateway/shell/xzibition.com/x-lgdcybxnvexdtewr) 03.23.15 Quit GeekShadow (Quit: The cake is a lie !) 03.28.06 Quit mshathlonxp (Ping timeout: 240 seconds) 03.37.50 Quit Strife1989 (Ping timeout: 260 seconds) 03.56.57 *** Saving seen data "./dancer.seen" 04.14.12 Quit TheSeven (Disconnected by services) 04.14.26 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.17.57 Quit bluebrother (Disconnected by services) 04.17.59 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 04.21.47 Quit fs-bluebot (Ping timeout: 255 seconds) 04.22.58 Join fs-bluebot [0] (~fs-bluebo@f053154079.adsl.alicedsl.de) 04.32.56 Quit Unhelpful (Ping timeout: 276 seconds) 04.47.53 Quit kadoban_ (Ping timeout: 255 seconds) 04.47.59 Quit pixelma (Disconnected by services) 04.48.00 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.48.22 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.48.26 Quit amiconn (Disconnected by services) 04.48.27 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.48.44 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.51.17 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 04.51.24 Quit Unhelpful (Remote host closed the connection) 04.51.55 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 04.56.59 Quit Unhelpful (Read error: Connection reset by peer) 05.05.52 # <[Saint]> re: Market/multiple .apks...aren't the size categories for the drawable sections of an .apk simply l/m/hdpi as opposed to any one given resolution? 05.09.24 Quit B4gder (Read error: Connection reset by peer) 05.10.50 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 05.10.50 Quit Bagder (Changing host) 05.10.50 Join Bagder [241] (~daniel@rockbox/developer/bagder) 05.13.10 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 05.19.44 Quit Unhelpful (Ping timeout: 240 seconds) 05.22.24 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 05.50.15 Quit evilnick (Ping timeout: 260 seconds) 05.52.53 Join Rob2222 [0] (~Miranda@p4FFF2992.dip.t-dialin.net) 05.56.44 Quit Rob2223 (Ping timeout: 258 seconds) 05.57.01 *** Saving seen data "./dancer.seen" 06.14.59 Quit krazykit (Ping timeout: 276 seconds) 06.25.57 Join krazykit [0] (~krazykit@206.183.185.8) 06.25.58 Join Horschti [0] (~Horscht@xbmc/user/horscht) 06.29.21 Quit Horscht (Ping timeout: 246 seconds) 06.30.06 Quit krazykit (Ping timeout: 240 seconds) 06.41.05 Join krazykit [0] (~krazykit@206.183.185.8) 06.48.37 Quit factor (Read error: Connection reset by peer) 06.55.15 Join Strife1989 [0] (~Strife89@207-144-19-39.cstel.net) 07.05.43 Join factor [0] (~factor@74.197.205.204) 07.35.07 Quit saratoga (Ping timeout: 252 seconds) 07.56.54 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 07.57.03 *** Saving seen data "./dancer.seen" 08.04.08 Join robin0800 [0] (~robin0800@149.254.61.30) 08.13.04 Join hskf [0] (~hskf@32.171.148.193) 08.34.11 Join simonlnu [0] (XljQXt6aHW@unaffiliated/simonrvn) 08.34.47 Quit Rob2222 (Read error: Connection reset by peer) 08.35.03 Join Rob2222 [0] (~Miranda@p4FFF2992.dip.t-dialin.net) 08.35.53 Join L-Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 08.38.33 Quit Strife1989 (Ping timeout: 264 seconds) 08.39.37 # Alright, so I've recently acquired a Gigabeat F20 in rather nice shape(even in the box with the receipt :o), and am about to rockbox it. Before I do this though, I'd like to backup the firmware, if I can. I have raw disk access and DD at my disposal, can anybody tell me what sector offset I want to copy? 08.39.55 Quit Zarggg (Quit: Rebooting client...) 08.40.48 # <[Saint]> Why would you want to backup the firmware? A complete uninstallation is possible and should be outlined in the manual. 08.41.16 # <[Saint]> I'd be very surprised if the method for uninstallation requires backing up the entire original FS 08.42.02 # Because I'm lazy and find it less work to use images for restoration. Its not for the sake of uninstalling, its for the sake of being able to start over from scratch if something mucks up down the road, or for simplicity sake when I upgrade the drive 08.42.52 # I have a S30 as well, and if I'd had an image of the original firmware partition on it to work with when I upgraded the drive I'd have had less of a fight with it 08.43.38 # The original firmware is a load of ass anyhow, as seems be standard for DAPs. 08.43.46 # <[Saint]> That method will only work wo restore provided that Rockbox installation *only* touches the disk. 08.44.19 # This isn't for being able to uninstall rockbox, its for the sake of easier upgrading or repair 08.44.31 # I don't know why anyone would ever want to uninstall rockbox :< 08.45.29 # <[Saint]> Yes, I understand that. But what I mean is, you need to guarantee that you can copy the image of *everything* that is modified. There may/may not be some firmware partition that isn't exposed. 08.45.48 # <[Saint]> *s/is modified/may be modified/ 08.45.50 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 08.45.50 # * bluefoxx shrugs, just images the entire disk to start with 08.59.06 # Aside, what is the correct term for the 50-pin connector used in the F20, along with most of the older ipods 08.59.55 # 50-pin ATA 09.01.05 # Danke 09.03.09 # Blech. All the nice big drives are ZIF-40 :< 09.03.39 # well, that is a newer connector... 09.03.48 # if you havent seen this page: http://www.rockbox.org/wiki/HardDriveReplacement 09.04.13 # Yeah, I saw that. I'd figured though that there might be a better term to search ebay with. 09.04.30 # I suppose I can come up with an adapter if I can find the pinouts for either. 09.04.57 # The F20 feels a lot more solidly put together than the S30 does 09.07.07 # * [Saint] isn't sure if there is such an adapter (40-to-50pin ZIF), but may be wrong. 09.08.20 # [Saint]: other way around, and yes there is 09.08.46 # http://www.rockbox.org/wiki/ZIFToATAAdapter 09.10.02 # Oh nice. 09.11.12 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 09.11.52 # Might not hurt to have that linked a little more in the wiki 09.11.52 Join Strife1989 [0] (~Strife89@207-144-19-39.cstel.net) 09.12.09 # <[Saint]> "linked a little more"? 09.12.12 # I've spent probably too much time stumbling about it and never seen that before 09.12.15 # <[Saint]> that's what search is for ;) 09.12.50 # bluefoxx: well, it is a wiki - feel free to make a section on the hard drive replacement page linking to that page... 09.15.14 Quit L-Strife89 (Ping timeout: 246 seconds) 09.20.19 Quit wtachi (Quit: &) 09.26.31 Quit hskf (Quit: Bye) 09.27.45 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.29.03 Quit sasquatch (Quit: WeeChat 0.3.5) 09.29.33 Join sasquatch [0] (~username@p4FF2CBEB.dip.t-dialin.net) 09.36.41 Quit robin0800 (Quit: Leaving) 09.38.19 Join mdipolt [0] (~xeniter@85-126-127-58.static.xdsl-line.inode.at) 09.44.21 Join robin0800 [0] (~robin0800@149.254.61.232) 09.44.55 Quit BHSPitMonkey (Quit: Ex-Chat) 09.50.12 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.50.12 Quit bertrik (Changing host) 09.50.12 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.57.04 *** Saving seen data "./dancer.seen" 09.57.32 Join stoffel [0] (~quassel@p57B4C115.dip.t-dialin.net) 10.16.39 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 10.22.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 10.26.59 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 10.37.10 Quit kadoban_ (Ping timeout: 240 seconds) 10.42.16 Quit stripwax (Quit: http://miranda-im.org) 10.42.47 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 10.46.20 Join ntkm [0] (~taku@bmdk6138.bmobile.ne.jp) 10.48.09 Quit n1s (Remote host closed the connection) 10.50.59 Quit ntkm (Client Quit) 10.55.42 Join evilnick [0] (~evilnick@host217-44-128-244.range217-44.btcentralplus.com) 10.55.42 Quit evilnick (Changing host) 10.55.42 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 10.58.00 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 11.00.13 Join [Saint] [0] (~Saint]@124-197-58-10.callplus.net.nz) 11.21.09 # Is Marcin Bukat here? 11.21.41 # * ukleinek intends to push the rk27xx port forward and he seems to be the one who started it 11.21.50 # That's wodz 11.21.52 # So no :) 11.24.08 # AlexP: still helpful, thanks 11.24.27 # He's often here, so just hang around a bit 11.25.37 # AlexP: will do, thanks 11.26.30 # ukleinek: "push" it how? wodz is already doing the work, unless you want to help out? 11.26.54 # JdGordon: yeah, helping out is great 11.27.03 Join Horscht [0] (~Horscht@xbmc/user/horscht) 11.29.17 Quit Horschti (Ping timeout: 255 seconds) 11.29.23 Join Horschti [0] (~Horscht@p5DD56ADB.dip.t-dialin.net) 11.29.23 Quit Horschti (Changing host) 11.29.23 Join Horschti [0] (~Horscht@xbmc/user/horscht) 11.32.24 Quit Horscht (Ping timeout: 258 seconds) 11.34.29 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 11.34.40 Quit pamaury (Changing host) 11.34.40 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.35.09 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 11.37.43 Join ender` [0] (~ender@foo.eternallybored.org) 11.44.08 Quit jhMikeS (Ping timeout: 255 seconds) 11.57.07 *** Saving seen data "./dancer.seen" 12.05.23 Quit Stummi (Quit: Bye!) 12.07.43 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 12.08.10 Quit robin0800 (Quit: Leaving) 12.08.35 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.08.53 Join robin0800 [0] (~robin0800@149.254.61.232) 12.28.44 Quit stoffel (Ping timeout: 276 seconds) 12.33.09 Quit stripwax (Ping timeout: 264 seconds) 12.43.51 # hum, is there a reason why the arm TTB should be in iram rather than dram ? On the fuze+ the mmu doesn't seem to work if I use the dram 12.45.47 Quit JimmyJ (Ping timeout: 255 seconds) 12.46.02 Join JimmyJ [0] (~JimmyJ@unaffiliated/jimmyj) 12.59.25 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 13.02.27 Join stoffel [0] (~quassel@p57B4C115.dip.t-dialin.net) 13.09.30 # pamaury: should not matter AFAICT 13.09.56 # * pixelma isn't sure which way round pamaury meant though 13.10.28 # if I put the ttb in on-chip-ram, it works; if I put the ttb in dram, it doesn't 13.11.14 # and the datasheet doesn't say anything about it afaict 13.12.03 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 13.14.40 Join boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03) 13.22.23 # now the fun begins: fixing all my code to handle the cache commit/discard I forgot 13.24.37 Join keyb_gr [0] (~chatzilla@p4FF0550D.dip.t-dialin.net) 13.45.05 # New commit by 03pamaury (r30198): imx233/fuze+: fix memory size and appextra configuration 13.45.19 # New commit by 03pamaury (r30199): imx233/fuze+: prepare target to enable MMU 13.45.24 # New commit by 03pamaury (r30200): imx233/fuze+: huge rework ... 13.48.34 # r30198 build result: All green 13.49.22 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 13.52.46 # r30200 build result: All green 13.57.09 *** Saving seen data "./dancer.seen" 14.00.37 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 14.01.57 Quit Stummi (Read error: Connection reset by peer) 14.02.05 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 14.04.46 # * bertrik wonders what's left to improve for the ipod nano 1g 14.05.53 Quit robin0800 (Ping timeout: 255 seconds) 14.16.13 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 14.17.00 # I just possibly discovered a semi-hidden features of the imx233 14.17.55 # * ukleinek looks up 14.21.40 # This is extremely weird, the OF seems to make us of it, I found a datasheet with rev 4 which describes it but with ROM TA1 and a datasheet rev 1 which does not describe it but with ROM TA4 :-/ 14.22.39 # what is the hidden feature? 14.23.29 Quit stoffel (Ping timeout: 258 seconds) 14.23.33 # Default First-Level Page Table 14.23.50 # basically, some hardware emulates a 16Kb First-Level Page Table 14.24.01 # but in fact, only a few entries are confiurable 14.24.27 # so if you use a simple memory scheme, you configure the whole MMU with a few bytes and it's faster than any memory 14.25.26 # google "imx233 dflpt" will point you to the datasheet if you are interested 14.28.13 Join stoffel [0] (~quassel@p57B4C115.dip.t-dialin.net) 14.28.21 # In the early stages of a port, a flat memory model is best to start with, right? 14.29.06 # I don't see any advantage to using something different 14.29.19 # appart branch from iram to dram perhaps 14.29.24 # but iram is really small 14.30.28 # and I can't put this fucking page table in the sdram for some reason 14.40.38 Join L-Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 14.44.11 Quit Strife1989 (Ping timeout: 258 seconds) 15.01.07 Quit Stummi (Ping timeout: 250 seconds) 15.02.35 Quit Strife89 (Ping timeout: 276 seconds) 15.06.31 # Does anybody know /anything/ about the hardware-side of the LCD in the V1 series of the Sansa E200? I've got one here thats perfectly good except for a broken screen, and am entertaining ideas of converting it to an in-dash unit for a car, if I can interface a new LCD onto it... 15.19.28 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110713171652]) 15.27.10 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 15.27.59 Join Strife1989 [0] (~Strife89@207-144-19-39.cstel.net) 15.30.09 Quit L-Strife89 (Ping timeout: 264 seconds) 15.32.14 Quit Strife89 (Ping timeout: 260 seconds) 15.48.02 # New commit by 03pamaury (r30201): imx233/fuze+: move page table to dram 15.51.41 Join Lorenzo92 [0] (~50b41b84@giant.haxx.se) 15.52.11 # r30201 build result: All green 15.52.53 Quit Lorenzo92 (Client Quit) 15.57.13 *** Saving seen data "./dancer.seen" 15.58.40 # Am I dreaming or we indeed have nearly 40 implementation of lcd_blit_yuv ? 15.59.02 Join Thra11 [0] (~thrall@46.208.198.247) 16.13.26 # pamaury: wouldn't yoube more worried if we had 40 copies which were vastly different? 16.14.14 # that's precisely what I'm checking currently 16.16.23 Join mgue [0] (~mgue@p5DDA247B.dip.t-dialin.net) 16.34.10 Quit mudd1 (Read error: Operation timed out) 16.36.42 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 16.37.41 Quit stoffel (Ping timeout: 276 seconds) 16.51.40 Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 16.54.58 Join wtachi [0] (~wtachi@cpe-065-190-012-236.nc.res.rr.com) 16.55.20 Quit mc2739 (Quit: Reconnecting) 16.58.16 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 16.59.44 Quit domonoky (Quit: Leaving.) 17.00.00 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.01.04 Quit GeekShadow (Remote host closed the connection) 17.02.34 Join Thra11_ [0] (~thrall@255.40.112.87.dyn.plus.net) 17.03.46 # there are lots of similar-but-slightly-different implementation 17.04.01 # <[Saint]> bluefoxx: I _think_ that the Fuze V1/2 LCDs will mate happily with the E200 17.04.27 # <[Saint]> (they won't have kittens or anything, though... ;)) 17.05.00 # Aw, and here I was hoping for a new pet :< 17.05.15 # Got any links to info on those then? 17.06.01 Quit Thra11 (Ping timeout: 258 seconds) 17.06.26 # [Saint]: wtf gives you that idea? 17.08.25 # I strongly suspect that my fantasies of recycling my old e200 into a rockbox-powered in-dash unit for a car will probably be on hold until I get my hands on a logic analyzer and can play around with the other two I've got... 17.11.07 # <[Saint]> trial. I replaced a screen in an e200 of mine a while ago with a screen I purchased that was supposedly a FuzeV2 LCD, and it worked happily. Unless of course it wasn't actually an FuzeV2 screen to begin with. And Fuze V1/2 screens are compatible with each other. So, if it was sold to me correctly as a FuzeV2 LCD, it should "just work" in the same respect with a V1 LCD. 17.11.13 Join stoffel [0] (~quassel@p57B4C115.dip.t-dialin.net) 17.11.22 # <[Saint]> Alternatively, I was sold an e200 LCD, and this isn't the case ;) 17.11.38 # Buying the screens on ebay I presume? 17.11.58 # <[Saint]> Nah, some guy off local forums. 17.12.09 # Hum 17.12.15 # <[Saint]> Had lots of bits & pieces of many, many Sansas. 17.12.20 # scary 17.12.29 # Wonder how they managed to salvage the screens 17.13.02 # <[Saint]> Dissassembly is relatively easy, correct tools are handy, but not needed. 17.13.11 # <[Saint]> A guitar pick is usually sufficient. 17.13.37 # I had no luck trying to desolder the infernal flat-flex cable with my iron and simply cut it with a knife, peeled off the plastic and then used a glob of solder and braid to clean up the pads in the end 17.13.59 # (Screen's cable was toast anyhow.) 17.15.06 # I'd think a heatgun to be useful, but I've not yet gotten myself one to test out, and am unsure of how much LCDs would agree with them... 17.15.14 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.15.33 # <[Saint]> ZIF cables don't like them very much... 17.15.49 # <[Saint]> the shrink and/or distort. 17.15.52 # <[Saint]> *they 17.15.59 # One more reason to loath them :c 17.19.57 # <[Saint]> Hmmmmm...I *really* need to get around to doing that "Start Database indexing here" patch so I can actually use the Database with the SDL application. It doesn't seem to pick up the music where it is on the system presently. 17.20.25 # <[Saint]> (also handy for RaaA, of course (and possibly other targets)) 17.24.38 Quit Thra11_ (Read error: Connection reset by peer) 17.28.06 Join robin0800 [0] (~robin0800@149.254.219.237) 17.29.01 # <[Saint]> Does anyone know the reasoning for *not* including "Shutdown" in the main menu for RaaA? I have tried grepping logs for keywords to see if I missed a discussion about it but I can't seem to find one. 17.29.10 # <[Saint]> However, my logs are hardly complete. 17.31.01 # <[Saint]> It quite definitely takes the sting out of initialising the database the first time around. Having to launch the programme manager and force close the app isn't exactly intuitive for a newcomer, nor immediately obvious. 17.31.17 Quit powell14ski_ (Quit: powell14ski_) 17.31.50 # why does it have to be restarted in the first place? 17.32.17 # <[Saint]> I personally include shutdown in the main menu on all my targets as I don't see a reason not to have it there, but its hardly needed when there is actually another way to shut down. 17.32.55 # <[Saint]> Xerion: No idea, to be honest. There are a couple of settings that once applied require a restart. 17.33.23 # I use rockbox on my phone to play from network shares :) 17.33.45 # <[Saint]> timestretch and the initial database init are all I can think of just offhand, there may be more. 17.33.56 # yesterday I succeeded for the first time to actually build the database from these 17.34.53 # [Saint]: Android apps don't generally 17.34.59 # there's something odd btw, even when I kill the rockbox app the battery gets drained if I have played from network shares 17.35.15 # but not using rockbox and leaving the network shares open doesn't do this 17.35.26 # [Saint]: I think bluebroth3r it was can explain more (or rasher maybe?) 17.36.16 # <[Saint]> AlexP: I understand that, but for RaaA to not require it the need to reboot to init needs to be overcome. Which would be cool on all targets. 17.36.55 # <[Saint]> otherwise the option is waiting for idle timeout, or force closing it. Neither of which seem well suited. 17.37.29 # Maybe a "re-initialize" option under the Rockbox menu 17.38.00 # <[Saint]> rasher: clarify? 17.38.09 # Clarify what? 17.38.17 # you can already use the initialize option there, but still the first time you setup the database you HAVE to kill the application and start it again for it to work 17.38.24 # <[Saint]> re-initialize...what? 17.38.25 Join Thra11_ [0] (~thrall@87.115.52.7) 17.38.32 # Rockbox 17.38.40 # basically a reboot (except it's just an application) 17.38.42 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 17.38.43 # just like you HAVE to actually reboot a DAP to use the database first time 17.39.06 # Having a shutdown entry in the root menu would give people the wrong idea 17.39.42 # I'd call it Exit rather than shutdown 17.39.44 # <[Saint]> I don't see how just off the bat, but I'll take your word for it. 17.39.59 # I'm glad the custom builds actually have the option though 17.40.12 # Xerion: The point is, Android apps don't have exit buttons. And shouldn't 17.40.18 # some do 17.40.19 # <[Saint]> Xerion: Nah, see...to me "Exit" doesn't imply that the application has actually been shut down. 17.40.25 # <[Saint]> Perhaps that'sjust me though. 17.40.32 # [Saint]: It's just you :) 17.40.34 # Xerion: but it's wrong 17.40.39 # What else would it do if you exit? 17.40.40 # but still the option wouldn't be needed 17.40.56 # if you can initialize the database the first time without actually restarting the app 17.41.15 # <[Saint]> Yeah, untill then, wrong or not, its needed in RaaA 17.42.16 # Not really 17.42.19 # I don't even agree with the android philosophy of having all apps stay resident, it only makes sense for some apps :p 17.42.19 # AlexP: Exit _could_ imply backgrounding it 17.42.27 # As I said, put a "reboot" entry in the rockbox submenu 17.42.34 # evilnick: I don't see it myself 17.42.54 # * evilnick is playing devil's advocate, or [Saint]'s advocate. Or something :) 17.43.01 # <[Saint]> ;) 17.43.07 # Xerion: well, the point is computers are way smarter than you 17.43.30 # haha 17.43.41 # that doesn't even make sense 17.44.17 # untill they can program themselves perhaps 17.44.21 # Well, it's been explained on the web a thousand times. Look up articles about why task killers are bad 17.44.33 # Your phone knows better than you when to unload an app 17.44.57 # they make presumptions about what an app can be 17.45.34 # but task killers usually kill stuff that IS better as a stay-resident app 17.45.40 # which makes them bad 17.45.49 # doesn't mean all apps shouldn't be closed 17.50.15 Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) 17.51.41 # the android philosophy isnt that all apps stay resident - you might want to look at how the acitivity life cycle works - this helps explain it: http://geekfor.me/faq/you-shouldnt-be-using-a-task-killer-with-android/ 17.51.51 # however, this is getting a bit offtopic for this channel... 17.52.31 # <[Saint]> Hmmm...the more I think about it the more I warm to the idea of having a "reboot" option in the menu somewhere for RaaA. Especially if its available to the quickscreen. 17.52.51 # what no, why on earth? 17.52.55 # it's so rarely needed 17.53.15 # <[Saint]> available to doesn't mean "defaults on" 17.53.29 # <[Saint]> there's plenty of rarely used settings that are "quickscreen-able" 17.54.59 # Reboot may be needed now because some options need that, but there is ongoing work to change that 17.57.17 *** Saving seen data "./dancer.seen" 17.59.59 # <[Saint]> Is anyone present in the immediate discussion able to outline exactly why it is that a reboot is needed for ? Complete technical accuracy is far from necessary, just an outline, is possible so I can understand whats happening and why. 18.00.06 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 18.00.31 Quit mgue (Quit: Lost terminal) 18.00.40 # [Saint]: memory allocation 18.00.55 # <[Saint]> *s/is possible/if possible/ 18.01.00 # <[Saint]> gevaerts: Ah right, thanks. 18.01.40 # it would be odd not to have a restarting option in now, because the restarting might not be needed somewhere in the future 18.01.45 # can always take it out later 18.01.57 # * rasher looks at kugel 18.02.30 # Xerion: sure. What I mean is that it probably doesn't make sense to spend too much time on it. A simple solution will work well enough for now 18.04.29 Quit robin0800 (Read error: Connection timed out) 18.04.32 Join FoH [0] (~foh@adsl-98-71-67-250.bhm.bellsouth.net) 18.05.27 Join robin0800 [0] (~robin0800@genld-218-237.t-mobile.co.uk) 18.21.26 Quit Strife1989 (Quit: Connection reset by deer.) 18.41.59 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.45.16 Quit [Saint] (Remote host closed the connection) 18.46.35 Join [Saint] [0] (~st.lasciv@124-197-58-10.callplus.net.nz) 18.47.04 Quit robin0800 (Quit: Leaving) 18.54.39 Join y4n [0] (y4n@unaffiliated/y4ndexx) 18.58.30 Quit mdipolt (Ping timeout: 252 seconds) 19.22.16 Join froggyman [0] (~seth@50.105.150.82) 19.22.16 Quit froggyman (Changing host) 19.22.16 Join froggyman [0] (~seth@unaffiliated/froggyman) 19.27.30 # Is Musepack seeking being slow and bugged a known issue? 19.28.45 # take a 20 minute .mpc and seek to, say, 15 minutes in. restart your device, "resume playback", it goes to 8 minute mark 19.28.50 # also takes some time 19.29.18 # SV8 files here, Rockbox 3.9, Sansa Clip+ 19.31.22 # Not that I'm aware of 19.31.28 # Ask bushel if you see him 19.32.05 # ok 19.33.21 # *buschel 19.34.21 # is that Andree Buschmann? 19.34.25 # yes 19.34.37 # this is most excellent then :) 19.35.40 # He knows a bit about musepack :) 19.35.52 # I know, I know :) 19.57.18 *** Saving seen data "./dancer.seen" 20.33.46 Quit kadoban_ (Ping timeout: 255 seconds) 20.35.14 Join dfkt [0] (dfkt@unaffiliated/dfkt) 20.39.09 Join funman [0] (~fun@rockbox/developer/funman) 20.45.21 Quit Stummi (Quit: Bye!) 21.01.57 Quit stoffel (Remote host closed the connection) 21.14.53 Quit factor (Read error: Connection reset by peer) 21.16.00 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 21.16.00 Quit jhMikeS (Changing host) 21.16.00 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 21.16.41 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 21.31.19 Join factor [0] (~factor@74.197.205.204) 21.31.36 Join Horscht [0] (~Horscht@xbmc/user/horscht) 21.34.04 Quit Horschti (Ping timeout: 246 seconds) 21.35.36 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 21.46.13 Quit funman (Quit: leaving) 21.50.45 Join Buschel [0] (~chatzilla@p54B66D5C.dip.t-dialin.net) 21.51.00 # Buschel: hi Andree 21.51.06 # 21:27 Is Musepack seeking being slow and bugged a known issue? 21.51.07 # 21:28 take a 20 minute .mpc and seek to, say, 15 minutes in. restart your device, "resume playback", it goes to 8 minute mark 21.51.07 # 21:28 also takes some time 21.51.08 DBUG Enqueued KICK y4n 21.51.08 # 21:29 SV8 files here, Rockbox 3.9, Sansa Clip+ 21.51.42 # I saw this in the logs. this is not normal of course... 21.52.25 # does this happen with v3.8 as well? 21.52.35 # Yes definitely 21.52.49 # only with sv8? 21.53.01 # haven't tested with sv7 really 21.53.03 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 21.53.03 # * Buschel has only got few sv8 21.54.06 # ok I can test this 21.57.20 *** Saving seen data "./dancer.seen" 21.57.25 # Buschel: same 21.57.33 # hmmm 21.58.19 # * Buschel searches for the sv7 with the longest playback duration that he owns 21.58.41 # Don Davis — "Matrix Reloaded" Suite [OST The Matrix: Reloaded #2.07] (2003) is 17 minutes long 21.58.44 # was enough :) 21.59.11 # I will have some 20+ minutes Genesis songs here :) 22.00.54 # Supper's Ready 24:36 22.01.55 # yep, does seek to ~7 min instead of 15... 22.02.13 # even in the sim -- which is good 22.03.35 # * Buschel cannot believe this was the same with v3.8 22.07.26 # at a first glance this looks like an overflow resuming up to ~7 min works fine. beyond the modulo part is resumed (e.g. resuming 3 min when seeking to 10 min) 22.10.05 Join ReimuHakurei [0] (~reimu@74.112.212.15) 22.10.43 Quit ReimuHakurei_ (Read error: Connection reset by peer) 22.12.03 Join petur [0] (~petur@rockbox/developer/petur) 22.14.58 Quit Llorean (Read error: Connection reset by peer) 22.17.10 # interesting 22.17.29 # and yes I had the same issues with 3.8 22.17.58 # I guess not so many people have long songs in musepack :) 22.20.47 Join Strife1989 [0] (~Strife89@207.144.201.128) 22.20.52 # post-metal and post-rock tends to have long songs :) 22.21.13 # prog rock is the prime offender 22.21.53 Nick madskiny is now known as dre (dre@gateway/shell/xzibition.com/x-lgdcybxnvexdtewr) 22.22.19 Quit ReimuHakurei (Quit: If I use this, I will disappear, and Shana-tan will remain...) 22.22.20 # there's clearly an overflow happening. cannot see where, yet 22.27.31 Join L-Strife89 [0] (~Strife89@207.144.201.128) 22.28.00 Quit Stummi (Quit: Bye!) 22.30.38 Quit Strife1989 (Ping timeout: 240 seconds) 22.37.08 # Torne, does an ipod nano 1g also have an 4066? 22.42.15 Join ReimuHakurei [0] (~reimu@74.112.212.15) 22.46.59 Quit keyb_gr (Ping timeout: 260 seconds) 22.47.18 Join ro_bertram [0] (~8602f76e@giant.haxx.se) 22.50.24 Join Topy [0] (~Topy44@f048076141.adsl.alicedsl.de) 22.50.26 Join Horschti [0] (~Horscht@xbmc/user/horscht) 22.51.02 # y4n: got it 22.51.02 Quit ro_bertram (Client Quit) 22.51.13 # baaad 22.52.43 # excellent 22.53.08 # this is not working since 16 months now 22.53.59 Quit Horscht (Ping timeout: 260 seconds) 22.54.10 Quit T44 (Ping timeout: 255 seconds) 22.56.23 # Torne, on my nano 1g, 4066_ISTAT has a value of about 60 by default, it goes to about 250 when plugged while holding SELECT 22.56.55 # New commit by 03buschel (r30202): Fix musepack resume for resume positions > 7:30m. 22.59.43 # Buschel: is this going to fix seeking delay too? 23.00.46 # r30202 build result: All green 23.02.56 # no. mpc-resume cannot directly jump to a desired byteposition but will always need to parse from the very beginning to the desired position (parsing = skipping from frame to frame) 23.03.29 # Buschel: might backport that fix to the 3.9 branch 23.03.39 # yep, on my way 23.04.59 Join keyb_gr [0] (~chatzilla@p4FF0550D.dip.t-dialin.net) 23.05.48 # New commit by 03buschel (r30203): Backport r30202. Fixes musepack resume for resume positions > 7:30m. 23.11.08 # y4n: how long does the resume take for you? 23.11.12 # Buschel: I thought it was a limitation of sv7 that was dealt with in sv8? 23.11.34 # it can take 3-5 seconds 23.12.20 # well not a big deal, but... 23.13.39 # about 10 seconds to seek to 45 min position 23.14.38 # but hopefully only when seeking there for the first time ;) 23.16.06 # more like 15 seconds 23.16.10 # but yeah first time only 23.18.08 # sv8 *could* use another way of seeking/resuming. but for now it is still using the same principles as sv7. it is even the same function in the code 23.19.48 # oh makes sense then 23.21.36 # at least mp will now resume as intended :) 23.21.40 # *mpc 23.21.45 # thanks for the hint! 23.22.33 # no problem, musepack has a special place in my heart :) 23.22.46 # is Frank doing anything related these days? 23.24.01 # not that I know of, I have totally lost contact to him since several years 23.27.10 Quit keyb_gr (Ping timeout: 276 seconds) 23.28.32 # Does anyone know how much current a nano 1g draws when charging? 23.31.16 Quit petur (Quit: here today, gone tomorrow) 23.31.30 # good night! 23.31.33 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723]) 23.31.42 Join vitorpamplona [0] (~vitor@201.47.213.60.dynamic.adsl.gvt.net.br) 23.32.05 # is the 64 MB version of the ipod video considered older or newer than the other version? 23.32.47 # Hey guys, is there any developer doc on hacking iPod Nano 5th gen with RockBox? 23.33.10 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 23.33.18 # bertrik: didn't they come out at the same time? 23.34.06 # I have no idea, I just see that the 64 MB version has a different scaling factor for the battery current formula 23.34.18 # I wonder what formula to apply for the nano 1g 23.35.17 # So I assume that apple used the same circuit for the ipod nano 1g and one of the ipod videos 23.35.26 # Ah, yes. I saw that too. I wonder if it's a coincidence that the "big" video is scaled by 1.5 while at the same time having a battery with 1.5 times the capacity 23.35.55 # vitorpamplona: No, not in particular 23.36.16 # vitorpamplona: There is info on the wiki about setting up a dev environment, and on some of the hardware 23.36.23 # But other than that it is the source 23.36.49 # vitorpamplona: you could also ask on #freemyipod. Those people concentrate on new ipods 23.37.03 # ah yes, I missed nano 23.37.10 # * [7] extends his ears 23.37.13 # gevaerts, maybe, I think you can probably use a 1.5 times bigger charge current on a battery with 1.5 times bigger capacity, so perhaps the old scaling factor was too low for the big battery 23.37.40 # Which ipod video is considered the "big" one? 23.37.57 # 60/80 23.38.14 # i.e. the one with 8mm disks 23.38.32 # <[7]> vitorpamplona: no, there's no known exploit for the 5th gen nano so far 23.38.44 # hum... thanks. Before I start hacking this guy I wanna know what options people have tried and what are the pitfalls 23.39.01 # gevaerts, I don't understand 23.39.26 # we have an ipod video with 64 mb and some other one, but I don't know the other properties that changed with that 23.39.39 # <[7]> vitorpamplona: find a way to execute your own code on it, and you're mostly set 23.39.47 # <[7]> but apple has tried pretty hard to prevent that 23.41.09 # Grmbl, can't find anything on our wiki about that, I'll guess I'll have to reverse engineer that info from the sources 23.41.30 # bertrik: ipod videos come in four models: 5G 30GB, 5G 60GB, 5.5G 30GB and 5.5G 80GB. The 30GB ones are "thin", have 5mm disks, 32MB RAM, and a 400mAh battery. The 60GB and 80GB ones are thick, have 8mm disks, 64MB RAM, and a 600mAh battery. The 5G and 5.5G differ in block size used on the disks (and LCD type, but I don't think we care about that) 23.41.53 # thanks 23.42.57 # That's all assuming new hardware of course. With refurbished players, anything goes 23.43.00 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 23.43.21 Quit dfkt (Read error: Connection reset by peer) 23.43.27 Join petur [0] (~petur@rockbox/developer/petur) 23.43.30 # like putting a thin drive in a "thick" video, etc. 23.44.13 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 23.44.27 # Or swapping mainboards, which wil confuse the battery rate measurement 23.44.36 # great :) 23.46.24 # So I should really do an independent current measurement to determine which battery current scaling factor I need, unfortunately I just broke my measurement cable :| 23.46.31 Part vitorpamplona 23.46.34 # for the ipod nano 1g 23.50.25 Join keyb_gr [0] (~chatzilla@p4FF0550D.dip.t-dialin.net) 23.55.12 Part JimmyJ ("Leaving") 23.57.23 *** Saving seen data "./dancer.seen"