--- Log for 04.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 1 day ago 00.04.22 Quit K3N (Read error: 110 (Connection timed out)) 00.06.12 # e200 boot builds are missing from the build page - they are currently broken 00.07.17 # obo: I see them on the build page.. 00.08.38 # rasher: don't worry, I'm just going mad. Not enough sleep last night 00.11.54 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 00.16.16 # New commit by 03peter (r21626): Accept FS #10244 by Wincent Balin: more pdbox work done for GSoC; also some keyword and line-ending fixes by me 00.24.27 # can we please update the Sansa bootloaders 00.28.11 # * petur hands mcuelenaere 618 points 00.28.35 # all yellow, cool :) 00.29.36 # New commit by 03mcuelenaere (r21627): Also enable frequency switching on Onda VX767 00.33.28 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 00.35.00 # how close to being supported are the Onda players? 00.39.08 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 00.39.12 Quit bmbl (Remote closed the connection) 00.39.22 # saratoga_: update? 00.39.41 # kugel: on the clip issue? 00.40.02 # what do you mean by update? 00.40.26 # we still haven't released the 3.3 sansa bootloaders 00.40.45 # ah, that sansas :8 00.40.50 # :) 00.41.16 # I think we should start over. Maybe create a branch for them, because the round I built have some issues 00.41.51 Nick TheSeven is now known as TheSeven|Zzz (n=theseven@dslb-084-056-168-237.pools.arcor-ip.net) 00.41.59 # TheSeven|Zzz: Please don't do that here. 00.42.48 Quit Zarggg (Read error: 104 (Connection reset by peer)) 00.44.05 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 00.44.43 Quit linuxstb (Remote closed the connection) 00.44.55 Quit saratoga_ ("Page closed") 00.45.04 # saratoga_: there's still some weird crashes with pictureflow, doom & genre tags on some music files 00.45.20 # next to that there's no rbutil support, dual boot or installation method 00.46.25 # hmm build server stuck? 00.47.05 Quit ender` (" The reason they call it the American Dream is because you have to be asleep to believe it. -- George Carlin") 00.48.32 Quit Zarggg (Read error: 54 (Connection reset by peer)) 00.50.50 # New commit by 03zagor (r21628): Inverted browser check to only server multipart/mixed to Gecko browsers. ... 00.51.51 *** Saving seen data "./dancer.seen" 00.52.42 # * bertrik sees working DMA to the PCM (IIS) on the meizu M3 00.53.08 # Zagor: I'm thinking khtml can probably manage as well? 00.54.15 # This is interesting. 00.54.26 # The database scanner crash causes Rockbox to see a full battery as empty 00.54.27 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 00.54.41 # rasher: I don't think it does. Safari doesn't. 00.56.22 # rasher: do you have kthml installed to try? 00.56.34 # No.. 00.57.38 # Chrome doesn't seem to like it - thinks it's a download 00.59.25 # same with webkit (arora - who says "Gecko" in the user agent... grr) 00.59.41 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 01.00.32 # and so does Chrome 01.01.26 # Either that, or in a half of a second, it manages to expend the entire charge without melting anything. 01.02.48 # New commit by 03zagor (r21629): Identify real Gecko-based browsers (Mozilla). 01.03.11 # New commit by 03mcuelenaere (r21630): Lua: always expose BUTTON_TOUCHSCREEN and remove BUTTON_ constants from rocklib.c 01.20.16 Quit mcuelenaere ("Gnight") 01.23.03 Join froggyman [0] (n=Froggyma@pool-72-69-217-158.chi01.dsl-w.verizon.net) 01.24.12 Join saratoga [0] (n=9803c264@rockbox/developer/saratoga) 01.24.26 # so theres no way to make Chrome or Safari work with the log viewer like FF does? 01.25.39 # not without changing the way it feeds data to the browser 01.26.24 # I didn't actually know this was a mozilla-only technique when I wrote it 01.27.30 # Zagor: Is there a test page for this multipart thing? 01.27.32 # on browsers that do reflow during transmission, couldn't you just never "finish" the document? 01.28.23 # Unhelpful: most (all?) browsers today don't render the screen until they know the boundaries, which they don't until they get all html 01.29.16 # saratoga: there's not no way, but you probably have to use some fancy xmlhttp ajax javascript thing? :) 01.29.32 # Zagor: really? i've watched firefox redraw as it gets more of the page HTML.... 01.29.49 # Unhelpful: we are saying how it only works in firefox 01.30.03 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 01.30.33 # i was just offering a counterexample for "no draw until all html text received"... i can't say how IE and Safari do things, i don't use them. 01.30.50 Quit gevaerts (Nick collision from services.) 01.30.59 # Unhelpful: ok, I could be wrong. perhaps also things like wrapping can affect it. it's not a terribly reliable method anyhow. 01.30.59 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 01.31.04 # next time i'm on a slow link or dealing with a slow site that triggers redraw, i'll try it in konqueror too... surely this could be simulated though. 01.31.32 # no, but if you can't use multipart, and don't want to do ajax, it may be all you have :/ 01.43.11 Quit ze ("MOVING! gone for weeks, probably.") 01.45.09 Quit val3 (Read error: 104 (Connection reset by peer)) 01.47.36 Quit BHSPitLappy (Read error: 104 (Connection reset by peer)) 01.52.08 # New commit by 03zagor (r21631): Fixed client dupe check. ... 01.53.06 Quit notlistening ("Leaving") 02.00.10 Quit petur ("Zzzzzz") 02.07.42 Quit mt (Remote closed the connection) 02.08.18 # New commit by 03zagor (r21632): Exit with 22 if HELLO failed. 02.09.39 # amiconn: sorry, no I don't know a test page 02.13.31 # gevaerts: new patch 02.13.41 # http://pastie.org/533773 -- apply with -p1 :) 02.15.33 Quit Zagor ("Leaving") 02.15.46 # * gevaerts builds 02.16.17 Join evilnick_bs [0] (i=620ec27e@gateway/web/freenode/x-aa235488d431a937) 02.20.55 # kugel: nice :) 02.21.42 # which target ? 02.22.22 Quit Thundercloud (Remote closed the connection) 02.25.09 Join BdN3504 [0] (n=5ce53b8f@gateway/web/cgi-irc/labb.contactor.se/x-9b0e06e647512285) 02.27.11 # gevaerts: ^ 02.27.20 # gigabeat f 02.27.31 # have i missed something? since when does the theme gallery support the second screenshot i uploaded to my themes (i mean the menu screenshot)? i am looking at the gigabeat f gallery, but only two of my themes show the menu upon hover 02.27.36 # does going to the wps from pf work ? 02.27.59 # yes 02.28.19 # ah no, "spartan black" also shows its menu screenshot 02.29.02 Quit Unhelpful (Read error: 113 (No route to host)) 02.29.18 # gevaerts: with the standard wps button too? 02.30.11 # apparently, yes 02.30.51 # that's cool 02.32.29 # gevaerts: that's using exit() in rfa btw, since the return value of main_menu() is used for other things 02.33.40 Join Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) 02.33.54 # ok sorry, my bad. actually all menu screens are show if you leave your mouse long enough upon a wps. but still, since when does this work? don't we add this to the major changes? 02.35.27 Quit bertrik (Read error: 113 (No route to host)) 02.40.05 # kugel: well, the return value indicates whether it should exit, so that bit would be fine. I think I'd rather see that exit variable become an integer instead of a boolean, so you can indicate no exit, normal exit, or error 02.40.38 # The way it is now is a bit inconsistent. I think it should either use exit() everywhere, or return everywhere 02.40.46 Part n00b81 ("Leaving") 02.40.51 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 02.41.13 # those are minor things though 02.43.25 Quit BdN3504 ("CGI:IRC (EOF)") 02.47.05 # drakonik, my idea - as Llorean suspects - was to isolate possible hardware issues from software (Rockbox) issues. I think we can conclusively say you have a non-rockbox issue. :( 02.48.40 # There's a LOT of problems. One of them is that something is causing the scanner to crash. Another is that file transfers while in Rockbox mode, but not ipod-firmware-mode, cause an endless unstoppable loop of crashing and rebooting and crashing. 02.49.05 # Or at least, sometimes they do. 02.49.33 # And sometimes they don't, and sometimes it's a different file that causes the hangup, and sometimes there's no noticable error regarding files. 02.49.37 # It's all really confusing =\ 02.50.48 # Oh, now there's the issue of a database scanner induced crash causing rockbox to stop seeing a full battery as full. Or, causing it to discharge the whole battery at once. 02.51.55 *** Saving seen data "./dancer.seen" 03.05.19 # drakonik, I'm guessing there is one problem. 03.05.55 # whatever is causing the file transfer problems is likely causing the playback (IIRC) and DB scanner problem. 03.06.31 # hmm, rockbox needs a /dev/null. 03.07.34 # Then you could test transfers when the drive is suspect (or just to isolate the wire speed w/o drive speed affecting results) by copying files from PC to /dev/null/ 03.12.26 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 03.12.50 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 03.13.55 # /dev/null shouldnt be too hard to imple,ment 03.15.29 # any word on the new bootloader yet? 03.18.14 Join r0b- [0] (n=rob@adsl-76-235-166-231.dsl.klmzmi.sbcglobal.net) 03.18.25 # how hard is it to install rockbox to a Fuze 03.18.29 # maybe there's something in the debug tools that'll help me 03.18.48 # r0b-: well considering that it isnt a supported target yet... 03.19.32 # oh it isnt 03.23.15 Join goffa__ [0] (n=goffa@216.220.23.105) 03.23.16 # ok how do i install the bootloader from FS #9955 ? 03.24.24 Join topbloke [0] (n=x@adsl-99-35-40-71.dsl.chcgil.sbcglobal.net) 03.25.21 Quit evilnick_bs ("Page closed") 03.28.20 # n/m 03.31.23 Quit topbloke ("bye") 03.34.25 Quit evilnick_home1 ("Leaving.") 03.34.51 Quit goffa_ (Read error: 110 (Connection timed out)) 03.35.27 # I dunno, I'm really disheartened. A scanner crash means I have to shunt it into ipod mode so that it'll have a charge. That means 30 minutes or an hour between times I can narrow down the files being scanned. And I don't know any better way to figure out what's wrong. 03.37.23 Quit zeveroare (Remote closed the connection) 03.44.39 # drakonik, with all the other problems you're having my first suspicion is now hardware failure, not messed-up tags. :( 03.45.26 # I'd think the smae thing too if it weren't for the fact that until the moment I installed rockbox, my ipod hadn't EVER done anything like this ever 03.46.02 # you, yourself, said earlier that you didn't use the ipod before rockbox. 03.46.08 # No, I did 03.46.10 # much, at least. 03.46.19 # I used it extensively 03.46.25 # I phrased it poorly 03.46.47 # Which is strange, cause I never had an iota of trouble till I started messing with Rockbox. To be fair though, I didn't really try doing anything AT ALL with it till I started dicking with Rockbox 03.47.00 # 10h18m ago 03.47.05 # Yeah, that was crappy choice of words on my part =\ 03.47.24 # the fact of the matter is rockbox has no impact on behavior of the original firmware. 03.47.46 # What I meant was I never did anything directly to it, I just let itunes/winamp/whatever sync media to it. I never directly tried to transfer this many files to it before. 03.48.31 # I only just got home, and have not read the last 12 hours of logs (except where my name was said and the context around that) - but have you checked your iPod's filesystem? If you're lucky that is the solution to all your data problems. Your battery problem is just that, a battery problem. 03.48.46 # Yeah, I've formatted it completely clean 03.49.03 # rewriting the FAT is not a disk scan. 03.49.29 # Not quite sure what you mean by 'disk scan' 03.49.51 # are you on windows? (winamp)? 03.50.08 # CHKDSK on Windows XP. 03.50.18 # aha 03.50.23 # Scandisk on earlier flavors of windows. 03.50.25 # Okay, I see. Sorry 03.50.28 # Do the full scan. 03.50.33 # probe it deep. 03.51.34 # Alright, running it now 03.52.59 # huh. Apparently, "Windows made corrections to the file system" 03.53.34 # Fingers crossed. 03.54.18 # that was fast. 03.54.39 Quit DarkSpectrum () 03.54.48 Quit amiconn (Nick collision from services.) 03.54.49 Quit pixelma (Nick collision from services.) 03.54.49 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 03.54.50 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 03.55.03 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 03.55.09 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 03.55.12 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 03.55.18 # Well, usually, it crashes by this point. 03.55.27 Join toffe82 [0] (n=chatzill@adsl-70-137-196-176.dsl.frs2ca.sbcglobal.net) 03.55.27 # So I'm cautiously optimistic 03.55.47 # Ah! There is goes 03.55.50 # Crash. 04.02.31 # have you formatted the whole filesystem? 04.02.35 # Yep 04.02.40 # even zeroed it? 04.02.57 # full format? not quick 04.03.03 # Full format, yeah 04.03.08 # Hm 04.03.10 # I can do it again 04.03.31 # I'm not sure if Windows is all that reliable 04.08.19 Join toffe82_ [0] (n=chatzill@ppp-71-138-17-16.dsl.frs2ca.pacbell.net) 04.08.27 Quit TheSeven|Zzz (Nick collision from services.) 04.08.41 Join TheSeven|Zzz [0] (n=theseven@dslb-084-056-145-250.pools.arcor-ip.net) 04.16.27 # what information would I need to put up about a speaker/remote for help with ipod protocol help? 04.17.27 # currently only audio works with the speakerdocks remote 04.21.43 # man, this chkdsk run is taking forever 04.23.50 Quit toffe82 (Read error: 110 (Connection timed out)) 04.26.12 # it should - and don't format again - that won't fix the problem. 04.26.49 # I ran it with a new flag this second time, to recover readable data from damaged sections. It shouldn't change much, but I figured thoroughness can't hurt 04.30.25 # badblocks takes two days (!!) on a 2TB drive 04.34.13 # and now it's not making any progress at all, and Ctrl+C doesn't work. Fucking awesome. 04.47.32 # On the bright side, I did something that stopped the crashes from wiping the battery 04.47.54 # if your ipod fails to respond to the Menu + Select combo you have a hardware failure. 04.48.01 # No, it responds to it 04.48.33 # then I'm confused on how a crash is killing the battery... 04.49.07 # When the database scan caused a crash, on reboot, Rockbox would refuse to acknowledge even a full battery as full. 04.49.19 # no 04.49.50 # I left it to charge overnight, and crashed it moments after unplugging it. It rebooted, and rockbox thought the battery was 100% empty. It booted up, said "Battery is empty please charge" and shut itself down. 04.49.53 # your battery - from everything you have said - is on its way out. 04.50.27 # And I'd boot into the ipod firmware, and it'd show a solid 75 to 100% charge. 04.50.43 # a failing lithium chemistry battery develops higher internal resistance - thus high current activities such as running the hard drive pull the voltage down more than on a new battery. 04.51.09 # there is no dipstick on a battery - you estimate remaining charge by comparing voltage to a discharge curve. 04.51.33 # when the voltage dips under load a lower estimation is made based on what that voltage normally means. 04.51.44 # regardless, your battery is on death's door. 04.51.56 *** Saving seen data "./dancer.seen" 04.52.14 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 04.52.26 # I don't care what the iPod firmware says, I have no idea how they estimate remaining life - but estimate it they do. 04.52.35 # Yeah, that's fair. 04.53.14 # But, my point is, Rockbox thinks the battery is 95% full, and then one crash later, thinks it's 1% full. That's the discrepancy that concerns me. 04.53.33 # I already explained that. 04.53.41 # the drive running is the factor. 04.53.57 # running while creating the database, and immediately running again upon reboot. 04.54.24 # exactly the conditions you would expect to see a failing battery start to show itself. 04.56.09 # I believe I and others have given the most likely explanation for all of the evidence you have provided so far. I also believe you don't like the answer, as it is not a good prognosis, for it appears to me you keep asking the same questions and providing evidence predicted by us. 04.56.16 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 04.56.24 # i'm sorry about your luck, but I really do suspect hardware failure. 05.00.37 # Yeah. It might be. I find it hard to buy and I really don't want to give up, because I've been utterly disenchanted with the actual ipod firmware and the management software that it requires. I want rockbox to work so I can be fucking done with that bullshit. 05.01.24 # you can run iPod's diagnostic mode. 05.01.32 # Apple's built-in one. 05.01.44 # don't recall the keypresses to get it. 05.02.54 # I'm sure I can find it 05.04.03 Quit evilnick_home (Read error: 104 (Connection reset by peer)) 05.04.35 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 05.10.24 Quit kugel (Read error: 110 (Connection timed out)) 05.10.34 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 05.11.14 # Wow. This is new. 05.11.19 # I've never even heard of this 05.16.14 # Shit, now it's stuck on a diagnostic 05.17.17 Join PaulPosition [0] (n=alex@modemcable013.174-56-74.mc.videotron.ca) 05.17.19 Quit BlakeJohnson86 (Read error: 104 (Connection reset by peer)) 05.21.43 # Alright, I dunno if I'm looking for any specific numbers, but it passes every single diagnostic I'm running 05.25.47 # Interesting. It seems to have populated the database pretty completely... 05.26.59 # Hm. Crashing even when I'm not updating the database. 05.31.10 # I was running test_disk on my e200v2, I got a "*PANIC* flush_fat_sector() - Could not write sector 321 (error -101)" Is this of any importance? 05.34.18 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 05.38.23 Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") 05.52.28 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 06.02.23 Join Nausicaa [0] (n=Ribbon@ppp-69-214-15-0.dsl.klmzmi.ameritech.net) 06.03.40 # Is there a way to make the iPod mini 2g have less backlight intensity? 06.04.56 Join josh1238 [0] (n=sniderbo@207-144-14-44.cstel.net) 06.04.59 Part josh1238 06.05.30 # Can anyone explain this C-noob what the following accomplishes in plugin pictureflow code..? I'd like to get the keymap to work with my target (h10) but I can't see any logic in it.. http://pastebin.com/d23e60ea7 06.06.31 # (as it is now, up and down scroll and left and right (usually std action cancel and select) do the same (ie, scroll).. :( 06.10.00 Quit Horscht (Read error: 110 (Connection timed out)) 06.11.48 Quit HBK () 06.16.05 Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 06.17.09 Part toffe82_ 06.23.23 Part PaulPosition 06.39.31 Quit saratoga ("CGI:IRC (EOF)") 06.48.34 Join dmb [0] (n=Dmb@unaffiliated/dmb) 06.51.59 *** Saving seen data "./dancer.seen" 06.52.18 Quit dmb (Remote closed the connection) 06.59.39 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 07.16.42 Join einhirn [0] (n=Miranda@p4FC6033B.dip0.t-ipconnect.de) 07.18.27 Quit Nausicaa (Read error: 110 (Connection timed out)) 07.18.38 Join Nausicaa [0] (n=Ribbon@ppp-69-214-15-0.dsl.klmzmi.ameritech.net) 07.40.35 Join Horscht86 [0] (n=Horscht2@p4FD4CE44.dip.t-dialin.net) 07.48.49 Quit Nausicaa (Read error: 110 (Connection timed out)) 07.57.02 Join petur [0] (n=peter@rockbox/developer/petur) 07.58.43 Quit Horschti (Read error: 110 (Connection timed out)) 08.01.51 Quit rvvs89 (Read error: 104 (Connection reset by peer)) 08.02.37 Join Rob2223 [0] (n=Miranda@p4FDCCDE5.dip.t-dialin.net) 08.03.28 Join jkl [0] (n=jlp@cpe-74-65-31-43.rochester.res.rr.com) 08.15.39 Join Russel-Athletic [0] (n=engelzz@d174.stw.stud.uni-saarland.de) 08.16.08 Join dmb [0] (n=Dmb@unaffiliated/dmb) 08.17.03 # I changed my tagnavi_custom.config, what do I need to do, to reload it? 08.18.51 Quit dmb (Read error: 104 (Connection reset by peer)) 08.19.04 Join dmb [0] (n=Dmb@unaffiliated/dmb) 08.20.54 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.20.59 Quit dmb (Read error: 54 (Connection reset by peer)) 08.24.24 Join dmb [0] (n=Dmb@unaffiliated/dmb) 08.25.01 Join stoffel [0] (n=quassel@p57B4EC54.dip.t-dialin.net) 08.47.06 Quit einhirn (Read error: 104 (Connection reset by peer)) 08.52.00 *** Saving seen data "./dancer.seen" 08.55.31 Join mt [0] (n=mt@41.233.147.176) 08.58.54 Join Grahack [0] (n=chri@ACaen-156-1-75-178.w90-51.abo.wanadoo.fr) 09.00.12 Join Rob2222 [0] (n=Miranda@p4FDCC999.dip.t-dialin.net) 09.07.00 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 09.12.53 Nick at0m|c is now known as at0m (n=at0m@94-225-90-23.access.telenet.be) 09.17.22 Quit robin0800 (Read error: 104 (Connection reset by peer)) 09.17.50 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.18.32 Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) 09.19.19 Quit stoffel (Remote closed the connection) 09.27.46 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 09.30.04 Join daurnimator [0] (n=john@unaffiliated/daurnimator) 09.31.57 Quit Russel-Athletic ("leaving") 09.51.44 Quit robin0800 (Remote closed the connection) 09.51.47 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 09.57.14 Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) 09.57.49 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.05.56 Join ender` [0] (i=krneki@foo.eternallybored.org) 10.15.15 Part TheSeven|Zzz 10.25.51 Quit petur ("blub blub blub") 10.43.45 Quit mt (Remote closed the connection) 10.43.51 # wow, the s5l8700 apparently generates all internal clocks from a single 32768 Hz input clock 10.52.03 *** Saving seen data "./dancer.seen" 11.00.10 Join {phoenix} [0] (n=dirk@p54B45B4D.dip.t-dialin.net) 11.21.15 # I'm getting confused about the number of clocks involved in s5l8700 PCM: I see mentions of PCLK, SCLK, BCLK, CODECLK and MCLK 11.21.51 # oh I forgot LRCK ... 11.26.12 # bertrik: google PLL 11.26.54 # then what? it all becomes magically clear or something? 11.27.40 # bertrik: no, just saying that generating the various clocks for uC or SoC from a single source is common and old 11.39.01 Join mt [0] (n=mt@41.233.147.176) 11.45.05 Nick Horscht86 is now known as Horscht (n=Horscht2@p4FD4CE44.dip.t-dialin.net) 11.46.18 # Could someone check my final patch in FS#10182 ? I was going to commit it, but thought I should discuss it first. 11.46.58 # I'll be back later so I will check both the logs and the task for the comments. 11.54.42 # mt: My first comment is that local functions (i.e. functions only used in the C file where you define them) should be declared "static". e.g. read_cook_extradata() and print_cook_extradata() in apps/metadata/rm.c 11.55.08 # mt: Also, you seem to have set the svn:executable flag on a lot of files (e.g. apps/metadata/rm.c) 11.58.50 # mt: I also notice some brackets don't look to be aligned properly - are there TABs in any of the files? 12.12.56 Quit rasher (Read error: 145 (Connection timed out)) 12.23.02 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.27.53 Join petur [0] (n=peter@d54C6F267.access.telenet.be) 12.52.07 *** Saving seen data "./dancer.seen" 12.55.15 Join kugel [0] (n=kugel@rockbox/developer/kugel) 12.55.27 Quit DarkSpectrum () 12.57.08 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 12.57.23 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 13.04.18 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 13.09.24 Quit Grahack ("Leaving.") 13.09.25 Quit robin0800 (Read error: 104 (Connection reset by peer)) 13.13.38 Quit Horscht ("Verlassend") 13.13.59 Quit Res1 (Read error: 60 (Operation timed out)) 13.27.25 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 13.29.44 # bertrik: what formula/how did you generate the log table for the vx747 backlight? 13.32.40 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) 13.34.54 # is there a svn command to gradually upgrade an older revision to newer versions, or do i have to always check out a full old revision? 13.35.17 # you can check out a specific revision of just one file 13.35.28 # meaning, i want to go from r21550 to r21551 to r21552, etc 13.35.39 # just give -r 1423 13.35.39 # and checking out a full version takes quite some time 13.35.49 # mcuelenaere, markun generated that curve 13.35.51 # over the same folder i used before? 13.36.08 # ah, markun: same question :) 13.36.15 # dfkt: svn update -r 3243 myfile.c 13.36.23 # dfkt: or a directory 13.36.24 # I think it was round(1+sqrt(2)^x) where x = 0..15 13.36.40 # Mikachu, thank you 13.37.45 # that seems to give 2, 3, 0, 1, 6, 7, 4, 5, 10, 11, 8, 9, 14, 15, 12, 13 ? 13.39.06 # you're doing something wrong then :) 13.39.21 # % for a ({0..15}) {echo $(( 1 + sqrt(2)**a )) }|cut -f1 -d.|xargs 13.39.21 # 2 2 3 3 5 6 9 12 17 23 33 46 65 91 129 182 13.39.25 # sqrt(2)^x - 1 13.40.01 # Mikachu: for($i=0; $i<16; $i++) echo round(sqrt(2)^$i-1).", "; echo "\n"; 13.40.20 # mcuelenaere: i think ^ in perl is xor? 13.40.20 # ah, the ^ is probaby the wrong operator 13.40.29 # and it's PHP btw :) 13.40.36 # well, regardless, ^ is usually xor :) 13.40.44 # maybe with some fiddling for the low numbers to make it linear 13.40.50 # yeah, that's the problem; thans 13.40.52 # thanks* 13.41.06 # to the power of is what I mean with that, sometimes written as ** 13.41.27 # * mcuelenaere already tried this on his TI-83, but couldn't reproduce it on PC 13.42.00 # bertrik: yes I know, I'm just not used to using math in scripts :) 13.43.33 # hm. the usb mode in this beast bootloader doesn't seem to work :) 13.45.32 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 13.45.46 # well, it doesn't show up as a disk, anyway 13.46.15 # usb-storage: waiting for device to settle before scanning 13.46.26 # then nothign :( 13.47.15 # Torne: is this just recently or .. ? 13.47.27 # this is the first time i've gotten it to boot at all, borrowed it from linuxsstb 13.47.32 # the battery was too dead for it to power on before. 13.47.46 # ah, and USB works fine in normal Rockbox? 13.47.57 # no idea, the rockbox image is missing or something 13.48.05 # and the OF doesn't appear to be there either 13.48.15 # so it just reboots over and over until you plug in usb 13.48.22 # :) 13.50.23 # ah, weird. it mounts on the windows pc 13.50.28 # just not on my linux box 13.50.50 # hi mcuelenaere 13.50.58 # hi 13.54.29 # Torne: That could be because the mbr is broken - see the GigabeatSInstallation wiki page for info on what you need to do to fix it. 13.56.37 # hmm I don't suppose theres touchscreen support for the USBPOWER_BUTTON mechanism? 13.59.29 # what's USBPOWER_BTN_IGNORE for? 14.03.55 # is that related to vbus? 14.05.36 # yes 14.09.35 Quit perrikwp ("Leaving.") 14.11.27 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 14.11.30 Join Dark_Apostrophe [0] (n=tda@unaffiliated/darkapostrophe/x-0983214) 14.11.46 # Any progess on the Cowon D2 port? 14.12.04 # Last I checked (admittedly, long ago), there were USB problems 14.13.31 # linuxstb: it doesn't even come up as a storage device connected to linux 14.13.41 # linuxstb: let alone find any partitions. 14.13.51 # linuxstb: but on windows it works fien and i can browse both partitions 14.14.01 # so i suspect my laptop is doign something stupid. it's ok :) 14.14.57 # Dark_Apostrophe, some problems with flash access were recently fixed on the cowon d2 14.15.19 # bertrik: Do you own one, or anyone else here? 14.15.30 # I'd like to hear what it's like to use Rockbox on it - the default firmware is annoying as hell 14.15.53 # Dark_Apostrophe, no I don't own one 14.16.03 # damn. 14.16.16 # Well, at least you were spared the torment of using the default fw :P 14.19.38 Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 14.20.16 # dfkt: with svn up -rXXX you can update single files/dirs, a set of files/dirs or the whole repo to that specific revision 14.20.53 # kugel: i already told him that :) 14.22.16 # yea, I just saw that :< 14.26.13 Join Grahack [0] (n=chri@ACaen-156-1-75-178.w90-51.abo.wanadoo.fr) 14.26.49 # New commit by 03mcuelenaere (r21633): Consolidate all fixed point math routines in one library (FS#10400) by Jeffrey Goode 14.29.18 # how do I install the bootloader in FS#9955 on my e200? sansapatcher -a? 14.32.08 # * bertrik wishes there was some kind of guide on what is expected of the pcm hardware functions 14.32.52 # New commit by 03mcuelenaere (r21634): Set svn:keywords property 14.33.07 # * mcuelenaere wants that too 14.35.40 # bertrik: what exactly is the issue? 14.36.17 # for example, what to do in pcm_dma_apply_settings 14.36.34 # set up the frequency 14.36.35 # should I use pcm_sampr to calculate pcm rate, or fsel, or both? 14.37.05 # * mcuelenaere uses pcm_sampr 14.37.17 # but it depends on how you internally handle the frequency I suppose 14.37.58 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 14.38.40 # * mcuelenaere wonders about the red 14.38.49 # or pcm_play_dma_get_peak_buffer, does it expect bytes, or samples? 14.39.36 # I'm not sure if I can guarantee that the peak buffer address and size are consistent with each other, without stopping dma 14.40.31 # bertrik: bytes >> 2 I think 14.42.27 # hmm this doesn't seem right, FS #10400 *increases* binsize 14.43.39 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) 14.44.59 # mcuelenaere: It would increase it some. It brings in some code that existed outside the core before. 14.45.14 # hmm then that isn't really good 14.45.30 # perhaps that should be #ifdef'd with PLUGIN? 14.45.31 # Maybe it could be split up? 14.45.48 # I thought it might be a bit bloated. What's the difference in size? 14.45.56 # http://build.rockbox.org/dev.cgi 14.46.12 # around 2,4kB 14.46.28 # So instead of #include "fixedpoint.h" it would be #include "fixedpoint/functionname.h" 14.47.54 # I thought about making subset .h files. That might be a better approach. 14.49.07 # I also wrote a coupld of brand new functions that would be exposed rather than using the actual math functions. I noticed that replaygain for instance doesn't actually need the results of exp10, it needs a gain factor. 14.50.17 Join s0u][ight [0] (n=s0ulligh@d54C4717D.access.telenet.be) 14.50.19 # !svn 14.51.07 # Nothing right now actually uses the log10 or decibel functions. Those can be #if 0 commented out right now without affecting anything. I put them in because they might be useful. 14.51.59 # output of bloat-o-meter between the two revisions: http://pastie.org/534068 14.52.09 *** Saving seen data "./dancer.seen" 14.52.45 # Tell you what, let me work more on this later today, and I'll post another patch. Can we reopen FS? 14.55.15 # Blue_Dude: re-opened 14.56.50 # Excellent. I'll have some free time later today to noodle it some more. Other than unneeded function bloat, how does this approach seem? Is it a decent kludge or are we better off exposing the core functions to plugins and codecs via the API's? 14.58.12 # Blue_Dude: this approach doesn't require much change to plugins, so I'm not against it 14.59.16 # OK. It's not very pretty but it's better than rewriting or copying code around. 14.59.20 Quit Lss (Read error: 104 (Connection reset by peer)) 14.59.39 # Blue_Dude: also, any idea about the red on the H100? 15.00.00 # Red? 15.00.04 # http://build.rockbox.org/dev.cgi 15.00.05 Join Lss [0] (n=Lss@cm33.zeta237.maxonline.com.sg) 15.00.08 Quit petur ("real-life") 15.00.15 # the two red table cells in the upper-right 15.00.20 # (click on them) 15.01.26 # That's a rather nasty delta 15.02.25 # Nope, don't know why. I'm not sure why that particular build wouldn't behave. 15.02.57 # the red looks like it's in rombox which explains why it's H100s only - if the rest of the code changes don't affect hwcodec targets (or lowmem ones) 15.04.27 # Yeah. Time to rethink this one. We're probably better off revoking the commit until it behaves everywhere. 15.05.11 # Really gotta go. Sorry to run in the middle like this. 15.05.34 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 15.14.33 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 15.18.00 # New commit by 03mcuelenaere (r21635): Revert "Consolidate all fixed point math routines in one library (FS#10400) by Jeffrey Goode" 15.18.14 Part n00b81 ("Leaving") 15.18.34 # ... 15.18.59 # Excuse me, but may I ask for the link to rm.codec? 15.23.05 # Anyone here got a Cowon D2? 15.24.47 # mcuelenaere: a comment on the reasons for reverting would've been nice 15.25.11 # yes, forgot about that (was too busy figuring out git) 15.25.18 # hehe 15.25.22 # I know that problem :P 15.25.34 # it does have a nice git revert command though :) 15.25.45 # I actually used svn to revert my mistake yesterday 15.26.00 # hehe 15.26.39 # Minthe: You'd have to compile Rockbox yourself. See http://www.rockbox.org/tracker/task/10182 for the patch 15.27.13 Join Nausicaa [0] (n=Ribbon@ppp-69-214-15-0.dsl.klmzmi.ameritech.net) 15.31.08 Quit Horscht ("Verlassend") 15.31.27 # yay, PCM on the meizu is now running at the expected rate 15.32.10 # OK, Thank you. Hopefully I have a build environment to use usbstack(since 2008) 15.32.45 Quit s0u][ight ("Leaving") 15.34.11 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 15.35.28 # I think it won't take very long now before we have first sound on the meizu 15.36.37 # Torne: "waiting for device to settle before scanning" and then nothing is the classic symptom of this hal/gphoto2 bug 15.36.47 Quit Minthe ("Leaving...") 15.40.37 # gevaerts: ah, maybe this machine is all too ubuntu-y 15.40.54 # it worked on windows anyway so it boots rockbox and charges properly now :) 15.40.58 # and i dumped the rom 15.41.10 # will post a fs# with the patch to enable flash rom dumping on beast soon 15.42.44 # gevaerts: did you see we "fixed" some issues with the c200? 15.43.12 Quit kugel (Nick collision from services.) 15.43.20 Join kugel [0] (n=kugel@85.178.117.155) 15.43.53 # rasher: I saw that, yes. I don't have a real opinion on which is the right id to use, so if this makes things work better for some people, why not? 15.44.28 # Yeah. It's not that it's more right than the other, but we might as well act like the OF when it makes things work better 15.48.55 # * Torne wonders why config-gigabeat-s.h says FLASH_SIZE is 4mb when it's clearly 2mb :) 15.49.39 # Torne: is it 2mb on all gigabeats? Maybe there are different models 15.50.01 # it's possible, i guess. the part number on the wiki is a 2mb part, and i dumped 4mb and it's mirrored 15.50.11 # but there might be a different one, yah 15.50.15 # it doesn't amtter a great deal, admittedly 15.50.26 # FLASH_SIZE is not used for anything, i was just using it for my rom dumping patch 15.50.27 # ...somebody's working on beast flash? :) 15.50.45 # Unhelpful: i'm reversing the flash code a bit, yah 15.50.54 # not *writing* to it :) 15.50.56 # to what end? 15.51.13 # tring to work out why it decides to reformat the player sometimes after rockbox has been used 15.51.36 # ah... it'd be nice if we could get the bootloader in there. :) 15.51.54 # oh. that'd be easy, probably 15.52.26 # in fact since it s a2mb flash you cuold prob ably put rockbox in there too :) 15.53.03 # the chip isn't entirely empty in this dump though so the OF might actually use some of it for purposes other htan the bootloader code 15.53.20 # hrm... and it can execute in-place from there? 15.53.39 # yp 15.53.48 # it's an intel bootflash, nor. 15.53.51 # That would be nice. The beast is quite RAM-constrained! :P 15.54.08 # well yah 15.54.09 # gevaerts: it would speed boot time quite a bit. :) 15.54.15 # Unhelpful: it probably wouldn't 15.54.32 # why? 15.54.32 # nor flash is pretty slow to read on most modern platforms compared to sdram 15.54.37 # Torne: i have the 1.3 bootflash... the one that still needs a dual-boot flash bootloader. :/ 15.54.47 # but you still save the disk spin up 15.54.57 # s/flash b/rockbox b/ :) 15.55.02 # kugel: yah. you'd want to copy to ram, rather than xip'ing 15.55.13 # probably, yes 15.55.14 # Unhelpful: what's the difference between the firmware versions, btw? :) 15.55.23 # but it would most likely improve boot time 15.55.32 # i don't know anything about the beast besides what i've just figured out by dumping its rom and reading the wiki 15.55.49 # Torne: i don't really know... i believe 1.3 was a fix for the leap-year bug. 15.55.53 # not sure which one this is in flash 15.55.57 # but it's not 1.2 or 1.3 15.55.59 # Most boot time improvement would come from just not half-booting the OF 15.56.11 # gevaerts: like i did on ipod, kinda ;) 15.56.29 # exactly. ideally we'd like to be able to chain-load the OF from the RB bootloader, or from RB itself 15.56.29 # anyway yah. it can go on the list. 15.56.30 # Torne: on the ipod, it only loaded that bit :) 15.56.33 # also it's a bit more than half. :) 15.56.59 # gevaerts: still took over a second :) 15.57.28 # Torne: try measuring how long it takes on the beast 15.57.39 # this beast doesn't ahve the OF 15.57.42 # Torne: if you have a patch for a flash dump plugin, i can get my installed 1.3 flash for you. i'm *pretty* sure it installed new flash - i used the updater tool on windows, and it acted very much like it was writing to flash, with all of the warnings that tend to go with that. 15.57.48 # nk.bin is just the rockbox bootloader 15.57.58 # Unhelpful: taht would be nice. i'll be uloading the patch shortly 15.59.20 # Unhelpful: did it seem like it 3as flashing during the update, or during the subsequent reboot? 16.01.11 # 3as? 16.01.16 # was 16.01.25 # eee 701 keyboard :) 16.01.33 # and smoking. 16.01.35 # ...ah. i *believe* during the reboot, but this was some months ago. 16.03.11 # yah, the boot log on the wiki implies that it compares the files on disk with the ones in flash at boot and reflashes if it's newer, but that may not be right 16.04.06 # * bertrik hears noise from his meizu \o/ 16.04.10 # which vesions need the dual flash bootloader? and why? :) 16.04.22 # er 16.04.23 # well, not mine actually, gevaerts' 16.04.25 # dual boot :) 16.04.41 # this beast obviously doesn't, nk.bin is just our bootloader 16.04.45 # the OF is not there 16.05.32 # so it boots quite fast :) 16.07.22 Quit Nausicaa (Read error: 110 (Connection timed out)) 16.07.25 # Torne: mine came with 1.2, i don't think it reveals a flash version if that's versioned separately at all... it worked with single-boot RB bootloader then. the official update to 1.3 broke single-boot. running a dual-boot built with the 1.3 nk.bin didn't - i did that for a bit first, and obviously booting a 1.3 nk.bin doesn't do anything to tha flash. 16.08.18 # yah, i think to trigger the reflash you have to put the other .bin files on there 16.08.29 # it probably deletes them after a successful flash 16.10.16 # oh, of course, that's what else is in the flash: the recovery image 16.10.19 # it had other .bin files after i started - perhaps some flag is set when they're uploaded, and cleared when they're flashed. 16.10.32 # still doesn't need 2mb though 16.11.05 # Unhelpful: yah, normally i think the updater will copy all three bins ont ehre, and then it'll reflash the bootloader and the recovery image 16.11.16 # the log implies it's timestamp based 16.11.19 # rather than a flag 16.12.25 Join _lifeless [0] (n=lifeless@188.16.122.193) 16.13.00 # that would work too... it doesn't seem to remove them, but it will work just fine if you do. nk.bin alone will boot it. 16.13.11 # yup. this beast only has nk.bin 16.13.26 # (which is our bootloader) 16.13.41 # i love the signature check bypass thing, btw 16.13.49 # its' just hilarious. 16.14.30 # such a stupid bug in the loader :) 16.16.03 # i've actually never looked at how we do it :) 16.16.44 Quit Horscht ("Verlassend") 16.17.03 # bertrik: congratulations! "Ladies and gentlemen, we have noise!" 16.19.23 # Unhelpful: the nk.bin consists of a series of records, with a load address and size for each 16.19.35 # Unhelpful: but it doesn't bounds check the load addreses, and the bootloader is running from RAM by this point 16.19.47 # Unhelpful: so you can tell it to load a record at an address that overwrites part of the bootloader 16.19.55 # disabling the signature check by branching past it. 16.20.09 Quit {phoenix} (Read error: 110 (Connection timed out)) 16.20.58 # so one 4 byte record with a branch instruction in it disables all the security. 16.21.00 # :):) 16.21.09 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 16.22.50 # ...and it loads *all* of these records before it checks anything for signatures? 16.23.42 # yes. because the records collectively constitute the thing it's signature checking :) 16.24.01 # it loads them into ram at their desired addresses to save having to shuffle it all around, i guess 16.24.15 # it would be a waste of time to load the file and check it then just have to relocate all the data again :) 16.24.46 # it should really check that the records aren't going to overwrite the bits of ramt he bootloader is using, but good for us taht it doesn't :) 16.25.29 # ok, the flash dump patch is FS#10410 if you wanna give it a go 16.26.53 # the devil is in the details huh 16.27.22 Quit __lifeless (Read error: 101 (Network is unreachable)) 16.30.00 Join {phoenix} [0] (n=dirk@84.180.97.33) 16.31.30 Quit lilltiger (Read error: 110 (Connection timed out)) 16.34.12 Join fdinel [0] (n=Miranda@24.203.232.204) 16.35.46 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 16.48.57 Quit robin0800 ("Leaving") 16.49.26 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 16.50.06 Quit efyx_ (Remote closed the connection) 16.52.00 Quit Grahack (Read error: 60 (Operation timed out)) 16.52.14 *** Saving seen data "./dancer.seen" 16.52.39 Join Grahack [0] (n=chri@ACaen-156-1-75-178.w90-51.abo.wanadoo.fr) 16.55.56 Join Mysterytrain [0] (n=George@66-216-236-32.dhcp.stcd.mn.charter.com) 16.56.52 # Torne: http://looking-glass.us/~chshrcat/rockbox/flash_rom_A0000000-A03FFFFF.bin 16.58.49 Part Mysterytrain 16.59.15 # Unhelpful: cheers, i'll compare it to the other binaries i have ;) 17.01.44 # * Unhelpful wonders how he can even look at this... arm-*elf*-objdump obviously doesn't like a raw memory dump 17.02.11 # just tell it the file type is 'binary' 17.02.48 Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-45a2ff58d588606a) 17.03.24 # the voltage scaling patch for AMS seems to fail completely on some Clips, i think we shoudl revert it for now 17.04.16 # i'm looking for such an option... 17.05.13 # Unhelpful: -b binary 17.05.29 # saratoga: It also seems to not work with SD cards according to one post in the thread? 17.05.44 # http://www.rockbox.org/twiki/bin/view/Main/ObjdumpGuide 17.05.50 # that as well 17.08.46 Join PaulPosition [0] (n=alex@modemcable013.174-56-74.mc.videotron.ca) 17.10.54 Quit dmb (Read error: 104 (Connection reset by peer)) 17.14.24 Join stoffel [0] (n=quassel@p57B4D030.dip.t-dialin.net) 17.14.53 Quit robin0800 ("Leaving") 17.15.30 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 17.18.03 # saratoga: we should try to boost on sd transfers first (or scale voltage only), imo 17.18.22 # Llorean: only some 17.19.05 # unfortunately, the uSD of the devs all work just fine 17.19.50 # kugel: i think that the big "non-scrollwheel" change in the PF keymap caused some trouble. it was previously using the scrollbar for scrolling on H10... it still does now, but the right/left buttons are now scroll as well, and there's no select/cancel. 17.19.56 Join Minthe [0] (n=Minthe@KD124214153219.ppp-bb.dion.ne.jp) 17.19.57 # Torne: can we try to stop bloating debug_menu.c with target dependant code? I'd rather have it in the target tree 17.20.04 # Trying to get the pictureflow plugin working with my target's keymap (iriver H10)... The code first defines a lot of actions from ACTION_STD_* and then proceeds to overload them anyway with target-level (?) (BUTTON_LEFT, etc.) names... is there any other plugin which does things similarly and which I could use to compare and understand the logic? (I'm not a coder but I still have half a functioning brain) 17.20.41 # there's the fellow with the problem, in fact. :) 17.20.56 # ohj, lol 17.21.16 # Unhelpful: I think having left and right is nice, but not a requirement. People are probably expecting to use the scrollpad anyway on the h10 17.22.34 Join AndyI [0] (i=AndyI@212.14.205.32) 17.22.41 # kugel: that's what i'm fairly sure it was doing before a huge block of CONFIG_KEYPAD got replaced with HAVE_SCROLLWHEEL... we probably need to treat the H10 as a scrollwheel target. 17.22.41 # (let it be known that the scrollpad has always been a buttonUp/buttonDown affair on the h10 (ie, it never 'scrolled').. Does the H10 identifies itself as scrollwheel device? 17.22.55 # no 17.24.05 Part Dark_Apostrophe ("I tawt I taw a puddy tat") 17.24.37 # the problem is only about pictureflow, where the albums covers are are basically horizontal list, hence using some left/right buttons is desire-able 17.24.40 # PaulPosition: it's not how you scroll in lists? 17.24.48 # desirable* 17.24.58 # kugel: the rom dumping thing could easily be a generic function with target defines for where the rom[s] are.. 17.25.00 # kugel: yes, but the H10 doesn't have a d-pad layout. 17.25.06 # well i say easily 17.25.14 # *fairly* generic. :) 17.25.14 # Yeah, I meant to say that it's not a 'flowing scroll' ie, upper part is button up, lower part button down.. You don'T slide along... 17.25.54 # generic is fine, but debug_menu is already full of highly target-dependant, non-generic stuff, and it's a nightmare 17.27.46 Quit Horscht ("Verlassend") 17.28.11 # all the versions of the dumping functions are the same, modulo where they dump from and whether they have to turn off the memory guard 17.28.30 # i'll maybe look at that another time ;) 17.28.48 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 17.30.03 # PaulPosition: i think this should sort it... basically treats the H10 like a scrollwheel target: http://pastie.org/534163 17.30.43 # Unhelpful: the standard actions pf uses... where are they taken from? I ask because there are a few contexts that e.g. remap ACTION_STD_OK 17.30.49 # unhelpful - well that's helpful.. Mind if I take some time examining it (for learning) before I compile and test? :) 17.30.55 # Unhelpful: the start of your beast's flash is substantially similar to the unpacked 1.3 boot binary :) 17.30.59 # I'll just cheat my way to a full database. Tell it to update and shut it down (and thus having it commit its update) before it crashes. At least, I hope that'll work 17.31.05 # not at all :) 17.31.07 # Unhelpful: but as you noticed there are quite a few flipped bits in the unused regions 17.31.31 # and some substantial changes later on as well 17.31.35 # so that's.. interesting ;) 17.31.52 # pixelma: they chain to CONTEXT_TREE on everything but M3, where they chain to CONTEXT_REMOTE 17.32.07 # Unhelpful: this has nothing to do with scroll or not scroll 17.32.15 # the h10 uses his scrollpad as plain buttons 17.32.57 # left / right is ACTION_STD_CANCEL and _OK on many targets. 17.32.58 # kugel: but it maps the scrollpad to PREV/NEXT, and the non-D-pad layout makes the mapping that other targets use make very little sense. 17.33.24 # what information would I have to put up on a speaker that docks and has a remote to help advance the iPod accessory protocol 17.33.26 # ? 17.33.35 # that's right, but the HAVE_SCROLL define is missleading IMO 17.34.06 # perhaps call it "USE_CORE_SCROLL" or "USE_CORE_PREVNEXT"? 17.34.12 # the samsungs would have the same problem 17.34.25 # they have up/down and left/right, but no select that's in the middle 17.34.40 # I compiled pf for testing, and I couldn't access the track list 17.34.42 # froggyman: you'd probably need to be willing to dump the serial connection between it and the ipod while in the original firmware 17.34.54 # so we can see what it's supposed to do 17.35.06 Quit AndyIL (Read error: 110 (Connection timed out)) 17.35.14 # this would need you to buy/make suitable cables to break out the dock port and watch it from a pc :) 17.35.36 # I don't think using up/down for scrolling through the covers is a big deal, if any other list uses up/down too 17.35.42 # froggyman: i presume it doesn't work at all at the moment? 17.35.53 Quit Horscht ("Verlassend") 17.35.57 # I actually used up/down on the samsung before trying left/righ 17.35.58 # Torne, That is correct 17.35.59 # t 17.36.10 # froggyman: do you not even get audio out? because that *generally* always works 17.36.28 # Torne, well that is the one thing that does work 17.36.36 # right. so you just can't control the ipod with it 17.36.41 # Torne, correct 17.36.48 # i think on targets with a d-pad layout for up/down/left/right, and a standard select mapping other than right, it makes sense to use l/r to scroll the album list. if *any* of those conditions changes, we should probably use the standard prev/next mappings. 17.37.36 # I agree 17.37.52 # but is there an easy way to detect without target specific #ifdefs? 17.38.14 # i rather doubt it, unless we add a define in core that is based on target specific ifdefs. :) 17.38.26 # froggyman: http://www.rockbox.org/tracker/task/9951 17.38.47 # and i see from the UI bmps that our development samsung targets have rather, um, interesting button layout choices. 17.38.55 # froggyman: also http://www.rockbox.org/twiki/bin/view/Main/IpodAccessories# 17.39.23 # froggyman: if you report the info those pages ask for someone may be able to figure it out, but if you really want it to work then dumping the serial data is much more informative ;) 17.39.27 # i have a YP-Z5 that i mean to *try* to work on porting whenever i find a charger for it :) 17.39.46 # Unhelpful: interesting as in pain 17.40.06 # it has no plugins yet because you can't have sane button mappings, basically 17.41.37 # indeed. the Z5 is nearly as bad... or maybe worse? there's a touchpad in the center that registers touches along the edges as directional input, but can be pressed to select. it's framed by a square frame that can be pressed on any of the sides, which are labeled with functions. and there's a rocker on the side for volume. 17.42.42 # Hm. I think I know how I could fix this problem. All the important stuff is codec in C, I suppose? 17.42.49 # btw, I still need testers for http://www.rockbox.org/tracker/task/10387 17.43.18 # drakonik: except for speed-critical sections that may have some assembly, yes. 17.43.30 # Awesome. 17.43.36 Quit jkl (Read error: 60 (Operation timed out)) 17.43.51 # Now I gotta learn C and figure out how to make the database commit each song as it finds it 17.44.07 # Which should be pretty simple. 17.44.24 # that's, um, not codecs, and why do you want that? 17.44.33 # ... 17.44.35 # *Coded 17.44.36 # Not codec 17.44.38 # shit 17.44.40 # Anyway 17.44.52 # Unhelpful: The db scanner crashes for some reason. 17.45.24 # But because the scanner doesn't commit till it finishes scanning or the player is shut down,the crash means whatever GOOD files it finds don't get committed 17.45.50 # I don't think changing the way it stores its entries will help you find out why 17.45.55 # No, it won't 17.46.00 # But. 17.46.32 # it will also make DB scanning much slower for the vast majority of users for (to them) no good reason. 17.46.39 # Oh, of course 17.46.45 # I was going to use it for myself alone 17.46.51 # pixelma: the ondio and c200 have some issues with PLA, correct? 17.47.09 # If I have the database fully populated except for the bad files, I'll be able to find the bad ones by comparing the full list against the database list 17.47.32 # drakonik: you can't commit the db by song by song, that would be _extremely_ inefficient 17.47.41 # Well aware of that. 17.47.46 # assuming the db traverses in a specific sort order, which is probably a wrong assumption 17.48.09 # I'm just pretty desperate to get Rockbox working. 17.48.19 # drakonik: the proper thing to do would be print the store the log of the db scanner in order to find the corrupt files and fix the problem 17.48.23 # _maybe_ you can find the troublesome files if you throw it into a simulator and initialise the db there? 17.48.24 # * kugel thinks Slasheri has auto-ping if someone mentions "DB" or "database" 17.48.31 # -print 17.48.31 # s/it/them 17.48.42 # Slasheri: How would I do that? 17.48.43 # kugel: indeed, i have "database" in my hilight :) 17.49.06 # drakonik: look at the function "add_tagcache" in tagcache.c 17.49.17 # * Unhelpful suggests compiling a database of games that are playable in rockboy per-target ;) 17.49.23 # Gotta brush up on my C. 17.49.32 # there you could add some code that adds the current file being processed to some log.txt file 17.49.37 Join toffe82 [0] (n=chatzill@adsl-71-132-80-79.dsl.sntc01.pacbell.net) 17.49.42 # pixelma: is that correct? If yes, can you try out http://www.rockbox.org/tracker/task/10387 please? 17.49.54 # Why, after so long, do we not have a better way of debugging database crashes than binary search? 17.49.58 # well, actually a test would be nice no matter of existing problems 17.50.17 # rasher: on target i don't think there *is* a better way without a performance hit... 17.50.37 # Unhelpful: There could be a "log database creation" option, in the debug menu or something 17.50.47 # rasher: we could always write a logfile or something like that but that would slow down the db building 17.50.54 # kugel: does this seem less "miss" leading? http://pastie.org/534178 17.51.31 # isn't there an entry that should show the currently processed file in the db debug menu? 17.51.35 # maybe just UP_DOWN_SCROLLING?, but yea, it's less misss leading :) 17.51.55 # pixelma: indeed there is 17.51.55 # Slasheri: couldn't the debug menu have a "initialize database with log" entry? 17.52.08 # Yes 17.52.11 # That would be awesome 17.52.22 # Which enables a bit of logging code 17.52.50 # Slasheri: btw, we were wondering what the count at building db actually counts. is that the total number of files and dirs traversed, or the found tags? 17.52.50 # we could also offer a pluginlib import of the tag scanner, with some defines that insert logging code, and a plugin to run it. zero cost to a non-debug run in core, that way... 17.53.02 # What I will need help with is compiling the code for my ipod. 17.53.21 # kugel: yes, some plugin controls don't work correctly on the Ondio and on the c200 due to PLA (and context "overlapping") and I might try the patch this weekend - but don't have much time (and energy) currently because of RL things 17.53.27 # pixelma: and entering "view db info" slows done the building a lot because the engine will wait for the screen to update the current file being processed. So that should already help if used 17.53.37 # drakonik: there is a page or three on the wiki about setting up a compiling environment 17.53.43 # Okay. 17.54.04 # C first, wiki later, success eventually 17.54.07 # I refuse to give up 17.54.09 # kugel: it's the total number of files and dirs 17.54.16 # drakonik: i would suggest you try building the DB in a sim, presumably the problem is not in target-specific assembly. 17.54.29 # drakonik: okay, try starting database initialising and going into System > Debug menu (keep out!) > View database info 17.54.35 # Unhelpful: Alright. I just have no idea what that means. 17.54.38 # a crash in the sim can be trapped by a debugger... 17.54.49 # * pixelma wants some points for that ;) 17.55.00 # hrm 17.55.17 # Progress: -1% (0 entries) 17.55.25 # I don't think that's quite right... 17.55.52 # Nope. 100% wrong. I've got 700 songs in the db so far. 17.55.52 # drakonik: wait for a while, database creation is slow when you're in that screen 17.56.02 # Nah, I checked it jsut now 17.56.12 # I'll clear out the db and reinitialize 17.56.21 # I told you to initialize... 17.56.28 # And I'm doing it now. 17.56.43 # Why did you not do as I told you? 17.57.07 # I wanted to see what the db info had to say for a good database, before I wiped it. 17.57.10 Quit bmbl ("Bye!") 17.57.13 # Start "Initialize Now", go to System > Debug menu (keep out!) > View database info and wait! 17.57.32 # Slasheri: ok. it shows some 3k-4k on my e200, I don't think I have that many files and folders 17.57.37 # Progress doesn't make sense if you're not in the middle of a scan... 17.57.41 # but you know it better :> 17.58.00 # anyone got the gigabeat s updater version 1.1? 17.58.17 # kugel: it might count . and .. as files also, i don't remember 17.58.41 # ah, that would make more sense 17.58.43 # Slasheri: err, does Curfile: not scroll? 17.58.59 # Torne: i rather doubt it... i think the only one seen in the wild as an official updater is 1.3? 17.59.05 # Slasheri: having a log feature would be really nice, then we'd get more bug reports and could look into codec bugs that cause them 17.59.08 # i have 1.2 and 1.3 17.59.12 Quit stoffel (Read error: 60 (Operation timed out)) 17.59.25 # the toshiba page linked from the wiki has 1.2 and a different bit of toshiba's site has 1.3 17.59.57 # hah! 18.00.01 # I actually didn't know the database info screen shows that 18.00.04 # Some goddamn beatles song causes thecrash 18.00.16 # I've been looking for an excuse to get rid of that stuff 18.00.21 # drakonik: DONT 18.00.26 # Oh, right. 18.00.27 # derp 18.00.29 # For the love of god. We want the file 18.00.34 # I'm not sure which one it is. 18.00.50 # The debug page only shows like 15 chars and most of that was the directory info 18.01.03 # drakonik: try a smaller font 18.01.07 # There are some really tiny ones 18.01.07 # :O 18.01.11 # facepalm.jpg 18.01.19 # I just bumped my font size up, too 18.01.45 # Hum, it actually cuts off the display 18.01.50 # So that won't help much 18.02.03 # Maybe it'll be enough though 18.02.03 # Only 10 possible files 18.02.10 # Let's see... 18.02.10 # So remove half, try again 18.02.14 # Torne: i never knew we had an official 1.2 updater... before the 1.3 one was found i'd never heard of an updater in the wild, part of the trouble with dual-boot was that the only nk.bin we had came from dumping from the HDD. 18.02.24 # (and maybe remove or put a database.ignore to ignore the rest of your files) 18.02.48 # http://www.tacp.toshiba.com/customersupport/ has 1.2 18.02.56 # you have to go through a flash applet to get the real download link :) 18.03.07 # or just make a "removed" dir with a database.ignore in it and move files in and out of it to "remove" them from scanning 18.03.19 # That was my plan 18.03.29 # Except explorer is locked up 18.03.31 # markun: ping 18.03.33 # Go Windows! 18.03.57 # see now i'm unsure which binary to reverse :) 18.04.11 Quit saratoga ("CGI:IRC (Ping timeout)") 18.04.13 # the copies from the updaters are 'neater' in that they don't have garbage in unused areas etc 18.04.22 # but neither updater is the version that's in flash on the player I have :) 18.04.45 # interesting. is the 1.3 updater similar to what was in my ROM? 18.04.57 # the beginning is almost identical except in the unused areas 18.05.03 # but nearer the end it is not the same 18.05.25 # the certificates etc seem to start at a different address 18.05.36 # crap, the DB info debugger didn't show any curfile info 18.05.39 # But it still crashed. 18.06.05 # Unhelpful: yours has the same checksum in the header as the 1.3 updater, at least 18.06.25 # but i'm not sure which bits that's a checksum *of* 18.06.34 # it can't be the whole lot because yours doesn't match :) 18.06.51 # I don't actually know why the simplelist is croping the entry there anyway 18.07.20 # presumable a checksum of the ranges of records in the .bin file? 18.07.36 # possibly 18.07.43 # drakonik: drakonik maybe you weren't fast enough 18.07.45 # anyway, yours looks like a different build, i have to say :) 18.07.48 # Yeah... 18.07.52 # I'm gonna see what I can do 18.08.01 # Updated the build, which should wipe the database and give me a clean start 18.08.04 # drakonik: try adding back some "irrelevant" files, and moving the suspect ones into a shorter path (a.mp3 b.mp3 etc) 18.08.05 # the ethernet bootloader's strings have a different date in 18.08.22 # yours says "built jan 15 2007" and the 1.3 updater says feb 3 2009 18.08.23 # drakonik: updating doesn't wipe the db 18.08.29 # no? 18.08.34 # deleting the *.tcd files in .rockbox does 18.08.34 # No. 18.08.36 # oh, duh 18.08.39 # updating doesn't wipe anything if we can help it 18.08.42 # :) 18.08.42 # kugel: there's no reason to do that 18.08.45 # or initialise 18.08.48 # Just do Initialise Now 18.09.02 # That makes sense. Mine crashed, it never committed, there was no db ever initialized 18.10.36 # Unhelpful: Ooh. Actually, now i have my brain turned on, yours is *much* more similar to the 1.2 updater 18.10.37 # Okay, battery is dead. Gotta let it charge up in ipod firmware mode for a lttle while 18.10.52 # :( 18.10.52 # Torne: i wonder if the update always contains a complete ROM, or if they only put records in the bin file for specific ranges, and it's treated as a sort of patch... 18.10.53 # everything between 0x1000 and 0x30b20 is identical 18.12.04 # in fact the only difference between yours and 1.2 is that some areas are data in yours that are 0 in the updater 18.12.15 # presumably because there was something bigger in your flash before? i dunno 18.12.25 # so i think you actually have the 1.2 eboot in your flash. 18.12.51 # 1.2 -> 1.3 have very few changes in the bootstrap code, but more in the nk.exe 18.13.12 # is my suggestion to try and find the files in the sim that bad? 18.13.27 # pixelma: No, but it requires more setup than this 18.13.49 # Once I've exhausted this, I'll move on to that. And once I've exhausted that, I'll move on to coding up a debug log. 18.14.11 # well, you probably won't need to wait for some charging etc. 18.14.24 # Torne: it did something suspiciously like writing to flash during the 1.3 update, and since then won't accept a rb-only nk.bin :/ 18.14.36 # Touché. 18.14.45 # Unhelpful: well, i can't explain that :) 18.15.14 # * Torne checks the ranges in 1.2's pmcboot_secure.bin to see if it's really all the same 18.15.40 # installing an RB-only nk.bin triggers format->ask-for-firmware-upload 18.17.06 # yup. every range of bytes that's present in pmcboot_secure.bin from the 1.2 update is exactly what's in your flash 18.17.20 # very odd. :/ 18.17.23 # and it doesn't seem to just be a patch 18.17.32 # it seems complete as far as the CE dumping tools are concerned 18.17.39 # it's happy to believe that's a bootstrap and nk.exe 18.17.50 # Awesome. The db initializes and crashes, but the debug screen only shows "---" for curfile. 18.18.18 # drakonik: As I said, add some unrelated files to delay the crash a bit 18.18.29 # It's probably crashed before you even reach the debug screen 18.18.32 # Well, it takes 30 or 45 seconds to crash 18.19.06 # And during that time, 'curfile' never changed to an actual file, it was just stuck at '---' 18.19.55 # And yet, it actually did what we want it to the first time you tried. 18.20.07 # Which is why I'm so weirded out. 18.20.20 # Unhelpful: i think i'm going to try and reverse the 1.2 version for now, from the updater 18.20.32 # Unhelpful: it doesn't match what's on the beast i have but hey. 18.20.49 # does the beast you have do spurious reformats at all? 18.20.54 # haven't a clue 18.20.55 # drakonik: And yet you don't want to try anything else? 18.20.58 # only booted it twice 18.20.59 # I do. 18.21.04 Quit jon-kha (Read error: 145 (Connection timed out)) 18.21.08 # I'm just working on them from least to most difficult 18.21.23 # Unhelpful: it's not my dap, borrowed it from linuxstb 18.21.31 # I'm looking up how to do a sim like pixelma suggested now 18.21.40 # since for whatever reason, the db debug isn't working 18.21.51 # drakonik: It is working. You saw it worke. 18.21.59 # Yeah,but then it stopped working. 18.22.08 # * rasher sighs 18.22.16 # I dunno why, and I can't fix it. 18.22.19 # It is the same code. It did not "stop working" 18.22.28 # Of course. 18.22.41 # But for whatever reason, curfile was no longer being updated. 18.22.57 # And I say, probably because it was already done 18.22.59 # or it was, after you removed the non-offending files, crashing before you could look at debug... 18.23.43 # Unhelpful: hm, or maybe 1.3 since that way anything discovered is indirectly applicable to everyone ;) 18.24.52 # I'm going to start this install 100% fresh. latest build, no previous settings or db from before. All the non-relevant files are in a folder with a database.ignore file in it. 18.25.38 # drakonik: NO! 18.25.49 # no? 18.26.01 # drakonik: Do *not* put all the irrelevant files in a folder with a database.ignore file in it. Will you please listen to what we're telling you? 18.26.41 Quit MarcGuay_ (Read error: 110 (Connection timed out)) 18.27.44 # The first run I did watching the debug page, the scanner crashed on some Beatles song. I've taken all my beatles files and put them where the db can scan them. I'll eventually be able to pare it down to the one file causing trouble. Or multiple files. 18.27.45 Join MarcGuay_ [0] (n=chatzill@ip216-239-79-254.vif.net) 18.28.12 Join Nausicaa [0] (n=Ribbon@ppp-69-214-15-0.dsl.klmzmi.ameritech.net) 18.28.12 # If that's not the approach I should be taking, I misunderstood. 18.28.28 # drakonik: 1) It could be crashing on the file *after* the beatles songs 2) You've just told us that that approach means you did not get to see the debug screen while it was building. 18.28.39 # drakonik: Add some irrelevant files. A few albums or such 18.28.50 # To make sure you reach the debug screen before it's done 18.30.17 # Yeah. Makes sense. 18.36.53 # gevaerts: do you think anything speaks against committing the plugin-goto-wps work? 18.37.13 Quit Nausicaa (Read error: 104 (Connection reset by peer)) 18.37.29 Join stoffel [0] (n=quassel@p57B4D030.dip.t-dialin.net) 18.38.47 # kugel: there's this bit in RFA that I don't really like that I mentioned last night, but I can fix that later. I seem to recall that some people didn't like the idea in general though, and I'd like to know why :) 18.47.06 # unhelpful - Thanks, that patch from http://pastie.org/534178 made it all work, thanks. Would you mind posting it to the tracker ( FS#10404 ) in case there is need for further discussion and so it may some day make its way into 'current build' ? 18.49.01 # PaulPosition: if it works, i don't think it really needs discussion. 18.50.39 # heh.. dunno about the inclusion in svn and closing task process so you may well be right. :) 18.52.15 *** Saving seen data "./dancer.seen" 18.52.36 # lot of keymap stuff can already be tried in a sim (at least the software part, not the electrical or mechanical limitations or awkward button placement though) 18.53.07 Join lee321987 [0] (n=chatzill@76.235.54.44) 18.53.10 # ugh, I put in filler files and did the scan, but curfile isn't showing anything other than '---' 18.53.29 # How fast does the db scanner work? Would it be able to do about 40 files in under 3 seconds? 18.54.28 # is there any possible way to update RB when disconnected from the computer (from an update on the external MicroSD card) on a c200v1? 18.56.27 # yes, if you have the unzipped .rockbox folder on the card you should be able to copy it over the other one on the internal memory (note: haven't tried on the c200 and my try on the Ondio is some years ago...) 18.56.46 Quit stoffel (Remote closed the connection) 18.57.28 # I think I found it. 18.57.36 # some people also tried patched builds that can run off the microSD, if I remember correctly 18.57.47 # Tried to play Lucy in the Sky and I got a crash 18.58.52 # Except it didn't crash the second time I tried to play it. 18.59.52 # New commit by 03unhelpful (r21636): Replace HAVE_SCROLLWHEEL in PictureFlow with USE_CORE_PREVNEXT, defined on targets where special horizontal-scroll mappings are broken or make no ... 19.00.34 # PaulPosition: thanks for testing that, it should be in the regular builds shortly. :) 19.01.13 # Thanks a lot mate :) 19.01.48 # Unhelpful: Was that to fix FS#10404 ? 19.02.50 # AlexP - it is. 19.02.52 Quit scorche (" rawr...that is all...rawr") 19.03.18 # Unhelpful: It is nice practice to mention the FS# you fix in the commit message :) 19.03.36 # AlexP: i'm on that now :) 19.03.49 # How? 19.04.10 # If it has already been committed? 19.04.25 Quit Grahack ("Leaving.") 19.04.32 Join doink12121 [0] (n=nick@69.183.22.11) 19.04.34 # oh... yes, i see what you meant. i was addressing the open FS task. :/ 19.04.55 # Unhelpful: Yeah, it is just useful to have blah blah blah - fixes FS#xxxx or whatever 19.05.21 # i am trying to get rockbox working on my sansa clip using ubuntu but it wont reconize the mount point and it keeps giving me an error 19.05.35 # Unhelpful: and if you do it as FS#xxxx it gets automatically parsed on the website so you can click on it and go straight to the task :) 19.06.23 # and i try to do that, but forgot that there was a related FS task. thanks for the reminder. :) 19.07.01 # pixelma: It just worked on my c200. I thought maybe some of the executables couldn't be overwritten while not in USB mode. Thanks. 19.07.53 # Unhelpful: Hehe, just me being officious :) 19.08.16 # lee321987: No, Rockbox is copied to RAM then run 19.13.46 # alright, time to see what I can do in the sim 19.14.21 Quit robin0800 ("Leaving") 19.14.44 # how do i know if rockbox is working, i installed it but my player hasn't changed at all 19.15.58 # then it's not working 19.15.59 # :) 19.16.08 # doink12121: then it's not running, and you're in what we often call the "OF" (Original Firmware) 19.17.37 Quit HellDragon (Connection timed out) 19.17.38 # will rockbox ever work with the original sansa clip 19.17.56 # because i just google the models numbers from the sansa menu, and its looking quite grim 19.19.12 Join scorche [50] (n=scorche@rockbox/administrator/scorche) 19.22.56 # doink12121, yes it will eventually work 19.27.04 Quit daurnimator ("Ex-Chat") 19.28.32 Quit fyrestorm ("lamers envy me like they envy bill g -- main boot xp, just the way it should be!") 19.32.13 # okay, copying music over to the simulated disk. shouldn't take more than six or seven hours :| 19.33.02 # drakonik: what OS are you using? 19.33.06 # Windows XP 19.33.21 Quit flydutch ("/* empty */") 19.33.31 # ugh... that makes things a bit more tricky, i was going to suggest you symlink it. :) 19.33.38 # I considered it 19.33.48 # But I wasn't sure if that'd actually work 19.35.00 # I was exaggerating 19.35.06 # it should work fine, but be very very very careful about what you do to the directory after that 19.35.17 # But it takes an hour or more to copy my 7 gigs or so of music 19.35.22 # a recursive delete of the simdisk would descend into your player, i believe. 19.35.30 # haha 19.35.42 # Don't worry, I've abandoned the command line here 19.35.53 # WIndows is...not good for command line work. 19.37.58 Quit DarkSpectrum (Read error: 60 (Operation timed out)) 19.38.24 Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) 19.39.27 Quit linuxstb (Read error: 104 (Connection reset by peer)) 19.40.23 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 19.40.47 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 19.41.12 # okay, symlink didn't work 19.41.38 # But instead of copying the music into the disk folder 19.41.46 # I'll just move the disk folder to the music folder 19.41.57 # ...you could do that. :) 19.42.01 # i guess. 19.42.07 # It's not a great solution 19.42.24 # but better than duping 7 gigs of music on my hard drive 19.42.36 # symlink works fine on linux... and i'd hope Vista since that has "real" symlink. i'm surprised a junction on XP doesn't do the job. 19.42.54 # Well, a lot of things you'd expect to work in Windows don't 19.45.29 # a junction would work 19.45.54 # but i am guessing drakonik isn't aware of them :) 19.46.05 # which is not a surprise given that windows contains no tool to create them 19.46.06 # Nope 19.46.14 # Aha, there we go 19.46.18 # Now I'm getting useful data 19.46.55 # hmr 19.47.11 # How do I reboot the sim? If I close it and rerun the executable, that counts as a reboot right? 19.47.23 Part doink12121 19.47.56 # Well. Shit. 19.47.58 # This is bad. 19.48.11 # The sim loaded up everything flawlessly. 19.48.15 Quit flux (Read error: 60 (Operation timed out)) 19.49.21 # ooh... 19.49.32 # What are the odds that I could copy .rockbox from the sim, into my ipod? 19.49.34 # and ahve it work? 19.49.46 # why would you want to do that? 19.50.02 # Because the shit on my ipod oesn't work for whatever reason 19.50.07 # and the shit in the sim does. 19.50.25 # So, hopefully, if I copy the sim data into the ipod, it will work. 19.51.01 # no....it would be better if you figure out why "shit" doesnt work on your ipod... 19.51.03 # if metadata parsing crashes on target but not on the sim my first suspect is gonna be alignment, pretty much automatically ;) 19.51.16 # Torne: Alignment? 19.51.32 # drakonik: not something you can do anything about. a bug in one of the metadata parsers. 19.51.35 # Scorche: I tried, but crashes are inconsistent and the debug tools don't work when I need them to 19.51.38 # So 19.51.39 # =\ 19.52.14 # and no, the files in .rockbox are not even relevant to this, the metadata parsing is all in the main rockbox binary (and the ones from the sim wouldn't work anyway) 19.52.24 # I figured as much. 19.52.29 # But I hoped 19.52.52 # So alignment. What is this problem? 19.53.33 # the details are not very interesting unless you are going to fix the code yourself :) 19.53.38 # Well 19.53.45 # I couldn't 19.53.47 # we basically can't do anything unless you can track down which file(s) cause it to crash. 19.53.54 # That's the problem 19.54.00 # it's not a single file 19.54.09 # Sometimes it's one, sometimes it's another. 19.54.28 # At least as far as playback goes. 19.54.42 # it crashes on playback as well? i must've missed you saying that 19.54.45 # I can't get an accurate fucking readout of what the db is scanning when it crashes 19.54.59 # Only sometimes. 19.55.26 # "a real OS" and "run under gdb" would be smart. 19.55.31 # Like, Lucy in the Sky With DIamonds caused a crash, but I rebooted and played it through twice 19.55.36 # drakonik: that is why we suggest doing a bunary search method to figure out which file(s) cause the DB scanning to have issues 19.55.36 # And no crash 19.56.07 # it sounds like it's crashing in metadata parsing, at which point it's not the file that's currently playing which will be causing the crash, but the one that's currently being read into the buffer 19.56.11 # scorche: Yeah. I tried to do that, but because windows explorer is shit, it takes 15 minutes to SELECT half of the music in my collection, much less operate onit 19.56.13 # i.e. a file several ahead of the one you are actually hearing 19.56.21 # then dont use windows explorer? 19.56.47 # Hrm 19.57.42 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) 19.58.18 # drakonik: have you weird tags in that files, such as embedded AA or long commments (weird as in not suitable for rockbox) 19.58.29 # I'm not sure 19.58.42 # I don't really know the limits on 'weird'. 19.58.50 # But it's possible 19.59.01 # hm 19.59.07 # okay, I've got an idea for a test. 19.59.30 # No. Nevermind, that's dubm 20.00.17 # New commit by 03bluebrother (r21637): When changing TTS settings from the talkfile dialog make sure to not reset the currently selected folder if its valid. Fixes FS#10409. 20.03.30 # drakonik: does it crash in the simulator? 20.03.39 # Nope 20.03.44 # Loads up 100% perfectly 20.04.07 # drakonik: With all your files, or just the beatles one you suspect to be the cause? 20.04.13 # All of them 20.04.16 # My entire music collection 20.04.22 Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.04.30 # Bummer 20.04.32 # Which is why I said 'shit' 20.04.34 # =\ 20.05.38 # Alright. That option didn't work. Time to move on to the next level of difficulty: implement a db scan log. 20.08.42 # Should be simple 20.09.03 # Yeah, but i'm going to have to go to a lot of work to set up a compile environment 20.10.12 # I'm detailing a bug on my e200v2 in the forum thread and mentioning the data abort addresses I'm getting, where should I put my rockbox.elf? (I'm not up to disassembling it 20.10.23 # fucking reinstall cygwin with all the necessary components and I don't even knwo what I have to do. That's later. Right now, I've got to re-learn C, find a copy of the source that I can use, find the function to edit, edit it. THEN I can worry about setting up the damn compiler 20.10.40 # drakonik: please don't use profanity in here 20.10.46 # right 20.10.57 Join flux [0] (i=flux@jolt.modeemi.cs.tut.fi) 20.17.10 Part PaulPosition 20.17.57 Quit kugel (Nick collision from services.) 20.18.03 Join kugel [0] (n=kugel@e178090232.adsl.alicedsl.de) 20.19.04 # gevaerts: what "bit in RFA"? Also, I can only remember JdGordon having some doubts, and he wasn't able to explain why 20.21.24 Join desowin [0] (n=desowin@atheme/member/desowin) 20.22.25 # drakonik: which target do you have? 20.22.41 # ipod video. Which is what you're asking, I think 20.23.07 # Yes 20.25.53 # Why do you ask? 20.26.03 # Doing a build 20.26.14 # With some very dumb logging 20.26.28 # Dumb logging is what I need. I am very dumb and it's gotta be on my level 20.27.46 # drakonik: try this: http://rasher.dk/rockbox/rockbox-dumb-db-log.zip (patch here: http://rasher.dk/rockbox/dumb_db_log.diff) 20.27.57 # should create a database.log file in the root 20.28.11 # Where it writes the name of each file as it's about to open it 20.28.21 # That's perfect 20.28.35 # Well, hopefully 20.29.04 # It's going to be a great deal slower 20.29.20 # I have nothing but time. 20.32.01 Quit Hillshum (Read error: 110 (Connection timed out)) 20.35.47 # let's add database.hardignore 20.35.54 Quit tvelocity (Read error: 104 (Connection reset by peer)) 20.37.46 # Uhm 20.37.51 # How about no 20.38.07 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-58c3f40f077cecef) 20.38.40 # rasher: you should consider making that patch sim only, and then commiting it 20.38.47 # logging on the sim would be a very useful feature 20.38.59 # it didn't crash on the sim 20.39.10 # Yeah,but logging on the sim is still useful. 20.39.20 # saratoga: you can always enable logf on the sim. The database does a lot of logf 20.40.13 # rasher: why that 20.40.29 # kugel: Because it's a hack on top of a hack 20.40.33 # rasher: yeah but something a little easier for non-developers to use would be nice 20.40.35 # and we've got our log. 20.40.41 # Time to see the culprit. 20.40.52 # ideally we'd be able to point people at the EXE and tell them to give us the resulting log 20.41.08 # saratoga: Problem is it didn't crash in the sim at all 20.41.14 # rasher: then let's remove the first hack. Although markun apparently wants that 20.41.29 # rasher: I saw, which makes me assume its a hardware problem on whatever target 20.42.20 # saratoga: so it wouldn't really have helped us 20.42.36 # hahahaha wow 20.42.41 # That's a very short log 20.42.52 # drakonik: Oh? 20.42.58 # yeah, 11 lines long 20.43.02 # Whatever you do, remember not to delete the file.. 20.43.06 # Right. 20.43.15 # So, you have a suspect file now? 20.43.15 # It's not a music file at the end of the log, though 20.43.25 # I think it was put there by one of the chkdsks I ran 20.43.44 # It must look like a music file then 20.44.08 # Let's look at the file 20.44.15 # I really think we should offer some speed for more helpful diagnostics 20.44.16 # Which is not unlikely, if it's a chkdisk file 20.44.39 # at least until those diagnostics helped us to kill common failure issues so that we can go for speed again 20.44.43 # It's called 'clock' 20.44.53 # So I'm pretty sure it's part of the old ipod firmware files 20.44.54 # rasher: most of the time its due to an actual problem in the tags though 20.44.59 # chkdisk doesn't add this 20.45.06 # in which case the sim and target should be equivilent 20.45.08 # drakonik: can you share that file somewhere? 20.45.14 # it adds a folder FOUND.00X with dozens of files 20.45.31 # saratoga: I've no problem with adding that patch in #ifdef SIMULATOR 20.45.48 # rasher: yup 20.45.56 # uploading it now 20.45.57 # or we go for that plugin 20.46.11 # that does the stock db scan but more verbosely 20.48.53 # http://www.fileden.com/getfile.php?file_path=http://www.fileden.com/files/2007/4/18/995590/radio 20.49.11 # And I misread the log, radio was the last one opened 20.52.17 Join petur [0] (n=peter@d54C6F267.access.telenet.be) 20.52.20 *** Saving seen data "./dancer.seen" 20.52.24 # please check the last music file 20.52.24 Quit DarkSpectrum (Read error: 60 (Operation timed out)) 20.52.37 # rasher: or please put that logging after the probe_file_format() :) 20.52.55 # Slasheri: There were no music files 20.52.57 # Slasheri: Hm, don't we want to catch as much info as possible? 20.53.02 # files without extensions don't even make it into the metadata code if I understand correctly 20.53.18 # so they should be harmless 20.53.19 # drakonik: oh, so you didn't have music files at all? 20.53.28 # I do. 20.53.32 # But the scanner didn't get to them. 20.53.35 # saratoga: There's no guarantee that it's a bug in the metadata code drakonik is hitting 20.53.46 # It crashed when it tried to scan FOUND.001\radio 20.53.48 # hmm.. really interesting 20.53.57 # this is on the sim? 20.54.02 # nope 20.54.04 # hardware 20.54.07 # bad hardware 20.54.12 # drakonik: humour me. Try doing the same again 20.54.16 # Delete the log first 20.54.17 # rasher: Way ahead of you 20.54.26 # I wouldn't be surprised if it was a different file this time 20.54.34 # likewise 20.54.35 # hmm.. maybe reading that file crashed the FS layer of rockbox 20.54.42 # drakonik: thats a file created by chkdisk 20.55.27 # because database shouldn't process files without known extension 20.55.30 # And yeah, I'm leaning towards bad hardware 20.55.41 # hm 20.55.46 # nope 20.55.47 # same file 20.55.59 # well 20.56.16 # if chkdisk already creates files, the fs or hardware seems to be broken 20.56.30 # kugel: could be simple fs corruption 20.56.42 # that's what I said 20.57.05 # But it shouldn't be crashing... Plus you've been saying how explorer is very slow to list files on the disk. I think your disk is bad 20.57.45 # Slasheri: can we change the counter to only count recognized files? 20.58.13 # that would be awesome. that would make much better progress informationo 20.59.36 # kugel: yes, i have thought about doing that many times already 20.59.55 # rasher: It's everywhere 21.00.01 # on my hard drive, on my thumb drive, everywhere 21.00.07 # rasher: so you're going to add an option for that in the sim? or at least post a sim build that has it enabled? 21.00.14 # Slasheri: And why didn't you just do it? 21.00.14 # initially the reason for this obscure counter was that with dircache it would know the number of files and show the actual progress in percents 21.00.38 # kugel: i just haven't been so active lately :) too much work to do 21.01.00 # Slasheri: did you work on the disk cache stuff? 21.02.03 # Okay. 21.02.25 # I'm going to make a copy of the file to my hard drive, remove it from the ipod, and try the scan again. 21.02.43 # Is this a bad idea? 21.03.09 # saratoga: the dircache? i wrote that 21.03.54 # i've wanted to add a way to merge the microsd file directory and interneal file directories into one tree for a while, could you speculate on how hard that would be to do? 21.05.19 # If it is, it's too late to stop. Scan's going, log is building up. 21.05.20 # saratoga: I don't see why it even needs to be an option in the sim. Just always do it 21.05.34 # yea, it's logf 21.05.51 # saratoga: I remember amiconn having a good reason for not doing that... wasn't it a problem with what would happen if you have the same file (in the same dir structure) on both volumes? 21.05.57 # saratoga: a nice feature, definitely, but clashes are sort of very likely 21.06.43 # kugel, pixelma: XBMC already supports it as Llorean pointed out to me, and it works very well in my testing 21.06.52 # duplicate files are simply ignored 21.07.08 # both? 21.07.14 # no just one copy 21.07.24 # and what would be the preferred one, e.g. when you want to copy/paste etc.? 21.07.43 # I'd actually be fine with that 21.07.45 # Internal. 21.07.49 # Just by convention 21.07.56 # Or whichever drive holds the directory you're in 21.08.01 # or just don't allow copy and paste while this is enabled 21.08.04 # either is fine really 21.08.07 # it needs to be internal I guess. what if you have .rockbox on the µSD 21.08.11 # how to get access to the other one then? 21.08.14 # saratoga: You mean files with the same name, or duplicated files? And how do you specify where to save a new file to? 21.08.15 # weird 21.08.19 # pixelma: disable this feature 21.08.23 # this time, it crashed on reading database.log 21.08.45 # drakonik: it really seems to be a bad FS or even HW actually 21.08.48 # linuxstb: It gets saved to the drive holding the directory you save in 21.09.02 # rasher: Where is the root? 21.09.04 # hrm 21.09.06 # HW? 21.09.06 # what if the dir exists in both? 21.09.06 # in xbmc I think it just disables writing to directories that have been merged, at least I couldn't figure out a way to 21.09.07 # linuxstb: Internal. 21.09.16 # linuxstb: As per the made-up convention 21.09.18 # rasher: Then how do you access the root of the external? 21.09.23 # drakonik: hardware 21.09.25 # ah 21.09.35 # linuxstb: just unmerge them 21.09.35 # linuxstb: You don't. You can access the files there though 21.09.36 # too much complication for a fwature I'd probably turn off anyways. If you want one list you could already do that now - with the database 21.09.42 # feature too 21.09.48 # I dunno, I think it it was bad hardware, it'd have shown symptoms before I installed rockbox 21.10.00 # its actually much simplier to use then you'd think 21.10.16 # * rasher doesn't think it'd be terribly complicated either 21.10.25 # saratoga: So this would be an option, rather than a change in behaviour? 21.10.30 # yeah 21.10.31 # Until I did that, it wasn't crashing ever. 21.10.41 # saratoga: to use, yea. but how complex is the code? 21.10.57 # With hybrid wavpack, you could have the correction-files on an sd card. A special losslessify-card! 21.10.59 # originally i just wanted to hack up my own build, but Llorean said he thought it could be commitable 21.11.09 # also, I think that would also be only usable with dircache at all 21.11.29 # kugel: I'm not sure, i haven't looked into it, just the rockbox file tree code a little 21.11.44 # I'm not convinced it'd be worth the delta, but the feature itself seems fairly straightforward to me 21.12.04 # that wouldn't be happening in the apps/ level I think, but in the firmware/ 21.12.21 # well it only impacts targets with flash memory slots, so the delta is only on the sansas and maybe the onda [?] 21.12.22 # I don't use any targets with *sd cards, but can see how it would be convenient for people who do. 21.12.32 # I don't enable dircache, even on my c200 - no use for it on a flash target (and not a real "user" of the db) 21.12.35 # windows 7 implements it too, seems to be a new trend 21.12.51 # linuxstb: Or people with multi-partition archoses 21.12.54 # pixelma: dircache has nothing to do with the db 21.13.01 # rasher: Both of them? 21.13.03 # Though that's probably a rather small userbase 21.13.09 # pixelma: dircache is still useful with on flash targets, skimming through flash memory is quite slow compared to ram 21.13.26 # indeed 21.13.30 # kugel: it has - for speed reasons when updating 21.13.44 # yes, but not for browsing 21.14.01 # not to mention you don't get the sansa electrical noise when browsing the file tree so often 21.14.07 # dircache is a feature on it's own. the database might make use if it, of course 21.14.41 # since I don't update but only initialise, it's no use... and I did not feel access to dirs is slow 21.14.52 # and it does speed up file browsing. I notice it on my e200. And I miss it on my fuze 21.15.19 # hmm Slasheri escaped 21.15.44 # not to mention it saves waking up the SD controller, yielding in actual battery life 21.16.06 # umm... but then it takes RAM away... 21.16.37 # so that's a loss again if you don't browse too often and just listen to music ;) 21.16.44 # 500k of 30M is neglible 21.17.11 # and you won't even reach 500k on a c200 21.17.17 # gah, why does the gigabeat system diagram not number the GPIO lines? 21.17.23 # they;'re all labelled "GPIO" 21.17.27 # but it doesn't say which one is which :0 21.17.34 # :) 21.18.07 # for the fuze, it *might* be a loss, but almost certainly not for the c200v1 21.18.11 # the rom is looking at bits 10 and 11 in GPIO3, which is not labelled in any of the diagrams and isn't used in rockbox afaict 21.18.26 # saratoga: So you think I should commit it (for the sim)? 21.19.20 # rasher: yes absolutely, though I wonder if theres any consequence to having that log generated everytime? 21.19.24 # "for the sim"? 21.19.30 # though i suppose not since most people won't have the database on in the sim anyway 21.19.34 # 311k with an 8GB microSD and my current files/folder structure 21.19.45 # what's the problem with using logf and have it always enabled 21.19.55 # theres really no cost to having a smaller compressed audio buffer on the sansas 21.20.13 # kugel: you mean always enable logf in the sim? 21.20.16 # the flash memory spends the same amount of time energized with a 1MB buffer as it does with a 30MB buffer 21.20.29 # rasher: no 21.20.31 # with logf you get a lot more then just the database thought right? 21.20.44 # you enable it per-file 21.21.02 # I think it should be a plugin, always available, actually 21.21.06 # kugel: Right, so always enable logf, and enable it for tagcache.c for the sim? 21.21.10 Join matsl [0] (n=matsl@host-90-233-180-166.mobileonline.telia.com) 21.21.26 # kugel: sure, but that takes someone to write it, which hasn't happened for 3 years now 21.22.02 # Slasheri: ping 21.22.22 # rasher: meh, I don't know 21.23.35 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 21.24.43 # Unhelpful: have you seen my plugin-goto-wps patch? 21.25.04 # kugel: i've not really looked at it... 21.25.10 # rasher: anyway, if you commit it, do some error checking :) 21.25.20 # oh er 21.25.57 # the log should probably also stored in .rockbox/ 21.26.41 # Yeah, I already did that 21.26.52 # Unhelpful: please do so :> 21.28.08 # i probably can't do so in depth until tonight. we're going to a picnic shortly. i'll try to remember to look then. 21.28.13 # Unhelpful: http://pastie.org/531932 21.28.50 # New commit by 03rasher (r21638): Crude logging for the sim in database creation/updating - to aid in debugging 21.29.03 # * Unhelpful still wonders what exactly happens when the plugin loader is called from somewhere unusual... shouldn't a plugin started from the WPS put you back in the WPS on exit? 21.29.25 # Unhelpful: there's credits.rock 21.30.42 # rasher: i can't start that from WPS any way that i know of, though... 21.31.22 # ...but i can open rockpaint. :) 21.31.29 # But you can start it from a "weird" location 21.32.00 # Or is that not weird enough? 21.32.26 # kugel: i'm not sure we need an "exit to wps" hook. if you use the context menu in WPS, you can open the current file with a viewer. doesn't matter if it works... open a currently-playing file with rockpaint, it'll try to open it, fail, and give you a blank canvas. 21.33.11 # when you quit rockpaint, you're back in WPS. i think that being able to launch a plugin from WPS will suffice to take the user back to WPS on exit. 21.34.05 # the same works with rocklife 21.38.46 # Unhelpful: You're getting it wrong I think 21.38.59 # it's not about launching a plugin from the wps 21.40.02 # kugel: it at least partly is. the ability to "go to WPS" is a non-issue if we assume that the plugin is started from there... 21.40.11 # it's about launching from everywhere, end exit to the wps (there's also really no hook involved, it's all managed by the root menu with existing code). May it be a plugin used in the core for consistency, or a music-orientated plugin 21.41.29 # Unhelpful: this assuming doesn't work 21.41.50 # Why do you want a plugin to exit to the wps? 21.42.14 # i'm assuming the main case would be if it's going to start playback? 21.42.36 # yes, in the case of pf and rfa which I adapted for now 21.42.46 # jj 21.42.51 # oops 21.42.54 # but I'd also like properties and credits to be adapted, for consitency 21.43.42 # Unhelpful: I gave you the wrong diff, btw 21.43.49 # kugel: Why would those want to exit to the wps? 21.44.14 # Why not? 21.44.15 # You can open properties from the wps, but then exiting it will bring you back anyway, with the current system.. 21.44.23 # And credits.. is opened from the menu 21.44.26 # * rasher fails to understand 21.44.29 # Those are used in the core, where you basically can go from everywhere to the wps 21.44.50 # Ahh, with the go-to-wps button. Right 21.45.06 # You can go to the wps from the context menu, but not 1 menu item farther (properties) 21.45.09 # See, that was a better answer than "Why not" 21.45.32 # it's really meant to be optional 21.46.32 # Unhelpful: that's the correct: http://pastie.org/533773 21.46.40 # the code added to the core is minimal 21.46.53 Join AndyIL [0] (n=pasha_in@212.14.208.235) 21.47.56 # Unhelpful: btw, I get audio skips when scrolling in pf on my fuze 21.48.20 # also, I see the empty slide when scrolling quickly. I never get either of those on my e200 21.51.30 # kugel: http://www.rockbox.org/irc/log-20090704#02:40:05 21.51.46 # mostly nitpicking I guess 21.52.44 # we can do that 21.53.14 # I don't actually know why main_menu is called in a loop, instead of having the loop in main_menu 21.53.38 # rasher: this "play shuffled" option in RFA starts playback and exits the plugin. In cases like that, I think going to the WPS is a good idea 21.53.44 # it seems people don't really like exit() :) 21.55.04 # kugel: I don't mind exit(), but I don't like this single function using exit() half the time and return the other half. That will just make things hard to read 21.55.23 # hm, using exit seems not a good idea, if we want to stick to standard behavior of exit() (if there's a defined standard) 21.55.57 # with my change, exit(!=0) may not result in an error 21.56.14 # especially not exit(1) 21.56.32 # gevaerts: I agree with you 21.56.48 # I just wanted a quick way to get it to work without rewriting the whole plugin 21.57.26 Quit AndyI (Read error: 110 (Connection timed out)) 22.00.07 # kugel: http://pastie.org/534308 :) 22.00.22 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 22.02.32 # gevaerts: alright. our exit has nothing todo with the standard anyway :p 22.03.11 # also, they don't define what EXIT_FAILURE is, so we can get away with defining to a value that fits us 22.04.37 # do we mind that guy posting links to patched Sandisk firmwares on the forums? 22.04.46 # if the value was defined, the name wouldn't be needed :) 22.04.50 # i don't personally but if he doesn't have permission to distribute them that seems like a bad thing to do 22.05.50 # Mikachu: well, EXIT_SUCCESS is basically defined though 22.06.12 # not exactly, but why would you define EXIT_SUCCESS not as zero 22.07.38 Join bluebrother [0] (n=Dom@g224237222.adsl.alicedsl.de) 22.08.24 # saratoga: That's not good. 22.13.51 Join p3tur [50] (n=petur@rockbox/developer/petur) 22.21.03 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 22.21.45 # gevaerts: OK, I have a exit()-less version now 22.28.17 # database logging seems to work nicely in the sim for me 22.29.57 # what the hell 22.30.13 # gcc tells me about unused variable, but its clearly used 22.30.21 # oh, I see 22.30.21 # make clean 22.32.27 Join Ubuntuxer [0] (n=johannes@dslb-088-077-000-235.pools.arcor-ip.net) 22.34.27 # saratoga: You should be able to point people at http://rasher.dk/rockbox/simulator within 24 hours to get a build with that 22.34.36 # ok cool 22.35.00 # Or I could rebuild manually.. 22.35.05 # Might as well. 22.37.53 Quit {phoenix} (Remote closed the connection) 22.38.10 # kugel: actually, EXIT_FAILURE and EXIT_SUCCESS are defined elsewhere. "expand to integer constant expressions that can be used as the argument to theexit function to return unsuccessful or successful termination status, respectively, to the host environment" 22.38.20 # Not that it matters :) 22.39.57 # somehow it doesn't surprise me that you tell me that now :> 22.42.28 # gevaerts: http://pastie.org/534327 new patch, even smaller 22.44.21 Join __lifeless [0] (n=lifeless@188.16.68.82) 22.45.02 # kugel: looks good as far as I'm concerned 22.45.29 # most of it is changing the indentation due to rewriting main_menu() a bit 22.48.07 # -w for diff ignores whitespace changes, if you want to look at only the functional changes 22.48.12 # (which you probably already know) 22.49.19 # I heard of it yes, but I wouldn't say that I *know* it :p 22.50.51 # seems the linux4nano guys think they have the decryption keys now 22.51.27 Quit r0b- (Read error: 110 (Connection timed out)) 22.51.43 Join r0b- [0] (n=rob@76.235.166.231) 22.51.49 # does the mean the encryption key for all ipods 6th gen or just nanos? 22.51.50 # I'm not in the channel, but the guys have already claimed much 22.52.22 *** Saving seen data "./dancer.seen" 22.52.31 Join {phoenix} [0] (n=dirk@p54B46121.dip.t-dialin.net) 22.52.58 # kugel: you don't believe them ? 22.53.06 Quit matsl (Read error: 110 (Connection timed out)) 22.53.52 # I have my doubts, but I'm not really following the whole thing anyway 22.54.18 # given planetbeing's involvement, I trust they have genuine progress 22.57.03 # * scorche points GSoC mentors towards -gsoc 22.57.12 Quit saratoga ("CGI:IRC") 22.57.24 # kugel: they arent all like Taylor... 22.57.27 Join webguest37 [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-6dacabb50d4d5631) 22.57.29 Quit webguest37 (Read error: 104 (Connection reset by peer)) 22.57.35 Join saratoga [0] (n=9803c6dd@rockbox/developer/saratoga) 22.57.52 # there's more than taylor? :> 22.58.15 # kugel: read their logs from last night for a taster 22.58.21 # they pulled the bootrom to bits 22.58.37 # can they decrypt the NOR then? 22.59.06 # saratoga: that's what they seem to think 22.59.13 # they won't REALLY know until they can dump it 22.59.20 # which is what they're nattering about at the moment 22.59.29 Quit _lifeless (Read error: 110 (Connection timed out)) 22.59.36 # they already dumped the NOR though last year 22.59.42 # GodEater: where are the logs? 22.59.51 # kugel: one sec 22.59.55 # I saw their site recently, where you can get no information about the project 23.00.24 # kugel: http://logs.clustur.com/%23linux4nano-dev/ 23.00.47 # GodEater: Those logs are password protected 23.00.52 # They are a bit paranoid 23.01.03 # AlexP: you want the username / pass too ? 23.02.46 # sounds like "open" development :) 23.03.02 Join n00b81 [0] (n=taylor@unaffiliated/n00b81) 23.03.37 # bluebrother: Yeah, you basically have to wait for a black box to appear, after which you can pick it apart and create something useful for Rockbox, I guess 23.04.05 # http://l4n.clustur.com/index.php/Bootrom isn't very useful either.. 23.04.24 # they're being very lazy about documenting it 23.04.26 # :( 23.04.44 Quit yosafbridge ("Coyote finally caught me") 23.04.54 Join yosafbridge [0] (n=yosafbri@ludios.net) 23.05.12 # * scorche pushes Bagder into -gsoc 23.05.35 # * kugel join #rockbox-gsoc 23.05.39 # lol 23.05.52 Join slyyx [0] (n=slyyx@142.46.8.26) 23.06.11 # GodEater: no wonder that they made progress. Many rockers around there too 23.06.28 # !seen onlysoaa 23.06.44 # herm.... 23.06.48 # Is there a !seen? 23.06.54 # kugel: indeed :) 23.07.07 # who the hell is onlysoaa ? 23.07.19 # * p3tur walks inside.. getting too dark :/ 23.07.42 # GodEater: This guy: http://forums.rockbox.org/index.php?action=profile;u=2222 23.08.32 # I don't think he's ever been in here. 23.08.48 # Months ago he was very active. Working on a p2 port. 23.09.00 # Two months ago or so. 23.10.03 # in here though ? 23.10.15 # Yes, patch number #10280 23.10.19 # must be in a different time zone to me 23.10.50 # As I recall, usuaually from...3-5hrs from now he would get on. 23.11.00 # slyyx: ask logbot... "logbot seen nick" 23.11.02 # GodEater: I admit, impressive 23.11.11 # logbot: seen onlysoaa 23.11.21 # slyyx: /msg will work 23.11.24 # /msg logbot :) 23.11.25 # k 23.11.48 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 23.12.00 # Alright, 26 days ago....*shrugs* 23.12.06 Part slyyx ("Reality is that which, when you stop believing in it, doesn't go away") 23.12.35 # I don't remember /msg being necessary (but working) 23.13.06 # !seen onlysoaa 23.13.08 # only recognized users at some level can do it in public 23.13.13 # and not with ! 23.13.16 # also doesn't work 23.13.23 # it never did 23.13.32 # ah, that explains it 23.13.50 # I never tried seen before actually 23.15.16 # JdGordon: ping 23.16.06 Quit robin0800 (Success) 23.16.30 # GodEater: I'll be laughing if we get rockbox on the newer nanos before they get linux :p 23.16.52 # kugel: well they're rooting for us too 23.16.56 # i'd assume thats more likely given how many more people we have then ipod linux 23.17.10 # It's not terribly unlikely. They have some hurdles in the whole linux department that we don't 23.17.19 # You probably will. Most of the people at ipodlinux are busy :) 23.17.21 # we have to tip our hats to the work they've done there though 23.17.36 # I'm so pleased planetbeing spared us his time 23.17.41 # busy is another word for dead these days? B) 23.17.50 # Bagder: yeah, kinda :) 23.18.07 # Hey, extracting a bootloader through a notes vuln is not the easiest thing on this planet :) 23.18.36 # at any rate maybe this will ram the meizu port through too 23.18.45 # though i guess the FTL issue is still looming 23.18.49 # I don't think you need to tell this channel about how reverse engineering can be hard;-) 23.18.55 # Bagder: which script creates the current build table? 23.19.04 # GodEater: we should team up for sure, I was kidding 23.19.06 # do any of our meizu guys have any idea how to get the UART working 23.19.21 # That would be a big help :-) 23.19.24 # Zagor: showbuilds.pl 23.19.31 # i doubt it since its not something we'd actually need, but i assume its in teh datasheet? 23.19.54 # yeah, I suspect our chaps have spent longer looking at the datasheet than they have 23.20.15 # lol @ Badger, my head is still hurting from even looking at the SansaAMS and i believe that was not the biggest challenge 23.20.57 # the sansaAMSes was what I would call medium hard 23.21.15 # the PP ones were harder 23.21.21 # the PP were definitely harder 23.21.30 # and these new ipods are on the top of the scale 23.21.31 # no datasheets at all. 23.21.49 # I figure perhaps zunes are up there too 23.22.09 # darn, where's those zunelinux guys when we need them! ;-P 23.22.55 # chapter 25: UART 23.23.00 # sounds promising :) 23.26.05 Quit p3tur ("back inside....") 23.28.54 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 23.33.12 # bluebrother: for the texts in the manual that mention actions, I'd like to have a macro that - depending on HAVE_REMOTE_KEYMAP defined expands to either "\ActionSomething" or "\ActionSomething (\ActionRCSomething) where Something is passed through the new macro and then the actual button for this action is looked up in the keymap files - is this possible? 23.34.17 # linuxstb: I totally forgot about declaring the local functions static, will do. About the executable property, it was added by mistake, but will be removed in the next patch. I never use TABs, so it might just be a misalignment, I'd appreciate it if you could point me to the specific part you're talking about :) 23.36.40 # pixelma: can't tell that off the top of my head -- never needed something like that. Will check it 23.37.48 # mt: Searching your patch, I found some tabs, but I forget exactly where. Some of them are in SVN already though I think... 23.37.53 # pixelma: HAVEREMOTEKEYMAP :) 23.38.10 # mt: Do you have any big-endian targets to test it on? 23.38.30 # bluebrother: well I thought the wikilinks etc. are a bit similar as you can feed them with the wiki page name and it will make a proper link out of it, but couldn't figure out how that works or where the limits are 23.39.13 # AlexP: sorry, was off the top of my head and for the explanation, would have looked it up in real use 23.39.25 # linuxstb: No I don't. About the tabs, are they in files other than makefiles ? 23.39.35 # pixelma: Hehe, it wasn't serious :) 23.40.55 # bluebrother: although the wikilinkks are "one step" whereas my idea would be two steps (combine a string and use it for the lookup in the keymap files) 23.40.56 # pixelma: well, the wikilinks macro constructs an argument for another macro while you want to construct a macro that should get evaluated, so it's different. 23.41.17 # yeah 23.42.48 # I'm wondering how hard it would be to create a new LaTeX macro package that reads a keymaps file directly. Unfortunately it's unlikely I'll find time working on it (and I doubt I'd succeed anyway) 23.43.16 # would be the nicest solution I could think of until now for the problem that you sometimes need both and sometimes one each (in the tables) - and without preparing a lot of combined actions or opting on every occurance in the text 23.43.39 # I mean RC action and non-RC action 23.46.07 Join barrywardell [0] (n=barrywar@86-43-167-232-dynamic.b-ras2.prp.dublin.eircom.net) 23.48.06 Quit notlistening ("Leaving") 23.49.50 # mt: Yes, of course. 23.50.11 # Bagder: did you have a reason for putting handoutbuilds() so high up in COMPLETED? it's a bit inconvenient since that clears $buildround on the last build 23.50.57 Quit {phoenix} (Remote closed the connection) 23.51.00 # * pixelma is reminded of the start of an M3 manual waiting for a commit, even though it doesn't compile cleanly yet 23.51.19 # pixelma: It doesn't compile anyway, does it? 23.51.22 # Zagor: I think because handing out builds is a priority 23.52.10 # rasher: hmm? 23.52.39 # I don't understand the question 23.52.48 # pixelma: Just saying that it's still a step in the right direction 23.52.54 # Bagder: ok. I'll simply copy $buildround to a local var and leave handoutbuilds() where it is. 23.53.55 # ah yes... that's why I wanted to commit it but forgot due to being occupied with other things 23.54.46 # linuxstb: I'll chase them tomorrow then :) .. I want to finish cleaning this patch and committing it tomorrow. 23.56.09 # For BE targets, First thing that comes to mind would be modifying the get_uint* functions according to the endianess of the target (like in metadata.c/h) .. 23.56.10 # hmm, no I'll move it below the file moves. we need to clean out upload/ in endround. 23.56.31 # Zagor: good point 23.57.36 # also I'm changing the filenames in data/ to $revision-$id.* to more easily tie them to the build table 23.59.00 # Considering that there's now an "abort build" command, maybe the build round should start immediately on commit, and then restart if a commit is detected within the grace period?