--- Log for 23.06.114 Server: morgan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 23 hours ago 00.05.02 Join Provel [0] (~Provel@75-132-32-77.dhcp.stls.mo.charter.com) 00.13.30 Quit yosafbridge (Ping timeout: 240 seconds) 00.15.22 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140616143923]) 00.21.53 Join yosafbridge [0] (~yosafbrid@192.241.198.49) 00.31.22 Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 00.37.32 Quit Guest70275 (Ping timeout: 240 seconds) 00.38.01 *** Saving seen data "./dancer.seen" 00.56.16 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.59.02 Quit bluebrother^ (Ping timeout: 240 seconds) 00.59.16 Quit fs-bluebot (Ping timeout: 272 seconds) 01.01.30 Join fs-bluebot [0] (~fs-bluebo@f053154187.adsl.alicedsl.de) 01.03.34 Quit ZincAlloy (Quit: Leaving.) 01.24.41 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 01.40.20 Join JdGordon [0] (~JdGordon@203.111.191.138) 01.40.27 Quit JdGordon (Changing host) 01.40.27 Join JdGordon [0] (~JdGordon@rockbox/developer/JdGordon) 01.56.40 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 02.09.48 Quit zoktar (Read error: Connection reset by peer) 02.12.13 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 02.35.20 Join Misanthropos_ [0] (~Misanthro@frnk-5f746e1b.pool.mediaWays.net) 02.36.46 Quit Misanthropos_ (Client Quit) 02.38.02 *** Saving seen data "./dancer.seen" 02.41.51 Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 03.00.02 Quit AlexP (Remote host closed the connection) 03.52.22 Join us`0gb [0] (~0gb.us@c-71-237-219-28.hsd1.or.comcast.net) 04.08.35 Join ygrek [0] (~user@108.59.6.97) 04.18.17 Quit amiconn (Disconnected by services) 04.18.17 Quit pixelma (Disconnected by services) 04.18.17 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.18.17 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.18.17 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.18.17 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.38.04 *** Saving seen data "./dancer.seen" 05.06.37 Join steffengy [0] (~quassel@p57B49EC8.dip0.t-ipconnect.de) 05.07.33 Quit TheSeven (Ping timeout: 272 seconds) 05.09.06 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.09.33 Quit steffengy1 (Ping timeout: 240 seconds) 06.10.15 # <[Saint]> Regarding exFAT vs FAT32 in modern Android handsets, isn't the FS compatibility argument pretty much dead these days? 06.11.50 # <[Saint]> I mean, I use F2FS for my external storage (and internal, actually), and MTP makes it completely irrelevant that the host may or may not support it. 06.33.05 Join pretty_function [0] (~sigBART@123.252.214.60) 06.33.28 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 06.38.08 *** Saving seen data "./dancer.seen" 07.13.06 Quit pamaury (Ping timeout: 245 seconds) 07.53.38 Quit pretty_function (Remote host closed the connection) 07.54.10 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 08.00.25 Quit ygrek (Ping timeout: 264 seconds) 08.00.39 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.13.40 Quit user890104 (Ping timeout: 244 seconds) 08.15.55 Join pretty_function [0] (~sigBART@123.252.214.60) 08.16.27 Join AlexP [0] (~alex@rockbox/staff/AlexP) 08.18.09 Join mortalis [0] (~kvirc@213.33.220.118) 08.22.07 Join kugel [0] (~kugel@avm-guido.avm.de) 08.22.07 Quit kugel (Changing host) 08.22.07 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.22.39 Join ender` [0] (krneki@foo.eternallybored.org) 08.35.25 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) 08.38.09 *** Saving seen data "./dancer.seen" 08.41.10 Join ygrek [0] (~user@108.59.6.97) 08.41.19 Join petur [0] (~petur@rockbox/developer/petur) 08.44.30 Quit pretty_function (Remote host closed the connection) 08.53.41 Join Sparkie [0] (~Sparkie@121-74-147-249.telstraclear.net) 08.54.00 Nick Sparkie is now known as Guest51238 (~Sparkie@121-74-147-249.telstraclear.net) 08.57.04 Part Guest51238 09.01.11 Join ygrek_ [0] (~user@108.59.6.97) 09.03.56 Quit ygrek (Ping timeout: 245 seconds) 09.04.37 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.26.01 Quit us`0gb (Quit: http://0gb.us/) 09.32.27 Join pystar89 [0] (~pystar89@ip-176-199-76-43.unitymediagroup.de) 09.34.10 # <[Saint]> I've been looking at https://android.googlesource.com/platform/frameworks/av/+/android-4.4.4_r1/media/libstagefright/codecs/mp3dec/src/ 09.34.31 # <[Saint]> saratoga_: have you seen this? Is it useful to us? 09.35.17 # <[Saint]> whoops: https://android.googlesource.com/platform/frameworks/av/+/android-4.4.4_r1/media/libstagefright/codecs/mp3dec/src/asm/ 09.36.29 # <[Saint]> Well...shit. That's somewhat creepy. 09.36.47 # * [Saint] just found the backlog where saratoga found the exact same thing 09.41.25 Join Sparkie_ [0] (~Sparkie@121-74-147-249.telstraclear.net) 09.42.45 # I installed rockbox on my 7th gen ipod classic and my battery life is appalling when i have the screen on, 1% every 5 seconds, but it stayed on playing music on shuffle with no display for around 15 hours over night and today. How do i fix the battery life? 09.43.32 Quit JdGordon (Remote host closed the connection) 09.45.25 # <[Saint]> The battery indicator is based on voltage, so, its likely your battery is just fucked. 09.45.52 # should i wipe rockbox and put apple back on and ask for replacement? 09.46.34 # <[Saint]> Hahaha. Good luck with that. Its a decade old. 09.46.41 # <[Saint]> If not more. 09.48.16 # oh no i bought it two days ago 09.48.47 # the ipod 7th gen is not a decade old 09.49.46 # and apple still sells it 09.50.07 # Sparkie_: if it's that new the battery is probably fine 09.50.39 # perhaps the calibration data is just inaccurate 09.50.54 # <[Saint]> I don't see how it could be anything other than the battery. 09.51.05 # <[Saint]> Its possible to configure it poorly, but, not *that* poorly. 09.51.11 # did you try if the "1% every 5 seconds" continues until the battery is completely empty? 09.51.53 # <[Saint]> And, yes, the calibration data is bullcrap, but I haven't ever seen the battery on any of my Classics plummet at a rate anywhere close to 1% every 5 seconds. 09.52.03 # the battery stays on 84% for a while and then at 0% for about 15 minutes with the screen on 09.52.43 # im thinking it could be to do with the calibration because when it charges it goes really fast then really slow 09.52.53 # and stays on %'s for a decent amoutn of time 09.52.58 # <[Saint]> Even if I configure my Classic as badly as I possibly can, I can't get the batery to drop that fast. 09.53.02 # oh and it fluctuates 09.53.10 # <[Saint]> I set the LCD to always on, and the HDD spindown time to 10 minutes. 09.53.16 Join edhelas [0] (~edhelas@2001:981:e7ba:1:863a:4bff:fe85:8a3c) 09.53.18 # <[Saint]> And its still not dropping anywhere near that rate, 09.54.08 # <[Saint]> Even other things I can think of that add to it like maxing out all the EQ bands, and enabled accessory power supply don't come close to making the batteyr drop as fast as OP claims his does. 09.54.19 # <[Saint]> And my batteries are very well used. 09.54.59 # Sparkie_: i think you should check if it's bad with the OF too 09.55.22 # <[Saint]> Hmmmmm...what theme are you using? 09.55.32 # flying spaghetti monster 09.55.40 # <[Saint]> Its highly possible the author fucked up the display. 09.56.03 # <[Saint]> Improbable, but, certainly possible. 09.57.07 # ok i will restore back to apple firmware through i tunes 09.57.40 # Sparkie_: i don't think the battery is bad at this point, but better be sure by checking with the OF 09.58.19 # ok yes thank you very much 09.58.26 # <[Saint]> Hmmm, nope, the theme is displaying battery in a sane way. 09.59.08 # <[Saint]> Odd indeed. 09.59.43 # hold on guys, my ipod seems to be charging fine now 09.59.51 # at a proper rate i mean 09.59.56 # maybe it calibrated by itself 10.00.01 # <[Saint]> Nope. 10.00.06 # <[Saint]> Doesn;t work that way. 10.00.18 # yer yer i know bu ti have no idea what is happening 10.00.37 # Sparkie_: I also think you need a few more charge cycles to reliably tell that the battery runs empty fast. could be that it wasn't fully charged 10.01.23 # yer sure thank you and i will do 10.01.55 # my battery is charging at a seems to be normal rate now instead of some stupid % per 2 seconds 10.02.37 # <[Saint]> Wait. 10.02.43 # <[Saint]> Do you mean *discharging*? 10.02.49 # no no chargin now 10.03.04 # <[Saint]> Ok. Well, that's new information. 10.03.52 # <[Saint]> Are we positive about the "loses 1% every 5s" statement? 10.04.02 # it was before 10.04.12 # <[Saint]> Simple math seems to suggest that you'd be getting 8 minutes of battery at that rate. 10.04.19 # <[Saint]> I'm willing to believe that wasn't the case. 10.04.54 # when the screen was on. when it wasn't 80% to 30% shuffling music through earphones for about 15 hours straight 10.05.25 # saint, it was doing that for a while and then slowing down every now and again and stayed on 0% for about 15 minutes 10.06.45 # <[Saint]> How long is "for a while"? Even if it did it for a period of 30s, that's 6% battery lost. 10.06.58 # <[Saint]> Is it possible at all that the perception of time was warped? 10.07.46 # Oh my god dude. I am saying that before, the battery was decreasing fast. But sometimes it would decrease slower 10.08.41 Quit ygrek_ (Ping timeout: 255 seconds) 10.09.31 # It charged super fast aswell. 10.10.44 # <[Saint]> The impression you gave, was that whenever the screen was on the battery would reliably discharge at a rate of ~1% ever ~5s, I'm just trying to ascertain how close to reality that is. Because as noted, at that rate, you've only got 8 minutes of battery with the screen on. 10.11.26 # yes ok . It was doing that for times, but not all the time 10.11.37 # that's why i said it fluctuates 10.11.42 # it's puzzling me too 10.13.41 # <[Saint]> It definitely puzzles me. I attempted to configure my iPod in the worst possible way and I can't get anywhere near that kind of discharge rate. 10.13.47 # <[Saint]> Something odd is going on. 10.14.11 # i orignally thought it was a battery that could hold very little charge but i think it must be something else. 10.14.24 # also do you happen to know how many miiliamphours 7th gen ipods hold 10.14.56 # <[Saint]> 600, IIRC. 10.15.12 # ok i think it said 500 on battery stats 10.15.15 # on rockbox 10.15.38 # <[Saint]> That setting isn't related to any battery level displayed to the user at any time. 10.15.48 # <[Saint]> That setting is only related to the estimated runtime. 10.15.54 # <[Saint]> Which is hilariously inaccurate anyway. 10.16.32 # <[Saint]> So, errr, what I'm saying is, changing it will have absolutely no effect. 10.16.39 # ok yep 10.17.04 # my ipod charging seems allright now. It might have just taken some cahrge/discharge cycles as kugel said 10.19.01 # another thing on my todo list... 10.19.13 # yes? 10.19.24 # finally figure out where apple is hiding that current sensor so that we can get more accurate battery readings 10.20.09 Join JdGordon [0] (~JdGordon@pa49-183-201-219.pa.vic.optusnet.com.au) 10.20.18 # Oh cool. theseven are you part of dev team? 10.20.26 # yes 10.20.36 # I'm the ipod nano 2g & ipod classic port maintainer 10.20.50 # oh my that's really cool 10.21.02 # ty for the rockbox :0 10.22.09 # Sparkie_: I'd *guess* that the battery runtime will be fine, just the meter is probably a bit off 10.22.43 # so if it works for several hours while pretending that the battery would be empty, I just wouldn't worry about that at this time 10.23.05 # if it's very new, it might also be that the battery just hasn't been run in properly yet 10.23.30 # especially if it has (somewhat likely) been sitting in a warehouse for years before being sold 10.23.50 # yer I guess. I'll keep rockbox on for like another week or so then change back to apple and if still hasnt fixed i will take back in 30 day warranty babyyyy 10.23.57 # yer that's true 10.24.44 # another thing is that the battery won't even try to charge before it's (actually, even if the meter says otherwise) below 80% or so 10.25.11 # however plugging it in (and thus removing the load on the battery) will make the meter fluctuate quite a bit even in that area 10.25.42 # Ok, it just went from 100% to 95% in abuit 10 seconds 10.25.48 # 93 10.25.50 # 92 10.25.55 # 91 10.26.06 # what does the voltage reading in the battery debug screen say? 10.26.13 # (system => debug => battery) 10.27.04 # the percent gauge is nowhere near accurate, it has >10% tolerance in a lot of situations, especially shortly after changing the power source 10.27.18 # it will vastly overestimate the battery state while charging, and slightly underestimate it while discharging 10.27.25 # view battery? 10.27.29 # yes 10.27.40 # 4.030V 10.27.46 # so if you're just playing with the 80-100% range, this kind of behavior is just normal at this point 10.28.09 # it's 3.977V atm 10.28.27 # ok, it should actually start charging at that point if you plug it in 10.28.59 # however the meter will likely just jump straight to 100% if you do so, even though fully charging it from that point would take an hour or so 10.29.24 # ok it is jumping all over tha place on the view battery 10.29.27 # this is something that's somewhat likely to get fixed during the next weeks, as I'm currently trying to clean out the last few remaining quirks of the ipod classic port 10.29.36 # oh cool 10.30.06 # Sparkie_: I'd expect it to jump to about 4.15-4.20V if you plug it in, and back to about 4.00V if you unplug it 10.30.15 # where will that be available from? 10.30.38 # yer you are right 10.30.45 # i meant the voltage is jumping 10.30.52 # ok, you're just seeing the normal battery meter confusion then ;) 10.31.21 # pwr status is discharging when it is plugged in? 10.31.22 # you can't properly tell the exact state of charge from just the voltage, but without access to the current sensor it can't do much better 10.31.57 # yes, that's also just not implemented yet. it will always say discharging. 10.32.08 # another thing that I already have a fix for, that just didn't go into the official builds yet 10.32.15 # oh ok. so are you saying my problem is pretty normal but will most likley be fixed next patch? 10.32.23 # yes 10.32.31 # oh coool dude thanks for that 10.33.13 # I'd expect this kind of things to be fixed in the development builds in about 1-2 months 10.33.30 # how long should i keep it charging after 100%? 10.33.39 # and once we've reached that point there will very likely also be a new emCORE release which embeds these newer builds 10.34.06 # Sparkie_: about an hour should be sufficient to get it close to actual 100%, however it's safe to just keep it plugged in overnight ;) 10.34.32 # ok yer i might do that 10.35.32 # also note that if the voltage was above ~4.00-4.05V while plugging in, it won't start charging (you'll see that the voltage goes back up to about 4.1V, but not close to 4.2V) 10.37.40 # ok so, one last time, the reason my batteyr was discharging fast and then slow may have been because it wasn't fully charged and therefore not at the given percentage? 10.38.12 *** Saving seen data "./dancer.seen" 10.41.15 # is that right? 10.41.21 Join pretty_function [0] (~sigBART@123.252.214.60) 10.47.26 # theseven? 11.01.24 Join ygrek_ [0] (~user@108.59.6.97) 11.04.07 # Sparkie_: techincally not 100% correct, but the behavior is similar, yes 11.04.40 # ok cool. so what do you think i should do from here? 11.04.46 # actually the battery meter is slightly underestimating the state of charge while discharging, and massively overestimating it while charging (but only if it actually charges) 11.05.08 # ok and the bettery meter is trying to coirrect itself hence the fast discharge? 11.05.18 # the meter will "jump" (not instantly, but during a few minutes) between those different estimates 11.05.57 # once we have current sensor readings, the meter can actually calculate how big these over/underestimations are and correct them 11.06.42 # * kugel wonders why other targets can get largely-reliable battery readouts without current sensor 11.07.28 # because they aren't dealing with 300+ mA discharge current spikes I guess ;) 11.07.42 # or just because nobody cared about the meter accuracy 11.08.25 # but even on nano2g adding the current sensor to compensate for the battery's internal resistance vastly improved the readings 11.08.52 # especially during charging, as you just can't tell the battery state from just the voltage if it's charging in the CV phase 11.09.45 # this one is probably just as "largely reliable" as the others ;) 11.10.53 # * TheSeven spotted some code in disk mode yesterday that measures the USB D+/D- lines and thus must be dealing with the mux in front of the ADC that is also responsible for battery current measurements 11.13.02 # (this would also enable us to properly detect USB charging spec compliant chargers btw) 11.21.36 # where will i find the rockbox update if it come sout next month? 11.22.31 # where do you usually "find" it? 11.22.38 # http://build.rockbox.org/ will always point to the newest development builds 11.22.56 # and if we consider the latest changes somewhat complete and stable, we'll release them on freemyipod.org 11.25.31 # where would be the ipod classic 7th gen one be though 11.26.12 # hm, looks like the link is missing indeed 11.26.29 # http://build.rockbox.org/data/rockbox-ipod6g.zip 11.26.46 # oh ok ty 11.26.54 # and this is the latest one with the battery issue/ 11.26.56 # ? 11.27.12 # there's a battery issue? 11.28.08 # this is the most recent development build, which doesn't have any battery meter and charging state detection improvements yet 11.28.23 # I guess these will go in there within the next month though 11.28.49 # ok yer i had this on before but i changed to the one from rockbox utility after the battery issue 11.29.54 # the rockbox utility will do nothing else, it will just download that file ;) 11.30.29 # hmm ok. looking at the graph on view battery on my ipod, the gradient at which the battery is decreasing is really steep 11.31.33 # even after charging for over anhour after 100% is this normal? 11.33.16 # oh wait that's voltage my bad 11.35.55 # anywaays im of ty for the help. I'll look forward to seeing new rockbox. goodbye 11.41.23 Quit Sparkie_ (Ping timeout: 255 seconds) 12.10.37 Quit JdGordon (Ping timeout: 272 seconds) 12.15.30 Quit mc2739 (Read error: Connection reset by peer) 12.16.04 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 12.16.38 Join user890104 [0] (Venci@unaffiliated/user890104) 12.31.42 Join krabador [0] (~krabador@unaffiliated/krabador) 12.38.15 *** Saving seen data "./dancer.seen" 12.44.11 Quit pretty_function (Remote host closed the connection) 13.04.23 Join JdGordon [0] (~JdGordon@pa49-183-201-219.pa.vic.optusnet.com.au) 13.04.27 Quit JdGordon (Remote host closed the connection) 13.15.27 Join wodz [0] (~wodz@89-75-149-112.dynamic.chello.pl) 13.17.07 # what is the difference between target_id in configure and MODEL_NUMBER define in target specific config file? 13.20.47 Quit bcobco () 13.29.35 # hmm, we have duplicates in MODEL_NUMBER - hm60x, clip zip 79; xfi2, hm801 82; xfi3, ma9 83; ma9c, yp-z5 84; zenv, ihifi760 92; android, nokian8xx, nokian900, pandora, yp-r0, sdlapp 100 13.29.43 # I guess this is not good 13.29.50 # wodz: IIRC MODEL_NUMBER used in bootloader to check compatibility of bootloader and main binary, and target_id is the same thing but for voicefiles 13.31.54 # so we shouldn't have duplicates in MODEL_NUMBER 13.32.06 # it doesn't make much sense for app builds also 13.34.21 Join bcobco [0] (~bcobco@77.225.204.119) 13.35.29 # target_id is exported as TARGET_ID 13.39.10 # changing MODEL_NUMBER might be a prblem for some targets, as it will require to release new bootloaders 13.39.36 # yes 13.42.53 # I wonder why there are two distinct numbers while vast majority of targets have this unique 13.46.41 Join ZincAlloy [0] (~Adium@pD9EEAFDC.dip0.t-ipconnect.de) 14.07.41 Quit bcobco (Remote host closed the connection) 14.08.06 Join bcobco [0] (~bcobco@77.225.204.119) 14.10.54 # wodz: modelnum is for the bootloader and target_id for apps 14.11.16 # what you mean apps? 14.11.42 # codecs, plugins, voicefiles 14.11.52 # I think each codec and plugin has the target id in the header 14.12.19 # ok, but why it needs to be different then MODEL_NUMBER? 14.12.36 # why two separate numbers 14.13.17 Join Rower [0] (~husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 14.13.25 # no good reason I think 14.14.22 # pamaury: btw. I looked at cp3 OF and there is gpio toggling in codec related functions. I tried this but without luck. I need to study more gpio setup :/ 14.15.02 # ok, so there might be power/hp gates controlled by gpio ? 14.15.28 # could be 14.16.14 # also the model_num is in two places: configure and target config file 14.16.32 # because some targets don't use it except for rolo 14.17.28 # also the scramble tool doesn't always make use of the model_num values, like for RKW I think 14.19.34 Quit Rower (Ping timeout: 240 seconds) 14.20.26 Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 14.25.08 # pamaury: i pushed the 24bit driver 14.25.39 # pamaury: in configure there is target_id in target config file there is MODEL_NUMBER 14.30.33 Quit ygrek_ (Ping timeout: 240 seconds) 14.32.17 Quit copper (Ping timeout: 240 seconds) 14.32.35 # TheSeven: http://pastie.org/9316335 (HEAD + g#843 + g#844) with rockbox official compiler 14.32.38 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 14.32.38 # 3Gerrit review #844 at http://gerrit.rockbox.org/r/844 : 3usb-designware: New USB driver for Synopsys DesignWare USB OTG core. by Michael Sparmann 14.33.08 # + bunch of 'function declaration isn’t a prototype' which I fixed locally 14.37.37 Join Sparkie_ [0] (~Sparkie@121-74-147-249.telstraclear.net) 14.38.19 *** Saving seen data "./dancer.seen" 14.42.17 Quit Sparkie_ (Ping timeout: 255 seconds) 14.49.26 # wodz: but the modelnum is duplicated in configure when given to scramble as an argument 14.49.45 # kugel: yeah I saw, I modified the zen to use it, it works fine 14.49.54 # I'll push it soon 14.50.17 # pamaury: I don't understand 14.50.54 # in configure, there are lines like "$rootdir/tools/scramble -rkw -modelnum=92" 14.51.31 # and also in tools/scramble.c, the modelnum are written for each target, that's many places to keep in sync, pretty bad 14.53.12 # :/ 14.54.25 Quit cmhobbs (Ping timeout: 264 seconds) 14.54.57 # the simplest approach would be to change the target_id, I *think* it won't cause any problem 14.56.42 Join copper [0] (~copper@unaffiliated/copper) 14.57.49 Quit bcobco (Remote host closed the connection) 14.58.13 Join bcobco [0] (~bcobco@77.225.204.119) 14.58.57 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.44.41 Quit petur (Quit: *plop*) 16.01.56 Quit krabador (Quit: Sto andando via) 16.07.13 Join ygrek_ [0] (~user@108.59.6.97) 16.24.56 Quit kugel (Quit: Lost terminal) 16.38.23 *** Saving seen data "./dancer.seen" 16.44.56 Join kugel [0] (~kugel@46.114.24.96) 16.44.57 Quit kugel (Changing host) 16.44.57 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.48.50 Quit bcobco () 16.53.16 Join bcobco [0] (~bcobco@77.225.204.119) 17.00.00 Join petur [0] (~petur@rockbox/developer/petur) 17.03.39 Quit edhelas (Ping timeout: 260 seconds) 17.04.36 Quit kugel (Read error: Connection reset by peer) 17.10.00 Quit bcobco () 17.12.34 Quit mortalis (Ping timeout: 240 seconds) 17.13.46 Join kugel2 [0] (~kugel@46.115.1.147) 17.17.32 Quit GodEater (Ping timeout: 255 seconds) 17.18.34 Join GodEater [0] (~whoknows@90.194.223.13) 17.18.34 Quit GodEater (Changing host) 17.18.34 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 17.19.28 Join bcobco [0] (~bcobco@77.225.204.119) 17.23.50 # wodz: hm, weird errors... 17.24.43 # TheSeven: I made it compile but didn't have time to test 17.38.35 Quit mc2739 (Ping timeout: 240 seconds) 17.39.47 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.51.09 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.51.46 Quit petur (Quit: *plop*) 17.58.43 Join edhelas [0] (~edhelas@77-173-104-232.ip.telfort.nl) 18.04.48 # copper: which way does that adapter get inserted into the ipod? 18.04.48 # with the CF card towards the front or the back? 18.05.18 # haha 18.06.04 # erm 18.06.12 # I'm trying to figure out a way to explain it 18.06.27 # but basically the ZIF interface should give you a clue 18.06.35 # it's not perfectly in the middle 18.06.58 # http://outpost.fr/tmp/qrM.jpg/ 18.07.09 # that side should go against the back 18.07.17 # the back case* 18.07.43 # you won't be able to plug in the ZIF ribbon if you install the adapter the wrong way 18.09.01 # in other words, the adapter should be facing you like in the picture, with the front side of the ipod (with the display) against the table 18.09.19 # dunno if that's clear enough :P 18.10.02 # the top left end of the adapter will make it fit snuggly in the front case 18.10.38 # it's designed to fit the case so it doesn't move around 18.11.06 # you're supposed to remove the two blue bottom "bumpers" 18.11.09 # ok, so unlike the HDD, the adapter gets plugged with the contacts of the ZIF ribbon cable facing towards the top of the connector? 18.11.49 # not sure what you mean, but yes, it's installed differently from the HDD 18.12.04 # you'll know it when it fits 18.12.44 # I took pictures but I was stupid and deleted them 18.13.11 # ok, that little piece of metal that holds it in its position makes it more clear 18.14.38 # I don't suppose you're going to close the ipod anyway? 18.15.10 # yeah, just didn't want to insert it the wrong way round, as the ZIF connector might have pins on both sides 18.15.25 # and it's kinda convenient that the battery is accessible on the top side 18.15.29 # like I said, it's conveniently off-center 18.16.13 # 16:15:26 UTC and it's kinda convenient that the battery is accessible on the top side 18.16.16 # what do you mean? 18.16.28 # er, damn 18.16.32 # what did I type 18.16.35 # the battery should be glued to the back case, not the front case 18.16.36 # I meant the CF card 18.16.44 # ah 18.16.47 # was just plugging the battery while typing that :P 18.16.59 # hm, surprise 18.17.02 # yes, so you can insert an SD card without removing the adapter 18.17.12 # I just tried to plug a microdrive into it just out of curiosity, and it doesn't work (ata error 5) 18.17.44 # it wouldn't be any fun if it worked! 18.18.17 # hm, interesting 18.18.27 # with just the adapter without a card, I don't even get an error 18.18.28 # <[Saint]> Seems a bit of a unnt gesture to get east access to the card without renovi the adapter considering how you have to get to the adapter in the first place. 18.18.30 # it pretends to work 18.19.09 # too many typos! 18.19.10 # <[Saint]> s/unnt/cute/ no idea what autocomplete did there. 18.19.21 # <[Saint]> *easy 18.19.44 # <[Saint]> *removing 18.19.55 # * TheSeven needs to remove that empty battery detection code again 18.20.36 # too inconvenient to actually connect the battery! :P 18.22.13 # I can't remember, did you determine if it was the ZIF adapter, or the CF adapter, that used up too much current? 18.22.28 # the ZIF adapter is completely passive 18.22.32 # that's just a connector adapter 18.22.43 # hmmm 18.22.52 # have you tried a CF card? 18.22.56 # without the CF adapter 18.23.12 # that's one of the things that I'll experiment with 18.23.22 # for a while I couldn't decide if I should buy a CF card instead of an SD card 18.23.44 # but the CF cards are a lot more expensive, even when used 18.23.47 # (second hand) 18.25.00 # and I figured that I didn't need the extra performance, since I would only access it over USB anyway 18.26.26 # <[Saint]> If you're not doing bulk transfers often, the extra performance is rather wasted. 18.26.52 # <[Saint]> Roxkbox would certainly never make use of it at all during playback. 18.27.32 # <[Saint]> Its rather surprising how slow "fast enough for lossless realtime" actually is. 18.33.51 # indeed 18.38.26 *** Saving seen data "./dancer.seen" 18.50.32 # nothing connected: ata error 4, microdrive connected: ata error c, tarkan adapter without card: no error 18.51.24 # tarkan adapter with weird card: no error 18.52.02 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 18.52.03 Quit bertrik (Changing host) 18.52.03 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.53.10 # <[Saint]> "weird card"? 18.54.13 # some old minisd thing that works in basically no device 18.54.32 # reading sector 0 on that succeeds, but returns what looks like an ATA identify response 18.54.39 # "Rev 1.4 FC-1307 SD to CF Adapter V1.4" 18.54.57 # ugh 18.55.06 # I never suspected so much could go wrong with that thing 18.55.16 # I thought, it's just an adapter 18.56.37 # storage init error 0 with tarkan adapter + some old noname 256MB card. that worked in the card reader, we have something here! 18.58.42 # 256MB CF card: no init error, raw access seems to work, but filesystem accesses don't. maybe just too small? 18.59.30 # yeah, probably too small for valid FAT32 with 4K sectors 19.05.02 # that's downright ancient! 19.14.34 # <[Saint]> I have a 6MB SD card somewhere 19.14.58 # <[Saint]> (Yep...6MB) 19.16.05 # * TheSeven has a 16MB card somewhere :P 19.22.06 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 19.23.17 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 19.25.46 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.26.58 Quit APLU (Ping timeout: 272 seconds) 19.31.24 Quit pamaury (Ping timeout: 272 seconds) 19.31.32 # tarkan adapter + 256MB noname card: works after sorting out some FS issues 19.32.20 # note: it seems like the emcore installer messes things up if there's already a FAT filesystem on the card and it's not an initial installation 19.32.49 # you need to manually tell it to reformat the data partition in that case, or it will fail to mount 19.34.39 Join model [0] (~model@cscluster.minotstateu.edu) 19.37.35 Quit bertrik (Ping timeout: 240 seconds) 19.38.03 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.40.21 Join RiD [0] (RiD@bl22-9-15.dsl.telepac.pt) 19.42.48 Quit Rower (Ping timeout: 272 seconds) 19.43.56 Quit jhMikeS (Ping timeout: 245 seconds) 20.21.39 Quit y4n (Disconnected by services) 20.21.43 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 20.26.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.32.05 Quit ygrek_ (Ping timeout: 240 seconds) 20.38.20 # * TheSeven spots some rather idiotic bugs that might have wasted several days of his time 20.38.29 *** Saving seen data "./dancer.seen" 20.40.59 # ok, microdrive compatibility fixed 20.41.54 # copper: how did you manage to get hold of tarkan? 20.43.57 # TheSeven: http://pastie.org/9317501 <- this is my 'fix' for official rb gcc version. The problem is the driver doesn't work on my n2g (with and without g#842) 20.43.59 # 3Gerrit review #842 at http://gerrit.rockbox.org/r/842 : 3Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann 20.44.38 # wodz: but with the cache coherency patch? 20.44.40 # how does it fail? 20.44.52 # TheSeven: yes with coherency fix 20.46.35 # TheSeven: http://pastie.org/9317513 (with HID turned off and g#842 applied) 20.46.37 # 3Gerrit review #842 at http://gerrit.rockbox.org/r/842 : 3Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann 20.47.42 # ok, so it survives enumeration... 20.48.04 # TheSeven: tarkan@tarkan.info 20.48.20 # TheSeven: not always it seems 20.48.37 # the behavior suggests that there are STALLs 20.49.12 # which could be a sign of cache trouble 20.49.28 # TheSeven: the other time I got http://pastie.org/9317524 20.50.02 # yep, that's EP0 stalls 20.50.13 # typical behavior that I was observing *without* the cache coherency fix 20.50.45 # TheSeven: could you give me build with your gcc so I could test if this my n2g or gcc + fix + whatever 20.51.15 # TheSeven: 'Fix cache coherency on ARM940T (and other ARMv4T cores).' is definitely applied 20.51.25 # sure 20.51.37 # http://theseven.homenet.org/~theseven/tmp/rockbox-ipodnano2g-usbfixtest.zip 20.59.47 Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) 20.59.57 # TheSeven: your build enumerates correctly but drive doesn't pop up 21.00.01 # no error in dmesg 21.00.17 # ah, and device hard freezes 21.00.39 # and then there are errors 21.01.16 # TheSeven: http://pastie.org/9317573 21.01.45 # <[Saint]> Yep. Same here. 21.02.04 # <[Saint]> Enumerates, never mounts, hard freeze. 21.02.32 # TheSeven: the same on w7 and linux 21.02.59 # <[Saint]> (I used the supplied build too...cos, honestly, fuck sorting out getting the patch set to compile with the Rb toolset. 21.03.43 # <[Saint]> But the backlog suggests wodz got a lot further than I did in battling compile errors. 21.03.51 # <[Saint]> And, to no avail it seems. 21.05.06 # hm, I'll have to have another look after my replacement LCD arrives 21.07.39 # <[Saint]> Wheeee! 21.07.39 # TheSeven: sorry to disappoint you :/ 21.07.52 # <[Saint]> It mounted! 21.07.59 # wodz: better catch that sooner than later 21.08.10 # <[Saint]> Buuuuuut, this time the host froze. :) 21.09.37 # TheSeven: can usb_dw_get_max_transfer_size() be called agains ep0 ? If so this is plain wrong. 21.09.59 # no, that function is completely counter-intuitive 21.10.16 # it returns the number of packets that can be sent at once on a bulk endpoint 21.10.21 # not the number of bytes 21.10.25 # oh 21.11.03 # well, not quite sure what it's supposed to do in rockbox, but that's what it's doing, and it seems to work on the classic ;) 21.12.34 # TheSeven: anyway http://pastie.org/9317612 makes it compile cleanly with rb gcc and I think should be correct 21.12.57 # yeah, as kugel said we should get rid of those bitfields regardless 21.13.01 # or at least the hw-related ones 21.13.23 # thanks for pinpointing the cause of that error though :) 21.14.27 # TheSeven: yeah, I am all for this but this is a lot of work to debitfildize the driver 21.18.21 # copper: seems like I can reproduce your behavior with a 32GB sandisk extreme SDHC card 21.18.41 # that's the only card that I have that exhibits this problem though 21.19.30 # Is it the only one that claims to be extreme? 21.19.40 # You can only expect such cards to be outliers :) 21.22.22 # gevaerts: Could you comment maybe my question why there are two different numbers describing target in our build system? (I mean MODEL_NUMBER in target's config .h file and target_id in configure) 21.22.38 # wodz: I have no idea 21.22.44 # TheSeven: do you mean that, you have other sandisk cards that work? 21.23.10 # or rather: what cards did you test, that do work? 21.23.11 # no, it's the only sandisk card that I have 21.23.16 # from what I can tell the CF adapter's firmware is locking up somehow 21.23.30 # it doesn't recover until a power cycle even if I swap the card 21.23.30 # gevaerts: Who may I ask about this? 21.23.41 # wodz: someone who was around before me :) 21.23.47 # Zagor, maybe? 21.23.50 # not sure if it's supposed to handle swapping cards during operation though 21.23.58 # Possibly amiconn? 21.25.09 # amiconn is rather inactive and hard to catch 21.31.15 # * TheSeven wonders how it can be possible that we lock up that adapter with only some SD cards, but it still works fine with the very same card in a card reader 21.32.38 # what works fine 21.32.42 # the CF adapter? 21.32.45 # yes 21.32.55 # if I put it into a CF card reader, it works just fine with the sandisk card 21.33.00 # like it did for you with the original firmware 21.33.09 # but emcore somehow locks it up 21.33.19 # but only with the sandisk card. hm... 21.33.19 # there's still the tarkan adapter between the two 21.33.33 # that adapter isn't more than a few pieces of wire 21.33.34 # you didn't answer my question: what cards work for you? 21.33.47 # some old 256MB noname crap 21.34.18 # the 2GB minisd card doesn't work in a card reader either and behaves differently (as if no card was plugged in at all) in emcore 21.34.39 # wait isn't tarkan cf<->sd thing? If so there must be mcu inside (or cpld/fpga) 21.35.02 # it's zif → cf → sd 21.35.04 # wodz: it's a passive ZIF => CF adapter + active CF => SD adapter 21.35.19 # and the CF => SD card works in a card reader with the very same card that fails in the classic 21.35.33 # oh, thats weird 21.36.21 # that fails with emcore* 21.36.32 Quit bcobco () 21.37.12 # it must be some compatibility thing that involves *both* sides of the adapter 21.37.14 # also note that the first thing I did, was to format the entire sd card as FAT32, labeled "iPodClassic", then I put the card into the adpater 21.37.51 # copper: the working lexar card had roughly the same capacity as the failing sandisk one, both way above 32GB, right? 21.38.08 # disabling DMA doesn't help at all 21.38.16 # http://outpost.fr/tmp/DCi.jpg/ 21.38.20 # those are the cards I tried 21.38.24 # top row: fails 21.38.27 # bottom row: works 21.38.43 # the top center one is the one that I'm experimenting with right now 21.38.51 # the final 128 GB Lexar card (which worked) isn't on the picture 21.39.57 # so we can rule out any capacity / sdhc / sdxc based thing as well 21.43.29 # TheSeven: Do you have any documentation/reveng which sdio signals map to which ata lines? 21.43.52 # http://www.tarkan.info/20121226/tutorials/ipod-and-sdhc-sdxc-cards 21.44.00 # wodz: no, I'd have to probe that 21.44.29 # hm or actually I can't probe it, because I don't have a CE-ATA ipod 21.45.04 # [Saint]: do you have the required tools to figure out where the pins inside the CE-ATA ZIF cable end up? 21.52.56 Quit RiD (Ping timeout: 255 seconds) 21.55.05 Quit y4n (Quit: PÆNTS ØLF!) 21.56.08 Join RiD [0] (~RiD@2.83.169.151) 21.57.16 Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) 21.57.39 Quit Misanthropos (Read error: Connection timed out) 21.58.03 Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) 22.02.06 # interesting... I can trigger the very same behavior by unplugging and replugging an otherwise working card on the fly 22.02.51 # another side note: the adapter doesn't seem to support LBA48 22.03.41 # so 128GB is the maximum card size that it can possibly support 22.04.27 Quit ender` (Quit: #define sizeof(x) ((rand() % 100 == 42) ? sizeof(x)-1 : sizeof(x))) 22.10.39 Join wo [0] (594b9570@gateway/web/freenode/ip.89.75.149.112) 22.13.15 # TheSeven: As it seems that ipod side is the same in thick and thin I'd be more interested to see where sdio signals are mapped on 40pin connector 22.13.32 Quit Misanthropos (Ping timeout: 272 seconds) 22.13.45 # wo: yes, but I only have access to one half of that mapping 22.13.53 # i.e. I don't know where which SDIO signal is on the ipod side 22.15.08 # TheSeven: why do you need to know this? You need to know where it ends up on 40pin 'hdd' flex' side 22.15.23 # yeah, but I can only track ipod => 40pin here 22.15.31 # but what I actually need to do is track ceata => 40pin 22.15.50 # the only way how I can do this is tracking ceata => ipod => 40pin 22.16.10 # can't you drive sdio and look with scope on 40pin? 22.16.54 # possibly, if I had a scope that's fast enough. it's also a bit hard to tell produce any signal at all on the data pins as long as nothing responds on the CMD pin 22.16.58 Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) 22.17.08 # tell it to produce* 22.18.20 # ok, so the only way is to compare mapping of thick and thin flex cable 22.18.29 # yes 22.18.40 # I can figure out the mapping of the thick one, and where the CEATA identify pin is 22.18.44 # er, thin one 22.18.51 # I need [Saint] for the thick one 22.18.55 Join rela [0] (~x@pdpc/supporter/active/rela) 22.23.40 Quit Misanthropos (Ping timeout: 272 seconds) 22.25.45 Join RiDD [0] (Ghost@2.83.169.151) 22.29.49 Quit RiD (Ping timeout: 255 seconds) 22.30.10 Nick RiDD is now known as RiD (Ghost@2.83.169.151) 22.31.46 Quit model (Read error: Connection reset by peer) 22.34.22 Join Gallomimia [0] (~gallomimi@S0106c8fb26452633.ca.shawcable.net) 22.37.55 Quit rela (Read error: Connection reset by peer) 22.38.33 *** Saving seen data "./dancer.seen" 22.56.12 Quit wo (Quit: Page closed) 22.56.14 Quit TheSeven (Ping timeout: 252 seconds) 22.57.56 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 23.03.12 Quit amayer (Quit: Leaving) 23.10.24 # hm, sometimes I'm getting it to hand badly enough to not even allow access to the registers anymore 23.14.15 # s/hand/hang/ 23.15.52 Quit wodz (Quit: Leaving) 23.29.30 Quit nyanpasu (Ping timeout: 240 seconds) 23.39.35 Quit pamaury (Ping timeout: 240 seconds) 23.44.35 Quit TheSeven (Disconnected by services) 23.44.52 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 23.49.51 Quit GodEater (Ping timeout: 244 seconds) 23.53.12 # hm the build client fetches all remotes between each build 23.53.21 # why that? 23.54.40 # <[7]> hm, as in checks for new versions of them? 23.55.22 Join GodEater [0] (~whoknows@90.194.223.13) 23.55.22 Quit GodEater (Changing host) 23.55.22 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 23.55.51 # yes. i don't know if it would also actually check out new commits that happen in the meantime though 23.56.22 # i have 4 remotes, and fetching them takes a significant amount of time if the internet connection is congested due to build uploads 23.57.25 # <[7]> hm right, between each build is nonsense, I was thinking at the beginning of each round, which seemed to make sense 23.57.53 Join Basstard` [0] (~sturgeon@host-95-195-128-64.mobileonline.telia.com)