--- Log for 02.09.109 Server: orwell.freenode.net Channel: #rockbox --- Nick: @logbot_ Version: Dancer V4.16 Started: 6 days and 1 hour ago 00.00.23 Quit BlakeJohnson86 (Read error: 104 (Connection reset by peer)) 00.01.11 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 00.06.40 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 00.10.35 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.10.43 Quit kick_me ("grumble") 00.15.17 Join BdN3504 [0] (n=55b22760@gateway/web/cgi-irc/labb.contactor.se/x-pjjojqahamxqnonv) 00.15.54 # which targets do NOT support the repeat a-b mode? are there any? 00.16.18 # BdN3504: most touchscreen targets I guess, as there's no button mapping for them (unless there is in grid mode) 00.16.37 # those mappings should be added... 00.17.19 # mcuelenaere: but there are no manuals for those atm right? 00.17.49 # I don't know, there isn't one for the Onda's.. 00.17.53 *** Saving seen data "./dancer.seen" 00.18.15 # JdGordon|: that depends on the WPS I guess (if not in grid mode) 00.18.47 # mcuelenaere: sure, but adding the option is needed, then its up to themers 00.18.52 Join TopyMobile [0] (n=topy@xdsl-78-34-70-136.netcologne.de) 00.18.56 Join dys` [0] (n=andreas@krlh-5f705651.pool.mediaWays.net) 00.19.42 # true 00.19.47 # JdGordon|: You didn't answer me why users should care how much RAM a theme uses 00.20.00 Quit Topy (Read error: 110 (Connection timed out)) 00.20.13 # sorry, must have missed the message? 00.20.32 # umm... I would really like to have the buffer size user-customisable at some point in the future 00.20.36 # so can i "un"opt that part in the appendix of the manual then? atm it's \opt{player,recorder,recorderv2fm} but that's definitely outdated now, right`? 00.20.40 # so knowing how much is needed is imoprtant 00.20.59 # Why would it be user-customisable? 00.21.30 # That seems like asking for trouble 00.21.34 # so people who only want text dont need to waste huge amounts so themes like yours can work on other people daps... 00.21.50 # I think you've stayed with MS too long 00.22.18 # We're talking at most a few dozen KB. What problem are you trying to solve? 00.22.52 # on some targets its tiny, 2 or 3KB, on some it could be over 100KB wasted 00.23.25 # yes its not alot, but doing that makes everyone happy 00.23.47 # Except the users who have to piss about with setting a useful buffer size 00.24.11 # the default would be the same or larger than now anyway so I dont know what you're complaing about 00.24.23 # its not like the default would be enough for a 1 line wps 00.24.24 # Then why add it in the first place? 00.24.47 # So the people who like to moan about 10KB wasted can get YET ANOTHER SETTING THAT IS ESSENTIALLY USELESS 00.25.02 # We don't need more memory managing settings. We need less. 00.25.13 # you want to calm down a bit? 00.25.35 # I'm perfectly calm 00.26.31 # rasher: useless to some may be useful to others, more settings doesn't cause too much trouble as long as they aren't necessary 00.26.52 # That's the thinking that leads to millions of settings that shouldn't exist in the first place 00.26.55 # how it works right now is the buffer size is the same (relative to the screen size/depth) for every target.... someone comes along and wants to add a very image intensive skin for say the e200, fine now he has to argue to add a a dump, say double the size... its not very much for him but a huge waste for EVERYONE ELSE 00.27.12 # Define "huge waste" 00.27.27 # totally unused memory 00.27.34 # rasher: some people like to tweak settings, I don't see how that causes any problems for those who don't. (clearly you) 00.27.56 # JdGordon|: unused memory is only a problem if it's needed for something else 00.28.12 # andrewrb: Rockbox shouldn't have settings for which reasonable defaults exist. 00.28.38 # Clearly, we can live without a wps/theme buffer size setting, as has been demonstrated by the past 5 years 00.28.40 # sure, doubling the buffer on the 64mb video build isnt a big issue... but what about the clip? we have enough issues with playback already... or rec and its talk buffer? 00.28.42 # or however much, I forget 00.29.04 # JdGordon|: I find it very unlikely the Clip will have 200KB themes. 00.29.56 # You're solving a problem that doesn't exist. Point me to one person in the past that has voiced a reasonable complaint about unused RAM due to the wps buffer being larger than it needs to. 00.30.00 # Just one. 00.30.13 # And in the process of doing this, you're adding complexity 00.30.24 Quit dys (No route to host) 00.31.37 # why is \opt{player,recorder,recorderv2fm} {, A-B} in the repeat mode section of the manual? 00.31.44 # i know that I never use any themes with images, yet I can't view images while also playing music on my D2 due to lack of memory. If there was a setting which might allow me to shrink the wps buffer I would be grateful 00.32.00 # rasher: 1) we had no setting doesnt mean we didnt need one... I remember a few times people complaing about not enopugh image buffer 00.32.19 # 2) you're missing th epoint on the clip... its playback buffer is 1MB or something... an extra 10KB is a big deal 00.32.29 # andrewrb: There is no setting. 00.32.44 # andrewrb: Shrinking the WPS buffer would not solve this anyway. 00.32.46 # * rasher groans 00.32.48 # You need to increase the plugin buffer. 00.33.14 # Clearly, what we need is MSDOS style memory management where everyone has to micro-manage memory and make sure there's adequate space for the various bits and pieces 00.33.18 # * andrewrb shouldn't have stuck his head in with a lack of knowledge 00.33.38 # rasher: you say that like its something we dont already do? 00.33.49 # thats EXACTLY what we do 00.34.04 # [00:25] We don't need more memory managing settings. We need less. 00.34.37 # ok, so lets enable cuesheet, last.fm, timestreth, everything and see how it copes 00.35.36 # Or let's at least not add more of this tomfoolery. 00.35.37 # Clearly you should just drop the WPS buffer entirely, and use the existing playback buffering to "buffer" the WPS using only as much memory as it needs. 00.35.40 # :-P 00.35.43 # we have a very small amount of RAM to play with and a HUGE feature set... without toggle/sizing settings there is either feature freeze (in which case i'm out of here), or huge bloat for those which dont use those features 00.36.09 # Very small amount of RAM? Except the clip, everything has more RAM that we could ever use 00.36.41 # you must be new here.... we dont cater to the highest speced DAP.. we cater to the lowest 00.37.08 Part rasher 00.37.12 # I've been saying for years keeping an eye on the RAM usage is stupid... 00.37.56 # There's a compromise between "not keeping an eye on it" and "letting it limit everything" called "trying to make sure the amount we use is reasonable relative to what we gain" 00.38.21 Quit antil33t (Read error: 60 (Operation timed out)) 00.38.32 # and I've been happy with the compromise which started this argument again.... 00.40.59 Join antil33t [0] (n=Mudkips@119.224.12.185) 00.41.03 # Could we have a minimum WPS buffer size that can be increased *if* playback is stopped when the WPS is loaded? 00.41.34 # in theory... sort of... 00.41.50 # So we could normally allocate less memory, in a value good enough for say, 80%+ of themes to work fine without playback stops, but allow people their giant themes if they really wanted it? 00.41.50 Quit BdN3504 ("CGI:IRC (EOF)") 00.42.01 # No settings involved. 00.42.12 # in *theory*... 00.42.29 Join PaulJam [0] (n=Paule@p54BEDBE9.dip.t-dialin.net) 00.42.31 # in practice its way to hard to do 00.42.32 Quit ender` (" If Klingons had invented Usenet, killfiles really would...") 00.43.25 # its a general memory issue with rockbox... restarting playback could be used to do it but you waste lots more ram each time 00.43.29 # which could be acceptable 00.43.57 # * JdGordon| isnt even sure where this "restart playback to enable" idea came from 00.44.12 # i'm pretty sure its never handled doing more allocs after playbacks tarts the first time 00.48.39 # * Llorean shrugs 00.56.57 Quit NuNuRs () 00.58.17 Join descendent87 [0] (n=benji@87.242.153.98) 00.59.29 Quit PaulJam (".") 01.08.48 Join goffa_ [0] (n=goffa@216.220.23.105) 01.13.28 Quit robin0800 (Remote closed the connection) 01.14.22 # is there any progress on rockbox for creative zen vision m? 01.14.40 # descendent87: the project has more or less stalled 01.15.17 # bummer, looked on the site and didnt see any updates on it so thought it might have 01.15.41 # * JdGordon| decides to beat the horse once more.... figuring out the correct skin buffer size is going to be verry difficult when statusbar, fm, and wps all use the same one.. and then there is the remote to consider also 01.16.06 # maybe we just hard code it to 1MB and call it quits? 01.20.52 Quit goffa__ (Read error: 110 (Connection timed out)) 01.22.37 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.24.38 Quit soap (Read error: 110 (Connection timed out)) 01.26.19 # rasher: i've been thinking about various ways to not have to fix buffer sizes at compile time or at startup time. i don't like many of them very much. prefixing buffer_alloc buffers with a pointer to a callback that can safely move them is probably the best scheme in my opinion. 01.28.27 Quit CaptainKwel ("Page closed") 01.32.54 Part descendent87 ("Konversation terminated!") 01.34.09 Join kugel [0] (n=kugel@rockbox/developer/kugel) 01.35.19 Quit Thundercloud (Remote closed the connection) 01.37.07 # what about a buffer alloc which gives you say 50k per call, it would get those by stopping playback, but would garuantee to append/prepend the new 50k to the buffer from existing calls. Within in that buffer, stuff like skin engine/dsp/whatever could freely use a real malloc 01.37.29 Join JdGordon_ [0] (i=483efeb0@gateway/web/freenode/x-ttxqsofebwsikjgu) 01.38.00 # s/existing/previous/ 01.38.08 Join FOAD_ [0] (n=dok@dinah.blub.net) 01.38.40 # the "could freely use a real malloc" is not even needed I guess 01.39.36 # the point is, to have a single buffer which can grow, but is still always a single buffer 01.40.58 Quit Zagor ("Clint excited") 01.42.19 # froggyman: About brickmania, I think adding more options for gameplay style would be nice. Like an ' 01.42.51 # endless' mode that keeps on going, and the like 01.43.08 Join rasher [50] (n=rasher@rockbox/developer/rasher) 01.44.44 Quit bubsy (Read error: 54 (Connection reset by peer)) 01.46.29 # I like the idea of forcing anything that does allocation after a set "time" to handle a callback which means it has to realloc 01.46.57 # but that still wont fix the problem.... there is no way to know the required skin usage untill its finished loading 01.47.18 # ^ kugel, Unhelpful 01.47.40 # hence the idea of letting it grow 01.48.10 # letting it grow doesnt work with how the skin buffer allocation works 01.49.00 # it would have to be VERY smart t handle that 01.49.21 # well, you could approximate the skin usage by investigating the images first (reading headers, calculating size, add it up), the rest of the skin would unlikely take more than 5% additionally 01.49.42 # JdGordon_: because you made it complicated 01.49.49 # meh 01.49.51 # :) 01.50.26 # that can still be changed, paying 4bytes per token for using the ram more effeciently in the end 01.51.21 # you understand its a hell of a lot of work needed to make that change right? 01.51.22 # froggyman: The way brickmania is currently set up it becomes a quest for the most points, with no risk of not finishing 01.51.55 # no, not really, and I think it could be worth it in the end 01.52.15 # no you dont understand its alot of work? or you dont belive me it is? 01.52.30 # i don't understand 01.52.33 Join bubsy [0] (n=Bubsy@94.139.72.137) 01.52.44 Join bubsy_ [0] (n=Bubsy@94.139.72.137) 01.52.45 # then trust me... it is :) 01.53.33 # still 01.53.43 # I think it could be worth it 01.54.13 # it's not just about the skin buffer, all the other stuff too (timestrech, cuesheet, etc) 01.55.18 Quit FOAD (Read error: 110 (Connection timed out)) 01.55.18 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 01.55.45 # but my idea probably won't work as long as each user of that buffer wants a single buffer. making it grow would still mean to potentially split the skin buffer in 2 parts for example 01.55.46 Quit JdGordon_ (Ping timeout: 180 seconds) 01.55.56 Join JdGordon_ [0] (i=483efeb0@gateway/web/freenode/x-xrpevcmbpgbpiuut) 01.56.01 # this webchat sucks 01.56.16 # those are all constant sizes so resizing/gorwing isnt needed 02.01.57 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 02.02.00 Join TheCoolGman [0] (n=446e5e7d@gateway/web/cgi-irc/labb.contactor.se/x-bawgpucrampzvlbe) 02.02.24 Join chandoo [0] (n=chandoo@ool-4353b978.dyn.optonline.net) 02.03.30 # Hi, I'd Like to bring up patch FS#10554 Rockpaint: enable to set canvas size and FS#10555 Rockpaint: improve browsing font. The Font browsing still neds some work but the canvas size works well 02.04.01 Quit JdGordon_ (Ping timeout: 180 seconds) 02.08.56 Quit antil33t (Read error: 113 (No route to host)) 02.17.55 *** Saving seen data "./dancer.seen" 02.18.15 Quit chandoo_ (Read error: 110 (Connection timed out)) 02.20.09 Join Strife89 [0] (n=Strife89@adsl-154-3-186.mcn.bellsouth.net) 02.22.49 Join MG_Man [0] (n=MGMan@11.208.101.97.cfl.res.rr.com) 02.22.51 Quit MG_Man (Client Quit) 02.23.36 # New commit by 03kugel (r22597): Forgot to add keys for the quickscreens' top item for the ipods (they didn't have ACTION_QS_DOWNINV before). As that one was used as exit button, ... 02.24.51 Join MG_Man [0] (n=MGMan@11.208.101.97.cfl.res.rr.com) 02.28.46 Quit Hillshum ("Ex-Chat") 02.28.55 Quit mcuelenaere () 02.32.20 Quit DataGhost (Nick collision from services.) 02.32.28 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 02.34.04 Join Topy44 [0] (n=Topy44@g227172122.adsl.alicedsl.de) 02.37.04 # it stands to reason that if something is breaking a pointer (or not initialising it correctly) that memset()ing it to 0 first shouldnt fix the problem but make it more obvious yes? 02.37.35 Nick dys` is now known as dys (n=andreas@krlh-5f705651.pool.mediaWays.net) 02.38.44 # on the other hand... doing that would set the bad pointer to NULL so hiding the real issue :/ 02.40.00 # kugel: can you test a patch? 02.40.12 # Strife89: you volanteered to test yesterday yeah? 02.40.24 # sure 02.41.36 # http://www.rockbox.org/tracker/task/10576#comment32387 thanks 02.41.44 # JdGordon: Yep. :) 02.41.49 # what did you mean with the pointer stuff? 02.42.03 # JdGordon: perhaps if it did as the album art loader does, and grabbed the remaining buffer space to handle the load, and determined the final size afterward? then it could buffer_alloc the new skin buffer, copy the loaded data there, and free the buffer handle... 02.42.35 # there is an uninitialised pointer somehwere (I dont know where) and because its not being set to NULL something thinks its legit so follows it when it shuldnt 02.43.26 # the AA loader can only do that readily because it's inside bufopen, though. :/ 02.43.27 # Unhelpful: nope... pointers everywhere... 02.43.35 # JdGordon: Give me a minute, I need to get on my laptop. 02.43.42 # thanks 02.43.52 # try loading different themes and make sure they all display correctlty 02.43.56 # I tihnk its all good now 02.44.54 # it doesn't apply to my statusbar branch. no luck for you :) 02.45.00 # * Strife89 wonders if FS#8806 is ready for WPS comission. 02.45.05 Join tvelocity [0] (n=tony@adsl19-148.her.forthnet.gr) 02.45.06 # JdGordon: well, if there's a "move buffer" callback that you'd have anyway in case something force the already allocated skin buffer to be moved, surely the same callback could be used to move the data from a buffer handle to the new buffer_alloc'd location? 02.47.18 Quit Strife89 ("Switching machines.") 02.48.35 Join Strife89 [0] (n=michael@adsl-154-3-186.mcn.bellsouth.net) 02.49.03 # it could be done, but everything would need to be changed to offsets which is something I really dont want to do... 02.49.32 # even a boring text only wps will have a absolute heap of pointers which would need reworking 02.50.43 # is ther a skin with sublines ? 02.50.54 # ? 02.51.13 # don't want to make one 02.51.24 # you mean a shipped one? 02.51.39 # or one from the theme site 02.51.39 # most of them no? 02.52.03 # JdGordon: Hang on and I'll patch and compile. 02.52.15 # most of them? I can't remember one 02.52.39 # JdGordon: Do you know if anything will break if I make a copy of my rockbox folder and rename it? 02.52.45 # dancepuffduo definetly does 02.52.53 # Strife89: no, it will be fine 02.52.54 # alright 02.53.13 # I was hoping for coverage on themes I hadnt tested though :p 02.53.15 # JdGordon: Okay, just wanted to check. 02.58.16 # JdGordon: Okay, making. One Sansa build, and then the iPod Photo build, coming up. 02.59.49 # amiconn: good call on updating the screen backwards, for some reason it didn't occur to me. Originally I was stuck on the 32x32 pixel squares because I was trying to do the transform in hardware, but that didn't work out so well. The fps drops to 164 fps with the ARM updating the registers 2x as often, but that's not too bad. Overall the responsiveness is much better so I think the new lcd format worked out well for it. 03.01.35 # New commit by 03kkurbjun (r22598): Update Vertical stride so that it's oriented left to right in the destination. 03.02.44 # * Strife89 backs up his .rockbox folders. 03.04.03 # JdGordon: that's why I was asking 03.05.05 # JdGordon: About halfway through the iPod build now, I think. 03.05.13 # kkurbjun: that's what I meant with the framebuffer trickery :) 03.05.55 # :-D, It went over my head at the time 03.06.32 # Strife89: announcing every step is really unneeded 03.07.44 # kugel: Sorry. ._. 03.10.25 # JdGordon: seems to work here, it has 4x %t3 in it 03.10.35 # with conditionals and stuff 03.10.48 # although, the 3s don't seem to be very accurate 03.11.03 # how not accurate? 03.11.06 # too fast or slow? 03.11.38 # JdGordon: Anyway, installing now. 03.11.55 # * JdGordon echos kugel's request from about 4 min ago... 03.14.25 # JdGordon: So what does this do, exactly? 03.14.41 # Forgive my incompetence. ._. 03.14.55 # it does nothing... hopefully... 03.15.56 Quit kkurbjunW (Remote closed the connection) 03.16.10 # JdGordon: to slow, it's more like 3.5s 03.16.47 # no, wait, faster. ~2.5s 03.16.55 Join kkurbjunW [0] (n=karlk@12.41.166.8) 03.17.58 # JdGordon: At least one theme raised the volume on me when I loaded them. 03.18.20 # On the c250. 03.18.26 # kugel: split the difference and its all good :) 03.18.29 # Strife89: REALLY?! 03.18.38 # JdGordon: No joke. 03.18.53 # i dont belive you! 03.18.57 # It jumped from -32dB to -13dB. 03.19.13 # does it by any chance contain a volume: X line? 03.19.20 # * Strife89 checks. 03.19.47 # JdGordon: i managed to get it to do that when i was hacking on convttf and it was generating buggy fonts. it would jump from -25dB to +6 or whatever the beast maximum is. 03.19.50 # JdGordon: False alarm. 03.20.14 # Unhelpful: crap, thats really wierd... 03.20.18 Quit MG_Man (Read error: 110 (Connection timed out)) 03.20.18 # Strife89: told you so :) 03.20.38 # Why someone would make a theme jump to a certain volume is beyond me, but hey. 03.20.53 # and i'm pretty sure it was not a false alarm in my case, as the difference in volume was quite, um, obvious. 03.21.08 # i wasn't allowed to use the beast in the family car until i fixed it. 03.21.15 # Strife89: is that one from the themes site? 03.21.28 # JdGordon: It's called Rockblack. 03.21.36 # Unhelpful: you sure it wasnt a fixed.cfg or config issue? 03.22.00 # I mean sure its possible to get the volume to have a wierd value, but I'd expect a crash or two to go along with it 03.22.11 # JdGordon: Anyway, the c250 checks out okay. :) 03.22.49 # JdGordon: i'm pretty sure it started suddenly after some revision in convttf, and disappeared, along with other weird problems, after i fixed that and a glyph size calculation patch. 03.25.37 # JdGordon: scrolling seems bugged on dancing puff duo 03.27.27 # kugel: which target? 03.27.34 # e200 03.27.59 # this is a normal line with %s, it begins to scroll but resets after 0.5-1 seconds 03.28.16 # which line? or whats on the line? 03.28.50 # same problem on blacknblue glass also 03.29.38 # * Strife89 gives JdGordon's patch a thumbs up. 03.30.43 # JdGordon: the line after the "Next Song:" one 03.31.16 # kugel: it resets, but after that it scrolls forever correctly yeah? 03.31.26 # no it keeps doing that 03.32.10 # it looks like the usual "next track info ready" reset, but it doesn't stop 03.33.32 # hmm... 03.33.44 # New commit by 03kkurbjun (r22599): M:Robe 500: Add low-level support for vertical strides 03.35.48 # * JdGordon checks the diff 03.36.00 Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 03.38.50 Quit TopyMobile (Read error: 110 (Connection timed out)) 03.38.57 Join antil33t [0] (n=Mudkips@119.224.12.185) 03.39.32 Join TopyMobile [0] (n=topy@g227172122.adsl.alicedsl.de) 03.39.37 # kugel: ok, I have a fix... you want the full diff again? or just the few changed lines? 03.40.04 # http://pastebin.com/m5cda0875 is just the func to replace 03.40.08 # in skin_display.c 03.41.31 # seems to be good here 03.42.30 # New commit by 03kkurbjun (r22600): M:Robe 500: fix warning 03.44.02 # JdGordon: just post-poned the reset? by 100*HZ? 03.44.13 # thats what svn does 03.44.24 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 03.45.22 # hm, sounds strange, but well 03.45.36 # umm.. I'm not entirely sure how that is going to handle next track when it becomes avilable 03.45.41 # * JdGordon checks 03.46.22 # yeah, should be fine 03.48.39 # I think 100s is a wierd value, but it works 03.48.55 # I wonder if it should be something like 3min or so? 03.49.28 # why's there this value at all? 03.49.56 # because the displayer is stupid 03.50.23 # if the line hasnt been updated it shouldnt be redrawn 03.50.31 # that a bug... but a seperate issue 03.50.38 # a line should just reset scrolling when it's swapped with another subline, or its information changes 03.50.41 # yea, probably 03.51.27 # thats for later though... I have an idea how to do it... 03.51.56 # but really.. the lines tokens need to be checked to make sure none are dynamic, or it wont work 03.52.11 Quit antil33t () 04.05.39 Quit TheSeven (Nick collision from services.) 04.05.56 Join The_Seven [0] (n=theseven@dslb-084-056-170-128.pools.arcor-ip.net) 04.06.02 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-170-128.pools.arcor-ip.net) 04.06.44 Quit froggyman ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 04.13.56 Join dys` [0] (n=andreas@95.112.82.178) 04.17.41 Quit kugel (Remote closed the connection) 04.17.56 *** Saving seen data "./dancer.seen" 04.22.17 Quit chandoo ("Leaving") 04.25.58 Quit dys (Connection timed out) 04.27.07 Quit DataGhost (Nick collision from services.) 04.27.14 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 04.31.51 Quit andrewrb ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 04.32.11 Quit bubsy_ ("I'll be back somewhere in time...") 04.33.45 Join antil33t [0] (n=Mudkips@119.224.12.185) 04.39.35 Quit Strife89 ("Bed.") 04.41.35 # New commit by 03kkurbjun (r22601): Fire: Add support for 256 color hardware pallete mode 04.48.00 Quit Rondom (Nick collision from services.) 04.48.10 Join Rondom [0] (n=Rondom@84.57.137.29) 04.55.36 # New commit by 03jdgordon (r22602): Almost the last of the skin ram wastage fixing... This one moved the line/subline handling into the alloced buffer and links them more sensibly with ... 05.00.39 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 05.02.03 # New commit by 03jdgordon (r22603): fix player's red 05.04.19 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 05.06.56 Quit TheCoolGman ("CGI:IRC") 05.09.13 Join TopyMobile_ [0] (n=topy@g227172122.adsl.alicedsl.de) 05.09.32 Quit JdGordon ("Leaving.") 05.09.59 Quit TopyMobile (Read error: 104 (Connection reset by peer)) 05.10.44 # Unhelpful: do you have a pointer on where to look to add support for vertical strides for pictureflow? 05.11.53 Quit TopyMobile_ (Remote closed the connection) 05.27.18 Join ecognito [0] (n=ecognito@203.39.191.114) 05.28.59 # Anybody know good stores in Melbourne, Australia for buying rockbox friendly MP3 players? Or is ebay my best bet? 05.32.52 # New commit by 03kkurbjun (r22604): Pictureflow: Add support for vertical strides. 05.42.06 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.44.06 # New commit by 03kkurbjun (r22605): Fix collision detection for invadrox 05.44.40 Quit gevaerts (Nick collision from services.) 05.44.51 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 05.46.52 Join n1s [0] (n=n1s@rockbox/developer/n1s) 05.52.22 Quit Horscht ("Verlassend") 06.15.24 Quit intrados_ (Read error: 104 (Connection reset by peer)) 06.16.35 Join intrados_ [0] (n=intrados@cpe-71-67-138-190.woh.res.rr.com) 06.17.58 *** Saving seen data "./dancer.seen" 06.27.18 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 06.27.31 Quit sbhsu (Read error: 60 (Operation timed out)) 06.31.28 Quit BHSPitMonkey (Read error: 104 (Connection reset by peer)) 06.31.28 Join BHSPitMonkey_ [0] (n=stephen@pool-71-252-194-100.dllstx.fios.verizon.net) 06.32.33 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 06.38.17 Quit CaptainKwel (Remote closed the connection) 06.44.03 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 06.50.02 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 06.59.17 Quit sbhsu (Read error: 110 (Connection timed out)) 07.07.24 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 07.07.49 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 07.14.23 Quit kkurbjunW (Remote closed the connection) 07.14.45 Join kkurbjunW [0] (n=karlk@12.41.166.9) 07.17.03 Quit sbhsu_ (Read error: 110 (Connection timed out)) 07.31.42 Join FOAD_ [0] (n=dok@dinah.blub.net) 07.35.40 Nick BHSPitMonkey_ is now known as BHSPitMonkey (n=stephen@pool-71-252-194-100.dllstx.fios.verizon.net) 07.40.07 Quit TheSeven (Nick collision from services.) 07.40.25 Join The_Seven [0] (n=theseven@dslb-084-056-170-128.pools.arcor-ip.net) 07.40.31 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-170-128.pools.arcor-ip.net) 07.44.41 Quit bmbl ("Bye!") 07.48.58 Quit FOAD (Read error: 110 (Connection timed out)) 07.48.58 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 07.58.35 Quit moos ("Rockbox rules the DAP world") 08.08.56 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 08.18.02 *** Saving seen data "./dancer.seen" 08.18.49 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.23.06 # New commit by 03jdgordon (r22606): rename wps_[sub]line to skin_[sub]line 08.32.23 Part safetydan ("Leaving.") 08.34.57 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 08.36.14 Join Rob2223 [0] (n=Miranda@p4FDCDC4D.dip.t-dialin.net) 08.37.42 Join pamaury [0] (n=pamaury@140.77.26.34) 08.38.35 # * GodEater yawns 08.39.10 # good evening :) 08.39.37 # pcc1: hello 08.40.11 # * GodEater stumbles towards the kitchen to get coffee going 08.42.54 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.42.58 Quit ender` (Read error: 104 (Connection reset by peer)) 08.45.36 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.48.06 Join decayedcell [0] (n=decayed_@60-241-92-53.static.tpgi.com.au) 08.51.15 # good morning everybody 08.51.34 # what's so good about it? 08.52.01 # that would be _very_ offtpoic... 08.54.31 Quit Rob2222 (Read error: 110 (Connection timed out)) 08.56.06 # pamaury: hello 08.56.47 # pamaury: I saw that you pushed your MTP stuff to the github repository 08.56.57 Join AndyIL [0] (n=pasha_in@212.14.205.32) 08.57.27 # I was thinking what the next step would be 08.58.14 # If you want to code MTP, I can advise you to get some documents before coding. 08.59.50 # yes, I was reading some parts of the MTP spec and comparing to your work earlier today 09.00.01 # You'll need the following documents: 09.00.11 # - MTP spec (USB-IF), you probably have that 09.00.46 # - USB Still Image Capture Device Definition (USB-IF): that's the USB specific part of PTP (MTP is an extension of PTP) 09.01.15 # - PIMA15740: the PTP spec, not so easy to find, could be useful 09.01.27 # I can advise you to get the libmtp source code. 09.03.55 # There are still some thing in the code that I'm not satisfied with. For example, the handling of unrecognized commands on the Control Endpoint: should it stall endpoints and wait for the reset command ? I'll need to read it once more to be sure. Furthermore, the transfer code for writing (device point of view) will not work for big transfers and reading is not implemented yet 09.07.38 Join funman [0] (n=fun@rockbox/developer/funman) 09.08.30 Quit AndyI (Read error: 110 (Connection timed out)) 09.12.29 Quit BHSPitLappy (Remote closed the connection) 09.12.42 # pamaury: ok I'll look into those 09.13.48 # are you sure you committed all your code? for example I didn't see usb_mtp.c added to firmware/SOURCES 09.14.29 # Really ? I'm sure it was modified on my svn repo. I check that immediately 09.14.41 # If you don't have usb knowledge or don't want to get hands too dirty with that, you'll noticed I tried to abstract the protocol with the *pack_data* functions and send_*/recv_* 09.15.28 # There are also lots of gots to be answered about the ways objects are managed 09.16.56 # yes. I am concerned we may need a large object->path mapping table 09.17.10 # If I'm correct, the following code is in SOURCES: 09.17.11 # #ifdef USB_ENABLE_MTP 09.17.11 # usbstack/usb_mtp.c 09.17.11 DBUG Sent KICK pamaury to server 09.17.11 # #endif 09.17.11 Kick (#rockbox pamaury :No flooding!) by logbot_!n=bjst@gateway/web/cgi-irc/labb.contactor.se/x-omujtcgrxpmeuywc 09.17.26 Join pamaury [0] (n=pamaury@140.77.26.34) 09.17.38 # Hey, why the bot kicked me ? 09.17.59 # It is a bit sensitive about flooding, perhaps you typed too fast :/ 09.18.01 # I guess because you pasted three lines 09.18.19 # pamaury: I don't have those lines 09.18.32 # your commit only added two files: usb_mtp.[ch] 09.18.32 # Hum, perhaps I forgot too commit them 09.20.30 # I modified several other files, I tought I had commited those changes. what command I should type to do so ? (perhaps that's the reason) 09.21.01 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 09.21.16 Part ecognito ("I read it on the Internet so it MUST be true!") 09.21.24 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 09.21.29 # you need to provide the -a flag to git commit to commit changes to existing files 09.21.49 # alternatively you can use "git add" to add those files to your pending commit 09.21.54 # does it adds unversioned files also ? 09.22.08 # no, you still need to use git add for that 09.22.27 # you can check unversioned files with 'git status' 09.23.58 # That's done 09.25.12 # got it 09.25.14 # Concerning your object->path table mapping, for now it's useless with tagcache. But the problem is that tagcache is limited to music and is not hierarchical. It's a choice I made for the first MTP code because it's simpler 09.25.30 # (the problem is tagcache is that's it is slow) 09.27.46 # yes, we may need to move away from tagcache 09.28.05 # pamaury: are you mixing spaces and tabs in your code? I'm looking at the commit and the alignment is a bit wacky in places 09.28.21 # Normally not, only spaces. 09.28.29 # hmm 09.28.35 # I check that. you mean in usb_mtp.[ch] ? 09.28.52 # usb.c at the moment 09.28.57 # where you've modified it 09.29.36 # Ah, perhaps 09.30.22 # My editor says there are no tabs in usb.c 09.30.29 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 09.30.44 # maybe it's just github playing silly buggers then 09.30.56 # I'm just using it's source browser, I've not actually checked your commi tout 09.31.02 # I'm looking on github 09.31.07 # s/ t/t 09.31.44 # Where do you see strange things ? which line(s) ? 09.32.14 # 310 09.32.15 # I modified the usb.c code because it didn't allowed drivers to get exclusive disk access 09.32.34 # 310 is an empty line no ? 09.32.39 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.32.48 # not according to github :) 09.32.54 # it has "usb_core_enable_driver(USB_DRIVER_CHARGING_ONLY, false);" on it 09.33.06 # oops no storry, looking the wrong version ;) 09.33.22 # and has some odd extra padding at the beginning 09.34.16 # I don't see the problem with this line, it's correctly indented to me 09.35.05 # as I say, it may well be git hub's rendering of it 09.35.18 # Even on github, I don't see the problem :) 09.35.45 # * GodEater prepares a screenshot 09.35.59 # I see a new level of indentation but it's because of the added "else {" 09.36.34 # maybe that's it 09.36.43 # * GodEater throws away the screenshot 09.38.56 Quit bertrik (Read error: 113 (No route to host)) 09.39.22 # * GodEater looks up how to track a remote branch 09.45.33 Quit BHSPitMonkey ("Ex-Chat") 09.47.42 Quit Thundercloud (Remote closed the connection) 09.56.54 Join l403 [0] (n=l@85.132.159.239) 09.57.37 Join xavieran [0] (n=xavieran@ppp118-208-218-251.lns10.mel6.internode.on.net) 09.57.49 # http://www.rockbox.org/twiki/bin/viewfile/Main/SansaFuze?rev=1;filename=fuzev2_bottom.JPG http://www.anythingbutipod.com/archives/2009/08/sandisk-sansa-clip-plus-disassembly.php <<< the 1st lines written on the chip is identical for Clip+ and Fuzev2 so perhaps they use the same AMS SoC .. 10.03.04 Join polobricolo_ [0] (n=paul@AGrenoble-257-1-122-185.w90-27.abo.wanadoo.fr) 10.05.44 Nick polobricolo_ is now known as polobricolo (n=paul@AGrenoble-257-1-122-185.w90-27.abo.wanadoo.fr) 10.06.08 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 10.16.56 Join moos [0] (i=mostafa@rockbox/staff/moos) 10.18.05 *** Saving seen data "./dancer.seen" 10.19.49 Quit pamaury ("exit(*(int *)0 / 0);") 10.30.16 Quit robin0800 (Remote closed the connection) 10.49.41 Quit moos (Read error: 145 (Connection timed out)) 11.12.20 Quit elcan (Remote closed the connection) 11.12.54 Join elcan [0] (i=user36@z0ne.us) 11.14.26 Quit kkurbjunW (Remote closed the connection) 11.14.57 Join kkurbjunW [0] (n=karlk@12.41.166.8) 11.15.56 # any theme site people around? I think the c200 Rockblack(2) theme should be removed/hidden. It sets the volume 11.16.00 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 11.16.44 # and other things actually... 11.18.08 # I have a battery_bench.txt of YH920 (10hours runtime, battery bench stopped at 93%) 11.18.53 # reading from ADC works, but I need to check how the value read is converted to volts (I'm not sure if it's standard on all PP devices) 11.19.52 Quit elcan (Client Quit) 11.20.04 Join elcan [0] (i=user36@pr0.us) 11.27.40 # I hate how PP register locations can be assigned to a register with only mov 11.28.01 # FYI: svn.rockbox.org will be upgraded tomorrow morning european time. downtime approx 08:00 - 09:00 CET. 11.30.10 Join pamaury [0] (n=pamaury@140.77.26.34) 11.34.18 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 11.35.51 # do you know how PP OFs fill IRAM ? 11.43.02 # functions with variadic arguments use the registers for the variable arguments, not only the stack as I thought 11.44.42 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 11.47.27 # i have found a string in my yh920 PP bootloader which could print battery percentage and voltage, but I am not sure how to run the YH-920 into test mode 11.56.43 Join GeekShado_ [0] (n=Antoine@36.201.192-77.rev.gaoland.net) 11.58.39 Quit GeekShadow (Read error: 104 (Connection reset by peer)) 12.03.30 Quit ej0rge (Read error: 110 (Connection timed out)) 12.03.51 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.13.24 # damned, for some reason my YH920 enters USB mode even if usb is unplugged 12.13.57 # "charger present" 12.18.07 *** Saving seen data "./dancer.seen" 12.18.19 # AlexP: ping 12.19.48 # (or rasher, or scorche|sh, or maybe someone else. Are there other theme site admins?) 12.32.20 Quit n17ikh|Server (Read error: 104 (Connection reset by peer)) 12.32.22 Join n17ikh| [0] (n=n17ikh@host-69-59-126-212.nctv.com) 12.32.30 # the battery level (from 0 to 1.0) seems to be (670 - adc_read()) / 110 12.32.47 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 12.33.15 # or rather, (adc_read() - 670) / 110 12.34.18 # so adc_read would range from 670 to 780, i need to get a DMM to measure (and calculate) the voltage 12.38.06 # but my battery_bench measurements show the adc_read() went from 1023 (all 10 bits set) to 916 before shutting down 12.38.30 # Perhaps the OF bootloader code for battery test is wrong though 12.41.16 # could have not been updated for the YH920 battery 12.41.43 # All but one of Quinlan Moll's c200 themes should be removed (11 of them). He doesn't seem to grasp the concept of only including theme-related settings in the .cfg file, so they contain any setting that he happened to be using at the time 12.43.31 # only the Zune theme looks ok to me 12.45.34 # gevaerts: yo 12.46.09 # AlexP: can you remove eleven themes from the theme site? 12.46.23 # can do, what's up? 12.46.33 # see three lines up :) 12.46.36 # ah, I see 12.46.52 # I wonder if hiding or removing is better 12.47.07 # Or getting in touch first 12.47.13 # Or fixing them :) 12.48.12 # It think they should be made unavailable ASAP. Most of them set things like "show files", and all of them set the volume 12.48.41 # also tagcache settings 12.49.23 # OK, I'll hide them all - that should send him an e-mail (or 11 rather) saying get in touch with me when he is ready to re-upload them 12.49.51 # have fun, and start clamoring for a mass-admin feature :) 12.50.40 # hm, actually, my count may be off 12.51.12 Quit krazykit (Remote closed the connection) 12.52.56 # gevaerts: All except zune right? 12.53.29 # one moment, I'm checking again 12.55.54 # zune and windowsmediacab (that one doesn't actually include a .cfg) 12.56.39 # OK, all the others I'll hide 12.57.17 # I'm not sure if we want themes without .cfg, but at least they're not actively harmful 12.57.59 # gevaerts: Should be gone (hidden) now 12.58.16 # great! 12.58.52 # can you give me advice on the price of a DMM I would use with rockbox targets? 12.59.02 # gevaerts: I told him to contact me (here or in the forums) when he has fixed them so I can remove them and he can re-add 12.59.14 # hm, he also uploaded ipod video themes. I guess we need a full audit 12.59.21 # gevaerts: I only hid them in case he doesn't reply, then I'll get round to fixing them eventually 12.59.32 # gevaerts: :/ 13.00.20 # "Skylar G" doesn't sound like a proper name either, and he has a load of ipod video themes 13.00.46 Quit intrados_ (Read error: 110 (Connection timed out)) 13.01.07 # the ipod video "Pod" theme is also buggy 13.01.49 # and the 0800_Text c200 theme comes in a file named .rockbox.zip. Not technically against the rules, but I can't say I like it 13.03.46 # gevaerts: I've hidden the pod one 13.05.57 # it would be good if someone with easy access to the files (i.e. shell, or a bigtar file to download) would check all themes for weirdness I think 13.09.32 # kkurbjun: look in render_slide. you should actually see a nice boost from this, since pictureflow renders by columns anyway. changing the calculation of pixel and pixelstep should do it. 13.10.01 # gevaerts: I guess that'd be rasher, scorche|sh or maybe mculenaere 13.10.46 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 13.36.35 Quit l403 (Read error: 113 (No route to host)) 13.52.02 Join fml [0] (n=4fd3c45a@gateway/web/cgi-irc/labb.contactor.se/x-ekedcpqifahlsnps) 13.53.05 # In keymap-e200.c, button_context_quickscreen, there is an entry for ACTION_NONE. What purpose does it serve? Can it be removed? 13.56.53 # fml: what happens if you enter the quickscreen accidentally, and don't want to change anything ? 13.57.03 # don't you require an ACTION_NONE in that case ? 13.57.45 # GodEater: then you press ACTION_STD_CANCEL. Other players don't have ACTION_NONE in this context. 13.57.55 # ah right 13.59.53 # I think it can be safely removed (will try first) 13.59.53 # Unhelpful: thanks, I found that, I already committed the support in pictureflow 14.00.57 # kkurbjun: ah... i see that now, i only caught the highlighted part before 14.03.45 # New commit by 03vitja (r22607): i7: Notify the backlight driver when the HOLD button is toggled, same as D2 14.03.55 # ACTION_NONE lines are used to suppress combos which would otherwise trigger actions in a chained context 14.04.18 # New commit by 03kkurbjun (r22608): Pictureflow: Fix define 14.07.16 # Ah, it seems the ACTION_NONE entry in e200's quickscreen does serve a purpose. It masks the cancel action in the standard context. I don't fully understand the mechanics but without that entry, pressing LEFT quits the screen. 14.07.47 # amiconn: where is the "standard" action defined? 14.08.06 # amiconn: another issue came up with this vertical stride stuff. This appears to mainly be a problem with the picture.c stuff in the plugin library, but it could also be a problem with the icons. Right now the stride macro makes no attempt to determine what screen it is being used on. This could be an issue for the remote since it's stride is different than the main display... 14.09.02 # fml: a lot of times things like this happen because _STD defines an action on button press, and some other context wants to differentiate between press-and-release and press-and-hold, but wants to include other items from that context 14.09.31 # and pretty much all of that should be in apps/keymaps :) 14.09.49 # I think the stride problem will exist for anything that uses the screens api 14.10.14 # Unhelpful: Ok, now I understand. Thanks! 14.14.20 # Have the USB capable bootloaders for sansa e200 been officially released? 14.18.10 *** Saving seen data "./dancer.seen" 14.23.39 Quit polobricolo (Read error: 110 (Connection timed out)) 14.31.04 Join polobricolo [0] (n=paul@AGrenoble-257-1-122-185.w90-27.abo.wanadoo.fr) 14.34.09 Join moos [0] (i=mostafa@rockbox/staff/moos) 14.34.51 Quit funman ("++") 14.35.47 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.36.21 # amiconn, I'm thinking of ways to go about fixing this, at the moment, I am thinking that if there was an extra parameter in the screens api that scored either screen number or screen type then the stride macro could use that as a parameter which determines whether to return the remote stride or the main display stride. Everywhere else that used the stride macro could call it with a define that was something like LCD_MAIN or LCD_REMOTE if t 14.36.35 # I'm not sure if that's the best way to go about fixing it though 14.49.46 Quit fml ("CGI:IRC (EOF)") 14.52.59 Join petur [50] (n=petur@rockbox/developer/petur) 14.53.22 Quit SUSaiyan (Read error: 110 (Connection timed out)) 14.53.30 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.54.06 # kkurbjun: fortunately the multiscreen api has that 14.54.19 # kugel what is that? 14.54.26 # screen_type 14.54.47 # you can do "screens[i].screen_type == SCREEN_MAIN" etc 14.55.10 # :-D, I missed that 15.02.33 Quit antil33t (Read error: 104 (Connection reset by peer)) 15.02.46 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.03.53 Join Sajber^ [0] (n=Sajber@h-142-237.A213.priv.bahnhof.se) 15.05.07 Nick polobricolo is now known as polobricolo_ (n=paul@AGrenoble-257-1-122-185.w90-27.abo.wanadoo.fr) 15.06.16 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 15.11.01 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 15.13.05 Quit kkurbjunW (Remote closed the connection) 15.13.36 Join kkurbjunW [0] (n=karlk@12.41.166.9) 15.15.43 Quit kkurbjunW (Remote closed the connection) 15.16.12 Join kkurbjunW [0] (n=karlk@12.41.166.8) 15.23.48 Quit polobricolo_ (Read error: 110 (Connection timed out)) 15.38.23 Quit bluebrother (Nick collision from services.) 15.38.27 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 15.39.17 Quit petur (Remote closed the connection) 15.39.38 Join petur [50] (n=petur@rockbox/developer/petur) 15.44.03 Quit petur (Client Quit) 15.44.31 Quit antil33t (Read error: 110 (Connection timed out)) 15.48.28 # kugel: The screen_type member is not supposed to be changed after api init. I don't see how it would help wrt kkurbjun's problem here 15.56.17 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 15.57.40 Part decayedcell 16.03.41 # amiconn: the screen type would help me detect which screen the lcd operations are being done on, and I could use it as an argument to the stride macro 16.07.22 Join arohtar [0] (n=faemir@78.33.109.163) 16.07.41 Quit gibbon_ (Read error: 60 (Operation timed out)) 16.07.45 Join gibbon_ [0] (i=gibbon_@could.become.a.servant4you.org) 16.08.31 Quit faemir (Read error: 104 (Connection reset by peer)) 16.08.37 Join bzed_ [0] (n=bzed@devel.recluse.de) 16.17.35 # amiconn: he didn't intent to change it, IIUC 16.18.13 *** Saving seen data "./dancer.seen" 16.18.17 Part LinusN 16.18.38 Join funman [0] (n=fun@rockbox/developer/funman) 16.19.21 Join Strife89 [0] (n=michael@168.16.237.214) 16.19.45 Join BlakeJohnson861 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 16.20.48 Quit bzed (Read error: 104 (Connection reset by peer)) 16.20.48 Nick bzed_ is now known as bzed (n=bzed@devel.recluse.de) 16.23.59 Quit kkurbjunW ("Leaving.") 16.26.15 # kugel: i notice lcd problems with my fuze 16.27.01 # sometimes "stairs" splashes: each line goes 1 or 2 pixels to the right (from top to bottom), sometimes splashes are correctly displayed 16.27.12 # I also notice the display going on and off on a quick rate 16.27.42 # The best way I found to reproduce it is to launch a demo which does intensive lcd updates (mandelbrot, pictureflow, cube to the max speed) 16.29.00 Quit Strife89 ("Gone to class.") 16.29.08 # Try plasma... 16.29.16 Quit BlakeJohnson86 (Read error: 110 (Connection timed out)) 16.29.38 # funman: I also noticed that 16.30.00 # it seems to be related to boosting also 16.30.12 # amiconn: plasma looked fine for the whole second i ran it 16.30.45 # try playing bubbles with music playing, sometimes it'll go crazy, sometimes it'll be fine. If you force boosting bubbles is always crazy 16.31.03 # additionally, it also only seems to happen on "unaligned" or uneven transfers 16.31.59 # plasma should be fine since it's doing lcd_update() 16.33.10 # you don't wait for the fifo to empty in lcd_write_data() after lcd_write_singla_data16 16.33.22 # or rather, until the fifo is full 16.33.43 # you don't check if the fifo is full* 16.33.51 # the fifo isn't going to get full from a single transfer 16.34.03 # I tried waiting for empty, no success 16.34.51 # it should have been emptied when prior call to lcd_write_data() returned (or have at maximum 16 bits in it) 16.35.05 Quit bubsy (Read error: 60 (Operation timed out)) 16.36.21 Quit DataGhost (Nick collision from services.) 16.36.29 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 16.39.27 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-vsphvxhubgycjlhw) 16.39.37 # funman: any basic DMM should work 16.39.45 # in the US they might go for $10-20 16.40.04 # thanks 16.40.19 # also I saw your remarks about the YH battery voltage 16.40.30 # i thought all was needed was a battery discharge curve? 16.42.15 # yes but figuring out the real voltage would be nice as well 16.43.25 # funman: can you fully charge it in the OF and assume thats equal to 4.25 v? 16.43.32 # why 4.25V? 16.43.44 # thats how much a lipoly battery should be when fully charged 16.44.25 # http://www.commentcamarche.net/guide/314800275-samsung-batterie-pour-samsung-yh-920 : 3.7V Li-ion battery for YH-920 16.45.24 # i think all 3.7v lipoly batteries go up to 4.25 16.45.29 # at least thats how it was for the sansas 16.45.33 # the wiki has no pictures for yh-920 battery 16.45.44 # funman: if you want you can revert r22574 and r22575 (I don't have time now). The blue pixels on the e200v2 and FS#10580 should be fixable by increasing BUTTON_DELAY for both in button-e200v2-fuze.c 16.45.59 Join petur [50] (n=petur@rockbox/developer/petur) 16.46.18 # kugel: i can wait ^^ 16.46.20 # alright, I can too :) 16.46.35 # the 3.7v on the clip says "Charging the cell initially with constant current at 0.5C and then with constant voltage at 4.2V till charge current < 0.05C" 16.46.52 # i think its just a quirk of the chemistry in lipoly 16.47.22 Quit kugel (Remote closed the connection) 16.49.48 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.50.50 # hm when it was fully charged the adc data was maximum (10 bits set) 16.51.11 # and the last value read before power off was 916 16.51.29 # rockbox didn't power off because it thought the battery was 93% full 16.51.45 # c200 "maximum art", strange behavior after wps changes, the first alternating screen dosn't obey its "t" setting on start up just flashes 16.52.00 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 16.52.10 # so, it stopped at 3.8V, does it make sense? 16.54.50 # no it should go much lower then that 16.55.10 # are you sure you have the correct channel on the ADC? 16.58.43 Quit BlakeJohnson861 (Read error: 110 (Connection timed out)) 16.59.09 # no but what else could it be ? 16.59.28 # if it decreases almost linearly with battery 17.00.14 # well there was no change within the first hour 17.00.15 # perhaps the slope is just off? you could adjust it so that 916 is ~3.2v 17.00.19 # hmm 17.01.25 # could be a floating pin, those might go up and down with the supply voltage even if they're not directly measuring it 17.01.55 Join PaulJam [0] (n=Paule@p54BEE982.dip.t-dialin.net) 17.02.59 Quit Zagor ("Don't panic") 17.03.24 # funman: did you try doing a battery bench? the curve from that should give us a good idea if the ADC is really measuring the voltage or not 17.06.28 Quit DarkDefender ("Leaving") 17.06.43 Join low_light [0] (i=c730180a@gateway/web/freenode/x-bzryntfhiwtsqgdw) 17.07.10 # http://img513.imageshack.us/img513/9704/plot.png 17.08.30 # you should "set style data line" 17.08.33 # it really starts at 1:30 (i think it was the rockbox uptime) 17.08.52 # dionoea: thanks, and i should get a title for the data ;) 17.09.01 # funman: the yh9xx OF adjusts the adc readings as such http://pastie.org/603041 17.10.33 # also, the OF calculates the battery level as: level = 100 * (ave - 775) / (924 - 775) 17.10.56 # Is the PLL on ? 17.11.07 # I have seen other numbers in the YH920 OF bootloader test mode 17.11.25 # I don't know if those are right / how to enter test mode 17.11.48 # I don't think you can enter test mode 17.12.08 # funman: If i remember correctly it's set title "bla" for the graph's title and label "bla" for a plot item's label 17.13.07 # plot "plot.txt" using 1:2 title "discharge curve" with lines 17.13.30 # ah ok, so it was title too for the second one :) 17.13.40 Join FOAD_ [0] (n=dok@dinah.blub.net) 17.13.49 # low_light: the numbers i found might well be for another battery and have never been updated 17.14.01 # isn't using 1:2 implicit ? (ok, i'll stop the offtopic talk) 17.14.20 Quit moos (Read error: 131 (Connection reset by peer)) 17.14.47 # low_light: is the PLL dynamically toggled in YH? 17.15.04 Join moos [0] (i=mostafa@rockbox/staff/moos) 17.15.55 # funman: it depends on the cpu freq (system-pp502x.c) 17.16.23 # using your numbers I see the battery went from 166% to 94% (adc[1] from 1023 to 916) 17.17.15 # minus 0x1a would not change much 17.18.03 # however, it looks like maybe the pll is always enabled 17.18.24 Quit robin0800 (Remote closed the connection) 17.18.30 # have you checked if we use the correct adc channel? 17.19.51 # Those numbers were for the 925, let me see if the 920 is different 17.25.39 Join Creposucre [0] (n=86f69562@gateway/web/cgi-irc/labb.contactor.se/x-sjvavqxoqaleuxnt) 17.26.06 # Hi 17.26.07 # funman: looks like the 920 uses level = 100 * (ave - 850) / (1023 - 850) 17.27.10 # means power off at 38% :/ 17.28.07 # or rather, 84% with battery full and 23% battery empty (removing 0x1a from values read) 17.28.46 # Dionoea: Did you found some time to test your remote? 17.28.56 Quit FOAD (Read error: 110 (Connection timed out)) 17.28.56 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 17.29.12 # Creposucre: I completely forgot about it when I got home (and remembered this morning at work). I'll try not to forget tonight :) 17.31.10 # lol 17.31.12 # ok 17.31.14 # no problem 17.32.16 Quit saratoga ("Page closed") 17.32.40 # dionoea: do you have others accessories than the remote? It should work for them too 17.33.31 # I have the apple dock which features a line out, mic input, SPDIF output and an IR receiver which already kind of works when using the remote provided with a macbook 17.33.44 # other than that not really 17.35.05 # low_light: have you seen the FM radio patch on flyspray? 17.36.20 # might need change in audio-pp.c 17.38.18 # kugel: the problem with fuze lcd might be related to buttons (i get invalid readings when the screen flickers) 17.38.35 # dionoea: What does not work correctly with the commands? 17.39.42 # funman: you mean change on the modification I made? 17.40.27 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 17.40.37 # Creposucre: no, it was addressed to low_light 17.41.52 Quit petur (Nick collision from services.) 17.41.58 # Creposucre: As far as I remember the only slight issue I still have (when using the radio remote for example) is the volume control which is done in hardware on the remote and not on the ipod. That might have changed recently though so I'll have to double check. I'll post all the info once I've given it a try tonight. 17.42.03 Join petur [50] (n=petur@rockbox/developer/petur) 17.44.23 # dionoea: ok. I added some stuffs to modify the ipod volume with a remote control, but not from the ipod to the remote yet since I had some tests to do 17.45.14 Join saratoga [0] (i=9803c6dd@rockbox/developer/saratoga) 17.45.50 # basically, if I remember correctly, you had 2 serialized volume controls: the ipod's and the remote's 17.46.12 # while it seems that you only have 1 when using apple's firmware with the remote control (of course I could be mistaken) 17.46.30 # i'm increasingly annoyed at the current "supported" and "unsupported" build system we use 17.46.43 # i really think we should reconsider this 17.47.16 # saratoga: what do you mean? 17.48.29 # dionoea: you're right, a modification of the volume on the ipod under the OF modify the volume of the remote 17.48.58 # funman: we have targets like the YH and AMS sitting as unsupported for ages which I don't think helps anyone 17.49.27 Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) 17.49.32 # IMO they should be supported and simply marked "unstable" since they're usable and we'd like people to use them, report bugs and perhaps develop if they're interested 17.49.41 # but not completely stable yet 17.49.44 # but the volume of the remote and the volume on the ipod's port would be the same in the OF, while in rockbox you still have both volume filter which apply (ie volume applies on line out). Or maybe you changed that 17.49.53 # dionoea: I have to link the ipod volume to the remote and it is ok. I just thought that It might be a need to keep two separate level 17.50.18 # saratoga: you arn't the only one... were we going to say pretty much once the main build works it would fall under todays "supported" category and then have classes like gold/silver/bronze for how well? 17.50.19 # same as the Gigabeat S, having it languish as a half supported target for the last year has done nothing to encourage people to work on it, and a lot to make it harder for users and prospective developers 17.51.04 # IMO when a port is usable but still unstable we should encourage people to use it, since that tends to encourage people to work on it 17.51.13 # dionoea: yes I did, at least for the remote buttons to control the ipod volume level 17.51.40 Join ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) 17.51.56 # saratoga: i'm not sure bug reports are useful at this stage (at least on AMS) 17.51.57 # JdGordon: I don't know what was decided, but I'd like to just have "stable", "unstable", and "unsupported" 17.52.17 # funman: no but they'd be nice on the YH for instance 17.52.35 # stable, unstable and not working at all... supported is a bad term 17.52.47 # I think one would just need to make a list of targets with their new status and send it to the mailing list => if no complaint, then it becomes official 17.52.47 # stable, unstable and unusable 17.52.59 # saratoga: the Philips hdd1630 should be supported too. It only lacks rbutil install and the manual. 17.53.02 # should be quite clear 17.54.33 # stable means rbutil and most everything works, unstable means no rbutil but playback mostly works for day to day use, unusable means its missing playback and/or important drivers 17.54.39 # stable and unstable dont work so well.... the clip is unstable plaayback but fine everything else... the fuze is definetly as stable as any other target... the mr500 would be in the unstable group because of crappy install and start procedure but playback is fine 17.55.10 Quit petur (Remote closed the connection) 17.55.23 # the fuze is unstable in the sense that we keep breaking drivers (well kugel) and other drivers simply don't work correctly (microsd) 17.55.44 Join petur [50] (n=petur@rockbox/developer/petur) 17.56.33 # its usable if you don't mind some revisions being less functional then others, and possibly overclocking your SD card 17.56.34 # we should use some rating system and then on the front page have "rockbox runs at various levels of completeness and stability on the following DAPs.... for further details and known issues" which leads to the TargetStatus wiki page 18.03.52 Quit Creposucre ("CGI:IRC (EOF)") 18.04.42 # saratoga: that's essentially what was decided at DevConEurope, that a lot of targets need to be promoted from unsupported to some status inbetween fully stable and not supported at all 18.04.52 # although I think the Gigabeat S is still a special case =/ 18.05.42 # heh 18.06.16 # until we have a confirmed working way to get a single bootloader on it at least 18.06.22 # low_light: Ping 18.06.59 # GodEater: do we actually know what the pattern is there, with which devices will take a single bootloader and which won't? 18.07.04 # nope 18.07.11 # no more than we know what triggers the random reformating 18.07.19 # unless you've made progress there ? :) 18.07.22 # not yet :) 18.07.34 # sorry. recently i have been really busy and/or high. :) 18.07.43 # * GodEater shrugs 18.07.50 # you're not on a timetable as I recall ;) 18.08.41 # on the subject of hte beast, though 18.08.51 # is someone willing to commit the flash dumping patch I wrote 18.09.02 # or do we want to fix up that mess in debug_menu first 18.09.06 # Torne: A flash dumping patch, you say? :) 18.09.12 # FS# ? 18.09.13 # Torne: What FS#? 18.09.14 # it would probably be quite useful to hav ethe flash dumping patch in 18.09.29 # FS#10410 18.09.42 # it makes the huge ifdef'ed nightmare in debug_menu.c worse 18.09.53 # hurrah! 18.10.04 # there was a discussion in here some time ago about it and we decided it would be nice to factor that crap out into firmware 18.10.19 # there were various methods of doing this proposed 18.10.22 # and nothing really decided :0 18.10.37 # but, yah. whether that happens or not it would be nice to have flash dumping for the beast rom in 18.10.51 # in that case I think it's rather silly to wait to commit this 18.10.54 # because then i can ask people with beasts to dump their flash to check what version they have and what settings they have 18.11.06 # if no-one has a plan for doing it any time soon, we're just hurting ourselves not having it in 18.11.08 # and see if we can find a pattern for who experiences reformats and who can't use a single bootloader 18.11.22 # i have 3 dumps I think 18.11.23 # I should try and reassemble my first beast 18.11.28 # which are all different 18.11.32 # and try this on the working one I got recently 18.11.38 # and all differ amusingly from the versions in the firmware updates as well :) 18.11.46 # but that might be explained now that i've found the config sectors 18.12.03 # not that i know what the data in the config sectors mean yet, or if it's actually changed in practise 18.12.07 # but it's *there* 18.12.14 # and one of hte bits stops the reformats! :) 18.12.27 # it also stops any method of recovering the device other than taking hte disk out, admittedly 18.12.27 # we've had similar weirdness with the Gigabeat F I think 18.12.30 # but it does stop it reformatting. 18.12.56 # that's a bonus 18.12.59 # not really 18.13.04 # did you manage to find a reliable way to trigger them then ? 18.13.08 # that you know this stops them 18.13.10 # it means that whenever the condition that causes the reformats happens, the player bricks 18.13.15 # hahahaha 18.13.16 # ah 18.13.17 # I see 18.13.22 # so it doesn't stop it very well ;) 18.13.25 # instead of reformatting it just crashes 18.13.31 # and will continue to crash on boot until the problem goes away 18.13.36 # awesome 18.13.38 # which requires fixing the disk using an ipod or similar ;0 18.13.43 # i haven't actually tried it, either 18.13.44 # lovely 18.13.53 # but it's checked in all the paths i have found so far that cause reformats 18.14.00 # it's likely it's a flag for the device type, or similar 18.14.03 # "is this a devboard" 18.14.11 # i.e. so that test hardware doesn't reformat 18.14.18 # right 18.14.19 # on the assumption that someone wants to debug it. 18.14.32 # low_light: FS#10431 is waiting for you to check out. 18.14.39 # there's also a flag that controls how much memory it thinks it has :) 18.14.42 # well we could definitely do with some more dumps then I guess 18.14.42 # which again is for the devboard 18.14.52 # turns ethernet on as well i think 18.14.56 # Torne: i have put the cleaning of debug_menu.c on my TODO list but didn't feel like doing it O:-) 18.14.59 # * GodEater is also suffering from lack of time atm :( 18.15.08 # funman: ah yes it was you i was discussing it with 18.15.16 # anyway yeah i think for now just shove my patch in as is :) 18.15.20 # * GodEater votes that someone with commit access puts the dump patch in then 18.15.21 # someone can clean debug_menu.c later 18.15.24 # yeah 18.15.31 # though I realise votes don't count for squat :D 18.15.34 # having an extra dozen lines in doesn't make it measurably worse :0 18.15.49 # also, I think FLASH_SIZE for the beast is wrong 18.15.54 # as mentioned in the FS 18.15.56 # yes, I read the comment 18.16.00 # i haven't changed it in the patch 18.16.07 # but all three dumps i have are just mirrored 18.16.13 # it's a pity jhMikeS has fallen off the intertubes 18.16.16 # and the available schematics on the wiki indicate the smaller size is right 18.16.25 # ah 18.16.49 # the devboard has 4x the flash, as well, according to the schematic 18.16.55 # so the size is not right for that either :0 18.17.09 # GodEater: No one's seen or heard from him? 18.17.18 # it's not the end of the world to have mirrored dumps 18.17.19 # well I haven't heard from him for AGES 18.17.25 # though it means people need to punt bigger files around 18.17.25 # have you ? 18.17.45 # logbot has seen him 1month 10 days ago 18.17.50 # if someone puts the flash dump patch in, then i will write a lil tool that tries to ID dumps 18.17.54 # funman: lucky logbot ;) 18.17.59 # i'll see if i can work out what regions are supposed to be variable or not 18.18.02 # and md5sum them seperately 18.18.13 # * GodEater coughs at LambdaCalculus37 and asks him to do the deed 18.18.13 # then we can see if everyone's dump matches up to one of hte known ones or not 18.18.14 *** Saving seen data "./dancer.seen" 18.18.40 # there's at least three things in the flash: the pmcboot_secure.bin which is the actual loader, the config page, and the recovery.bin 18.19.05 # there is some evidence that beasts do *not* always reflash themselves when upgraded 18.19.23 # iirc someone had 1.3 firmware on their beast but the bootloader in their flashdump was definately older 18.19.35 # that doesn't sound like a recipe for success 18.19.44 # it seems to work anyway, though 18.19.51 # yeah, but it's still weird 18.20.21 # well yes :) 18.20.28 # but there's lots of weird things in the beast rom 18.20.48 # "here be dragons" 18.21.01 # I documented the disk setup ones at http://www.rockbox.org/twiki/bin/view/Main/GigabeatSOriginalLoader btw if you've not seen it 18.21.06 # well the ones i've found so far 18.21.19 # * GodEater hadn't seen it 18.21.20 # that's just the partition setup and disk checks, the "first round" of stuff that might cause a reboot 18.21.22 # * GodEater goes to read 18.21.35 # i think there are more later when it actually tries to access the FS for real to read the firmware 18.21.46 # the code i've reversed only looks at MBR and BPBs 18.21.50 # nothing in fat 18.21.56 # (so not the TFAT stuff yet) 18.22.02 # BPBs ? 18.22.10 # boot parameter blocks 18.22.13 # first sector of the partitions 18.22.17 # ah ok 18.22.31 # FAT's version of superblock ;) 18.22.35 # right 18.23.00 # and those don't differ between FAT32 and TFAT it seems 18.23.11 # no. 18.23.26 # Not sure if the volume label being TFAT is significant or not yet 18.23.35 # not got to the point where it might read that 18.23.56 # do you know what it is about the disk when it's "virgin" that means linux refuses to mount it? 18.24.02 # I've never figured that out 18.24.08 # linux refuses to mount it? 18.24.23 # yeah, you have to open it up in fdisk and re-write the MBR 18.24.29 # weird. 18.24.41 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 18.24.42 # on repartition it seems to write the mbr out fairly sensibly 18.24.42 Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 18.24.51 # makes a 150mb partitoin and a rest-of-disk 18.24.56 # i've not actually run any of this code though 18.24.59 # and this is only the 1.3 loader 18.25.04 # which i suspect few people actually have 18.25.15 # but i'm reversing this one because everyone could upgrade to it if necessary 18.25.20 # http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInstallation <-- see Step 2 18.25.43 # oh, it doesn't set the bootable field? 18.26.05 # unsigned int lol = 3600*1024*1024; warning: integer overflow in expression 18.26.05 # seems not 18.26.08 # It doesn't check those. :) 18.26.14 # I don't understand how it can overflow a 32 bits integer? 18.26.20 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 18.26.20 # the bullet points i put on the wiki there is *all* it checks 18.26.33 # so it's possible that ATACreateMBR doesn't write valid values to the status byte either 18.26.37 # i'll check it out 18.26.47 # especially when 3600<<20 doesn't give a warning ! 18.27.07 Quit BryanJacobs ("Java user signed off") 18.27.11 # it should be ok to just set it to 0x00 or 0x80 though 18.27.28 # since it doesn't check 18.27.40 # which is what the instructions say to do :) 18.27.41 # cool 18.27.42 # WPS %pt used to be track length it is now total tracks length is this correct? 18.27.56 # anyway off for now 18.27.59 # later 18.28.11 # i will probably have a look at the dumps later and see if i can make proper notes on the wik i of which bit is which 18.28.17 # and the md5sums of bits I know 18.28.20 # so people can compare 18.31.07 # Q. can rockbox FAT driver write 2GB+ files? 18.33.13 Quit Rob2223 () 18.33.34 Join Rob2222 [0] (n=Miranda@p4FDCDC4D.dip.t-dialin.net) 18.35.10 Join JdGordon_ [0] (i=441bed28@gateway/web/freenode/x-bwkwlckzzbpfdmyn) 18.35.57 Join intrados_ [0] (n=intrados@cpe-71-67-138-190.woh.res.rr.com) 18.36.18 # * GodEater notices we "now have a source for the nk.bin file" 18.36.23 # where the hell did we get that ? 18.36.36 # toshiba put up a firmware link last winter 18.36.41 # awesome 18.36.57 # like 2 days after i finally got around to writing code for dumping the one from the disk 18.36.59 Quit intrados_ (SendQ exceeded) 18.37.02 # hahaha 18.37.03 # which is why i stopped working on it 18.37.04 # bastards 18.37.07 # it's like they knew 18.37.10 # maybe they used that code? 18.37.30 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.38.44 Join intrados_ [0] (n=intrados@cpe-71-67-138-190.woh.res.rr.com) 18.40.24 Quit pamaury ("exit(*(int *)0 / 0);") 18.40.27 # yeah, there are a few different versions of the beast firware floating around 18.41.23 Quit petur (Read error: 113 (No route to host)) 18.41.46 # I still think that somebody, somewhere, has the v1.1 restore utility forgotten somewhere on their computer. At least, google turns up forum posts of people who say they used it. 18.42.01 # i have v1.2 and v1.3 upgrade packages 18.43.15 # isn't the 1.1 restore tool actually for the gigabeat V and hacked to work with the S? 18.44.23 # saratoga: I saw at least one person claim that they got a tool from toshiba to restore their S, that predated the release of v1.2 18.44.47 # anyway, bbl 18.47.11 # is something like this better discussed on the SVN or Developers list? 18.47.33 # which? 18.48.29 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.48.42 # the supported unsupported thing 18.49.03 # dev ml.... 18.49.29 # it has been agreed on sort of.. so its just a matter of putting targts in the right status and fixing the site... 18.51.33 Part fish_ 18.52.20 # is there a description of what was decided? 18.55.00 Quit bertrik ("ubuntu needs a reboot") 18.55.35 # i dnt remember if it was irc or ml.. but it was decided at DCE anyway 18.55.41 # or at least that it shuld change 18.57.11 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.59.28 # JdGordon_: haven't tried myself yet but did you assign a default value for %t again (it was possible before to use it without number in which case something like 2 seconds was used, since I never used it the "pure" way I wouldn't notice, just wondering) 19.00.05 # %t with nothing is the same as ; isnt it? 19.00.25 # pixelma: I think this is now broken 19.01.16 # JdGordon_: did that work before? As I said, I always used other timeouts so wouldn't know 19.01.49 # I did testing with just ; and =with %t with a timeout.... it should work 19.01.57 # robin0800: %t with no number is broken? 19.03.03 # pixelma: pt has changed i think and %t in alternate conditionals neither of my wps works properly now 19.03.51 # pt=%pt 19.04.21 # robin0800: %pt wasn't touched, maybe it doesn't work correctly but I don't understand you descriptions what it does differently now 19.04.22 Nick dys` is now known as dys (n=andreas@95.112.82.178) 19.04.34 # s/you/your 19.05.40 # pixelma: it used to show track time now its showing tracks total time 19.09.06 # I can't imagine what you mean with "track time" and "tracks total time"... is your %pt on a subline by any chance? 19.09.09 # pixelma: perhaps that should be a question as I'm not sure what it is displaying now 19.09.09 # tracks total time?! 19.09.22 # GodEater: that fdisk step should no longer be needed. The USB storage code cheats a bit on the beast 19.09.25 # LambdaCalculus37: Hi! I'v been really busy lately, but I hope to get to the hdd6330 port soon. I haven't tried your patch for the sa9200 plugins, but as long as it doesn't break anything, feel free to commit it. 19.10.06 # I'll update and see what my WPS does 19.10.26 # pixelma: no its in a bunch of conditionals 19.10.58 Join stoffel [0] (n=quassel@p57B4C71B.dip.t-dialin.net) 19.11.13 # * JdGordon_ bbs 19.12.54 # AlexP: do you feel like hiding some more themes? dCleanAA sets the language to Brasilian Portuguese (and seems obsolete anyway), and dCleanAA-2 still sets lang (english this time), as well as scroll delay and scroll speed (I don't think those belong in a theme, but I'm willing to be convinced otherwise) 19.13.14 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 19.13.23 # gevaerts: Sure (which target?) 19.13.46 # oops, sorry. e200 19.14.14 Quit JdGordon_ (Ping timeout: 180 seconds) 19.14.31 # I thought those themes would be rejected anyway? Or couldn't those settings be stripped from the cfg file? 19.15.19 # I seem to vaguely remember that linuxstb told me to be nice and not do that when I proposed to upload such a cfg file 19.15.37 # I think they should be either rejected or cleaned automatically, yes 19.15.59 # I agree. 19.17.15 # I did only find two theme authors who got it wrong though 19.17.41 # robin0800: from CustomWPS) %pt - Total Track Time (the length of the track). That hasn't been changed in a loooong time 19.18.26 # gevaerts: OK 19.18.49 # pixelma: I know but something has stopped it working 19.19.07 # I deleted the first one (as he uploaded the 2nd to replace the first), and hid the second one telling him to let me know when it was fixed. 19.19.10 # AlexP: I looked at cfg files for all themes, so I think I won't bother you with this for a while now :) 19.19.27 # Good work, and I don't mind :) 19.19.56 # AlexP: So, apparently the guy working on DxVA (even posted and said he had some renderers he thought were ready to go, except that he couldn't get a directX surface to render on, since at the time the Dx build wasn't usable yet) is facing DMCA charges for something else, supposedly 19.20.03 # Oops, wrong channel, sorry 19.21.04 # hello, I have just realized that my buildclient glasschale-Rondom is blocked because it disconnects every 10 seconds 19.22.30 # the reason for the disconnects is the following message: "HELLO failed: error duplicate name!" 19.23.12 # do you have two clients running? 19.23.18 # robin0800: What exactly happens? "something has stopped it working" isn't a useful bit of information on its own 19.23.36 # pixelma: the second problem is on "maximumart" where now the first screen dosen't obey the display time 19.24.05 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-usrafijcwsbafueu) 19.24.07 # gevaerts: no, but I do have had this message from time to time, when I got disconnected and tried to reconnect 19.24.37 # Rondom: I think you'd better wait for Zagor then 19.24.51 # Llorean: it shows a time that appears to be a sum of the playlist tracks times 19.25.28 # Rondom: I had that too once, killing the client and restart helped 19.26.03 # robin0800: you arnt using a custom build are you? iirc there is absoluytlyu nowhere that the count is being kept 19.26.21 # JdGordon|: There's nowhere to even *make* that count without opening all the files involved, right? 19.26.34 # pixelma: hmm, maybe I can try to reproduce by disconnecting my internet connection 19.26.36 # yes 19.27.16 # I guess it could be a random number which might be close to the complete playing time of the playlist by accident... but I update and have a look myself 19.27.25 # JdGordon|: no and this afternoon ive been using the sim 19.28.06 # pixelma: yes I'll go with a random number 19.29.16 # low_light: I will, but I wanted a second opinion on the patch, and perhaps a little help getting the dimensions for a few of the plugins right. 19.36.23 # FlynDice: can you look at FS#10507 if I forgot something and test on your side? 19.38.47 # I can use the µSD card at a correct frequency with your patch 19.39.28 Quit funman ("free(random());") 19.50.05 Join Lss [0] (n=Lss@cm204.delta92.maxonline.com.sg) 19.50.32 Join fml [0] (n=4fd3c45a@gateway/web/cgi-irc/labb.contactor.se/x-ozxvrrdflxlzoqxz) 19.50.32 Join petur [50] (n=petur@rockbox/developer/petur) 19.51.02 # I'm sorry to ask again but have the USB capable bootloaders been released for sansa e200 (v1)? 19.51.24 Nick n17ikh| is now known as n17ikh|Server (n=n17ikh@host-69-59-126-212.nctv.com) 19.52.16 # yes and no. They are on the download server, but not in the correct place 19.54.42 # I can't see anything wrong with the %pt info in my c200 WPS. robin0800 - are you sure it's not the file(s) you tried? 19.54.47 # gevaerts: so it's impossible to download them? Have they been tested? I.e., for example, do you use them? Do you have problems? 19.55.40 # fml: you can download them, and they are tested. rbutil won't find them though 19.59.15 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 20.02.11 # gevaerts: is it what's in http://download.rockbox.org/bootloader/sandisk-sansa/e200/ ? 20.02.31 # no, that's the old one 20.02.46 # http://download.rockbox.org/pp-bootloaders/ 20.03.02 Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) 20.04.03 # huh, don't know how I managed that but at the moment the WPS shows the name of the next track as title of the currently playing one - and "next track" info shows the same. Playlist position is correct though 20.04.19 # ah fooey 20.05.45 # gevaerts: changing bootloader location on the download server is not a good idea. rbutil will install the old ones :-) 20.06.00 # and I don't know if it was the case before but if you seek for a while scrolling lines stop (at "position 1") 20.06.18 # gevaerts: should I just follow the installation instructions in the manual? Or how do I install it? Is there a wiki page? 20.07.31 # JdGordon|: that next track/current track info problem did not correct itself on track change, will keep an eye on that 20.07.35 # gevaerts: there's no mention of pp5022.mi4 there, only sansa patcher 20.07.58 # domonoky: I know that... 20.08.11 # fml: the download location has both 20.08.26 # gevaerts: good :-) so they will get moved if final ? 20.08.35 # JdGordon|: not even stopping playback and resuming helped 20.08.47 # eek! 20.09.08 # a complete reboot did... 20.09.24 # domonoky: as soon as Zagor or Bagder get to it 20.10.32 # can't reproduce easily though and don't know how I got there 20.10.36 # pixelma: did you change the theme before the next/current track problem occured? i have seen this problem too, but only after loading a theme. 20.10.50 # * gevaerts is one of several people who do not have write access to the download master 20.11.02 # PaulJam: yes, I was testing some 20.12.19 # PaulJam: do you remember about when you saw this the first time - recently or a while ago? 20.13.40 # gevaerts: thank you! All went well. One last question: the battery charging works as before? I.e. if I just connect the player to the PC while the player is off, the battery will be charged? 20.15.12 # it should 20.16.38 # pixelma: i think i saw it about a week ago the first time, but before that i did not update rockbox for a few weeks. 20.18.17 *** Saving seen data "./dancer.seen" 20.18.56 # gevaerts: OK! 20.24.49 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.27.06 # funman:(for the logs) re FS#10507 I'll take a look tonight sometime, very busy with real life these days.... 20.27.58 Join Strife89 [0] (n=Michael@214.sub-75-254-83.myvzw.com) 20.29.19 # FlynDice: I'll apply it to my e200 sometime today 20.35.53 Quit petur (Remote closed the connection) 20.36.49 Join petur [50] (n=petur@rockbox/developer/petur) 20.38.00 Quit fml ("CGI:IRC (EOF)") 20.41.57 Quit petur (Remote closed the connection) 20.42.22 Join petur [50] (n=petur@rockbox/developer/petur) 20.44.07 Quit amiconn (Nick collision from services.) 20.44.09 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 20.44.26 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 20.44.26 Quit pixelma (Nick collision from services.) 20.44.31 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 20.44.45 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 20.48.57 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 20.55.14 # GodEater: The "linux refuses to mount beast" cause is known 20.56.37 Join Strife1989 [0] (n=michael@95.sub-70-223-206.myvzw.com) 20.56.51 Join MDCarr [0] (n=Michael@95.sub-70-223-206.myvzw.com) 20.57.06 Quit MDCarr (Client Quit) 20.57.18 Quit Strife89 (Nick collision from services.) 20.57.23 Nick Strife1989 is now known as Strife89 (n=michael@95.sub-70-223-206.myvzw.com) 20.57.47 Join funman [0] (n=fun@rockbox/developer/funman) 21.00.08 # [18:31:07] Q. can rockbox FAT driver write 2GB+ files? <= A: No, it can't, since it uses 32 bit integer for off_t 21.01.17 # and off_t is signed 21.01.31 # I just ran a test with a bit less than 2GB 21.02.08 # test_disk ran fine, but rockbox couldn't play from the µSD card, elapsed time just stayed at 0 (didn't investigate further) 21.02.42 # That's in fact one of the things I wanted to look into (changing off_t to 64 bits). If it doesn't cost too much, it should be enabled for all targets 21.03.15 # I know that at least *some* OFs do handle 2GB+ files (the iriver firmwares do) 21.03.21 # is there a real gain to allow 4GB files? 21.03.36 # Recording people will probably like it. 21.04.01 # how long would a 4GB mp3 recording be? 21.04.03 # i mean we would just put the limit a bit higher, not get rid of it 21.04.08 # Yes - not choking on perfectly legal files is certainly a plus 21.04.32 # funman: A higher limit though, means that if you need to record say, a show that caps out at 3GB, you don't have a split. 21.04.35 # JdGordon|: I'd suspect people who hit the limits to record to lossless 21.04.39 # I tested a 2.5GB WAV file on my H300. The OF plays it, rockbox simply skips it 21.04.54 # oh right we can record to wav 21.05.46 # Yes, and we can even do that on archos (just still nonintegrated) 21.05.57 # * JdGordon| forgot that 21.06.49 Quit GeekShado_ (Read error: 110 (Connection timed out)) 21.09.10 # If I have a 30 gig iPod Video that used to have rockbox on it, and it is broken. How can I tell what part of it is broken, how can I tell if it is the hard disk? 21.11.00 Join T44 [0] (i=Topy44@f048185214.adsl.alicedsl.de) 21.22.47 # JohnTeddy: An iTunes restore would help 21.24.26 # Hillshum: I see, will iTunes restore tell me what is wrong? 21.24.46 # Hillshum: isn't that a bit heavy-handed? 21.25.01 Quit PaulJam (".") 21.25.13 # gevaerts: ? Isn't that the best thing to do to misbehaving iPods? 21.25.21 Quit Strife89 ("Huzzah!") 21.25.49 # Hillshum: clearing everything? That may be the most thorough way, but it should never be the first thing you try... 21.26.03 # true. 21.26.35 # JohnTeddy: Will it connect? Have you run a disk test like scandisk or fsck? 21.28.51 Quit Topy44 (Read error: 110 (Connection timed out)) 21.31.27 # Hillshum: not yet, my ex says it's broken. 21.31.42 # (It was a christmas gift, I put rockbox on it) 21.32.01 # So since rockbox players are hard to find, I thought I might be able to put a new hdd in and fix it. since she doesn't know how. 21.32.09 # I don't know the details of the problem yet. 21.32.21 Join antil33t [0] (n=Mudkips@119.224.12.185) 21.32.25 # She left her car jack here, so I'm going to see if I can get the broken player. 21.32.49 # JohnTeddy: Has she tried resetting it? 21.33.04 # no idea, but I don't want her to fix it. heh 21.33.09 # I want her to give up, and give it to me. 21.33.18 # It's been like this for several months. I hope she didn't throw it out. 21.33.28 # heh 21.33.41 # I tried to buy a new player online, but the ones that work with rockbox are too hard to find. 21.33.58 # So I figured this one is probably repairable, as long as she didn't static shock the ICs or something 21.34.58 # Is there a good possibility that she overlooked something simple? 21.35.10 # probably 21.35.21 # The device is a couple years old 21.36.07 # JohnTeddy: Be advised that this channel is logged publically 21.39.29 # It's fine, she can't figure out how to get on irc. I told her I wanted to try and repair it, and ask if I could have it. 21.39.44 Join froggyman [0] (n=chatzill@pool-71-186-11-249.chi01.dsl-w.verizon.net) 21.40.36 # JohnTeddy: A google search will bring up stuff from this channel. 21.40.51 # and? 21.41.13 # Did I say something taboo? 21.42.02 # No, just don't say anything you don't want coming up. Sounds like things are fine 21.43.01 Join p3tur [50] (n=petur@rockbox/developer/petur) 21.44.23 Quit petur (Read error: 104 (Connection reset by peer)) 21.45.27 # Is it hard to get the device 'opened' and replace the hard disk, physically that is. 21.46.23 Nick p3tur is now known as petur (n=petur@rockbox/developer/petur) 21.47.03 # Depends. It's not too hard to do if you don't mind scratches and other visible traces of you doing it. I have no idea how hard it is to do it properly 21.49.57 # the thing is keyed/scratched to hell anyway 21.58.52 Quit Thundercloud (Remote closed the connection) 21.59.10 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") 22.02.55 Join BdN3504 [0] (n=55b20d37@gateway/web/cgi-irc/labb.contactor.se/x-bspllqncsgeqrqly) 22.03.25 Join bubsy [0] (n=Bubsy@94.139.72.137) 22.03.49 # i think i found a bug in the wps code: since we have support for realmedia files now, is that change already in the wpstag for the codec? %fc ? 22.04.31 # BdN3504: Did you try? 22.04.51 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 22.04.54 Quit LambdaCalculus37 () 22.05.13 # New commit by 03rob (r22609): Make the left quickscreen item work in touchscreen grid mode. 22.08.33 Join paprica [0] (n=47ba0bf9@gateway/web/cgi-irc/labb.contactor.se/x-pctkruzptldgarsk) 22.08.41 # * low_light listens to radio on the yh920 22.09.03 Quit paprica (Client Quit) 22.09.51 # low_light, is that a first time for radio to work on yh920 rockbox? 22.10.23 # yes 22.10.47 # it's kind of a bad hack for now 22.11.08 # nice 22.11.31 # what's the "bad hack" part of it? 22.12.44 # well, no regular audio output (from files), just the radio 22.13.12 # * bertrik has some code for the c200v2 button reading ready to test on actual hardware 22.13.20 # Llorean: no, i did not, but the neither the wiki nor the manual list it. 22.18.20 *** Saving seen data "./dancer.seen" 22.19.00 # low_light: cool :) 22.19.06 Join p3tur [50] (n=petur@rockbox/developer/petur) 22.19.57 Quit petur (Read error: 113 (No route to host)) 22.20.01 # BdN3504: So try it out, then write whichever patches are necessary? 22.21.21 Join Strife89 [0] (n=michael@168.16.237.214) 22.22.39 # Llorean: i can't, sorry. but i'll try. where would i have to append this/which files would i have to look at? 22.23.03 # low_light: 820 and 925 have no tuner? 22.23.08 Quit p3tur (Remote closed the connection) 22.23.14 # according to the status page on the wiki they dont' 22.23.21 Quit tvelocity (Read error: 104 (Connection reset by peer)) 22.25.50 Join p3tur [50] (n=petur@rockbox/developer/petur) 22.31.24 Quit stoffel (Remote closed the connection) 22.32.05 # funman: Correct. The OF doesn't have the option, but I haven't taken them apart to verify that the hardware is not there 22.34.31 # taking yh920 apart is simple : no plastic locking (or very easy to take off) 22.34.53 Join tvelocity [0] (n=tony@adsl19-148.her.forthnet.gr) 22.36.31 # funman: radio patch: http://pastie.org/603517 22.36.57 # it's probably got some othere stuff there too 22.37.18 # can you switch between playback/radio ? 22.37.59 # ide power enable > should higher a bit the runtime, I got 8/9 hours 22.40.46 # IIRC, fmradio_i2c_init isn't usually done inside power_init 22.41.27 Quit tvelocity ("Αποχώρησε") 22.42.00 # funman: it doesn't switch back to playback 22.42.31 # oh, it is on the beast 22.42.45 Quit bmbl ("Bye!") 22.42.58 # low_light: what if you reset akcodec completely? that would give a hint 22.44.12 Quit p3tur (No route to host) 22.45.42 # I'm a bit surprised that fmradio_i2c-yh920 apparently works, bytes are sent as 8-bits with no ACK it seems 22.47.07 # bertrik: you'd have to ask someone at Samsung about that ;) 22.48.33 # Is there a way to get the bootloader to load the default firmware? seems as though my Sansa won't charge properly when rockbox is running 22.48.47 # bertrik: it's possible that people implementing i2c are laxist or workaround broken software implementations 22.49.02 # Klowner: yes, this is documented in the manual; 22.49.26 # funman: ah, I must be looking at the wrong section of the manual 22.49.27 Part JohnTeddy 22.49.29 # funman, but it talks to a TEA5767 chip right, so it should be doing proper i2c 22.50.10 # Klowner: is your sansa a c200 or e200? 22.50.23 # funman: e200 22.50.32 # hold the left button? just found it 22.50.45 # http://download.rockbox.org/manual/rockbox-sansae200/rockbox-buildch3.html#x5-290003.1.3 22.50.49 # ok ^^ 22.50.55 # thank you :) 22.53.04 # hmm... /me just got error updating playlist control file doing mass insert shuffled :( 22.53.43 # funman, low_light , maybe this isn't really i2c, I'll check the tea5767 datasheet if it supports something else besides i2c 22.54.31 # bertrik: I think it also uses a 3-wire bus 22.55.19 Quit Hillshum ("Ex-Chat") 22.56.10 # low_light, yes, I'm seeing that now too, let's not call it i2c in the source then :) 22.57.13 Join Hillshum [0] (n=hillshum@75-165-247-150.slkc.qwest.net) 22.57.25 # how do you stop playback on the fuze? 22.57.46 # Unplug the battery. 22.58.02 # Is there a way to make test_disk test the uSD? 22.58.15 # ok, how do normal people stop playback? power doesnt seem to do it 22.58.33 # JdGordon|: wait for the battery to die 22.58.43 # hold play maybe? or look in the source 22.58.43 Quit Zarggg (Connection reset by peer) 22.58.56 # JdGordon|: set repeat to off and make it run out of playlist items 22.58.57 # bertrik: but tea5767.c uses fmradio_i2c_read/write 22.59.30 # ah ok, this is probably the first time that a tea5767 is used with 3-wire instead of i2c 22.59.31 # gevaerts: the playlist is broken... i have to stop it to clear the problem 23.00.48 # * JdGordon| gives up shuffling his whole DAPs content and goes back to just a single folder 23.01.19 Quit BdN3504 ("CGI:IRC (EOF)") 23.02.28 Quit GeekShadow ("The cake is a lie !") 23.03.25 # low_light, can you put at least a big fat warning in the code about this inconsistency? 23.03.30 Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 23.04.19 # bertrik: sure :) 23.16.48 # Llorean: what was decided at devcon regarding releases? 23.17.35 # saratoga: Dunno? 23.17.57 Quit low_light () 23.17.58 # * bertrik can't remember 23.18.08 # saratoga: we agreed on the principle, the rest was a bit vague 23.18.21 # saratoga: there is a brief description on the devoconeuro2009 wiki page 23.18.42 # which translates to "sansa ams should get on the download page" for me 23.19.12 # ok 23.19.21 # funman: all of them? 23.19.24 # well i wrote up a proposal for that but haven't sent it to the list yet 23.19.34 # There's also the email discussion I started in july? 23.20.05 # gevaerts: i don't know what was the state of each target by that time 23.20.42 # in principle it sounds like most people agreed on having a 2 teer system for supported targets based on what I can find 23.20.58 # funman: the status at that time doesn't matter much now :) I mean, as far as I can see fuze and e200? are pretty stable, but is clip ood enough? 23.21.26 # as soon as the SD issue is fixed I'd say the Fuze and e200v2 can go 23.21.29 # clip is not good enough 23.21.44 # gevaerts: fuze and e200 are unstable when using µSD cards, and clip/m200v4/c200v2 are equally unstable when using playback (especially the c200v2 which lacks some buttons anyway) 23.21.50 # its only semiusable unless you stick to MOD files or something similar that never buffer 23.22.11 # funman: "µSD cards unstable" is something that can be documented easily 23.22.22 # true 23.22.29 # unstable playback is slightly harder to explain away 23.22.32 # provided you use some unicode medium :) 23.22.35 # the problem is that it overclocks the cards though, which is something thats fairly dirty 23.22.56 # in theory it could corrupt them or maybe even do damage (though that seems extremely unlikely) 23.23.11 # c200v2 buttons will probably work this weekend 23.23.30 # bertrik: but what about after that? 23.24.00 # bertrik: in my experience c200v2 is more unstable than clip/m200v4 because of a shorter audiobuffer (color LCD needs more space) 23.24.37 # You could trigger a bug in buffering.c when playing a file with album art associated (album art wouldn't fit in the buffer) 23.24.38 # funman, so do you think it's a fundamental problem? 23.25.11 # One needs to take a look at buffering.c and playback.c, I ran logf on my clip today but was too lazy to continue ... 23.25.22 # gevaerts, code will be committed to SVN and the buttons will keep on working after the weekend too 23.25.31 # I think the low audiobuffer size might trigger some corner case bug in these files 23.26.02 Part froggyman 23.26.03 Quit Hillshum (Read error: 60 (Operation timed out)) 23.26.16 # bertrik: ah, nice! :) 23.31.35 # funman: so maybe we shuold disable AA on low mem? 23.31.42 # to at least get around the problem? 23.31.59 # JdGordon|: i had a get around back then, but i wanted to read more buffering.c/playback.c first 23.32.12 # AA itself works fine 23.32.13 # the color screen will also be a problem, since it uses quite a bit of memory 23.32.25 # the underlying problem with buffering needs to be fixed 23.32.28 # funman: well if its AA we can blame Unhelpful :) 23.32.29 # 2MB jpegs are a bit of a problem though :) 23.32.40 # c200v2 doesn't have external DRAM, like the clip? 23.33.18 # i think the clipv1, c200v2 and m200v4 are all the same 23.34.52 # ignoring the fact AA hardly makes sense on the clip at all.... I wonder if it would be possible to convert the jpg to a preloaded bmp but on disk instead of in ram, then we could still display it on low mem targets 23.35.19 # bertrik: clip and c200v2 have 2MB external SDRAM 23.35.25 # like m200v4 23.35.52 # clipv2 has 8MB afaict (not deeply tested) 23.36.22 # funman, oh, I can't remember seeing external DRAM on Clip PCB scans 23.37.38 Quit Strife89 ("Going home.") 23.38.00 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.38.16 # it's not visible 23.38.21 Quit robin0800 (Remote closed the connection) 23.38.31 # perhaps inside the SanDisk chip, next to the AS3525? 23.39.30 # ok, I'd call that internal since it's not a separate chip, but I understand what you mean now 23.41.41 Quit xavieran (Read error: 104 (Connection reset by peer)) 23.41.42 # huh the mailing list really eats my posts 23.41.59 # saratoga: Supported v. Unsupported Builds? 23.42.00 # does it?☕ 23.42.13 # saratoga: It came through fine 23.42.16 # well on the website the text wraps oddly and some new lines are removed 23.42.18 # ok good 23.42.30 # ah yes, it does that 23.42.49 # or at least, something does 23.43.49 Quit bertrik ("De groeten") 23.53.54 Quit kkurbjun (Read error: 60 (Operation timed out)) 23.56.49 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk)