--- Log for 04.12.109 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 14 hours ago 00.02.13 Quit robin0800 (Remote closed the connection) 00.09.34 Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) 00.10.58 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.12.42 Part froggyman 00.13.47 # New commit by 03rmenes (r23838): Another round of plugin keymaps for the Philips GoGear SA9200. ... 00.15.25 # Crap, I accidentally committed an unwanted change to utils/MTP/beastpatcher/Makefile 00.15.34 # I need to revert to the previous SVN revision. 00.17.31 # Unhelpful: Full screen mono bitmap in iram. Everything else would be too complex imo 00.18.05 # JdGordon|: No testing from my side before late Sunday evening (CET) 00.20.28 # ok, ill test in the sim then... I really want this in before the weekend 00.21.20 Quit LambdaCalculus37 ("Leaving") 00.23.25 Join liar [0] (n=liar@83.175.83.185) 00.27.58 Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-huybfygmrkqfbqhj) 00.28.04 # :grmbl: 00.29.44 Quit hebz0rl ("Ex-Chat") 00.30.38 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 00.37.17 Quit tomers ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") 00.37.25 # rjg: http://www.rockbox.org/irc/log-20091203#22:19:03 would be a more stable link 00.39.07 # thanks gevaerts, I'll edit it 00.39.30 # left it too long to edit it now 00.39.51 # oh no 00.39.56 # session timed out that's all 00.40.52 # sorted 00.44.17 # rjg: I don't do advanced playlist manipulation often, but isn't what you want pretty similar to "Play Next" (http://download.rockbox.org/daily/manual/rockbox-h100/rockbox-buildch4.html#x7-680004.4.3 )? 00.44.27 Quit captainkwel ("Page closed") 00.45.31 # rjg - right, if you forget the fact that it's called a playlist, sounds like you want something like Play Next, Queue Next or Party Mode 00.47.15 # yeah, simply to play that file next and just continue through the filesystem from that point on as would normally happen, just don't immediately do it, but wait till the song's finished 00.48.29 # Play Next seems to only queue the single file you selected, and not the rest of the directory. The waiting bit is the same as what you want I think 00.51.02 # play next queues the currently playing track and prepends it to a new playlist built using the selected file/folder as the list 00.51.33 # yeah, actually, something really f*cked up just happened there - let me see if I can reproduce what just happened 00.52.15 # amiconn: that grumble was to me right? the people being annoyed by the current statusbar redraw issues far outnumber those that will be annoyed if charcell isnt working correclty 00.53.30 # right, the play next, it played the file I'd selected then after that it skipped to the next directory entirely and continued from there 00.53.41 # then I did play next again and it completely ignored it 00.54.21 Quit soap () 00.54.24 # JdGordon|: feel free to shout if I missed some things, but weren't there some GUI issues that need the remaining sbs FS tasks to be fixed? Am I understanding your mail correctly as proposing to not have those in 3.5? 00.54.34 # * gevaerts probably misses something 00.54.48 # thats correct 00.55.19 # its either fix niggly issues with lots of bandaids, or fix them all with one big hammer 00.55.24 # but yeah, something which simply did the absolute exact same thing as just selecting a file in the file browser but only once whatever is playing has finished, is what I'm after 00.56.01 # branch already? didn't we used to have a freeze period before branching? 00.56.25 Join soap [50] (n=soap@rockbox/staff/soap) 00.56.57 # rjg: well, if it's close to something that's already there, and you manage to describe it in terms of existing functionality, I think it increases your chances of getting it :) 00.57.13 # freezing before the branch doesnt make any more sense than branching instead of freezing 00.57.22 # sure it does 00.57.27 # especially when bugs arnt going to get fixed in either branch 00.57.28 # well, fingers crossed gevaerts :) 00.57.47 # I would write a patch myself, but I'm no coder unfortunately 00.58.12 # * JdGordon| is trying to cause the least amount of pain to everyone 00.59.44 # JdGordon|: the point of freezing is to allow fixing serious and/or obvious bugs without having to do the work twice. Branching first means that you will miss some merges, or that some bugs will be considered too minor to risk destabilising the release branch 01.00.02 # That means that branching without freezing causes *more* pain for everyone 01.00.45 # I disagree 01.00.50 # I know 01.01.03 # You also think that testing is useless 01.01.21 # the first reason I agev was to give users time to test 01.01.26 # gave* 01.01.28 # rjg - so I think you can just Play Next the directory, rather than the single file, by selecting the directory (rather than the single file). Does that do what you need? 01.01.30 # and no i dont 01.01.43 # users should start testing as soon as we freeze, not as soon as we branch 01.02.20 # ok, so lets just release today anyway seen as its entirely arbitrary 01.02.44 # * gevaerts seems to be unable to understand JdGordon| at all 01.03.07 # stripwax: not really, because there's times I don't want to play the entire directory, just play from a file onwards just like playing a file in the file browser 01.03.12 # the freeze is pointless because bugs dont get fixed during it, it just annoys people who want to keep working 01.04.12 # the only reason to not branch early is to give me one MASSIVE inconvienice because I know this shouldnt go in before release 01.04.36 # it's *not* pointless if people get a chance to point out bugs 01.04.46 # rjg - hm. so you want to play the whole directory but starting at some file you select onwards (and set it so that it doesn't play it immediately, but starts playing that file when the current one finishes, and then the rest of the directory follows that) ? What happens if you want to play a new track before it's finished the directory (just throw away the rest of the directory and replace it with the new directory) ? 01.05.02 # Why is it that you seem to be opposed to *any* proposal that's meant to improve the quality of our releases? 01.05.11 # yes stripwax, absolutely 01.05.42 # rjg - mm, could you just insert the directory, and then delete the tracks from the playlist that you don't want to hear? 01.06.00 # yes I could but that's a bit of a faff imo :) 01.06.04 # heh 01.06.05 # gevaerts: you are obvisouly completly missing the point... I'm getting frustrated with the sbs stuff.. that means I either commit now and make the release WORSE, or sit on it for another month which I'm just not going to do 01.06.11 # especially if controlling the player one handed in a car 01.06.20 # releasing/branching now is a relativly stable point and has no down side? 01.06.25 # s/?/! 01.06.33 # and actually that wouldn't help - as it would play from the start of the dir 01.06.39 # and it might be track 3 I want to hear next 01.06.52 Join Hillshum [0] (n=hillshum@75-165-233-21.slkc.qwest.net) 01.06.54 # JdGordon|: if you think that committing now makes the release worse, you shouldn't even be thinking about committing it, even if the release was three years away 01.06.58 # rjg - right that's what I mean (insert the directory into the playlist but then delete track 1 and track 2 from the playliust) 01.07.00 # and while listening to track 3 I might think "yeah I like track 4 too, I'll leave it playing" 01.07.24 # gevaerts: no, the atch makes things better... but it effects people 01.07.32 # JdGordon: That build you gave me works fine at first glance. Anything specific to check? 01.07.42 # but then go "enough of this, I want to play X album from track 6 now" 01.07.55 # if it makes things better, how in hell can it make the release worse? 01.07.56 # understood. 01.07.57 # Hillshum: thanks :) plugins being funny, screens beign funny... different themes not working 01.08.08 # Okay 01.08.36 # rjg - possibly naive question but what would you want it to do when it gets to the end of that directory? 01.08.56 # gevaerts: it reworks a big part of the GUI... I'm happy with it but I obviously havnt tried every screen... it changes the inbuilt statusbar behaviour 01.09.35 # I'm completly OK with commiting it tonight, but then there is no guarentees that graphical glitches dont get worked out before xmas 01.09.49 # stripwax: continue to the next directory :) 01.09.50 # * JdGordon| is looking out for the users here (for some retarted reason) 01.09.52 # aren't there graphical glitches now? 01.09.56 # yes 01.10.46 # those hopefully will all be removed, but new ones might be added... I dont know because noone wants to help test 01.12.22 # rjg - yeah, thought you'd say that :) basically i'm trying to think how to generalise that, it's as you say, exactly the same as just playing a track, except with the track change not happening immediately but happening after the current track has finished. Definitely cannot be done now, sounds like it wouldn't be too hard, and (yet another) playlist insert mode 01.12.45 Join GeekShado_ [0] (n=Antoine@APoitiers-552-1-27-18.w86-217.abo.wanadoo.fr) 01.12.55 # We really do need to find a way to rationalise all those Insert/Queue/After/Next/End/Shuffled items into something nicer (esp. given that there's combinations missing). 01.13.11 # rjg - and I think I'd probably use your play mode too, if it were there :) 01.13.33 # JdGordon|: If we manage to get better testing of RC builds, and we manage to get this testing started at freeze time, I think committing now is the best thing to do. If we don't manage to get testers (and we actually ask for it and provide some guidance...), I think we can honestly say that we did our best... 01.13.44 # stripwax: that's good to hear :) 01.15.00 # I think the setting would look similar to the existing "warn before erasing dynamic playlist" setting -- a new setting like "preseve currently playing track before erasing dynamic playlist" 01.15.40 # yeah that could make sense 01.16.02 # Committing something knowing that it breaks things shouldn't be done, but committing something after doing reasonable testing, and then fixing issues as they appear, is perfectly reasonable I think. Today, we are *not* in a freeze, and "there will be a freeze soon, so let's be more careful" is silly, as that is what the freeze itself is supposed to be 01.16.19 # gevaerts: I'm not sure how that actually changes anything... I'm proposing take a known state and call it the RC, or keep going and maybe have a dodgey build in 3 weeks.. if then we decide its better quality use that instead 01.16.43 # breaking here isnt crahsing breaking... 01.16.50 # Right now, when you just select a track, it (and the rest of its directory) gets put into a blank dynamic playlist. If that setting is true, the only difference is that the currently playing track gets bubbled to its own spot at the top of the playlist and the new tracks go after it. I might have a stab at doing that (doesn't sound too hard) 01.17.10 # ^that setting^that imaginary new setting 01.17.16 # "if then we decide its better quality use that instead"? You mean suddenly import big features from trunk? 01.17.59 # if its deemed better quality sure 01.18.04 # If we do RC builds, trunk will *not* be tested enough for that 01.18.14 # trunk isnt tested anyway 01.18.21 # releases are stupidly arbitrary 01.18.23 Quit efyx_ (Remote closed the connection) 01.18.30 # and you *never* do that sort of thing if you want to have a chance of having a stable release 01.18.41 # * JdGordon| makes it clear, these patches dont break code.. they change user experience 01.19.18 # this is why I'm saying branch now.. its stable, and we can release them in 1 week or 4 weeks dependaing on how much testing it actually gets 01.19.43 # JdGordon|: I thought your patch is good? 01.19.56 # patch is good 01.19.58 # why do you think it makes the release worse? svn is rather broken 01.20.35 # cool stripwax, that's great :) let me know how you get on with it 01.20.39 # You're basically saying that we should totally change the release schedule because it happens not to match your personal schedule, and to hell with all other considerations 01.21.01 # half the issue is explaining the function properly, which you have done I think 01.21.50 # rjg - I'll add a patch sometime soon (look out for it on the patch tracker on rockbox.org) 01.21.53 Quit GeekShadow (Read error: 113 (No route to host)) 01.22.34 # cool stripwax, I'll need to get all the SDK stuff and attempt to get it working :) 01.22.36 # having a set release date was never a good idea for exactly this reason... having a rough date makes 1000x more sense... there is nothing saying that the build in X days will be more stable than todays.. EVER.. 01.22.55 # the release is a build we think is good and stable 01.23.20 # knwoing that there is a good chance that some instability (whatever that means) is coming is a good excuse to release 01.23.43 # and if it ends up being better great.. and if it ends up begin dodgey then its good we released a bit eariler than expected 01.23.47 # Also, the radio works on my clip for the logs 01.24.09 # JdGordon|: the current code is *broken* 01.24.16 # * kugel also disagrees that freeze is useless 01.24.16 # indeed 01.24.46 Quit pamaury ("exit(*(int *)0 / 0);") 01.24.46 # you also didn't answer my question 01.24.52 # its not broken in a way that users care about (look at FS.. the bugs in that area havnt been jumping) 01.25.09 # You're saying that we should release broken code, because the fix might not work well. Why don't you just commit some random changes then? If you're lucky, you'll get lots of red, which clearly means that we should then release right away 01.25.25 # the current bugs arnt gonig to be fixed 01.25.31 # not by me anyway... 01.25.46 # not outside of the work I've done to remove the issues I mean 01.25.59 # what is that supposed to mean? 01.26.29 # this patch changes stuff in a way that removes those bugs 01.26.39 # CHANGES and breaks user expectations 01.26.58 # although not really because the change has had plenty of warning 01.27.20 # how does fs10824 change the user experience? 01.27.33 # you cant force the statusbar on 01.27.41 # fm/rec screens make this obvious 01.27.56 # what about %we? 01.28.09 # stripwax: updated the forum post with what you've said 01.28.09 Quit fyrestorm ("Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!") 01.28.11 # that enabled the theme 01.28.13 # not the inult bar 01.28.18 # rjg cool 01.29.17 # * JdGordon| did bring up the qeustion of %we quite a while ago... it doesnt exactly make sense anymore 01.29.43 # If behaviour changes, you document that in the manual, and possibly in the release notes. If that were a reason to not commit before a release, it would also be a reason not to commit at all. Or is it that you think too many devs are opposed to your changes? 01.31.12 # JdGordon|: for you... 01.31.21 # while I'm in rockbox mode I might try to fix the DGT theme so that it doesn't go spaztastic on newer builds like it currently does 01.31.50 # kugel: ok, whats it supposed to do whent here is no such thing an an inbuilt bar anymore? 01.32.07 # gevaerts: its alot less headache for everyone if we release before this change 01.32.32 # JdGordon|: OK, fine. Then this change goes in in two weeks 01.32.37 # I also think that certain areas arnt entirely ready yet, but cant be fixed in this patch 01.32.59 # why does the date matter? 01.33.11 Quit stripwax ("http://miranda-im.org") 01.33.16 # that really inconvieniences me and doesnt have any positive affect on anyone 01.33.40 # Sure, you don't see a positive effect, so it doesn't exist 01.33.44 # deactiving the sbs bar maybe? 01.34.12 # gevaerts: so list one then 01.34.32 # kugel: I'm not sure how that makes sense.. thats what %wd does 01.34.46 # enable it, then 01.34.52 # its always enabled 01.35.08 # JdGordon|: you're the one who wants to drop the freeze, so you should explain why. All you've said comes down to "But I want to commit this thing that shoudln't be in the release today!" 01.35.19 Join Casainho [0] (n=chatzill@87.196.81.204) 01.35.31 # Almost everyone else thinks that the freeze is a good idea 01.35.38 # have a 3 week freeze/RC isnt dropping the freeze 01.36.09 # right, that's one of your other changes 01.36.26 # You're proposing to branch today, and then go wild in trunk. How is that not dropping the freeze? 01.37.09 # * kugel thinks JdGordon| is pretty ignorant these days 01.37.11 # JdGordon|: Branching now *is* dropping the freeze 01.37.29 # Because the current plan is to have a week where there's no branch, just freeze, then a week where there's a branch but work can resume on the main codebase. 01.37.57 # go back and look at the amount of commits during the freezes.... 01.38.22 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 01.38.28 # looking for what? That statement on its own doesn't tell what point you're trying to make, since it's obviously an opinion of some sort. 01.38.31 # Were there too many? Too few? 01.39.22 # ok so fuck it... I'll commit it because it improves code quality 01.39.40 # Because you can't wait two weeks to do so? 01.40.35 # it fixes bugs, I think 01.40.38 # because waiting 3 weeks is stupid because it will net exactly 0 more testers 01.40.57 # But you already said you don't think it should go in the release. 01.41.08 # So rather than inconvenience yourself you're saying "screw it, I'll inconvenience everyone" 01.41.49 # no... it fucking changes user expectations.. and releasing now has no NEGATIVE effect on ANYONE other than "oh no we released 3 weeks before we said we would" 01.42.20 # brnaching still lets people commit bug fixes if they want to 01.42.27 # You keep talking about changing user expectations. If that's a bad thing, why does the patch exist at all? 01.43.00 # JdGordon|: Releasing now has the negative effect of "everyone who planned some time to try to get things cleaned up or fixed for the release now can't do it" 01.43.01 # because 2 months ago I said "this is whats happening" and had no objections... 01.43.19 # You're assuming people would never, EVER plan ahead and say "we've scheduled a freeze this week during which I can try to take a hard look at this problem" 01.43.44 # which you can do anyway if you were so inclined 01.43.59 # fix the bugs in the branch.. why is that a big deal? 01.44.16 # JdGordon|: Because people can magically change their schedules to fit your whims? 01.44.28 # Maybe people are busier this week? 01.44.50 # so they can do it next week.. or two weeks... 01.44.55 # You said "releasing now" 01.44.56 # did you actually read the damn email? 01.45.01 # JdGordon|: while in the meantime you've been diverging trunk and the release branch, so it gets a lot harder to move fixes between them? 01.45.03 # I'm responding to what you're saying *in here* 01.45.08 # Because we're talking *in here* 01.45.12 Part toffe82 01.45.18 # I responded to your email in the email 01.45.30 # * gevaerts doesn't think it matters whether people have read the email, because the email doesn't make much sense anyway 01.45.45 # The freeze should be a freeze, whereas the branch should be for an RC and should receive as few fixes as possible, which means there still needs to be a freeze period 01.45.56 # Which means your commit is still delayed at least two weeks if the branch is going to stay short 01.46.00 # Which solves nothing for you personally 01.46.19 # Unless you just make it a branch with no separate freeze, which is something that was argued for, and failed, back when we set up the freeze then branch. 01.50.57 Quit Thundercloud (Remote closed the connection) 01.59.29 *** Saving seen data "./dancer.seen" 02.03.23 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.06.16 Quit robin0800 (Remote closed the connection) 02.08.58 Quit dmb ("Leaving") 02.12.21 Join CaptainKewl [0] (n=jason@64.121.176.61) 02.16.06 Nick fxb__ is now known as fxb (n=felixbru@85.214.97.64) 02.16.27 Join JdGordon1 [0] (n=jonno@174-145-129-184.pools.spcsdns.net) 02.24.06 Join moonscapex [0] (n=moonscap@d75-159-168-71.abhsia.telus.net) 02.35.53 Quit binaryhermit (Read error: 110 (Connection timed out)) 02.45.42 Quit GeekShado_ ("The cake is a lie !") 02.46.30 Quit Urexis () 02.51.47 Quit DerPapst ("Leaving.") 02.54.22 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 03.00.42 Quit moonscapex ("http://rbsansa.webs.com") 03.01.50 Join Sajber^1 [0] (n=Sajber@h-143-7.A213.priv.bahnhof.se) 03.03.38 # evilnick: you wanna find out if lambda is going to revery the accidental MAkefil commit? 03.04.00 # probably not a good idea to leave it in... 03.05.12 Quit Sajber^ (Read error: 60 (Operation timed out)) 03.06.46 # amiconn: that would get ugly for the antialiased cases because of the larger size of stored pixels. 03.08.58 # 9600B for the 4bpp whole-pixel AA fonts that the current patch uses, 15360B for subpixel (both on beast, although i believe there are a couple of 640x480 unsupported targets?) 03.09.05 Quit JdGordon1 (Read error: 110 (Connection timed out)) 03.12.05 # i'm also not sure transposing font glyph bitmaps is worthwhile, but something that might be would be storing groups of bytes in the buffer as host ints, so that we can load word-at-a-time 03.13.56 Quit parafin (Read error: 60 (Operation timed out)) 03.14.15 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 03.15.55 Nick Strife89 is now known as Strife1989 (n=Strife89@adsl-146-197-34.mcn.bellsouth.net) 03.16.18 Join Strife89 [0] (n=michael@adsl-146-197-34.mcn.bellsouth.net) 03.16.45 Quit Strife1989 ("If you hold a Unix shell to your ear, you can hear the C.") 03.18.13 Join parafin [0] (i=parafin@paraf.in) 03.21.56 Quit MethoS- (Remote closed the connection) 03.23.23 Quit parafin (Read error: 60 (Operation timed out)) 03.26.16 Quit HBK (Read error: 110 (Connection timed out)) 03.26.22 Nick KBH is now known as HBK (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 03.27.06 Quit sbhsu ("leaving") 03.30.11 Nick fxb is now known as fxb__ (n=felixbru@85.214.97.64) 03.31.27 Join parafin [0] (i=parafin@paraf.in) 03.33.15 Quit kugel (Read error: 60 (Operation timed out)) 03.34.58 Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) 03.35.33 # JdGordon: I have some time to do testing on your patch - which one was it 03.35.58 # I would like to see the fixups go in because as it stands the custom statusbar stuff is pretty broken 03.36.23 # (commenting about the mailing list) 03.36.47 Join krabador [0] (n=krabador@host156-36-dynamic.31-79-r.retail.telecomitalia.it) 03.37.08 # and a release with the feature set as it currently is seems sloppy 03.39.24 # 10824 03.39.48 Join toffe82 [0] (n=chatzill@adsl-99-130-6-5.dsl.frs2ca.sbcglobal.net) 03.39.51 # I've got a bit more work on it to do still.. but its pretty much ready 03.40.12 Join Tomis2 [0] (n=Tomis@70.134.106.143) 03.46.39 Quit Tomis (Read error: 110 (Connection timed out)) 03.46.40 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.106.143) 03.54.29 # New commit by 03rmenes (r23839): Revert an accidental commit that I didn't want to go in. 03.59.33 *** Saving seen data "./dancer.seen" 04.02.51 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 04.06.00 # JdGordon: I am not able to compile the patch.. 04.07.29 # can you upload a new version with current svn? 04.19.09 # kkurbjun: yep, 1 min 04.20.32 # shit.. I didnt accidently commit radio.c did I? 04.22.23 # done 04.23.37 Quit Strife89 ("Bed.") 04.25.48 Part froggyman 04.28.35 # jdgordon, I still cannot compile ro the mr500 04.28.55 # in screens.c I am getting some errors with the calibrate function 04.29.07 # error: ‘VP_SB_HIDE_ALL’ undeclared (first use in this function) 04.30.40 # naughty lambda :/ 04.31.58 # New commit by 03jdgordon (r23840): 2 equal signs are better than waaa-huunn.... 04.33.25 Quit BHSPitMonkey (Read error: 113 (No route to host)) 04.33.42 Quit krabador ("Sto andando via") 04.35.24 # kkurbjun: ok, fixed again 04.36.11 # ah, bugs bunny in drag, always comedy 04.39.20 # JdGordon: it's compiling now and the main firmware seems to be working so far, but it segfaults when I go into any plugins 04.39.38 # did you do a full rebuild? 04.39.42 # to reproduce load the cleangreen theme in the sim and then go into a plugin 04.39.42 # plugin.h changed 04.40.05 # I believe so, but I'll do a clean build and try again 04.40.27 # oh, png might have messed that up 04.40.31 # pong that is 04.40.41 # I didn't update after you fixed that failure 04.41.15 # oh cool 04.41.26 # the plugin menus show the statusbar! 04.41.41 # of course! 04.41.42 # it's a little messed up, but I like that it is showing it all integrated 04.42.00 # messed up how? 04.42.06 # on the mr500 I am getting alot of black boxes when I go into blackjack for example 04.42.11 # ah yes 04.42.16 # I think it might try to disable the backdrop.. 04.42.29 # one thing at a time.. its beter than svn at least 04.42.46 # yeah, exiting is clean 04.43.14 # New commit by 03mc2739 (r23841): fix red - add missing #elif 04.43.25 # I really like that it tries to maintain the statusbar though 04.43.55 # I'm thinking about linking the backdrop with the sbs and ui viewport also 04.44.09 # not sure if that will cause more problems though 04.47.28 # JdGordon: I tested all of the demo's they work as well as quite a few games - boomshine segfaults though 04.48.01 # which backdrop would you link with the sbs? 04.48.13 # the main one 04.48.47 # that could cause problems in the wps if the custom statusbar is enabled, and a different backdrop is used I would guess 04.49.31 # wps would force change the backdrop so that shouldnt cause problems 04.49.54 # oh yeah 04.50.41 # I think it's more than a problem just with the ui viewport and the sbs viewports - if I go into a plugin and then enter the game and go back to the menu I get artifacts of the game screen 04.51.13 # leaving the menu should cause the game to redraw 04.51.36 # I'm going to do some cleverness when going from fullscreen to theme, not the other way around though 04.51.46 # the game redraws, but the menu doesn't redraw witht eh backdrop, I still see the game in the background in the menus 04.51.54 # or portions of the game 04.52.23 # ah yeah, I misunderstood 04.52.29 # how do you get boomshine to segfault? 04.53.36 # I had the cleangreen theme loaded on the mr500S with music playing 04.53.46 # and then I entered the plugin 04.53.57 # oh weird, it didn't crash this time 04.54.11 # get it crashing in gdb and let me know where it breaks :) 04.54.14 # I went through all of the demo's and then entered it 04.54.15 # I gotta run... back in an hour 04.54.20 # k 04.54.54 Quit TheSeven (Nick collision from services.) 04.55.12 # oh weird, I get a floating point exception when going into dice... 04.55.12 Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) 04.55.24 Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) 04.55.26 # that appears to be consistent 04.56.09 # invadrox consistently segfaults too 04.56.50 # * Unhelpful wonders how you got an FPE at all... 04.57.01 # :), yeah, I was wondering that too 04.57.20 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 05.01.52 # metronome also segfaults when I exit 05.06.34 # JdGordon: I found an area in the main build that causes glitches - if I disable the custom statusbar and then go back into the setting and enable it it takes a menu transition before the ui-viewport takes effect and it causes a glitch in the background showing a portion of the old menu where the menu used to be 05.06.58 # that appears to persist till I transition to the now playing 05.07.01 # screen 05.10.10 Join Tomis2 [0] (n=Tomis@70.134.71.187) 05.14.20 # JdGordon: I was mistaken about the boomshine segfault - I was loading something else on my end that was similarly named 05.15.43 # and I think the dice error is caused by the remote :) 05.16.25 # it's crashing on a check for the number of dice to show and I would guess the remote screen ends up with a 0 in the denominator of a division 05.16.59 # yeah, that's what it looks like, I'll take a look at that since it's a plugin specific problem 05.18.41 Quit Tomis (Read error: 110 (Connection timed out)) 05.18.42 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.71.187) 05.22.04 # hmm, actually, that calculation should work sort of - it is calling display->getstringsize, and on the remote in this case it is set to the ui font, so that should return a height/width of 8 05.23.49 # it looks like it is returning the value based on the main screen ui viewport font rather than the remote font setting 05.26.11 Quit jasio (Read error: 110 (Connection timed out)) 05.36.09 # kkurbjun: ok ta 05.38.54 # I dont tihnk the plugin api got bumped in the diff which could be causing you pain :) 05.40.20 Join Muffins [0] (n=601cdded@giant.haxx.se) 05.40.43 # JdGordon: yeah, I forgot about invadrox, I have that disabled currently on my system 05.40.48 # from building that is 05.41.02 # so I'm running whatever it used to be 05.42.08 # I tried to format my Sansa c240 with the built in format tool, and now the rockbox bootloader is saying "no partition found", is there anyway to fix this? I just got this mp3 player today :( 05.42.19 # I'm guessing that the ui viewport somehow gets changed in dice which causes the segfault on the remote.. 05.42.57 # if the viewport setting persisted it wouldn't crash, but it must be getting reset, in either case it needs a check to prevent a div by 0 05.43.17 # ok 05.43.25 # I am adding that now 05.43.32 # I need to do real work now unfortunatly :( bbl 05.43.37 Quit JdGordon ("Leaving.") 05.43.42 Quit Muffins (Client Quit) 05.45.24 # New commit by 03kkurbjun (r23842): Dice: Prevent a divide by 0 05.59.37 *** Saving seen data "./dancer.seen" 06.01.23 Join JdGordon| [0] (n=Miranda@c-24-22-210-83.hsd1.wa.comcast.net) 06.10.36 Quit BlakeJohnson86 (Read error: 60 (Operation timed out)) 06.13.27 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 06.17.19 Quit Casainho ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") 06.26.43 Quit CaptainKewl (Remote closed the connection) 06.28.40 Join dmb [0] (n=Dmb@unaffiliated/dmb) 06.29.57 Quit phanboy4 (Read error: 104 (Connection reset by peer)) 06.30.16 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 06.32.44 Join krazykit` [0] (n=kkit@69.219.239.79) 06.35.03 Quit krazykit (Read error: 54 (Connection reset by peer)) 06.37.54 Join mylogic [0] (n=matt@c-71-63-90-56.hsd1.va.comcast.net) 06.40.11 Part toffe82 06.40.44 Quit Hillshum (Remote closed the connection) 06.41.12 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 07.03.22 Quit bluebrother (Nick collision from services.) 07.03.25 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 07.19.47 # amiconn: actually, that math is all wrong. the needed buffer for full-size 4bpp font data would be 38400B. worse for subpixel AA with 6bpp, 61400B. even 9600B for mono sounds a bit costly, but the buffer could be sized for mono, and then only the AA font code would use partial buffering. 07.24.30 Quit mylogic (Client Quit) 07.25.06 Quit liar (Client Quit) 07.50.36 Join bnijk_ [0] (n=ush@unaffiliated/octopuswitharms) 07.50.43 # everybody in ipodlinux is gone 07.50.52 # can you tell me how to get this bootloader on 07.50.56 # without ipodpatcher 07.51.31 # bnijk_: Just because the right place to ask your question is empty doesn't mean you should come here with it. 07.51.36 # This is for questions and discussion about Rockbox. 07.51.58 # ok well 07.52.01 # my ipod's partition table is borked 07.52.02 Join AndyIL [0] (n=pasha_in@212.14.205.32) 07.52.04 # should i use rockbox 07.52.09 # is it better anyway 07.52.38 # besides, most people around here wouldn't know the answer anyways (I for myself don't even have an Ipod) 07.52.45 # "better" is pretty subjective. It's got a substantial feature set covered in the documentation, and is generally considered superior for audio playback functionality. 07.53.22 # that'll do it then 07.53.39 # * bnijk_ tupac rockbox-utility 07.56.17 # holy cow 07.56.20 # text to speech? 07.56.46 # No. 07.56.50 # Pre-recorded voice clips. 07.58.29 Quit Sajber^1 (Read error: 104 (Connection reset by peer)) 07.59.02 Join Sajber^ [0] (n=Sajber@h-143-7.A213.priv.bahnhof.se) 07.59.39 *** Saving seen data "./dancer.seen" 08.02.33 # is there a program that will just format my ipod 08.03.30 # it's giving me a real headache 08.04.11 # Anything that can format partitions can format the data area just fine. 08.04.28 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.04.46 # how does it need to be formatted 08.06.08 # FAT32, most things will have sane defaults. 08.08.13 # bnijk_: Why not format it using itunes? 08.08.29 # Then at least you're starting from a known good state 08.09.23 # i already finished 08.09.38 # now i'm installing 08.10.14 # man 08.10.16 # this thing rules 08.10.33 Join Bagder [0] (n=dast@giant.haxx.se) 08.10.51 Quit AndyI (Read error: 110 (Connection timed out)) 08.12.16 # it's giving me a harddrive problem though 08.12.19 # i think... 08.19.31 # i'm installing quicktime through wine 08.21.02 # bnijk_: We don't need to know about unrelated stuff. Please keep your comments here to questions or related information. 08.22.22 # it's not unrelated 08.22.54 Quit TheSeven ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 08.23.26 # Neither Rockbox nor its tools requires quicktime. 08.26.23 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 08.32.13 Join flydutch [0] (n=flydutch@host140-41-dynamic.116-80-r.retail.telecomitalia.it) 08.33.53 # JdGordon: Yes, the grumble was related to the statusbar changes. Not becaue of charcell though, but because you seem to be pushing a change with known bugs 08.34.12 # (recording screen, early usb, charging screen etc) 08.34.31 # recording screen doesnt have bugs 08.34.44 # neither do the other two 08.37.35 # The fs task says so... 08.37.55 Join Rob2222 [0] (n=Miranda@p4FDCB22E.dip.t-dialin.net) 08.38.19 # ok 08.38.23 # now i'm having serious problems 08.38.34 # i did the install like ten times, and i'm still getting the folder with the exclamation point 08.39.08 # i just did sudo ./ipodpatcher -ab loader.bin 08.39.15 # and it still doesn't work 08.39.25 # i suspect this: 08.39.26 # [INFO] Part Start Sector End Sector Size (MB) Type 08.39.26 # [INFO] 0 32 10239 5.0 Empty (0x00) 08.39.26 DBUG Enqueued KICK bnijk_ 08.39.26 # [INFO] 1 10240 39061503 19068.0 W95 FAT32 (0x0b) 08.39.28 # is a problem 08.39.59 # bnijk_: If you're installing Rockbox you don't need any parameters for ipodpatcher 08.40.33 # i just did that 08.40.34 # too 08.40.38 # no good 08.40.48 # it says "bootloader installed successfully" 08.40.58 # You need a working iPod first 08.41.08 # Get it restored, then do it the way you're supposed to do it for Rockbox. 08.41.13 # We can't really help you if you're trying other random things too. 08.41.21 # what do you mean "restored" 08.41.33 # Working in the original firmware. 08.41.43 # well before i started, it was doing that 08.41.51 # yes, but you've clearly done several things 08.41.54 # Some of which must've been wrong. 08.42.00 # that seems to be true as well 08.42.05 # the question is really "what goes in that empty space" 08.42.11 # It's just marked as "empty" 08.42.12 # That's normal 08.42.22 # A type "empty" doesn't mean there's nothing there. 08.42.22 # so then what exactly would the problem be 08.42.32 # without using itunes 08.42.33 # I don't know, because I don't know everything you've done. 08.42.33 # how do i fix this 08.42.45 # You need to restore it. Find the Manual Restore page in the Rockbox wiki and follow the instructions there. 08.42.51 # i've done that 08.42.58 # http://www.rockbox.org/wiki/IpodManualRestore 08.43.03 # In the last several seconds you did it? 08.43.10 # immediately before doing the install 08.43.19 # Except you clearly did something other than the normal Rockbox install 08.43.25 # Since the command you gave up there isn't our command 08.43.26 # before that the drive was wiped 08.44.01 Join gibbon_ [0] (i=gibbon_@not.a.servant4you.org) 08.44.08 # hiho and good morning 08.44.38 # What you need to do is 08.44.38 # 1) Get the Apple firmware booting following the instructions on the manual restore page. 08.44.38 # 2) Follow the instructions for installing Rockbox exactly as in the manual. Do not try to install some other bootloader. 08.44.38 DBUG Enqueued KICK Llorean 08.44.38 # 3) After doing these if you have problems explain exactly what you did immediately before you got unexpected results. Do not try other things as soon as *anything* turns up different than it should be. 08.45.08 # Right now we've got an unknown number of other steps in there where you've tried commands such as the one you pasted, and this isn't the place for asking for help with other install processes. 08.46.37 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.49.43 # ok 08.49.50 # i did all the manual restore steps 08.49.56 # i mounted the vfat partition to /f 08.50.06 # gave /f to rbutilqt as the mount point 08.50.12 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.50.15 # did "complete installation" 08.50.20 # did "install bootloader," to be double safe 08.50.31 # and it still gives me a folder with an exclamation point above it 08.50.50 # Was the original firmware working after the manual restore? 08.50.58 # no 08.51.08 # And what was step 1) I gave you? 08.51.20 # fine 08.51.55 # is this Firmware-2.2.3 08.51.57 # from the manual restore page 08.52.34 # i have a 40mb boot partition, too 08.52.40 # I don't know. Do you have a 3rd generation Grayscale iPod? 08.52.44 # yes 08.52.51 # Then that might be a suitable one. 08.52.56 # so i do 08.53.15 # ./ipodpatcher... 08.54.43 # does clear_display() not actually clear it if you dont do an update()? 08.54.57 # clear the framebuffer anyway.. so the next update will be correct? 08.55.06 Ctcp Ignored 2 channel CTCP requests in 5 minutes and 12 seconds at the last flood 08.55.06 # * JdGordon thinks he should goto bed instead of fiddle with this 08.55.08 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.02.01 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 09.04.16 Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) 09.06.52 Join advcomp2019__ [0] (n=advcomp2@unaffiliated/advcomp2019) 09.07.20 # it's still not even close 09.08.33 # bnijk_: Copy down exactly what you did to a site like pastebin.ca including the output from each of them, maybe I can spot where you misunderstood a step 09.10.31 # can you just tell me how to format it 09.10.32 # from scratch 09.10.39 # so it can handle rockbox 09.10.42 # The instructions are on the restore page. 09.10.52 # the manual restore page 09.10.53 # Or the linked FAT32 conversion page if you're using Linux 09.11.26 # Yes. 09.11.54 # i have linux 09.11.57 # isn't that what the manual restore page is for 09.12.23 Join petur [50] (n=petur@rockbox/developer/petur) 09.12.32 # Sorry got it backward, the Restore page is Linux yes. 09.12.36 # the Conversion page is for OSX 09.12.40 # They're very similar. 09.12.47 # But the Restore page includes a full format. 09.13.38 # It restore page rebuilds everything necessary for the original firmware and Rockbox to work on your iPod. Which is why I've told you to do it several times, and asked for what output you got to be pasted to a site like pastebin.ca 09.13.54 # Since the only way I can help you is if I figure out what part of that is messing up. 09.16.18 # $ cat ipodRestore.sh 09.16.18 # #!/bin/bash 09.16.18 # dd if=/comp/ipodlinux/mbr/kernel/mbr-3g-20gb.bin of=/dev/sdi 09.16.18 # hdparm -z /dev/sdi 09.16.18 # dd if=Firmware-2.2.3 of=/dev/sdi1 09.16.20 # mkfs.vfat -F 32 /dev/sdi2 09.16.42 # Okay 09.16.53 # I said paste it to a site like pastebin.ca 09.17.05 # we're the only people in here Llorean ... 09.17.09 # Yes, and the logs 09.17.14 # Which do not need to be filled up with long pastes. 09.17.18 # Or even medium pastes. 09.17.26 # doesn't that just make them more comprehensive 09.17.53 # no, it makes them more annoying for people reading them for actual development discussion. 09.18.07 # The channel has posted guidelines (as you can see in the topic) 09.18.18 # oh, well 09.18.20 # if there are guidelines 09.19.47 # so i have fully completed 09.19.49 # the manual restore 09.20.23 # And does the original firmware work? 09.20.36 # i installed Firmware-2.2.3 09.21.44 Quit phanboy4 (Read error: 104 (Connection reset by peer)) 09.21.52 Quit advcomp2019 (Read error: 113 (No route to host)) 09.22.10 # this is not the apple firmware 09.22.12 # as far as i know 09.22.17 # i don't have that 09.22.48 # The firmware files linked from the manual restore page are the original firmware. 09.23.03 # yes 09.23.09 Quit advcomp2019_ (Read error: 113 (No route to host)) 09.23.13 # from iPod_2.2.3.ipsw 09.23.23 # So if you installed Firmware-2.2.3 and it works, you have the original firmware. 09.23.28 # If it doesn't work, the answer to my question was a simple "no" 09.23.34 # what do you mean "works" 09.23.36 # does it boot? 09.23.43 # Yes. 09.23.48 # Can you boot your player and use it? 09.23.50 # no 09.23.53 # dude 09.23.57 # the vfat partition ahs been wiped 09.24.07 # unless the whole ipod OS is on the firmware ( i don't know if it is) 09.24.10 # No part of the apple firmware exists on the data partition. 09.24.23 Nick advcomp2019__ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) 09.24.24 # The whole iPod OS goes in that "blank" partition, which is what that Firmware-2.2.3 file is. 09.24.30 # fine 09.24.33 # then no, it won't boot 09.24.47 # it gives me a folder with an exclamation point 09.24.47 # Alright, delete *all* files associated with this. Start over from scratch 09.24.51 # That means redownloading everything 09.25.09 # Install it. Copy the output of every step you do to a pastebin. *include* steps such as extracting the .ipsw 09.25.14 # Make sure to get the output of everything 09.26.13 # I can't help you until I can see which step went wrong, and that means I need much more comprehensive information than you've been giving me because every step of the way you've decided to filter what I've asked for through your decision of what your limited understanding of the situation thinks I need. I know I'm sounding rude now, but I've been trying to help you for nearly an hour now and we're still at square 1 and I've already asked you for s 09.28.01 # http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=13584#a13584 09.28.29 # Okay, you didn't follow my instructions exactly 09.28.32 # I'm done. 09.28.41 # so what didn't i do 09.28.52 Join DerPapst [0] (n=DerPapst@p4FE8F081.dip.t-dialin.net) 09.29.10 Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) 09.29.12 Join Kitr88 [0] (i=Kitarist@193.77.180.134) 09.29.14 # "Copy the output of every step you do to a pastebin. *include* steps such as extracting the .ipsw" 09.29.47 # [root@buffalo ipodlinux]# unzip *.ipsw 09.29.47 # Archive: iPod_2.2.3.ipsw 09.29.47 # replace Firmware-2.2.3? [y]es, [n]o, [A]ll, [N]one, [r]ename: y inflating: Firmware-2.2.3 09.29.50 # replace manifest.plist? [y]es, [n]o, [A]ll, [N]one, [r]ename: y inflating: manifest.plist 09.29.53 # [root@buffalo ipodlinux]# 09.29.59 # Again, DO NOT PASTE TO THE CHANNEL 09.30.37 # it's 3:30 buddy 09.30.44 # in the morning 09.30.47 # you don't see me shouting 09.30.57 # If you're too tired to remember simple things like that, please come back when you've had some rest. 09.31.09 # i remember it 09.31.17 # the issue is that i don't care at all 09.31.18 # me, I'm getting frustrated because I seem to have to give you instructions 2+ times before you remember it. 09.31.38 Mode "#rockbox +o Llorean " by ChanServ (ChanServ@services.) 09.31.58 # and now you pull out the +o 09.32.02 # Yes. 09.32.07 # Yes. 09.32.14 # so you're in like 09.32.15 # support? 09.32.18 # I tried asking you politely. now I'm going to be clear. 09.32.18 # bnijk_: are you shocked? you've made it clear you don't care about channel guidelines. 09.32.24 # this is how you help people? 09.32.28 # This channel has guidelines. You've asked for help. You're now being an ass about it. 09.32.36 # you're the one threatening to ban me 09.32.39 # we are not support people 09.32.42 # i'm not being an ass 09.32.50 # Did I say I was going to ban you? 09.33.02 # you sure implied it 09.33.07 # I put on the +o now to show that I'm not just some random person spouting things, but someone in a position to know that these rules really are intended to be followed. 09.33.09 # not being an ass? the issue is that i don't care at all 09.33.21 # how is that being an ass? 09.33.25 Join n1s [0] (n=n1s@rockbox/developer/n1s) 09.33.29 # i don't respect your rules because *this is how your rules are applied* 09.33.35 # I won't imply that I'm going to ban you. I will state something such as "if you do that again, you will be banned." 09.33.42 # i don't respect them because they *make the discussion more difficult* 09.34.02 # bnijk_: What makes discussion more difficult is idiots who can't follow directions, and refuse to give the information they're asked for because they think they know better. 09.34.16 # i gave you the information 09.34.20 # i sent you the paste of everything i did 09.34.23 # and gave the rest of you the information 09.34.27 # which was 7 lines of information 09.34.28 # when you complained 09.34.30 # bnijk_: somehow I think you've blown your chances now 09.34.43 # you're being a little selfish here. Pastes may make your discussion easier but they screw things up for everyone else searching through the logs afterward. 09.34.45 # bnijk_: First, you didn't give the information on first request for either of those sets of info. 09.35.00 # Second, you chose to disregard simple channel guidelines for your own laziness. 09.35.04 # because i thought my problem was simple 09.35.14 # and didn't need this whole thing 09.35.18 # Exactly. Idiots who decide they know better than the people they're asking for help 09.35.32 # well if rockbox could install on any reasonable filesystem 09.35.37 # I explicitly told you I wanted the whole thing but you, who can't solve the problem himself apparently know enough about it to know that I'm clueless and don't really need what I asked for. 09.35.37 # we wouldn't be having this problem 09.35.45 # Rockbox can install on any working FAT32 iPod 09.35.51 # You get yours working, you can install it. 09.35.55 # this is not a rockbox issue, you need a working ipod :P 09.36.04 # that's still such a joke 09.36.17 Mode "#rockbox -o Llorean " by ChanServ (ChanServ@services.) 09.36.19 # bnijk_: we're all just jokers here, now get out of here 09.36.22 # you can't write your own OS, without having to bootstrap it from another OS 09.36.24 # on the same machine? 09.36.29 # bye bye 09.36.43 # i'm still trying to get it installed 09.36.48 # no you don't 09.36.49 # because as stupid as it is 09.36.54 # you're trying to upset us 09.36.55 # it's not as stupid as apple's software 09.36.57 # bnijk_: yes, well you're not going to get any more support here. Feel free to try elsewhere. 09.36.59 # and it doesn't work 09.37.09 # you don't know what my intentions are 09.37.13 # my intentions are to install rockbox 09.37.14 # yes I do 09.37.19 # and then this asshole comes out with a @ 09.37.24 # like he's going to ban me 09.37.25 # I've followed your chat the entire time 09.37.27 # how am i supposed to react? 09.37.32 # you are a lost cause 09.37.39 # you're all lost causes 09.37.43 # yes 09.37.44 # look at how you treat people 09.37.44 # bye bye 09.38.02 # you'll have to ban me before i leave 09.38.02 # sorry, but you are not people 09.38.21 # i'm not a person huh 09.38.26 # not people 09.38.28 # You're a person. 09.38.34 # yes 09.38.36 # people is the plural 09.38.38 # Generally *people* as a group consider our project to have a pretty solid support base. 09.38.44 # bnijk_: then why don't you try to listen to advice and help and be friendly? 09.38.47 # Your feedback is welcome though 09.38.47 # i'm sure others in similar situations would have similar reactions 09.38.50 # why are you trying to insult us? 09.39.04 # you call this a solid support base? 09.39.12 # no 09.39.20 # bnijk_: I spent an hour trying to help you despite your best attempts to avoid directly answering my questions 09.39.22 # we call this an IRC channel 09.39.34 # yeah Llorean you caught me 09.39.37 # my secret motive the whole time 09.39.46 # was to hinder you while you tried to help me to do something i wanted to do 09.39.50 # bnijk_: The only "problem" here is that you decided a channel having enforced guidelines is 'bad support' 09.39.59 # i do think that 09.40.06 # the problem isn't that i realize it 09.40.09 # the problem is that you don't 09.40.13 # Instead of dropping the issue and simply following them, getting back to the support because you "want to" install Rockbox, you persist in making a scene of yourself. 09.40.30 # There's nothing secret about it. You admit that you know about the channel guidelines and don't care. Therefore we admit that we know you want help and don't care. 09.40.30 # "and simply following them" 09.40.33 # you just have to keep doing it 09.40.40 # you can't act like we're equals 09.40.47 # The majority of participants here respect the channel guidelines. In fact, everyone except you. 09.40.55 # Having insulted the project's wishes, you now somehow expect members of the project to provide you with support anyway. 09.40.57 Quit bertrik (Read error: 113 (No route to host)) 09.41.01 # oh, well, if a majority of people do it 09.41.05 # it has to be right 09.41.17 # "insulting the project's wishes" 09.41.24 # bnijk_: no, we've all been wrong for all these years until YOU came here and showed us the light 09.41.27 # finally! 09.41.37 # thanks 09.41.51 # good, now make it sincere and i'll listen 09.42.06 # why? 09.42.15 # I'm aa stupid loser 09.42.21 # * Unhelpful wonders how you expect Bagder to say something ridiculous and untrue sincerely 09.42.34 # bnijk_: Seriously, the wishes of dozens of developers isn't going to change just to meet your needs. The rule stands, if you want to insult it you're welcome to your opinion, but don't expect people to say "thanks" and still help you. 09.42.52 Mode "#rockbox +o Unhelpful " by ChanServ (ChanServ@services.) 09.43.00 # maybe it won't 09.43.05 # but the point of software is to get better, isn't it 09.43.14 # yes, usually 09.43.14 # And it doesn't need you to do that, apparently 09.43.29 # apparent to you maybe 09.43.31 # Since you can't even manage to install it, something tens of thousands have done just fine. 09.43.38 # bnijk_: and the purpose of rules is that we've figured out a way that works (better) for us 09.43.41 # i'm starting 09.43.45 # with a _blank harddrive_ 09.43.51 # i was using it 09.43.53 # _for storage_ 09.43.56 # And the Format page is designed explicitly for that state. 09.43.57 # oh we're starting over now? 09.44.00 # And it works for everyone who does it right. 09.44.24 # what 09.44.25 # http://www.rockbox.org/wiki/IpodManualRestore#How_to_restore_an_iPod 09.44.27 # that page? 09.44.36 # Yes. 09.44.44 # well i followed all of those instructions 09.44.49 # And you did something wrong. 09.44.51 # I don't know what. 09.44.57 # Unfortunately I'm not at your computer so I can't figure it out. 09.45.02 # well i showed you the pastes 09.45.03 # Either that or something is different about your ipod 09.45.13 # bnijk_: we chose our method of installation, it works well and , if you want to install in another fashion, get ready to do some hacking on the install tools and bootloader 09.45.21 # Maybe the in-flash bootloader is different, maybe it has physical damage since you mentioned having other problems with it before. 09.45.56 # that's possible 09.46.01 # should i switch it with another 09.46.09 Quit Kitar|st (Connection timed out) 09.46.41 # swictch what with another? 09.46.48 # the flash 09.47.01 # Do you have a way to remove the flash chip and put a new one in? 09.47.05 # it's about the size of a really flat razor, right? 09.47.20 # It's probably the disk that's bad though 09.47.38 # considering it was working 5 hours ago 09.47.40 # i doubt it 09.48.20 # well forget it, i have to sleep 09.56.29 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 09.59.42 *** Saving seen data "./dancer.seen" 10.00.31 Quit Thundercloud (Remote closed the connection) 10.01.49 Quit faemir ("Leaving") 10.30.27 Join kugel [0] (n=kugel@rockbox/developer/kugel) 10.30.36 Quit Tomis (Read error: 110 (Connection timed out)) 10.31.33 Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) 10.33.11 Join Tomis [0] (n=Tomis@70.134.67.28) 10.33.49 Quit DerPapst ("Leaving.") 10.44.54 Quit kugel (Read error: 104 (Connection reset by peer)) 10.56.44 # i am greeting everyone 10.57.03 # Unhelpful: how complicated would loading albumart for two different displays (pixel formats) be? I just remembered the Iaudio remote control problem again... 10.58.15 # my new clip just arrived and it is a v2... i already suspected that, though. While there seems to be code in svn (that i know is dearly stages development code... i am not asking how to install this) i want to do something useful while (and for) the port is becoming more and more working 10.58.34 # what besides translations and perhaps testing would help this port? 10.59.12 Join Casainho [0] (n=chatzill@87-196-81-204.net.novis.pt) 11.00.14 # pixelma: you'd need a remote-format output plugin for the scaler, and a way for the scaler to know to call it. perhaps the format field of the bitmap struct could be used to pass the info? the loader would also have to be called with FORMAT_REMOTE - it's called from buffering.c 11.00.15 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 11.00.44 # actually, perhaps the output plugin could just check the format flag itself if it's compiled on a target with a remote 11.06.45 # hrm, or you could just pass the plugin as a custom output format plugin when loading. that'd involve the smallest amount of new code. 11.16.15 # * Unhelpful thinks the hardest part is likely to be telling bufopen that it's loading for the remote (without making a big mess) 11.17.10 Quit robin0800 (Remote closed the connection) 11.25.28 Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) 11.38.21 Part LinusN 11.38.33 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 11.44.54 Mode "#rockbox -o Unhelpful " by ChanServ (ChanServ@services.) 11.46.11 # is there any reason developers can op and deop via chanserv, but can't just use chanserv to quiet/unquiet/ban/etc beligerent users? 11.47.06 # That would be nice. 11.48.09 # chanserv has commands for it, but i tried it earlier and noticed that i lack permissions to ask chanserv to do things that i could do myself after asking it to op me 11.48.34 # * Llorean thinks this may be a scorche question. 11.48.39 # Isn't he the one who got all the permissions set up? 11.49.11 # "services permissions are bizarre and arcane" is likely the reason ;) 11.49.42 # Sounds like a good one 11.49.51 # also *does* it have those commands? 11.49.54 # it has quiet/unquiet.. 11.49.56 # but i don't see ban 11.49.58 # or kick 11.50.09 # only things that manipulate permanent lists (akick and the like) 11.50.58 # you're right, i don't see ban... which is odd considering that quiet/voice user modes are provided 11.52.39 Quit BHSPitMonkey (Read error: 113 (No route to host)) 11.53.07 # i suspect dancer services assumes that *because* you can do it by being opped it's not neccessary to hide behind chanserv :) 11.54.14 # Torne: and where do voice and quiet fit into that model? 11.54.39 # * Torne shrugs 11.55.05 # "IRC services are all awful"? 11.55.06 # Doesn't freenode like to extremely discourage bans in favor of mutings? 11.55.19 # Maybe it's simply a policy thing "they can do it, but we don't make it easy so maybe they'll stop to think a second" 11.55.50 Quit Casainho ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") 11.57.46 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 11.58.38 Quit n1s ("Lämnar") 11.59.44 *** Saving seen data "./dancer.seen" 12.06.13 Join watto [0] (n=watto@193.203.81.165) 12.10.58 Join teru [0] (n=teru@KD059133115245.ppp.dion.ne.jp) 12.15.43 Join n1s [0] (n=n1s@90-230-78-242-no134.tbcn.telia.com) 12.28.01 # i guess there will be a second build host by me in the next few hours 12.28.28 # even though four minutes are quite fast for a full build round, i suppose the faster, the better 12.39.18 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.41.34 # New commit by 03rmenes (r23843): Fix a typo for the GoGear SA9200 on chessclock, and got the LCD resolution ... 12.46.41 Quit robin0800 (Remote closed the connection) 12.56.34 # New commit by 03teru (r23844): blackjack: Set foreground color and background color properly after canceled to input amount. ... 13.06.43 Join geertvdijk [0] (n=chatzill@cc412026-a.zwoll1.ov.home.nl) 13.13.27 Quit killan_ (Read error: 110 (Connection timed out)) 13.37.07 Quit z35 (Read error: 104 (Connection reset by peer)) 13.43.57 Join Transformer [0] (n=Transfor@ool-43563460.dyn.optonline.net) 13.46.45 Part Transformer 13.53.17 # New commit by 03teru (r23845): text editor: Return pointer to buffer but position in buffer for ACTION_GET to simpify code. ... 13.59.47 *** Saving seen data "./dancer.seen" 14.06.52 Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) 14.08.05 # i have a question regarding timestretch 14.08.54 # on my iPod mini 1st Generation (r23826) when i enable timestretch, it tells me to reboot 14.09.36 # * Torne preempts this one. Are you resetting the ipod by holding menu+select? :) 14.09.43 # if i enter the menu again, the setting is still enabled... after rebooting it is disabled again... is this known 14.09.51 # Torne: hm... well, right. yes :P 14.10.07 # New commit by 03tomers (r23846): Skin parser: Use parse_list() when possible 14.10.08 # don't do that 14.10.10 # that hard-resets the ipod 14.10.15 # which means none of your settings will be saved 14.10.22 # just shut it down, and then turn it on again. 14.10.47 # ok... i forgot the proper way to reboot it was turning it off. sorry 14.10.50 # and thanks 14.10.59 # menu+select is only if the device has hung and you can't reset it any othe rway 14.11.18 # yes, thats obvious if i think about it 14.11.50 # Torne: nice catch :) 14.12.09 # I wouldn't have even thought about asking that 14.12.28 # this is not hte first time :) 14.12.29 # i just found out about that setting and the compressor... i love these features. 14.12.46 # especially the compressor when in the car. thanks. 14.13.51 # markun: it seems quite a few people hard-reset the ipods when our splashes tell them to reboot. pondered what we could do to make it clearer but got nothing :) 14.14.12 Join DerPapst [0] (n=DerPapst@dslb-188-097-069-016.pools.arcor-ip.net) 14.14.23 # ah, it's the first time I hear it, but I haven't been around much and don't pay that much attention to ipod ports 14.15.27 # i think it's my second most commonly used support answer, after the way more popular "try turning on dircache" 14.15.30 # :) 14.16.03 Part Bagder 14.17.52 # mt: can you add something to the FasterMDCT wiki page about the speed of the current MDCT (from Tremor) 14.20.20 Quit shai ("Leaving") 14.21.25 Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) 14.25.32 Quit antil33t (Read error: 54 (Connection reset by peer)) 14.25.38 Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) 14.26.48 # markun: saratoga measured its speed, but I can't remember the actual numbers. 14.27.39 # was it slower than the one from liba52? 14.27.40 # More stuff should be added soon to this page anyway, I just need some more free time to do so. :) 14.27.46 # ok 14.29.07 Quit DerPapst ("Leaving.") 14.38.53 # New commit by 03teru (r23847): png: Change zoom in/out method and don't center the view on zoom. ... 14.41.11 Join Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) 14.43.27 Quit Lss (Read error: 54 (Connection reset by peer)) 14.44.37 Join Lss [0] (n=Lss@cm205.delta92.maxonline.com.sg) 14.51.53 Join z35 [0] (n=z35@ool-45714f83.dyn.optonline.net) 14.54.56 Quit HBK (Read error: 104 (Connection reset by peer)) 14.58.07 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 14.58.58 Quit HBK (Read error: 104 (Connection reset by peer)) 14.59.07 # shouldn 14.59.37 # 't we define cpu_boost to an empty macro in plugins too to get rid of the #ifdefs like we have done in the core 15.00.03 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.02.21 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.04.04 Join Jaykay [0] (n=chatzill@p5DDC55BA.dip.t-dialin.net) 15.04.55 Quit KBH (Read error: 104 (Connection reset by peer)) 15.06.19 # hi.... i have an idea, but maybe its complete bullshit. how about a second... trunk in which the devs can integrate every patch they want to? of course also with something like the current builds so everyone can test it 15.07.13 # Jaykay: are you under the impression that devs are somehow held back from integrating patches? 15.07.23 # yes. 15.07.27 # :) 15.07.28 # by what/who? 15.07.34 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.08.01 Quit KBH (Read error: 104 (Connection reset by peer)) 15.08.05 # i think the devs/some of them think that everything in the current build should somehow work, preventing them from integrating patches which might not work 15.08.06 Quit HBK (Read error: 104 (Connection reset by peer)) 15.08.27 # well, yeah. what's the point of adding a patch that doesn't work? 15.08.35 Quit bnijk_ (Read error: 110 (Connection timed out)) 15.08.56 # zagor: not "doesnt work" but maybe cause instabilities 15.09.06 # it would make testing a lot easier 15.09.10 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.09.39 # no. merging a dozen unstable patches would actually make testing a lot harder 15.09.55 # it's much better to test one patch at a time. 15.11.00 # Jaykay: i think what you *really* want is a way for people to post patches which causes a build of them to happen, so epople can try the patch without building, maybe? :) 15.11.09 # ok... then another freaky idea: if a dev wants to test a patch, he can somehow trigger the buildsystem to give him all builds with his patch. these builds are then hosted on the main page in a category "testing builds" 15.11.19 Quit KBH (Read error: 54 (Connection reset by peer)) 15.11.36 # torne: that would be another (imo very good) idea 15.12.01 # i've pondered that tbh :) 15.12.13 # Jaykay: yes, that's a better idea. i'm just now working on the first steps of a user testing framework. 15.13.07 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.13.34 Quit HBK (Read error: 104 (Connection reset by peer)) 15.14.07 # zager: cool :) 15.14.41 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.14.46 # how would this work? a user gives this framework a patch and a target and gets the build? 15.15.39 # no, this has nothing to do with building yet. it's just a database of test cases so we can formalize release testing better. 15.15.55 # and make better use of helpful users 15.16.01 # something like a checklist? 15.16.06 # yeah, sort of 15.16.09 # * Torne nods, that is indeed a good plan, but is unrealted, no? 15.16.26 # unrealted? 15.16.29 # unrelated 15.16.30 # sorry :) 15.16.32 # ah :) 15.16.32 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.16.46 # the build system is incredibly fast and is idle quite a bit. it doesn't seem *entirely* unreasonable to allow devs to do "test" builds on it.. 15.17.01 # thats what i thought :) 15.17.05 # i realise someone would have to do all the work to support that 15.17.11 # and i'm not volunteering :) 15.17.43 # indeed. that's sort of a "step two". in my opinion we need a proper test/reporting tool before there's any point in automated patch builds. 15.17.47 Quit KBH (Read error: 104 (Connection reset by peer)) 15.17.54 # Zagor: Hm, perhaps 15.18.02 # the current test builds don't seem to ever get tested, that's for sure :) 15.18.10 # exactly 15.18.12 # at all, let alone in a sensible way 15.19.13 Quit HBK (Read error: 104 (Connection reset by peer)) 15.19.45 # i wanted to test a test build today but the problem was that an updated version of the patch was available, but not an updated test build :) and as an normal user you don't know wether you should still test this "old" test build.... 15.21.11 # well, but it's cool that someone (zagor) is doing something and keep up the good work and so on :D 15.21.21 # talking of old test builds, what're we supposed to do about outdated test builds on the forum? just delete the thread? 15.21.47 # maybe ask for a new test build? 15.22.03 # (or do some and post them :) ) 15.22.04 # no, i'm not ready to produce one yet :) 15.22.34 # * Torne tries: 15.23.31 # gevaerts: the test build you posted on the forum for PP502x ATA DMA is kinda outdated and I'm intending ot make more changes to the DMA code (changing the DMA mode to a higher one, and general cleanups..) - should we just delete it for now? 15.24.34 # Torne: when test results from a test build are no longer useful i 15.24.39 # 'd say delete it 15.25.25 # but the dev maybe wants to post a updated build 15.25.33 # Jaykay: I pretty much am the dev for that now :) 15.25.45 # gevaerts did the test builds before but i'm the one working on the patch it seems 15.26.18 # then... if the patch is working, why dont you commit it? 15.26.24 # n1s: well, the changes I made to the generic ata code mean that the DMA test build is pretty obsolete; it will panic in places where it shouldn't (and now doesn't) so the results may be misleading :) 15.26.30 # Jaykay: it's not working 15.26.33 # well it is 15.26.35 # but it's not done :) 15.26.43 # amongst other things it currently makes writing to disk slower. 15.26.55 # since for some reason i've not yet figured out DMA writes are noticably slower than PIO 15.27.07 # i'm tidying it up and writing some more benchmarks :) 15.27.29 # this DMA stuff has been a bit of an epic odyssey and we're not at the end yet 15.28.33 # could you explain what this patch is all about? i mean, what are the advantages of it? just less cpu usage..... on what? reading/writing? 15.28.54 # it makes reading from disk faster, especially when unboosted (it's still faster when boosted but not by as much) 15.29.13 # and it reduces cpu usage while reading/writing the disk as the thread can yield while it waits for the dma 15.29.35 # on all PP502x players, primarily tested on ipodvideo but should work on all pp502x that use the IDE controller. 15.29.57 # should help the dircache scanning and trying to buffer case a bit then? 15.30.04 # Yes, it speeds up buffering 15.30.11 # that's very nice 15.30.15 # but there is not a huge gain in runtime with mp3 15.30.25 # the gain is higher if you use an expensive codec, i think 15.30.29 # but i've not tested that personally 15.30.59 # test with 96kHz 24bit wav! 15.31.01 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.31.02 # Hehe 15.31.04 # torne: the gain will be not that high because you have a lower runtime anyway then :) 15.31.12 # Jaykay: percentage-wise, i mean 15.31.21 # ok, true 15.31.30 Quit HBK (Connection reset by peer) 15.32.01 # it was originally theorised that it would help writes too, especially on usb 15.32.08 # but it seems not to. i need to investigate why in more detail :) 15.32.25 # btw i didn't write this originally, dreamlayers did all the reversing of the OF to find how to use the DMA controller 15.32.31 # what has this to do with usb? 15.32.51 # MSC file transfers are slow on ipod 15.32.57 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.33.03 # some people suspected this was because we weren't doing DMA on the disk 15.33.18 # and whats up with dreamlayers btw? (i didnt see patches/commits for a while) 15.33.25 Quit HBK (Connection reset by peer) 15.34.02 # no idea. 15.34.09 # he's vanished for quite a while now 15.34.16 # torne: so the writing "method" is different when writing over usb instead of... internal copying? 15.34.17 # i emailed him a while back to ask him about some of his patches and he didn't reply 15.34.30 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.34.35 # i've committed several of his patches now ;) 15.34.41 # and it looks like i'll be committing some more :) 15.34.54 # no, writing is the same whether rockbox or the host pc over usb is doing it 15.34.57 # #define rb->cpu_boost(on_off) doesn't work... 15.34.58 # too bad, his patches where interesting 15.35.08 # Jaykay: well, i am intersted in most of the stuff he's posted.. 15.35.21 # so for the ones related to hardware i have, i am looking at finishing/committing them :) 15.35.21 # torne: why should be writing over usb slower then? 15.35.31 # slower than with the OF, i mean 15.35.38 # by quite a lot 15.35.47 # ah, ok 15.36.33 Quit HBK (Read error: 104 (Connection reset by peer)) 15.36.43 # n1s: no, it won't.. the C preprocessor is token-based, not a simple string replacement 15.36.58 # well, to come back to the original topic... if you would give me a test build, i would really like to test it :D 15.37.02 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.37.22 Quit HBK (Read error: 104 (Connection reset by peer)) 15.37.23 # Torne: any tips on how to do that then? static inline wrapper? 15.37.39 # you could #define cpu_boost(x) as being one of the data members in rb :) 15.37.48 # then it will evaluate to an expression with no side effects and get optimised away? :) 15.38.15 # :) 15.38.47 # wont' we get a lot of "statement has no effect" warnings then? 15.38.52 # Probably. 15.38.58 # I assumed you were just doing a quick hack :) 15.39.06 Part r00s 15.39.44 # i don't know of a better answer, i'm afraid ;) 15.41.10 # Jaykay: when i've done my next set of changes to it and run some more tests locally I will try and produce test builds for all the relevant platforms. 15.41.35 # where do you post them? 15.41.47 # FS#9708 15.41.58 # i've not posted any changes to the main DMA patch yet 15.42.08 # i'm still using v0.7 that was resynced by buschel 15.42.25 # but i did the other patch that makes it actually work without crashing ;) 15.42.49 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.43.46 Quit Farthen (Ping timeout: 180 seconds) 15.45.50 Quit HBK (Read error: 104 (Connection reset by peer)) 15.47.27 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.47.38 Join FOAD_ [0] (n=dok@dinah.blub.net) 15.47.56 # i planned on a quick hack and a static inline function would work but feels kind of stupid 15.48.12 Quit HBK (Read error: 104 (Connection reset by peer)) 15.48.31 # * n1s looks for other things to "fix" 15.49.16 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.49.42 # heh, fun you can do #define foo rb->foo but not the other way around :) 15.49.49 # Well yes 15.50.11 # A macro's LHS must be a token, or a token followed by arguments in parens. The RHS can be any number of tokens. 15.50.36 # The C preprocessor is not a text substitution program :) It tokenises the input the same way the C compiler does. 15.52.23 # * n1s dislikes 15.52.44 # then alas you will need to use sed/perl/similar to preprocess your code instead :) 15.52.58 # i want it to replace an arbitrary amount of tokens with another arbitrary amount of tokens, dammit! 15.53.28 # Torne: this is hardly worth hacking sed into the build system :) 15.53.39 # Indeed :) 15.53.52 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.56.15 Quit KBH (Read error: 104 (Connection reset by peer)) 15.56.33 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.56.49 Quit KBH (Read error: 104 (Connection reset by peer)) 15.59.04 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.59.32 Quit HBK (Read error: 104 (Connection reset by peer)) 15.59.37 Nick KBH is now known as HBK (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 15.59.49 *** Saving seen data "./dancer.seen" 16.01.36 Quit HBK (Read error: 54 (Connection reset by peer)) 16.01.39 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.01.54 Nick KBH is now known as HBK (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.02.04 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 16.03.37 Quit FOAD (Read error: 110 (Connection timed out)) 16.03.38 Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) 16.05.08 Quit teru ("Quit") 16.05.34 Join TopyMobile [0] (n=topy@xdsl-78-34-66-147.netcologne.de) 16.08.07 Quit HBK (Read error: 104 (Connection reset by peer)) 16.08.45 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.09.34 Quit antil33t (Read error: 54 (Connection reset by peer)) 16.09.41 Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) 16.15.17 Quit evilnick_B (Ping timeout: 180 seconds) 16.15.32 Quit HBK (Read error: 54 (Connection reset by peer)) 16.19.02 Join evilnick_B [0] (i=0c140464@rockbox/staff/evilnick) 16.27.55 Join bnijk_ [0] (n=ush@unaffiliated/octopuswitharms) 16.28.48 # Torne: you may have done it already, but deleting seems like a good idea 16.29.19 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 16.29.38 # i haven't done it already, no 16.29.41 # shall i just kill the thread? 16.30.29 # sure 16.30.49 # ..how do you delete a thread? 16.31.27 # i'm sure i did this before 16.31.35 # Torne: Press Remove Topic 16.31.42 # It's at the bottom of the page on the left 16.31.49 # not on this thread 16.32.07 # presumably because it's posted by gevaerts who is also a mod 16.32.42 # * gevaerts removes it 16.33.26 # i'll do a new one once i've fiddled with the code a bit more, anyway 16.35.17 Join toffe82 [0] (n=chatzill@12.169.218.14) 16.35.52 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.36.23 Quit bnijk_ ("Lost terminal") 16.37.53 Join Omlet [0] (i=omlet05@91.176.184.6) 16.42.33 Join stoffel [0] (n=quassel@p57B4F432.dip.t-dialin.net) 16.43.10 Quit HBK (Read error: 104 (Connection reset by peer)) 16.43.16 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.43.49 Quit HBK (Connection reset by peer) 16.46.08 Quit n17ikh (Read error: 104 (Connection reset by peer)) 16.46.22 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.46.47 Quit HBK (Success) 16.48.15 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.48.43 Quit HBK (Connection reset by peer) 16.49.50 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 16.54.34 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 16.56.58 Quit HBK () 16.58.03 Join faemir [0] (n=faemir@78.33.109.163) 17.00.40 Quit loyx (Read error: 110 (Connection timed out)) 17.06.25 Quit Zagor ("Don't panic") 17.06.49 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-212-230.pools.arcor-ip.net) 17.08.05 Join HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 17.09.30 Join loyx [0] (n=men@ool-43554637.dyn.optonline.net) 17.15.17 Quit petur ("connection reset by beer") 17.15.40 Quit Kitr88 () 17.16.39 Quit chaos (Read error: 60 (Operation timed out)) 17.17.39 Quit tomers (Read error: 60 (Operation timed out)) 17.17.40 Join chaos [0] (n=chaos@gentoo/user/ch4os) 17.26.55 Join CaptainKwel [0] (i=2669ecc2@gateway/web/freenode/x-haimpzjpjnfnnhzv) 17.35.11 Quit Jaykay (Read error: 110 (Connection timed out)) 17.35.20 Join Sajber^ [0] (n=Sajber@h-143-7.A213.priv.bahnhof.se) 17.39.11 Quit CaptainKwel ("Page closed") 17.46.32 Join Jaykay [0] (n=chatzill@p5DDC55BA.dip.t-dialin.net) 17.49.52 # ist MDCT from FasterMDCT "Modified Discrete Cosine Transformation"? 17.52.38 # FlynDice: did you hear of any problem reports on the Fuze after r23835/r23836 ? 17.53.23 # my Fuze (r23842) gets stuck starting up showing the Rockbox bitmap, the version number and battery/clock 17.53.29 # it doesn't reach the main menu 17.53.42 # topik: No, haven't heard anything, have you? 17.53.57 # i'm experiencing this 17.54.07 Join petur [0] (n=peter@d54C6F9B2.access.telenet.be) 17.54.45 # if i quickly put the Fuze on hold while it starts, and then back off hold i can get to the menu and use it normally 17.55.30 # it seems to happen just before the blue ring is supposed to get lit 17.56.03 Join dfkt_ [0] (n=dfkt@d86-33-169-63.cust.tele2.at) 17.57.22 # topik: That sounds similar to some things I tried that didn't work... :/ 17.57.47 Join kugel [0] (n=kugel@e178100158.adsl.alicedsl.de) 17.57.48 # Jaykay: yes 17.57.57 # topik: have you trued updateing the bootloader? 17.59.02 # Jaykay: it is used in several transform codecs and is using a substantial amount of the cpu cycles 17.59.03 # no, the bootloader is RC1 from a while back 17.59.04 # n1s: and the advantage of it is "only" less cpu-load on some codecs? 17.59.22 # n1s: ok, thanks :) 17.59.35 # the bar at the top loads, and it shows the rockbox version at the bottom so i'm guessing it's beyond the bootloader at that stage 17.59.37 # Jaykay: yeah, afaiu a faster MDCT has the advantage of beingm well faster 17.59.51 *** Saving seen data "./dancer.seen" 17.59.58 # topik: if you can use rockbox fine after that trick the bootloader might need an update 17.59.59 # s/m/,/ 18.00.22 # n1s: and what are transform codecs? 18.00.32 # i'll try that, kugel 18.01.01 # Jaykay: codecs that use transforms such as MDCT 18.01.08 # * kugel hasn't tried that revision yet on his fuze 18.01.18 # kugel: is your fuze working ok or have you even tried it? 18.01.21 # ok 18.01.24 # nm... 18.01.28 # :p 18.01.43 # kugel: it seems to only happen when the fuze is "cold". once i get it tricked to work, it works as usual 18.02.28 # can you try rolo'ing rockbox.sansa directly after a boot that needs the trick? 18.03.13 # that's navigating the file browser to that file and "view" it? 18.03.21 Quit dfkt (Nick collision from services.) 18.03.24 Nick dfkt_ is now known as dfkt (n=dfkt@unaffiliated/dfkt) 18.03.50 # topik: exactly 18.05.31 # Torne: re FS#10828 i wouldn't go so far as saying there's no bug in rockbox ;) this situation is a very ugly workaround imo 18.05.48 # n1s: well, we've previously discussed the fix 18.06.00 # which would be to move plugin/codec buffers to the start of ram, before the main binary, and then detect the memsize at boot 18.06.16 # yeah i hope we get the proper fix one day 18.06.17 # I guess we could just detect memsize anyway 18.06.17 # and tlel the user they are wrong 18.06.21 # that'd be better than nothing ;) 18.06.56 # yes, and it would be a step in implementing the proper solution 18.07.07 # "write code to detect ram size" is on my todo list 18.07.18 # i don't have a 32mb ipod to test on, though :) 18.07.21 # how would one do that, out of curiosity? 18.07.27 # depends how the 32mb ones work 18.07.39 # either hte second 32mb bank will be missing and will cause an external abort 18.07.45 # in which case you'll have to trap the abort.. 18.08.02 # or the second is a mirror of the first, which you can detect by writing a magic value somewhere and seeing if the magic value gets mirrored. 18.08.11 # the latter is much easier, but it depends how the hardware is wired up :) 18.08.25 # well ok there's a third option: missing but doesn't abort either 18.08.35 # you can detect tha tby writing and then reading and seeing if you get the right data you just wrote :) 18.08.45 # kugel: the "new" bootloader is saratoga's on the forum? 18.09.05 # i presume it aborts, since that's what happens when you run code, but it is unfortunately possible that it behaves differently for prefetch vs data 18.09.45 # Torne: one ugly workaround for this (if rolo is reliable) would be for the main binary to detect ramsize whenb booting and if it was 32MB just rolo a 32MB version 18.09.56 # when we can detect the size of course 18.09.57 # kugel: when i rolo it after a tricked boot, it works fine 18.09.58 # Torne: can you invoke rolo as an abort handler? :) 18.10.05 # gevaerts: i suspect not :) 18.10.12 # but i was going to give us a magic abort handler 18.10.33 # actually, that doesn't really work anyway, since the plugins are linked at a different address 18.10.33 # (a way to signal "yes, i expect to maybe abort here, just tell me if i did") 18.10.58 # yah 18.11.09 # gevaerts: right 18.11.27 # if i get around to it i'll write the code anyway, and someone with a 32mb ipod cna test it 18.11.36 # if it works we can decide what we want to do then :) 18.11.37 # i guess you guys decided going PIC was a Bad Idea (tm) ? 18.11.50 # n1s: it seems to be massively impractical without gcc changes 18.12.02 # and even then probably suboptimal 18.12.02 # except if you build with a different ROCKBOX_DIR of course... 18.12.03 # that's what i gathered 18.12.21 # n1s: the problem isn't the main binary. plugins and codecs are 18.12.24 # the "best" option would probably be to implement an actual relocatin gloader in rockbox, worryingly, and not do PIC at all 18.12.27 # gevaerts: yes, it could work with an amazingly hacked up build :) 18.12.42 # but that would be a reasonably huge effort for maybe not *that* big a benefit 18.12.50 # i'm certainly not about to volunteer for it 18.12.52 # :) 18.12.54 # "hm, this ipod looks much more like an x5, better rolo that one" :) 18.12.59 # kugel: partially, the main binary will still try to write outside ram 18.13.15 Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) 18.13.48 # I mean the "ugly rolo the 32MB binary" doesn't work 18.14.14 # kugel: yeah, gevaerts mentioned that 18.14.24 # oh I didn't see that 18.14.31 # yeah we can just print a message. or fix the memory map so two seperate builds are not needed. 18.14.33 # and i din't think of it 18.14.36 # more likely one then the other 18.15.00 # i'm still trying to sort DMA for now though ;) 18.15.42 # what would such a relocating loader have to do? change fixed addresses in the binary? 18.16.48 # We could just link the plugins and codecs at the start, "just" after the main binary, with some sort of safety margin. That wastes some RAM, but it shouldn't be more than a few hundreds of KB, and these are 32MB players at least. Not optimal, but it would work 18.17.24 # why not before the main binary even 18.17.40 # before the main binary is a slighlty more invasive change, but not impossible from my brief investigation 18.17.45 # it just needs someone to fuck about sufficiently 18.17.46 # :) 18.18.16 # Torne: invasive? it shouldn't be more than fixing a few lines in the linker scripts 18.18.25 # the bootloader needs to be changed also.. 18.18.28 # kugel: you still need to load the thing :) 18.18.43 # and then people would need to upgrade their bootloaders, of course 18.18.56 # not necessarily 18.19.18 # well you could have the main binary relocate itself 18.19.19 Join Kitar|st [0] (i=Kitarist@BSN-143-94-72.dial-up.dsl.siol.net) 18.19.20 # Either you change the bootloader, with *no* backward compatibility (i.e. upgrade at the same time), or you have the main binary relocate itself 18.19.20 # but that sucks :) 18.19.24 # do we then link the main binary to a static address and change that on the fly in the loader 18.19.26 # ? 18.20.00 # gevaerts: well you could be backward compatible, if you tried, actually 18.20.06 # gevaerts: you could change the model string or similar 18.20.11 # so the bootloader could tell the difference 18.20.15 # true 18.20.20 # crt0.S could look for the address it's running at, if it's the old area then move the binary before jumping to main 18.20.28 # the size of th ebootloader is not so critical, i think? 18.20.35 # there's plenty of room in the firmware partition ;) 18.20.44 # room for a few more lines of code 18.20.44 Quit evilnick_B ("Page closed") 18.20.51 # certainly 18.20.53 # kugel: having to relocate is silly though :) 18.21.28 # this would break my OSOS loading code, though, actually 18.21.33 # I don't see what's bad with breaking bootloaders 18.21.34 # because the apple rom always loads OSOS to the start of DRAM 18.21.50 # we have just released v6 so svn should be stable. and updating is really easy with rbutil 18.21.50 # so to preserve that feature it owuld have to be able to relocate itself :) 18.21.59 # we didn't even release a new bootloader for ipod 18.22.15 # (which i forgot to poke people about) 18.22.24 # (since the svn bootloader has the OSOS loading feature and the release one doesn't) 18.22.41 # ipod bootloader is different to the other PP bootloaders 18.22.53 # updating is still easy with rbutil.. 18.23.18 # we never guaranteed that bootloaders never need updates 18.23.26 # yah, bootloader updating on ipod is painless. 18.23.30 # and recoverable 18.23.50 # no, but we need to have the bootloader load older revisions at least. As Torne said, not that hard, but it needs to be done I think 18.23.53 # changing the model or similar, so we can detect a mismatch, would be good 18.24.04 # the error for failing to update won't be very good 18.24.43 # but it's better than it crashing :) 18.25.00 # * Torne is slightly disappointed that this breaks OSOS booting though :) 18.25.23 # that *would* require a relocation stub 18.25.46 # we could do both, of ocurse 18.26.21 # yes, but should we? If you write this relocation stub, is there a good reason to break bootloaders left? 18.26.26 # kugel, FlynDice : newly compiled bootloader makes no difference 18.26.34 # I agree with gevaerts, sometimes testing older versions can be usefull and having to switch the bootloader is annoying, especially since it should be pretty easy to keep compatibility 18.26.43 # gevaerts: well, there will be *some* speed impact, but it's probably pretty small 18.27.09 # about 0.1 seconds or so I guess 18.27.15 # at most 18.28.04 # i suspect we have a PIC memcpy() in crt0 anyway, for the ram remapping thing? 18.28.18 # topik: Do you know which revision made it start? 18.29.11 # well, we don't actually, it just inlines the trival one word at a time one 18.29.18 # Torne: no "memcpy" but moving sections around happens already 18.29.24 # yah 18.30.33 # branching to main might be tricky if main is not a fixed address 18.30.49 # it would be by the time it goes to branch to it.. 18.30.59 # FlynDice: r23842 is the first one i noticed it on. before i used one a couple of days old 18.31.29 # Torne: how? 18.31.34 Join funman [0] (n=fun@rockbox/developer/funman) 18.31.42 # you do this in crt0.. right after remapping ram 18.31.43 # the old binary expects to be run from a different address 18.32.18 # topik: does uSd or no uSD make any difference? 18.32.26 # hrm? 18.32.30 # i can build something from before your updates from r23829 onwards. 18.32.30 # i'm not sure what you mean 18.32.36 # haven't tried without uSD. moment. 18.33.03 # if you do compatibility, you either move the old binary to the original, or the new one to the new place. in either way the old and new binary have main() at different addresses 18.33.47 # first time without uSD worked. but i'm not sure i waited long enough between tries for the issue to happen 18.33.50 # no, you have the new binary able to relocate itself if it finds it's been loaded at the wrong address, and you have the new bootloader able to tell the difference between new and old binaries in order to know where to load them to 18.34.09 # then all combinations work; the combination of old bootloader and new binary just is slightly slower to start because of the copying. 18.34.44 # and it never matters where main() is.. 18.35.04 # main is called from crt0, not the bootloader 18.35.27 # bootloader calls start, which is always the first word in the loaded image. 18.35.29 # that is a clever solution :) 18.35.40 # n1s: it would also make OSOS loading work :) 18.36.01 # but as gevaerts said if you are going ot have the relocatoin code anyway do you even need to bother messing around with the bootloader like aht? 18.36.18 # the relocation probably doesn't take very long; it's just copying half a meg from one place to another in ram. 18.36.27 # Torne: ah right, main isn't called from the bl, my bad 18.37.10 # 1 and a half meg, rather 18.37.16 # Torne: the main problem with having it in two places is that after a while only one of them will actually be used anymore, and the other could well break silently 18.37.29 # gevaerts: yeah 18.37.54 # kugel: no, under 700kb 18.38.06 # We can solve that by removing it after six months or so, but I'd still like to see the actual speed impact first 18.38.10 # surely initialized data needs to be moved as well? 18.38.14 # kugel: yes, that's included 18.38.21 # topik: I'm actually getting the same exact symptom, stuck at same place, trying to get 4 bit bus working on the uSD. Of course it's always there right now..... 18.38.23 # rockbox.ipod is 686,072 bytes in the current build.. 18.38.34 # that's all the data you need to move, by definition 18.38.37 # :/ 18.38.40 # sorry again :) 18.38.55 # topik: How long does it take to get "cold" again...? 18.39.06 # 5 minutes? 18.39.24 # i'm glad you're able to reproduce it. that gives us users a far bigger chance of a solution :) 18.39.29 # gevaerts: either people keep using old bootloaders, then we will now when it breaks; or nobody will use old bootloaders anymore, then we don't care of the old one is broken, isn't it? 18.39.52 # topik: Could you wait 10 mins then and give it a try withou the uSD? 18.40.06 # of course 18.40.26 # kugel: yes and no. It adds maintenance overhead in the long term, and people might assume that it works when needing it for some reason 18.40.32 # topik: Thanks, I'll be here 18.41.28 Join evilnick_B [0] (i=0c140464@rockbox/staff/evilnick) 18.42.09 # well when I'm bored of DMA i will probably try this ;) 18.42.26 # stuff in crt0 is usually rock solid over a very long term, meaning that once it works it never breaks again, so I don't expect it to be a problem 18.42.30 # see how trivial it is to remap everything and see how long it takes to have the binary reloc itself. 18.42.45 # if it's negligible then we might as well leave the bootloader alone 18.43.10 # there's no benefit to changing it *other* than eliminating the reloc time. 18.44.00 # I doubt it will be noticeable afterall 18.44.32 # kugel: if the relocation takes 0.5 seconds, we should probably do both. If takes 0.05 seconds, I vote to leave the bootloader alone 18.44.35 Join JdGordon| [0] (n=Miranda@nat/microsoft/x-xompcartxpyigwof) 18.45.19 # * kugel counts <= 0.5-0.7s as unnoticeable 18.45.39 # i agree with that 18.45.50 # Ah, one problem is that at this early stage in booting the cache will be off :) 18.46.00 # so it might tkae longer than you would think :( 18.46.03 # Torne: is it? Isn't cache useless for this? 18.46.09 # we shouldn't be discussing breaking bootloaders until it exceeds 1s even IMO 18.46.13 # gevaerts: depends how prefetching balances out :) 18.46.33 # gevaerts: i'm not sure what optimal timing is for the PP with its weird cache 18.46.43 # kugel: wasn't the plan *not* to break the bootloader 18.46.53 # but for ARM9/ARM11 type caches the cache will prefetch in a very helpful way if you arrange the code nicely, and give you substantially faster copies 18.47.07 # s/breaking/touching/ :) 18.47.16 # n1s: the plan is not to break the bootloader, but we're allowed to change it :) 18.47.21 # too bad we have no arm9/11 targets with varying ram size :) 18.47.33 # gevaerts: that's what i meant 18.47.39 # n1s: if we did they'd probably have MMUs anyway 18.47.45 Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) 18.47.48 # caches are disabled after the bootloader finishes? 18.47.57 # kugel: no, crt0 disables the cache shortly after starting 18.48.05 # because it's copying code to iram and then relocating RAM to 0 18.48.07 # Torne: ah, yes, no need to copy 18.48.11 # which would go horribly wrong if caching was still inplace :) 18.48.17 # or at least, need flushes 18.48.20 # easier to disable it. 18.48.39 # especially since you can only blow away the whole cache at once on pp as far as we know :) 18.49.19 # hm, iram... 18.49.38 # That means that the amount of data to copy is actually slightly smaller :) 18.49.45 # gevaerts: yeah, you can skip that part. 18.50.29 # does the bootloader copy iram sections to iram currently or does crt0 do that too? 18.50.33 # crt0 does that as well 18.50.50 # potential for optimization then! 18.50.58 # the bootloade rliterally just loads rockbox.ipod minus the header to the start of ram and then branches to the start of ram. 18.51.18 # meh, it's better to minimise coupling between them in general :) 18.51.21 # kugel: is there any reason you didnt origionally just clear the entire display if viewport_set_statusbar(true) happened? 18.51.36 # instead of using the events you added 18.51.41 # Torne: yeah, j/k 18.51.58 # JdGordon: yes, for the same reason your latest patch adds massively erratric flickers everywhere 18.52.10 # massivly eratic flickers?! 18.52.23 # I was using a build with your patch today 18.52.40 # the clear_display you added is very noticeable 18.53.18 # massivly erratic though? and everywhere? 18.53.20 # anyway, this is on my list of "things i kinda care about and will maybe look at when i get a chance", so who knows, we might find the answer to how long it takes at some point :) 18.53.34 # and being in viewport_set_statusbar isn't sufficient 18.53.45 # also, I wouldnt use that build just yet... it will panic if you enter the wps too often 18.53.58 # it didn't panic for me 18.53.58 # why not? 18.54.16 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 18.54.52 # FlynDice: cold, without uSD it starts fine 18.54.58 # the event is also used for clearing some splashes and some other stuff where viewport_set_statusbar isn't called 18.55.18 Join Tomis2 [0] (n=Tomis@70.134.92.158) 18.55.40 # topik: Now when you pop the card in does it init ok? 18.55.57 # that's what i tried, it works fine 18.56.16 # JdGordon|: going from the main menu to any item results in a noticeable (single) flicker 18.56.26 Quit Tomis (Read error: 60 (Operation timed out)) 18.56.27 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.92.158) 18.56.39 # it's worst in the sbs area, but but also noticeable in the list area 18.57.02 # ok, that was a very naive first go.. 18.57.05 # topik: What kind of card? 18.57.07 # that's why the event draws the statusbar and can take a redraw function, the flicker is killed with that 18.57.45 # how do i give you more info beyond "sandisk sdhc 8GB" ? 18.58.09 # top 18.58.19 # whoops 18.58.43 # the good thing about the patch: all plugins magically show the sbs properly and only in its menu (and not where it's not wanted) 18.59.14 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.59.50 Quit dfkt (Read error: 60 (Operation timed out)) 18.59.50 # topik: Can you go into system/debug/view disk info and tell me if speed is 50.0 MBit/sec 19.00.00 # JdGordon|: if enter_wps() can be called multiple times without leave_wps() after each, it seems like a bug to me 19.00.42 # yes 19.01.04 # oh, the problem is the the if (restore) block in the main loop 19.01.27 # FlynDice: it only lists the internal storage i think. microsd 0. which runs at 25MBit/s 19.01.39 # oops, 19.01.40 # press select 19.01.47 # microsd 1 is at 25Mbit/s too 19.02.18 # JdGordon|: restore should only be true after the wps is (re)entered from some other screen (where leave_wps() was called before) 19.02.54 # now I find that intersting... means it's not getting changed to high speed timings 19.03.15 # JdGordon|: I'm not able to trigger a panic 19.03.31 # yeah, except also happens after changing volume(!) and I think possibly after a while of nothing 19.03.33 # do any of the other numbers mean anything to you? 19.03.54 Join Tomis2 [0] (n=Tomis@70.134.101.207) 19.03.59 # just go wps->menu->wps about 7 time I think 19.04.13 # I wish USB would work so we could use debugging through usb serial 19.04.38 # did anyone look at reusing the ipod nano 2g usb code on sansa ams ? 19.05.11 # topik: well, I know what they mean but as far as this goes I don't think they matter.. 19.05.25 # JdGordon|: update_on_volchange() only returns true on charcell, never on lcd_bitmap (don't ask me why) 19.05.46 # would you recycle that card and see if it stays at 25? 19.05.55 # oh goody 19.06.12 # maybe its a sim only thing.. either way it needs to be fixed :) 19.06.22 # no change, FlynDice 19.07.32 # one of the widely available (j/k) charcell users should check if restoring the wps is actually needed 19.08.26 # I can imagine that's simply a left-over from pre-skin engine times 19.08.32 # I find it hard to believe a sandisk 8GB sdhc is not a v2 card... no I'm not doubting you just typing while I think... 19.08.35 # probably 19.09.03 # i doubt i still have the packaging. the card came with the fuze as a freebie 19.09.08 # topik: How old is the card? 19.09.15 # bertrik: did you see http://www.rockbox.org/mail/archive//rockbox-dev-archive-2009-12/0009.shtml ? 19.09.21 # I thought HC was always v2? 19.09.29 # me too... 19.09.58 # you could dump the csd and check 19.10.20 # funman, yes, I'm fine with reverting that 19.10.52 # this TEST1 register is a bit weird 19.11.00 # bertrik: do you remember how you made this commit ? 19.11.10 # there is a circled 2 on the card 19.11.19 # that would help fixing FM on e200v2 (and c200v2?) 19.11.20 # my change seemed to make it work better on c200v2, but it didn't help much 19.11.23 # Thats speed class I think 19.11.50 # which is still HS 19.11.51 # bertrik: i already reverted the c200v2 change, this commit is about e200v2 (from June) 19.11.56 # fm on e200v2 should work without this patch too 19.11.59 # oh, ok 19.12.22 # fm on e200v2 wouldn't work at all with my change from june 19.12.31 # argh, *without* 19.12.49 # JdGordon|: the event probably needs to stay, but it could be changed into a function call since it's always active since a while (it was only active when custom ui vp is used originally) 19.13.05 # ok but it looks illegal according to my datasheet, did you make this change after reverse engineering the FM code ? 19.13.07 # that would be fine 19.13.30 # I really dont like using events as function calls which is sort of what it is in svn 19.13.30 # funman, I don't know exactly anymore 19.14.07 Quit bmbl ("Bye!") 19.14.12 # wasn't the devcon in june ? 19.14.18 # Unhelpful: as Torne mentioned, dancer doesnt really let you do those things without being op anyway - their philosophy is more of an open one, so someone hiding by not being opped and issuing out kicks and such is not desirable...while there are some commands that chanserv allows you to do, you must be opped in order for it to allow you to do it 19.14.51 # right, this commit was made during devcon 19.15.18 # JdGordon|: it made sense to be an event at first; I also thought about possibly having more callbacks but it turned out not needed 19.15.31 # funman, I tested it on domonoky's e200v2 19.16.27 # I think we should make a list of exactly what fm chip is used in what ams sansa player, and what works for each revision 19.17.02 # kugel: fine.. I'm thinking that the screen clear shuold work everywhere (with a bit more smarts) with the worst happening is a black screen for a tiny fraction of a second.. even with the splash 19.17.05 # iirc there was different chips in different hardware revisions of Clipv1 19.17.09 # I'm pretty sure all of the ams sansas need the XOSC_EN bit set somehow in the TEST1 register 19.17.29 # right, but what is bit 8 ? 19.18.32 # it should be able to clear the screen fully every time it goes from theme off to theme on without any delay because the screen is always redrawn instantly in that case 19.18.52 # the problem is the lcd_update() which needs to happen after the clear because the nxt screen doesnt update the full display 19.18.53 Join jasio [0] (n=yann@cpc2-rdng23-2-0-cust292.15-3.cable.virginmedia.com) 19.19.05 # bertrik: another thing, did you see my forum post about mkamsboot/c200v2 ? 19.19.27 # the DBOP thing? 19.19.33 # in the case of the splash, this would work because it would disable the them, draw (without clearing the display), then reenable it when leaving 19.19.40 # yes, use DBOP to read buttons in dualboot.S 19.20.01 # i could do it and ask you to test before putting a test build on the forum 19.20.15 Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) 19.20.21 Quit Tomis (Read error: 110 (Connection timed out)) 19.20.21 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.101.207) 19.21.49 # funman, I think I prefer using simple GPIO instead of DBOP in the bootloader, it's much simpler and easier to verify for correctness 19.22.16 # JdGordon|: the problem is that a blank screen even for a split second is noticeable and ugly :/ 19.22.18 # bertrik: but appears to not work on some c200v2 19.22.47 # doing it right requires more than "a bit more smarts" I fear 19.22.52 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 19.22.52 Quit pixelma (Nick collision from services.) 19.23.11 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 19.23.12 # it looks like the event is the best we can do right now 19.23.15 # kugel: yes, agreed.. but it should happen too quickly to be seen :( does the lcd drivers have a way of saying "do a full update next update call.. regardless of the viewport?" 19.23.47 # that would fix the issue 19.23.52 # s/fix/remove 19.23.57 Quit amiconn (Nick collision from services.) 19.24.01 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 19.24.06 # hm, that could probably work 19.24.41 # topik: Right now I'm guessing(and hoping ;-) ) this is an issue with your particular card. Of course you may just be the first to experience it.. Please don't feel like I'm discounting your problem. I will keep it in mind as I look over the code. 19.24.49 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 19.25.19 # and see if others start reporting similar problems 19.25.30 # no no, not at all. i appreciate you listening to me and working on making my Fuze even better 19.25.49 # i read about people with uSD problems before and never had any myself. so i figured i'd report it since it only just started happening 19.26.16 # in your current patch, the flicker seems to happen unecessarily too though. I wouldn't like to do clear_display too often just because 19.26.59 # sandisks are usually "bulletproof" from my experience with complaints! 19.27.07 Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-wbyxebbxxmfowoay) 19.27.16 # amiconn: "29-105% faster apply_filter, 6-90% faster ape decoding on core2" 19.27.33 # you paid attention to any of the ffmpeg optimizations to the ape decoder? 19.27.46 # i can try building an older revision from just before your set of changes and see what the speed is then 19.28.13 # If you're willing to spend the time I'd be interested! 19.28.19 # saratoga: some of these are x86 asm no? 19.28.27 # don't know if they're even applicable to fixed point though 19.28.47 # any revision you'd prefer? 19.28.47 # funman: yeah, but the idea might be portable 19.28.55 # (I don't actually know how APE works) 19.35.55 # asm is by definition not "portable", isn't it? :) 19.36.13 # you might be able to port it nevertheless though :p 19.36.26 Quit mikroflops_ (""Maailmanpyoramuualta"") 19.38.31 # yeah but it's not only asm 19.42.16 Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) 19.45.19 # bertrik: can you try http://pastie.org/727839 please ? 19.45.36 # the check for usb connection is made before the button check so it's safe 19.46.14 # dual-boot button should be the left button 19.47.29 # i was just wondering, if its possible to change some of the rockbox settings from a playlist 19.48.21 Join Guest23293 [0] (n=n17ikh@host-69-59-126-212.nctv.com) 19.48.24 # funman, ok I'll try it later tonigh 19.48.25 # for example by adding a config file to the playlist that is "played" 19.48.50 Quit n17ikh (Nick collision from services.) 19.48.58 Nick Guest23293 is now known as n17ikh (n=n17ikh@host-69-59-126-212.nctv.com) 19.50.27 # this might seem a little odd, but especially for sing along stuff and so on i want to adjust the pitch of songs per situation or the EQ or Channel config 19.51.49 Quit n17ikh (Client Quit) 19.53.59 Join Strife89 [0] (n=Strife89@adsl-146-197-34.mcn.bellsouth.net) 19.57.07 Join Omlet05 [0] (i=omlet05@91.176.181.84) 19.57.21 Join n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) 19.58.26 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 19.58.37 # funman: "ldr r1, =0xa167e06f" works? I thought immediates are limited to shifted variants of +-4096 19.59.18 # or does as automatically convert it? 19.59.55 *** Saving seen data "./dancer.seen" 20.00.20 # ldr doesn't take immediates, mov does 20.00.41 # ldr rX, =ZZZZ will place ZZZ in memory near the ldr instruction 20.01.59 # so it's conerted to a ldr rX, [pc+Y] by the assembler 20.04.29 # yep 20.07.47 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 20.08.29 Quit bertrik ("De groeten") 20.09.05 Quit funman ("free(random());") 20.09.37 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 20.10.07 Quit Tomis (Read error: 110 (Connection timed out)) 20.13.49 Quit Omlet (Success) 20.16.53 # saratoga: I noticed someone at abi made a guide for a DIY "dock" that uses the line-out of the fuze 20.18.37 # I just wonder what diyLOD is 20.19.15 # maybe do-it-your-self-line-out-dock? :S 20.20.00 # or do-it-yourself-Laser-Of-Doom 20.23.56 Join Tomis [0] (n=Tomis@70.134.73.183) 20.31.14 Quit Tomis (Read error: 60 (Operation timed out)) 20.31.43 Join Casainho [0] (n=chatzill@87.196.81.204) 20.36.09 Nick Omlet05 is now known as Omlet05^away (i=omlet05@91.176.181.84) 20.41.17 Part watto 20.41.18 Join domonoky1 [0] (n=Domonoky@g229178184.adsl.alicedsl.de) 20.45.26 Join solexx_ [0] (n=jrschulz@e182090083.adsl.alicedsl.de) 20.45.49 Quit Strife89 ("If you hold a Unix shell to your ear, you can hear the C.") 20.57.32 Quit solexx (Read error: 113 (No route to host)) 20.58.13 Quit flydutch ("/* empty */") 20.59.07 Quit domonoky (Read error: 110 (Connection timed out)) 21.05.15 Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) 21.07.04 Quit dfkt (Nick collision from services.) 21.07.09 Nick dfkt_ is now known as dfkt (i=dfkt@unaffiliated/dfkt) 21.16.30 Quit Sajber^ (Read error: 104 (Connection reset by peer)) 21.18.54 Quit tchan ("WeeChat 0.3.1-dev") 21.26.38 Join p3tur [50] (n=petur@rockbox/developer/petur) 21.33.06 Join kugel_ [0] (n=kugel@e178080233.adsl.alicedsl.de) 21.34.17 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 21.40.11 Quit domonoky1 (Read error: 104 (Connection reset by peer)) 21.44.21 Join tubafish [0] (n=4cd4e124@giant.haxx.se) 21.45.01 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 21.48.06 # I was wondering if anyone might have an idea of what might be causing this situation. In my car, I have a Sony Xplod head unit. It features Sony's 1-wire control. With that feature, you should be able to control your MP3 player from the head unit. It is compatible with my rockboxed Sansa Clip, yet it fails to recognize my rockboxed 80gb 5.5generation iPod video. Does anyone know of any workarounds or what might be happening? 21.50.05 # how does it control the clip? 21.51.02 Quit kugel (Read error: 110 (Connection timed out)) 21.51.48 Join lostlogic [50] (n=lostlogi@rockbox/developer/lostlogic) 21.54.20 Quit tubafish ("CGI:IRC") 21.54.23 Join tubafish [0] (n=4cd4e124@giant.haxx.se) 21.54.27 Join Byan [0] (n=notByan@lackey.csl.mtu.edu) 21.54.51 # can you customize the whole menu? 21.55.11 # not without recompiling your own build 21.55.25 # =( 21.55.27 # why not? 21.55.44 # because its something most people here dont want to allow 21.56.00 # weird.. cause it was one of the best features of the iPod firmware >_> 21.56.25 # anyway, is bleeding edge usually stable, or should I edit the source of a release? 21.57.09 # the release is a mostly arbitrary point in time where we make a copy of the last nightly and call it release 21.57.29 # yea totally... 21.58.00 # lol, ok 21.58.18 # that was more or less the case for 3.4, but it definitely wasn't for 3.0 and 3.1 21.58.43 # and making it into some sort of slogan is not going to fix things 21.59.13 # gevaerts: hrm? 21.59.16 # slogan? 21.59.37 # we already talked more about the release 1 week before the freeze now than in total about 3.4 :) 21.59.57 *** Saving seen data "./dancer.seen" 22.00.06 # Byan: don't bother. Internal arguments between devs 22.00.18 # alright >_> 22.00.33 # so, whats the reason for not allowing the entire menu to be customized anyway? 22.00.57 Quit tubafish ("CGI:IRC (Ping timeout)") 22.01.12 # The official reason is that it will cause support headaches, as you can't tell people where to find options anymore 22.01.25 # >_> 22.01.43 # thats a stupid ass reason, imo 22.01.48 # but, ok 22.01.53 # yes.. yes it is 22.01.54 # you're not doing the support :) 22.02.13 # gevaerts: maybe there should be an easy way to get into the default menu 22.02.17 # just for that case 22.02.34 Join liar [0] (n=liar@83.175.83.185) 22.02.37 # how is it usefull though? imo it's just a gimmic feature 22.02.43 # n1s: what? 22.02.53 # Also of course, any such option will have a cost in CPU and memory, and we have some low-memort targets where that might be a problem 22.02.56 # no, for instance, I like to use the sleep feature alot 22.03.13 # to get to it I have to do like.. 22.03.17 # 4 menu selects.. 22.03.20 # I'd like it to be 1.. 22.03.32 # go code it then, the source is yours 22.03.38 # I plan on it 22.03.43 # Putting ... after every sentence doesn't make it more likely to happen :) 22.03.47 # it's checking out right now >_> 22.04.02 # we don't even need to discuss inclusion as long as nobody is doing the work 22.04.07 # AlexP: we won't know unless we try 22.04.08 # Anyway, right now the project standpoint is "no", but we know people want it, and I plan to make sure it (and other similar standpoints) gets on the agenda for the next devcon. 22.04.18 # Byan: How is that related to what I said? 22.04.37 # it was just a joke.. 22.04.46 # gevaerts: sounds good 22.05.22 # even if the project changes its mind someone needs to code it 22.05.54 # it sounds trivial to code 22.06.01 # in comparison to most things that rockbox has.. 22.06.09 # * JdGordon| has said many times that making the menu entirely customisable is piss easy and very low resource wastes... 22.06.49 Quit tmzt (Read error: 60 (Operation timed out)) 22.07.01 # the best way to force a discussion is a patch :) 22.07.09 # Byan: Can the sleep timer not be put in the quick screen? 22.07.19 # It might turn out to be a flamewar instead of a discussion though 22.07.19 # probably not 22.07.28 Quit Casainho (Connection timed out) 22.07.29 # gevaerts: "might"?! 22.08.03 # I'm not a big fan of customisable menus, but I don't really care - we just tell people they need to reset the menus to default to get support. If they are able to find their way around without doing that then all power to them 22.08.44 # I already customise my menus by building without the database :) 22.08.57 # JdGordon|: no comment :) 22.09.03 # AlexP: I think there needs to be a lot of safeguards in place too. Inability to remove items (just reposition them), ability to reset the menus on-target without resetting your settings, things like that. 22.09.54 # Llorean: sure, but if the general idea is approved, then those are just (albeit important) details 22.09.56 Join Casainho [0] (n=chatzill@87-196-81-204.net.novis.pt) 22.10.16 # honestly, I just realized what the quick screen is 22.10.31 # that thing is awfully annoying actually, cause I use it by mistake all the time 22.10.36 # AlexP: Well if someone wants to get the idea approved, they should put a lot of effort into making the patch mitigate things most likely to be complained about *before* they show up with it for further discussion 22.10.39 # where do I change the settings for it? 22.10.51 # Llorean: A fair point 22.11.04 # oh, context menu.. 22.11.06 # Byan: Context menu on the setting you want 22.11.07 # ok 22.11.21 # anyway 22.11.23 # that reminds me 22.11.24 # AlexP: The first time they bring a patch in there, people are going to say what it's missing. Some people take that as "complaints" rather than "I should now try to address these" 22.11.40 Join killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) 22.12.06 # why cant options be completly removed? 22.12.08 # is there a way to set it so that when you plug in a cable it charges by default instead of starting the HDD mode thing? 22.12.43 # cause I forgot to hold menu about half the time >_> 22.13.14 # JdGordon|: Because people may remove an option without realizing they need it. Instead they should be limited to putting it somewhere out of the way (say an "Advanced" submenu or whatnot) so that if they do screw up, they can get to it without resetting settings 22.13.29 # Byan: Swap the logic in the code 22.13.30 # Since I doubt there's going to be an effective menu organization UI outside of a plugin or editing .cfgs. 22.13.42 # AlexP: lol, alright >_> 22.14.21 # Byan: I think there used to be a patch on the tracker with an option for toggling between "charge on default" and "UMS on default" 22.14.27 # Llorean: if they can figure out the menu organisation config (however its done) then they are smart enough to not worry about that.. I think thats a rediculous requirement 22.14.27 Join dutchie [0] (n=josh@pdpc/supporter/student/dutchie) 22.14.31 # and hard to implement 22.15.19 # couldn't you just make it so that there are two configs.. one that they are suppose to edit 22.15.27 # and that if you hold a button on start, it uses the default instead 22.15.47 # JdGordon|: Oh yes, people *never* make mistakes. 22.15.55 # And then find themselves in a week trip without PC access. 22.16.05 # Seriously, what's wrong with having a little bit of safety for the user in there? 22.16.12 # my nano 2g is not appearing mounting right. excerpt from dmesg: http://pastebin.com/m10964b4 on ubuntu karmic 22.16.50 # Byan: Rebooting the player is actually pretty battery intensive. Is there some reason why it's significantly "bad" to say "you can just reorganize, not remove"? 22.16.56 # I can mount it manually on the CLI, but not through any GUI 22.17.14 Join webguest38 [0] (n=3ff1ae81@giant.haxx.se) 22.17.16 # Llorean: because.. writing the stuff to reorganize is harder than just having a config file to parse 22.17.29 # I mean, what happens right now if someone screws up their tagnavi file on accident.. 22.17.42 Join tmzt [0] (n=tmzt@adsl-99-164-34-42.dsl.akrnoh.sbcglobal.net) 22.17.42 # Byan: Tagnavi doesn't prevent use of the player if it's messed up. 22.17.45 # Byan: then they throw away the tagnavi file? 22.17.55 # gevaerts: but they are "without PC access" 22.17.58 # do the same with the menu config file 22.18.11 # Byan: so? rockbox has a file browser 22.18.19 # gevaerts: oh, right 22.18.21 # Byan: How is "reorganize" harder than "just having a config file to parse" - if they miss a setting in their parsed config file (either by typo or by leaving it out) it ends up in the default tree location it would normally have. Bam, done, can't remove settings 22.18.24 # JdGordon|: you just disabled the "file" entry 22.18.45 # then reset the settings on boot 22.18.50 # Llorean: oh, well, there ya go 22.18.52 # Llorean: thats a fine idea? 22.19.23 # * gevaerts isn't convinced either way 22.19.47 Quit webguest38 (Client Quit) 22.20.03 # Also, the less buttons a user can hold and cause things to happen on boot, the better. 22.20.05 # Reset on boot is a bit annoying if it resets everything, and another button to hold doesn't sound that good either 22.20.29 # reset on boot is there exactly for that reason... 22.20.32 # On some players I seem to recall detecting certain buttons on boot being really unreliable anyway. 22.20.47 # Llorean: from the bootloader, or from the main build? 22.20.53 # JdGordon|: So basically the option is "get your menu right on boot, or lose all your settings" 22.21.16 # and thats not reasonable why? 22.21.34 # how often are people going to have bad config files.. 22.21.39 # gevaerts: I think some players it's "we can't detect buttons if they've been held from before power on" and others they won't be detected if they're held and it transitions from bootloader to build. Not sure. 22.21.51 # ah, that sounds likely 22.21.53 # Byan: If you're asking them to reorganize the whole menu to their liking, fairly often. 22.21.57 Join Tomis [0] (n=Tomis@70.134.72.209) 22.22.08 # JdGordon|: Because it's possible to be more user friendly than that very easily? 22.22.26 # Is there some reason we have to do things in the way most able to let users shoot themselves in their foot? 22.22.33 # save your settings in a seperate .cfg and there is no issue 22.22.59 # I think there's something else to consider. Are you going to allow configuring the menus from within rockbox, or not? If not, the reset issue is a lot less important I think 22.23.04 # there is a reason C is such a powerful language... 22.23.15 # gevaerts: I agree.. 22.23.28 # gevaerts: Less important if you can't change them in Rockbox? 22.24.08 # JdGordon|: Or there's no issue if you make a minimal step to make it "safer" for users. 22.24.17 # Why exactly is disabling the removal of items *bad8? 22.24.41 # so go ahead and implement that... you ovbisouly had no clue as to how hard that would be to do in the code 22.24.50 # It provides a very significant layer of safety, and the only "inconvenience" is that somewhere buried deep under things you'll know a few settings are there. 22.25.26 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 22.25.30 # Llorean: if you have to edit a config file, I think people are a lot more likely to do it from a real text editor, and I suspect that a lot more of them will test basic functionality. If you have a nice menu editor plugin, people will edit their menus whenever they're bored 22.25.40 # the option I've brought up just about every time we have this argument is force the full current menu system in the top menu... 22.25.46 Join GeekShado_ [0] (n=Antoine@15.160.204-77.rev.gaoland.net) 22.25.58 Quit stoffel (Remote closed the connection) 22.26.08 # JdGordon|: well, if all you did is require the user to place a "Advanced" or "StuffIDon'tWant" folder somewhere.. and then everything that isn't placed would just go in there? 22.26.14 # I don't see a problem with that 22.26.15 # gevaerts: I'm not sure I'd trust people to test basic functionality just because they use a text editor (specifically, the presence of settings they've forgotten about or don't know what do) 22.26.18 # it'd be easy 22.26.30 # JdGordon|: You mean the top level, not the top item of the top level I hope :) 22.26.37 # yes 22.27.00 # Llorean: maybe not, but I feel a lot more comfortable telling them to wipe all their settings if they could *easily* have made sure nothing bad would have happened 22.27.06 # Byan: no, that would mean a pretty big waste keeping track of which items are not put somewhere 22.27.23 # you'd only have to calculate it once >_> 22.27.40 # but the whole argument is just stupid... the first thing support says after "are you usign a current build" is "have you tried resetting your settings" 22.27.54 # haha >_> 22.27.55 # JdGordon|: You may have noticed I didn't talk about support at all 22.28.10 # I talked about user friendliness, and helping people avoid shooting themselves in the foot. Because of situations where support *isn't* available. 22.28.45 # These are portable players, the worst case should always be assumed to be "I have nobody else around, and no computer." In that situation, try to make fixing things as non-destructive as possible. 22.29.21 Quit kugel_ (Read error: 113 (No route to host)) 22.29.26 # * JdGordon| gives up... if someone 2wants technical help to implement this I'm open to help.. otherwsie i just dont care anymore 22.30.01 # JdGordon|: you can always implement the version without safe guards and improve it later >_> 22.30.32 # my todo list is way longer than time avialble... 22.30.41 # I can't blame you for that 22.31.10 # lol, if I were so rich I didn't have to work... 22.31.15 # so much stuff I'd want to do.. 22.32.04 # Llorean: you have any more ideas on where I could find that patch? 22.32.50 # Byan: No clue, sorry 22.32.51 Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-brkixouqkkeakbgv) 22.33.29 # alright 22.33.29 # New commit by 03bluebrother (r23848): Fix "Warning: Signals cannot be declared virtual" for progresslogger when building with Qt 4.6. 22.36.25 # Byan: I think it was held up because it also included discussion of reorganizing what button is held for USB connection, etc. 22.36.48 Join swistach [0] (n=sdsfs@ens53.neoplus.adsl.tpnet.pl) 22.37.03 # jest tu jakiœ polak? 22.37.16 # English please 22.38.44 # Ok. someone from Poland? I need help. 22.39.20 Quit GeekShadow (Read error: 104 (Connection reset by peer)) 22.39.52 # Llorean: yeah.. the current method is bad.. 22.40.27 # the best solution, in my opinion, is you plug it in, and then it asks you if you want to start UMS 22.40.39 # That's pretty slow if you've actually learned how to use it. 22.40.47 # It's only really useful the first dozen times you plug in or so. 22.40.58 # Byan: in my opinion that's the absolutely worst possible option 22.41.03 # Byan: That is a highly annoying wasye of time 22.41.08 # *waste 22.41.13 Quit swistach (Client Quit) 22.41.15 # >_> lol, ok, nevermind 22.41.35 # I guess I am in the majority that 95% of the time they plug it in they are only charging 22.41.55 # and starting UMS is very time wasteful if you idnd't mean to 22.41.59 # minority* 22.42.12 # So hold the button 22.42.34 # I don't always remember to.. 22.42.35 # Byan: A lot of players also have standalone chargers where holding the button isn't necessary, so the only time you attach to a PC WOULD be to sync because charging there is a lot slower. 22.42.37 # even then holding a button while plugging is faster then waiting for the menu or even navigating it 22.42.37 # Byan: word of caution.... stop with the >_> and lols 22.42.44 # Byan: I can't help you with that 22.43.09 # JdGordon|: alright. 22.43.35 Part froggyman 22.44.39 Quit Jaykay ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") 22.46.03 # do I just need to change the static inline bool usb_power_button(void) 22.47.19 Quit tchan ("WeeChat 0.3.1-dev") 22.49.16 Join Sajber^ [0] (n=Sajber@c-c33271d5.012-155-73746f22.cust.bredbandsbolaget.se) 22.53.46 Quit evilnick_B ("Page closed") 22.54.05 # whats the Build (A)dvanced do? 22.54.20 # Byan: try it! 22.54.24 # Gives you advanced build options 22.54.48 # anything useful? 22.54.53 # yes 22.55.01 # Otherwise they wouldn't exist 22.55.12 # Useful for what you are doing, I don't know 22.59.05 # lol, I like how there a ton of pages for compiling under windows, but none for linux 22.59.23 # because generally people need less help 22.59.28 # And there are plenty 22.59.32 # oh nevermind 22.59.40 # All of the none specific pages are for linux 22.59.42 # well, it wasn't next to the other ones on the list 22.59.57 Quit TopyMobile ("Ex-Chat") 23.00.00 # The specific windows ones exist as you have to do things like have a VM or cygwin 23.00.14 Join TopyMobile [0] (n=topy@xdsl-78-34-66-147.netcologne.de) 23.05.07 Part hatseflats 23.05.12 # hrm, cant figure out what packages contain the crosscompiler 23.05.18 # this doesn't seem like it should be this hard >_> 23.05.24 # Byan: you build it 23.05.28 # run tools/rockboxdev.sh 23.05.34 # It sets up everything for you 23.06.22 # oh 23.06.23 # thats nice of it 23.06.36 # ROCKBOXDEV: "bzip2" is required for this script to work. 23.06.38 # psh >_> 23.06.58 # See http://www.rockbox.org/wiki/DocsIndex#For_Developers - e.g. the CrossCompilers page there would have helped you here 23.07.22 # is "psh >_>" your shell prompt? 23.07.32 # no, I typed that 23.07.40 # I would horribly murder anything with >_> in it 23.07.42 # that'd be funny though 23.14.47 Quit Casainho (Read error: 60 (Operation timed out)) 23.16.25 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) 23.20.30 Quit TopyMobile (Read error: 110 (Connection timed out)) 23.23.41 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 23.29.52 Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) 23.34.02 Join Casainho [0] (n=chatzill@87-196-81-204.net.novis.pt) 23.35.22 # * LambdaCalculus37 wants to push to get the GoGear SA9200 to a working state 23.40.44 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 23.40.46 Quit tchan ("WeeChat 0.3.1-dev") 23.41.47 # Still need a cabbiev2 for 128x160 resolution. 23.42.03 # And a manual. And a better install method. And the rest of the plugins. :) 23.42.16 # sounds like some work left :) 23.43.03 # bluebroth3r: I'm not a very good artist, so I can't do the cabbiev2 theme for it. :) 23.43.35 # New commit by 03nls (r23849): FS#10711 by Martin Ritter fixes handling of the 'First Keypress Enables Backlight Only' setting in simulators 23.44.05 # * Byan likes his text only theme 23.45.22 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 23.47.09 # Byan: Regardless, we don't have a version of cabbiev2 for 128x160 screens, and thus need to have one made. 23.47.24 Quit Omlet05^away ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 23.47.32 Quit FlynDice (Remote closed the connection) 23.48.01 # true enough 23.48.16 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 23.52.13 # i wonder if we should make a wiki page with common trouble shooting tips 23.53.05 # like the "fsck, and if that's ok, do biary search for bad file, then report useful bugreport" thing we repeat over and over for databse initing troubles 23.53.16 # "try turning the dircache on" 23.53.24 # "or off" 23.53.24 # "are you resetting with menu+select" :) 23.53.37 # Torne: yes! 23.53.44 # "no no it's not a cup holder!" 23.53.46 # ;-P 23.53.50 # ;) 23.53.56 Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 23.53.59 # rockbox-ified ipod nano 2g not mounting on ubuntu 9.10: dmesg http://pastebin.com/m10964b4, don't see a /dev entry or a listing in lsusb 23.54.32 # * stripwax can't remember if nano 2g has dual boot 23.54.40 # does it work if you reboot to original firmware? 23.54.44 # i guess i know what to do tomorrow if i'm bored then :) 23.55.01 # * stripwax goes for food - om nom nom 23.55.07 Quit stripwax ("http://miranda-im.org") 23.56.13 Quit n1s ("Lämnar") 23.56.27 Join n1s [0] (n=n1s@rockbox/developer/n1s) 23.56.37 # yes, does seem to work on original firmware 23.57.03 # should FS#10686 be closed? it's basically "peakmeater is slow" 23.57.20 # or i guess display updates are slow 23.58.10 # but there seem to be a couple of error messages in dmesg: http://pastebin.com/mab7130e