--- Log for 25.03.110 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 2 hours ago 00.00.07 # I seem to remember we do that on other targets as well 00.00.17 # maybe I should just shut up xD 00.00.25 # ozzo: there is a manual for the clip. and since the v2 is identical I questioned the need for a special v2 manual. 00.00.26 # Yes, I said that - the "clipv2" and "clip+" manual links point to the clipv1 manual. 00.00.55 # Hi, I'd like to ask a question about the way my RiPod is behaving... 00.01.01 # got you wrong hehe 00.01.06 # Your "RiPod" ? 00.01.10 # iPod. 00.01.25 # lol nice name 00.01.35 # Sorry, I'm using Chromeand the "Waiting" message is blocking me reading what I write 00.01.44 # So there may be some typos 00.01.48 # Anyways, 00.01.59 # I have an iPod Nano, 1st gen. 00.02.16 # It had the lates softare when I installed Rockbox. 00.02.26 # When I did, I deleted the system files. 00.02.39 # For the iPod's orginal software, I mean. 00.02.42 # You mean the "iPod_Control" folder? 00.02.46 # Yeah. 00.02.57 # Oh.... 00.02.59 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 00.03.01 # I know it comes back when I open iTumes, and I've deleted it before. 00.03.26 # But sometimes it comes back after I make sure the folder uis gone and unplug it. 00.03.37 # if you boot the original firmware it will get recreated also 00.03.50 # So what should I do? 00.03.55 # it's probably easier to hide it instead; then it won't show up in rockbox unless you set the file viewer to all files 00.04.02 # it doesn't matter, though 00.04.22 # No, I mean the original software boots INSTEAD of Rockbox 00.04.25 # If you're asking about "how can I stop this happening" don't have/use the Apple of. 00.04.36 # Thats nothing to do with the iPod_Control folder 00.04.43 # the firmware is not stored in there, that's just for settings 00.04.52 # So how do I stop it? 00.04.57 # stop what 00.05.10 # the original firmware boots if you have the hold switch turned on when you power the player on 00.05.34 # So I shouldn't use the hold switch whevever the player is off? 00.05.47 # hm? 00.05.56 # turn off hold before you apply power ;) 00.05.59 # then it will boot rockbox. 00.06.01 # note that there *might* be a bug, where the alarm might trigger by mistake *and* boot up into the apple firmware if the hold switch is on 00.06.19 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 00.06.29 Quit ozzo (Quit: CGI:IRC (Ping timeout)) 00.06.40 # I can't pwere the player on if the hold is oon, though. 00.06.40 # Well...you can't power the player on if hold is on...can you? 00.06.43 # but if you connect usb power, yes, turn the hold switch off. 00.06.50 Quit pamaury (Client Quit) 00.06.51 # webguest77: connecting usb turns the player on 00.07.02 # No, this happens without pplugging the thing into a computer. 00.07.20 # there *may* be a similar bug... 00.07.38 # As was said earlier, regarding the alarm. 00.07.45 # I don't use the alarm 00.07.51 # webguest77 - how do you turn it on, if the hold switch is on ... ?? 00.07.52 # does it turn on instantly into the original firmware? 00.07.59 # or does it have to boot up for >60 seconds first? 00.08.16 # Torne - (if you see the Apple logo, but it boots up in <10 seconds, it's 'apple resume'...) 00.08.26 # When I unplug it from the computer? 00.08.31 # Or just any old time? 00.08.43 # * stripwax is super confused 00.08.43 # wait, this happens when you unplug? like, immediately? 00.08.48 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.08.48 # No. 00.08.53 # After 00.09.03 # Wait, sorry, let me explain this. 00.09.12 # webguest77 - can you break it down step by step please 00.09.37 # When I unplug the iPod from my computer, I make sure to check and make sure the firmware files have been deleted. 00.09.48 # After unplug, it loads Rockbox just fine. 00.09.56 # that *really* doesn;t matter... 00.09.57 Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 00.10.16 # deleting the 'firmware files' I mean. 00.10.19 Quit n17ikh () 00.10.35 Quit killan (Read error: Connection reset by peer) 00.10.35 # what do you mean by "make sure the firmware files have been deleted". Do you really mean "deleting the firmware files" - or do you just think you mean that? 00.10.35 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 00.10.46 # ipod_control is **NOT** 'the firmware files' 00.10.47 Quit petur (Quit: Zzzz) 00.11.01 # However, even after Rockbox loads then, I will try to boot it again sometime, and the old iPod firmware will load. 00.11.20 # There are no files on the disk besides ".rockbox" and my music. 00.11.34 # it might be the alarm bug. 00.11.45 # I DON'T USE THE ALARM. 00.12.11 # FS#11063 00.12.19 # it doesn't matter if you use the alarm. 00.12.19 # webguest77 - right, "IT IS A BUG" .. :-) 00.12.25 # Also, note that I turn the hold switch off every time I go into Sleep mode. 00.12.27 # the hardware sets the alarm on poweroff 00.12.31 Part toffe82 00.12.34 # Oh. 00.12.42 # webguest77 - I saw something similar (hence the bug that I logged :-)) 00.12.51 # So I shouldn't use the hold switch if the power is off? 00.12.51 # the origianl firmware uses the hardware alarm for something quite different 00.13.00 # also, what do you mean, go into sleep mode? 00.13.03 # rockbox doesn't have a sleep mode. 00.13.06 # Turn it off. 00.13.19 # webguest77 - it is supposed to work - but I have also seen the same symptom. What I think happens is: 00.13.32 # 1. you run rockbox, and then shut it down normally (via long press on PLAY). 00.13.40 # Yes. 00.13.54 # webguest77: yeah that's not sleep mode, that's just "off" 00.14.00 # OK. 00.14.08 # How long does it take to start the original firmware? 00.14.09 # 2. you turn the hold switch on. 3. at some indeterminate time later, the alarm fires 'by mistake', the ipod turns on, sees the hold switch is on, and boots the apple firmware 00.14.13 # a few seconds, or a minute or so? 00.14.16 # Because the iPod firmware calls it "sleep" 00.14.25 # 4. the apple firmware gets bored (since I'm in bed), and shuts down (specifically, hibernates) later on 00.14.26 # no, the ipod firmware *does* put it to sleep 00.14.28 # *we* turn it off. 00.14.38 # Less than a minute, but several seconds longer than normal. 00.14.39 # they are different :) 00.14.41 # 5. I turn the hold switch to 'off' and turn on the ipod - it wakes up the ipod firmware 00.15.03 # So this is an acknowledged bug. 00.15.12 # Torne - you've seen the bug I mentioned? (FS#11063)? 00.15.17 # it's an unreproducable bug 00.15.18 # Is there a patch or anything, or have you not been able to fix it? 00.15.24 # OH, okay. 00.15.28 # Thanks. 00.15.30 # which we already spsecifically introduced code to prevent 00.15.38 # and thus ther eis no way it should be possible for it to happen ;) 00.15.41 # Hmmm... 00.15.45 # * stripwax goes HMM also 00.15.52 # this happened while developing a different change 00.15.54 # But I have the latest version, I think... 00.16.10 # It doesn't matter what version you have ;) 00.16.17 # This should not be possible in any version :) 00.16.22 # so, yeah, i don't know how to fix it 00.16.30 # Torne - it does though, right? the whole shutdown thing was only changed recently 00.16.42 # Okay, thanks. 00.16.51 # stripwax: no, it doesn't.. the only vesion that doesn't set the alarm correctly on shutdown was in FS# 00.16.58 # webguest77 - what ipod model do you have? 00.17.01 # it was never in svn 00.17.07 # Nano, 1st gen 00.17.15 # Torne - I mean, before that patch was even submitted to svn, everything worked fine .... 00.17.15 # Latest firmware 00.17.32 # stripwax: yes, but everything works fine now :) 00.17.34 # So there is a patch. 00.17.39 # Torne - err.. what? 00.17.45 # webguest77: no. 00.17.49 # webguest77 - ignore. the patch *is* in the latest version of rockbox 00.17.54 Quit ender` (Quit: Do not believe any statistic you didn't falsify yourself.) 00.17.57 # webguest77: a change was made to the way we shut ipods down, for a completely unrelated issue 00.18.00 # I am of the opinion that the patch doesn't quite do what it is supposed to do 00.18.09 # OK. 00.18.12 # webguest77: during development of that patch we got the behaviour you are getting 00.18.16 # we fixed that before submitting the patch 00.18.22 Quit domonoky (Read error: Connection reset by peer) 00.18.26 # and only you and I seem to still have a problem... 00.18.30 # OK, I get it. 00.18.35 # yah. a dozen or so peope tested that for 6+ months 00.18.39 # without anyone having the problem :) 00.18.47 # Well, thanks for the help... 00.18.49 # and you are only the second person to report it since it was submitted 00.18.54 # well, it's an unreproducible bug, soooo .... 00.18.55 Quit Luca_S (Quit: CGI:IRC (EOF)) 00.18.58 # :-) 00.19.00 # just lookin at the front page. under stable it has e200 (all models) nad then under unstable it has clip (all versions) should they not both be either models or versions as opposed to being different ? 00.19.27 # webguest77 - by the way, this probably isn't what you want to hear, but I am quite grateful that I am not going crazy and someone else see the bug too .... :-) 00.19.28 Quit webguest77 (Quit: CGI:IRC (EOF)) 00.19.28 # Stephen__: no, there are lots of different models that fall under e200 00.19.40 # Stephen__: e250, e280, etc 00.19.45 # Stephen__: The clip has 3 versions, the e200 has 2 versions and the R model 00.19.48 # then should clip not be models aswell 00.19.54 # The clip has clip, clip+ and clipv2 00.20.04 # Stephen__: no, because they are sold as the same model and have no distinguishing features 00.20.17 # Stephen__: the changes between v1 and v2 are internal and not visible to users 00.20.19 # ah right. just thought i'd bring it up 00.20.32 # thanks Torne & Llorean 00.20.53 Quit wodz (Quit: Leaving) 00.20.56 # unfortunately sandisk have changed the internals of some players without actually marketing it as a new model 00.21.07 # which is bad for us ;) 00.21.18 # i wonder will we see a clip +v2 ? 00.21.28 # Torne - (although I think I mentioned this before) - the problem seems to be aggravated if I use OF usb mode (rather than rockbox usb mode) and then reboot into rockbox - but that might just be a coincidence. 00.21.29 # the clip+ already has similar hardware to the v2 00.21.39 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 00.21.52 # stripwax: i just cannot see how it can happen, is the issue 00.21.55 # stripwax: Is the clock set? 00.22.01 # I wonder if FS#10830 is related 00.22.10 # Llorean - rockbox reports the current time, yes 00.22.10 # it's great to have rockbox on a player that is still sold new 00.22.11 Quit jgarvey (Quit: Leaving) 00.22.16 # stripwax: the problem is that the OF enables wakeup by alarm, always, when we call it to do the dodgy shutdown for us ;) 00.22.28 # Annoyingly, the debug screen cannot tell me if the alarm is 'set', it only lets me 'set' it or 'cancel' it. 00.22.34 # stripwax: it doesnt' actually set the alarm time, as far as we saw, just turns on the PMIC bit to do the wakeup 00.22.54 # so, the shutdown patch sets the alarm time to the Distant Future on shutdown, if the user hasn't set a real alarm 00.22.58 # Torne - well, based on which OF firmware version? I have the original (unupgraded) OF firmware 00.23.01 Quit DataGhost (Ping timeout: 240 seconds) 00.23.11 Quit kugel (Remote host closed the connection) 00.23.20 # such that even though the alarm wakeup gets enabled, it won't really happen until like 2080 or similar. i forget th date :) 00.23.34 # let me check my apple os version 00.23.46 # Torne: Does it use whatever the RTC reports as the date + some constant, or a hard coded date? 00.23.57 # Llorean: it sets it to the maximum thing the RTC will accept, i think 00.24.02 # this is existing rockbox code 00.24.04 # not new. 00.24.22 # we do that anyway because there's no other way to tell whether you woke up by alarm or not 00.24.31 # the OF bootloader in flash eats the bit in the PMIC that tells you why you woke up. 00.24.40 # so, we have to rely on checking the alartm time to know if we woke up because of an alarm 00.24.46 # if it's set to Crazy Future Time then we know we didn't ;) 00.25.03 # this code gets run every time you disable the alarm 00.25.16 # the shutdown patch just runs it on shutdown, if the alarm wasn't set by the user, as well 00.25.43 # what if you *wan't* to set an alarm for ~10 years in the future? ;-P 00.25.45 # * stripwax just realised he has no idea how to check his apple os firmware version 00.25.56 # S_a_i_n_t - haha 00.26.02 # S_a_i_n_t: i'm prety sure it's a lot more than 10 years ;) 00.26.09 # 1.1.1 (apparently) 00.26.13 # the comment in the code says whoever wrote that is assuming they will be dead 00.26.14 # :) 00.26.25 # hehehe 00.26.37 # stripwax: but yes, it's possible your OF is resetting the alarm time 00.26.39 # well, hopefully they won't be, but the battery presumably will be :-) 00.26.49 # stripwax: but i can't see why it would unless it also went into sleep 00.26.50 # Torne - ok 00.26.53 # but it's difficult to tell 00.27.11 # The whole boot/sleep/reboot/shutdown/etc mess in the flash bootloader is incomprehensible 00.27.17 # agreed 00.27.31 # i've been disasembling it a bit but it's just vast beyond any reasonable need 00.27.46 # amusingly there is an entire serial bootloader debug console in there 00.27.53 # it's just implemented using Angel ICE 00.27.59 # which is worse, rockbox that sometimes need menu+select to boot at all, or rockbox that sometimes wakes up into either rockbox or apple os (depending on hold switch) at a random time you didn't specify 00.28.03 # so you can only access it over JTAG :) 00.28.30 # stripwax: well, nobody but you and that guy is having that problem, tho 00.28.36 # I'd love not to have this horrible hack 00.28.55 # but that *also* depends on working out what the hell the bootloader is doing and why it's failing to boot in the first place. 00.29.16 # presumably there's some specific parts of iram that contain magic values 00.29.23 # yes 00.29.30 # but that's not all 00.29.34 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 00.29.36 # it does a bunch of other crazy stuff also ;) 00.29.37 # have we tried zeroing out iram at shutdown time? 00.29.55 # dunno. 00.30.15 # it seems unlikely, though. not impossible 00.30.24 # but the data the bootloader reads from there is pretty specific 00.30.39 # Torne - do you have jtag? can you see what the iram contents are after an OF 'good' shutdown? 00.30.40 # i would think it vanishingly unlikely for it to appear by accident 00.30.47 # the OF doesn't *have* a shutdown 00.30.50 # ther is no such thing 00.30.55 # yeah, just realised the same 00.31.01 Join CaptainKewl [0] (~jason@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 00.31.02 # there is only sleep, suspend to disk, or "shit my battery ran flat" 00.31.26 # so yeah, we are trying to produce behaviour that the OF just doesn't have. 00.31.32 # Hmmmmmm 00.31.34 # that's a thought. 00.31.52 # maybe the shutdown problem is caused by the OF's data *still* being in iram 00.32.03 # Torne - re 'appear by accident' - I wonder if it's the other way around - the random data *doesn't* look like what it's expecting 00.32.04 # which i guess might happen if by fluke you don't run anything that goes that high 00.32.06 # right exactly 00.32.21 # stripwax: well it must logically be able to del with powering on to find IRAM is totally blank 00.32.27 # because that's what happens if you disconnect the battery 00.32.31 # yep.... 00.32.41 # though whether it always handles it correctly is a different matter 00.32.44 # but it must at least work in theory 00.32.48 # and presumably the OF boots just fine if you disconnect (and recharge, and reconnect..) the battery 00.32.53 # yeah 00.33.24 # if you disconnect hte battery or let it run completely flat, it happily powers on on usb insert at least 00.33.29 # presumably someone has tried that though. (btw - not the first time I suggested trying to zero out the iram) 00.33.33 # lioke i said, i've been disassembling the firmware 00.33.42 # but haven't found anything useful yet and it is *spectacularly* dull 00.33.54 # and it's full of very weird stuff 00.34.02 # e.g. detection of PP CPU types that we've never seen 00.34.26 # and what looks like lots of leftover code from different ipod models :) 00.34.39 # it really is a massive pile of crap. way too complicated for the miniscule amount it does ;) 00.35.04 # i was lookign for where it writes data to the LCD, to find where the "no battery" screen comes from 00.35.08 # but can't bloody find it 00.35.19 # (it doesn't help that the BCM video chip's control system is also insane) 00.35.53 # It was probably written by a thousand monkies, at a thousand typewriters... ;-P 00.36.02 # indeed 00.36.14 # annd kludged together at the end. 00.36.24 # i wonder if someone *has* tried clearing iram ;) 00.36.33 # or at least the bit at the end 00.36.34 # * stripwax suspects not 00.36.40 # ..yeah, tell you what 00.36.42 # i will do taht :) 00.36.54 # (and revert the other patch locally) 00.36.58 # my ipod seems to do it pretty often 00.37.05 # so, it's not a bad test ;) 00.37.51 # what real harm could it possably do? 00.38.05 # it couldn't...in *theory* 00.39.11 # well i'll try it 00.39.25 # seriously, without the other fix my ipod does it about one time in three 00.39.39 # so if it can go a day or three without doing it then it probabyl works, tbh :) 00.39.53 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-ddgzmivbcuppmbre) 00.39.53 Quit Schmogel (Read error: Connection reset by peer) 00.39.58 # i'm doing it now, anyway 00.40.05 # I don't mind doing some testing...if it helps. 00.40.17 # S_a_i_n_t: did you previously have the shutdown issue often? 00.40.20 # if not then it probably doesn't help 00.40.43 # shut down issue being "sometimes couldn;t power up without hard reset"? 00.40.44 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 00.40.47 # yes 00.41.00 # maybe once, twice a week... 00.41.09 # so not super often then ;) 00.41.39 # No, but I have 4 different targets to choose from, so none get any real hard use. 00.41.49 # probably the nano1g's get the most use. 00.45.14 Join g33kb0ard3r [0] (~chatzilla@dhcp-51-27-149-24.cf-res.cfu.net) 00.45.47 Quit liar (Ping timeout: 258 seconds) 00.46.02 Quit notlistening (Ping timeout: 248 seconds) 00.47.33 Quit Farthen () 00.47.57 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 00.48.26 Nick Farthen is now known as Guest10269 (~Farthen@static.225.178.40.188.clients.your-server.de) 00.49.27 # Has anyone else noticed anything similar to 10981? I'm trying to track down myself exactly *what* is messing things up. My theory is, with the way I have my viewers.config now...plus my *vast* .icons file I shouldn't have any problems displaying any icons at all :-/ 00.49.42 Nick Guest10269 is now known as Farthen_ (~Farthen@static.225.178.40.188.clients.your-server.de) 00.49.56 Join bieber [0] (~bieber@132.170.45.2) 00.50.13 Nick Farthen_ is now known as Farthen (~Farthen@static.225.178.40.188.clients.your-server.de) 00.51.14 Join kugel [0] (~kugel@rockbox/developer/kugel) 00.51.33 Join Minataku [0] (~Ed@unaffiliated/payphoneed) 00.51.49 # Huzzah on Sansa e260v2 support. Works great. 00.56.46 Quit Farthen () 00.57.13 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 00.57.42 Nick Farthen is now known as Guest63824 (~Farthen@static.225.178.40.188.clients.your-server.de) 00.58.40 Part Guest63824 00.59.07 Part b0hoon ("GTG. Bye.") 00.59.40 # do we really only use 0xc000 bytes of iram on the ipods? 00.59.49 # app.lds defines that as IRAMSIZE 00.59.56 # Torne - which ipods? .. 01.00.01 # All of them 01.00.03 # Torne: So that IS you 01.00.06 # hrm. 01.00.06 # Well, all the PP ones 01.00.11 # boot.lds defines it as the right values dependent on PP type 01.00.12 # * Minataku pounces Torne 01.00.23 # different ones have different amounts of iram... 01.00.31 # Minataku: this is an on topic development channel, be furry elsewhere ;) 01.00.36 # lol 01.00.46 # stripwax: yes. but app.lds defines it as way less than *any* of them have 01.00.58 # Well, I saw your name in some SVN commits, and I was wondering "Hm, same one?" 01.01.04 # * Minataku == NekoEd, BTW 01.01.18 # Torne - maybe, but what difference does that make? 01.01.31 # as in, what is IRAMSIZE used for / affect ? 01.01.32 # But yeah, just heaping praise for getting the SansaAMS devices up, now I can encode videos for my e260v2 myself 01.01.40 # stripwax: it's used for the linker script.. 01.01.45 # so it's limiting the size of the iram sections.. 01.01.47 # You know, WITHOUT that horrible Sansa Media Convertor 01.01.54 # only const/idata probably right 01.02.11 # presumably we can still use the rest of iram at runtime. (And presumably we also .. do ..) 01.02.27 # No idea 01.02.32 # haven't the faintest idea how it works ;) 01.02.34 # it just seems odd 01.02.41 # amiconn - any ideas? 01.04.07 Nick g33kb0ard3r is now known as Halborr (~chatzilla@dhcp-51-27-149-24.cf-res.cfu.net) 01.04.20 # anyway i'm building it now to see what happens 01.04.32 # i'm clearing from 0xc000 to the end of what my player has ;) 01.04.48 # on the assumption that this can't destroy anything rockbox is using because of the linker script.. 01.05.17 # Should never assume things, it's dangerous. 01.05.28 # I think by dangerous you mean hilarious 01.05.35 # always assume everything, otherwise you'll never really learn anything :-) 01.05.42 # It's all in the eye of the beholder 01.05.48 # * Torne also has his custom test_disk which writes to random sector numbers. 01.05.50 # That one is fun :) 01.05.51 Quit DerPapst (Quit: Leaving.) 01.05.59 # stripwax: That's less of an assumption and more of a "what's this do" 01.06.15 # An assumption means you don't expect to break something 01.06.21 # Learning means you do 01.06.22 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 01.06.22 # :3 01.06.30 # you'll learn soon enough if you find out you do break something 01.06.42 # er, yeah, what you just said :-) 01.07.28 # it's *probably* fine to zero all of iram, because nothing will be happening other than calling the PCF function to shut down 01.07.41 # so even if that happens to blow away the stack it is unlikely to notice as nothing will be doing any returning ;) 01.07.50 # but this should suffice 01.08.01 # probably ok so long as it's literally the last thing it does 01.08.17 # I'd dump it out and take a peek at it first, myself 01.08.22 # and doesn't use any variables on local stack to do it! 01.08.37 # See if there's anything in there that might be important 01.08.49 # Minataku: i already know what is likely to be in there 01.08.51 # Torne: app.lds has only the core iram, I think, plugin.lds the rest for codecs/plugins 01.09.02 # kugel: ah 01.09.33 # because there's no proper CORE_IRAM/CODEC_IRAM #define :p 01.10.18 # yeah, i see. 01.10.26 # anyway, that means it should be fine to clear from there to the end 01.10.33 # since codecs/plugins can't be running at shutdown 01.10.45 # as long as the OF doesnt' care about any data before then, which i'm pretty sure it doesn't. 01.12.20 # Say, the manual for the SansaAMS series seems to refer to it doing things regarding saving power for hard disk operations and such, and there's some comments in the code for it too.... but do any of the AMS series HAVE a hard drive? The e2x0v2 has NAND Flash. 01.13.42 # The old "Spinning newspaper injures publisher" comes to mind for some reason when I think about a Flash ROM "spinning up" 01.14.21 # it shouldn't need ctual spinups, but reducing accesses is still power efficient 01.14.32 # flashes on these things tend to go into idle when you don't access them for a while 01.14.38 # Makes sense. 01.14.43 # what are you trying to do? 01.14.46 # so touching the flash less often still saves power, just not by as huge an amount as a disk 01.14.54 # * Minataku nods 01.15.05 # But it can be a touch confusing 01.15.17 # well if there's somewhere it's badly worded in the manual reaise a bug 01.15.57 # It's not so much that it's badly worded that it just refers to mechanical disks when there's no such device in any of the Sansae 01.17.27 # Why does rbutil still require the user to press autodetect? 01.17.28 # Torne: ^ :) 01.17.45 # Can't we do that automatically when we detect there's no configuration... 01.17.53 # kugel: fix the shutdown bug on ipod Some Other Way 01.17.56 *** Saving seen data "./dancer.seen" 01.18.05 # the battery icon one? 01.18.08 # no 01.18.23 # the one where it doesn't turn on again 01.18.40 # but the battery icon is the side effect of the current fix? 01.18.44 # yes 01.19.05 # nobody has tried my suggestion to simply kill off the lcd before I assume? 01.19.33 # that doesn't fix the shutdown bug 01.19.39 # the point is not to solve the cosmetic issue 01.19.47 # the point is to not call the OF 01.19.56 # saratoga - (for the logs) - I see about a 0.78MHz gain on 266mhz nslu2 (30.77 seconds vs 31.43 seconds , for a 223.66 second example file) = around 2% improvement (so quite small). that's with ARM_ASSEM forced for both tremor trunk and tremor+patch 01.20.01 # because the OF does weird shit like turning the alarm back on 01.20.05 # Just have it display "Buy a better media player, you fool." 01.20.17 # bang for buck, the ipod5g 60GB is pretty hot 01.20.24 # well. was. 01.20.39 # the ipodvideos are still pretty much the best large hdd target.. 01.21.14 # I liked the quote on the "GoldenQuotes" page about iPod users. 01.21.28 # kugel - please read FS#11063 .. 01.22.29 # kugel - and the conversation with webguest77 earlier :-) 01.22.38 # Minataku: if you are buying a player specifically for rockbox and you want more storage than is available on a flash target, ipodvideo64mb is basically the best choice atm 01.22.47 # so, er, generalisations not so useful ;) 01.23.11 # Torne: The e2x0v2 has MicroSD external 01.23.13 # :3 01.23.28 # Technically infinite storage is pretty nice, you know. 01.23.30 # Minataku: and when there's a uSD card which will hold 55.75GB let me know 01.23.35 # :) 01.23.39 # right 01.23.41 # is there any known limit for sizes of SD external for sansas e200? 01.23.47 # 32GB 01.23.50 # They're up to 32GB so far 01.23.54 # I mean, in practice :-) 01.24.17 # SDXC is just another software extension to the protocol, IINM 01.24.43 # Similar to how SDHC was to SD 01.25.12 Quit stripwax (Quit: http://miranda-im.org) 01.25.16 # not a plain software extensions. the card readers and the cards itself have changed too 01.25.35 # Minataku: a 32GB uSD card already costs nearly as much as an 80GB ipodvideo 01.25.43 # so that's not such a great comparison either ;) 01.26.18 Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 01.27.06 # Torne: Yeah, but when you decide that swapping hard drives in and out of your iPod video is a good plan, get back to me 01.28.41 Quit planetbeing_ (Ping timeout: 240 seconds) 01.31.26 Quit Gartral (Ping timeout: 246 seconds) 01.31.27 Quit crwl (Ping timeout: 246 seconds) 01.31.27 Quit tipi^ (Ping timeout: 246 seconds) 01.31.27 Quit Horscht (Ping timeout: 246 seconds) 01.31.28 Quit lostlogic (Ping timeout: 246 seconds) 01.31.29 Quit CaptainKewl (Ping timeout: 246 seconds) 01.31.29 Quit jae (Ping timeout: 246 seconds) 01.31.29 Quit flyback (Ping timeout: 246 seconds) 01.31.29 Quit jfc^2 (Ping timeout: 246 seconds) 01.31.29 Quit FlynDice (Ping timeout: 246 seconds) 01.31.30 Quit Tuplis (Ping timeout: 246 seconds) 01.31.30 Quit MagusG (Ping timeout: 246 seconds) 01.31.31 Quit Bagder (Ping timeout: 246 seconds) 01.31.31 Quit soap (Ping timeout: 246 seconds) 01.31.31 Quit ved (Ping timeout: 246 seconds) 01.31.35 Quit panni_ (Ping timeout: 246 seconds) 01.31.36 # hrm... quick-swap HD bay mod :-) 01.31.37 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 01.31.38 Quit mrigesh (Ping timeout: 246 seconds) 01.31.44 Quit mt (*.net *.split) 01.31.45 Quit TheSeven (*.net *.split) 01.31.45 Quit yawny_ (*.net *.split) 01.31.46 Quit scorche|sh (*.net *.split) 01.31.46 Quit RoronoaZoro (*.net *.split) 01.31.47 Quit sevard_ (*.net *.split) 01.31.47 Quit Adubb (*.net *.split) 01.31.47 Quit Zarggg (*.net *.split) 01.31.47 Quit GHF (*.net *.split) 01.31.48 Quit Torne (*.net *.split) 01.31.48 Quit Zambezi (*.net *.split) 01.31.48 Quit YPSY (*.net *.split) 01.31.48 Quit dmb (*.net *.split) 01.31.48 Quit Minataku (*.net *.split) 01.31.49 Quit JdGordon (*.net *.split) 01.31.49 Quit evilnick_B (*.net *.split) 01.31.49 Quit m3dlg (*.net *.split) 01.31.50 Quit Guest3190 (*.net *.split) 01.31.51 Quit dionoea_ (*.net *.split) 01.31.51 Quit stavrob_ (*.net *.split) 01.31.51 Quit nimak (*.net *.split) 01.31.52 Quit pjm0616 (*.net *.split) 01.31.52 Quit gevaerts (*.net *.split) 01.31.52 Quit shai (*.net *.split) 01.31.53 Quit Topy (*.net *.split) 01.31.53 Quit tmzt (*.net *.split) 01.31.53 Quit tchan (*.net *.split) 01.31.54 Quit arbingordon (*.net *.split) 01.31.54 Quit anewuser (*.net *.split) 01.31.55 Quit krazykit (*.net *.split) 01.31.56 Quit tmzt_ (*.net *.split) 01.31.57 Quit MuscleNerd (*.net *.split) 01.31.57 Quit n17ikh (*.net *.split) 01.31.57 Quit adnyxo (*.net *.split) 01.31.57 Quit S_a_i_n_t (*.net *.split) 01.31.58 Quit jordan` (*.net *.split) 01.31.59 Quit _flow_ (*.net *.split) 01.31.59 Quit niekie (*.net *.split) 01.32.00 Quit CIA-5 (*.net *.split) 01.32.00 Quit Kohlrabi (*.net *.split) 01.32.01 Quit Tomis (*.net *.split) 01.32.01 Quit bzed (*.net *.split) 01.32.01 Quit mc2739 (*.net *.split) 01.32.02 Quit aholic (*.net *.split) 01.32.02 Quit advcomp2019_ (*.net *.split) 01.32.02 Quit parafin (*.net *.split) 01.32.03 Quit blithe (*.net *.split) 01.32.03 Quit planetbeing__ (*.net *.split) 01.32.03 Quit kugel (*.net *.split) 01.32.03 Quit BlakeJohnson86 (*.net *.split) 01.32.03 Quit leavittx (*.net *.split) 01.32.04 Quit Kitar|st (*.net *.split) 01.32.04 Quit avacore (*.net *.split) 01.32.04 Quit ps-auxw (*.net *.split) 01.32.04 Quit alexbobp (*.net *.split) 01.32.04 Quit yawny (*.net *.split) 01.32.05 Quit aevin (*.net *.split) 01.32.06 Quit simabeis (*.net *.split) 01.32.06 Quit ranma (*.net *.split) 01.32.06 Quit ThomasAH (*.net *.split) 01.32.06 Quit jobec (*.net *.split) 01.32.06 Quit fxb (*.net *.split) 01.32.07 Quit antil33t (*.net *.split) 01.32.07 Quit Zagor (*.net *.split) 01.32.08 Quit merbzt1 (*.net *.split) 01.32.08 Quit kadoban (*.net *.split) 01.32.08 Quit fidencio[AWAY] (*.net *.split) 01.32.09 Quit Galois (*.net *.split) 01.32.09 Quit Utchybann (*.net *.split) 01.32.09 Quit Hadaka (*.net *.split) 01.32.10 Quit jvd (*.net *.split) 01.32.10 Quit Stephen__ (*.net *.split) 01.32.10 Quit scorche (*.net *.split) 01.32.11 Quit rvvs89 (*.net *.split) 01.32.11 Quit mikroflops (*.net *.split) 01.32.11 Quit bluebroth3r (*.net *.split) 01.32.11 Quit jd (*.net *.split) 01.32.11 Quit Strife89 (*.net *.split) 01.32.11 Quit FOAD (*.net *.split) 01.32.12 Quit ObsidianX (*.net *.split) 01.32.12 Quit rasher (*.net *.split) 01.32.12 Quit linuxguy3 (*.net *.split) 01.32.12 Quit Llorean (*.net *.split) 01.32.12 Quit Connor (*.net *.split) 01.32.12 Quit beta_ (*.net *.split) 01.32.13 Quit bieber (*.net *.split) 01.32.13 Quit pixelma (*.net *.split) 01.32.13 Quit Xerion (*.net *.split) 01.32.13 Quit topik (*.net *.split) 01.32.14 Quit Unhelpful (*.net *.split) 01.32.14 Quit linuxstb (*.net *.split) 01.32.14 Quit MagusG (*.net *.split) 01.32.15 Quit Halborr (*.net *.split) 01.32.15 Quit killan_ (*.net *.split) 01.32.15 Quit RadicalR (*.net *.split) 01.32.15 Quit amiconn (*.net *.split) 01.32.16 Quit elinenbe (*.net *.split) 01.32.16 Quit xavieran (*.net *.split) 01.32.16 Quit evilnick (*.net *.split) 01.32.16 Quit SirFunk (*.net *.split) 01.32.17 Quit togetic (*.net *.split) 01.32.17 Quit Curtman (*.net *.split) 01.32.17 Quit lyngaas (*.net *.split) 01.32.17 Quit maraz_ (*.net *.split) 01.32.18 Quit preglow (*.net *.split) 01.32.18 Quit yosafbridge (*.net *.split) 01.32.18 Quit ChanServ (*.net *.split) 01.32.59 Join flyback [0] (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 01.32.59 Join mrigesh [0] (~mrigesh@iws3.iiita.ac.in) 01.32.59 Join fxb [0] (~felixbrun@h1252615.stratoserver.net) 01.32.59 Join blithe [0] (~blithe@72.14.176.144) 01.32.59 Join MuscleNerd [0] (eric@adsl-75-27-189-151.dsl.irvnca.sbcglobal.net) 01.32.59 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 01.32.59 Join jobec [0] (paulus@viherharakka.cs.tut.fi) 01.32.59 Join Kohlrabi [0] (~Kohlrabi@frustum.nosebud.de) 01.32.59 Join CIA-5 [0] (cia@208.69.182.149) 01.32.59 Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) 01.32.59 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 01.32.59 Join pjm0616 [0] (~user@61.250.113.98) 01.32.59 Join niekie [0] (~niek@CAcert/Assurer/niekie) 01.32.59 Join ranma [0] (ranma@mx.tdiedrich.de) 01.32.59 Join simabeis [0] (~simabeis@lobmenschen.de) 01.32.59 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 01.32.59 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 01.32.59 Join Hadaka [0] (~naked@naked.iki.fi) 01.32.59 Join jvd [0] (~syscrash@poipu/developer/syscrash) 01.32.59 Join nimak [0] (~nima@adsl-75-45-227-30.dsl.sfldmi.sbcglobal.net) 01.32.59 Join aevin [0] (eivindsy@unaffiliated/aevin) 01.32.59 Join stavrob_ [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 01.32.59 Join dionoea_ [0] (~dionoea@yop.chewa.net) 01.32.59 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 01.32.59 Join parafin [0] (parafin@paraf.in) 01.32.59 Join beta_ [0] (~beta@d24-36-66-52.home1.cgocable.net) 01.32.59 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 01.32.59 Join Connor [0] (Connor@ip72-204-35-60.fv.ks.cox.net) 01.32.59 Join fidencio[AWAY] [0] (~fidencio@li113-135.members.linode.com) 01.32.59 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 01.32.59 Join aholic [0] (aholic@pool-74-103-220-127.prvdri.fios.verizon.net) 01.32.59 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 01.32.59 Join krazykit [0] (~kkit@adsl-76-240-216-183.dsl.ipltin.sbcglobal.net) 01.32.59 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 01.32.59 Join merbzt1 [0] (~benlar@193.13.246.198) 01.32.59 Join linuxguy3 [0] (~timj@adsl-75-57-164-223.dsl.emhril.sbcglobal.net) 01.32.59 Join jordan` [0] (~jordan@78.235.252.137) 01.32.59 Join yawny [0] (user36@pr0.us) 01.32.59 Join tmzt [0] (~tmzt@adsl-99-164-48-101.dsl.akrnoh.sbcglobal.net) 01.32.59 Join topik [0] (awesome@wtf.grmpf.org) 01.32.59 Join Topy [0] (~topy@my.fastsh.it) 01.32.59 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 01.32.59 Join alexbobp [0] (~alex@66.112.249.238) 01.32.59 Join rasher [0] (~rasher@rockbox/developer/rasher) 01.32.59 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 01.32.59 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 01.32.59 Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) 01.32.59 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 01.32.59 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 01.32.59 Join ObsidianX [0] (~ObsidianX@99-27-207-18.lightspeed.irvnca.sbcglobal.net) 01.32.59 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 01.32.59 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 01.32.59 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 01.32.59 Join bzed [0] (~bzed@devel.recluse.de) 01.32.59 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 01.32.59 Join rvvs89 [0] (~rvvs89@pdpc/supporter/base/rvvs89) 01.32.59 Join _flow_ [0] (flow@star.freakempire.de) 01.32.59 Join FOAD [0] (~dok@dinah.blub.net) 01.32.59 Join Tomis [0] (~Tomis@70.134.88.172) 01.32.59 Join Kitar|st [0] (Kitr88@BSN-142-105-33.dial-up.dsl.siol.net) 01.32.59 Join scorche [0] (~scorche@rockbox/administrator/scorche) 01.32.59 Join Guest3190 [0] (jljhook@irkki.fi) 01.32.59 Join Stephen__ [0] (~S@86.45.50.221) 01.32.59 Join 13WAALBUM [0] (~leavittx@89.221.199.187) 01.32.59 Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) 01.32.59 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 01.32.59 Join pixelma [0] (quassel@rockbox/staff/pixelma) 01.32.59 Join m3dlg [0] (~m3dlg@212.183.140.102) 01.32.59 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.4) 01.32.59 Join anewuser [0] (anewuser@unaffiliated/anewuser) 01.32.59 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) 01.32.59 Join jd [0] (~jd@Wikipedia/HellDragon) 01.32.59 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 01.32.59 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 01.32.59 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-ddgzmivbcuppmbre) 01.32.59 Join bieber [0] (~bieber@132.170.45.2) 01.32.59 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.32.59 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 01.32.59 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com) 01.32.59 Join panni__ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 01.32.59 Join logiclost [0] (~lostlogic@erudite.lostlogicx.com) 01.32.59 Join Gartral [0] (~Gareth@99-9-202-154.lightspeed.bcvloh.sbcglobal.net) 01.32.59 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 01.32.59 Join tipi^ [0] (pihlstro@lehtori.cc.tut.fi) 01.32.59 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) 01.32.59 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 01.32.59 Join ved [0] (ved@ddsbox.co.cc) 01.32.59 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 01.32.59 Join CaptainKwel [0] (~jason@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.32.59 Join komputes [0] (~komputes@ubuntu/member/komputes) 01.32.59 Join leavittx [0] (~leavittx@89.221.199.187) 01.32.59 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 01.32.59 Join Minataku [0] (~Ed@unaffiliated/payphoneed) 01.32.59 Join Halborr [0] (~chatzilla@dhcp-51-27-149-24.cf-res.cfu.net) 01.32.59 Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 01.32.59 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 01.32.59 Join mt [0] (~mtee@rockbox/developer/mt) 01.32.59 Join RoronoaZoro [0] (~vijayss@202.3.77.149) 01.32.59 Join amiconn [0] (quassel@rockbox/developer/amiconn) 01.32.59 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 01.32.59 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 01.32.59 Join xavieran [0] (~xavieran@ppp118-209-228-213.lns20.mel6.internode.on.net) 01.32.59 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 01.32.59 Join SirFunk [0] (~Sir@97-92-38-108.dhcp.aldl.mi.charter.com) 01.32.59 Join sevard_ [0] (sev@216.164.6.24) 01.32.59 Join yawny_ [0] (user36@pr0.us) 01.32.59 Join Adubb [0] (~aldubuc@67.201.160.144) 01.32.59 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 01.32.59 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 01.32.59 Join GHF [0] (~meow@unaffiliated/ghf) 01.32.59 Join togetic [0] (~togetic@unaffiliated/ibuffy) 01.32.59 Join Torne [0] (torne@rockbox/developer/Torne) 01.32.59 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 01.32.59 Join dmb [0] (~dmb@unaffiliated/dmb) 01.32.59 Join YPSY [0] (~ypsy@geekpadawan.de) 01.32.59 Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) 01.32.59 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 01.32.59 Join maraz_ [0] (maraz@kapsi.fi) 01.32.59 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 01.32.59 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 01.32.59 Join ChanServ [0] (ChanServ@services.) 01.32.59 Mode "#rockbox +o ChanServ " by verne.freenode.net 01.33.26 Join soap [0] (~soap@rockbox/staff/soap) 01.33.28 Join jae [0] (~jae@jaerhard.com) 01.33.36 Join Bagder [0] (~daniel@rockbox/developer/bagder) 01.34.21 # ok so in this part I have to implement some thing like OpenGl 01.34.31 # RoronoaZoro: no. 01.34.42 # RoronoaZoro: Some of our players have hardware support for resizing video 01.34.50 # it's nothing to do with opengl 01.35.42 # Torne: Well, what's the interface to the GPU to do it? 01.35.58 # It is just a straight send and the GPU handles everything on it's own? 01.36.01 # Minataku: arbitrary 01.36.03 # and yes 01.36.24 # The i.MX31 I know actually has a 3D accelerator 01.36.30 # please don't answer questions if you don't know the answers, especially to potential GSoC students :) 01.36.33 # Along with that 64bit ARM11 01.36.50 # Torne: I said "standard GPUs", not embedded 01.37.03 # Yes, so your answer is irrelevant and confusing 01.37.35 # (and there are no 64bit ARM processors) 01.38.00 # Hm. Then I was misinformed. 01.38.23 # and we can't use the MBX core on the i.MX31 because there are no public docs forit 01.38.25 # I maent to ask what does hardware support for resizing video mean 01.39.26 # what is the video resolution of the output generated by the software 01.39.45 # RoronoaZoro:i'm not sure what you mean 01.39.56 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 01.40.08 # the video decoder outputs whatever resolution the video is. 01.40.23 # i mean is the info about hardware support required for the code 01.40.26 # to display that on a screen that's bigger/smaller you need to resize the image; some players would be able to do this in hardware, but we don't support this yet 01.40.52 # i mean is the info about hardware support required for the coding in the project 01.41.21 # how it does it, etc 01.41.22 # Yes, to implement it you would need to know how it works on the hardware.. 01.41.28 # how else could you do it? 01.41.41 # *magic* ;) 01.42.10 # lol 01.42.22 # Keep guessing until it works 01.43.05 # i mean it could be considered as a unit which accepts 'any' resolution of video and i decode the file in the original size or the optimal resolution for decoding 01.43.29 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 01.43.51 # but someone has to implement the code to drive the hardware 01.44.21 # if we'd already implemented that code it wouldn't be on the list for a project 01.45.21 # ok so the code to drive the is also part of the project. So where do i get info about it 01.45.29 # Torne: you think clearing iram solves it? 01.45.40 # before deciding on wether i can do it 01.46.19 # kugel: it seems possible, based on the limited disassembly i've done of the bootloader. and i can't actaulyl find any evidence that someone has tried it ;) 01.46.25 # it's easy enoguh to try, so i'm trying it. 01.48.35 # RoronoaZoro: I suspect we are assuming the student would investigate that 01.48.58 # RoronoaZoro: some players have public documentation for their hardware, some don't 01.49.06 # ok 01.50.08 # kugel: my ipod boots extremely unreliably without the workaround, so i'll test it like this for a while and see. 01.50.39 # how it is working so far? 01.50.48 # s/working/going/ 01.50.52 # S_a_i_n_t: perfectly, but i've only powercycled it half a dozen times, not actualyl used it 01.51.11 # seems promising... 01.51.18 # however if the theory is correct then powercycling it (rather than using it) is *more* likely to make it fail 01.51.32 # since the more codecs/plugins you load the higher the chance that any data that was in iram has been scrambled anyway ;) 01.54.06 # sounds good 01.54.18 # but, yeah. i'll use it like this for a while 01.54.23 # maybe the troll from the forums also shuts up if that fix works 01.54.26 # it's quite possible that nobody bothered to try this ;0 01.56.00 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 01.56.30 # I read about the VP3/Theora Video documentation on http://www.theora.org/doc/ and i am planning do it. I would like to know where to go about MP4 container i could not get much info on it 02.02.32 # Theora is stored in MP4? I would have thought it would be in Ogg. 02.03.00 Join katyl [0] (~katyl@adsl-074-170-246-249.sip.gnv.bellsouth.net) 02.03.05 # no, i think you go it wrong ... i meant 02.03.34 # I read about VP3/Theora and can go about implementing it 02.04.30 Join zOxta [0] (~52c9dbea@giant.haxx.se) 02.04.52 # but i also thought about Adding support for MP4 using the parser but could not understand much from it 02.05.13 # I have a sansa clip+ that I just installed rockbox on using the manual install process. I can't seem to get it to initialize the database. It happens on the archived and the current builds (I didn't find a release for my model). Anyone know what might be causing the problem? 02.05.43 # *i mean i need to know more about the parser 02.07.36 Quit zOxta (Client Quit) 02.08.00 # http://www.hydrogenaudio.org/forums/index.php?showtopic=68576 (the first hit on google for "mp4 specification") 02.08.11 # Does anyone have any comments about the WPS parsing code I posted last night (if anyone caught it in the logs), or about the architecture of the library in general? 02.08.55 # repost it? 02.09.05 # I'm probably one of the people you want to talk to for wps stuff 02.09.39 # Code is on a public Git repo at git@github.com:bieber/libwps.git 02.09.58 # bieber: Only why did you re-implement it, rather than using Rockbox's existing parser? (assuming you did). 02.10.11 # So far it only parses comments, plaintext, newlines, and ViewPort declarations (I'm just working my way down the CustomWPS spec and implementing things as I go along) 02.11.47 # yeah, reimplementing it means if needs to be kept in sync, which becomes a pain very quickly 02.12.19 # linuxstb:I talked with some folks on the channel about this the other day, and the consensus was that it's best not to try and use the existing parser in a theme editor (the last attempt at this project did so, and it didn't turn out well). I haven't looked into it in depth, but the parser in Rockbox's tree is all C code that's really closely tied to the internal workings of Rockbox, while I want more flexible code (that won't need to be conditionally comp 02.12.19 # iled for different platforms) that can output a parse tree structure that the viewer/editor can use more effectively 02.12.57 Join zOxta [0] (~email@82.201.219.234) 02.13.51 # ok so i think i may be able to do it now 02.13.55 # * kugel still thinks re-using the existing C code is a good idea 02.14.09 # it's just the creator disappeared too quickly 02.14.18 # the creator of the old wps editor 02.14.51 # Does the WPS format change that frequently? 02.15.02 # it can 02.15.19 # we usually try to keep things backward compatible but once in a while we break it 02.15.25 # not very often though 02.15.36 Quit kugel (Remote host closed the connection) 02.15.45 # if the existing parser is too tied into the code then maybe we should pull it out to a lib and be very strict with what it has access to? 02.16.50 Quit planetbeing (Quit: planetbeing) 02.16.52 Quit Stephen__ (Quit: Leaving) 02.17.11 # As it stands, to use the existing code I think I'd have to branch it and do a lot of refactoring to deal with the fact that it's relying heavily on conditional compilation for different platforms, and that work would still need to be duplicated any time the format changed 02.18.10 # we might be able to setup a working config which has all the tags enabled 02.18.31 # but I think forcing the target type like the current half-done editor does is a good thing 02.18.33 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 02.18.46 # bieber: How do you intend to deal with target-specificness ? 02.18.54 # imo, when/if said changes occurred, it would be significantly simpler to make the appropriate changes to a recursive descent parser built from the ground-up to parse independent of the target platform than duplicating that refactoring 02.19.25 # not when tags are pretty freeform.... 02.19.33 # if they were all just %xx then sure 02.20.09 # linuxstb: My goal is for the parser to generate a platform-agnostic parse tree, and then the editor can render the parse tree according to device settings supplied by the user (which will of course be included for standard targets) 02.21.12 # how is that different to what the current code does? 02.22.25 # and how should (for example) the viewport tag work? the definition of the tag is different based on the lcd depth of the target 02.22.43 # on mono targets the last 2 params don't exist 02.22.49 # I can't speak authoritatively about the current code, but I know that there were certainly a lot of #ifdef's relating to device specifics, and a lot of includes and function calls relating to Rockbox internals 02.23.23 # My code can distinguish between mono, greyscale, and color ViewPort tags, and sets a flag in the ViewPort object accordingly 02.23.49 # The only time it can't determine it definitively is if both fg and bg color/shade are left default, and then it sets it to an EITHER value 02.24.15 # And looking at the spec, I don't think there are any other tags with nearly that level of ambiguity 02.24.30 # I cant think of any either 02.25.43 Quit S_a_i_n_t () 02.26.33 # The other thing I forgot to mention is that the current parsing code is, of course, in C and designed to run on an embedded device. Since I'm writing a GUI application, being able to use some of C++'s features and (most importantly) generate an object-oriented parse tree is going to be a huge advantage when it comes to actually writing the editor 02.27.27 # but it is almost guarenteed to break or become outdated when tags are changed/added 02.28.11 # we have enough trouble with checkwps which is built with the same code... 02.28.43 # It seems like an editor should use as much of the original parsing and simulator rendering as possible (as well as being part of the main source) so that ideally when many new tags are added they'll either "just work" or require almost no added code for the editor to support them. 02.29.01 # Otherwise it's just going to join the ranks of things (like the manual) that get neglected when new features go in. 02.29.23 Join retroj [0] (~retroj@pdpc/supporter/active/retroj) 02.29.23 # Right, but it's also difficult to imagine a solution that could use the existing code without forking and refactoring, unless it had to be compiled for specific targets, which would be a pretty serious usability limitation 02.29.32 # hi.. newbie question. i have an iPod 5, and I am in the picture viewing screen. how do I get out of it? 02.30.20 # hmm, I guess a full rewrite wouldnt be so stupid though, seen as the editor will need to know about the inner workings of each tag anyway... 02.30.23 # Since WPSes more or less need to be created for specific targets anyway, is target-specific editors too big of a limitation if that's necessary? 02.30.48 # There aren't going to be many situations where there's a job that needs a target-agnostic editor 02.30.55 # bieber: as long as the tag definitions are coming from a txt file of some sort it shuold be easy enough to keep in sync 02.31.18 # Well, if we want it to be useful for a non-technical user, platform-specificness would be a pretty big issue 02.31.22 # are you doing it in Qt so it can be built into rbutil? 02.31.24 # retroj: I don't know, but the manual should say. 02.31.53 # Especially if said user wants to build a theme for more than one platform (and yes, QT was the consensus when I discussed this previously) 02.31.58 # bieber: Why? In the platform agnostic editor, they'd still need to know what their platform supports 02.32.09 # So they'd still need to make the same decision, it's just whether it's a check box or a download choice 02.32.18 # any hint on which section of the manual? i don't see anything that jumps out as "key bindings in the picture viewing screen" 02.32.21 # the parser doesnt need to be inherintly target specific thoguh 02.32.32 # Right, but that's a pretty big difference if you want to use the application for more than one platform 02.32.45 # And either the user needs to build the theme separately for each platform, or the editor will result in a theme that's multiplatform anyway (like 320x240 themes that work on several targets) 02.33.01 # bieber: if this was done as part of rbutil, AND the tag definitions are parsed from a text file in svn (and can be checked for updates in the util) then I'm for it 02.33.12 # No one wants to download two separate but almost identical applications to accomplish the same task 02.33.32 # People do it all the time anyway with the sims. 02.33.37 # bieber: if this was done as part of rbutil, AND the tag definitions are parsed from a text file in svn (and can be checked for updates in the util) then I'm for it 02.33.39 # ffs 02.33.42 Quit m3dlg (Ping timeout: 258 seconds) 02.33.49 # how hard would it be to go from a xml file to C++ objects? 02.33.49 # Tags in a config file is definitely a good idea, and now I'm feeling a little bit stupid for hard-coding the tag names 02.34.33 # *most* tags are simple %xx and on all targets 02.34.40 # Of course you can only allow so much flexibility, but at least the names should be changable from a config file 02.35.19 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.35.25 # git clone git@github.com:bieber/libwps.git -> permission denied? 02.35.36 # Dangit, must not be a public link 02.35.44 # bieber: you haven't thought of just finishing the existing wps editor did you? 02.35.55 # http://github.com/bieber/libwps 02.36.11 # We discussed it before, consensus was that it's not worth doing (the current code doesn't even compile) 02.36.38 # bieber: When was this previous discussion? 02.36.46 # * kugel would like to see it as well 02.36.54 # I want to say Sunday, but I'm not really sure, looking in the archives for it 02.37.40 # bieber: it's probably not worth it if you want to reimplement the whole parser and displayer anyway; but if you want to incorporate the code that actualy runs on the targets it does make sense (IMO) 02.37.41 Quit Halborr (Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.3/20100223143236]) 02.38.08 # I'm starting to like this seperate approach 02.38.13 # * JdGordon hates C++ :/ 02.39.05 # I would maybe like it if it wasn't c++, i.e. if it would have a chance to improve the target code as well 02.39.36 # c++ sux, after I started a big project I only learn what c++ cant do >_> 02.39.50 # typedef on templates 02.39.56 # static constructors 02.39.58 # whats not 02.40.17 # not to mention that asembelrs (like NASM for instance) have much better preprocessor than stupid C/C++ 02.40.47 # offtopic 02.40.57 # I'm afraid Llorean has a good point with "it's just going to join the ranks of things (like the manual) that get neglected when new features go in" 02.41.19 # depends how it learns about tags 02.41.26 # http://www.rockbox.org/irc/log-20100320 02.41.29 # That's the day 02.41.55 # I can definitely see how keeping it updated would be an issue, but I don't think that there's really any reasonable way to _avoid_ that issue 02.42.01 # what's the reason to do it in c++ if I may ask? 02.42.25 # QT and C++ were the suggested platform, and C++ is the OO language I'm most comfortable with 02.42.40 Join m3dlg [0] (~m3dlg@212.183.140.33) 02.43.04 # if all tags come from a text file in svn and they are something like %V|int[0:MAX|-]|int[0:MAX|-]|int[0:MAX|-]|int[0:MAX|-]|int[0:1]|colour|colour| 02.43.15 # it could work 02.43.36 # * kugel is still impressed by http://yosefk.com/c++fqa/ and therefore thinks c++ isn't really appropriate for this job 02.44.51 # JdGordon: that only works for syntax checking. the theme editor sure wants to display&draw, so I don't think a simple text file does the job 02.45.40 # ah right, /me forgot half the requirements for the editor :p 02.45.42 # JdGordon: I could allow specification of tags in something EBNF-esque and basically write a parser generator instead of a parser, but it doesn't seem really cost-effective 02.46.26 # without that it means at best some lag between new tags getting added in svn and the editor 02.46.30 # A recursive descent parser really isn't a complicated piece of software, and the difficulty of modifying the parser directly vs. modifying a potentially complex grammar specification file shouldn't be that disparate 02.46.38 # isnt wps regullar? 02.46.43 # nope 02.46.54 # JdGordon: or not at all 02.47.16 # You've got conditionals in there, so definitely not regular 02.47.21 # k 02.47.35 # the wps editor only had the problem that it lacked maintainers, not that it didn't work (it mostly did and didn't look too bad) 02.48.35 # parser is only part of the problem, as bison/yacc shows, it is no problem to do it in pure C 02.49.10 # Right, the parser is pretty much purely procedural code 02.49.24 # It's the parse tree structure that's using C++'s OO features 02.49.31 # but I would also want to do semantic check in OO code 02.50.03 # you dont need C++ for OO 02.50.27 # surely I can do OO in asm, but its more convenient in cpp 02.50.43 # Hehe 02.51.14 Part retroj ("Channel buffer killed") 02.51.15 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 02.51.37 # Since the end target is a QT application, C++ is certainly most convenient. There's Java and C#, but Java GUIs are atrocious, and C# means using Mono and its own iffy gui rendering on non-Windows platforms 02.51.43 # still, I dont think most of problems for wps checking/editing lies inparsing/language processing, but more on uniform approach to different targets 02.51.48 # And of course either one would leave systems without JRE or Mono out in the cold 02.52.35 # From the WPS standpoint, how much difference does the platform make? From what I've seen in the spec, pretty much only screen size and color depth should matter, no? 02.52.54 # There are some feature differences (presence of an RTC) 02.53.04 # As well, one player is text-only, not bitmap 02.53.30 # Will RTC tags still render (just as empty) on a non-RTC platform? 02.53.32 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.4) 02.53.38 # And some players are visible without the backlight on, others aren't. Backlight color can also matter (making a difference on whether you're willing to use shades of gray, as 2bpp can look quite different on one player than another) 02.54.19 Quit kugel (Ping timeout: 276 seconds) 02.54.21 # And of course, sometimes 1bpp isn't exactly "black and white" (see the Clip for example) 02.54.56 # These are all things that can be pretty easily dealt with in configurations, though 02.55.13 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.55.14 # You were asking how much difference platform made though. 02.55.38 # My point was that there's a lot more to how a WPS appears than "screen size and color depth" 02.55.49 # This is true, definitely 02.55.51 # As well, in the case of touchscreen targets WPSes are interactive. 02.56.18 # * kugel would probably use some scripting language if OO was a requirement 02.56.23 # but actually I would use a higher lanaguage for the UI stuff and call the existing C code from there :) 02.58.51 Quit Strife89 (Quit: Bed.) 02.59.25 # I'm sure we could fix the skin engine to be more accessible for outside tools (checkwps as well), or make it compile as a (standalone) lib 03.02.43 # * S_a_i_n_t inplements a vastly complicated "fancy scrolling playlistviewer" using *way* too many lines of code & a *heap* of viewports ;) 03.02.53 # *needs improvement however... 03.03.47 Quit xiainx (*.net *.split) 03.03.47 Quit m3dlg (*.net *.split) 03.03.47 Quit Horschti (*.net *.split) 03.03.47 Quit CaptainKwel (*.net *.split) 03.03.47 Quit komputes (*.net *.split) 03.03.49 Quit leavittx (*.net *.split) 03.03.49 Quit mt (*.net *.split) 03.03.49 Quit TheSeven (*.net *.split) 03.03.50 Quit yawny_ (*.net *.split) 03.03.50 Quit scorche|sh (*.net *.split) 03.03.50 Quit JdGordon (*.net *.split) 03.03.50 Quit evilnick_B (*.net *.split) 03.03.51 Quit panni__ (*.net *.split) 03.03.51 Quit Guest3190 (*.net *.split) 03.03.52 Quit dionoea_ (*.net *.split) 03.03.52 Quit stavrob_ (*.net *.split) 03.03.53 Quit nimak (*.net *.split) 03.03.53 Quit pjm0616 (*.net *.split) 03.03.53 Quit gevaerts (*.net *.split) 03.03.54 Quit shai (*.net *.split) 03.03.54 Quit Topy (*.net *.split) 03.03.54 Quit tmzt (*.net *.split) 03.03.55 Quit tchan (*.net *.split) 03.03.56 Quit flyback (*.net *.split) 03.03.56 Quit tipi^ (*.net *.split) 03.03.57 Quit Gartral (*.net *.split) 03.03.57 Quit arbingordon (*.net *.split) 03.03.57 Quit anewuser (*.net *.split) 03.03.58 Quit krazykit (*.net *.split) 03.03.59 Quit tmzt_ (*.net *.split) 03.03.59 Quit MuscleNerd (*.net *.split) 03.03.59 Quit kugel (*.net *.split) 03.04.00 Quit jfc^3 (*.net *.split) 03.04.00 Quit n17ikh (*.net *.split) 03.04.00 Quit adnyxo (*.net *.split) 03.04.01 Quit jordan` (*.net *.split) 03.04.02 Quit _flow_ (*.net *.split) 03.04.02 Quit niekie (*.net *.split) 03.04.03 Quit CIA-5 (*.net *.split) 03.04.03 Quit Kohlrabi (*.net *.split) 03.04.03 Quit jae (*.net *.split) 03.04.03 Quit soap (*.net *.split) 03.04.03 Quit FlynDice (*.net *.split) 03.04.04 Quit Tomis (*.net *.split) 03.04.04 Quit bzed (*.net *.split) 03.04.04 Quit mc2739 (*.net *.split) 03.04.05 Quit aholic (*.net *.split) 03.04.05 Quit advcomp2019_ (*.net *.split) 03.04.05 Quit parafin (*.net *.split) 03.04.06 Quit blithe (*.net *.split) 03.04.06 Quit Bagder (*.net *.split) 03.04.06 Quit logiclost (*.net *.split) 03.04.07 Quit BlakeJohnson86 (*.net *.split) 03.04.07 Quit 13WAALBUM (*.net *.split) 03.04.07 Quit Kitar|st (*.net *.split) 03.04.07 Quit avacore (*.net *.split) 03.04.07 Quit ps-auxw (*.net *.split) 03.04.07 Quit alexbobp (*.net *.split) 03.04.08 Quit yawny (*.net *.split) 03.04.08 Quit aevin (*.net *.split) 03.04.09 Quit simabeis (*.net *.split) 03.04.09 Quit ranma (*.net *.split) 03.04.09 Quit ThomasAH (*.net *.split) 03.04.09 Quit jobec (*.net *.split) 03.04.10 Quit fxb__ (*.net *.split) 03.04.10 Quit linuxstb (*.net *.split) 03.04.10 Quit antil33t (*.net *.split) 03.04.11 Quit Zagor (*.net *.split) 03.04.11 Quit merbzt1 (*.net *.split) 03.04.11 Quit kadoban (*.net *.split) 03.04.11 Quit fidencio[AWAY] (*.net *.split) 03.04.12 Quit Galois (*.net *.split) 03.04.12 Quit Utchybann (*.net *.split) 03.04.13 Quit Hadaka (*.net *.split) 03.04.13 Quit jvd (*.net *.split) 03.04.13 Quit planetbeing (*.net *.split) 03.04.14 Quit scorche (*.net *.split) 03.04.14 Quit rvvs89 (*.net *.split) 03.04.14 Quit mikroflops (*.net *.split) 03.04.14 Quit bluebroth3r (*.net *.split) 03.04.15 Quit jd (*.net *.split) 03.04.15 Quit FOAD (*.net *.split) 03.04.15 Quit ObsidianX (*.net *.split) 03.04.15 Quit rasher (*.net *.split) 03.04.16 Quit linuxguy3 (*.net *.split) 03.04.16 Quit Llorean (*.net *.split) 03.04.16 Quit Connor (*.net *.split) 03.04.16 Quit beta_ (*.net *.split) 03.04.16 Quit katyl (*.net *.split) 03.04.17 Quit bieber (*.net *.split) 03.04.17 Quit pixelma (*.net *.split) 03.04.17 Quit Xerion (*.net *.split) 03.04.17 Quit topik (*.net *.split) 03.04.18 Quit Unhelpful (*.net *.split) 03.04.18 Quit zOxta (*.net *.split) 03.04.19 Quit RoronoaZoro (*.net *.split) 03.04.19 Quit sevard_ (*.net *.split) 03.04.19 Quit Adubb (*.net *.split) 03.04.19 Quit Zarggg (*.net *.split) 03.04.19 Quit GHF (*.net *.split) 03.04.20 Quit Torne (*.net *.split) 03.04.20 Quit Zambezi (*.net *.split) 03.04.20 Quit YPSY (*.net *.split) 03.04.20 Quit dmb (*.net *.split) 03.04.21 Quit Minataku (*.net *.split) 03.04.21 Quit mrigesh (*.net *.split) 03.04.22 Quit Tuplis (*.net *.split) 03.04.22 Quit crwl (*.net *.split) 03.04.22 Quit ved (*.net *.split) 03.04.22 Quit MagusG (*.net *.split) 03.04.22 Quit killan_ (*.net *.split) 03.04.22 Quit RadicalR (*.net *.split) 03.04.23 Quit amiconn (*.net *.split) 03.04.23 Quit elinenbe (*.net *.split) 03.04.23 Quit xavieran (*.net *.split) 03.04.23 Quit evilnick (*.net *.split) 03.04.23 Quit SirFunk (*.net *.split) 03.04.24 Quit togetic (*.net *.split) 03.04.24 Quit Curtman (*.net *.split) 03.04.24 Quit lyngaas (*.net *.split) 03.04.24 Quit maraz_ (*.net *.split) 03.04.25 Quit preglow (*.net *.split) 03.04.25 Quit yosafbridge (*.net *.split) 03.04.25 Quit ChanServ (*.net *.split) 03.04.26 Quit Darkknight512 (*.net *.split) 03.06.41 Join mrigesh [0] (~mrigesh@iws3.iiita.ac.in) 03.06.41 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 03.06.41 Join kugel [0] (~kugel@rockbox/developer/kugel) 03.06.41 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 03.06.41 Join m3dlg [0] (~m3dlg@212.183.140.33) 03.06.41 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 03.06.41 Join zOxta [0] (~email@82.201.219.234) 03.06.41 Join katyl [0] (~katyl@adsl-074-170-246-249.sip.gnv.bellsouth.net) 03.06.41 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 03.06.41 Join Bagder [0] (~daniel@rockbox/developer/bagder) 03.06.41 Join jae [0] (~jae@jaerhard.com) 03.06.41 Join soap [0] (~soap@rockbox/staff/soap) 03.06.41 Join flyback [0] (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 03.06.41 Join fxb__ [0] (~felixbrun@h1252615.stratoserver.net) 03.06.41 Join blithe [0] (~blithe@72.14.176.144) 03.06.41 Join MuscleNerd [0] (eric@adsl-75-27-189-151.dsl.irvnca.sbcglobal.net) 03.06.41 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 03.06.41 Join jobec [0] (paulus@viherharakka.cs.tut.fi) 03.06.41 Join Kohlrabi [0] (~Kohlrabi@frustum.nosebud.de) 03.06.41 Join CIA-5 [0] (cia@208.69.182.149) 03.06.41 Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) 03.06.41 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 03.06.41 Join pjm0616 [0] (~user@61.250.113.98) 03.06.41 Join niekie [0] (~niek@CAcert/Assurer/niekie) 03.06.41 Join ranma [0] (ranma@mx.tdiedrich.de) 03.06.41 Join simabeis [0] (~simabeis@lobmenschen.de) 03.06.41 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 03.06.41 Join Utchybann [0] (~Utchy@rps6752.ovh.net) 03.06.41 Join Hadaka [0] (~naked@naked.iki.fi) 03.06.41 Join jvd [0] (~syscrash@poipu/developer/syscrash) 03.06.41 Join nimak [0] (~nima@adsl-75-45-227-30.dsl.sfldmi.sbcglobal.net) 03.06.41 Join aevin [0] (eivindsy@unaffiliated/aevin) 03.06.41 Join stavrob_ [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 03.06.41 Join dionoea_ [0] (~dionoea@yop.chewa.net) 03.06.41 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 03.06.41 Join parafin [0] (parafin@paraf.in) 03.06.41 Join beta_ [0] (~beta@d24-36-66-52.home1.cgocable.net) 03.06.41 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 03.06.41 Join Connor [0] (Connor@ip72-204-35-60.fv.ks.cox.net) 03.06.41 Join fidencio[AWAY] [0] (~fidencio@li113-135.members.linode.com) 03.06.41 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 03.06.41 Join aholic [0] (aholic@pool-74-103-220-127.prvdri.fios.verizon.net) 03.06.41 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 03.06.41 Join krazykit [0] (~kkit@adsl-76-240-216-183.dsl.ipltin.sbcglobal.net) 03.06.41 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 03.06.41 Join merbzt1 [0] (~benlar@193.13.246.198) 03.06.41 Join linuxguy3 [0] (~timj@adsl-75-57-164-223.dsl.emhril.sbcglobal.net) 03.06.41 Join jordan` [0] (~jordan@78.235.252.137) 03.06.41 Join yawny [0] (user36@pr0.us) 03.06.41 Join tmzt [0] (~tmzt@adsl-99-164-48-101.dsl.akrnoh.sbcglobal.net) 03.06.41 Join topik [0] (awesome@wtf.grmpf.org) 03.06.41 Join Topy [0] (~topy@my.fastsh.it) 03.06.41 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 03.06.41 Join alexbobp [0] (~alex@66.112.249.238) 03.06.41 Join rasher [0] (~rasher@rockbox/developer/rasher) 03.06.41 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 03.06.41 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 03.06.41 Join avacore [0] (nobody@1008ds1-rdo.0.fullrate.dk) 03.06.41 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 03.06.41 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 03.06.41 Join ObsidianX [0] (~ObsidianX@99-27-207-18.lightspeed.irvnca.sbcglobal.net) 03.06.41 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 03.06.41 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 03.06.41 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 03.06.41 Join bzed [0] (~bzed@devel.recluse.de) 03.06.41 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 03.06.41 Join rvvs89 [0] (~rvvs89@pdpc/supporter/base/rvvs89) 03.06.41 Join _flow_ [0] (flow@star.freakempire.de) 03.06.41 Join FOAD [0] (~dok@dinah.blub.net) 03.06.41 Join Tomis [0] (~Tomis@70.134.88.172) 03.06.41 Join Kitar|st [0] (Kitr88@BSN-142-105-33.dial-up.dsl.siol.net) 03.06.41 Join scorche [0] (~scorche@rockbox/administrator/scorche) 03.06.41 Join Guest3190 [0] (jljhook@irkki.fi) 03.06.41 Join 13WAALBUM [0] (~leavittx@89.221.199.187) 03.06.41 Join BlakeJohnson86 [0] (~bjohnson@2002:1876:a27b:0:227:13ff:fe65:1262) 03.06.41 Join pixelma [0] (quassel@rockbox/staff/pixelma) 03.06.41 Join anewuser [0] (anewuser@unaffiliated/anewuser) 03.06.41 Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) 03.06.41 Join jd [0] (~jd@Wikipedia/HellDragon) 03.06.41 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 03.06.41 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 03.06.41 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-ddgzmivbcuppmbre) 03.06.41 Join bieber [0] (~bieber@132.170.45.2) 03.06.41 Join jfc^3 [0] (~john@dpc6682208002.direcpc.com) 03.06.41 Join panni__ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 03.06.41 Join logiclost [0] (~lostlogic@erudite.lostlogicx.com) 03.06.41 Join Gartral [0] (~Gareth@99-9-202-154.lightspeed.bcvloh.sbcglobal.net) 03.06.41 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 03.06.41 Join tipi^ [0] (pihlstro@lehtori.cc.tut.fi) 03.06.41 Join Tuplis [0] (~jani@adsl-77-109-221-158.kymp.net) 03.06.41 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) 03.06.41 Join ved [0] (ved@ddsbox.co.cc) 03.06.41 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 03.06.41 Join CaptainKwel [0] (~jason@207-237-107-203.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 03.06.41 Join komputes [0] (~komputes@ubuntu/member/komputes) 03.06.41 Join leavittx [0] (~leavittx@89.221.199.187) 03.06.41 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 03.06.41 Join Minataku [0] (~Ed@unaffiliated/payphoneed) 03.06.41 Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 03.06.41 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 03.06.41 Join mt [0] (~mtee@rockbox/developer/mt) 03.06.41 Join RoronoaZoro [0] (~vijayss@202.3.77.149) 03.06.41 Join amiconn [0] (quassel@rockbox/developer/amiconn) 03.06.41 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 03.06.41 Join elinenbe [0] (~elinenbe@207-237-241-192.c3-0.80w-ubr1.nyr-80w.ny.cable.rcn.com) 03.06.41 Join xavieran [0] (~xavieran@ppp118-209-228-213.lns20.mel6.internode.on.net) 03.06.41 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 03.06.41 Join SirFunk [0] (~Sir@97-92-38-108.dhcp.aldl.mi.charter.com) 03.06.41 Join sevard_ [0] (sev@216.164.6.24) 03.06.41 Join yawny_ [0] (user36@pr0.us) 03.06.41 Join Adubb [0] (~aldubuc@67.201.160.144) 03.06.41 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 03.06.41 Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 03.06.41 Join GHF [0] (~meow@unaffiliated/ghf) 03.06.41 Join togetic [0] (~togetic@unaffiliated/ibuffy) 03.06.41 Join Torne [0] (torne@rockbox/developer/Torne) 03.06.41 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 03.06.41 Join dmb [0] (~dmb@unaffiliated/dmb) 03.06.41 Join YPSY [0] (~ypsy@geekpadawan.de) 03.06.41 Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) 03.06.41 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 03.06.41 Join maraz_ [0] (maraz@kapsi.fi) 03.06.41 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 03.06.41 Join yosafbridge [0] (~yosafbrid@li14-39.members.linode.com) 03.06.41 Join ChanServ [0] (ChanServ@services.) 03.06.41 Mode "#rockbox +o ChanServ " by verne.freenode.net 03.07.09 # Re-implementing it won't be bad at all. The parsing is easy, the only thing that will really be significantly difficult is the rendering, and I can't imagine trying to port rendering code from an embedded device to a higher-level GUI library 03.07.23 # Llorean: I'm not shy of doing actual work on this, but I want to make sure the work I do is targeted as effectively as possible. Building the editor itself is going to be a hefty task, and I don't want to spend any more time/effort than necessary getting the necessary groundwork laid 03.07.29 # the more code you use from rockbox, the less you need to reimplement. you could take it so far that would only implement a handful of firmware/ functions 03.07.31 Join Guest62701F [0] (Status@gentoo.lonis.org) 03.07.49 # bieber: Why is the editor itself so hefty? 03.07.59 # ppl...is rockbox going to support sansa connect anytime soon? 03.08.11 # Guest62701F: possibly, if you work on it 03.08.23 # otherwise, very unlikely 03.08.28 # kugel if I programmer in C I would ;] 03.08.33 # *programmed 03.08.41 Nick Guest62701F is now known as Status (Status@gentoo.lonis.org) 03.09.00 Quit S_a_i_n_t (Ping timeout: 240 seconds) 03.09.07 # Llorean: Consider the complexity of it. I can't imagine ever running out of new features that could be useful to implement 03.09.19 # Give me some examples 03.09.27 # kugel thats one of the best sansa's out there...supports wi-fi and everything 03.09.47 # thats why when I saw it didn't support I was even sad :/ 03.09.52 # bieber: I think we can judge a bit from the last wps editor, the editor itself wasn't overly complex 03.09.55 # There's just not that many elements of a WPS, and the vast majority of them are text. 03.10.09 # And positioning for most of those is line-based within the parent viewport 03.10.20 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 03.10.47 # Status: Being a volunteer project, support only happens when people who actually own the device are interested enough to do the necessary work. Anyone can learn C if they're dedicated enough. 03.11.03 # I'd think that building the rendering system to adapt to the different targets would be a pretty significant task to start with 03.11.10 Quit xiainx (Quit: Good Bye) 03.11.15 # There should be a decent code editor attached to it, with some form of syntax highlighting 03.11.19 # Llorean I tried learning C already on my own just to do simple things...but C doesn't like me ;/ 03.11.57 Quit Battousai (Read error: Operation timed out) 03.12.00 Join Battousai [0] (~bryan@gentoo/developer/battousai) 03.12.01 # It would be nice if a "project" could allow a user to target multiple targets with the same project file, adapting common elements as much as possible 03.12.08 # bieber: that's why should spend as little time as possible on the rockbox-side and more on the editor side 03.12.17 # bieber: What common elements? 03.12.24 Nick mrigesh is now known as animAgus (~mrigesh@iws3.iiita.ac.in) 03.12.50 # There's no relative positioning, so it's simply "if all the elements fit on screen, it's cross platform, if they don't, it's not" 03.12.51 # the skin enginge shold be completly seperate from the build and only use function calls/stubs instead of directly hitting stuff like screens. and global_settings 03.13.21 # * kugel liked (and still likes) the old wps editor's aproach 03.13.52 # kugel: That's why I'd rather re-implement the parser than try and deal with the existing code. imo it will entail significantly less effort, it'll leave the Rockbox main tree unaltered by my application, and it will be more easily maintainable 03.14.16 # * kugel largely disagrees but well 03.14.18 # leaving the rockbox tree unalterned isnt necessarily a good thing 03.14.20 # bieber: Wouldn't "it doesn't require separate maintenance" be more easily maintainable? 03.14.29 # I just don't think that building an editor that can automagically adapt itself to however Rockbox's skin engine may change is a realistic goal 03.14.30 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.4) 03.14.37 # I think the first goal of the WPS editor should be accuracy. If it can render exactly what the sims do, that would be ideal 03.14.59 # bieber: The sims "automagically" adapt themselves to changes in Rockbox's skin engine. 03.15.11 # What do the sims do? 03.15.20 # They run on the host PC and simulator the UI of Rockbox 03.15.22 # Including WPS 03.15.24 # we should be able to build a copy of the lib with support for every tag and make then run-time configurable (and compile time configurable on real targets also) 03.15.27 # compile all apps/ and most firmware/ code :) 03.16.18 # I'm guessing the sims do something like creating a vm that responds to all the system calls and such in the Rockbox source? 03.16.30 # It doesn't seem like a standalone theme editor would really be comparable 03.17.27 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 03.17.33 # bieber: I was just pointing out that it's not unrealistic for something to be able to adapt itself in such a way to skin engine changes. 03.17.56 # well, I consider it a win for rockbox if we would fix the skin engine-side as well 03.17.59 *** Saving seen data "./dancer.seen" 03.18.13 # Is there really anything broken about it? 03.18.56 # it's not broken, but it appearently doesn't attract 3rd party app developers to work with it 03.18.57 # If it's running on an embedded platform and its sole purpose is to parse and render skin files, it seems perfectly reasonable that the parsing, rendering, file-system and so on code should all be integrated together 03.19.35 # * Llorean just doesn't see the benefit of having a theme editor done if it's just going to fall to the wayside like the last one. 03.20.12 # There needs to be a plan in place for how it's going to be kept up to date, since there's no way to guarantee or even encourage feature authors to also update it. 03.20.36 # it's most certainly possible to make it automagically adapt changes, but yes, it probably needs changes in the skin engine itself as well 03.20.51 # And the most reliable plan in that sense is for it to share as much code as possible so that it updates itself (or at least requires the author to fix it too when committing the patch so there's no red in the build table) 03.23.41 # bieber: in fact, you'll probably be the only maintainer, nobody here is keen on touching c++ code for a desktop app :) 03.24.10 # It's possible, but then I'd be looking at two completely separate projects: completely refactoring RockBox's skin engine and building a theme editor 03.24.53 # you have 2 separate projects anyway, either refactor the skin engine or reimplement it, then build the editor 03.25.09 # And considering that I really know nothing about Rockbox's codebase or embedded programming in general, I don't even know if learning enough to accomplish the first project would be doable in a Summer 03.25.12 # what of the 2 former is less work? I'd think the refactoring 03.25.21 # Maybe if you already know your way around the code 03.26.02 # Re-implementing a parser and renderer is something I know for a fact that I can do, and doing it all in OO C++ rather than trying to refactor a large body of C code to do what I want will save a lot of effort 03.26.32 # not without getting deeper into rockbox and its codebase 03.26.34 # Aside from the fact that if I refactor the skin engine to work with my editor, then being able to pass an OO parse tree to the GUI app becomes impossible 03.26.37 # The thing is, it may be something you know you can do, but if the end result of the project is something the mentors decide isn't something we want, it doesn't matter whether or not you can do it. 03.26.47 # you want to emulate, not an alternative renderer 03.27.02 Quit adnyxo (Remote host closed the connection) 03.28.00 # If a WPS change changes aspects of the rendering in Rockbox, someone is going to have to reimplement those changes in a way that works right in your renderer too. 03.28.02 # fwiw, the earlier conversation with an actual potential mentor had everyone telling me that the last editor was a mess and that I would be better off re-implementing things 03.28.17 # I must have hit a different crowd tonight ;) 03.28.25 # bieber: Kugel and JdGordon are responsible for a significant chunk of the existing WPS code. 03.28.46 # Duly noted 03.29.30 # imo, heavily refactoring the skin engine for the benefit of a standalone editor looks like overengineering a great deal 03.30.55 # Creating a standalone editor that becomes outdated the first time the skin engine changes significantly and nobody is around to update the editor, on the other hand, is a big waste of Google's money. ;) 03.31.16 # Any code that comes out of this needs to be code the project will keep using. 03.31.50 # So if it leads to over all improvements of the skin engine, but doesn't result in a finished editor due to time constraints, I personally would say that's better than an editor that's likely to gather dust. 03.31.55 # bieber: yes, you talked to a different croud :) 03.32.11 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 03.32.19 # Code in general needs to be maintained. If the code that comes out of the project is useful to enough people for a long enough period of time, then it's worth the money, regardless of what may happen to it later 03.32.26 # I think you heavily overestimate the work the skin engine needs 03.32.37 # Regardless of how you build it, at some point it will break without someone keeping it up to date 03.32.58 # kugel: It's a possibility. I guess you've worked with it a lot, could you give me an idea of the complexity of the codebase? 03.33.31 # the skin engine is only a few thousand lines. the parser and displayer are mostly separate already 03.34.08 # My other concern is how much it might impact performance if you completely separated parsing from any of the system-specific functionality 03.34.33 # parsing is not a problem, it only happens rarely 03.34.53 # Only on theme load, right? 03.34.58 # and displaying is usually limited by the lcd drivers, so not a real problem too 03.35.06 # Llorean: yes 03.35.15 # Which for a lot of us is once per boot. 03.35.31 # And, of course, how feasible it would be to adapt Rockbox display code to render into a QT GUI 03.36.11 # It renders into SDL already. 03.36.12 # I think the old editor Qt'ified a lot, if not too much 03.37.23 # I just remember the fonts looked quite awkward compared to the targets 03.37.39 # I think it would possibly be a good idea to compile to reuse the lower level drawing functions as well (font, scrolling) 03.38.35 # s/to compile// 03.38.41 # but maybe that's asking too much 03.38.42 # wouldnt gtk be lighter? 03.39.05 # Weren't' the old pre-SDL sims in GTK? 03.39.34 # bieber: the old wps editor actually rendered WPSes IIRC, you could have a look at that code to see how much it involves 03.40.50 Quit CaptainKwel (Remote host closed the connection) 03.41.50 # GTK may be lighter, but it looks awful on Windows/Mac, and QT's a much friendlier library 03.42.24 # I'll have to take a look at the old editor code 03.43.11 # * Llorean isn't sure "looks awful" is too significant of a concern, but also doesn't see any big reason not to use QT. 03.43.13 # you probably only need a few dozen wrapper/stubs (and resolve the conditional compilation things) - that's it 03.43.48 # My biggest concern would be how much of the maintenance costst that kind of refactoring would actually alleviate 03.44.56 # Aside from parsing and rendering, the editor has to implement a lot of other functionality that's going to be directly dependent on the parse tree it gets, and there's really no way you can make that change when the underlying engines change 03.45.41 # are you sure? 03.46.06 # Even if we make rendering and parsing completely dependent on Rockbox's own source code, if you change the WPS structure enough it's still going to reduce the editor to a glorified UI sim, if it will still work at all 03.46.25 # I'd imagine it would just do wps_widget_draw(), and the skin engine would be setup to draw into rectangle, then be done 03.46.27 # Code generation, for instance, is just as an important element of the editor as code interpretation 03.46.39 Quit komputes (Ping timeout: 264 seconds) 03.47.25 Quit JdGordon (Ping timeout: 252 seconds) 03.47.26 # just reparse the whole file once in a while 03.47.30 # And as long as backward compatibility is maintained all the basic code generation will still function. 03.47.36 # the parser is blazing fast, especially on desktop systems 03.47.59 # and as long as there's a manual text editor, any new features can be addressed by hand until a gui implementation for them is added. 03.48.14 # I'm not worried about how fast it will run, just working with the code from the GUI application 03.48.50 # you said your editor is dependant on the parse tree, it's unclear to me how 03.49.17 # Besides, using Rockbox's code just to render the parse tree into a window would leave the editor out in the cold when you wanted that display to be interactive 03.49.41 # it doesnt need to be interactive 03.49.42 # It's not enough for it to be able to draw the elements, it has to know where they are, and be able to modify them accordingly to get what the user wants when they're doing their graphical editing 03.49.59 # kugel: Well a WYSIWYG style editor with drag and drop positioning of viewports and images would be heavily dependent on the wps language coming from WPS screen to .wps file, when traditionally we go the other way. 03.50.30 # drag'n'drop wps elements? 03.50.42 # If it's not interactive, aren't we really just chaining a text-editor to a UI sim? 03.50.48 # * kugel apparently has a different, clearly lower, expectation 03.51.00 # bieber: A live preview with a syntax highlighting text editor would (to me) be the obvious first step anyway 03.51.18 # As a first step, yes, but I certainly wouldn't be satisfied with stopping there 03.51.40 # but it would maybe enough to make the soc project succeed 03.51.50 # If I'm going to spend all Summer on this, then I should certainly be able to come up with something artistic types can use to make their themes without having to know or care about how the underlying code works 03.51.58 # you're of course welcome to work further on it, after gsoc 03.52.30 Quit FOAD (Ping timeout: 240 seconds) 03.52.41 # bieber: I don't think that's possible 03.52.55 # the idea is that we want to keep you working on it with us forever ;p) 03.52.56 # and I'm not sure we want that 03.53.14 # I think evidence shows that the artistic types are willing to get their hands pretty dirty to work on WPSes as it is. 03.53.35 # Well, I guess at very least they'd have to be able to use simple tags, but I'd still want at least something like a dropbox to insert those so they don't have to remember them 03.54.13 # And don't get me wrong, I'm certainly into this for the long haul (If SOC doesn't work out, I'll still be hacking away on it in my spare time), but if I'm going to have a couple of months where I get to work on it full-time, I know I can accomplish a lot 03.54.18 Join FOAD [0] (~dok@dinah.blub.net) 03.54.21 # I think the idea should be to remove as much burden from them as possible, sure, but that's often going to be just cutting out the rough edges of the testing and previewing process, and providing buttons to add tags and such 03.55.24 Join saratoga_lab [0] (~9803c20d@gateway/web/freenode/x-gijvtstbcpukcmgg) 03.55.32 # bieber: I doubt you can do it that fancy within gsoc no matter of reusing or reimplementing the skin engine 03.55.37 # i proposed yet another GSOC project today, a test driver for audio playback 03.56.14 # I don't know how far I could get, but at least rudimentary graphical editing wouldn't be too terribly difficult to implement 03.56.29 Quit kugel (Remote host closed the connection) 03.56.49 # And with the object-oriented parse tree I'm generating, it's dead-simple to make changes go back and forth between changes users make to code and the graphical representation 03.57.05 Quit Darkknight512 (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100202165920]) 03.57.24 # Just give each sub-class a draw() method and a genCode() method. User edits something on the canvas, call all the genCode() methods. User edits something in the code, reparse and call the draw() methods 03.59.31 # Since the parser as I've built it so far is including whitespace and such in the parse tree, no user formatting will even get lost between edits 04.01.03 # bieber: Remember that you can have nested conditionals, alternating sublines and other "objects with an object" situations, too. 04.01.29 # I don't know if you could reliably generate code from a purely graphical representation of the WPS 04.01.45 # Hmm, conditionals would be tricky 04.02.18 # I could probably display them as an area with a little page-corner-looking icon to flip between true/false or different enumerated values 04.02.28 # Or maybe a side-panel that lets you flip the state of different conditionals 04.02.30 # Also, it matters where in a file many objects are defined. 04.02.48 # Right, z-ordering and such will have to be specifiable 04.03.24 # Oh, btw, I read in the wiki page that a named viewport has to be displayed before it's declared. Is this meant to be the other way aroun? 04.04.19 Quit scorche (Read error: Connection reset by peer) 04.04.41 Join scorche [0] (~scorche@rockbox/administrator/scorche) 04.13.11 Quit planetbeing (Quit: planetbeing) 04.16.22 # TheSeven: Around? 04.17.05 Join Barahir_ [0] (~jonathan@gssn-5f754fe0.pool.mediaWays.net) 04.17.44 Quit Barahir (Read error: Operation timed out) 04.21.33 # is the *correct* syntax for the .icons file "ext:0" or "ext: 0" (I've seen examples of both in various iconsets) does it matter? 04.22.17 # saratoga_lab I did... 04.22.37 # but there's no status about the player anywhere..only stuff on the wiki 04.22.51 # thats why I posted to see if any progress was actually made 04.23.02 Quit TheSeven (Disconnected by services) 04.23.15 # Status: The stuff on the wiki is where you'd see progress if there was any 04.23.16 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.23.27 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.23.40 # so progress would be 0 ;/ 04.24.11 # Well, because the people who want it don't work on it. 04.25.08 # Llorean well I do want it...and would even pay for one of these for a dev if necessary... 04.25.44 Join moos [0] (moos@rockbox/staff/moos) 04.25.56 # Status: As I told you earlier, you're better off putting in the effort to learn what you must and do it. 04.25.58 # I don't code C...and telling me to learn isn't gonna do any good...by the time I could even code would take what? 3/4 months to code crappy code?...1 year to actually get into firmware stuff? ;] 04.26.10 # And 1 year is still shorter than "never" 04.26.49 # A port is hard work. There's no magic trick for making someone dedicated to doing it, so it's better to find someone dedicated and have them learn the parts that *can* be learned. 04.26.59 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 04.27.26 # I know it's hard work... 04.27.39 # that's why I was wondering if its missed hardware or something 04.28.27 # because usually devs/testers..sometimes don't even have hardware to work on...rely on testing done by others.. 04.28.41 # That's rarely the case here. 04.29.37 Quit ObsidianX (Read error: Connection reset by peer) 04.29.41 # hard port then? 04.30.05 # Nobody who wants it is working on it. 04.30.15 # I've said this already. 04.30.18 # :/ 04.30.31 # The people who want it are apparently all like you - hoping someone else will do it for them. 04.31.12 # because most people don't code...so they help in other ways...hardware...donations etc... ;] 04.31.34 # C is a pretty simple language, don't be discouraged about trying to learn it 04.32.00 # Do you know anything about programming? 04.32.03 # bieber I must have about 3/4 C/C++ books 04.32.29 # I get lost on all that pointers and var assignment stuff 04.32.34 # Is it immediately obvious where the piezo frequency (which line(s) of code etc.) is being set in FS#5111? It doesn;t sound quite right to me, and I wish t have a fiddle with it, but I'm definately missing someting... 04.32.40 # bieber I can do magic in tcl ;] 04.33.16 # Okay, so we just need to get you thinking a little bit lower level ;) 04.33.23 # be it in shell-scripts...web..eggdrops ;] 04.33.48 # Well, a port often also involves some reverse engineering unless there's good hardware docs. And that's after you've figured out a means of running your own code and/or decrypting the original firmware. 04.34.11 # So some assembly knowledge would also help. 04.34.25 # Ooh, I didn't even think about that 04.34.27 # uhum 04.34.41 # Llorean by the time I learn asm I'll have white hairs 04.34.43 # hehehehe 04.34.50 # But, practically speaking, ports don't happen from donated hardware or a bunch of people saying "this is a really neat player." 04.34.56 # assembly is the language of the devil 04.35.01 # They almost always happen by someone who is already interested in the player doing the hard work necessary 04.35.37 # If you aren't interested in doing the work, about all you can do is hope someone interested in it shows up in the future, and check back every now and then to see if the page is updating. 04.35.46 # Llorean do you code? 04.35.57 # C? something else..? 04.36.29 # Several languages including C, but in regards to Rockbox I'm more of a user. 04.37.15 # how would you consider yourself on C? 04.37.24 # What does this have to do with Rockbox? 04.37.45 # just to have an idea how you learned it ;] 04.37.54 # Just out of curiosity, if you're willing to contribute monetarily, and you really want to run Rockbox, why not just buy a player that runs it? 04.37.55 # because apparently the books I got don't cut it 04.38.21 Join ObsidianX [0] (~ObsidianX@adsl-99-62-79-226.dsl.pltn13.sbcglobal.net) 04.38.22 # bieber I have one that runs it 04.38.37 # and I got a 2nd one that doesn't ;/ 04.38.57 # * S_a_i_n_t asks if people can please review/add to http://pastebin.com/Sij10HSw any supported (or unsupported, which may still be viewed in the filebrowser if used as a storage device) filetypes he has missed... 04.39.06 # There shouldn;t be *too* many to go now ;) 04.39.17 # anyhow... 04.39.32 # S_a_i_n_t: What are the 5e,5f etc? 04.39.52 # for pacbox 04.40.04 # So why are they listed? 04.40.24 # I mean, if you're going to include unsupported files, isn't that every extension ever? 04.41.15 # In theory...yes, but I'm trying to come up with all the exts likely to be seen in the filebrowser... 04.41.19 # its a bit of a mission. 04.43.41 Part arbingordon ("`") 04.44.02 # S_a_i_n_t: What's the extension for the lossless correction file for lossy .wv? 04.44.08 Quit bieber (Quit: Leaving) 04.44.14 Join arbingordon [0] (~w@unaffiliated/arbingordon) 04.44.43 # Something is broken in viewers.config, even physically changing it so that it only points to 1 icon (like my .icons file) doesn't work right/as expected. FS#10981 gives a peak at this. 04.45.25 # Llorean: Pass...sorry, thats kinda why I asked in here, I bet I'm missing a *heap* of ext's I *should* have in there. 04.45.25 Join Rob2223 [0] (~Miranda@p4FDCA775.dip.t-dialin.net) 04.46.56 # I see .voice but not .talk 04.47.36 # Aha...thanks :D 04.47.45 # 1 down, a million to go ;) 04.48.28 Quit Rob2222 (Ping timeout: 240 seconds) 04.48.31 # .wvc for the wavpack correction file 04.49.10 # Llorean: Thanks again. 04.49.25 # srobbler.log is a file, right? 04.49.38 # * Llorean also wants to say .ini but doesn't know where that'd be from 04.50.46 # and yes, you're right about .log...wow, you're good at this ;) 04.52.33 # I see .tar and .gzip but not .gz or .tgz or .rar 04.53.42 # For the project 'Improved video playback', I would like to know where to start for the part of MPEG4 (A)SP Video 04.54.30 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-gqhbltndjfopwhqt) 04.54.44 # Wow! Thanks *so* much :D Its obviously a lot better to get a clear head to look at this, I look at that list (which has taken me ages to get as thorough as it is) and I'm just like "Gah! so. many. filetypes..." 04.57.25 # is it intended to have duplicated types? 04.57.57 # @S_a_i_n_t 04.58.12 # There are duplicates? 04.58.44 # just spoted one, line 87 and 81 04.58.48 Quit m3dlg (Ping timeout: 264 seconds) 04.58.58 # after quick look to be precise :p 05.00.30 # Hmm, that was odd..thanks for that moos 05.01.06 # you are welcome, btw I guess you checked the filetypes .c file? 05.01.08 # looking at a long list for ages (especially your own) can have drawbacks when it comes to seeing failures. 05.01.20 # indeed 05.01.22 # moos: yep, checked. 05.01.33 # good 05.07.17 # whats the Mac equivelent of an .exe again? (is it different? it is, isn't it?) 05.09.51 # .app i tihnk 05.09.58 # Application.app 05.10.01 # which is really a folder 05.10.03 # thanks. 05.10.40 Quit anewuser () 05.10.48 Part Llorean 05.11.06 # my .icons file has now grown to 170 ext's :D 05.11.17 # S_a_i_n_t: you can add .mmf file type too 05.11.37 # +10 from all you guys so far ;) 05.11.41 # +11 :D 05.11.45 # :) 05.12.02 # -1 too? ;) 05.13.21 # + .au 05.14.01 # you rang? 05.14.09 # is there a git webpage or any other way to browse rockbox code on http 05.14.24 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 05.15.16 # http://svn.rockbox.org 05.16.02 # thanks 05.17.02 # S_a_i_n_t: seems to miss some audio file types: .snd .vox... according to filetypes.c 05.18.02 *** Saving seen data "./dancer.seen" 05.19.02 # moos: Thanks again, I was *certain* I had all the ones from filetypes.c, but the list there isn;t alphabetical...so it was very hard for my scarrtered brain to compare the two lists ;-P 05.19.26 # make it alphamabetical then! 05.20.46 Quit panni__ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 05.20.47 # S_a_i_n_t: you have even a list just for audio extension on the parser .c file IIRC 05.20.55 # plenty files :) 05.21.24 # Ahhh..I'll have a look there too, thanks. 05.21.50 # I guess its pretty safe to say already that this .icons file has the most cases covered ;) 05.22.04 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 05.22.11 # Its preety easy when you're only pointing to 1 icon ;D 05.22.22 # thats just stupid 05.22.24 # *pretty also. 05.22.39 # check svn r24939, 50 file types for audio last time I did count for the stat plugin 05.22.50 # what is? pointing to 1 icon? 05.23.02 # It fits in with the theme *so* well though... 05.23.05 # * moos is remenbering that he gave a stats plugin patch he have to commit 05.23.28 # all audio type, for 1 icon the audio one 0: ) 05.23.44 # gave/have 05.24.56 Part Gartral 05.24.58 # moos: All icons are the same...*all* Icons, every icon :D Check the Symmetry theme (Nano1/2g) for a reference 05.25.15 # I think it looks cool, but it takes some getting used to. 05.26.18 Join m3dlg [0] (~m3dlg@212.183.140.19) 05.27.29 # S_a_i_n_t: if you want audio extension apart, they are on apps/metadata.c 05.28.56 Quit m3dlg (Client Quit) 05.30.33 # moos: Thanks, there's quite a few I don't have in that list ;) 05.30.46 Join m3dlg [0] (~m3dlg@212.183.140.19) 05.31.37 # np, have fun, you must have 50 filetypes just for audio 05.32.04 # codecs 05.32.06 # yes, and the list seems arbitrarily listed...alphabetical would be *so* nice right now 05.33.41 # {"mp3","mp2","mp1","mpa","ogg","oga", 05.33.43 # "wav","flac","ac3","a52","mpc","wv","m4a","m4b","mp4", 05.33.44 # "shn","aif","aiff","wma","wmv","asf","spx","ape","mac", 05.33.46 # "sid","mod","nsf","nsfe","spc","adx","sap","rm","at3", 05.33.48 # "ra","rmvb","oma","aa3","dmc","dlt","mpt","mpd","rmt", 05.33.50 # "tmc","tm8","tm2","cm3","cmc","cmr","cms","mmf"}; 05.34.38 # a few :) 05.36.41 # S_a_i_n_t: historicaly sorted I guess 05.41.11 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 05.41.22 Quit Horschti (Quit: Verlassend) 05.42.36 Quit planetbeing (Client Quit) 05.43.58 # even on the stats plugins, it seems I missed a few. I have to commit the easy patch I have to replace this constante with the variable we have on core to have the audio type regarding the file name 05.46.08 Join bluebrother [0] (~dom@f053153237.adsl.alicedsl.de) 05.46.08 Quit bluebrother (Changing host) 05.46.08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 05.46.34 # After painstakingly going through metadata.c I managed to find *one* I'd missed... w64 ;D 05.48.16 # revised list (moos + Llorean + Others suggestions included.) http://pastebin.com/qkKtjcaA 05.49.16 # New commit by 03moos (r25327): Stats plugin: Add 3 missing types to count. 05.49.35 Quit bluebroth3r (Ping timeout: 260 seconds) 05.49.47 # 175 extensions...!!! *evil laugh!* 05.50.46 # this is the last update, I'll commit soon the patch I have to get rid of this const. 05.50.55 # hehe :) 05.51.07 Quit JdGordon (Ping timeout: 252 seconds) 05.53.51 Join kadoban_ [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 05.53.51 Quit kadoban (Ping timeout: 276 seconds) 06.01.27 Join CGL [0] (~CGL@190.207.143.203) 06.04.39 # The thing that makes me *know* that icon display is borked somewhere is that even with this massive .icons file, and even if I edit viewers.config directly to only point to one file (which I shouldn't have to, as the .icons file is supposed to override the viewers.config defines) there are still a few .etx's that just *will not* display an icon. 06.05.19 # s/etx's/etx's/ 06.05.32 # hahahah...fail. .ext 06.09.59 Quit m3dlg (Read error: Connection reset by peer) 06.11.25 Quit saratoga_lab (Quit: Page closed) 06.16.57 Join m3dlg [0] (~m3dlg@212.183.140.19) 06.19.38 Quit kramer3d (Quit: Leaving) 06.23.35 Join JdGordon [0] (~7bf38c1f@gateway/web/freenode/x-dqvbtgiemcurlmls) 06.25.24 Quit CGL (Quit: Saliendo) 06.26.45 Quit xavieran (Ping timeout: 245 seconds) 06.37.20 Quit RoronoaZoro (Ping timeout: 252 seconds) 06.45.29 Quit Rob2223 (*.net *.split) 06.45.29 Quit BHSPitMonkey (*.net *.split) 06.45.29 Quit S_a_i_n_t (*.net *.split) 06.45.29 Quit animAgus (*.net *.split) 06.45.29 Quit shai (*.net *.split) 06.45.29 Quit Topy (*.net *.split) 06.45.29 Quit tmzt (*.net *.split) 06.45.30 Quit tchan (*.net *.split) 06.46.51 Join Darkknight512 [0] (~63e16e06@giant.haxx.se) 06.47.19 Quit Darkknight512 (Client Quit) 06.52.41 Join Rob2223 [0] (~Miranda@p4FDCA775.dip.t-dialin.net) 06.52.41 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 06.52.41 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.4) 06.52.41 Join animAgus [0] (~mrigesh@iws3.iiita.ac.in) 06.52.41 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 06.52.41 Join Topy [0] (~topy@my.fastsh.it) 06.52.41 Join tmzt [0] (~tmzt@adsl-99-164-48-101.dsl.akrnoh.sbcglobal.net) 06.52.41 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 07.16.55 Quit m3dlg (Ping timeout: 252 seconds) 07.18.04 *** Saving seen data "./dancer.seen" 07.18.45 # * pixelma wonders if some of the new codecs were added to the codec type enum for the WPS as well 07.19.07 Quit blairb (Ping timeout: 240 seconds) 07.19.56 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 07.25.12 Quit FOAD (Quit: I'll be back) 07.25.27 Quit blairb (Ping timeout: 240 seconds) 07.25.30 Join FOAD [0] (~dok@dinah.blub.net) 07.26.17 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 07.29.16 Join DerPapst [0] (~DerPapst@p5797C614.dip.t-dialin.net) 07.33.10 Join xavieran [0] (~xavieran@ppp118-209-228-213.lns20.mel6.internode.on.net) 07.33.36 Join r2_ [0] (~chatzilla@c-67-164-21-71.hsd1.ca.comcast.net) 07.38.47 Quit blairb (Ping timeout: 240 seconds) 07.39.42 Quit BHSPitMonkey (Quit: Ex-Chat) 07.40.42 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.50.14 Join Zarggg_ [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) 07.53.46 Quit sevard_ (Ping timeout: 252 seconds) 07.53.46 Quit Zarggg (Ping timeout: 252 seconds) 07.54.23 Join sevard [0] (sev@216.164.6.24) 08.09.05 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 08.13.39 Join ender` [0] (krneki@foo.eternallybored.org) 08.23.14 Join wodz [0] (~wodz@chello087206240004.chello.pl) 08.25.17 # Hello. Can someone from coldfire developers review apps/plugins/plugin.lds change in patch from #11137? It changes ifdefs for coldfire from targets specyfic to procesor variant specyfic. I think it is cleaner. 08.27.19 Quit zOxta (Ping timeout: 252 seconds) 08.29.22 Join zOxta [0] (~email@82.201.219.113) 08.35.41 Quit pjm0616 (Ping timeout: 258 seconds) 08.35.54 Join pjm0616 [0] (~user@61.250.113.98) 08.39.55 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) 08.41.41 # wodz: did you see funmans comment in the tracker? 08.43.25 # yes 08.44.01 # I am talking only about apps/plugins/plugin.lds change since it is the most intrusive one 08.44.23 # oh, right, I didn't read fully 08.45.56 # is dram location always in a permanently fixed location on these chips, or is that configurable? 08.47.20 # I would assume iram is fixed, but does the same apply to dram? 08.47.54 Quit Tomis (Quit: Tomis) 08.48.17 # dram address as well as iram adresses are configurable 08.48.30 # but all cf target uses the same bases 08.48.38 # in that case I disagree with your change 08.48.39 # I mean in rockbox 08.49.05 # Zagor: why? 08.49.36 # theoretically, a new MCF5250 target could appear with these areas in different locations. so it's bound to the player models, not the cpu model. 08.50.24 # Zagor: no no. You select by writing to register where to put dram/iram - look at crt0.S for coldfire 08.50.49 # oh. I thought it was a pin configuration. 08.50.57 # in that case, I *agree* with your changes! :-) 08.53.52 # or,wait 08.53.54 # crt0.S lines 45-65 sets irams addresses, lines 161-173 sets dram address 08.54.26 # the comment "Note on 32Mbyte models: We place the SDRAM on an 0x1000000" makes me confused 08.54.41 Join mitk [0] (~mitk@195.117.162.130) 08.55.33 # aha, it refers to the use of 0x3100000 instead of 0x3000000 08.55.48 # Zagor: yes 08.56.06 # it is related to error in BGA version of 5249 09.02.20 Join Connor_ [0] (Connor@ip72-204-35-60.fv.ks.cox.net) 09.05.07 Quit Connor (Ping timeout: 240 seconds) 09.05.19 Quit moos (Ping timeout: 276 seconds) 09.07.45 Quit wodz (Quit: Leaving) 09.07.52 Quit Llorean (Read error: Connection reset by peer) 09.08.02 Join petur [0] (~petur@rockbox/developer/petur) 09.09.31 Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) 09.18.08 *** Saving seen data "./dancer.seen" 09.30.02 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.35.01 Join swilde [0] (~wilde@aktaia.intevation.org) 09.40.50 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 09.53.34 Quit Luca_S (Quit: CGI:IRC (EOF)) 09.53.59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.57.13 Join kunal [0] (~kunal@121.242.23.197) 10.04.25 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 10.04.36 # I think I sorted out the (un)famous HID bug 10.05.46 Join Gartral [0] (~Gareth@unaffiliated/gartral) 10.06.27 # are there any known bugs with the buildclient scripts? 10.06.45 Quit r2_ (Read error: No route to host) 10.06.56 # Gartral: none known, no 10.07.01 # do you have a candidate? 10.07.20 Join r2_ [0] (~chatzilla@c-67-164-21-71.hsd1.ca.comcast.net) 10.10.49 Quit DerPapst (Quit: Leaving.) 10.11.07 # Zagor: yes, im not sure if this is a bug with ubuntu 9.10 or the buildscripts, but about 5 hours ago i started the script. and a few minutes later.. "2010-03-25 00:35:22 Starting client quarterof7, revision 34, cores 2" which is right and good, then: " * Reloading Common Unix Printing System: cupsd" and - no - action, or activity period for 5 hours 10.11.37 # and it's still sitting there like i just started it >.> 10.11.46 # surely you did not get a CUPS message in rbclient.log? 10.13.04 # true, i did not.. but neither has my buildclient done *any* work since 10.13.05 # my log shows a disconnect from you ~5 hours ago and nothing since 10.13.31 # wtf.. it must be an ubuntu issue.. 10.14.16 # I can't ping your host, but I guess I'm not supposed to? 10.14.32 # try killing rbclient.pl and see what happens 10.14.35 # no, i have a stealthwall 10.15.41 # huh.. it says no process found 10.17.44 # that would be a good reason :-) 10.17.46 # * Gartral thinks ubuntu is screwy 10.18.15 # i cant find either the .sh or .pl scripts 10.18.37 # but the terminal running the .sh hasen't returned a prompt or error 10.18.45 # ! 10.19.31 # so why would the script be killed rudly? 10.20.04 # I have no idea 10.20.37 Join liar [0] (~liar@213162066166.public.t-mobile.at) 10.21.24 # ok.. im back up. 10.23.02 # I don't see a connection 10.24.20 # doi... stupuntu failed again.. it disconnected me.. that's why the script failed 10.24.53 # oh crap 10.24.59 # heh, now you have two clients :) 10.25.07 # HELLO failed: error duplicate names! 10.26.48 # but i killed the first one.. 10.26.57 Quit jae (Quit: leaving) 10.27.38 # note to self... after hard hangup system needs rebooting 10.28.46 Join jae [0] (~jae@jaerhard.com) 10.29.03 # Zagor: do you have a log of my upload speeds? 10.30.22 # Gartral: yes. you can see them in the build graphs. for example: http://rasher.dk/rockbox/buildgraphs/graph.php?r=25326&debug 10.30.56 # the dark green fields are upload. mouseover shows the time. 10.35.06 # S_a_i_n_t: pong (although the ping has probably timed out by now :-P ) 10.43.28 Join xsteadfastx [0] (~spectrum@91.186.43.184) 10.44.36 # Zagor: but that doesnt show my upload speeds as seen from the server 10.44.50 # (in kbps) 10.45.15 # right, it only shows the time. 10.45.42 # is there a server side log of the reported network speed downstream from me? 10.46.08 Quit Luca_S (Quit: CGI:IRC) 10.46.32 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 10.46.54 # Gartral: sort of. we store lots of statistics in a database. 10.47.40 # may i have access (or a copy of my entry) to it? 10.48.04 # sure, just a minute 10.49.02 # if it reads 165 kbps imma be really angry with my isp 10.49.04 # your last 11 builds have been uploaded at 145-180 kbyte/s 10.49.10 # ARGH 10.49.36 # * Gartral joins #rockbox-community to rant x.x 10.50.23 Quit 13WAALBUM (Ping timeout: 248 seconds) 10.50.55 Join leavittx_ [0] (~leavittx@89.221.199.187) 10.57.20 Join RoronoaZoro [0] (~vijayss@202.3.77.149) 10.57.50 Quit animAgus (Ping timeout: 265 seconds) 11.04.23 Quit shai (Quit: Leaving) 11.11.10 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 11.17.02 Quit blairb (Quit: Leaving) 11.18.11 *** Saving seen data "./dancer.seen" 11.19.00 # Torne: It is absolutely correct that app.lds defines iramsize as 0xc000. That's the part we reserve for the core; the rest is given to codecs and plugins 11.19.19 # (either another 0xc000 or 0x14000, depending on PP version) 11.19.45 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 11.25.19 Join Lss [0] (~Lss@cm48.omega219.maxonline.com.sg) 11.25.22 # amiconn: right, i figured that out after a bit ;) 11.26.18 Quit lyngaas (Ping timeout: 245 seconds) 11.28.46 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.42.07 Quit katyl (Remote host closed the connection) 11.44.51 Join anewuser [0] (anewuser@unaffiliated/anewuser) 11.52.09 Join byondo [0] (~me@93-35-252-123.ip57.fastwebnet.it) 11.52.48 # hello everyone 11.53.10 # just flashed my clipv2 11.53.22 # it works like a charm :) 11.58.28 Quit byondo (Ping timeout: 276 seconds) 11.59.16 # it should work like a mediaplayer 12.00.25 Join byondo [0] (~me@93-35-252-123.ip57.fastwebnet.it) 12.04.40 Join ifonefox [0] (~irchon@mobile-166-137-139-190.mycingular.net) 12.05.37 Quit byondo (Ping timeout: 276 seconds) 12.06.13 Quit ifonefox (Client Quit) 12.06.54 Join byondo [0] (~me@93-35-252-123.ip57.fastwebnet.it) 12.07.00 Join ifonefox [0] (~irchon@mobile-166-137-139-190.mycingular.net) 12.07.05 # eheh 12.07.25 # (my mirc client is just goin'crazy) 12.08.07 Quit ifonefox (Remote host closed the connection) 12.11.36 Quit rasher (Ping timeout: 240 seconds) 12.13.54 Quit byondo (Ping timeout: 252 seconds) 12.17.14 Quit flydutch (Read error: Connection reset by peer) 12.17.21 Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) 12.17.48 Join byondo [0] (~me@93-35-252-123.ip57.fastwebnet.it) 12.19.02 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 12.19.02 Quit rasher (Changing host) 12.19.02 Join rasher [0] (~rasher@rockbox/developer/rasher) 12.21.40 Quit xavieran (Ping timeout: 246 seconds) 12.23.33 Quit zOxta (Ping timeout: 276 seconds) 12.27.36 Join zOxta [0] (~email@82.201.233.68) 12.28.05 Quit byondo () 12.30.52 Part xsteadfastx 12.32.34 Quit RadicalR (Read error: Connection reset by peer) 12.34.29 Quit zOxta (Read error: Connection reset by peer) 12.40.46 Join zOxta [0] (~email@196.205.165.112) 12.42.01 Join lyngaas [0] (~staale@19.81-167-149.customer.lyse.net) 12.42.22 Quit kugel (Ping timeout: 248 seconds) 12.44.19 Quit Llorean (Changing host) 12.44.19 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 12.44.27 Join xavieran [0] (~xavieran@ppp118-209-228-213.lns20.mel6.internode.on.net) 12.45.15 Join bimbel [0] (~Miranda@unaffiliated/bmbl) 12.47.33 Join Strife89 [0] (~michael@168.16.232.201) 12.48.35 Part Gartral 12.58.22 # gevaerts (and others): I'm now prettry sure I understand the usb hid bug, the explaination was trickier than I expected first but I think I now grasp it ! The solution is simple however. 12.58.38 Quit bimbel (Quit: Bye!) 12.59.01 Quit Luca_S (Quit: CGI:IRC) 12.59.10 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 13.00.06 Quit anewuser () 13.03.10 # pamaury: is it still simple enough to explain? :) 13.03.20 # yes 13.04.31 # does it go something like "whoever wrote the hid code is a flaming gallah"? 13.04.42 # No, it's a usb-arc bug 13.05.05 # Give me a minute to write an explaination :) 13.05.15 # * gevaerts starts his stopwatch 13.05.38 # From what I understand, it's *just* a stupid mistake in usb-arc. On usb interrupt, the controllers write the ENDPTCOMPLETE register with the mask of completed transfers. Now the code goes though all the endpoints if if ENDPTCOMPLETE bit is '1', it ends the transfer 13.06.07 # yes, or at least it should... 13.06.10 # But, we're are talking about a transfer descriptor here and for the usb code, transfer!=transfer descriptor. 13.06.30 # So, the code ends up big transfers in a premature way sometimes 13.07.13 # Oh, right... 13.07.18 # * gevaerts thinks he understands 13.07.37 # the fix, is to check that ALL tds of a transfers are finished, by looking at the active bit of the status... 13.07.47 # It's set up to only fire an interrupt at the end of the transfer, but it *looks* at all of them... 13.08.16 # Yes, and for an unknow reason, the controller sets ENDPTCOMPLETE bit even for non ioc tds 13.08.47 # That might indeed cause lots of interesting weirdness 13.09.49 Quit kunal (Read error: Connection reset by peer) 13.09.51 # Indeed, so the solution is to look at the active bit, and not only use ENDPTCOMPLETE 13.10.19 Join kunal [0] (~kunal@121.242.23.197) 13.10.56 # On my e200, it works, I'll submit a patch to FS so that others can check if there are no side effects. 13.11.04 # and possibly at the IOC bit 13.12.46 Quit lyngaas (Ping timeout: 248 seconds) 13.12.59 # Well, as transfers don't queue, it's not necessary, just go though all the tds of each endpoint and don't finish the transfer if the active bit is still set on one. 13.14.54 # * gevaerts congratulates pamaury for spotting this 13.15.46 # I wouldn't actually be surprised if this one also caused the other problems we've been seeing over time, where too much system load in general caused USB to go bad 13.18.00 # ooh 13.18.12 *** Saving seen data "./dancer.seen" 13.18.44 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.18.53 # Don't know. I also noted that the usb-arc driver doesn't check for error status in TDs but as interrupt and bulk transfer are retried on error, I believe it's not crucial 13.19.15 # gevaerts: do I create a separate task on FS ? 13.21.01 # pamaury: I don't know. I'd just commit it, it sounds obviously correct to me 13.21.39 # ok, I'll poste to pastebin so that people can look at it 13.22.52 # http://pastebin.com/qM8Gd7XH 13.23.58 # there's a ugly goto but it can be change if some are scared 13.24.33 Quit kugel (Ping timeout: 264 seconds) 13.25.02 # as far as gotos go, this one isn't ugly I think 13.25.21 # the Lskip:continue is ugly but C doesn't allow empty statement after goto iirc 13.25.32 # *after a label 13.26.58 # * gevaerts wonders if FS#9969 might now also work properly 13.28.54 # it didn't work ? 13.29.36 # it caused bus resets 13.30.13 # that's weird 13.30.31 # how is this possible ? It doesn't touch usb code... 13.30.52 # yes and no. To use it you need to change an #if 0 in usb_storage.c 13.31.59 # the queue_broadcast one ? 13.32.47 # yes 13.32.58 Join Strife1989 [0] (~michael@168.16.232.201) 13.33.00 Quit Strife89 (Read error: Connection reset by peer) 13.33.11 # strange 13.33.13 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.33.21 Nick Strife1989 is now known as Strife19 (~michael@168.16.232.201) 13.33.25 Nick Strife19 is now known as Strife89 (~michael@168.16.232.201) 13.34.12 # bad news 13.34.23 # The bug seems to be harder to trigger, but I still have it 13.35.32 # could this also be the cause of the MacOS 10.4 USB problems? 13.36.57 # pixelma: I doubt it 13.37.04 # can someone with some graphics skill make the rockbox logo somewhat rounded and fit on about the size of a cd please? 13.37.43 # arg, by harder you mean ? 13.37.48 # gevaerts: thought so 13.37.58 # but one can hope :) 13.38.11 # pamaury: I mean my e200 wheel turning finger gets a lot of exercise before I get problems 13.38.26 # pamaury: isn't there still a possible duplicate send in hid? 13.38.59 # yes there is, 13.39.17 # maybe I'm hitting that one now then 13.39.23 # Can you try to prevent sending while a transfer is on in usb-hid ? 13.39.51 # That's a simple fix, I'm pretty sure you post a diff on FS about that, but that only few lines 13.45.02 # pamaury: can you check if http://www.rockbox.org/tracker/task/10319?getfile=21252 looks correct? That one doesn't seem to fix the problem here 13.47.20 # it looks ok 13.47.48 # that's a shame 13.49.00 # I suspect you're on the right track though. Without your patch I get problems after a quarter turn of the wheel, with our patch it takes me at least 10 or 20 seconds of turning 13.50.39 # Also, without my patch, MSC transfer speed goes down to about half immediately when I start using HID. With my patch, it stays at or near the HID-less speed 13.51.08 # so there definitely is a HID issue... 13.52.41 # gah, HID is definitely buggy... 13.53.26 # ok, then it's better. Then can the queue_post in usb_core.c (for signaling completion) can overflow and cause mess ? Just a thought... 13.54.04 # I doubt it 13.54.45 # What I *seem* to be seeing is that as long as keep HID active, things work. If I put the player down for a minute or two and then turn the wheel again, it breaks 13.55.06 # I think that that points to a bug in usb_hid.c where it doesn't handle its internal queue properly 13.55.16 # s/queue/ring buffer/ 13.55.29 # Perhaps. I'll investigate it tonight 13.55.45 # * gevaerts thinks that HID should be rewritten to use a proper state machine 13.56.07 # The way it is now, you don't know what state it's in and what is expected to happen next 13.57.50 # Anyway, I think your patch is OK and should be committed 13.58.14 # ok, I'll do it later :) 13.58.21 # The hid one also 14.02.59 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 14.05.52 # hello, I am writing bootloader and I want handle let sey 1s long keypress and discard shorter ones. How to do that? 14.18.16 Quit Strife89 (Quit: Going to class.) 14.25.14 # wodz: what do you want to do? 14.25.21 # a fully graphical bootloader? 14.26.58 # easiest is probably making firmware/button.c compile for the bootloader 14.29.06 # damn this laptop sucks... 60min battery life! 14.29.11 # woops 14.29.54 Join Schmogel [0] (~Miranda@p3EE21FE6.dip0.t-ipconnect.de) 14.31.53 Part LinusN 14.33.41 # wodz: Do you enable interrupts in your bootloader? 14.33.53 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.38.58 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 14.42.41 # linuxstb: yes I do 14.44.05 # What do you want to do? I'm guessing other Coldfire bootloaders don't do what you want? 14.45.23 # New commit by 03pamaury (r25328): Fix usb-arc driver: the driver would prematurely mark a transfer as complete whereas only a part of it actually is, check the active of the TDs to ... 14.45.40 # gevaerts: can I commit you hid fix ? 14.49.37 # linuxstb: You have to press and hold PLAY button to power up dap. Than I want to display small menu with rockbox/OF/shutdown options. This is no problem. But if I want to boot OF I have to have PLAY button still pushed. The easiest way to do this is to use PLAY button as a confirmation but this makes it pretty hard to release button not to early (dap powers down) and not to late (bootloader grabs button event and loads first position from list) 14.49.57 Quit r2_ (Remote host closed the connection) 14.50.29 # New commit by 03pamaury (r25329): Commit a HID fix by gevaerts that prevent the HID driver to call usb_drv_send_nonblocking while the previous transfer has not finished because the ... 14.50.38 # Why not just do the same as the other devices? i.e. not have a menu, and if the user holds play in the Rockbox bootloader, then it starts the OF? 14.52.05 # You are holding play button to power up. 14.52.41 # I can't use REC+PLAY combination also because it is treated specialy in OF 14.53.35 Join SpyBot [0] (~piespy@stgt-5f709a1d.pool.mediaWays.net) 14.54.28 Join funman [0] (~fun@rockbox/developer/funman) 14.54.36 # I'm sure at least one of the iriver targets has the same issue, but forget how it's handled. (amiconn?) How long does your bootloader take to run? Is there time for the user to release the PLAY button to not start the OF? 14.55.46 # linuxstb: I don't quite understand question 14.56.54 # If you turn the DAP on by pressing PLAY, how long do you need to hold it (for the Rockbox bootloader to start)? Can you just press and release it quickly, so that when the bootloader starts, it's not being pressed? 14.57.28 # So in effect "short press on PLAY" - boot Rockbox, and "very long press on play" - start OF. 14.58.05 # linuxstb: hmm I have to check but I think this is possible scenario 14.58.21 Quit Luca_S (Quit: CGI:IRC) 14.58.22 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 14.58.31 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 14.58.33 # generaly You have to hold press as long as crt0.S is finished 14.59.00 # I'm guessing that's quite fast though? Or are there artificial delays? 14.59.14 # its fast 15.00.10 # brains stroming is always good :-) I have to test the ideas 15.00.18 # And I'm guessing you need to spin the hard disk up to load Rockbox? So maybe you could check for the button after the disk has spun up, to give the user time to release it. 15.04.41 # what is default cluster size for FAT32 in windowsXP? 15.12.01 # wodz: depends on the size of the partition, IIRC 15.12.34 # pamaury: do those fixes resolve the HID trouble completely for ARC-based devices? 15.13.00 # or is it just a first stage of a fix? 15.13.16 # and are they likely to affect the nano2g hid trouble? 15.13.32 Quit JdGordon (Ping timeout: 252 seconds) 15.14.30 # TheSeven, 8Gb CF card 15.14.59 # IIRC it always used 4K clusters on my 8GB ipod 15.15.26 # why do you need to know it? 15.15.56 Quit funman (Quit: free(random());) 15.17.10 # I had few partition corruption during test with entering usb mode. I formated card with mkfs.vfat and rockbox is happy but OF is not 15.17.36 # wait, it's an iPod? 15.17.57 # or which other targets are using cf? 15.18.12 # * Torne would guess it's the sector size, not cluster size, that it's pissed at 15.18.15 *** Saving seen data "./dancer.seen" 15.18.34 # but http://support.microsoft.com/kb/140365 has MS's choice of cluster sizes 15.18.50 # TheSeven: from gevaerts tests, it seems that with those both commit, it's real harder to trigger the hid bug, gevaerts suspect the hid driver is ill-written in some way 15.18.59 # *really 15.19.04 # Torne: There's a bug regarding superfloppy formatting in the Nano2G OF, but I guess a non-nano2g wouldn't even boot when formatted as superfloppy 15.19.33 # MPIO hd200 it is early stage not commited yet 15.19.34 # TheSeven: but please, try it and give your feedback :) 15.19.37 # pamaury: do you think it makes sense for me to re-test HID on nano2g, if there is less trouble now? 15.19.39 # ok 15.19.48 # i only speculate that it's sector size because I know that mkfs.vfat doesn't obey the disk's sector size when formatting :0 15.19.57 # (whereas windows does) 15.20.16 # Torne: not even most partitioning tools for linux seem to be able to deal with big sectors 15.20.24 # shit 15.20.40 # * wodz is looking for XP machine around 15.20.48 # wodz: do you not know the sector size? 15.20.51 Join evilnick_B_ [0] (~0c140464@rockbox/staff/evilnick) 15.20.55 # you can tell mkfs.vfat to use whatever. 15.21.16 # Torne: I lost my notes abot this 15.21.27 # the disk will tell you if you ask ;) 15.21.35 Quit evilnick_B (Ping timeout: 252 seconds) 15.21.38 # it's in IDENTIFY somewhere 15.22.03 # it's probably also in some dmesg output during connection of the UMS device 15.23.12 Quit DerPapst (Read error: Connection reset by peer) 15.23.42 # reading battery current for better runtime approximations isn't a NODO, is it? 15.23.58 # no, it's just difficult :) 15.24.14 # well not the reading part 15.24.53 Join DerPapst [0] (~DerPapst@p5099d40e.dip0.t-ipconnect.de) 15.24.59 # * TheSeven suggests wrapping the old battery current estimation code into some kind of dummy ADC API and implementing a real one for targets that support it 15.25.28 # depends whether you want it to be averaged over too much time (so it doesn't adapt to usage very well) or too little time (so it always massively underestimates because typically the user will only be looking when the device is drawing way more power than usual, i.e. when the screen is on) 15.25.35 # :) 15.25.48 # what is it doing right now? 15.26.01 # right now, neither 15.26.11 # IIRC it's not keeping any history at all and just uses the current state of the backlight etc. to guess a current 15.26.20 # Not quite.. 15.26.26 # It ignores the backlight current 15.26.31 # unless the backlight is set to *never* shut off. 15.26.35 # Which is a good approximation, really 15.26.57 # if the backlight has a timeout at all,then it's likely to be on very infrequently, and thus probably won't make much difference 15.26.58 # hm, that won't fit different codecs well at all 15.27.09 # so for most users it solely uses the CURRENT_NORMAL value 15.27.23 Nick evilnick_B_ is now known as evilnick_B (~0c140464@rockbox/staff/evilnick) 15.27.24 # which is someone's super long term average, usually computed using a codec with minimal/no boosting 15.28.22 # as i see it the problem with doing it from real current readings is mostly that when the user is *doing something* the current is basically irrelevant 15.28.31 # since they are probably causing disk spinups, backlight on, etc 15.28.41 # * TheSeven considers some kind of x = ((x * 127) >> 7) + read_current() averaging mechanism with, let's say, 5 second resolution 15.29.16 # my math is not so hot 15.29.33 # what will that do if I have a playlist that alternates a codec that doesn't boost and one that boosts a very high percentage of the time? :) 15.29.56 # er, i mean, by album or similar 15.29.57 # not per track 15.30.04 # it will smooth that out a bit, but not completely 15.30.07 # so it does an hour or so at no boost, then an hour or so at high boost 15.30.12 # alternating for 20 hours :) 15.30.39 # this happens a lot for my player, at least (i have quite a lot of m4a files that have to boost a lot on ipodvideo) :( 15.30.59 # at the moment it overestimates remaining time, because its estimat eis based on mp3 15.31.29 Join toffe82 [0] (~chatzilla@12.169.218.14) 15.31.34 # but yeah, obviously there are a wide range of ways to average it out ;) 15.31.35 # with that method, the estimation would always slowly drift towards the current value 15.31.56 Join Guest23293 [0] (~n17ikh@host-69-59-126-212.nctv.com) 15.32.05 # so it will be oscillating a bit in your case, but the estimation should still be better than before 15.32.29 Quit liar (Ping timeout: 248 seconds) 15.32.40 # i'm imagining some way of taking user behaviour into account 15.32.57 # user behavior in terms of what? 15.33.08 # how much he is skipping around, having the backlight on, etc? 15.33.17 # well, the power profile of hte device while the user is listening to music only, is different to when they're actively using the UI 15.33.29 Quit n17ikh (Ping timeout: 268 seconds) 15.33.44 # when listening to music only a very long term averge works pretty well 15.33.57 # (i.e. battery-bench like usecases) 15.34.27 # and if you do it over a sufficiently long term it will give you a number based on the rough mix of codecs in your playlist so far, which is probably a good indicator of the remainder 15.34.44 # when rebuffering 32mb, for how long does the drive usually spin? 15.34.50 # er 15.34.54 # not long. 15.35.12 # so a 5 second resolution might be not enough? 15.36.06 # 5 seconds seems veyr unlikely to catch enough of the disk spinning to account for it, yeah 15.36.36 # so let's do it on a second base 15.37.15 # how fast do we want old measurements to decay? 15.37.52 # stopped to buffer full on ipodvideo64mb takes about 9 seconds btw 15.38.01 # and i think rebuffering would be slightly faster 15.38.19 # most of the players have only half that big a buffer, also 15.38.47 # I really don't kow 15.38.57 # I'm just pondering a more complex method than sampling+averaging 15.39.40 # e.g. extend the current system to know how much current is drawn by disk spinup, and try and keep track of how often we rebuffer 15.40.05 # that would need to know the bitrates of tracks in advance 15.40.17 # a sampling and averaging algorithm will probably do better 15.40.35 # no it wouldn't 15.40.43 # you guess based on history 15.40.58 # you don't have data about the future in any case 15.41.10 # so we can at least try to make assumtions based on history 15.41.23 # no, but you are losing a lot of data about the *present* by just averaging samples 15.41.48 # well, those samples are weighed 15.41.57 # if i fiddle with a game for half an hour then exit it and turn on hold, then the past is probably now irrelevant 15.41.58 # the newest ones have the highest weight 15.42.03 # because we're back to just playing music 15.42.10 # and the screen is off 15.42.17 # and yes, it'll pick that up over time 15.42.26 # well, but the user will probably continue playing games another half an hour later 15.42.30 # but how fast are you gonna have it decay? 15.42.43 # if you have it decay quickly then it will sawtooth around rebuffers 15.42.47 # the history-based estimate would take that into account 15.43.02 # if you have it decay slowly then it will overestimate consumption after the UI stops being used for a long time 15.43.06 # yes, it will always sawtooth a bit 15.43.43 # and i see no reason why it should overestimate comsumption when decaying slowly 15.43.43 # yah. but my point is that we *know* why it's changing 15.44.03 # the upward spike on every rebuffer is not a mysterious factor, we initiated it 15.44.19 # (and we know when it's coming, maybe even 30 minutes in advance) :) 15.44.27 # if that spike is small enough, it would just don't care about it 15.44.58 # we won't know when it's coming, if the user decides to mix things like flac and mp3 15.45.17 # we know when the next one is coming, almost always 15.45.17 # that would cause estimation spikes 15.45.22 # (except when people skip tracks) 15.45.27 # i somehow would rather like it to sawtooth than to spike 15.45.58 # do we really analyze the playback time of the data while rebuffering? 15.46.08 Quit Schmogel (Read error: Connection reset by peer) 15.46.10 # well, no 15.46.20 # ..yeah 15.46.21 # :) 15.46.23 # ahwell 15.46.24 # * Torne shurgs 15.46.29 # i'm not saying don't do it 15.46.41 # i'm just saying there is extra information we have thta might be able to be taken into account 15.47.08 # because we know the common use cases for the device, in a way that a general purpose computer OS doesn't 15.47.08 # i'm open to better proposals of course, but right now i can't see that taking those data into account would make the estimations any better 15.47.41 # *personally* i like it how it is, but i am not a very typical user, so that's not relevant 15.48.02 # how many people will actually look at that estimation? 15.48.04 # (I measured the current while playing different codecs, then averaged them based on the proportions in my music collectoin, and stuck that in the config) :) 15.48.37 # (so for my specific ipod the estimate is really good anyway, and would probably only get worse with dynamic estimation) :) 15.49.05 # i basically want to get rid of that 8000 minutes estimate for nano2g, but i'm hesitant to add it to that old crappy estimation framework 15.49.29 # so you are basically doing ultra-long-term estimates 15.49.53 # yah. i rarely use my player for anything but playback, so backlight or non-buffering disk spinups are irrelevant 15.50.17 # nothing makes a significant difference to my battery life other than boost % and rebuffer frequency 15.50.27 # and I have pretty good long temr estimates of both 15.51.18 # I guess you could actually keep long term stats, if you were really determined :) 15.51.25 # and work out the same thing without human intervention ;) 15.51.40 # nothing says you actually have to forget history when the battery gets recharged 15.52.06 Quit mitk (Quit: Leaving) 15.52.59 # i am probably overcomplicating this, anyway 15.53.11 # i suggest you write a decaying average thiny 15.53.19 # and test it out with various parameters :0 15.54.04 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.54.22 # but also, you should probably put estimates in for nano2g in the current scheme 15.54.32 Quit RoronoaZoro (Ping timeout: 264 seconds) 15.54.39 # because it does work reasonably well for people who don't play lossless files and don't use the UI very much. 15.54.48 # :) 15.56.58 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 15.57.03 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 15.57.18 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 16.01.36 Quit Guest23293 () 16.03.24 Join bieber [0] (~bieber@132.170.43.96) 16.06.55 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 16.09.33 Quit bieber (Quit: Leaving) 16.18.58 Join Buschel [0] (~c2795aa3@giant.haxx.se) 16.20.15 Quit evilnick_B (Ping timeout: 252 seconds) 16.20.42 # Torne/TheSeven: Take a look at FS #10890 "Dynamic runtime estimation". This patch also uses a lowpass-filter for the current consumption -- with a time constant of about 20 minutes, shorter time constants lead to alternating runtime estimations. 16.22.07 Quit Buschel (Client Quit) 16.22.34 Quit zOxta (Ping timeout: 240 seconds) 16.22.53 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 16.26.16 Join zOxta [0] (~email@41.131.0.90) 16.45.30 # something like linky for wikipedia would be nice for FS numbers 16.45.54 # (a bot that detects all FS#numbers and posts URLs to them) 16.46.15 Join RoronoaZoro [0] (~vijayss@202.3.77.11) 16.48.29 # Buschel: that's basically what I was thinking about 16.54.06 Quit wodz (Quit: Leaving) 16.55.46 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.02.55 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 17.06.17 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 17.11.25 # gevaerts: I don't know how you managed to break HID but with the new patches, I can turn the wheel of e200 a long time without any problem. I also wait several minutes as you said but it didn't break. 17.11.42 # pamaury: while transferring data at the same time> 17.11.43 # ? 17.12.12 # yes, dd if=/dev/sdb of=/dev/null bs=128k 17.14.05 Join Strife89 [0] (~michael@168.16.237.214) 17.18.18 *** Saving seen data "./dancer.seen" 17.19.14 Quit robin0800 (Remote host closed the connection) 17.20.16 Join Darkknight512 [0] (~63e16e06@giant.haxx.se) 17.21.22 # gevaerts: did you try you usb indicator ? 17.21.27 # *your 17.22.36 Quit Darkknight512 (Client Quit) 17.22.46 Join Darkknight512 [0] (~63e16e06@giant.haxx.se) 17.23.51 # no 17.25.44 # /* Sansa can't be powered off while charging */ 17.25.48 # /* #define HAVE_POWEROFF_WHILE_CHARGING */ 17.26.10 # Any reason for this? OF allows poweroff while charging apparently... (on my C200v2) 17.26.23 # is it really off, or just turning off the screen, or some kind of sleep mode? 17.26.29 # The reason is right there 17.26.44 # Any reason for that statement I mean 17.26.55 # This might be inherited from the v1s 17.26.56 Join _silentAssassin [0] (~mrigesh@iws3.iiita.ac.in) 17.26.57 # It doesn't say why it's supposed to be not allow and OF allows it 17.27.00 # Er, presumably because whoever did the port believed they couldn't be powered off while charging 17.27.14 Nick _silentAssassin is now known as animAgus (~mrigesh@iws3.iiita.ac.in) 17.27.34 # when turned off (from rockbox) does it turn itself on when you connect power? 17.27.40 # if so that suggests they are almost certainly right :) 17.28.20 # (also, if you boot the OF, start charging, then power off, then power on again, does it actually boot up from scratch and start rockbox? or does it just resume the OF?) 17.28.42 # gevaerts: (I'm sure I already asked you) Are you working on usb host ? which devices support it ? (and which are still on the market) 17.29.32 # pamaury: have a look at some old gsoc ideas pages. I think I proposed that last year 17.30.48 # Torne: It boots OF, but presumably that's because dualboot can't distinguish between just charging (usb data lines not connected) and usb data connection. TODO: Verify using modified dualboot... 17.31.04 # ranma: is it really booting up, though 17.31.05 # ? 17.31.34 # It shows the sandisk bootloader, but as said, pending real confirmation. 17.32.12 # well, try it 17.32.26 # if you uncomment that define, it will stop preventing you from powering off 17.32.37 # if you then find it just turns itself straight back on again, then it doesn't work. 17.33.00 # And yes, when power is connected it turns on (presumably because it will only change when it is on), but it _can_ be turned off (showing the normal sandisk goodbye screen) and then stays off until I press power of insert usb. 17.33.14 # Make that reinsert. 17.33.34 # Ok, I'll try a rockbox image with #define HAVE_POWEROFF_WHILE_CHARGING 17.33.44 # right, so try it. but just because it works in the OF doesn't mean it will work in rockbox, on many targets we handle power differently 17.34.09 # I would say that if it doesn't charge while off, we shouldn't allow it to be turned off while the cable's connected. 17.34.23 # That's just a recipe for people who are used to players that *can* charge while off to have dead players in the morning 17.34.27 # well, that too. is it actually charging :) 17.35.14 # Llorean: At least it would be nice to show an info message to that extent in the GUI. 17.35.54 # I was wondering before why I couldn't poweroff properly sometimes until I realized it's only with charger connected... 17.36.11 # Anyway, all that define does is stop you powering off. 17.36.18 # er, the lack of it, i mean 17.36.37 # Yeah, I figured that much 17.36.37 # so if you add it back and it behaves fine, and you can verify that it does indeed still charge while it's like that, then let us know and we can change it in svn 17.45.32 # Ok, for one thing it stays off when I power off with the define uncommented. The datasheet says "automatic 50mA trickle charging" in the overview, need to test that... 17.50.57 Join mitk [0] (~mitk@chello089078013146.chello.pl) 17.51.17 Nick fidencio[AWAY] is now known as fidencio (~fidencio@li113-135.members.linode.com) 17.53.12 Quit petur (Quit: *plop*) 17.54.22 Quit pamaury (Remote host closed the connection) 17.55.00 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 18.00.47 Join liar [0] (~liar@213162073039.public.t-mobile.at) 18.09.57 Join Schmogel [0] (~Miranda@p3EE21FE6.dip0.t-ipconnect.de) 18.11.04 Join CGL [0] (~CGL@190.79.148.8) 18.11.24 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-xnalgswwbclxclwn) 18.11.36 # the AMS players have software controlled charging, so you won't be able to charge with the player off 18.12.04 # ah :) 18.15.14 # is it normal that the SBS flashes on and off when splashes and the like are happening? 18.16.21 # my player is doing the committing datbase super long splash 18.16.29 # which i guess is a bunch of shorter ones in a row 18.16.41 # and the statusbar is flashing nice and regularly ;) 18.17.34 Join Lear [0] (chatzilla@rockbox/developer/lear) 18.20.51 Quit kugel (Remote host closed the connection) 18.23.08 # * Torne boggles as he notices Album Artist in the database, and was sure that didn't used to be there, but no, svn says it's been there for years. 18.30.59 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.33.07 Join xiainx [0] (xiainx@wpa071186.Wireless.McGill.CA) 18.34.20 Join petur [0] (~peter@rockbox/developer/petur) 18.35.27 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 18.40.49 Quit jgarvey (Ping timeout: 265 seconds) 18.44.27 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 18.45.18 Quit komputes (Ping timeout: 258 seconds) 18.46.13 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 18.46.51 # * jae thinks that if SVN speaks to you, it may be a good idea to go see a doctor 18.46.55 # ;) 18.50.00 Quit Luca_S (Quit: CGI:IRC (EOF)) 18.53.30 Quit jae (Quit: leaving) 18.53.37 Join jae [0] (~jae@jaerhard.com) 18.55.33 Quit jae (Client Quit) 18.55.38 Join funman [0] (~fun@rockbox/developer/funman) 18.55.58 Join Kitr88 [0] (~Kitr88@BSN-182-5-16.dial-up.dsl.siol.net) 18.56.34 Quit DerPapst (Quit: Leaving.) 18.57.48 Quit Kitar|st (Ping timeout: 248 seconds) 19.00.39 Quit Kitr88 (Ping timeout: 276 seconds) 19.03.28 Quit swilde (Quit: ERC Version 5.3 (IRC client for Emacs)) 19.04.37 # Torne: is there a reason why STORAGE_ALIGN_MASK isn't using CACHEALIGN macros ? 19.04.49 # funman: because nobody involved in 9708 noticed them 19.05.05 # o 19.05.07 # ok* 19.05.08 # so, i guess i actually mean "no" :0 19.05.11 # feel free to change it 19.05.17 # in fact you are encouraged to do so :) 19.05.24 # well i could certainly 19.05.47 Join Kitar|st [0] (Kitr88@BSN-142-107-58.dial-up.dsl.siol.net) 19.05.49 # It might be better if it was more than just a mask defined, also 19.05.51 # but so far only PP defines PROC_NEEDS_CACHEALIGN, i need to figure why (perhaps something to do with the COP) 19.06.09 # Well, only PP defines STORAGE_ALIGN_MASK 19.06.13 # so.. yeah 19.06.15 # and ipodnano2g 19.06.35 # Oh. yeah, i suggested to TheSeven he could reuse the 9708 code for that 19.06.41 # Well, define it on nano2g 19.06.43 # and you don't know about my plan for sansa AMS 19.06.47 # Yah 19.06.59 # I just mean, is there any reason not to have the cachealign stuff defined on every target with a cache? 19.07.03 # right but PROC_NEEDS_CACHEALIGN has other implications so i don't want to enable it blindly 19.07.06 # Oh, hm 19.07.18 # i guess it actually goes and aligns a bunch of stuff, rihgt. 19.07.25 # pardon me, i've been at work for too long ;) 19.07.40 # hm 19.07.46 Quit kunal (Quit: Ex-Chat) 19.08.00 Join kunal [0] (~kunal@121.242.23.197) 19.08.01 # I suspect the "right" answer is to have a stnadard way of specifying what cache alignment *is* for a given platform 19.08.02 # the comment in mpegplayer makes me think this is needed for dual core 19.08.07 # i.e. 16-byte-aligned, 32-byte-aligned 19.08.23 # and then to have PROC_NEEDS_CACHEALIGN for whatever it's used for now, to actually make those things aligned 19.08.26 Quit TheSeven (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) 19.08.43 # and define STORAGE_ALIGN_WHATEVER for platforms that benefit from storage_* calls being aligned 19.08.53 # yup 19.08.56 # such that htey are enable-able independantly 19.09.02 # but get their definition of alignment from the same place. 19.09.16 # btw grep STORAGE_ALIGN_MASK only shows buffering.c, calls in fat.c are already aligned? 19.09.26 # no, i've not gotten around to fixing anywhere else 19.09.36 # normal non-buffering accesses are mostly *not* aligned atm 19.09.38 # so DMA is not used 19.09.47 # that's one of the things that's sitll left to do 19.10.03 # I have half of a patch to track down unaligned accesses using the return address intrinsic, but haven't gotten around to doing it yet 19.10.59 # fat.c is not quite the only place where it would be useful 19.11.06 # there's things like the image loaders for album art, etc 19.11.19 # so i was gonna write a thing that tracks them all down for me and then fix them en masse :) 19.11.26 Join captainewkl [0] (~2669ecc2@gateway/web/freenode/x-apafdgsfafgtuhih) 19.11.46 # the main concern was just to do buffering because that's the primary source of large accesses :) 19.11.49 Join webguest63 [0] (~ad1ad68d@giant.haxx.se) 19.12.10 # yup 19.12.15 # again if you wanna go and align all the buffers in fat.c please do ;) 19.12.47 # i need to modify the AMS sd driver(s) because now they use an aligned extra buffer 19.12.48 # if i get around to all this before anyone else, i will do it as above now that I am aware of the cachealign stuff 19.13.00 # if someone else does it first then goody for them :) 19.17.25 Part RoronoaZoro ("Leaving") 19.17.26 # but yeah thanks for pointing it out, i hadn't noticed. 19.17.57 # New commit by 03funman (r25330): mpegplayer: align video output data structure only on multicore 19.18.06 # thanks for the work ^^ 19.18.21 *** Saving seen data "./dancer.seen" 19.18.21 # psh, dreamlayers did most of the work :0 19.18.24 # but he seems to have vanished 19.18.48 # anyway time for me to go, seeya. 19.19.13 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 19.22.50 Quit webguest63 (Quit: CGI:IRC) 19.24.35 Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) 19.24.35 Quit DataGhost (Changing host) 19.24.35 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 19.26.08 # TheSeven, Torne: http://pastie.org/886989 19.26.40 # hm actually STORAGE_ALIGN_MASK could go in system.h with other alignement attributes 19.28.32 # http://pastie.org/886993 19.34.23 Join Luca_S [0] (~5712526b@giant.haxx.se) 19.35.02 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 19.35.35 Quit mitk (Quit: Leaving) 19.36.48 Quit CGL (Quit: Saliendo) 19.37.19 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 19.37.37 # linuxstb: Both irivers check REC for booting into the OF. The iAudios don't have the problem since they're single boot 19.37.52 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 19.38.23 Join RoronoaZoro [0] (~vijayss@202.3.77.11) 19.43.06 Join Tomis [0] (~Tomis@70.134.88.172) 19.43.45 Quit xiainx (Ping timeout: 252 seconds) 19.44.33 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 19.45.30 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 19.49.17 Join komputes [0] (~komputes@ubuntu/member/komputes) 19.51.00 # amiconn: I thought the OF on the irivers also checked that the "power" (play) button was being held when it was being started? Am I mis-remembering? 19.51.27 # Iirc it does, but I'm not 100% sure 19.52.02 # Who uses the OF when (s)he has rockbox installed? 19.52.25 # funman: Can you tag the Clipv2/Clip+ bootloaders in SVN? Also, they need manuals (or the clipv1 manual needs changing), as the installation instructions contain links to the bootloader to download, so are currently wrong. 19.52.32 # amiconn: Exactly. That's why I can't remember... 19.52.39 # linuxstb: ah i forgot to do that after they've been tested 19.52.47 # thanks for reminding 19.52.53 Join DerPapst [0] (~DerPapst@p5797C96D.dip.t-dialin.net) 19.53.07 # funman: Also, why are they called "-RC" ? If they're on the download server, then aren't they "1.0" by definition? 19.53.32 # they are RC because only a few people tested them so far 19.54.00 # Then why are they on the download server? IMO, either they're released, or they're not... 19.54.00 # Well, on the H300 there's one situation when you might want to use the OF: USB host 19.54.05 # my fuze still says RC too 19.54.46 # funman: Yes, I know. And they shouldn't be either (I've mentioned that in the past). 19.55.24 # i'm fine either way (1.0-RC or 1.0), i'll just need to rebuild them if we change the version number 19.57.25 # there's already a "bootloader_ams_v1" tag, i don't think "bootloader_amsv2_v1" would be fine 19.58.22 # Just call it bootloader_sansaclipv2_sansaclipp_v1 19.58.32 # (or whatever the official target names are) 19.59.59 # New commit by 03funman (r25331): Tag release v1 of Clipv2 and Clip+ bootloaders 20.00.52 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.01.03 Quit stripwax (Client Quit) 20.02.26 # Clipv1 bootloader says "Boot Ver. 1.0", Clipv2/+ say "Boot 1.0-RC" and e200v2/fuzev1 say "Boot Ver. 1.0RC" 20.03.21 # iirc mc2739 had rebuilt fuzev1/e200v2 bootloaders to change the version string, dunno what happened 20.04.13 # Wouldn't it make sense to test the actual binaries being released, rather than testing, then recompiling to change the version string? 20.04.54 # * linuxstb always did it that way for ipod bootloaders when he released them 20.05.31 # linuxstb: i didn't say they hadn't been tested 20.07.55 # I'm not sure what you mean. I'm suggesting you never build binaries with "1.0-RC" in the version string, but build them with "1.0" instead, which are then tested before being put on the download server. 20.08.05 Join moos [0] (moos@rockbox/staff/moos) 20.09.02 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 20.09.11 # ah ok. I don't remember the discussion when we did the first "RC" bootloaders but I suppose we thought it could be needed to change them before a rockbox release for those models. 20.09.37 # include a build number in the version string? 20.09.55 # but then bootloader releases are independant from rockbox releases so we can perfectly release 1.0 bootloaders now 20.11.15 # * ender` installed the bootloader that was put online yesterday on his 8GB Clip v2 20.12.47 # funman: The pain now is that to fix the version string, you now need to go through another round of testing. Which is probably why it never happened for most of the other AMS Sansas. 20.12.52 Quit kaniini (Remote host closed the connection) 20.14.02 # ender`: a build number isn't release friendly, but if necessary you can know the svn revision used for the build from the svn tag 20.14.14 # svn fuze v1 bootloader has the same version numbering as regular rockbox. so rXXXXX-YYMMDD 20.14.35 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 20.14.39 # linuxstb: true, i could test clip+ & fuzev1 bootloaders, just need someone to test clipv2 & e200v2 ones 20.16.16 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 20.18.44 Quit flydutch (Quit: /* empty */) 20.19.01 # i wonder if flashing a Fuze v1 a lot causes some kind of wear. it's faster to reflash, turn off, turn on and boot rockbox then have the 'refreshing database' thing 20.20.14 # wear levelling should be handled by SD card 20.20.55 # firmware is on the internal sd card? 20.21.55 # yes 20.23.41 # i suppose it is rather off-topic, other than making rockbox use on samsa's more convenient until there is rockbox usb support, but would it be possible to disable the OF's "refreshing database" behavior? 20.27.30 # funman: Sorry to be a pain, but there are also no manuals for the clip+ and clipv2... 20.27.45 Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 20.29.37 Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 20.30.39 Quit Farthen (Remote host closed the connection) 20.31.02 Quit planetbeing (Ping timeout: 252 seconds) 20.31.03 Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 20.31.07 # i'm not going to work on the manuals now 20.32.16 # i think they should be removed from manual webpage 20.32.54 Quit Darkknight512 (Quit: CGI:IRC) 20.33.01 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 20.33.19 # topik: Do you know how to disable it? 20.34.45 # no, i was hoping someone who disassembled the OF had come across it 20.35.37 # topik: on the 1st gen sansas we found out that info was stored on the nand by dumping the contents between runs 20.35.39 Quit phanboy4 (Read error: Connection reset by peer) 20.37.51 # funman: I'll give the manual a shot... 20.40.23 # thanks 20.40.35 # Don't kill it entirely! 20.40.39 # who can test a bootloader on e200v2 and clipv2 ? 20.41.48 # Bagder: "that info" being the device's decision to do the "rebuilding database" action? 20.41.56 # yes 20.41.58 # Bagder: I'd be interested in disabling the 'refreshing database' feature on my fuzev2... how can I dump the nand content? 20.42.19 # we just dd'ed it 20.50.11 Quit planetbeing (Quit: planetbeing) 20.51.12 # the OF must respond in its code to the settings on the nand though 20.51.55 # if i had any clue, i'd say the OF could be patched to ignore the nand value and not start refreshing 20.52.10 # yes, but in the days we could just set the "right" value to trick the OF 20.53.02 # that's clever too 20.54.58 # ender`: would you try a clipv2 bootloader ? just check that it works and that it prints "Boot Ver. 1.0" 20.58.56 # funman: sure 20.59.20 Join perfectdrug [0] (~marko@p5B0EEC1C.dip.t-dialin.net) 20.59.23 # i can't upload files, just give me your email in private 21.02.54 Quit leavittx_ (Ping timeout: 258 seconds) 21.02.54 Quit leavittx (Ping timeout: 258 seconds) 21.03.48 Quit Strife89 (Quit: Leaving work.) 21.05.11 Quit perfectdrug (Quit: Leaving.) 21.06.28 # * ender` 's playing with http://eternallybored.org/Image2.png 21.07.05 Quit n17ikh (Ping timeout: 268 seconds) 21.10.55 # "best viewed in opera 3.x on windows 3.11" 21.10.57 # Am I right in thinking the clipv1 and clipv2 look the same, but the clip+ is different? 21.11.06 # linuxstb: yes 21.11.08 Join b0hoon [0] (~quassel@xdsl-7253.bielsko.dialog.net.pl) 21.11.36 # New commit by 03dave (r25332): Initial manuals for clipv2 and clip+, with corrected installation instructions. The player picture in Chapter 3 is the same as the Clipv1 for both ... 21.11.38 # Clipv1 & v2 are just similar to e200v1 & v2 : different firmware, same marketing from Sandisk 21.12.31 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 21.12.33 # Bagder: What needs doing to make the clipv2 and clipplus manuals "live" ? The manuals page currently point to the clipv1 manual for all three variations, but now the clipv2 and clip+ have their own. 21.14.46 # * linuxstb guesses tools/builds.pm is one thing? 21.14.59 Quit liar (Ping timeout: 258 seconds) 21.15.30 # yes, it should be fairly automatic 21.16.05 # it checks for a trunk/manual/platform/$name.tex file 21.16.21 Join leavittx_ [0] (~leavittx@89.221.199.187) 21.16.27 Join leavittx [0] (~leavittx@89.221.199.187) 21.16.37 # New commit by 03dave (r25333): Sansa Clipv2 and Clip+ now have their own manuals. Also add "v1" to the label for the clipv1 21.16.56 # where $name is the model name OR the specific 'manual' field in build.pm 21.17.25 # OK, thanks. I've updated builds.pm. Anything else to do? 21.17.36 # that should be enough methinks 21.17.40 Quit pixelma (Disconnected by services) 21.17.40 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.17.53 Quit amiconn (Disconnected by services) 21.17.55 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.17.58 # * linuxstb sees the manual page has automagically updated... 21.18.00 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.18.17 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.18.25 *** Saving seen data "./dancer.seen" 21.18.30 # Bagder: Can you easily force a manual build? Or shall we just wait until tomorrow? 21.19.14 # it's better to just wait, it runs with a specific user in a specific path and it's not that easy to just build a specific one 21.19.17 # There's no real rush - at least now there are no install instructions, rather than the wrong ones. 21.20.06 # * linuxstb wonders if someone wants to rename the "sansaclip" target to "sansaclipv1"... 21.20.29 # linuxstb: same for fuze and e200? 21.21.02 # Err, yes. Although I would have thought the e200 existed when Zagor did the big rename? 21.21.09 # s/e200/e200v2/ 21.21.30 # btw if we have instructions in the manual we should remove the duplicate in wiki>SansaAMS and link to the manual instead 21.22.05 # funman: Yes, but we won't have manuals until tomorrow morning though. 21.22.33 # linuxstb: I see sansae200 sansam200 sansac200 sansaclip and sansafuze , all of them have a 'v2' model 21.23.31 # Also, I left it as it was, but the link for the clipv1/v2 firmware is (I think) pointing to an older thread on those forums. The link in the manual is http://forums.sandisk.com/sansa/board/message?board.id=clip&thread.id=15109 21.24.38 # we could just point to the clip board, but some users might get lost and not find the correct thread, so the link is bound to be obsolete one day or the other 21.24.56 # i changed the thread url the other day when updating the wiki 21.25.50 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 21.26.02 # It's in manual/getting_started/sansaAMS_install.tex if you (or someone else) wants to fix the manual. 21.33.21 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 21.33.54 # New commit by 03b0hoon (r25334): Packard Bell Vibe: add Simulator and CheckWPS to the build table 21.35.41 Quit kaniini (Read error: Connection reset by peer) 21.37.58 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 21.38.20 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 21.39.04 Join naag [0] (~harish@210.212.160.101) 21.41.56 # New commit by 03b0hoon (r25335): Packard Bell Vibe 500: correct the path to a proper one in rbutil (proper directory on the file server to the bootloader) 21.42.44 Join Strife89 [0] (~michael@adsl-220-102-96.mcn.bellsouth.net) 21.45.59 Quit zOxta (Ping timeout: 260 seconds) 21.46.52 Quit bmbl (Quit: Bye!) 21.49.11 Join perfectdrug [0] (~marko@p5B0EEC1C.dip.t-dialin.net) 21.50.48 # i'll send Bagder or Zagor the "1.0" fuze/clip+/clipv2/e200v2 bootloaders once the e200v2 one get tested 21.51.15 Quit funman (Quit: free(random());) 21.54.46 Join grawity [0] (grawity@wind.nullroute.eu.org) 21.54.52 # * grawity looks around. 21.56.26 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.57.39 Join CGL [0] (~CGL@190.79.148.8) 22.01.18 Quit Luca_S (Quit: CGI:IRC) 22.04.21 Quit grawity (Quit: Good night.) 22.06.47 Quit perfectdrug (Quit: Leaving.) 22.09.37 Join perfectdrug [0] (~marko@p5B0EEC1C.dip.t-dialin.net) 22.12.11 Quit fyrestorm (Read error: Connection reset by peer) 22.17.28 # domonoky: Was the "online services" SoC project your suggestion? 22.17.58 # linuxstb: jup, nobody objected to it :-) 22.18.37 # domonoky: I'm just wondering what you think the voice generating service would do? 22.18.50 # (that isn't done by the voice files we already make available) 22.19.34 # linuxstb: more languages and voices for example. 22.20.03 # Wouldn't it be better to generate them all nightly - i.e. expand the current system? 22.20.10 # but i am more interested in other services like fm-presets, or what ever a student can imagine :-) 22.21.02 # linuxstb: sure, thats also possible. if the combination doesnt go up too much. 22.22.22 # but it would also be good if a voicefile service could provide correct voice files for specific revisions (like rbutil does). And then it gets much files to build nightly :-) 22.23.26 # Bagder: Do you know how long it takes to generate all the voice files? I'm guessing the caching makes things quite fast? 22.24.47 # linuxstb: but currently we only provide english with one voice. imagine 30 languages with 5-10 different voices each, and different speeds etc :-) 22.25.23 # Do we need both an online service and rbutil though? 22.25.47 # I'm guessing rbutil is potentially better, as it can use commercial voices. 22.26.13 # yes, rbutil will always be better, but it has accessibility problems :-) 22.26.34 # So the solution to rbutils accessibility problems is an online voice service? ;) 22.26.59 # Could that be an SoC project? 22.27.11 # but i am really more keen on other webservices, i just added the voice one too for completeness :-) 22.27.13 # Or is it fundamental problems with Qt that we can't really solve? 22.27.29 # * linuxstb assumes it's not too late to add new project ideas... 22.27.52 # last time i researched the accessibilty problems, it always was a Qt problem. and thats not easy to fix. so nothing for SoC. 22.29.04 # the "workaround" to make rbutil speak itself would be a better SoC project, but maybe thats too cracy :-) 22.29.05 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 22.29.52 # And then an online service to generate voicefiles for rbutil? ;) 22.30.05 # hehe 22.30.58 # it wouldnt need voicefiles, it has support for many different tts already. Only some magic need to catch things under focus and speak its title/content. 22.31.22 # But IMO accessibility for rbutil seems quite important - so it could be an SoC project, where the student does as much as can be done via Qt, and then implements workarounds in other places. 22.32.27 # i dont know if that is a good project, so many possible blockers. 22.33.00 # s/blockers/opportunities for the student to show initiative/ 22.33.01 # For some issues, i posted workarounds in the tracker, but we didnt commit it, because they are too hackish :-) 22.33.29 # But OK, you know the issues far better than me (I don't have a clue...) 22.33.46 Join xiainx [0] (xiainx@wpa071073.Wireless.McGill.CA) 22.33.54 # linuxstb: with that reasoning, "Port rockbox to the Zune" would be a perfect project :) 22.33.54 # but i would love some SoC project with rbutil, just can image a good defined project at moment. 22.34.06 # gevaerts: I'll go and add it... 22.34.26 # +t 22.35.37 # Maybe the online services could have the "integration with rbutil" parts included as well - so at least the student will get involved with rbutil, and may hang around after the summer doing other things... 22.36.16 Quit kunal (Quit: Ex-Chat) 22.37.10 # Maybe I'm underestimating the complexity, but the online services all seem relatively straightforward. Including rbutil work adds some more (and useful) work to them. 22.42.39 # well, the project says to create a few new services from scracth 22.42.53 # so, if you're going to create two entirely new services from scratch, that could take 3 months or so... 22.47.30 Quit Strife89 (Quit: Going, going, gone for now.) 22.49.18 Quit naag (Quit: Leaving.) 22.51.28 Quit Adubb () 22.51.44 Join Adubb [0] (~aldubuc@67.201.160.144) 22.54.15 Nick fidencio is now known as fidencio[AWAY] (~fidencio@li113-135.members.linode.com) 22.55.11 Quit arbingordon (Read error: Connection reset by peer) 22.55.35 Join arbingordon [0] (~w@unaffiliated/arbingordon) 22.58.17 Quit Zagor (Quit: Clint excited) 23.09.52 Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) 23.13.34 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 23.13.59 Quit kaniini (Remote host closed the connection) 23.15.30 Join kaniini [0] (~quassel@dyn75-70.yok.fi) 23.15.52 Quit evilnick_B (Quit: Page closed) 23.17.55 Quit CGL (Quit: Saliendo) 23.18.28 *** Saving seen data "./dancer.seen" 23.18.30 Quit petur (Quit: Zzzzzz) 23.18.41 # what is about FS#2660 ? seems to be the oldest still open bug and I'm wondering if it was still valid 23.19.37 # xiainx: remember, that this is just a suggested goal. So the actual project a student does could get different goals. 23.21.08 # xiainx: so if you can convince us, that for example 1 service + rbutil integration would be a worthwile gsoc project, all is fine :-) 23.23.13 Quit jgarvey (Quit: Leaving) 23.23.33 Quit captainewkl (Quit: Page closed) 23.27.23 # yes, well I guess it depends to some degree on the complexity/quality of the service, doesn't it? 23.29.30 # sure 23.30.48 # if the students wants to create some complex/big project, he perhaps will only work on this. 23.31.19 # s/this/one 23.32.05 # or maybe he wants to work on different small thing, and so plans to create many small service.. all is possible. 23.32.10 Join jae [0] (~jae@jaerhard.com) 23.32.42 # Yeah, I'm actually kind of interested in that project 23.32.51 # They just have to convince us in their application (or even better here in irc) that, what they plan is worthwile for gsoc. 23.34.03 Quit jae (Client Quit) 23.34.31 Join jae [0] (~jae@jaerhard.com) 23.34.35 # xiainx: do you have any specific interests for this services project, any specific preferences ? 23.34.45 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 23.35.06 # well, I'm kind of interested in the fmpresets database one, and/or the voicefiles one 23.35.18 # the voicefiles doesn't seem like it would be terribly complicated 23.35.44 Quit jae (Client Quit) 23.36.10 Join jae [0] (~jae@jaerhard.com) 23.36.17 # xiainx: voicefiles can get pretty complicated if you want all the bells and whistles :-) ( i did the voice generation in rbutil) 23.36.30 # Oh, really? 23.36.46 # What exactly are these voicefiles for? RB's tts system? 23.37.03 # RB doesn't have a tts system :) 23.37.07 # yet 23.37.27 # maybe, but we would hardly be supplying voice files for something that doesn't exist 23.37.29 # xiainx: its rockboxs tts replacement. prerecorded audiofiles with menucontent. 23.37.33 Quit jae (Client Quit) 23.37.37 # Ok 23.37.53 # topik: On the c200v1, where we can't intercept the OF in the necessary way to stop it from updating its database, it helps to make the SYSTEM folder write protected 23.37.54 Join jae [0] (~jae@jaerhard.com) 23.38.00 # xiainx: rockbox can use this to readout its menus. (there is also a similar thing for files and folders) 23.38.12 # Right, okay, I see 23.38.26 # The OF will comlain that there is no space to update the database, but that only takes a few seconds. Maybe the trick also works on the later sansas 23.38.27 # So, you could use a tts system to generate the sound files, and store those using a database system? 23.39.26 # but to generate voices we already have different tools. usersubmitted /generated fmpresets are much more interesting, because there is no good solution for that available (only fmpresets in the wiki). 23.40.16 # Keep in mind also that this is three months full time work 23.40.34 # xiainx: yes, we use tts systems to generate those prerecorded files, and assemble the to a voicefile. the webservice would ofcourse do something similar. 23.42.21 # Okay, so is the fmpresets project doable in 3 months, and if so, would there be time for more, by your estimation? 23.42.22 # * domonoky thinks fmpresets and rbutil integration of this could be enough work for gsoc (depends a bit on how a potential fmpreset site would work). 23.42.23 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 23.42.37 # Right, that's what I'm wondering, is how much to aim to accomplish! 23.43.00 # xiainx: fmpresets service alone is probably not enough work. 23.43.35 # Ok 23.44.06 # at least a fmpreset site with usersubmitted content. Maybe it gets more work if it would use a potential global fm frequency db (dont know if they exist) 23.44.17 Quit DerPapst (Quit: Leaving.) 23.44.26 # a website for fm presets shouldn't be much work if it doesn't include fancy features 23.44.52 # and integration in rbutil shouldn't be much work either. 23.46.08 # bluebrother: so you think there's time to tackle another project as well over the summer? 23.46.19 # definitely. 23.46.35 Quit jae (Quit: leaving) 23.46.49 # the fm presets site (assuming its simply a site user can submit their preset files to similar to the themes site) is nothing complex. 23.47.02 # domonoky: Something like.... http://qrg.broker.freenet6.net 23.47.14 Join jae [0] (~jae@jaerhard.com) 23.47.16 # domonoky: That seems to have mostly German frequencies though 23.47.39 # bluebrother: Okay, yeah like I said, it depends a lot on how powerful/feature-ful you want it to be 23.48.07 # if its to retrieve data from some global database it obviously also depends on the way they provide the information and if they provide an API for accessing that. 23.48.38 # xiainx: yes, something like that as sources to get the frequency to put into fmpresets. Probably needs a bit research to find good dbs as sources. 23.49.29 # well, from my point of view having a page users can upload their presets, list available presets and batch-download them is the most important features. Plus rbutil integration. 23.49.45 # further features are nice but not that important IMO. 23.50.03 # Okay 23.51.20 Part b0hoon ("GTG. Bye.") 23.51.42 # but the features I mentioned aren't hard. I'd expect something around 2 weeks for that, at least for the functionality. 23.51.58 # Okay, 2 weeks isn't very long! 23.52.46 # * domonoky would plan 4 weeks with rbutil, you have to learn new stuff, and will probably hunt for some nasty bugs sometime. 23.52.52 # no, but it isn't a complex or hard task either. 23.53.12 # 4 additional weeks, or 4 weeks total for the whole thing? 23.53.26 # 4 total 23.53.29 # Okay 23.53.49 # theme site integration for rbutil was done in less than 2 weeks :) 23.53.50 # but thats ofcourse my view. others might see it different :-) 23.54.20 # time estimations of course depend on the knowledge of the programmer :) 23.54.25 # bluebrother: not true. it was done first by me, and redone by you sometime later :-) 23.54.51 # domonoky: well, as the Qt version was a complete rewrite I didn't count that at all. 23.55.31 # :-) 23.56.06 # and then what would the rest of the summer be spent doing? the tts thing? themepage? 23.56.29 # if we'd count the wx version rbutil has been quite a lot of work. It has done for the Qt version too, but summing that up would make it even noticably more :) 23.56.38 Quit bertrik (Quit: De groeten) 23.56.51 # translationpages improvements would be nice too. 23.57.10 # what needs to be done about translate.themes.org? 23.57.24 # we want bluebrothers rbutil translationpage finsihed and integrated into translate.themes.org :-) 23.57.53 # and i am sure there a things to improve at the core translationpage too, if you look closely :-) 23.58.07 # * bluebrother plans looking into that during the next train trip :) 23.58.39 # hmm, rbutilqt is already 2 3/4 years old. Time files ...