--- Log for 12.07.109 Server: simmons.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 1 month and 9 days ago 00.00.08 # gevaerts: Could you perhaps test on Video, mrobe100 and Clip? 00.00.19 # sure 00.00.20 # kugel: Yes, that's the idea 00.00.51 # For functions with previously saved r4..r12 *and* lr it was easy - just don't save r12 because it's scratch reg anyway 00.01.13 # But functions which didn't use all the regs needed some register rearrangement 00.01.25 # * kugel finds it confusing to read rl in code that doesn't use it as the lr 00.02.29 # Consistency - this way you'll see that something happens to the link register. It's just a preference though 00.03.17 # what speaks against keeping r11 and save this instead of lr? 00.03.35 # The way I did it saves an instruction 00.04.04 # If you save lr, you can pop it into pc together with restoring the other registers 00.04.33 # Basically, if you need a non-scratch reg you should *always* use lr first 00.05.22 # amiconn: that patch doesn't apply. It seems to be broken off halfway 00.06.35 # Oh? The patch has 1544 lines. All of them are shown in pastie... 00.06.59 # hm 00.07.43 # broken here too 00.07.48 # gevaerts: Pastie's "raw" or "download" swallows the last 3 lines 00.07.48 # http://pastie.org/542646 shows it fine, http://pastie.org/542646.txt (which is the way to get it raw) does not... 00.08.07 # blergh - and pastebion.ca doesn't werk atm 00.08.30 # did you really try pastebion? ;) 00.08.47 # * pixelma wonders what that has to do with a cinema 00.08.51 # no 00.09.10 # pastebin.com? 00.09.15 # same 00.09.35 # Weird - now the latter works 00.09.38 # * amiconn goes pasting 00.09.49 # appending the lines gives a failed hunk 00.09.54 Join matsl [0] (n=matsl@host-90-233-177-32.mobileonline.telia.com) 00.10.37 # http://rockbox.pastebin.com/m6fbc1707 00.11.07 Join Ubuntuxer [0] (n=johannes@dslb-088-077-002-163.pools.arcor-ip.net) 00.13.47 # Ubuntuxer: Hi. Since you committed Clix, I'm been meaning to ask if you can refer to FS tasks when you commit patches? Also, when you close a task as "accepted", can you mention the SVN revision it was committed as? 00.14.14 Join tessarakt [0] (n=jens@e180074117.adsl.alicedsl.de) 00.14.17 Join tessarakt2 [0] (n=jens@e180074117.adsl.alicedsl.de) 00.14.19 Quit tessarakt2 (Client Quit) 00.15.15 # Ubuntuxer: Also, looking at it now, I think you forgot to set svn:keywords on clix.c 00.15.27 # (see the UsingSVN wiki page) 00.15.34 # ok, I'll do it next time, sorry 00.15.47 # * amiconn is puzzled. He tested on c200 this afternoon and it worked. Now mpegplayer crashes... 00.19.48 # Ubuntuxer: also - since you committed chamges to the mazezam controls on some targets, it would be really nice if that couild be changed in the manual as well 00.20.39 # ok, I'll have a look... 00.20.39 # amiconn: stkov here 00.21.07 # target? 00.22.12 # fuze 00.22.33 # And in mpegplayer I guess? 00.22.36 # yea 00.22.42 # Also on ipod video 00.23.02 # Same thing I observe on the beast and c200. Weird 00.23.07 # * amiconn goes bug hunting 00.23.09 Quit ender` (" If I capture the hero's starship, I will keep it in the landing bay with the ramp down, only a few token guards on duty and") 00.24.23 Join fml [0] (n=4fd3df32@gateway/web/cgi-irc/labb.contactor.se/x-1aa21bda82715a91) 00.24.52 # In the manual, can all the entries in "features" be used as the switch for \opt and \nopt? 00.26.28 # For example, I see \opt{swcodec} in some places. I'll just try it out. 00.29.38 # fml: yes 00.30.35 Quit flydutch ("/* empty */") 00.32.20 Join funman [0] (n=fun@rockbox/developer/funman) 00.34.33 # svn is slow for me 00.35.05 # New commit by 03bertrik (r21792): S5L8700: fix buttons used in debug menu 00.36.43 Join Blue_Dude [0] (n=chatzill@12-189-93-2.att-inc.com) 00.37.17 # Aren't commits to the manual observed by the CIA? 00.38.13 # yes they are 00.38.27 # * funman kicks CIA-71 00.38.27 # ow 00.39.14 # funman: he-he, they should be fired. Mine slipped through! :-) 00.39.44 Quit AndyI (Read error: 60 (Operation timed out)) 00.40.47 # funman: I was wondering about your *patcher Makefile changes - doesn't the mkdir fail if the directory already exists? 00.41.15 Join mc2739_ [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 00.41.25 # funman: i.e. "mkdir -p" would be better? 00.41.57 Join AndyI [0] (i=AndyI@212.14.205.32) 00.42.17 Quit matsl (Read error: 110 (Connection timed out)) 00.43.01 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 00.44.50 # linuxstb: hum yes i didn't think of a previously existing directory (and i felt a bit akward of using mkdir in a makefile ..) 00.45.48 # so yes -p should be used (doesn't error if the directory already exists) 00.46.08 # I would also use "cp -p", but there's probably no good reason to (just personal preference) 00.47.02 # i have no problem with that, can you commit a fix? 00.47.02 Quit fml ("CGI:IRC (EOF)") 00.47.43 # For both mkdir and cp? 00.48.25 # yes 00.49.27 Quit mc2739 (Nick collision from services.) 00.49.28 Nick mc2739_ is now known as mc2739 (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 00.49.36 Join fml [0] (n=4fd3df32@gateway/web/cgi-irc/labb.contactor.se/x-9f04f5e5d3a04212) 00.50.18 # Hrm... After all the pitchscreen related commits I wonder whether it was worth it. The reason for my doubt is a high red delta. :-/ 00.50.25 # New commit by 03dave (r21793): Small tweaks to r21778/r21779 - use -p for both mkdir and cp commands in dmg creation rule 00.51.26 # fml: What actually changed? r10359 has lots of words to read... 00.51.45 # * linuxstb should probably just try it... 00.52.59 # unfortunately the commit message didn't have much to read, the FS task though 00.53.23 # linuxstb: 1) Correct display of the speed 2) Changing pitch in 0.1 semitone steps 3) Correct changing from % to semitones and back 4) Persisting the screen state (pitch changing mode) 00.54.40 # saratoga: test_fps/battery_bench with a slower pclk would be interesting now that data cache is enabled on Sansa AMS 00.55.28 # Maybe it's just a not optimal implementation. I didn't pay much attention to the bin size when I was looking at it, to be frank 00.55.32 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 00.56.15 *** Saving seen data "./dancer.seen" 00.56.25 # funman: I thought kugel said the tests of it were done with MMU enabled? 00.56.26 # gevaerts, kugel: The crash has nothing to do with my patch - svn crashes too 00.57.07 Quit tessarakt ("Client exiting") 00.57.10 # * amiconn suspects r21781 00.58.44 # saratoga: oh right, i'll look in the forum thread for the benches 00.59.15 # * amiconn wonders whether people actually test pontentially affected things before committing :\\ 00.59.25 Quit Ubuntuxer ("Leaving.") 01.00.35 # amiconn: what is the problem? 01.00.40 # wrong pitch 01.00.53 # funman: I still want to do more testing though with DMM instead of battery bench 01.01.03 # saratoga: got just a minute to chime in... On the battery benches I did the higher pclk configs performed significantly better, by 3 hrs or so 01.01.04 Join Ridayah_ [0] (n=ridayah@173-19-228-175.client.mchsi.com) 01.01.04 # The scale changed. Several plugins set pitch as well 01.01.22 # FlynDice: why is that? 01.01.43 # does higher pclk reduce boosting independently of everything else? 01.01.44 Join _0x90u[Sleep] [0] (n=00x90u@17-116.232.popsite.net) 01.01.59 # FlynDice: do you rememeber where your benches are (on flyspray?), i can't find them on the forum 01.02.13 # amiconn: oh! I didn't check the plugins. Do the set it to 100% and then restore? 01.02.16 # splitedit, video, wavplay, wavrecord, mpegplayer 01.02.30 # They just set it to 100%. No restore 01.02.41 # saratoga: a fact is that SDRAM clock frequency is equal to pclk 01.02.42 # I don't know... I tried what I thought would be the best power saver in 62/31 fastbus only and 248/62 sync bus beat it by 3 hours 01.02.49 # I'll go find it 01.02.53 # But they use the permille values, i.e. 1000. splitedit also sets 50% and 150% 01.02.58 # in theory we could have it twice faster but in practice rockbox didn't boot 01.03.03 Nick _0x90u[Sleep] is now known as _0x90u (n=00x90u@17-116.232.popsite.net) 01.03.56 # FlynDice: in svn we use fastbus clocking when unboosted 01.04.22 # saratoga: why do you prefer to use a DMM over a battery_bench? is it more precise? 01.04.30 # funman: it is 01.04.36 # plus it doesn't take 18 horus a test 01.04.37 # Yes but I changed it to fastbus only to test and see what I could get, was rather disapointed 01.04.40 # so I can do dozens of them a night 01.05.04 # what is 'fastbus only' ? 01.05.16 # plus I can do time resolved power measurements, so I can see how much power is used boosted, how much unboosted, how much playing mp3, how much paused, etc 01.05.59 # battery benches can be misleading because they average boosted and unboosted power together, so changes in boost ratio get conflated with changes in power consumption per clock 01.07.19 # i wonder though why changes in memory clock would have a big impact, particularly with mp3 I would expect us to be mostly running off of IRAM with little/no DRAM activity 01.07.47 Quit Ridayah (Read error: 110 (Connection timed out)) 01.08.07 # saratoga: here's my graphs post http://forums.rockbox.org/index.php?topic=14064.msg151734#msg151734 01.08.19 # i'm going to do boosted/unboosted measurements of power consumption using SVN, if someone wants to make other suggestions about what they want tested let me know 01.09.23 # can we lock the mem clock to 31MHz and try pclk at 31 and 62MHz ? that would be very interesting to me 01.09.44 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 01.09.52 # saratoga: I think the IRAM clock is pclk 01.10.16 # funman: for fastbus only I simply made the busmode stay as fastbus in the boosted state 01.10.22 # saratoga: the SDRAM clock can be equal to pclk or twice faster 01.10.23 # hmm so both get faster/slower 01.10.41 # amiconn: I have a patch: http://pastebin.ca/1492116 Could you have a quick look? I don't really know what the plugins do. Just set the pitch to 100/50/150%? 01.10.46 # FlynDice: so you used the same frequency for boosted cpu (i.e. no boosting) ? 01.10.56 # thats really undesirable, ideally we would lock IRAM at full speed even if the CPU goes lower then 60MHz 01.11.11 # the cpu frequency must be higher or equal to pclk 01.11.28 # funman: no I ran unboosted at 31 MHz fastbus and boosted at 62MHz fastbus 01.12.15 # New commit by 03amiconn (r21794): Fix plugins for the changed pitch scale from r21781 01.12.50 # gevaerts: Could you try again with latest svn + patch? Patch doesn't change... 01.13.45 # no more time for now! 01.15.08 # amiconn: ah, you were faster! But wouldn't it be better to work with the _100 value (like in my patch)? 01.15.15 # why? 01.16.03 # amiconn: the effect is the same, just the readability would be "better" IMO. 01.16.34 # Precision is technical term, whereas "_100" is a "semantical" value meaning 100% 01.17.16 # * amiconn thinks a single multiplication is more readable than using fractions 01.18.42 # amiconn: but it's hard to figure out what multiplication it should be. We probably have to introduce a macro for converting percents to the right value 01.19.28 # Bah, typical. Hung build and no Swede around 01.19.35 # New system isn't building either 01.19.45 # gevaerts: Have you looked at FS#4755? Any idea how committable (or not) it is? 01.20.33 # amiconn: ipod video seems to be fine 01.20.55 Quit fml ("CGI:IRC") 01.21.30 # funman: somone on ABI mentioned graphical corruption from time to time in MPEGplayer, not sure if you've heard of this before 01.21.42 # linuxstb: no. I happen to be subscribed to it, but I've never actually looked at the code 01.21.44 # on AMS of course 01.22.07 # saratoga: i have not heard of it, but i frequently see it on my fuze ;) 01.22.10 # linuxstb: IIRC Last year roolku told me that it needed cleanup 01.22.48 # I see mcuelenaere posted a "cleaned up" version 5 days ago... 01.22.49 # ok then 01.22.51 # saratoga: i am not sure if i mentioned this LCD corruption problem to kugel (I also saw it in plugins, not only mpegplayer) 01.23.43 # linuxstb: ah indeed. I do think that tools/converter is a bit too generic though 01.23.51 # now i hope we can put some light on what's wrong in the current SD driver 01.24.16 # gevaerts: Yes, and perhaps not for tools/ either. (if tools/ is "build tools") 01.24.19 # regarding voltage scaling or some new bug? 01.24.51 # saratoga: if you have an e200v2 could you have a look at fs#10413 ? 01.25.34 # saratoga, thoughts on the forum thread move and title edit? 01.25.37 # * linuxstb looks at the patch and sees "* Copyright by ???" in the first file... 01.25.40 # some users experiment deadlocks using current build (see http://forums.rockbox.org/index.php?topic=22137) 01.25.47 # linuxstb: also true. utils? 01.25.55 # that, and filesystem corruption 01.26.02 # gevaerts: Yes, I think so. 01.26.09 # Hmm, plus files #2 and #3 have no (C) holder... 01.26.52 # funman: sure but I didn't even realize we could flip the lcd on the e200v2 01.27.15 # * linuxstb decides to post a comment 01.27.25 # mc2739: you should shout about your work and not quietly post new patches to flyspray ;) 01.27.42 # soap: the one about the headphone jack? i dont' mind 01.28.00 # just saw you were reading the moved thread and was curious. 01.29.22 # funman: whats wrong with the driver now when its flipped? 01.29.34 # amiconn: mr100 seems fine as well 01.29.40 # saratoga: no idea i don't have an e200v2 01.29.51 # funman: It isn't that important a patch, not as important as other things that are being worked on 01.30.27 # mc2739: I'm trying mpegplayer now with the screen flipped and it seems to work without the patch 01.30.32 # what would it actually fix? 01.30.43 # oh the menu are upside down 01.30.48 # try pausing 01.30.56 # yes now i see 01.31.14 # i'll try it out later, i have to get back to work now 01.31.25 # the video content does not flip but the controls do 01.32.16 # funman: I think we all see the corruption from time to time 01.32.37 # mc2739: have you seen fs#10371 (recording on AMS) ? Perhaps I've missed something stupid .. 01.33.26 # kugel: i imagine it could be a race condition in the button/lcd synchronisation code, but i have nothing to back this feeling 01.34.04 # <_0x90u> Does anyone know if there is a simple custom bootloader for the STMP3500? So that I could possible load a different .sb if say the play button is pressed during startup. 01.34.12 # could be, but I can't see how 01.34.53 # kugel: funman: I don't think I have seen any corruption. Is it reproducible? 01.35.07 # no, it's random 01.35.12 # mc2739: it's much more frequent in mpegplayer though 01.35.16 # _0x90u: I dont' know that anyone has looked at the STMP chips very much 01.35.41 # funman: it surely is, it updates very frequently too 01.35.52 # if it's not on the e200v2, maybe it's some delay missing 01.36.20 # <_0x90u> saratoga: Ok, well I'm looking into it. Might be able to shead some light on the subject of the STMP. 01.36.49 # is there a way to run code on any player based on it? 01.37.12 # funman: I have seen FS10371 but have not had time to try it yet 01.37.28 # mc2739: well i think there is nothing to try, only read :/ 01.38.03 # how much work would it be to merge e200v2 and fuze lcd drivers ? 01.39.05 # gevaerts: Clip is okay as well? 01.40.13 # amiconn: no, but that's apparently due to a bad bootloader (plain svn also didn't work, but it does now after installing a new bootloader). I'll know more soon 01.41.11 # mc2739: is the e200v2 battery the same than fuze battery ? I see that powermgmt-e200v2.c was copied from e200v1 01.42.19 # IIRC its similar but not exactly the same 01.42.29 # amiconn: looks fine as well 01.42.36 # since the e200v2 one is a user replaceable sandisk battery while the fuze has an OEM one soldered in 01.43.05 # funman: I do not think that the battery is the same 01.43.11 # gevaerts: Thanks for testing! 01.43.49 # New commit by 03amiconn (r21795): ARM asm LCD and ATA driver functions: Don't save r12 as it is a scratch reg. Saves a bit of stack and execution time. 01.44.50 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 01.47.12 # Bleh, svn is borked 01.49.29 Join Ox9OU [0] (n=00x90u@30-193.232.popsite.net) 01.49.50 Quit rasher ("leaving") 01.50.04 # someone around with a c200 at hand (not a too patched build)? 01.50.13 # yes 01.51.01 # could you try whether bubbles crashes for you as soon as the bubble should be shot? 01.51.22 Quit funman ("free(random());") 01.53.04 Quit _0x90u (Read error: 60 (Operation timed out)) 01.53.58 # pixelma: I finished the first level, but this is about 20 revisions behind. I'll try a current build as soon as it's built 01.54.40 # mine's running r21778 now but with kugel's pla_rework patch 01.54.57 # and bubbles uses PLA 01.55.10 # 21776 here 01.56.12 # is there a minimum required time that needs to be possible to set with timer_set? 01.56.39 # if I implement it in a simple way, the timer overflow after 83 ms 01.58.12 # pixelma: latest svn also works 01.59.01 # ok, seems to be patch related then. Thanks :) 02.00.08 # weird 02.01.08 # and also - teru is right that the repeat actions don't work correctly (observerd in robotfindskitten as he said and aldo aiming left/right in bubbles) 02.01.51 # How can my patch make bubble crash?! 02.02.42 # metronome seems to have lost the "tap" but now has the "play" instead, svn is the other way round 02.02.43 # that's the only patch you have applied? 02.03.39 # well, other than that only the HID disable and I have a few changes in the manual... 02.04.02 # HID disable really shouldn't change anything at all for plugins 02.04.26 # I try an update 02.04.26 # pixelma: play seems to more useful than tap anyway :) 02.05.35 # * gevaerts thinks that metronome should use the volume buttons for volume on the gigabeat f 02.06.49 # pixelma: tap could be long select 02.07.07 # kugel: long? 02.07.07 # how would you tap with "long select"? 02.07.17 # very slowly ... :) 02.07.29 # no idea, that's what the code says :) 02.07.33 # especially since short select changes play/tap mode 02.07.44 # * gevaerts wonders if this is an indication of what sort of music kugel likes :) 02.07.47 # I admit it doesn't make sense 02.08.57 # oh, then it works (but changes play/tap mode at the same time an indicator that it's not "guarded" by button release events, probably= 02.09.07 # although not really usable 02.09.57 # * gevaerts thinks that metronome is just weird 02.10.07 # in general? 02.10.13 # "Rec to SYNC" on gigabeat f. 02.10.26 # * pixelma thinks metronome should use vol up/down for changing the volume on the c200 too, then Play (Up) would be free for "play" and Select 02.10.28 # that button doesn't exist 02.10.32 # for tap 02.10.38 # it says that on any target, but Rec only does something on the irivers 02.11.29 # gevaerts: I've been told that this is a feature that basically only works on the H100 (H300 too?) and just wasn't ported correctly - or taken out from the other targets 02.11.52 # indeed. The code has proper #ifdefs everywhere except for the text 02.13.36 # What is this strange sorting on new.cgi? 02.13.45 # and why is the fuze not on the tabe 02.13.58 # rrr... I would like to update but nothing happens (and seeing the trouble I had with svn.rockbox.org earlier in the evening) :\ 02.14.04 # ah found it 02.14.43 # pixelma: I had problems an hour ago as well 02.15.47 # amiconn: still stokv 02.15.50 # stkov* 02.16.28 # oh, wait 02.16.35 # grml 02.18.05 # svn.rockbox.org lagging.. 02.18.27 # or just git-svn? 02.18.43 # no, read a few lines up ;) 02.19.05 # yea, but I could access the site just fine 02.19.35 # ok, it's definitely svn.rockbox.org 02.20.50 # PLA doesn't seem to be a good choice for metronome 02.20.54 # seems like it is impossible for me to update now - I got a nice "data abort" in bubbles though. Happens when the bubble has to be shot (also after the timeout without shooting manually) 02.21.59 # quite a "low" address, 00001140 (0) 02.22.37 # noob question.. Is there a decomplier/complier for the STMP? 02.22.47 # what CPU does it have? 02.22.58 # if ARM, then we have compilers 02.23.22 # No idea. I haven't figured that part out yet. 02.23.36 # well then no sense asking about compilers until you know the CPU 02.23.39 # amiconn: shouldn't you've updated other langs too? 02.24.02 # they weren't in the initial patch 02.24.39 # I'm trying to find the CPU arch. for the STMP3400 02.24.47 # semitone was added? I seem to recal it exists already 02.25.37 # 0x90U: the rockbox wiki says Motorola DSP56004. 02.26.49 # Ok thanks bro 02.26.52 # according to our wiki, there is no compiler 02.27.10 # what about ASM? 02.27.33 # theres an assembler 02.27.39 # why don't you read the wiki entry? 02.27.44 # new pitchscreen is weird 02.28.01 # Ok nvm. I found the DSP56000 Software Development Tools. Sorry 02.28.06 # kugel: "#ifdef HAEV_SCROLLWHEEL" in bubbles.c? Could this be problematic? 02.28.17 # yes it could 02.29.45 # and could you change the comment below, while at it? Not all sansas have a scrollwheel ;) 02.29.49 # "Tempo" definitely needs renaming now in the german translation 02.30.55 # yes, the problem is that it is the most descriptive of what "pitch" does on hwcodec 02.31.15 # what does it there? 02.32.43 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.32.54 # well, it changes pitch by playing the data faster or slower (so not independently) 02.33.07 # up/down indicatins making playback faster/slower. But up and down actually do nothing, and the scrollwheel doesn't make anything faster or slower eaither 02.33.28 # pixelma: so what it did on swcodec too before timestrech? 02.33.33 # yes 02.34.19 # it doesn't really indicate changing tones 02.35.50 Join Bishop [0] (i=Bishop@c-0b27e353.713-1-64736c10.cust.bredbandsbolaget.se) 02.35.54 # hi 02.36.39 # and it's just wrong on swcodec now 02.37.09 # Which OSS replacements exists for zen/muvo/nomad? 02.39.07 # pixelma: hm, the old Pitch is now Rate, does hwcodec still show Pitch? 02.40.50 # it's buggy also :( 02.41.06 # haven't checked yet. Fixing the typo in the new bubbles.c didn't help fixing the crash 02.41.15 Quit bertrik (Read error: 113 (No route to host)) 02.41.48 # * kugel can't really believe the patch is causing this 02.42.20 # Bishop: AFAIK, none... Although some work has been done to port Rockbox to some Zens. 02.43.37 # oh, I think I'm seeing the problem 02.44.17 # pixelma: try swapping the mapping for BUBBLES_START and BUBBLES_SELECT 02.44.36 # ah no wait 02.46.20 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 02.46.48 # ok rockbox iw reporting 1 ammount of freespace but windows is showing a different ammount 02.47.02 # pixelma: try this (incremental patch, use with p1): http://pastie.org/542745 02.47.20 # rockbox shows 322MB free but windows only shows 215MB free 02.52.03 Quit n00b81 (Read error: 110 (Connection timed out)) 02.53.15 Join n00b81 [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 02.55.08 # what could cause this? 02.55.46 # r0b-: run chkdsk on it 02.56.10 # whats the command 02.56.19 *** Saving seen data "./dancer.seen" 02.56.37 # chkdisk 02.56.40 # i run windows 02.57.07 # just check it for errors in, the properties of that drive 02.58.22 # r0b-: before doing that - did you trigger an update in the Rockbox Info screen? Button depending on target 02.58.35 # ? 02.59.34 Join GreatBeaver [0] (n=chatzill@c-71-59-18-236.hsd1.ga.comcast.net) 02.59.34 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 02.59.38 # hi 03.00.03 # r0b-: when you went to the Rockbox Info screen and it showed you the stats (322MB), you can also press a button to let it update (Select on many players) 03.00.21 # i used the Stats app 03.01.20 # r0b-: Then try the Rockbox info screen... 03.01.42 # ok there we go 03.01.46 # now its right 03.01.49 # the "Stats app"? Do you mean the stats plugin`I'm wondering because I can't see info on free disk space there 03.02.26 # i wasnt thinking 03.02.26 # r0b-: The problem is that there is a bit of info stored on the disk called (I think) "FSINFO", which Rockbox uses and keeps up to date, but Windows doesn't. 03.02.49 Join Biatch [0] (i=Bishop@c-0b27e353.713-1-64736c10.cust.bredbandsbolaget.se) 03.03.46 # Which player hardware is most supported? Is there a (de facto) primary development platform? 03.04.22 # Biatch: Not really, no. 03.04.47 # (anything but sansa's) 03.04.47 # :P 03.05.04 # Biatch: Generally, the longer the hardware has been supported by Rockbox, the better the support (but that's a generalisation) 03.05.05 # r0b-: my e260 v1 works just fine :P 03.05.27 # i like my E250 v1 03.05.46 # newegg's got recert ones for $35ish I think 03.05.49 # If I would to purchase a new player and flashing with rockbox, which should i buy? (price no matter) 03.06.12 # "new" as in fresh off the factory floor with no previous owners? 03.06.14 # You can't buy a new player and install Rockbox... 03.06.49 # new, yes completely new manufactured. 03.07.04 # if you want alot of sttuff i like my Sansa E250v1 refurb 03.07.31 # Why cant i install rockbox on a new player? 03.07.47 # new players have encrypted firmware 03.07.51 # See the list of hardware Rockbox supports on the front page of our website... 03.08.02 # And then compare with what you can buy new. 03.08.22 # Is there any player currently selling without encrypted firmware? 03.08.25 # r0b-: That's not true at all... 03.08.25 # honestly the older players ROCK! 03.08.33 # r0b-, _few_ new players have encrypted firmware. 03.08.54 # sorry not thinking 03.09.01 Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") 03.09.07 Quit tvelocity (Read error: 110 (Connection timed out)) 03.09.15 # zune is out i guess. lol. 03.09.22 # Biatch: Simply that porting Rockbox to new devices generally takes longer than the lifetime of that device. 03.09.29 Quit kugel (Remote closed the connection) 03.09.57 # isn't the zune made by microsoft? 03.09.59 # honestly the older players if there good they will last longer then a modern player 03.10.05 # yes 03.10.31 # so why would you want to buy a microsoft product just to put open source firmware on it? :P 03.11.00 # i dont. want to. 03.11.13 # buy it. 03.11.53 Join tvelocity [0] (n=tony@athedsl-4488555.home.otenet.gr) 03.12.03 Quit Bishop () 03.12.05 # i went with my mp3 player because it can run rockbox 03.12.21 # and just for the bragging rights that i can play doom and non of my friends can on there mp3 players 03.13.12 # their 03.13.23 # none 03.14.36 # :| 03.15.11 # hoenestly being able to play doom while running around is pretty interesting 03.15.36 # now if the controls just weren't quite as awkward 03.15.57 Join mc2739_ [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 03.16.11 Quit mc2739 (Nick collision from services.) 03.16.13 Nick mc2739_ is now known as mc2739 (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) 03.16.21 # i got the controls a little easier 03.17.28 # but even using the "Rotate Screen" option still is a little odd 03.17.44 # i think i know how i can make the game easier on me 03.17.45 # bbl 03.17.52 # getting it set up so the sansa's scroll could be used for turning would be nice (would probably need some acceleration) 03.31.02 Quit Thundercloud (Remote closed the connection) 03.34.05 Quit Blue_Dude (Read error: 110 (Connection timed out)) 03.35.23 Join Blue_Dude [0] (n=chatzill@12-189-93-2.att-inc.com) 03.38.50 Join daurnimator [0] (n=daurnima@unaffiliated/daurnimator) 03.41.26 Quit gevaerts (Nick collision from services.) 03.41.38 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 03.47.23 Quit evilnick (simmons.freenode.net irc.freenode.net) 03.47.23 NSplit simmons.freenode.net irc.freenode.net 03.47.23 Quit saratoga (simmons.freenode.net irc.freenode.net) 03.56.06 # dz thats gangerous thinking 03.59.16 # dz you aorund 04.04.06 # yeah 04.04.59 # if there was a way to map to the reverse scrollwheel motion it would work 04.05.57 # but as you cant map the game buttons to Button Off 04.05.58 # it wont work 04.06.27 # yeah 04.06.47 # some of the bindings for the sansa are odd, such as 'record' actually being submenu 04.06.57 # yea i know 04.07.15 # if i had the crap to compile it properly id change that :P 04.07.29 # I've got a toolchain set up 04.07.44 # is it able to run in windows? 04.07.50 # although I can't guarantee it'll work properly, since it's with gcc-4.3 04.08.13 # no, I run linux at home 04.08.15 # tell me what i need 04.08.23 # i only got CYGWIN or a VM 04.08.25 Quit Biatch () 04.08.41 # not sure for windows 04.09.05 # well what tools do i need using Linux? 04.09.17 # but you can feed me patches (or probably preferably post them on flyspray) 04.09.38 # you need arm-elf-gcc and friends in binutils 04.09.45 # there's a shell script to set it up on the wiki somewhere 04.09.49 # well dz i havent really learned full C 04.10.00 # nor have I 04.11.21 # if I get adventurous tomorrow I might try to fix that backlight flickering bug (tried poking around at it a while ago but couldn't quite wrap my head around the code) 04.12.35 # could you try to get scrolling working in the dictionary? 04.12.38 # dict plugin 04.20.46 NHeal (timeout) simmons.freenode.net irc.freenode.net 04.21.02 Quit Lss__ (Read error: 104 (Connection reset by peer)) 04.31.40 Quit fdinel (Read error: 104 (Connection reset by peer)) 04.34.02 Quit tvelocity (Remote closed the connection) 04.45.48 # FS#10430 updated with new asmdefs mechanism for handling C struct sizes and offsets in asm... comments welcome, especially from anybody familiar with the build system or asm. i also tweaked tools/addtargetdir.pl a bit to prefix all headers which are not found during deps with the build dir, since the asmdef.h files will need this as the existing sysfont.h does. 04.55.42 Join kamlurker [0] (n=chatzill@user-142gr2b.cable.mindspring.com) 04.55.45 # strafing/sidestepping needs to be easier in doom 04.55.53 # s/easier/possible/ 04.56.20 *** Saving seen data "./dancer.seen" 04.56.21 # (while still being able to turn and aim) 04.57.34 # I'd be happy with being able to both turn and shoot and turn and move forward at the same time 04.58.02 # which is rather difficult on the e200 due to the raised scrollwheel 05.02.28 Quit sbhsu (Read error: 60 (Operation timed out)) 05.02.34 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 05.03.40 # * Dhraakellian has a fuze, so yarr 05.04.06 Quit martian67 (Read error: 60 (Operation timed out)) 05.04.17 # same number of buttons, really, but power is less convenient to hit (well, slide) than record 05.05.07 # otherwise, though, the Fuze controls are much nicer, so if they could be properly mapped... 05.11.25 # does Rockbox currently support audio playback during fast-forward? 05.14.00 # no 05.15.03 # okay. thanks. 05.15.22 # Dhraakellian: just add mouse/keyboard support for targets with usb host hardware. ;) 05.16.11 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 05.18.44 Quit r0b- (Read error: 110 (Connection timed out)) 05.22.52 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 05.25.43 Quit BHSPitLappy (Read error: 60 (Operation timed out)) 05.26.11 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 05.27.19 Quit n00b81 ("Leaving") 05.32.34 Quit efyx_ (Remote closed the connection) 05.37.50 # dz? 05.39.21 Quit martian67_ (Read error: 60 (Operation timed out)) 05.40.01 Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 05.41.14 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 05.42.08 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 05.50.10 Quit sbhsu (Read error: 110 (Connection timed out)) 06.07.19 Join EpicReviews [0] (n=Lyle@pool-71-177-61-16.lsanca.btas.verizon.net) 06.07.41 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 06.08.05 # if I didn't like RockBox, could I use the Sansa Firmware Upgrader to revert back to the default firmware? 06.11.36 Quit sbhsu_ (Read error: 60 (Operation timed out)) 06.11.56 Join legendarymidget [0] (n=79dc436b@gateway/web/cgi-irc/labb.contactor.se/x-1fbf4ebde7e65a75) 06.13.10 Quit legendarymidget (Client Quit) 06.13.19 Join legendarymidget [0] (n=79dc436b@gateway/web/cgi-irc/labb.contactor.se/x-807aea6e05c506d3) 06.13.39 # hi legendarymidget 06.13.47 # let's carry out a conversation here 06.13.55 # EpicReviews, RBUtil has an uninstall function. 06.14.03 # EpicReviews: You could use rb-util to uninstall Rockbox 06.14.07 # ok 06.14.14 # cool 06.14.31 Quit legendarymidget (Client Quit) 06.14.48 Part EpicReviews 06.17.50 Quit GreatBeaver ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 06.18.05 Join faemir [0] (n=faemir@cpc2-cmbg2-0-0-cust30.cmbg.cable.ntl.com) 06.21.37 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 06.24.30 Quit evilnick_home1 (Read error: 113 (No route to host)) 06.30.05 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 06.30.08 Quit Ox9OU () 06.30.59 Quit m67_l3 (SendQ exceeded) 06.31.33 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 06.38.01 Quit martian67_ (Read error: 110 (Connection timed out)) 06.45.19 Join EpicReviews [0] (n=Lyle@pool-71-177-61-16.lsanca.btas.verizon.net) 06.45.56 # does rockbox only support the v1 series of Sansa? will this work on v2? 06.47.57 Join ReKleSS [0] (n=ReKleSS@d58-110-125-63.sbr6.nsw.optusnet.com.au) 06.48.17 # EpicReviews, only the v1's but the v2 aka ams sansas is being worked on 06.48.25 # :'( 06.48.43 # is there like a daily build that would work? 06.50.16 # nope.. the only way is build it yourself 06.50.33 # ok I'm hopeless there lol 06.50.44 # well is there like a newsletter I can sign up for? 06.50.59 # so I can know when it come s out? 06.51.01 # *comes 06.52.21 # you can look at the mailing list or keep an eye on the rockbox site 06.53.24 # well I'll just hopefully find it later 06.53.30 # when it comes out... if ever 06.53.56 Quit faemir (Remote closed the connection) 06.55.07 # It's kinda funny, I love Linux, but I really like the interface of Windows Media Player, and it amazes me that no one's made a look-alike media player/manager 06.56.24 *** Saving seen data "./dancer.seen" 06.56.29 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 06.56.47 # that is getting off-topic for your info.. you can read the guidelines 06.57.20 # ok :\ not a fun room I see 06.57.23 Part EpicReviews 06.58.58 Quit kamlurker ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060310]") 06.59.53 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 07.00.45 Quit martian67_ (SendQ exceeded) 07.01.27 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 07.04.04 Join sbhsu_ [0] (n=a6530466@Zion.dorm.au.edu.tw) 07.04.37 Quit sbhsu (Read error: 101 (Network is unreachable)) 07.08.50 Quit m67_l3 (Read error: 110 (Connection timed out)) 07.15.12 Join martian67 [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) 07.25.09 Quit martian67_ (Read error: 110 (Connection timed out)) 07.28.23 Quit martian67 (Read error: 54 (Connection reset by peer)) 07.29.03 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 07.35.03 Quit amiconn (Nick collision from services.) 07.35.07 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 07.35.16 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 07.35.22 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 07.35.22 Quit pixelma (Nick collision from services.) 07.35.40 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 07.46.34 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 08.05.29 Quit Horscht (Read error: 110 (Connection timed out)) 08.09.54 Quit evilnick_home (Read error: 104 (Connection reset by peer)) 08.10.59 Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 08.46.23 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 08.51.16 Join Rob2223 [0] (n=Miranda@p4FDCF677.dip.t-dialin.net) 08.56.26 *** Saving seen data "./dancer.seen" 09.09.01 Quit Rob2222 (Read error: 110 (Connection timed out)) 09.10.11 Part toffe82 09.21.59 Quit domonoky (Read error: 104 (Connection reset by peer)) 09.41.09 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.06.02 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 10.07.53 # I'm looking into a way of implementing timer-s5l8700.c for hardware that has a timer of only 16 bits 10.07.55 Quit n17ikh () 10.09.03 # there is a clock selection register (/2, /4, /16 and /512) , a prescaler register and a count register 10.12.55 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 10.18.10 Quit flydutch ("/* empty */") 10.26.19 Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) 10.38.04 # I think I got it (and not too complex) 10.40.39 # bertrik: other targets have 32 bits? 10.40.49 # * pixelma wonders about the one change (in the diff) by fml in the manual (the simplify conditions one) 10.41.26 # markun, yes, the other timer drivers I've seen so far have 32 bits indeed 10.43.50 # the prescaler can go up to 1/1024 (10 bits range), the clock select can go to 1/64 (5 bits) and the timer itself gives me 16 bit range, for a total of 31-bit range 10.43.58 # so that's OK I think 10.45.43 # I looked a bit into the clock frequencies for boosting. I think a good and simple start would be to use peripheral clock PCLK=50 MHz and use processor clock FCLK = 50 MHz / 200 MHz for normal / boosted 10.46.15 # As far as I can tell, we can toggle between unboosted/boosted CPU by setting a single bit somewhere 10.48.24 # bertrik: don't know if it's possible for you to do some measurements to see how much current the meizu draws boosted and unboosted, on the gigabeat for example it didn't make any difference. 10.49.07 # wow 10.49.26 # also a samsung chip 10.50.02 # I think the power controller automatically switches to USB power when plugged in and I can measure USB current. 10.51.15 # fml: (I know he reads logs) - why did you change the "masf" opt to an "swcodec" nopt? Usually opts are preferable over nopt and this way it's a bit more accurate... masf will also exclude it from the Player (although not necessary since it's already put inside a pitchscreen target only section). The "masf" also comes from features.txt. 10.51.32 Join petur [50] (n=petur@rockbox/developer/petur) 10.51.47 # I have a hard time believing it really doesn't make a difference, or maybe we're not doing something right then 10.51.53 # the only thing is that it is not as descriptive 10.52.44 # * amiconn summons Bagder or Zagor 10.55.03 Join GodEater_ [0] (n=godeater@rockbox/staff/GodEater) 10.55.51 # bertrik, markun: The sh1 timers are also just 16 bit with prescaler (/1.../256 in powers of two). 10.56.28 *** Saving seen data "./dancer.seen" 10.58.54 Join borris1 [0] (n=Luke@121-73-226-251.broadband.telstraclear.net) 10.59.14 # fml: there also is the possibilty to use an "hwcodec" opt 11.01.13 Join kugel [0] (n=kugel@rockbox/developer/kugel) 11.01.36 Join matsl [0] (n=matsl@host-90-233-177-32.mobileonline.telia.com) 11.02.24 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 11.04.11 # New commit by 03Ubuntuxer (r21796): set missing svn keywords 11.04.28 Quit GodEater_ (Remote closed the connection) 11.07.20 Quit BHSPitLappy ("Ex-Chat") 11.14.38 Quit martian67 (Success) 11.14.45 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 11.15.31 Quit m67_l3 (SendQ exceeded) 11.15.46 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 11.15.57 # amiconn: you called? 11.16.56 # New commit by 03kugel (r21797): Remove svn:executable from these files. 11.17.03 # "Build should have been done 629m ago...." 11.17.13 # And several commits are not on the frontpage 11.17.16 # amiconn: ah 11.17.50 # indeed. odd. 11.18.27 # looks like one of bagder's cronjobs is broken 11.23.10 Join robin0800 [0] (n=robin080@general-kt-199.t-mobile.co.uk) 11.23.49 Quit martian67_ (Read error: 110 (Connection timed out)) 11.25.08 Join m67_l3 [0] (n=martian6@about/linux/regular/martian67) 11.27.00 # http://forums.rockbox.org/index.php?topic=21696.0 am Iright in thinking WMP only syncs in MTP mode and this is causing music not to show in rockbox but perhaps the database can read it if player is back in MSC mode? 11.27.42 # meh, I broke ping again... 11.28.53 # Zagor: Perhaps repo locked or some 'svn up' got stuck? 11.29.06 # svn.rockbox.org was *extremely* slow last night 11.29.17 # I had several occasions of hung 'svn up' 11.30.02 # yeah but you regularly have problems with our servers when others don't so I rather suspect network issues 11.30.32 # Others reported slowness too - see backlog 11.32.37 # well, it has load 0.23 now so obviously that isn't the problem 11.32.40 # robin0800: no, you're wrong. WMP can also sync in MSC mode 11.33.03 Quit at0m (Read error: 104 (Connection reset by peer)) 11.33.13 Join at0m [0] (n=at0m@94-225-90-23.access.telenet.be) 11.33.52 # robin0800: you're in windows now? 11.34.19 # kugel: in that case would it still be in a hidden (burried) directory? 11.35.37 # /music ? I don't know if WMP hides it, but the OF on sansa does 11.36.20 # Zagor: Probably not now, but it seems that once svn gets stuck, it won't continue even if the reason for getting stuck is gone 11.36.41 Join Ubuntuxer [0] (n=johannes@dslb-094-221-090-006.pools.arcor-ip.net) 11.36.41 # It may even need a kill -9 followed by svn cleanup 11.36.46 # I just did a manual svn up, and it's not stuck 11.36.52 # ok 11.37.07 # the update has simply not ran for some reason 11.37.39 # kugel: I don't mean hidden attribute, I know about that. I mean is it in the same place as it would be for mtp, a directory with an essentially random name and unrecognizable filenames 11.37.44 # I can't set the svn keywords, it doesn't work. 11.38.05 # svn pset svn:keywords "ubuntuxer Id 2009-07-12 17:42:37Z 21720" apps/plugins/clix.c 11.41.06 # robin0800: but files put on the Sansa in MTP mode won't show up in Rockbox's database (so never should have there though) 11.41.31 # tmzt, no i'm out of the house and on a laptop with linux 11.41.35 # should have been 11.42.46 # okay 11.42.50 # Zagor: svn was slow for quite a few people last night (including kugel and me, should be in the logs) 11.43.42 # pixelma, the post says automatic sync in WMP is that possible in MSC mode? 11.43.47 # New commit by 03kugel (r21798): Correct svn:keywords and svn:eol-style on a few more files. 11.44.26 # tmzt: no. 11.44.37 # robin0800: never really used WMP so can't tell (just for the one try) 11.45.09 # pixelma, I'll check tomorrow 11.45.14 # I used it many month ago, but it worked 11.46.29 # amiconn: I'm still getting stkov on my fuze 11.46.36 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 11.46.45 # Ubuntuxer: you set the keywords "Author Id Date Revision" (as an example), the data will be filled out with Ubuntuxer etc, 11.46.55 # by svn for you 11.47.11 # kugel: stkov? 11.47.20 # I just filled out with "Author Date Id Revision" as the apps/ files have this 11.47.33 # I don't know if it matters 11.48.17 # well the actual keywords and the order was made up by me now, off the top of my head 11.48.53 # Ubuntuxer: "svn propset svn:keywords "Author Date Id Revision" apps/plugins/clix.c" 11.49.06 # pixelma: You quoted the same as the UsingSVN wiki page... But I don't think it matters. 11.49.07 # ah, ok thanks 11.49.25 Join QncOPFGl [0] (n=michi@g224203178.adsl.alicedsl.de) 11.49.34 # Ubuntuxer: you can look at how the other files do it - with proplist (or plist prbably). I use it with -v for a bit more verbosity 11.49.59 # Ubuntuxer: I would use svn pset svn:keywords "Author Id Date Revision" apps/plugins/clix.c - that's what the UsingSVN wiki page says to use. 11.51.14 # New commit by 03Ubuntuxer (r21799): set missing svn keywords to clix 11.51.41 # thank you for your help linuxstb! 11.51.43 Join fml [0] (n=4fd3c6a6@gateway/web/cgi-irc/labb.contactor.se/x-8bdd85bea75e3f1c) 11.51.45 Quit matsl (Remote closed the connection) 11.51.53 # linuxstb: I just changed 126files in firmware/ to "Author Id Date Revision" because all apps/* files use it 11.52.12 # to "Author Date Id Revision" I mean 11.52.22 # kugel: Bah... 11.52.55 # we should rather change UsingSVN 11.52.56 Quit m67_l3 (SendQ exceeded) 11.53.16 # kugel: What about all the other files though? 11.53.30 # is the order really important? 11.53.39 # pixelma: hello! Yes, that was my reasoning when changing the condition in the manual. The whole pitch screen related block is protected by "pitchscreen". And then, I think, all the devices can be diffrentiated by the "swcodec" feature which gives us two disjoint sets. Looking at "masf" could potentially give weird results. 11.53.40 # I don't, I don't think it's very important to change those 11.53.48 # Could it be that the plugin maze doesn't have a manual? 11.54.26 # fml: nopt is a custom hack though and sometimes tends to add unwanted newlines or spaces 11.54.49 # A note for all: since the size delta of the pitch scree was so big I intend to look into it and, if I find something, rework parts of it to reduce the size. But should I revert the whole patch now? 11.55.26 # fml: the new pitchscreen is strange 11.55.50 # pixelma: ideally, I'd have only one table with some \opts / \nopts inside. But that would be too much hacking and hard to read. Hence I left two tables. 11.56.04 # it resets values if you change the "pages", but only if you aren't doing it quickly, but then it also has strange values if you go on the same page again 11.56.42 # the new icons are superfluous 11.56.59 # kugel: in what regard? 11.57.20 # fml: the button tables need a rework in general to become more readable. Reminds me that I wanted to put a proposal on the wiki page explaining the style (I think it was LatexGuidelines are so) 11.57.26 # and I bet many languages translated "pitch" with "speed", they're all totally wrong now 11.57.48 # though, that's not you fault of course 11.57.57 # that can only be done bit by bit though I believe 11.58.21 # fml: the new icons? well, theres already a << icon, now there are two << icons next to each other 12.00.00 # fml: and by the way - when reading the diff, I first thought that by using \nopt{swcodec} this part would show up in the Player manual now because the surrounding pitchscreen opt is a bit away from it (just saying that different people read things differently) 12.02.49 Quit Zagor ("Leaving") 12.03.21 # kugel: I agree. The new icons should indicate that time stretch mode is active. But it's already obvious since there are two values displayed. Or are there daps that allow timestretch but have very small screens? 12.03.54 # the Clip has a tiny screen 12.04.02 # how does that matter? 12.04.05 # and the m200 12.04.15 # there are 2 icons on the left and 2 icons on the right 12.04.29 # 1 per side is totally enough 12.04.55 # * pixelma bites the bullet and takes the 5 minutes to install a new build on the Ondio to see if the new pitchscreen actually works 12.04.55 # kugel: I know. See above for the reason. But if the two values are shown on all platforms we can eliminate the second icon pair. 12.05.28 # I don't understand that 12.05.45 # you change pitch with up/down and speed with left/right, don't you? 12.05.47 # I wonder if it has been tested on hwcodec at all before (except compiling)? 12.06.41 # pixelma: not by me, no. 12.07.20 # Why do you need 2 icons on the left the left button is only doing 1 thing? 12.07.55 # kugel: to indicate the mode 12.08.09 # uh 12.08.13 # kugel: (rate vs. pitch/speed) 12.08.17 # it doesn't indicate the mode at all to me 12.09.06 # But the two displayed values already do it. The question is whether all platforms show two values. 12.09.26 # The icons are still a bad indicator 12.09.57 # A page counter at the top left makes more sense (ie. showing 1/4, 2/4 etc) 12.14.12 Join n17ikh [0] (n=n17ikh@c-68-59-19-150.hsd1.sc.comcast.net) 12.14.31 # hrmm... the Ondio daily manuals is broken though 12.15.26 # and some of the others - Ipod Video for example 12.16.53 # the ones that don't have a shortcut to the pitchscreen from the WPS and access it from the WPS context menu... 12.17.28 # they break in the WPS button table since \ActionWpsPitchScreen isn't defined 12.18.10 # fml: ^ 12.18.22 # pixelma: yes I'm looking into it 12.18.48 # the opt list was there for a reason 12.19.26 # I think I did everything right, but the s5l8700 still count 2x faster than expected 12.20.04 Join _zic [0] (n=user@83-156-253-6.rev.libertysurf.net) 12.20.29 # pixelma: yes, now I understand. 12.21.32 # is there a hanging build in the table for others too? I mean the one with the "old" system 12.22.09 # there's something borked, my commit also doesn't show on the front page 12.22.27 # "Build should have been done 695m 7s ago, at 00:46:53" 12.22.39 Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) 12.25.07 Part borris1 12.26.14 # New commit by 03alle (r21800): Fix the manuals (the problem was introduced in r21791): some players do not have a button to go from WPS to the pitch screen 12.26.50 # fml: the new pitchscreen seem to work on my Ondio, just that the center viewport is a bit big and cuts off the ones above and below (even looks like overlapping but doesn't cause update problems, "just" that you can't see the options in these two) 12.27.13 # can't see them completely, I mean 12.27.38 # pixelma: does it have the timestretch feature? 12.27.45 # no 12.28.13 # pixelma: is it properly centered vertically? I.e. is it exactly in the middle of the screen? 12.28.30 # pixelma: I mean the visible text 12.28.36 # amiconn: nevermind, working now 12.29.33 # the Ondio is hwcodec, but the Clip's screen is almost equally small (128x64 for the latter 112x64) the former), I use a 9-point font though which is unlikely someone does on the Clip 12.30.18 # the default one is the same height as sysfont (8px I think) 12.30.23 # fml: looks centered correctly but "Rate: value in percent" is now two lines 12.30.51 # the "Rate" isn't needed on the hwcodec screens 12.31.16 # pixelma: hrm... Does RB automatically wrap texts in viewports? 12.31.42 # pixelma: I agree, if there is no timestretch feature then the word is not needed 12.31.51 # pixelma: rate is the old pitch I think 12.31.57 Quit Ubuntuxer ("Leaving.") 12.32.41 # probably, but even if it wouldn't, then your problem would just be a different one - that you can't see everything completely 12.33.27 # kugel: yes, and targets that can only do the old style don't need to state this "mode" 12.33.52 # but then the same mode has two names accross tagets 12.33.52 # as fml said, sorry 12.33.57 # pixelma: but it was displayed in one line before, right? The patch added a space after the colon. hance I assume that it gets wrapped 12.34.28 # fml: there's no automatic wrapping 12.35.11 # kugel: then I have to look into the code more carefully to see what's done there 12.35.57 Join evilnick_home1 [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) 12.36.13 # hmm, the old one had the same problem 12.36.47 # pixelma: you mean two lines? Or partially non visible texts? 12.37.18 # I can't tell the difference between the old and the new one though now on hwcodec, just that it keeps the mode? 12.38.46 # pixelma: yes, that should be the case. Just the %/semitone mode should be preserved. 12.39.05 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 12.39.55 # fml: yes, the old one also has two lines and the center viewport overlaps the viewports above and below a bit (where you can read "semitone up" etc.) 12.40.10 # two lines in the center viewport 12.40.49 # fml: can this cause really that much binsize difference? 12.41.22 # pixelma: ok, so the patch didn't introduce something new in this regard 12.42.16 # pixelma: internal computations of semitone<->rate have been changed too. This might have been done not in the optimal way. I'll look into it. 12.42.45 # aha 12.44.04 # New commit by 03bertrik (r21801): S5L8700: implement timer driver 12.45.42 # bertrik: I wonder if you could have a look at purging tuner.c from target specific code 12.46.17 # kugel: bubbles crashes on my Ondio with your patch too (even with the changes you proposed later in the night), the patch also changes the "shoot bubble" button from "Up" to "Mode" which is the nice exception (and example) for how controls can differ between plugins: "Up" to shoot the bubble makes sense in this game, but not as a general "Select" button in other plugins 12.46.33 # kugel, I think I'll be working on the s5l8700/meizus in the coming time and not so much on other things 12.47.24 # grml 12.47.30 # no samsas too? 12.47.39 # pixelma: so is that good or bad? 12.48.22 # have you managed to install a svn version now to see if it crashes? It doesn't crash on my fuze 12.49.03 # kugel: the "Up" and "Mode" (for select) caused a lot of trouble when introducing PLA, since bubbles was the first one and later people thought "Up" was the "do something" button on the Ondio. Well, I prefer "Up" for shooting the bubbles, in other plugins "Mode" might be better suited for "action!" 12.49.44 # I can compile a version without the patch too now 12.50.21 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 12.52.03 Quit evilnick_home (Read error: 113 (No route to host)) 12.52.04 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 12.56.30 *** Saving seen data "./dancer.seen" 12.58.00 Quit robin0800 (Read error: 110 (Connection timed out)) 12.59.10 Quit petur ("linsucks") 12.59.17 Join robin0800 [0] (n=robin080@general-kt-199.t-mobile.co.uk) 13.00.07 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 13.06.06 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 13.14.21 # kugel: yes, the same revision without the patch doesn't crash in bubbles... 13.14.34 # which revision? 13.15.22 Quit robin0800 ("Leaving") 13.16.14 # r21795 13.18.02 # and you should really look into the button repeat problem with the patch 13.18.31 # the robotfindskitten one? 13.19.13 # it looks like a general problem, e.g. aiming left/right in bubbles doesn't work correctly either 13.19.18 Quit fml ("CGI:IRC (EOF)") 13.21.29 # or adjusting bpm in metronome 13.24.32 Join faemir [0] (n=faemir@cpc2-cmbg2-0-0-cust30.cmbg.cable.ntl.com) 13.28.56 # * bertrik has only one screenful of undefined linker references left for a normal meizu m3 build 13.33.04 Join dash32 [0] (n=dash32@p54AB44DD.dip.t-dialin.net) 13.39.40 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 13.56.41 # New commit by 03kugel (r21802): Optimize chopper a bit by making a often used macro an inline function(which means its parameter expressions are evaluated before expanding) and ... 14.00.42 # bertrik: almost there! 14.01.12 # markun: are you still using the database.unignore stuff? 14.01.29 # * bertrik invites other meizu owners to help hacking 14.03.24 # markun, it seems there is a kind of emergency-reset circuit on the meizus, just hold play or enter for 20 seconds or so 14.03.52 # kugel: you want to remove it? 14.04.00 # basically, yes 14.04.10 # why? 14.04.11 # I guess (but have not tried yet) that discharging or disconnecting the battery is not necessary 14.04.19 # because it scans the whole tree? 14.04.23 # yes 14.04.52 # I think it's a useful feature, but also would prefer it not to scan everything 14.05.12 # bertrik: I'd help, but someone took my M3 away! ;) 14.05.21 # I don't think it's worth saving a few database.ignore files 14.06.09 # kugel: you could do a forum poll 14.06.20 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 14.06.35 # well, I think you're about the only one using it 14.06.59 # bertrik: normally discharging or disconnecting the battery isn't necessary, yes. The problem I had in Gent was getting my finger timing exactly right to get it to DFU mode after the reset. I managed once in a few dozens of tries 14.07.08 # doing a forum is probably not helpful, I expect most people do not understand the gain of removing it 14.07.14 # to* 14.07.20 # kugel: then explain that in the poll 14.07.35 # if they don't understand the gain, then they will probably not care if you remove it either 14.07.41 # you just yourself you prefer to not scan everything 14.07.53 # +said 14.08.23 # kugel: if you can't explain the gain of removing it in the forum poll in a way that makes forum people understand, you haven't properly understood it yourself ;) 14.08.25 # yes, I said that. But I also prefer to have the unignore feature work :) 14.08.46 # You can't prefer both 14.08.59 # You can. It's called a setting :) 14.09.24 # I haven't used the feature, but the double inverted logic of unignore just seems weird to me 14.11.03 # I think there are four solutions. (a) just remove database.unignore, (b) stop at database.ignore if the setting "Use database.unignore" is set to off, (c) add database.ignorenonfinal (or some other name) that can be overridden with database.unignore and make database.ignore stop searching, and (d) do nothing 14.11.31 # I tend to prefer (b) or (c) 14.11.39 # I like c! 14.12.21 # better than adding a setting 14.12.26 # but maybe a different name 14.12.50 # yes. That name is lousy 14.12.53 # and there the trouble begins 14.13.02 # I bet we aren't able to agree on a name 14.13.28 # kugel: you can't be serious.. 14.14.01 # you just want to remove the feature and are trying to come up with a good excuse 14.14.03 # markun: "database.naturalsort" ;) 14.14.27 # markun: no, just my experience 14.14.49 # kugel: which other feature had not been implemented or was removed because of the name? 14.15.07 # huh 14.15.11 Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) 14.15.12 # I haven't said that 14.15.22 # I just said that I think that finding a name will be hard for us 14.15.52 # not that we should go for (a) just because of it 14.16.00 # ok, good :) 14.16.01 Quit dash32 (Remote closed the connection) 14.16.08 # how many people need to "unignore" a folder that's in another one they want to ignore? And in how many cases it is really only one folder in a lot of others that would need to be ignored if "unignore" wouldn't exist 14.16.39 # pixelma: who knows.. 14.16.44 # 1? 14.16.53 # * bertrik thinks this is all too complex 14.17.09 # pixelma: the main problem is that without unignore you can't ignore the root 14.17.14 # it is only really useful if you need to ignore a lot of others otherwise... why not put the subfolder elsewhere? 14.17.37 # IMO 1 sounds like a good approximation :) 14.17.51 # gevaerts: you could also solve that by rearranging your data structure 14.18.11 # If you only use the DAP for listening to music, you don't need unignore I think. If you also use it to transport random files, I think unignore is useful 14.18.29 # pixelma: I like my tree, my music is under "audio" along with other things like "podcasts", "audiobooks" etc. 14.18.37 # gevaerts: can you elaborate that? 14.18.53 # you only use database.ignore (or unignore) if you want to use the database 14.19.16 # then data structure becomes less important, I think 14.19.36 # markun: and that's makes 2 .[un]ignores either way 14.19.47 # kugel: if you dump random stuff in the root of your filesystem, the database scan will pick it up. That's a pretty common case if you meet someone who wants to give you some files 14.19.59 # kugel: I have 1 .ignore in my root and 1 .unignore in my "music" folder 14.20.08 # gevaerts: solved by creating a folder "/random_stuff" 14.20.17 # all the test tracks and other audio files gets ignored 14.20.31 # gevaerts: you can put the files into subfolders - you can even do so in Rockbox without a computer 14.20.49 # (can take some time in some cases) 14.20.52 Quit r0b- (Read error: 110 (Connection timed out)) 14.21.03 # kugel: not really. You can't just say "put it on this one, there's enough room" anymore. If you use it to get files often enough, that gets annoying 14.21.17 # pixelma: so, how should I arrange my files? Make 2 folders in the root, and put the things I don't want ignored in one and the rest in the other? 14.21.22 # gevaerts: huh? 14.21.37 # markun: as I said, put your test files in a "test" folder with an ignore 14.21.42 # how's the root different from /random_stuff in terms of "room"? 14.22.04 # kugel: my podcasts are not random stuff 14.22.04 # kugel: because you have to tell someone where to put it. You're not always the person sitting at the keyboard 14.22.40 # gevaerts: you can sort them later even on the player... 14.22.47 # If you only copy random files once a month, that's not a problem. If you do it seven times a day, it gets seriously annoying 14.23.06 # how many people do this? 14.23.10 # so you're using unignore also? 14.23.13 # anyway, I like the unignore feature, I can add and remove files and folders and everything keeps working as I want to with just these 2 files 14.23.28 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 14.23.39 # pixelma: I have no data, but I'd think it's not very uncommon 14.23.39 # I wouldn't mind having a database.scan file in the root where I specify which folders I want to have scanned 14.23.44 # would that solve the problem? 14.23.54 # kugel: I don't use the database 14.24.04 # gevaerts: and I would think if your folder is named properly like "put random stuff here" people could find out 14.24.09 # markun, database.scan was exactly what I was thinking too 14.24.21 # if database.scan exists, just use those folders, otherwise look at database.ignore and remove .unignore 14.24.33 # sounds good 14.24.37 # bertrik: it would also make the scanning faster 14.24.50 # yeah, because it doesn't even enter the ignored subdirs 14.24.58 # right? 14.25.07 # and also the other folders with no music 14.25.55 # I'd keep looking for database.ignore anyway. If you meet one, stop 14.26.09 # we could put a database.scan at lower sub-dirs too and make it empty to ignore even deeper subdirs 14.26.19 # gevaerts: yes, that too 14.26.35 # so an empty database.scan has the same effect as a .ignore file 14.26.59 # bertrik: I thought you didn't want to make it complex! 14.27.01 # :) 14.27.02 # pixelma: maybe I find I'm using stuff differently than the author intended often enough to start getting annoyed by "Then do it this way!" on sight... 14.27.05 # markun: go implement :) 14.27.10 # sounds nice to me 14.27.28 # kugel: can't you do it for me? :) 14.27.41 # bertrik: an emptu database.scan would be the same as not initialising the database :) 14.27.43 # I'm not sdure 14.27.59 # kugel: ok, maybe I'll do it later 14.28.09 # bertrik: I wouldn't do that 14.28.15 # haven't even downloaded the source and installed a cross compiler here 14.28.15 # having both seems redundant to me (and is probably more complex :\ ) 14.28.15 # markun, I think it's very easy, just one file type (database.scan) that can exist at different levels 14.28.26 # point of database.ignore is that you don'T need to read it (it's empty) 14.28.44 # I say let's at least keep database.ignore as well 14.28.44 # markun: there are some interesting cases to think about, like what if database.scan has a/ and a/b/c/ in it, and there's a/b/database.ignore. What happens? 14.28.47 # since people use that 14.29.11 # I think scan should override everything 14.29.31 # gevaerts: then a gets scanned (excluding a/b) and a/b/c as well 14.29.35 # it's the ultimative order for scanning 14.29.48 # same as .ignore in a/b and .unignore in a/b/c 14.30.30 # btw, should the folders in .scan be absolute or relative? If we make it relative, then you can still move the folder around 14.30.42 # or support both? 14.30.50 # I'd say relative 14.31.10 # I'd support just a single database.scan file in .rockbox, or maybe in the root of each drive 14.31.36 # If they can be anywhere, then they should have relative paths 14.31.36 # if we put it in .rockbox we should not make it relative :) 14.31.46 # exactly :) 14.31.56 # unless we add ../ every time 14.32.03 # but that's a bit pointless 14.33.45 # kugel: thanks for bringing this topic up. I think it's a win-win situation with both of the things I wanted (fast scan, "unignore" like power) 14.35.42 # and there I hoped it could get simpler... 14.36.23 # I won't lose sleep over this because I don't use the database ignore/unignore features personally, but I would very much like the system to be "as simple as possible, as complex as necessary". In particular not have exceptions to exceptions to exceptions 14.43.53 Join n1s [0] (n=n1s@rockbox/developer/n1s) 14.45.31 # pixelma: I think it will get simpler 14.45.37 # you can use .ignore if you want to 14.45.42 # or use a .scan file 14.45.50 # doesn't sound like it 14.46.55 # i found some files that svn:keywords isn't set in apps/plugins (i checked only files in apps/plugins). 14.46.59 # pixelma: if you are happy with .ignore just stick to that. It will not get more complex. 14.47.22 # and if will not scan beyond that file (like it does now) 14.47.33 # and if -> and it 14.47.50 # you have twio files and filetypes to take care of (and the user needs to know about both), codewise you need to take care of both and need to handle "overlapping" and conflicts 14.48.00 Quit DarkDefender ("Leaving") 14.48.46 # the user needs to if he or she wants to use it in a way ignore can not 14.49.19 Quit robin0800 (Read error: 110 (Connection timed out)) 14.49.51 # it will be more complex codewise and to me .ignore is enough :/ 14.50.04 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 14.50.23 # they don't need to be aware of both. 14.50.28 # They can stick to what they use 14.50.45 # I don't think anyone will create database.scan files by accident 14.50.56 # * gevaerts might :) 14.51.09 # ok, maybe 1 of our users then :) 14.51.11 # not if they use unignore and/or want to achieve something similar 14.51.40 # err... then they need to know I mean 14.51.45 # pixelma: if kugel is right then nobody uses .unignore but me ;) 14.52.20 # I'm not sure if have multiple scan files is a good idea 14.52.25 # me neither 14.52.30 # it always means: opening, parsing etc 14.52.37 Quit Thundercloud (Remote closed the connection) 14.52.38 # or someone gives them "random stuff" and a database.scan is amongst it... 14.52.40 # markun: last week someone asked here about it, so there are probably a few more 14.52.47 # cool! 14.53.05 # gevaerts: that was the first one since it was committed.. 14.53.13 # and he didn't even know about it 14.53.19 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 14.53.19 # :) 14.53.31 Quit faemir (Read error: 110 (Connection timed out)) 14.53.33 # kugel: that just means it's documented well and it has no issues 14.53.52 # pixelma: when there is a patch we can discuss it a bit more 14.55.11 # kugel, is opening/parsing such a problem? we're already scanning and it's just a bunch of lines, hardly any parsing needed 14.55.59 # In my idea, there would be 1 scan file, all folders in their (and the sub folders) would be scanned 14.56.09 # pixelma, I consider the case that someone copies a database.scan file by accident quite remote 14.56.11 # 1 scan file per volume/fs 14.56.33 # kugel: I think that's what normal people would do anyway 14.56.34 *** Saving seen data "./dancer.seen" 14.56.55 # bertrik: depends. If there's one global scan file, yes. If there can be one in each directory, who knows? 14.56.56 # but if someone like gevaerts wants to go crazy and make a big .scan .ignore mess, why not? :) 14.57.10 # I really think that a database.ignore (maybe with a special casing for the root) is enough for everyone (except markun maybe) 14.57.48 # pixelma: if that's enough for most people then they should not make .scan files 14.58.02 # removing .unignore will speed up scanning for everyone 14.58.12 # and .scan will speed it up even more if they decide to use it 14.58.12 # cool, but it's worth adding the code 14.59.15 # with all the corner case ideas that came up now, I couldn't even follow what it will do or not 14.59.50 Join martian67_ [0] (n=martian6@about/linux/regular/martian67) 15.00.15 Join ucchan [0] (n=ucchan@FLA1Adp241.kng.mesh.ad.jp) 15.00.53 Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) 15.02.46 Quit n1s ("Lämnar") 15.08.37 Quit martian67 (Read error: 110 (Connection timed out)) 15.09.46 Join n1s [0] (n=n1s@rockbox/developer/n1s) 15.10.08 # gevaerts: should USB serial work upon defining USB_ENABLE_SERIAL in debug_menu.c or should I do something else? 15.10.35 # mcuelenaere: depends 15.10.54 # You need to do that before plugging in, and you need to make sure you have enough endpoints for it 15.10.54 Quit ucchan (Read error: 104 (Connection reset by peer)) 15.11.09 # ah, then I probably need to disable mass storage 15.12.24 Quit robin0800 (Read error: 60 (Operation timed out)) 15.14.38 # New commit by 03amiconn (r21803): * ARM asm DSP and codec/plugin functions: Use r12 scratch register properly ... 15.15.50 # hm, I think we could introduce a simple MSG command to the build server to tell clients about stuff, like when a build round ends, just for us who happen to check the client outputs etc 15.16.18 # that would be good 15.16.55 # * gevaerts also wants the client to be able to run an external script with that MSG data :) 15.17.14 # another good idea 15.17.39 Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) 15.17.43 # the server already runs optional external scripts on some events, so the client could just use the same concept 15.17.57 # Bagder: Did you see the old build system is still hanging? (for about 14.5 hours now) 15.21.03 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 15.21.12 # a thought has occurred to me since last night... perhaps asmdefs ought to go in sooner rather than later? basically, commit the build system parts first, start converting individual bits of asm, since the whole point of asmdefs is to make asm abi-agnostic... and then think about building with EABI when it's done. 15.28.55 # How do I build the rockbox manual? I'd thought I'd just create a build dir with Manual instead of Normal or Sim, but that seems to have just built the same as Normal for me 15.29.18 # make manual 15.30.24 # ah! what's Manual as build type used for? 15.30.48 # an old leftover 15.31.01 # thanks1 15.31.10 # also, ManualHowto should have told you about "make manual" 15.31.52 # Bagder: did you get my bootloader mail? 15.32.30 # pixelma - I should probably add ManualHowto to the DocsIndex 'for developers' section, in that case. I didn't find ManualHowto. 15.32.45 # gevaerts: I did, but I've been too lazy to deal with it yet 15.32.52 # OK :) 15.32.59 # stripwax: good idea :) 15.33.06 # I'll work on it tonight 15.33.09 # as long as it didn't get lost 15.35.11 # gevaerts: ready for release? 15.35.17 # yes 15.35.32 # Don't forget to tag them 15.35.59 # indeed. I should do that... 15.36.14 # I should really try the new bootloader on my c200... so I do need the bootloader, sansapatcher and the "manual install" description, right? 15.36.15 # I find the path situation on the download server to be in a sorry state 15.36.25 # I mean, this is bootloader 6.0 we say 15.36.31 # but they're spread all over 15.36.45 # and some dirs contain mixed bootloaders (and versions) 15.36.46 # the most sorry thing is the 5.0 symlink :) 15.36.56 # no, that's one of the most sensible ones in there 15.37.08 # since it'll make 5.0 links to remain functional 15.37.09 # huh? 15.37.17 # indeed. It actually points to 5.0 after all :) 15.37.24 # yes, and will continue doing so 15.37.47 # it points to bootloader/sandisk-sansa 15.37.56 # it points to the dir where the 5.0 bootloaders are 15.38.11 # but well, I don't care :p 15.38.16 # as the 4.0 points to the 4.0-dir 15.38.43 # hm 15.39.37 # aha! i've found the magic to produce stubs without the other eabi changes... i think. :) 15.39.39 # ok, I can accept that :) 15.39.53 # Bagder: these are all named 6.0. They probably aren't the 6th version of the bootloader for H10 and mr100, but the released ones for those don't have a proper version number anyway 15.40.13 # yes, but part of the reason why I didn't do this yet is the path situation 15.40.27 # I didn't really see how it would be done the best way 15.40.45 # but I'll just make up something fine 15.40.48 Quit evilnick_home1 (Read error: 113 (No route to host)) 15.40.54 # well, we didn't release them with 3.3 anyway, so there's no reason to hurry 15.41.01 # gcc doesn't actually determine the relocation type used for calls. the assembler does that, based on the abi version and the instruction used. so building a non-eabi gcc that passes -meabi=4 to the assembler gets us long-call stubs :) 15.43.28 # Unhelpful: i.e. that works with our current compilers? 15.43.46 Join Jaykay [0] (n=chatzill@p5DDC5670.dip.t-dialin.net) 15.44.37 # the bootloader version flashes by so quickly perhaps it could be added to rockbox info in the system menu? 15.44.46 # kugel: it should. i've not tested with gcc-4.0.3 15.45.14 # what is the purpose of r21795 and r21803? 15.46.00 # Jaykay: "Saves a bit of stack and execution time" not clear enough? 15.46.53 # gevaerts: execution time of what? and thats for r21795 15.47.38 # of ATA and LCD drivers? 15.47.48 # i just tested with 4.3.3, though, and mp3 on e200 still breaks :/ 15.49.05 # gevaerts: and what do these drivers execute and are all of the functions of the drivers now faster? 15.49.28 # the drivers execute instructions 15.49.46 # gevaerts: for some reason, when I enable the USB serial driver (no mass storage, no HID) dmesg gives me this: usb-storage: probe of 1-3:1.0 failed with error -5 15.49.48 # * GodEater wonders what the purpose of these questions are 15.50.03 # ( http://pastie.org/543086 ) 15.50.12 # Unhelpful I think mp3 generally breaks with that compiler 15.50.30 # I tried 4.4.0 RCsomething and it crashed as well 15.50.37 # mcuelenaere: what does lsusb -v say for the device? 15.50.56 # GodEater: i only wanted to know what is better now with these two revisions, gevaerts short answers force me to ask further questions 15.51.01 # gevaerts: http://pastebin.com/f45a598ec 15.51.55 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.52.04 # Jaykay: but since you didn't understand the answer, I wonder what you're going to do with the information 15.52.13 # mcuelenaere: weird. usb_storage shouldn't even look at it 15.52.40 # * gevaerts wonders if this is another one of those HAL features 15.53.08 # GodEater: i thought i could get answers i could understand, i was just curious... 15.53.19 # gevaerts: that vid/pid combination used to do usb_storage, perhaps that's it? 15.53.38 # mcuelenaere: yes, but it shouldn't be... 15.56.36 # hmm I changed pid to a4a6 and now usb_storage backs off, but usbserial doesn't kick in.. 15.57.09 # did you modprobe usbserial with the right vid/pid arguments? 15.59.32 # ah no :/ forgot about that, I just did modprobe usbserial 16.01.06 # gevaerts: yep, that did it :) 16.02.31 Quit amiconn (Read error: 104 (Connection reset by peer)) 16.02.31 Quit pixelma (Read error: 104 (Connection reset by peer)) 16.02.49 Join pixelma [0] (i=quassel@rockbox/staff/pixelma) 16.02.50 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 16.04.19 Join matsl [0] (n=matsl@host-90-233-177-32.mobileonline.telia.com) 16.04.29 Quit stripwax ("http://miranda-im.org") 16.12.47 # New commit by 03FlynDice (r21804): AMSSansa: Use single adc_read instead of multiple ascodec_reads to read voltage for display in View HW info. 16.21.20 # Unhelpful: ping 16.21.26 # kugel: do you have any idea where that breakage starts? :) 16.21.44 # nope, I haven't looked into it further, as other codecs were slower too 16.22.21 # i've just got the -meabi=4 asm patch into our current gcc version... going to try it now. if it still crashes i guess i should see if reverting binutils fixes it... 16.25.36 # we don't have ARRAY_LEN in plugins? 16.26.21 # we don't have this at all :S 16.27.14 Quit matsl (Read error: 60 (Operation timed out)) 16.28.41 Join mt [0] (n=mt@41.233.138.250) 16.32.40 # New commit by 03bertrik (r21805): Meizu: implement power driver (USB power detect / charging status / poweroff) 16.33.24 # bertrik hardcore coding 16.34.16 Join PureDarkn [0] (n=Shadow@ip24-254-209-65.hr.hr.cox.net) 16.35.59 Part PureDarkn 16.36.08 # New commit by 03mt (r21806): Add seeking support in cook codec. 16.36.45 # hmm 16.37.09 # ARRAY_LEN(x) gives 2 in the one line (the reason it crashes), but when I printf it it says 1 :S 16.37.10 Quit ReKleSS (Read error: 104 (Connection reset by peer)) 16.37.31 Join ReKleSS [0] (n=ReKleSS@d58-110-125-63.sbr6.nsw.optusnet.com.au) 16.37.55 # funny, I see the GPIO attached to the piezo beeper change value when I pinch this meizu m3 :P 16.38.07 # extra button! 16.38.43 # yay for combos 16.41.35 # pixelma: I got the crash fixed 16.43.27 # New commit by 03mt (r21807): Some fixes for the standalone test program. 16.44.09 # * gevaerts sees things happening when he plugs a USB device into his F20 :) 16.44.29 # is there any reason some files don't have svn:keywords? may i set svn:keywords and commit? 16.45.01 # teru: probably an accident :) 16.46.03 # can I add ARRAY_LEN to system.h? 16.46.31 # or misc.h 16.47.29 # oh, we have ARRAYLEN 16.48.41 Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.49.02 # kugel: i was about to say that :) 16.49.39 # n1s: we also still have strncpy ;) 16.51.41 # * Unhelpful appears to have mp3 playback again (not putting on headphones) 16.53.03 # hrm, but all tracks fail without error for vorbis... no error displayed, just an immediate skip to the next track. 16.53.10 # kugel: right... 16.53.13 # OK. USB host on gigabeat F is definitely possible, and shouldn't have unexpected problems 16.53.51 # gevaerts: great 16.54.01 # * bertrik waits for gevaerts' commit 16.54.39 # bertrik: possible, not ready :) 16.55.23 # All I've really verified so far is that if I follow the init sequence from the spec, and I plug in a device, the "device plugged in" bit changes 16.56.21 Join petur [50] (n=petur@rockbox/developer/petur) 16.56.28 # I just want to be able to use hid to control my samsung with my clip :D 16.56.38 *** Saving seen data "./dancer.seen" 16.56.48 # the clip is an awesome remote also :) 16.56.58 # yeah, clip remotes! 16.57.54 # kugel: the samsung isn't OHCI, so that will have to wait a bit (unless you feel bored) 16.58.09 # I don't 16.59.38 # using this patch in place of the usual one for gcc should give you long-call stubs without the other EABI changes. the snapshot binutils will still be needed for this to work properly 17.00.00 # also, the generated object files are probably *very* non-standard and incompatible, as they claim to be EABI ;) 17.01.12 # New commit by 03gevaerts (r21808): Remove OHCI registers from s3c2440.h and move them to their own header. Since s3c2440 seems to be very close to the OHCI spec, there's no reason not ... 17.02.06 # obviously i need to link the patch: http://pastie.org/543124 17.02.43 # Unhelpful: what's the benefit of not getting the full eabi? 17.03.06 # n1s: not breaking ASM assumptions about structures 17.03.26 # aha 17.03.50 # Unhelpful: are you too lazy to not fix them, or are they just not worth it? 17.03.55 # will the patch likely work with future gcc version (or will it be neaded at all?) 17.04.26 # if there are no strong objections to it soon, i'll commit asmdefs and start working on fixing asm structure assumptions 17.04.51 Quit n1s ("Lämnar") 17.04.59 # New commit by 03teru (r21809): set svn:keywords property 17.05.56 # also building gcc<4.3 with full EABI breaks a bit with our current multilib settings. for some reason gcc and gas disagreed about whether ldrd is supported. changing that target to arm946e-s fixes it, and should be correct for all targets for which we use arm9e now. 17.08.22 # Weird, I can't reproduce the same warnings for e200 sim in the last commit 17.09.04 # i'm inclined to think that it's worth fixing asm for EABI in the long run. it makes many structures smaller, though i don't *think* it ever forces unaligned accesses to do so. this results in a 25% memory savings, for example, for core jpeg's decode buffer, since the rgb888 pixel struct is not padded to 4 bytes. 17.09.52 Quit ReKleSS ("Leaving") 17.10.36 # Unhelpful: what was the reason mp3 crashs? 17.11.27 # New commit by 03mt (r21810): Silence warnings to fix yellows for now. 17.15.38 Join funman [0] (n=fun@rockbox/developer/funman) 17.21.28 # kugel: i don't know. it happened even without EABI on 4.3.3 17.21.45 # but it doesn't happen with the new binutils alone. 17.22.45 Join kugel_ [0] (n=kugel@e178090250.adsl.alicedsl.de) 17.22.55 Quit kugel (Nick collision from services.) 17.22.59 Nick kugel_ is now known as kugel (n=kugel@e178090250.adsl.alicedsl.de) 17.24.34 # Unhelpful: that's what I said 17.25.45 # I think I didn't try 2.19.1 binutils 17.28.24 Join MrDuck [0] (n=kachna@r4ax178.net.upc.cz) 17.29.24 # perhaps we can have a look at the sd/mmc linux framework to see how errors are handled (retry / card reset) 17.29.24 # New commit by 03gevaerts (r21811): Add data structures 17.30.59 Join stoffel [0] (n=quassel@p57B4EB44.dip.t-dialin.net) 17.32.40 Quit amiconn (Read error: 104 (Connection reset by peer)) 17.32.40 Quit pixelma (Read error: 104 (Connection reset by peer)) 17.33.12 Join pixelma [0] (i=quassel@rockbox/staff/pixelma) 17.33.14 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 17.33.49 # Do you know if the CRC of data blocks are stored on SD cards, or calculated by the card before transmission ? 17.33.57 Quit Rob2223 () 17.34.00 # New commit by 03bertrik (r21812): Meizu M3: initial version of battery readout and (uncalibrated) charge/discharge curves 17.34.12 Join Rob2222 [0] (n=Miranda@p4FDCF677.dip.t-dialin.net) 17.34.15 # funman, I think this is pure a transmission thing 17.35.29 # The SD spec mentions "data transfer integrity" and not "data storage integrity" so I believe you are right 17.35.47 # So I wonder why 10 transfers get corrupted in a row 17.38.07 # kugel: good you fixed the crash, care to upload a new patch or so? 17.38.24 # yes, after I fixed the REPEAT thing 17.38.39 # alright 17.39.22 # The SD spec (4.6 Error Conditions) only mentions CRC checks for commands (and only say the card's state doesn't change if the CRC of a command sent by the host is wrong) 17.41.48 # In case of any error (CRC or Write Error) during Write Multiple Block operation, the host shall stop the 17.41.52 # data transmission using CMD12 17.43.38 # * funman writes that on his TODO list 17.44.10 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 17.45.21 Quit funman ("free(random());") 17.46.35 Quit aaron424 (Read error: 104 (Connection reset by peer)) 17.49.31 Join amiconn_ [0] (n=jens@p57B9E816.dip.t-dialin.net) 17.55.58 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 17.56.34 Join tvelocity [0] (n=tony@athedsl-4488555.home.otenet.gr) 17.57.41 Join Ubuntuxer [0] (n=johannes@dslb-088-078-119-208.pools.arcor-ip.net) 17.58.34 # pixelma: on the tracker 17.59.01 # New commit by 03Ubuntuxer (r21813): match the manual to the changes in 18.00.29 # revision 21529 18.00.38 Quit linuxguy3 (Read error: 104 (Connection reset by peer)) 18.01.21 Quit teru ("Quit") 18.03.08 Join matsl [0] (n=matsl@host-90-233-181-154.mobileonline.telia.com) 18.04.24 # Ubuntuxer: that should have been in the commit message, not here ;) But thanks :) 18.04.37 Join linuxguy3 [0] (n=timj@adsl-68-253-177-159.dsl.emhril.ameritech.net) 18.04.41 # kugel: alright, will have a look later 18.04.50 # nice, thanks 18.05.23 Quit pixelma (Read error: 110 (Connection timed out)) 18.05.24 Quit amiconn (Read error: 110 (Connection timed out)) 18.06.49 Nick amiconn_ is now known as amiconn (n=jens@p57B9E816.dip.t-dialin.net) 18.06.52 # kugel: it looks like that patch reverts the chopper changes 18.07.01 # you just committed 18.07.06 # it does? 18.07.37 Join n00b81 [0] (n=n00b81@unaffiliated/n00b81) 18.08.10 # interesting, git still has some surprises left :p 18.10.23 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 18.10.55 Quit antil33t (Read error: 104 (Connection reset by peer)) 18.11.09 Join antil33t [0] (n=Mudkips@119.224.12.185) 18.12.46 # pixelma: updated 18.14.38 # mt: Is this brute-force seeking? 18.15.41 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 18.17.41 # amiconn: what do you mean by that ? (btw it's briefly described here : http://www.rockbox.org/twiki/bin/view/Main/RealMediaSupport in Milestone 3, last point) 18.18.18 Join n1s [0] (n=n1s@rockbox/developer/n1s) 18.19.10 # Ah, so not entirely brute force, but skimming through the whole file (as opposed to a simple lseek()) 18.20.55 # Yes, skimming through the file. Although I'm still not sure what brute-force means in this context. :) 18.23.14 # Decoding from the beginning of the file until the seek point is reached 18.25.03 # Ah ok. No decoding though, just searching for the nearest timestamp. 18.28.56 # bertrik: any idea what the pop fifo is? 18.29.04 # for dbop 18.29.19 Quit robin0800 ("Leaving") 18.31.55 Join dys [0] (n=andreas@p5B315749.dip.t-dialin.net) 18.33.26 Quit Thundercloud (Remote closed the connection) 18.36.59 Quit mt (Remote closed the connection) 18.41.06 Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) 18.46.29 Join mt [0] (n=mt@41.233.138.250) 18.47.26 Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) 18.48.28 Quit DarkDefender ("Leaving") 18.50.54 # kugel, I think there is only one FIFO, the CPU pushes data into it and the DBOP pops data from it at its own pace 18.51.43 # I'm just wondering why the statusregister has bits for the pop, but no interrupts 18.53.44 Join robin0800 [0] (n=robin080@general-ld-216.t-mobile.co.uk) 18.54.40 # I think the pop status signals are for information only, it would be of no use to have two interrupt sources because they occur almost always at the same time 18.56.42 *** Saving seen data "./dancer.seen" 19.05.39 # bertrik: hmm, success, sort of 19.06.11 # bertrik: I did the lcd speed up thing using wakeup_signal 19.06.23 # hmph! neither the new binutils nor the passing to it of EABI flags is responsible for breaking vorbis. if i enable -mlong-calls, so that long calls are used instead of short calls with linker-generated long-call stubs, the faux-eabi toolchain gives me a working vorbis codec again. :/ 19.06.32 # no blue bars (even though 99.5fps when boosted), but 10fps less when unboosted 19.06.45 # bertrik: Do you know how similar the Meizu's S5L8700 is to the Nano2G's 8701? 19.06.57 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 19.07.23 # I only have the datasheet to the 8700, but I think quite similar 19.07.25 Quit stripwax (Client Quit) 19.07.42 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 19.08.10 # at least the peripheral ranges seem to be the same (although 8700 has no crypto engine as far as I know) and I expect the actual peripherals to also work the same 19.10.08 # I'm looking here - http://www.rockbox.org/twiki/bin/view/Main/MeizuM6Port - is the status table up to date? (e.g. it says neither the bootloader or Rockbox build?) 19.10.25 # no it's not up to date 19.11.09 # the bootloader does compile now for example 19.12.36 # at least the meizu M3 bootloader does, the M6 bootloader should be compileable with little effort 19.12.41 # grml 19.13.43 # I was planning to clean up the MeizuM6Port, create a MeizuM3Port page and clean up MeizuReverseEngineering 19.14.07 # New commit by 03alle (r21814): Unify semitone and cent macros and make the formula a bit more obvious 19.14.43 Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) 19.16.43 Quit robin0800 ("Leaving") 19.17.01 # bertrik: I was just wondering if, now that's it's possible to run code on a Nano2G, it's worth setting up a minimal bootloader target in Rockbox, based on the existing 8700 code... 19.17.16 # bertrik: no idea how to implement the wakup_signal stuff in asm :) 19.18.33 # linuxstb, not that hard I would guess, just a linker script and a bootloader main and some way of packaging the bootloader up so it can be sent to an ipod 19.18.57 # the big problem is that we don't have a driver for the NAND so we also don't have a file system 19.19.17 # You have lcd drivers for both the m3 and m6? 19.20.01 Join TheSeven [0] (n=theseven@dslb-084-056-177-202.pools.arcor-ip.net) 19.20.15 # no, only for the m3, there has been some research into the m6 display (init sequences, getting an LCD ID) earlier but it never worked so far AFAIK 19.21.27 # ok, so i heard you're discussing nano plans here? 19.21.46 # * bertrik prods gevaerts and markun to start working again on their M6's 19.22.48 # TheSeven: I was wondering about getting a very minimal (i.e. doing nothing) Rockbox bootloader build working for the Nano 2G. Rockbox bootloaders are basically cut-down versions of Rockbox itself, using the Rockbox low-level drivers, but with a "main()" that simply loads the main Rockbox binary from disk. 19.23.16 # ok... what kind of hardware access do these need? 19.23.28 # concerning NAND: we definitely have some whimory thing in there 19.24.40 # right now we can't properly install a bootloader on the firmware partition yet, but that will come as soon as we find the relevant code in the disassembly 19.24.44 # TheSeven, yes, it's in the Meizus too 19.24.44 # I'm not sure what you mean by "what kind of hardware access do these need?" - a functioning bootloader needs buttons, lcd, disk, but I was just thinking of a "do nothing at all" bootloader that can be used for experimenting. 19.24.55 # This "bootloader" would be the code uploaded via iBuggerLoader 19.25.01 # ok... 19.25.23 # It's mainly to make use of the Rockbox build system to allow people to easily hack with C 19.25.28 # in fact i'm wondering whether i should upload an extended ibuggerloader through ibuggerloader :-P 19.25.36 # (and to share any existing code with the Rockbox Meizu ports) 19.25.56 # any success with other new ipods yet? 19.25.57 # once i get these bulk IN endpoints working, you'll have some kind of minimalistic debugger then 19.26.09 # n1s: not yet 19.26.49 # n1s: Unfortunately the notes files are not yet compatible with 3g/4g. What iPod do you have btw? 19.26.59 # i have a 4g nano 19.27.16 # You can always do some testing :P But there are a ton of files 19.27.42 # ibuggerloader provides the following functions right now: reset, reconnect, write (i.e. copy data from usb to ram), fastwrite (the same, but 4byte-aligned), and execute. so you can use it to poke at AHB etc. to study hardware, but it would be easier, if we also had a read command, which depends on that evil IN pipe 19.27.59 # TheSeven, on the Meizu I'm using some kind of built-in DFU mode that allows me to write my bootloader test program to an 1MB NOR flash 19.28.47 # bertrik: the nano has such a thing, too, but it's nonstandard and encrypted, so you would need to encrypt the file on a nano before you can upload it through dfu 19.28.50 # TheSeven: Ah, so currently you can upload data to the Nano via USB, but not the other way around? 19.29.00 # linuxstb: yes 19.29.28 # bertrik: and as itunes is not able to talk to that dfu mode, restoring the original nor would be hard, so it's too risky 19.30.14 # ibuggerloader was written to provide a replacement for that, by just uploading arbitrary data to arbitraty memory locations (usually SRAM), and execute them from there 19.30.59 Join fml [0] (n=4fd3c6a6@gateway/web/cgi-irc/labb.contactor.se/x-47594a4663e98690) 19.31.22 # i was planning to set up some trivial c environment myself in fact... i.e. init code, linker scripts, ... 19.31.47 # sounds like that's your intention, too 19.32.28 # Hrm... I'm looking into the pitch screen code and can't see what can be done to significantly reduce the bin size. One thing would be to rewrite it from scratch with that aspect in mind and hope that the result will be better than what we have now. But I wouldn't like to do that. 19.33.17 # TheSeven, I'm copying a lot from similar rockbox targets :P 19.33.22 # TheSeven: Yes, that's the idea. 19.33.38 # ahhh 19.33.45 # I can't reproduce the 80fps 19.34.05 # TheSeven: Do you have any feedback methods to prove your code is running once uploaded? 19.34.32 # well, a little. by making it crash, lockup, or return to ibuggerloader 19.34.59 # as long as you don't touch SDRAM, you can return into the debugger by jumping to the LR passed to the entry point 19.35.15 # maybe we could help, e.g. identifying the backlight enable, or maybe an LCD init sequence 19.35.33 # bertrik: we have a NOR dump now, so that should be doable... 19.35.36 # we already have code to write text to the screen that could help a lot 19.36.02 # what would help even more would be to get that IN pipe working, so we could just read back memory 19.37.11 # my long-term plans (at least until i managed to decrypt nor yesterday) were to write a bigger clone if ibuggerloader in c, which provides a lot of additional functionality, using the openiboot usb stack, as this seems to fit to that hardware 100% 19.38.07 Quit Ubuntuxer (Read error: 110 (Connection timed out)) 19.40.16 # I can have a look tonight at that dump, it's usually not hard to figure out the hardware connections, just takes a lot of patience 19.40.28 # what i forgot concerning feedback methods: we have uart up and running, so if you have the appropriate hardware, you can use that 19.40.45 # When I find anything interesting, I'll put the results on the rockbox wiki if you don't mind 19.41.16 # I'm right now disassembling that dump, until now straightforward with the control flow, to get an idea of the structure 19.42.29 # Can I download it somewhere? 19.45.42 Quit stripwax ("http://miranda-im.org") 19.46.25 Quit r0b- (Read error: 104 (Connection reset by peer)) 19.48.35 Join darkip [0] (n=bbq@87-194-208-7.bethere.co.uk) 19.49.21 # hey, is there any way to customise the database browsing to show the album title underneath each track title (like on the ipod classic firmware) 19.49.24 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 19.50.13 Part r0b- 19.50.13 Join r0b- [0] (n=rob@adsl-76-235-217-188.dsl.klmzmi.sbcglobal.net) 19.50.38 Join toffe82 [0] (n=chatzill@ppp-69-238-94-134.dsl.frs2ca.pacbell.net) 19.52.33 # I wonder if other people have this problem too but: in timestretch mode, just lowering the pitch there is a certain range where I don't hear anything (at around 60%), going lower gives me noise again, higher is no problem at all. I'm trying with music mp3's at different bitrates usually above 128kb/s vbr and cbr 19.53.13 # sometimes when adjusting a bit around those value I get a burst of noise 19.53.27 # New commit by 03peter (r21815): Patch by Wincent Balin: convert pdbox from app to viewer 19.53.45 # oh, and I already observed it while trying a build before the new UI 19.53.59 # this is on a c200 19.56.21 # darkip: I don't know a way to make the display use two lines per entry but I think you could maybe let it show the album title in front or after the title (I am not sure though and couldn't tell how) 19.56.45 # hmm, so there's no native feature for this... 19.56.59 # maybe I'll have a dabble in the code and see what I can do myself 19.58.11 # you can customise the view a bit using tagnavi syntax (it's explained in the DataBase wiki) but as I said only the entry itself 19.58.28 # ok, thanks again :) 20.00.31 # pixelma: yes, I also experience strange behaviour with time stretch sometimes. Sometimes playback is stopped and the playlist is corrupted. 20.01.36 # darkip: and of course the virtual "folders" and sorting can also be customised 20.02.14 # fml: "nice" 20.04.27 Quit pixelma (" laters") 20.05.31 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 20.07.11 # Zagor: will you make the new build table use new links to the title pics and create a fresh set? 20.07.35 # ok 20.08.19 # possibly we should make them with a Makefile or something 20.08.35 # to make it easier to generate new ones when the builds file changes 20.09.12 # I'm simply adding a 'next if (-f "$dir/pic-$id.png");' to the loop 20.09.53 # good idea 20.11.02 # I'll also move the build scores into the builds file, no point in having two separate ones 20.11.15 # good 20.11.27 # * gevaerts thinks that the scores need to be tweaked. They seem to favour kugel's server ;) 20.11.35 # looking forward to some late night sessions next week :) 20.11.51 # yeps, that should help us get this go live soon 20.12.09 # devlatenightweek 20.12.32 # gevaerts: hehe, they just favor the fastest one :> 20.12.44 # kugels server is bloody invincible 20.13.30 # gevaerts: your combined only has 20k more than the fastest split one? 20.13.49 Join cmwslw [0] (n=irchon@adsl-065-006-217-207.sip.mem.bellsouth.net) 20.13.53 # kugel: don't forget that there's still an old-style builder in there as well 20.14.07 # ah, right 20.14.21 # Zagor: is the 40838 cpu seconds on cancelled builds correct? 20.14.33 # 11 hours! 20.14.37 # who runs jakorasia-cg? it's very fast with that low bogomips. 20.14.53 # gevaerts: it does look a bit high 20.15.11 # hey guys- I'm cmwslw from Linux4nano 20.15.11 # How many servers didn't finish anything? 20.15.17 # bogomips is really bogo... 20.15.34 # hey cmwslw 20.15.45 # Bagder: yeah, I'd just like to know what machine it is that is sort of the inverse of Atom 20.15.53 # Bagder: not always. My 1193 bogomips client is really slow :) 20.15.55 # does rockbox have any info on the iPods clickwheel? 20.16.09 # gevaerts: ;-) 20.16.33 # I'm talking about pinouts etc. 20.16.37 # Zagor: I believe saratoga's machine is a quad-core... 20.17.51 # it would be interesting to see the mhz values too 20.18.03 # gevaerts: split them again, you were doing more builds with it :( 20.18.06 # perhaps they are only slightly less bogus 20.18.24 # I love this line from the bogomips wp page... "It is not usable for performance comparison between different CPUs.[4]" :D 20.18.28 Join BdN3504 [0] (n=5ce539e0@gateway/web/cgi-irc/labb.contactor.se/x-39b316b4ef0cc171) 20.18.32 # cmwslw: I can't seem to find anything like that in our wiki 20.19.10 # JdGordon: yeah, but practically nothing is other than a custom benchmark 20.19.12 # JdGordon: I figure we can all agree to that! 20.19.57 # perhaps we should indeed to a small test compile as benchmark when the client starts 20.20.16 # would probably be better, yes 20.20.28 # I don't want to rely on the speed number too much, but having it semi-reliable would enable more detailed optimization 20.21.17 # Zagor: MHz is tricky. It can change (laptops), and my arm machine doesn't even have it in /proc/cpuimnfo 20.21.20 # 27K 32K 34K 36.9K 40.8K 20.21.34 # the number of "wasted cpu seconds" just goes up! 20.21.43 # those are the last 5 rounds 20.21.45 # gevaerts: bogomips changes with mhz on the laptops 20.21.50 # my gigabeat fails initializing the database. i tried it with a current build and the 3.3 release, but neither works. the initialization seems normal (as in rockbox gathers datat for all 15780 files) then tells me to reboot to enable the db. when i do so, i get the normal committing database at startup, but it doesn't finish, only commits 3/9 and then cancels. when i try to access database in the main menu, i get 20.21.51 # Bagder: that could point to a bug :) 20.22.00 # indeed 20.22.03 # we could busy-loop for a second before reading /proc/cpuinfo :) 20.22.25 # Zagor: you could. It would still all be bogus of course :) 20.22.37 # i look through all the useful tools section of the wiki, hoping there was one which would take the database creation to a pc instead of rb 20.22.44 Quit HellDragon (Read error: 104 (Connection reset by peer)) 20.23.16 # BdN3504: tools/database/ 20.23.22 # iirc 20.23.35 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 20.23.35 # but i couldn't find one. does such kind of software exist? (i.e. one that looks at the device and then creates the respective database files on it) 20.23.36 # I'm thinking about run all makes "nice" by the client btw. 20.23.40 # Zagor: one thing you could do is just look at how long each build takes, and use the build score/build time ratio to sort clients 20.24.03 Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) 20.24.10 # gevaerts: yeah but as far as I understand it tends to vary quite a bit 20.24.22 # yes, build times vary too much 20.24.29 # do i have to compile that myself? is it linux or pc? will i have to just "make" in tools/databse? 20.24.40 Quit amiconn (" .") 20.24.41 # BdN3504: yes, yes, yes 20.24.53 # Zagor: I'd really leave nice values to the people who run it. Some of us use dedicated VMs, so renicing won't buy you anything 20.25.00 # linux or pc-< yes? 20.25.01 # BdN3504: most people run linux on a pc 20.25.10 # i mean windos 20.25.11 # BdN3504: exactly 20.25.12 # :) sorry 20.25.17 # wuindows 20.25.21 # go figue 20.25.40 # well you know what i mean. so it's only linux? 20.25.43 # gevaerts: right, but it does make the mother prioritized over the compilers. the ping response times are worryingly long at times 20.25.45 # is it documented? 20.26.04 Join _lifeless [0] (n=lifeless@188.16.107.31) 20.26.11 # also I don't see how it would be negative 20.26.21 # Zagor: ah yes. I'm not sure if that's the cause though. At least for me, network is *slow* while things are uploading 20.26.56 # uploading uses curl, right? 20.27.19 # yes I think that's the main reason too, I just figured niceing has several positive effects 20.27.26 # gevaerts: curl yes 20.27.50 # Zagor: you're right. niceing shouldn't hurt 20.28.20 # Maybe add the --limit-rate option to the settables? 20.28.33 # could you explain, why the database doesn't work anymore? or is this my device specific problem? does it have something to do with the limitations that can be set within rb? 20.28.49 # People with limited connection probably know how much they can spare 20.30.45 Part cmwslw 20.31.48 # i get "cc1: error: unrecognized option `-Wno-pointer-sign'" when i try make in tools/database 20.32.05 # BdN3504: Have you checked your disk for errors? That seems to be the most common cause of problems. 20.32.23 # yeah, i just ran scandisk on it 20.32.33 # and chkdsk afterwards, no errors 20.34.37 # if i delete all database files form the .rockbox dir on the device (except for the databas.ignores) and try to rebuild it, that should create an immaculate database, shouldn't it? 20.35.29 Quit TheSeven ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") 20.37.48 # bertrik: The Meizu uses the ARM in big-endian mode? 20.38.06 # * bertrik blushes 20.38.15 # I don't know to be honest 20.38.20 # it does 20.39.09 # I think one of the first meizu-related commits was to rockboxdev.sh 20.41.03 # according to the s5l8700 datasheets the CPU can be configured for LE or BE 20.41.17 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 20.42.19 # Bagder: heh, I forgot to zero $wastedtime :-) 20.42.37 # that explains it a little ;-) 20.42.50 Quit flydutch ("/* empty */") 20.42.53 # Zagor: were you trying to suggest something about all this? :) 20.43.40 Join Jaykay [0] (n=chatzill@p5DDC5670.dip.t-dialin.net) 20.44.27 Join TheSeven [0] (n=theseven@dslb-084-056-177-202.pools.arcor-ip.net) 20.44.29 # New commit by 03peter (r21816): More work on PDBox by Wincent Balin. The PDBox plug-in is now working with the pdpod_test.pd file from the PureData.zip archive 20.46.22 # I'm considering not handing out targets someone else is uploading 20.46.28 # linuxstb, why are you asking? 20.46.50 # New commit by 03bagder (r21817): moved the "score" into the builds file, removed the separate score file and ... 20.46.52 # Zagor: that makes sense... 20.46.55 # it requires some extra complexity in the form of a timeout (if the uploading client exits before completion) but it could save some time 20.47.07 # true 20.47.16 # why would it save time? 20.47.33 # Zagor: maybe just put them lower in the sorted list 20.47.46 # right, that could be a sort key 20.48.05 # Bagder: becuase in the case of big >30s targets it is unlikely that anyone will compile+upload in the time it takes for someone to just upload. better then to start on a target that isn't already compiled. 20.48.27 # yes, so we should factor that in in the sorting 20.48.29 # yeah, I meant sorting it away 20.48.38 # makes sense 20.48.49 # it's better to hand out one that hasn't even begun uploading 20.48.53 # * gevaerts thinks that all problems should be fixed by sorting differently 20.49.10 # yes, the sorting is the key to most 20.50.14 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 20.50.16 # but this also requires client changes to notify the server when compilation is done. currently it only suggest that by requesting a new build. but it doesn't say which of its' builds are compiled. 20.50.37 # Zagor: maybe use the log upload? 20.50.42 # Isn't that first? 20.51.05 # I don't want to mix apache logs and the perl script... 20.51.45 # currently the client uploads the log and the zip before saying "completed". only then does the server look for the log. 20.52.21 # bertrik: Because I'm adding a nano2g build target, based on the meizus... 20.52.37 # New commit by 03peter (r21818): PDBox: One file with stuff is enough.... 20.52.44 # hm, yes. To do it cleanly you do need a new command 20.52.53 # linuxstb, could you help create an app.lds for the meizus? I already made an attempt at it. 20.53.38 # bertrik: Possibly. I want to familiarise myself with the 870x first, by looking at the bootloaders. 20.56.44 *** Saving seen data "./dancer.seen" 21.02.17 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 21.04.57 Nick n00b81 is now known as n00b81|away (n=n00b81@unaffiliated/n00b81) 21.06.47 # * linuxstb has a basic nano2g target and wonders whether to commit it, given his previous record with new ports... ;) 21.07.05 Join BryanJacobs [0] (n=bryanjac@cpe-74-67-191-154.rochester.res.rr.com) 21.07.30 # linuxstb: this time it's hardware that several other people also own 21.07.51 # gevaerts: You think it's more popular than the Elio? 21.08.04 # * linuxstb can't believe that 21.08.12 # linuxstb: I think so. Maybe not as popular as the DAX though 21.09.35 # on the topic of new targets... any ideas how to go about cracking the iriver e100's firmware? 21.11.44 Quit thegeek (Read error: 104 (Connection reset by peer)) 21.11.59 # TheSeven: How is memory mapped on the Nano2g? On the Meizus, it looks like (from the Rockbox linker scripts) to have 16MB RAM remapped from 0x80000000 to 0x0, and 256KB of SRAM at 0x22000000. 21.13.11 # 50K BR @0x20000000, 256K SRAM @0x22000000, 1M NOR @0x24000000, 32M SDRAM @0x08000000 21.13.20 Quit freqmod ("No Ping reply in 90 seconds.") 21.13.40 # during boot first BR, and later SRAM is mapped to 0x00000000, however i haven't spotted SDRAM being there yez 21.13.43 # yet* 21.14.23 # So when code is uploaded via iBuggerLoader, SRAM is at 0x0 and SDRAM is at 0x08000000? 21.14.37 # however, if that's better for any reason, mapping SDRAM there is a matter of some control reg writes, i've already tried that and it worked first shot 21.15.38 Join freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 21.15.58 # linuxstb: yes. ibuggerloader uploads to 0x22000000 and jumps to 0x22000020, which maps to 0x00000000 and 0x00000020 respectively 21.16.18 # changing these values is no problem at all, though, as you may have seen in the python script 21.16.37 Quit preglow (Remote closed the connection) 21.16.40 Join preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) 21.16.56 # Do you mean that SRAM is accessible at both addresses? 21.17.02 # yep 21.17.25 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 21.17.31 Join dash32 [0] (n=dash32@p54AB44DD.dip.t-dialin.net) 21.18.47 # TheSeven: I have no opinions yet about where RAM should be mapped to, it's just that I'm currently adapting the Rockbox Meizu code to compile/link for the Nano 21.19.01 # New commit by 03peter (r21819): Another patch by Wincent Balin (from the FS #10416 series): get rid of some warnings. PDBox now builds without any error or warning. 21.20.16 # you could even map SDRAM to zero before your code gets run, through an ibugger script 21.20.25 # just to show you the possibilities 21.20.44 # so if any issues arise from the different memory layout, we can just make it meizu-like 21.23.20 Quit matsl (Remote closed the connection) 21.26.25 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 21.26.55 Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) 21.28.47 Quit stoffel (Remote closed the connection) 21.31.41 Quit QncOPFGl (Read error: 110 (Connection timed out)) 21.32.29 Join QncOPFGl [0] (n=michi@g228061029.adsl.alicedsl.de) 21.36.29 # New commit by 03bertrik (r21820): S5L8700/Meizu: miscellaneous minor fixes, stubs added, keywords set 21.36.37 # bertrik, gevaerts: Do I need a special arm-elf-gcc to compile the meizu builds? It was a while ago when I last ran rockboxdev.sh... 21.36.56 # linuxstb: maybe just try? 21.37.00 # linuxstb, I didn't do anything special 21.37.10 # gevaerts: I did, but get errors about big/little endian mismatches... 21.37.20 # in that case, I guess you do 21.37.30 # Unless my changes have broken it... 21.38.02 # * linuxstb re-runs rockboxdev.sh... 21.38.14 # The rockboxdev.sh changes were on 2008-04-28 21.38.14 # I guess it needs a big-endian libgcc.a 21.39.51 # ahh, I think I've finally got the interspersing loader working 21.40.15 # that was more effort than I thought it would be -_- 21.40.29 # I'm completely sure that I have a rockboxdev setup later than that 21.40.38 # How is code run on the Meizu? Is it written to flash at 0x24000000, and uses IRAM at 0x22000000 for data? 21.40.59 # * BryanJacobs spent half an hour trying to figure out why Wavpack was saying his files were invalid, only to discover that he'd toggled a boolean so that the first chunk was from the second file x_x 21.41.14 # BryanJacobs: Just in time for mid-term evaluation... (although I've already passed you!) 21.41.21 # linuxstb: yay! 21.41.40 # * BryanJacobs is happy that he has something that could potentially be committed, finally 21.41.56 # How much new code is needed in the core? 21.42.00 # this code doesn't interfere with anything except for Wavpack hybrid files with readable correction files present 21.42.38 # around 20 lines in playback.c for the buffering implementation, and around 40 lines in buffering.c to handle codec-specific callbacks 21.43.03 # It would be nice to see the binsize difference - see "rockbox-info.txt" with and without your changes. 21.43.07 # about 5 lines in metadata/wavpack.c to handle adding the callback 21.43.22 # But it sounds about as unobtrusive as it could be... 21.43.37 # it only takes effect when this particular type of file is played 21.43.56 # the only other harm it does is making struct memory_handle and struct mp3entry slightly bigger 21.44.07 # BryanJacobs: you mean you spent weeks on writing 60 lines of code? ;) 21.44.20 # * gevaerts hides 21.44.24 # gevaerts: this was only written since Thursdayish, actually 21.44.40 # and there's also code in the wavpack codec... linuxstb only asked for "in the core" 21.45.00 # I know :) 21.45.42 # oh also there are a few extra arith ops in buffering.c since now widx != available 21.45.45 # gevaerts: Can you answer my meizu question from about 4 minutes ago? 21.46.07 # linuxstb: I don't really know... 21.46.38 # Who would know? markun? bertrik? 21.46.55 # I suspect markun knows this best 21.47.11 # linuxstb, I'm not sure, just look at the link file or .map 21.47.52 # bertrik: Yes, that's what I'm doing. I just wanted someone to confirm my understanding. I can't look at the .map yet though (can't build it...) 21.48.06 Quit notlistening (Remote closed the connection) 21.48.07 Quit darkip (Read error: 110 (Connection timed out)) 21.48.14 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.48.33 # OK, rockboxdev.sh has finished, and the meizu builds fine now... 21.48.38 # linuxstb: IRAM at 0x22000000 sounds familiar, but I have no idea where the code is 21.49.12 # According to the map, code starts at 0x24000000, which the lds says is the flash 21.49.36 # yeah, as far as I can see, it runs from flash and uses only IRAM 21.49.37 # code, data, stack, bss are all in IRAM at 0x22000000 21.49.42 # * gevaerts slaps his forehead 21.50.02 # bertrik: you *can* run directly from dfu, but you have to change the .lds then 21.50.13 Nick n00b81|away is now known as n00b81 (n=n00b81@unaffiliated/n00b81) 21.50.13 # petur: just spotted filenames like rsqrt~.c in pdbox. Are those filenames correct? Looks quite strange 21.50.24 # they are 21.50.35 # both strange and correct ;) 21.50.40 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 21.50.43 # gevaerts, you mean we could build our own "SST39VF800.dfu"? 21.50.45 # ok. Weird, but well :) 21.51.17 # bertrik: something similar anyway. I'm not sure if I'd use dfu for the second stage 21.51.50 # So currently you permanently flash a bootloader via dfu? 21.51.59 # yes :) 21.52.39 Quit mcuelenaere () 21.54.46 # bertrik: see firmware/target/arm/s5l8700/boot.lds for the DFULOADADDR bit 21.56.11 # New commit by 03zagor (r21821): Added sub 'command' to reset ping timer each command. Added timer to measure and report ping response time. 21.56.12 # well flashing the bootloader worked so far for me for getting the basic drivers implemented 21.56.47 # we probably still need to think a bit about the whole rockbox bootloading process 21.58.29 # like, how to dualboot rockbox with the OF on the meizus 22.00.57 # linuxstb, the NOR image of the OF contains just basic setup code and a Rar archive that is extracted to DRAM. The Rar takes about 600k of the total 1 MB NOR, so we have some room here 22.04.16 # linuxstb: ipods are little-endian btw. 22.04.29 # at least unless you switch it :-P 22.07.03 # TheSeven: Yes, I assumed that (from your code) 22.07.19 Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) 22.07.45 # just wanted to clarify this because you were talking about needing a bigendian libgcc 22.07.50 # bertrik: Is the OF available unencrypted? 22.08.06 # TheSeven: Thanks. But that was just so I could compile the meizu builds 22.08.15 # ok 22.09.00 Join JdGordon| [0] (i=43a02c5a@gateway/web/freenode/x-539d944851b9861f) 22.12.53 # I have seen a mail on the Dpeech Dispatcher mailing list about a plugin to use speech dispatcher in rockbox. This must mean that the writer is ruunning rockbox in linux for this to work, is that right? 22.14.50 # notlistening: or is he talking about using the dispatcher to create voice files? 22.20.56 Join pixelma [50] (n=pixelma@rockbox/staff/pixelma) 22.21.01 # yeah need to check with the guy it is not clear 22.22.11 # New commit by 03zagor (r21822): Report to server when zip upload starts. Run make with nice. 22.22.34 # Do 60GB ipod 5Gs exist with 400mAh batteries instead of 600mAh? Also is there such a thing as a 60GB 5.5G ? 22.23.10 # stripwax: in the world of refurbished players, who knows? 22.23.39 # Especially 60GB 5.5G sounds reasonably likely 22.24.09 # yeah. specifically I'm wondering about FS#8596 and whether the battery on my 60GB 5G is actually materially different to Uchida's 22.24.40 # Or, indeed, whether my battery is somehow an outlier with better stats and Uchida has the standard 60GB 5G battery 22.25.00 # linuxstb, yes 22.25.37 # New commit by 03zagor (r21823): Accept _UPLOADING response... 22.26.24 # If the 400mAh and 600mAh have different discharge curves, do that just mean we need to define BATTERY_TYPES_COUNT to 2 for ipodvideo and setup two curves? 22.26.30 # ^do^does 22.28.24 # I doubt they have different curves. don't curves look pretty much the same for each battery chemistry? 22.30.01 # Perhaps; his readings seem to be consistently 100mv or so below mine so maybe the specs of the cell (rather than the chemistry) is somehow different 22.30.22 # bertrik: So you could modify that file to include a Rockbox bootloader? 22.30.50 # nearly 200mv actually 22.30.59 Join Ubuntuxer [0] (n=johannes@dslb-094-221-090-086.pools.arcor-ip.net) 22.31.16 # stripwax: that's a lot. is the lower voltage the "400mah" battery? 22.32.34 # Zagor - that's something I would like to find out .. his runtime is about two-thirds of mine, and his discharge curve matches the current Rockbox ipod 30GB (400mAh) curve, so that is my suspicion. 22.32.50 # (and his has the lower voltage, yes) 22.32.51 # linuxstb: the meizu OF is basically an 8K unrar tool followed by a rar archive that has the main binary 22.33.24 Quit bmbl ("Bye!") 22.33.47 # gevaerts: Do you have a copy? 22.34.29 # But I guess there's not much point in implementing a "real" bootloader until you can read from the NAND... 22.34.42 # linuxstb, sadly so 22.35.05 # stripwax: these are single-cell batteries, aren't they? liion cells are 3.7V. starting out 0.2V lower than that looks like a malfunction to me. though I'm no battery guru. 22.35.15 # bertrik: Is that going to be troublesome? e.g. is there an unknown FTL? 22.35.18 # * Unhelpful is going to go ahead and add the addtargetdir and asmdefs changes... not any of the crossdev changes yet, though. 22.35.29 # Would be very useful to see other users'/dev's discharge curves for 30GB 5G models and 60GB 5G models. 22.35.41 # stripwax: indeed 22.35.55 # linuxstb, it uses the 'whimory' FTL 22.36.19 # linuxstb: I have some OF copies, yes 22.36.28 # the openiboot project has some read-only code for it apparently, but nobody took a serious look at it AFAIK 22.37.03 # Zagor - mmm.. so, my starting voltage is reported as something like 4.2V. His is starting out 4.1V ish. My ending voltage (where the knee really kicks in) is appx 3.8V; his is a shade over 3.6V. 22.37.07 # bertrik: So that's used on all the new ipods? 22.37.27 Part Ubuntuxer 22.37.38 # linuxstb, I don't know for sure 22.37.45 # linuxstb: I think that's the suspicion as its mentioned in the nano2g and used by the iphone 22.37.55 # Zagor - if the cell is 3.7V, I'd have thought the starting voltage would be 3.7V 22.38.21 # I'm also no battery guru 22.38.22 # stripwax, most battery benches I've seen had their knee at about 3.6V 22.38.42 # IIUC 4.1x to 3.7 applies to all li-ion 22.39.23 # kugel: so 3.7 is basically the floor voltage? 22.39.25 # linuxstb: do you want some to have a look? 22.39.42 # gevaerts: Yes, I'll have a quick look at one. 22.40.02 # Zagor: that's how I understood it, yes. I.e. you should shut down soonish of you go under 3.7V 22.40.13 # i can't fix my database, can anyone help me? please, just say yes or no, because i won't stick around if nobody is willing... 22.40.15 # Li-Ion/Li-Poly: Full: 4.15-4.25, Empty: 3.4-3.7 22.40.29 # gevaerts: I'm guessing a similar technique to mktccboot will work for dual-boot. 22.41.01 # linuxstb: I haven't looked at that one yet 22.42.32 Quit BdN3504 ("CGI:IRC (EOF)") 22.42.33 # is there any objection to changing the substitution in functions.make so that the dep is on $BUILDDIR/lang/lang.h instead of $BUILDDIR/lang/lang_core.o? the former will be used anyway if make dep is run after those files are generated. 22.43.29 # Unhelpful: but make dep isn't run after those files are generated 22.43.34 # TheSeven/kugel - cool, thanks. So having 3300 as 'battery level dangerous' and 'battery level shutoff' doesn't make sense? 22.43.44 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 22.43.44 Quit pixelma (Nick collision from services.) 22.43.44 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 22.44.02 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 22.44.12 # stripwax: <3.3 will heavily damage it, so that's about the lowest you may ever go 22.44.13 # stripwax: that sounds quite dangerious 22.44.19 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 22.44.22 Quit mt (Read error: 104 (Connection reset by peer)) 22.44.23 # Zagor: really? i tend to run it occasionally to make sure deps aren't out of date. 22.44.42 Quit pixelma_ (Client Quit) 22.44.49 # normally you'll only go to ~3.6, but i've also seen devices going to 3.4 regularly 22.45.05 # probably depends on some manufacturing details whether the cells survive that or not 22.45.24 # >4.25 is also an easy way to kill them 22.45.36 Quit BryanJacobs ("Java user signed off") 22.46.01 # TheSeven - hm, but fully charged my battery reports >4.25 .. 22.46.06 # this battery manufacturer shows curves down to 3.0V : http://www.atlbattery.com/eng/Psheet3038.html 22.46.31 # however, because of the discharge curve of li-ion, the runtime will not be a big difference between 3.4 and 3.6 22.47.04 Join ybit [0] (n=ybit@unaffiliated/ybit) 22.47.06 # a lot of rockbox targets have their shutdown limit at 3.3V 22.47.36 # also, i simplified addtargetdir.pl a bit locally... splits the whole input into files, and one regexp determines whether a file is a target (ends in :), a fully-specified source (starts with /) or if it needs a prefix added. this is in anticipation of asmdefs, which addes some more generated headers. also, it eliminates all of the special-case sed rules from mkdepfile, except for the lang headers that need a dir added. 22.47.43 # the manufacturers always max this out :-P 22.47.58 # however, they definitely live longer if you don't go below ~3.4 22.48.07 # 3.0 should really be avoided 22.48.17 # what could be causing rockbox to skip songs after about 1:30 into the song? 22.48.19 # so maybe we should increase this a little, say give a warning at 3.6V and shut down at 3.4V? 22.48.38 # Unhelpful: actually I don't remember why it looks like this. :) if it works, go ahead. simple is good. 22.48.49 # warning at 3.6 is a good idea, as it will very quickly go down from that point 22.49.26 # ybit: What kind of songs (what audio format?) and what device are you running Rockbox on? Does it always happen on every song/ 22.49.40 # Zagor: i actually just realized that the special cases can be cleaner/safer if the sed is before addtargetdir... i'll fix that up and test it before commit. :) 22.50.05 # i don't think addtargetdir needs a rename for this, seeing as that's still what it's really doing 22.50.59 # linuxstb: since the meizu OF uses clearly separated loader and main binary, we can basically do whatever we like I think 22.51.15 # Unhelpful: I agree 22.51.16 # TheSeven - mine would appear to go down very quickly after about 3.8, 3.6 probably critical, I doubt mine would even go as low as 3.4 judging by the battery bench 22.51.46 # well, that depends a lot more on the electronics than on the battery 22.51.54 # (although the other guy's battery in FS#8596 looks like it's fine to 3.6V, then fast from 3.6V to 3.4V) 22.52.14 # kugel: is there any reason to not commit the custom vp patch as it is, and fix up any redraw issues as they come up? 22.52.15 # if shutoff limit is 3.3, it will shut off at 3.3, at least as long as the electronics are capable of operating at that voltage 22.52.15 # I'm wondering what could cause the differences 22.52.38 # bluebrother: The "~" sign at the end of the operator in Pure Data means that the operator works with sound signals (as opposed to control signals). More evident example is "osc~". 22.52.40 # JdGordon|: not really, I actually have a quite committable version here 22.52.56 # either different manufacturer with slightly other discharge curve, or maybe just measuring issues? 22.53.03 # wincent: they use hungarian filenames? 22.54.17 # gevaerts: Not that I am aware of. But "~" looks like a sine curve, does it? 22.54.56 # TheSeven - I'll rerun a couple times and see if I can get same reproducible result. Battery is stock and I'm assuming the curve already in powermgt-ipod-pcf.c was also on stock battery. Could 200mv diffs be a tolerance issue alone? 22.55.14 Join gregzx [0] (n=chatzill@dsm195.neoplus.adsl.tpnet.pl) 22.55.19 # wincent: it does a bit, yes :) 22.55.39 # Zagor: is there a reason i'm not understanding behind the used of $(1)_ as the output file in mkdepfile? 22.56.02 # nevermind, i see now :/ 22.56.29 # stripwax: depends on the technology they use for measuring it. probably some kind of resistor-based voltage divider connected to an ADC. if these are 10% tolerance resistors, and one is 10% too high, and the other one 10% too low, that could be the issue 22.56.48 *** Saving seen data "./dancer.seen" 22.56.50 # Unhelpful: I guess a small comment would be in place... 22.56.53 # if it's just a constant factor that your curve seems to be off, then you're probably having a measuring problem 22.57.09 # Zagor: i'll add that, too, then :) 22.57.54 # linuxstb: every song 22.57.56 # mp3s 22.58.00 # ipon nano 22.58.20 # TheSeven - would it make more sense then for rockbox to use the actual min/max observed measured voltage rather than hardcoded readings that may differ due to tolerance? 22.58.21 # well, it doesn't skip @ the 1:30 mark every song 22.58.36 # it might be the files, who knows. i'll monitor it a little longer 22.59.17 # (I realise that the answer may be 'yes but that hasn't been implemented anywhere' of course :-) 22.59.21 # And what exactly do you mean by "skip"? It moves to the next track? 22.59.31 # stripwax: depends on the hardware. if there is some kind of hardware shutoff at 3.3 or some such, one could try calibrating to that. however generally these measurements don't seem to be off that badly 23.00.04 # maybe it is just a different battery chemistry, like LiIon vs. LiPolymer 23.00.32 # bertrik - presumably both ipod batteries have the same chemistry? or is the hardware capable of charging both 23.02.37 Quit _zic (Remote closed the connection) 23.03.06 # li-poly vs. li-ion is the same charging strategy 23.03.18 # maybe voltage levels tuned by 0.05V or some such 23.03.47 # interesting. judging by your numbers then my battery sounds more like a li-poly than a li-ion but I imagine I would have to dismantle the ipod to find out :( 23.04.34 # li-poly usually have slightly higher voltages than li-ion (as far as i've observed) 23.04.39 # All supported irivers, iaudios and ipods have LiPoly batteries. Only the archos FM/V2 Recorder has plain LiIon 23.04.40 # however, they're very very similar 23.06.19 # amiconn - not according to this (which could very well be totally wrong) http://www.ipodbatteryfaq.com/ipodbatteryandpower.html 23.06.20 # Not only those, but most others, except the few with AA or AAA rechargeables or non-rechargeables 23.07.34 # I'm quite sure this list is incorrect if they write LiIon, although the two types are very similar wrt chemistry 23.07.45 Join dmb [0] (n=Dmb@unaffiliated/dmb) 23.08.07 Quit n1s (Remote closed the connection) 23.08.46 # ok 23.09.30 # LiIon has a bit lower voltage, and needs a solid metal case 23.09.48 # All those foil wrapped "LiIon" batteries are in fact LiPoly 23.10.00 # http://en.wikipedia.org/wiki/Lithium-ion_polymer_battery 23.10.33 # great info, thanks! 23.10.49 Join RalpH_himself [0] (n=deadeye@adsl-62-167-69-5.adslplus.ch) 23.11.05 Part RalpH_himself 23.13.42 Quit dash32 (Read error: 110 (Connection timed out)) 23.14.31 Join dash32 [0] (n=dash32@p54AB5496.dip.t-dialin.net) 23.19.11 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.19.21 Quit Xerion (" ") 23.22.45 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 23.23.52 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.25.56 # New commit by 03zagor (r21824): Down-sort builds that are being uploaded. Upsort zip builds without changing score values. 23.26.59 Quit JdGordon| ("Page closed") 23.27.03 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") 23.27.54 Quit Thundercloud (Remote closed the connection) 23.36.39 Join robin0800 [0] (n=kvirc@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.39.55 # JdGordon: ping 23.42.45 Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 23.43.02 Quit robin0800 ("KVIrc Insomnia 4.0.0, revision: , sources date: 20090520, built on: 2009/06/08 19:18:46 UTC http://www.kvirc.net/") 23.45.08 Part robin0800_ ("No matter how dark the night, somehow the Sun rises once again") 23.46.32 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.46.59 # kugel: brup 23.47.01 # burp 23.47.08 # pong 23.47.30 # I'm going to post a new customlist patch in a few minutes 23.48.34 # ok 23.48.50 # im about to ruin my day by heading into work so ill look later 23.48.59 # it is sunday! 23.49.11 # I'd like to get in in soonish, we can work out the bugs later 23.49.26 # I know.... but i want to take time off so need to make up sundays :( 23.49.43 # and it is...almost 3 23.49.45 # * JdGordon dosnt have the willpower to work from home 23.50.27 # * scorche|sh is apparently watching a bunch of guys stand around on TV 23.51.31 # space shuttle going off today.. 23.51.36 # JdGordon: "we work out bugs later" as in you point to me when a report comes in? :p 23.51.47 # something like that 23.51.49 # * gevaerts shoves people into the other channel 23.51.59 # * scorche|sh notices that he is in the wrong channel and blames JdGordon 23.52.06 # JdGordon: btw, you broke themes with the statusbar work. 23.52.19 # * JdGordon hides 23.52.24 # such as cabbiev2, it has "statusbar: on" in the settings 23.52.39 # yeah, forgot to fix that.. ill do it now 23.54.49 Quit bluebrother ("leaving") 23.55.27 # arg... perl :'( 23.57.22 # who knows wpsbuild.pl? 23.57.42 # I touched it 23.58.00 # you need to look at WPSLIST though 23.58.14 # i've modified both...