| 00:00:07 | kugel | I seem to remember we do that on other targets as well |
| 00:00:17 | ozzo | maybe I should just shut up xD |
| 00:00:25 | Zagor | 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 | linuxstb | Yes, I said that - the "clipv2" and "clip+" manual links point to the clipv1 manual. |
| 00:00:55 | webguest77 | Hi, I'd like to ask a question about the way my RiPod is behaving... |
| 00:01:01 | ozzo | got you wrong hehe |
| 00:01:06 | linuxstb | Your "RiPod" ? |
| 00:01:10 | webguest77 | iPod. |
| 00:01:25 | ozzo | lol nice name |
| 00:01:35 | webguest77 | Sorry, I'm using Chromeand the "Waiting" message is blocking me reading what I write |
| 00:01:44 | webguest77 | So there may be some typos |
| 00:01:48 | webguest77 | Anyways, |
| 00:01:59 | webguest77 | I have an iPod Nano, 1st gen. |
| 00:02:16 | webguest77 | It had the lates softare when I installed Rockbox. |
| 00:02:26 | webguest77 | When I did, I deleted the system files. |
| 00:02:39 | webguest77 | For the iPod's orginal software, I mean. |
| 00:02:42 | linuxstb | You mean the "iPod_Control" folder? |
| 00:02:46 | webguest77 | Yeah. |
| 00:02:57 | S_a_i_n_t | Oh.... |
| 00:02:59 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 00:03:01 | webguest77 | I know it comes back when I open iTumes, and I've deleted it before. |
| 00:03:26 | webguest77 | But sometimes it comes back after I make sure the folder uis gone and unplug it. |
| 00:03:37 | Torne | if you boot the original firmware it will get recreated also |
| 00:03:50 | webguest77 | So what should I do? |
| 00:03:55 | Torne | 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 | Torne | it doesn't matter, though |
| 00:04:22 | webguest77 | No, I mean the original software boots INSTEAD of Rockbox |
| 00:04:25 | S_a_i_n_t | If you're asking about "how can I stop this happening" don't have/use the Apple of. |
| 00:04:36 | Torne | Thats nothing to do with the iPod_Control folder |
| 00:04:43 | Torne | the firmware is not stored in there, that's just for settings |
| 00:04:52 | webguest77 | So how do I stop it? |
| 00:04:57 | stripwax | stop what |
| 00:05:10 | Torne | the original firmware boots if you have the hold switch turned on when you power the player on |
| 00:05:34 | webguest77 | So I shouldn't use the hold switch whevever the player is off? |
| 00:05:47 | Torne | hm? |
| 00:05:56 | Torne | turn off hold before you apply power ;) |
| 00:05:59 | Torne | then it will boot rockbox. |
| 00:06:01 | stripwax | 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 | webguest77 | I can't pwere the player on if the hold is oon, though. |
| 00:06:40 | S_a_i_n_t | Well...you can't power the player on if hold is on...can you? |
| 00:06:43 | stripwax | but if you connect usb power, yes, turn the hold switch off. |
| 00:06:50 | | Quit pamaury (Client Quit) |
| 00:06:51 | Torne | webguest77: connecting usb turns the player on |
| 00:07:02 | webguest77 | No, this happens without pplugging the thing into a computer. |
| 00:07:20 | S_a_i_n_t | there *may* be a similar bug... |
| 00:07:38 | S_a_i_n_t | As was said earlier, regarding the alarm. |
| 00:07:45 | webguest77 | I don't use the alarm |
| 00:07:51 | stripwax | webguest77 - how do you turn it on, if the hold switch is on ... ?? |
| 00:07:52 | Torne | does it turn on instantly into the original firmware? |
| 00:07:59 | Torne | or does it have to boot up for >60 seconds first? |
| 00:08:16 | stripwax | Torne - (if you see the Apple logo, but it boots up in <10 seconds, it's 'apple resume'...) |
| 00:08:26 | webguest77 | When I unplug it from the computer? |
| 00:08:31 | webguest77 | Or just any old time? |
| 00:08:43 | * | stripwax is super confused |
| 00:08:43 | Torne | 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 | webguest77 | No. |
| 00:08:53 | webguest77 | After |
| 00:09:03 | webguest77 | Wait, sorry, let me explain this. |
| 00:09:12 | stripwax | webguest77 - can you break it down step by step please |
| 00:09:37 | webguest77 | 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 | webguest77 | After unplug, it loads Rockbox just fine. |
| 00:09:56 | S_a_i_n_t | that *really* doesn;t matter... |
| 00:09:57 | | Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 00:10:16 | S_a_i_n_t | 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 | stripwax | 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 | stripwax | ipod_control is **NOT** 'the firmware files' |
| 00:10:47 | | Quit petur (Quit: Zzzz) |
| 00:11:01 | webguest77 | However, even after Rockbox loads then, I will try to boot it again sometime, and the old iPod firmware will load. |
| 00:11:20 | webguest77 | There are no files on the disk besides ".rockbox" and my music. |
| 00:11:34 | stripwax | it might be the alarm bug. |
| 00:11:45 | webguest77 | I DON'T USE THE ALARM. |
| 00:12:11 | stripwax | FS #11063 |
| 00:12:19 | Torne | it doesn't matter if you use the alarm. |
| 00:12:19 | stripwax | webguest77 - right, "IT IS A BUG" .. :-) |
| 00:12:25 | webguest77 | Also, note that I turn the hold switch off every time I go into Sleep mode. |
| 00:12:27 | Torne | the hardware sets the alarm on poweroff |
| 00:12:31 | | Part toffe82 |
| 00:12:34 | webguest77 | Oh. |
| 00:12:42 | stripwax | webguest77 - I saw something similar (hence the bug that I logged :-)) |
| 00:12:51 | webguest77 | So I shouldn't use the hold switch if the power is off? |
| 00:12:51 | Torne | the origianl firmware uses the hardware alarm for something quite different |
| 00:13:00 | Torne | also, what do you mean, go into sleep mode? |
| 00:13:03 | Torne | rockbox doesn't have a sleep mode. |
| 00:13:06 | webguest77 | Turn it off. |
| 00:13:19 | stripwax | webguest77 - it is supposed to work - but I have also seen the same symptom. What I think happens is: |
| 00:13:32 | stripwax | 1. you run rockbox, and then shut it down normally (via long press on PLAY). |
| 00:13:40 | webguest77 | Yes. |
| 00:13:54 | Torne | webguest77: yeah that's not sleep mode, that's just "off" |
| 00:14:00 | webguest77 | OK. |
| 00:14:08 | Torne | How long does it take to start the original firmware? |
| 00:14:09 | stripwax | 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 | Torne | a few seconds, or a minute or so? |
| 00:14:16 | webguest77 | Because the iPod firmware calls it "sleep" |
| 00:14:25 | stripwax | 4. the apple firmware gets bored (since I'm in bed), and shuts down (specifically, hibernates) later on |
| 00:14:26 | Torne | no, the ipod firmware *does* put it to sleep |
| 00:14:28 | Torne | *we* turn it off. |
| 00:14:38 | webguest77 | Less than a minute, but several seconds longer than normal. |
| 00:14:39 | Torne | they are different :) |
| 00:14:41 | stripwax | 5. I turn the hold switch to 'off' and turn on the ipod - it wakes up the ipod firmware |
| 00:15:03 | webguest77 | So this is an acknowledged bug. |
| 00:15:12 | stripwax | Torne - you've seen the bug I mentioned? (FS #11063)? |
| 00:15:17 | Torne | it's an unreproducable bug |
| 00:15:18 | webguest77 | Is there a patch or anything, or have you not been able to fix it? |
| 00:15:24 | webguest77 | OH, okay. |
| 00:15:28 | webguest77 | Thanks. |
| 00:15:30 | Torne | which we already spsecifically introduced code to prevent |
| 00:15:38 | Torne | and thus ther eis no way it should be possible for it to happen ;) |
| 00:15:41 | webguest77 | Hmmm... |
| 00:15:45 | * | stripwax goes HMM also |
| 00:15:52 | Torne | this happened while developing a different change |
| 00:15:54 | webguest77 | But I have the latest version, I think... |
| 00:16:10 | Torne | It doesn't matter what version you have ;) |
| 00:16:17 | Torne | This should not be possible in any version :) |
| 00:16:22 | Torne | so, yeah, i don't know how to fix it |
| 00:16:30 | stripwax | Torne - it does though, right? the whole shutdown thing was only changed recently |
| 00:16:42 | webguest77 | Okay, thanks. |
| 00:16:51 | Torne | stripwax: no, it doesn't.. the only vesion that doesn't set the alarm correctly on shutdown was in FS# |
| 00:16:58 | stripwax | webguest77 - what ipod model do you have? |
| 00:17:01 | Torne | it was never in svn |
| 00:17:07 | webguest77 | Nano, 1st gen |
| 00:17:15 | stripwax | Torne - I mean, before that patch was even submitted to svn, everything worked fine .... |
| 00:17:15 | webguest77 | Latest firmware |
| 00:17:32 | Torne | stripwax: yes, but everything works fine now :) |
| 00:17:34 | webguest77 | So there is a patch. |
| 00:17:39 | stripwax | Torne - err.. what? |
| 00:17:45 | Torne | webguest77: no. |
| 00:17:49 | stripwax | 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 | Torne | webguest77: a change was made to the way we shut ipods down, for a completely unrelated issue |
| 00:18:00 | stripwax | I am of the opinion that the patch doesn't quite do what it is supposed to do |
| 00:18:09 | webguest77 | OK. |
| 00:18:12 | Torne | webguest77: during development of that patch we got the behaviour you are getting |
| 00:18:16 | Torne | we fixed that before submitting the patch |
| 00:18:22 | | Quit domonoky (Read error: Connection reset by peer) |
| 00:18:26 | stripwax | and only you and I seem to still have a problem... |
| 00:18:30 | webguest77 | OK, I get it. |
| 00:18:35 | Torne | yah. a dozen or so peope tested that for 6+ months |
| 00:18:39 | Torne | without anyone having the problem :) |
| 00:18:47 | webguest77 | Well, thanks for the help... |
| 00:18:49 | Torne | and you are only the second person to report it since it was submitted |
| 00:18:54 | stripwax | well, it's an unreproducible bug, soooo .... |
| 00:18:55 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 00:18:58 | stripwax | :-) |
| 00:19:00 | Stephen__ | 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 | stripwax | 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 | Torne | Stephen__: no, there are lots of different models that fall under e200 |
| 00:19:40 | Torne | Stephen__: e250, e280, etc |
| 00:19:45 | Llorean | Stephen__: The clip has 3 versions, the e200 has 2 versions and the R model |
| 00:19:48 | Stephen__ | then should clip not be models aswell |
| 00:19:54 | Llorean | The clip has clip, clip+ and clipv2 |
| 00:20:04 | Torne | Stephen__: no, because they are sold as the same model and have no distinguishing features |
| 00:20:17 | Torne | Stephen__: the changes between v1 and v2 are internal and not visible to users |
| 00:20:19 | Stephen__ | ah right. just thought i'd bring it up |
| 00:20:32 | Stephen__ | thanks Torne & Llorean |
| 00:20:53 | | Quit wodz (Quit: Leaving) |
| 00:20:56 | Torne | unfortunately sandisk have changed the internals of some players without actually marketing it as a new model |
| 00:21:07 | Torne | which is bad for us ;) |
| 00:21:18 | Stephen__ | i wonder will we see a clip +v2 ? |
| 00:21:28 | stripwax | 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 | Torne | 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 | Torne | stripwax: i just cannot see how it can happen, is the issue |
| 00:21:55 | Llorean | stripwax: Is the clock set? |
| 00:22:01 | stripwax | I wonder if FS #10830 is related |
| 00:22:10 | stripwax | Llorean - rockbox reports the current time, yes |
| 00:22:10 | Stephen__ | it's great to have rockbox on a player that is still sold new |
| 00:22:11 | | Quit jgarvey (Quit: Leaving) |
| 00:22:16 | Torne | 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 | stripwax | Annoyingly, the debug screen cannot tell me if the alarm is 'set', it only lets me 'set' it or 'cancel' it. |
| 00:22:34 | Torne | 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 | Torne | 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 | stripwax | 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 | Torne | 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 | stripwax | let me check my apple os version |
| 00:23:46 | Llorean | Torne: Does it use whatever the RTC reports as the date + some constant, or a hard coded date? |
| 00:23:57 | Torne | Llorean: it sets it to the maximum thing the RTC will accept, i think |
| 00:24:02 | Torne | this is existing rockbox code |
| 00:24:04 | Torne | not new. |
| 00:24:22 | Torne | we do that anyway because there's no other way to tell whether you woke up by alarm or not |
| 00:24:31 | Torne | the OF bootloader in flash eats the bit in the PMIC that tells you why you woke up. |
| 00:24:40 | Torne | so, we have to rely on checking the alartm time to know if we woke up because of an alarm |
| 00:24:46 | Torne | if it's set to Crazy Future Time then we know we didn't ;) |
| 00:25:03 | Torne | this code gets run every time you disable the alarm |
| 00:25:16 | Torne | the shutdown patch just runs it on shutdown, if the alarm wasn't set by the user, as well |
| 00:25:43 | S_a_i_n_t | 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 | stripwax | S_a_i_n_t - haha |
| 00:26:02 | Torne | S_a_i_n_t: i'm prety sure it's a lot more than 10 years ;) |
| 00:26:09 | stripwax | 1.1.1 (apparently) |
| 00:26:13 | Torne | the comment in the code says whoever wrote that is assuming they will be dead |
| 00:26:14 | Torne | :) |
| 00:26:25 | S_a_i_n_t | hehehe |
| 00:26:37 | Torne | stripwax: but yes, it's possible your OF is resetting the alarm time |
| 00:26:39 | stripwax | well, hopefully they won't be, but the battery presumably will be :-) |
| 00:26:49 | Torne | stripwax: but i can't see why it would unless it also went into sleep |
| 00:26:50 | stripwax | Torne - ok |
| 00:26:53 | Torne | but it's difficult to tell |
| 00:27:11 | Torne | The whole boot/sleep/reboot/shutdown/etc mess in the flash bootloader is incomprehensible |
| 00:27:17 | stripwax | agreed |
| 00:27:31 | Torne | i've been disasembling it a bit but it's just vast beyond any reasonable need |
| 00:27:46 | Torne | amusingly there is an entire serial bootloader debug console in there |
| 00:27:53 | Torne | it's just implemented using Angel ICE |
| 00:27:59 | stripwax | 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 | Torne | so you can only access it over JTAG :) |
| 00:28:30 | Torne | stripwax: well, nobody but you and that guy is having that problem, tho |
| 00:28:36 | Torne | I'd love not to have this horrible hack |
| 00:28:55 | Torne | 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 | stripwax | presumably there's some specific parts of iram that contain magic values |
| 00:29:23 | Torne | yes |
| 00:29:30 | Torne | but that's not all |
| 00:29:34 | | Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) |
| 00:29:36 | Torne | it does a bunch of other crazy stuff also ;) |
| 00:29:37 | stripwax | have we tried zeroing out iram at shutdown time? |
| 00:29:55 | Torne | dunno. |
| 00:30:15 | Torne | it seems unlikely, though. not impossible |
| 00:30:24 | Torne | but the data the bootloader reads from there is pretty specific |
| 00:30:39 | stripwax | Torne - do you have jtag? can you see what the iram contents are after an OF 'good' shutdown? |
| 00:30:40 | Torne | i would think it vanishingly unlikely for it to appear by accident |
| 00:30:47 | Torne | the OF doesn't *have* a shutdown |
| 00:30:50 | Torne | ther is no such thing |
| 00:30:55 | stripwax | 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 | Torne | there is only sleep, suspend to disk, or "shit my battery ran flat" |
| 00:31:26 | Torne | so yeah, we are trying to produce behaviour that the OF just doesn't have. |
| 00:31:32 | Torne | Hmmmmmm |
| 00:31:34 | Torne | that's a thought. |
| 00:31:52 | Torne | maybe the shutdown problem is caused by the OF's data *still* being in iram |
| 00:32:03 | stripwax | 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 | Torne | which i guess might happen if by fluke you don't run anything that goes that high |
| 00:32:06 | stripwax | right exactly |
| 00:32:21 | Torne | stripwax: well it must logically be able to del with powering on to find IRAM is totally blank |
| 00:32:27 | Torne | because that's what happens if you disconnect the battery |
| 00:32:31 | stripwax | yep.... |
| 00:32:41 | Torne | though whether it always handles it correctly is a different matter |
| 00:32:44 | Torne | but it must at least work in theory |
| 00:32:48 | stripwax | and presumably the OF boots just fine if you disconnect (and recharge, and reconnect..) the battery |
| 00:32:53 | stripwax | yeah |
| 00:33:24 | Torne | if you disconnect hte battery or let it run completely flat, it happily powers on on usb insert at least |
| 00:33:29 | stripwax | presumably someone has tried that though. (btw - not the first time I suggested trying to zero out the iram) |
| 00:33:33 | Torne | lioke i said, i've been disassembling the firmware |
| 00:33:42 | Torne | but haven't found anything useful yet and it is *spectacularly* dull |
| 00:33:54 | Torne | and it's full of very weird stuff |
| 00:34:02 | Torne | e.g. detection of PP CPU types that we've never seen |
| 00:34:26 | Torne | and what looks like lots of leftover code from different ipod models :) |
| 00:34:39 | Torne | it really is a massive pile of crap. way too complicated for the miniscule amount it does ;) |
| 00:35:04 | Torne | i was lookign for where it writes data to the LCD, to find where the "no battery" screen comes from |
| 00:35:08 | Torne | but can't bloody find it |
| 00:35:19 | Torne | (it doesn't help that the BCM video chip's control system is also insane) |
| 00:35:53 | S_a_i_n_t | It was probably written by a thousand monkies, at a thousand typewriters... ;-P |
| 00:36:02 | Torne | indeed |
| 00:36:14 | S_a_i_n_t | annd kludged together at the end. |
| 00:36:24 | Torne | i wonder if someone *has* tried clearing iram ;) |
| 00:36:33 | Torne | or at least the bit at the end |
| 00:36:34 | * | stripwax suspects not |
| 00:36:40 | Torne | ..yeah, tell you what |
| 00:36:42 | Torne | i will do taht :) |
| 00:36:54 | Torne | (and revert the other patch locally) |
| 00:36:58 | Torne | my ipod seems to do it pretty often |
| 00:37:05 | Torne | so, it's not a bad test ;) |
| 00:37:51 | S_a_i_n_t | what real harm could it possably do? |
| 00:38:05 | S_a_i_n_t | it couldn't...in *theory* |
| 00:39:11 | Torne | well i'll try it |
| 00:39:25 | Torne | seriously, without the other fix my ipod does it about one time in three |
| 00:39:39 | Torne | 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 | Torne | i'm doing it now, anyway |
| 00:40:05 | S_a_i_n_t | I don't mind doing some testing...if it helps. |
| 00:40:17 | Torne | S_a_i_n_t: did you previously have the shutdown issue often? |
| 00:40:20 | Torne | if not then it probably doesn't help |
| 00:40:43 | S_a_i_n_t | 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 | Torne | yes |
| 00:41:00 | S_a_i_n_t | maybe once, twice a week... |
| 00:41:09 | Torne | so not super often then ;) |
| 00:41:39 | S_a_i_n_t | No, but I have 4 different targets to choose from, so none get any real hard use. |
| 00:41:49 | S_a_i_n_t | 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 | S_a_i_n_t | 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 | Minataku | 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 | Torne | do we really only use 0xc000 bytes of iram on the ipods? |
| 00:59:49 | Torne | app.lds defines that as IRAMSIZE |
| 00:59:56 | stripwax | Torne - which ipods? .. |
| 01:00 |
| 01:00:01 | Torne | All of them |
| 01:00:03 | Minataku | Torne: So that IS you |
| 01:00:06 | stripwax | hrm. |
| 01:00:06 | Torne | Well, all the PP ones |
| 01:00:11 | Torne | boot.lds defines it as the right values dependent on PP type |
| 01:00:12 | * | Minataku pounces Torne |
| 01:00:23 | stripwax | different ones have different amounts of iram... |
| 01:00:31 | Torne | Minataku: this is an on topic development channel, be furry elsewhere ;) |
| 01:00:36 | Minataku | lol |
| 01:00:46 | Torne | stripwax: yes. but app.lds defines it as way less than *any* of them have |
| 01:00:58 | Minataku | 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 | stripwax | Torne - maybe, but what difference does that make? |
| 01:01:31 | stripwax | as in, what is IRAMSIZE used for / affect ? |
| 01:01:32 | Minataku | But yeah, just heaping praise for getting the SansaAMS devices up, now I can encode videos for my e260v2 myself |
| 01:01:40 | Torne | stripwax: it's used for the linker script.. |
| 01:01:45 | Torne | so it's limiting the size of the iram sections.. |
| 01:01:47 | Minataku | You know, WITHOUT that horrible Sansa Media Convertor |
| 01:01:54 | stripwax | only const/idata probably right |
| 01:02:11 | stripwax | presumably we can still use the rest of iram at runtime. (And presumably we also .. do ..) |
| 01:02:27 | Torne | No idea |
| 01:02:32 | Torne | haven't the faintest idea how it works ;) |
| 01:02:34 | Torne | it just seems odd |
| 01:02:41 | stripwax | 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 | Torne | anyway i'm building it now to see what happens |
| 01:04:32 | Torne | i'm clearing from 0xc000 to the end of what my player has ;) |
| 01:04:48 | Torne | on the assumption that this can't destroy anything rockbox is using because of the linker script.. |
| 01:05:17 | Minataku | Should never assume things, it's dangerous. |
| 01:05:28 | Torne | I think by dangerous you mean hilarious |
| 01:05:35 | stripwax | always assume everything, otherwise you'll never really learn anything :-) |
| 01:05:42 | Minataku | 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 | Torne | That one is fun :) |
| 01:05:51 | | Quit DerPapst (Quit: Leaving.) |
| 01:05:59 | Minataku | stripwax: That's less of an assumption and more of a "what's this do" |
| 01:06:15 | Minataku | An assumption means you don't expect to break something |
| 01:06:21 | Minataku | 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 | Minataku | :3 |
| 01:06:30 | stripwax | you'll learn soon enough if you find out you do break something |
| 01:06:42 | stripwax | er, yeah, what you just said :-) |
| 01:07:28 | Torne | 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 | Torne | 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 | Torne | but this should suffice |
| 01:08:01 | stripwax | probably ok so long as it's literally the last thing it does |
| 01:08:17 | Minataku | I'd dump it out and take a peek at it first, myself |
| 01:08:22 | stripwax | and doesn't use any variables on local stack to do it! |
| 01:08:37 | Minataku | See if there's anything in there that might be important |
| 01:08:49 | Torne | Minataku: i already know what is likely to be in there |
| 01:08:51 | kugel | Torne: app.lds has only the core iram, I think, plugin.lds the rest for codecs/plugins |
| 01:09:02 | Torne | kugel: ah |
| 01:09:33 | kugel | because there's no proper CORE_IRAM/CODEC_IRAM #define :p |
| 01:10:18 | Torne | yeah, i see. |
| 01:10:26 | Torne | anyway, that means it should be fine to clear from there to the end |
| 01:10:33 | Torne | since codecs/plugins can't be running at shutdown |
| 01:10:45 | Torne | as long as the OF doesnt' care about any data before then, which i'm pretty sure it doesn't. |
| 01:12:20 | Minataku | 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 | Minataku | The old "Spinning newspaper injures publisher" comes to mind for some reason when I think about a Flash ROM "spinning up" |
| 01:14:21 | Torne | it shouldn't need ctual spinups, but reducing accesses is still power efficient |
| 01:14:32 | Torne | flashes on these things tend to go into idle when you don't access them for a while |
| 01:14:38 | Minataku | Makes sense. |
| 01:14:43 | kugel | what are you trying to do? |
| 01:14:46 | Torne | 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 | Minataku | But it can be a touch confusing |
| 01:15:17 | Torne | well if there's somewhere it's badly worded in the manual reaise a bug |
| 01:15:57 | Minataku | 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 | rasher | Why does rbutil still require the user to press autodetect? |
| 01:17:28 | kugel | Torne: ^ :) |
| 01:17:45 | rasher | Can't we do that automatically when we detect there's no configuration... |
| 01:17:53 | Torne | kugel: fix the shutdown bug on ipod Some Other Way |
| 01:17:56 | *** | Saving seen data "./dancer.seen" |
| 01:18:05 | kugel | the battery icon one? |
| 01:18:08 | Torne | no |
| 01:18:23 | Torne | the one where it doesn't turn on again |
| 01:18:40 | kugel | but the battery icon is the side effect of the current fix? |
| 01:18:44 | Torne | yes |
| 01:19:05 | kugel | nobody has tried my suggestion to simply kill off the lcd before I assume? |
| 01:19:33 | Torne | that doesn't fix the shutdown bug |
| 01:19:39 | Torne | the point is not to solve the cosmetic issue |
| 01:19:47 | Torne | the point is to not call the OF |
| 01:19:56 | stripwax | 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 | Torne | because the OF does weird shit like turning the alarm back on |
| 01:20:05 | Minataku | Just have it display "Buy a better media player, you fool." |
| 01:20:17 | stripwax | bang for buck, the ipod5g 60GB is pretty hot |
| 01:20:24 | stripwax | well. was. |
| 01:20:39 | Torne | the ipodvideos are still pretty much the best large hdd target.. |
| 01:21:14 | Minataku | I liked the quote on the "GoldenQuotes" page about iPod users. |
| 01:21:28 | stripwax | kugel - please read FS #11063 .. |
| 01:22:29 | stripwax | kugel - and the conversation with webguest77 earlier :-) |
| 01:22:38 | Torne | 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 | Torne | so, er, generalisations not so useful ;) |
| 01:23:11 | Minataku | Torne: The e2x0v2 has MicroSD external |
| 01:23:13 | Minataku | :3 |
| 01:23:28 | Minataku | Technically infinite storage is pretty nice, you know. |
| 01:23:30 | Torne | Minataku: and when there's a uSD card which will hold 55.75GB let me know |
| 01:23:35 | Torne | :) |
| 01:23:39 | stripwax | right |
| 01:23:41 | ved | is there any known limit for sizes of SD external for sansas e200? |
| 01:23:47 | stripwax | 32GB |
| 01:23:50 | Minataku | They're up to 32GB so far |
| 01:23:54 | stripwax | I mean, in practice :-) |
| 01:24:17 | Minataku | SDXC is just another software extension to the protocol, IINM |
| 01:24:43 | Minataku | Similar to how SDHC was to SD |
| 01:25:12 | | Quit stripwax (Quit: http://miranda-im.org) |
| 01:25:16 | kugel | not a plain software extensions. the card readers and the cards itself have changed too |
| 01:25:35 | Torne | Minataku: a 32GB uSD card already costs nearly as much as an 80GB ipodvideo |
| 01:25:43 | Torne | 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 | Minataku | 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 | Halborr | 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 | RoronoaZoro | ok so in this part I have to implement some thing like OpenGl |
| 01:34:31 | Torne | RoronoaZoro: no. |
| 01:34:42 | Torne | RoronoaZoro: Some of our players have hardware support for resizing video |
| 01:34:50 | Torne | it's nothing to do with opengl |
| 01:35:42 | Minataku | Torne: Well, what's the interface to the GPU to do it? |
| 01:35:58 | Minataku | It is just a straight send and the GPU handles everything on it's own? |
| 01:36:01 | Torne | Minataku: arbitrary |
| 01:36:03 | Torne | and yes |
| 01:36:24 | Minataku | The i.MX31 I know actually has a 3D accelerator |
| 01:36:30 | Torne | please don't answer questions if you don't know the answers, especially to potential GSoC students :) |
| 01:36:33 | Minataku | Along with that 64bit ARM11 |
| 01:36:50 | Minataku | Torne: I said "standard GPUs", not embedded |
| 01:37:03 | Torne | Yes, so your answer is irrelevant and confusing |
| 01:37:35 | Torne | (and there are no 64bit ARM processors) |
| 01:38:00 | Minataku | Hm. Then I was misinformed. |
| 01:38:23 | Torne | and we can't use the MBX core on the i.MX31 because there are no public docs forit |
| 01:38:25 | RoronoaZoro | I maent to ask what does hardware support for resizing video mean |
| 01:39:26 | RoronoaZoro | what is the video resolution of the output generated by the software |
| 01:39:45 | Torne | 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 | Torne | the video decoder outputs whatever resolution the video is. |
| 01:40:23 | RoronoaZoro | i mean is the info about hardware support required for the code |
| 01:40:26 | Torne | 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 | RoronoaZoro | i mean is the info about hardware support required for the coding in the project |
| 01:41:21 | RoronoaZoro | how it does it, etc |
| 01:41:22 | Torne | Yes, to implement it you would need to know how it works on the hardware.. |
| 01:41:28 | Torne | how else could you do it? |
| 01:41:41 | S_a_i_n_t | *magic* ;) |
| 01:42:10 | Minataku | lol |
| 01:42:22 | Minataku | Keep guessing until it works |
| 01:43:05 | RoronoaZoro | 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 | Torne | but someone has to implement the code to drive the hardware |
| 01:44:21 | Torne | if we'd already implemented that code it wouldn't be on the list for a project |
| 01:45:21 | RoronoaZoro | ok so the code to drive the is also part of the project. So where do i get info about it |
| 01:45:29 | kugel | Torne: you think clearing iram solves it? |
| 01:45:40 | RoronoaZoro | before deciding on wether i can do it |
| 01:46:19 | Torne | 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 | Torne | it's easy enoguh to try, so i'm trying it. |
| 01:48:35 | Torne | RoronoaZoro: I suspect we are assuming the student would investigate that |
| 01:48:58 | Torne | RoronoaZoro: some players have public documentation for their hardware, some don't |
| 01:49:06 | RoronoaZoro | ok |
| 01:50:08 | Torne | kugel: my ipod boots extremely unreliably without the workaround, so i'll test it like this for a while and see. |
| 01:50:39 | S_a_i_n_t | how it is working so far? |
| 01:50:48 | S_a_i_n_t | s/working/going/ |
| 01:50:52 | Torne | S_a_i_n_t: perfectly, but i've only powercycled it half a dozen times, not actualyl used it |
| 01:51:11 | S_a_i_n_t | seems promising... |
| 01:51:18 | Torne | however if the theory is correct then powercycling it (rather than using it) is *more* likely to make it fail |
| 01:51:32 | Torne | 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 | kugel | sounds good |
| 01:54:18 | Torne | but, yeah. i'll use it like this for a while |
| 01:54:23 | kugel | maybe the troll from the forums also shuts up if that fix works |
| 01:54:26 | Torne | it's quite possible that nobody bothered to try this ;0 |
| 01:56:00 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 01:56:30 | RoronoaZoro | 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:00 |
| 02:02:32 | linuxstb | 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 | RoronoaZoro | no, i think you go it wrong ... i meant |
| 02:03:34 | RoronoaZoro | I read about VP3/Theora and can go about implementing it |
| 02:04:30 | | Join zOxta [0] (~52c9dbea@giant.haxx.se) |
| 02:04:52 | RoronoaZoro | but i also thought about Adding support for MP4 using the parser but could not understand much from it |
| 02:05:13 | katyl | 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 | RoronoaZoro | *i mean i need to know more about the parser |
| 02:07:36 | | Quit zOxta (Client Quit) |
| 02:08:00 | linuxstb | http://www.hydrogenaudio.org/forums/index.php?showtopic=68576 (the first hit on google for "mp4 specification") |
| 02:08:11 | bieber | 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 | JdGordon | repost it? |
| 02:09:05 | JdGordon | I'm probably one of the people you want to talk to for wps stuff |
| 02:09:39 | bieber | Code is on a public Git repo at git@github.com:bieber/libwps.git |
| 02:09:58 | linuxstb | bieber: Only why did you re-implement it, rather than using Rockbox's existing parser? (assuming you did). |
| 02:10:11 | bieber | 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 | JdGordon | yeah, reimplementing it means if needs to be kept in sync, which becomes a pain very quickly |
| 02:12:19 | bieber | 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 | bieber | 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 | RoronoaZoro | 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 | kugel | it's just the creator disappeared too quickly |
| 02:14:18 | kugel | the creator of the old wps editor |
| 02:14:51 | bieber | Does the WPS format change that frequently? |
| 02:15:02 | JdGordon | it can |
| 02:15:19 | kugel | we usually try to keep things backward compatible but once in a while we break it |
| 02:15:25 | kugel | not very often though |
| 02:15:36 | | Quit kugel (Remote host closed the connection) |
| 02:15:45 | JdGordon | 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 | bieber | 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 | JdGordon | we might be able to setup a working config which has all the tags enabled |
| 02:18:31 | JdGordon | 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 | linuxstb | bieber: How do you intend to deal with target-specificness ? |
| 02:18:54 | bieber | 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 | JdGordon | not when tags are pretty freeform.... |
| 02:19:33 | JdGordon | if they were all just %xx then sure |
| 02:20:09 | bieber | 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 | JdGordon | how is that different to what the current code does? |
| 02:22:25 | JdGordon | 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 | JdGordon | on mono targets the last 2 params don't exist |
| 02:22:49 | bieber | 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 | bieber | My code can distinguish between mono, greyscale, and color ViewPort tags, and sets a flag in the ViewPort object accordingly |
| 02:23:49 | bieber | 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 | bieber | And looking at the spec, I don't think there are any other tags with nearly that level of ambiguity |
| 02:24:30 | JdGordon | I cant think of any either |
| 02:25:43 | | Quit S_a_i_n_t () |
| 02:26:33 | bieber | 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 | JdGordon | but it is almost guarenteed to break or become outdated when tags are changed/added |
| 02:28:11 | JdGordon | we have enough trouble with checkwps which is built with the same code... |
| 02:28:43 | Llorean | 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 | Llorean | 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 | bieber | 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 | retroj | 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 | JdGordon | 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 | Llorean | 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 | Llorean | There aren't going to be many situations where there's a job that needs a target-agnostic editor |
| 02:30:55 | JdGordon | 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 | bieber | Well, if we want it to be useful for a non-technical user, platform-specificness would be a pretty big issue |
| 02:31:22 | JdGordon | are you doing it in Qt so it can be built into rbutil? |
| 02:31:24 | Llorean | retroj: I don't know, but the manual should say. |
| 02:31:53 | bieber | 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 | Llorean | bieber: Why? In the platform agnostic editor, they'd still need to know what their platform supports |
| 02:32:09 | Llorean | 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 | retroj | 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 | JdGordon | the parser doesnt need to be inherintly target specific thoguh |
| 02:32:32 | bieber | Right, but that's a pretty big difference if you want to use the application for more than one platform |
| 02:32:45 | Llorean | 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 | JdGordon | 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 | bieber | No one wants to download two separate but almost identical applications to accomplish the same task |
| 02:33:32 | Llorean | People do it all the time anyway with the sims. |
| 02:33:37 | JdGordon | 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 | JdGordon | ffs |
| 02:33:42 | | Quit m3dlg (Ping timeout: 258 seconds) |
| 02:33:49 | JdGordon | how hard would it be to go from a xml file to C++ objects? |
| 02:33:49 | bieber | 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 | JdGordon | *most* tags are simple %xx and on all targets |
| 02:34:40 | bieber | 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 | JdGordon | git clone git@github.com:bieber/libwps.git -> permission denied? |
| 02:35:36 | bieber | Dangit, must not be a public link |
| 02:35:44 | kugel | bieber: you haven't thought of just finishing the existing wps editor did you? |
| 02:35:55 | bieber | bieber/libwps">http://github.com/bieber/libwps |
| 02:36:11 | bieber | We discussed it before, consensus was that it's not worth doing (the current code doesn't even compile) |
| 02:36:38 | linuxstb | bieber: When was this previous discussion? |
| 02:36:46 | * | kugel would like to see it as well |
| 02:36:54 | bieber | I want to say Sunday, but I'm not really sure, looking in the archives for it |
| 02:37:40 | kugel | 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 | JdGordon | I'm starting to like this seperate approach |
| 02:38:13 | * | JdGordon hates C++ :/ |
| 02:39:05 | kugel | 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 | ved | c++ sux, after I started a big project I only learn what c++ cant do >_> |
| 02:39:50 | ved | typedef on templates |
| 02:39:56 | ved | static constructors |
| 02:39:58 | ved | whats not |
| 02:40:17 | ved | not to mention that asembelrs (like NASM for instance) have much better preprocessor than stupid C/C++ |
| 02:40:47 | JdGordon | offtopic |
| 02:40:57 | kugel | 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 | JdGordon | depends how it learns about tags |
| 02:41:26 | bieber | http://www.rockbox.org/irc/log-20100320 |
| 02:41:29 | bieber | That's the day |
| 02:41:55 | bieber | 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 | kugel | what's the reason to do it in c++ if I may ask? |
| 02:42:25 | bieber | 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 | JdGordon | 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 | JdGordon | 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 | kugel | 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 | JdGordon | ah right, /me forgot half the requirements for the editor :p |
| 02:45:42 | bieber | 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 | JdGordon | without that it means at best some lag between new tags getting added in svn and the editor |
| 02:46:30 | bieber | 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 | ved | isnt wps regullar? |
| 02:46:43 | JdGordon | nope |
| 02:46:54 | kugel | JdGordon: or not at all |
| 02:47:16 | bieber | You've got conditionals in there, so definitely not regular |
| 02:47:21 | ved | k |
| 02:47:35 | kugel | 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 | ved | parser is only part of the problem, as bison/yacc shows, it is no problem to do it in pure C |
| 02:49:10 | bieber | Right, the parser is pretty much purely procedural code |
| 02:49:24 | bieber | It's the parse tree structure that's using C++'s OO features |
| 02:49:31 | ved | but I would also want to do semantic check in OO code |
| 02:50:03 | JdGordon | you dont need C++ for OO |
| 02:50:27 | ved | surely I can do OO in asm, but its more convenient in cpp |
| 02:50:43 | bieber | 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 | bieber | 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 | ved | 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 | bieber | And of course either one would leave systems without JRE or Mono out in the cold |
| 02:52:35 | bieber | 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 | Llorean | There are some feature differences (presence of an RTC) |
| 02:53:04 | Llorean | As well, one player is text-only, not bitmap |
| 02:53:30 | bieber | 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 | Llorean | 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 | Llorean | And of course, sometimes 1bpp isn't exactly "black and white" (see the Clip for example) |
| 02:54:56 | bieber | 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 | Llorean | You were asking how much difference platform made though. |
| 02:55:38 | Llorean | My point was that there's a lot more to how a WPS appears than "screen size and color depth" |
| 02:55:49 | bieber | This is true, definitely |
| 02:55:51 | Llorean | 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 | kugel | 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 | kugel | 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:00 |
| 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 | S_a_i_n_t | *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 | bieber | 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 | bieber | 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 | kugel | 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 | Llorean | bieber: Why is the editor itself so hefty? |
| 03:07:59 | Guest62701F | ppl...is rockbox going to support sansa connect anytime soon? |
| 03:08:11 | kugel | Guest62701F: possibly, if you work on it |
| 03:08:23 | kugel | otherwise, very unlikely |
| 03:08:28 | Guest62701F | kugel if I programmer in C I would ;] |
| 03:08:33 | Guest62701F | *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 | bieber | 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 | Llorean | Give me some examples |
| 03:09:27 | Status | kugel thats one of the best sansa's out there...supports wi-fi and everything |
| 03:09:47 | Status | thats why when I saw it didn't support I was even sad :/ |
| 03:09:52 | kugel | bieber: I think we can judge a bit from the last wps editor, the editor itself wasn't overly complex |
| 03:09:55 | Llorean | There's just not that many elements of a WPS, and the vast majority of them are text. |
| 03:10:09 | Llorean | 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 | Llorean | 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 | bieber | 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 | bieber | There should be a decent code editor attached to it, with some form of syntax highlighting |
| 03:11:19 | Status | 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 | bieber | 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 | kugel | bieber: that's why should spend as little time as possible on the rockbox-side and more on the editor side |
| 03:12:17 | Llorean | bieber: What common elements? |
| 03:12:24 | | Nick mrigesh is now known as animAgus (~mrigesh@iws3.iiita.ac.in) |
| 03:12:50 | Llorean | 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 | JdGordon | 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 | bieber | 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 | JdGordon | leaving the rockbox tree unalterned isnt necessarily a good thing |
| 03:14:20 | Llorean | bieber: Wouldn't "it doesn't require separate maintenance" be more easily maintainable? |
| 03:14:29 | bieber | 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 | Llorean | 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 | Llorean | bieber: The sims "automagically" adapt themselves to changes in Rockbox's skin engine. |
| 03:15:11 | bieber | What do the sims do? |
| 03:15:20 | Llorean | They run on the host PC and simulator the UI of Rockbox |
| 03:15:22 | Llorean | Including WPS |
| 03:15:24 | JdGordon | 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 | kugel | compile all apps/ and most firmware/ code :) |
| 03:16:18 | bieber | 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 | bieber | 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 | Llorean | 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 | kugel | 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 | bieber | Is there really anything broken about it? |
| 03:18:56 | kugel | it's not broken, but it appearently doesn't attract 3rd party app developers to work with it |
| 03:18:57 | bieber | 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 | Llorean | 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 | kugel | 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 | Llorean | 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 | kugel | 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 | bieber | 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 | kugel | you have 2 separate projects anyway, either refactor the skin engine or reimplement it, then build the editor |
| 03:25:09 | bieber | 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 | kugel | what of the 2 former is less work? I'd think the refactoring |
| 03:25:21 | bieber | Maybe if you already know your way around the code |
| 03:26:02 | bieber | 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 | kugel | not without getting deeper into rockbox and its codebase |
| 03:26:34 | bieber | 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 | Llorean | 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 | kugel | you want to emulate, not an alternative renderer |
| 03:27:02 | | Quit adnyxo (Remote host closed the connection) |
| 03:28:00 | Llorean | 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 | bieber | 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 | bieber | I must have hit a different crowd tonight ;) |
| 03:28:25 | Llorean | bieber: Kugel and JdGordon are responsible for a significant chunk of the existing WPS code. |
| 03:28:46 | bieber | Duly noted |
| 03:29:30 | bieber | imo, heavily refactoring the skin engine for the benefit of a standalone editor looks like overengineering a great deal |
| 03:30:55 | Llorean | 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 | Llorean | Any code that comes out of this needs to be code the project will keep using. |
| 03:31:50 | Llorean | 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 | kugel | bieber: yes, you talked to a different croud :) |
| 03:32:11 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 03:32:19 | bieber | 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 | kugel | I think you heavily overestimate the work the skin engine needs |
| 03:32:37 | bieber | Regardless of how you build it, at some point it will break without someone keeping it up to date |
| 03:32:58 | bieber | 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 | kugel | the skin engine is only a few thousand lines. the parser and displayer are mostly separate already |
| 03:34:08 | bieber | 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 | kugel | parsing is not a problem, it only happens rarely |
| 03:34:53 | Llorean | Only on theme load, right? |
| 03:34:58 | kugel | and displaying is usually limited by the lcd drivers, so not a real problem too |
| 03:35:06 | kugel | Llorean: yes |
| 03:35:15 | Llorean | Which for a lot of us is once per boot. |
| 03:35:31 | bieber | And, of course, how feasible it would be to adapt Rockbox display code to render into a QT GUI |
| 03:36:11 | Llorean | It renders into SDL already. |
| 03:36:12 | kugel | I think the old editor Qt'ified a lot, if not too much |
| 03:37:23 | kugel | I just remember the fonts looked quite awkward compared to the targets |
| 03:37:39 | kugel | 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 | kugel | s/to compile// |
| 03:38:41 | kugel | but maybe that's asking too much |
| 03:38:42 | Status | wouldnt gtk be lighter? |
| 03:39:05 | Llorean | Weren't' the old pre-SDL sims in GTK? |
| 03:39:34 | kugel | 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 | bieber | GTK may be lighter, but it looks awful on Windows/Mac, and QT's a much friendlier library |
| 03:42:24 | bieber | 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 | kugel | you probably only need a few dozen wrapper/stubs (and resolve the conditional compilation things) - that's it |
| 03:43:48 | bieber | My biggest concern would be how much of the maintenance costst that kind of refactoring would actually alleviate |
| 03:44:56 | bieber | 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 | kugel | are you sure? |
| 03:46:06 | bieber | 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 | kugel | 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 | bieber | 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 | kugel | just reparse the whole file once in a while |
| 03:47:30 | Llorean | And as long as backward compatibility is maintained all the basic code generation will still function. |
| 03:47:36 | kugel | the parser is blazing fast, especially on desktop systems |
| 03:47:59 | Llorean | 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 | bieber | I'm not worried about how fast it will run, just working with the code from the GUI application |
| 03:48:50 | kugel | you said your editor is dependant on the parse tree, it's unclear to me how |
| 03:49:17 | bieber | 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 | kugel | it doesnt need to be interactive |
| 03:49:42 | bieber | 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 | Llorean | 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 | kugel | drag'n'drop wps elements? |
| 03:50:42 | bieber | 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 | Llorean | bieber: A live preview with a syntax highlighting text editor would (to me) be the obvious first step anyway |
| 03:51:18 | bieber | As a first step, yes, but I certainly wouldn't be satisfied with stopping there |
| 03:51:40 | kugel | but it would maybe enough to make the soc project succeed |
| 03:51:50 | bieber | 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 | kugel | you're of course welcome to work further on it, after gsoc |
| 03:52:30 | | Quit FOAD (Ping timeout: 240 seconds) |
| 03:52:41 | kugel | bieber: I don't think that's possible |
| 03:52:55 | scorche | the idea is that we want to keep you working on it with us forever ;p) |
| 03:52:56 | kugel | and I'm not sure we want that |
| 03:53:14 | Llorean | 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 | bieber | 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 | bieber | 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 | Llorean | 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 | kugel | bieber: I doubt you can do it that fancy within gsoc no matter of reusing or reimplementing the skin engine |
| 03:55:37 | saratoga_lab | i proposed yet another GSOC project today, a test driver for audio playback |
| 03:56:14 | bieber | 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 | bieber | 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 | bieber | 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 | bieber | 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:00 |
| 04:01:03 | Llorean | bieber: Remember that you can have nested conditionals, alternating sublines and other "objects with an object" situations, too. |
| 04:01:29 | Llorean | I don't know if you could reliably generate code from a purely graphical representation of the WPS |
| 04:01:45 | bieber | Hmm, conditionals would be tricky |
| 04:02:18 | bieber | 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 | bieber | Or maybe a side-panel that lets you flip the state of different conditionals |
| 04:02:30 | Llorean | Also, it matters where in a file many objects are defined. |
| 04:02:48 | bieber | Right, z-ordering and such will have to be specifiable |
| 04:03:24 | bieber | 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 | S_a_i_n_t | 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 | S_a_i_n_t | 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 | Status | saratoga_lab I did... |
| 04:22:37 | Status | but there's no status about the player anywhere..only stuff on the wiki |
| 04:22:51 | Status | thats why I posted to see if any progress was actually made |
| 04:23:02 | | Quit TheSeven (Disconnected by services) |
| 04:23:15 | Llorean | 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 | Status | so progress would be 0 ;/ |
| 04:24:11 | Llorean | Well, because the people who want it don't work on it. |
| 04:25:08 | Status | 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 | Llorean | 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 | Status | 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 | Llorean | And 1 year is still shorter than "never" |
| 04:26:49 | Llorean | 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 | Status | I know it's hard work... |
| 04:27:39 | Status | that's why I was wondering if its missed hardware or something |
| 04:28:27 | Status | because usually devs/testers..sometimes don't even have hardware to work on...rely on testing done by others.. |
| 04:28:41 | Llorean | That's rarely the case here. |
| 04:29:37 | | Quit ObsidianX (Read error: Connection reset by peer) |
| 04:29:41 | Status | hard port then? |
| 04:30:05 | Llorean | Nobody who wants it is working on it. |
| 04:30:15 | Llorean | I've said this already. |
| 04:30:18 | Status | :/ |
| 04:30:31 | Llorean | The people who want it are apparently all like you - hoping someone else will do it for them. |
| 04:31:12 | Status | because most people don't code...so they help in other ways...hardware...donations etc... ;] |
| 04:31:34 | bieber | C is a pretty simple language, don't be discouraged about trying to learn it |
| 04:32:00 | bieber | Do you know anything about programming? |
| 04:32:03 | Status | bieber I must have about 3/4 C/C++ books |
| 04:32:29 | Status | I get lost on all that pointers and var assignment stuff |
| 04:32:34 | S_a_i_n_t | 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 | Status | bieber I can do magic in tcl ;] |
| 04:33:16 | bieber | Okay, so we just need to get you thinking a little bit lower level ;) |
| 04:33:23 | Status | be it in shell-scripts...web..eggdrops ;] |
| 04:33:48 | Llorean | 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 | Llorean | So some assembly knowledge would also help. |
| 04:34:25 | bieber | Ooh, I didn't even think about that |
| 04:34:27 | Status | uhum |
| 04:34:41 | Status | Llorean by the time I learn asm I'll have white hairs |
| 04:34:43 | Status | hehehehe |
| 04:34:50 | Llorean | 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 | Status | assembly is the language of the devil |
| 04:35:01 | Llorean | They almost always happen by someone who is already interested in the player doing the hard work necessary |
| 04:35:37 | Llorean | 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 | Status | Llorean do you code? |
| 04:35:57 | Status | C? something else..? |
| 04:36:29 | Llorean | Several languages including C, but in regards to Rockbox I'm more of a user. |
| 04:37:15 | Status | how would you consider yourself on C? |
| 04:37:24 | Llorean | What does this have to do with Rockbox? |
| 04:37:45 | Status | just to have an idea how you learned it ;] |
| 04:37:54 | bieber | 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 | Status | 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 | Status | bieber I have one that runs it |
| 04:38:37 | Status | 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 | S_a_i_n_t | There shouldn;t be *too* many to go now ;) |
| 04:39:17 | Status | anyhow... |
| 04:39:32 | Llorean | S_a_i_n_t: What are the 5e,5f etc? |
| 04:39:52 | S_a_i_n_t | for pacbox |
| 04:40:04 | Llorean | So why are they listed? |
| 04:40:24 | Llorean | I mean, if you're going to include unsupported files, isn't that every extension ever? |
| 04:41:15 | S_a_i_n_t | In theory...yes, but I'm trying to come up with all the exts likely to be seen in the filebrowser... |
| 04:41:19 | S_a_i_n_t | its a bit of a mission. |
| 04:43:41 | | Part arbingordon ("`") |
| 04:44:02 | Llorean | 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 | S_a_i_n_t | 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 | S_a_i_n_t | 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 | Llorean | I see .voice but not .talk |
| 04:47:36 | S_a_i_n_t | Aha...thanks :D |
| 04:47:45 | S_a_i_n_t | 1 down, a million to go ;) |
| 04:48:28 | | Quit Rob2222 (Ping timeout: 240 seconds) |
| 04:48:31 | Llorean | .wvc for the wavpack correction file |
| 04:49:10 | S_a_i_n_t | Llorean: Thanks again. |
| 04:49:25 | Llorean | 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 | S_a_i_n_t | and yes, you're right about .log...wow, you're good at this ;) |
| 04:52:33 | Llorean | I see .tar and .gzip but not .gz or .tgz or .rar |
| 04:53:42 | RoronoaZoro | 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 | S_a_i_n_t | 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 | moos | is it intended to have duplicated types? |
| 04:57:57 | moos | @S_a_i_n_t |
| 04:58:12 | S_a_i_n_t | There are duplicates? |
| 04:58:44 | moos | just spoted one, line 87 and 81 |
| 04:58:48 | | Quit m3dlg (Ping timeout: 264 seconds) |
| 04:58:58 | moos | after quick look to be precise :p |
| 05:00 |
| 05:00:30 | S_a_i_n_t | Hmm, that was odd..thanks for that moos |
| 05:01:06 | moos | you are welcome, btw I guess you checked the filetypes .c file? |
| 05:01:08 | S_a_i_n_t | looking at a long list for ages (especially your own) can have drawbacks when it comes to seeing failures. |
| 05:01:20 | moos | indeed |
| 05:01:22 | S_a_i_n_t | moos: yep, checked. |
| 05:01:33 | moos | good |
| 05:07:17 | S_a_i_n_t | whats the Mac equivelent of an .exe again? (is it different? it is, isn't it?) |
| 05:09:51 | JdGordon | .app i tihnk |
| 05:09:58 | JdGordon | Application.app |
| 05:10:01 | JdGordon | which is really a folder |
| 05:10:03 | S_a_i_n_t | thanks. |
| 05:10:40 | | Quit anewuser () |
| 05:10:48 | | Part Llorean |
| 05:11:06 | S_a_i_n_t | my .icons file has now grown to 170 ext's :D |
| 05:11:17 | moos | S_a_i_n_t: you can add .mmf file type too |
| 05:11:37 | S_a_i_n_t | +10 from all you guys so far ;) |
| 05:11:41 | S_a_i_n_t | +11 :D |
| 05:11:45 | moos | :) |
| 05:12:02 | moos | -1 too? ;) |
| 05:13:21 | moos | + .au |
| 05:14:01 | JdGordon | you rang? |
| 05:14:09 | RoronoaZoro | 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 | JdGordon | http://svn.rockbox.org |
| 05:16:02 | RoronoaZoro | thanks |
| 05:17:02 | moos | 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 | S_a_i_n_t | 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 | JdGordon | make it alphamabetical then! |
| 05:20:46 | | Quit panni__ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
| 05:20:47 | moos | S_a_i_n_t: you have even a list just for audio extension on the parser .c file IIRC |
| 05:20:55 | moos | plenty files :) |
| 05:21:24 | S_a_i_n_t | Ahhh..I'll have a look there too, thanks. |
| 05:21:50 | S_a_i_n_t | 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 | S_a_i_n_t | Its preety easy when you're only pointing to 1 icon ;D |
| 05:22:22 | JdGordon | thats just stupid |
| 05:22:24 | S_a_i_n_t | *pretty also. |
| 05:22:39 | moos | check svn r24939, 50 file types for audio last time I did count for the stat plugin |
| 05:22:50 | S_a_i_n_t | what is? pointing to 1 icon? |
| 05:23:02 | S_a_i_n_t | 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 | moos | all audio type, for 1 icon the audio one 0: ) |
| 05:23:44 | moos | gave/have |
| 05:24:56 | | Part Gartral |
| 05:24:58 | S_a_i_n_t | moos: All icons are the same...*all* Icons, every icon :D Check the Symmetry theme (Nano1/2g) for a reference |
| 05:25:15 | S_a_i_n_t | 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 | moos | 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 | S_a_i_n_t | 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 | moos | np, have fun, you must have 50 filetypes just for audio |
| 05:32:04 | moos | codecs |
| 05:32:06 | S_a_i_n_t | <shakes fist>yes, and the list seems arbitrarily listed...alphabetical would be *so* nice right now</shakes fist> |
| 05:33:41 | moos | {"mp3","mp2","mp1","mpa","ogg","oga", |
| 05:33:43 | moos | "wav","flac","ac3","a52","mpc","wv","m4a","m4b","mp4", |
| 05:33:44 | moos | "shn","aif","aiff","wma","wmv","asf","spx","ape","mac", |
| 05:33:46 | moos | "sid","mod","nsf","nsfe","spc","adx","sap","rm","at3", |
| 05:33:48 | moos | "ra","rmvb","oma","aa3","dmc","dlt","mpt","mpd","rmt", |
| 05:33:50 | moos | "tmc","tm8","tm2","cm3","cmc","cmr","cms","mmf"}; |
| 05:34:38 | moos | a few :) |
| 05:36:41 | moos | 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 | moos | 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 | S_a_i_n_t | After painstakingly going through metadata.c I managed to find *one* I'd missed... w64 ;D |
| 05:48:16 | S_a_i_n_t | revised list (moos + Llorean + Others suggestions included.) http://pastebin.com/qkKtjcaA |
| 05:49:16 | CIA-5 | New commit by moos (r25327): Stats plugin: Add 3 missing types to count. |
| 05:49:35 | | Quit bluebroth3r (Ping timeout: 260 seconds) |
| 05:49:47 | S_a_i_n_t | 175 extensions...!!! *evil laugh!* |
| 05:50:46 | moos | this is the last update, I'll commit soon the patch I have to get rid of this const. |
| 05:50:55 | moos | 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:00 |
| 06:01:27 | | Join CGL [0] (~CGL@190.207.143.203) |
| 06:04:39 | S_a_i_n_t | 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_a_i_n_t | s/etx's/etx's/ |
| 06:05:32 | S_a_i_n_t | 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:00 |
| 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:00 |
| 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 | wodz | 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 | Zagor | wodz: did you see funmans comment in the tracker? |
| 08:43:25 | wodz | yes |
| 08:44:01 | wodz | I am talking only about apps/plugins/plugin.lds change since it is the most intrusive one |
| 08:44:23 | Zagor | oh, right, I didn't read fully |
| 08:45:56 | Zagor | is dram location always in a permanently fixed location on these chips, or is that configurable? |
| 08:47:20 | Zagor | I would assume iram is fixed, but does the same apply to dram? |
| 08:47:54 | | Quit Tomis (Quit: Tomis) |
| 08:48:17 | wodz | dram address as well as iram adresses are configurable |
| 08:48:30 | wodz | but all cf target uses the same bases |
| 08:48:38 | Zagor | in that case I disagree with your change |
| 08:48:39 | wodz | I mean in rockbox |
| 08:49:05 | wodz | Zagor: why? |
| 08:49:36 | Zagor | 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 | wodz | Zagor: no no. You select by writing to register where to put dram/iram - look at crt0.S for coldfire |
| 08:50:49 | Zagor | oh. I thought it was a pin configuration. |
| 08:50:57 | Zagor | in that case, I *agree* with your changes! :-) |
| 08:53:52 | Zagor | or,wait |
| 08:53:54 | wodz | crt0.S lines 45-65 sets irams addresses, lines 161-173 sets dram address |
| 08:54:26 | Zagor | 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 | Zagor | aha, it refers to the use of 0x3100000 instead of 0x3000000 |
| 08:55:48 | wodz | Zagor: yes |
| 08:56:06 | wodz | it is related to error in BGA version of 5249 |
| 09:00 |
| 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:00 |
| 10:04:25 | | Join Luca_S [0] (~5d3fc54b@giant.haxx.se) |
| 10:04:36 | pamaury | I think I sorted out the (un)famous HID bug |
| 10:05:46 | | Join Gartral [0] (~Gareth@unaffiliated/gartral) |
| 10:06:27 | Gartral | are there any known bugs with the buildclient scripts? |
| 10:06:45 | | Quit r2_ (Read error: No route to host) |
| 10:06:56 | Zagor | Gartral: none known, no |
| 10:07:01 | Zagor | 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 | Gartral | 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 | Gartral | and it's still sitting there like i just started it >.> |
| 10:11:46 | Zagor | surely you did not get a CUPS message in rbclient.log? |
| 10:13:04 | Gartral | true, i did not.. but neither has my buildclient done *any* work since |
| 10:13:05 | Zagor | my log shows a disconnect from you ~5 hours ago and nothing since |
| 10:13:31 | Gartral | wtf.. it must be an ubuntu issue.. |
| 10:14:16 | Zagor | I can't ping your host, but I guess I'm not supposed to? |
| 10:14:32 | Zagor | try killing rbclient.pl and see what happens |
| 10:14:35 | Gartral | no, i have a stealthwall |
| 10:15:41 | Gartral | huh.. it says no process found |
| 10:17:44 | Zagor | that would be a good reason :-) |
| 10:17:46 | * | Gartral thinks ubuntu is screwy |
| 10:18:15 | Gartral | i cant find either the .sh or .pl scripts |
| 10:18:37 | Gartral | but the terminal running the .sh hasen't returned a prompt or error |
| 10:18:45 | Zagor | ! |
| 10:19:31 | Gartral | so why would the script be killed rudly? |
| 10:20:04 | Zagor | I have no idea |
| 10:20:37 | | Join liar [0] (~liar@213162066166.public.t-mobile.at) |
| 10:21:24 | Gartral | ok.. im back up. |
| 10:23:02 | Zagor | I don't see a connection |
| 10:24:20 | Gartral | doi... stupuntu failed again.. it disconnected me.. that's why the script failed |
| 10:24:53 | Gartral | oh crap |
| 10:24:59 | Zagor | heh, now you have two clients :) |
| 10:25:07 | Gartral | HELLO failed: error duplicate names! |
| 10:26:48 | Gartral | but i killed the first one.. |
| 10:26:57 | | Quit jae (Quit: leaving) |
| 10:27:38 | Gartral | note to self... after hard hangup system needs rebooting |
| 10:28:46 | | Join jae [0] (~jae@jaerhard.com) |
| 10:29:03 | Gartral | Zagor: do you have a log of my upload speeds? |
| 10:30:22 | Zagor | Gartral: yes. you can see them in the build graphs. for example: rasher.dk/rockbox/buildgraphs/graph.php?r=25326&debug">http://rasher.dk/rockbox/buildgraphs/graph.php?r=25326&debug |
| 10:30:56 | Zagor | the dark green fields are upload. mouseover shows the time. |
| 10:35:06 | TheSeven | 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 | Gartral | Zagor: but that doesnt show my upload speeds as seen from the server |
| 10:44:50 | Gartral | (in kbps) |
| 10:45:15 | Zagor | right, it only shows the time. |
| 10:45:42 | Gartral | 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 | Zagor | Gartral: sort of. we store lots of statistics in a database. |
| 10:47:40 | Gartral | may i have access (or a copy of my entry) to it? |
| 10:48:04 | Zagor | sure, just a minute |
| 10:49:02 | Gartral | if it reads 165 kbps imma be really angry with my isp |
| 10:49:04 | Zagor | your last 11 builds have been uploaded at 145-180 kbyte/s |
| 10:49:10 | Gartral | 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:00 |
| 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 | amiconn | 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 | amiconn | (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 | Torne | 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 | byondo | hello everyone |
| 11:53:10 | byondo | just flashed my clipv2 |
| 11:53:22 | byondo | it works like a charm :) |
| 11:58:28 | | Quit byondo (Ping timeout: 276 seconds) |
| 11:59:16 | topik | it should work like a mediaplayer |
| 12:00 |
| 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 | byondo | eheh |
| 12:07:25 | byondo | (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 | pamaury | 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 |
| 13:00:06 | | Quit anewuser () |
| 13:03:10 | gevaerts | pamaury: is it still simple enough to explain? :) |
| 13:03:20 | pamaury | yes |
| 13:04:31 | JdGordon | does it go something like "whoever wrote the hid code is a flaming gallah"? |
| 13:04:42 | pamaury | No, it's a usb-arc bug |
| 13:05:05 | pamaury | Give me a minute to write an explaination :) |
| 13:05:15 | * | gevaerts starts his stopwatch |
| 13:05:38 | pamaury | 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 | gevaerts | yes, or at least it should... |
| 13:06:10 | pamaury | But, we're are talking about a transfer descriptor here and for the usb code, transfer!=transfer descriptor. |
| 13:06:30 | pamaury | So, the code ends up big transfers in a premature way sometimes |
| 13:07:13 | gevaerts | Oh, right... |
| 13:07:18 | * | gevaerts thinks he understands |
| 13:07:37 | pamaury | 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 | gevaerts | 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 | pamaury | Yes, and for an unknow reason, the controller sets ENDPTCOMPLETE bit even for non ioc tds |
| 13:08:47 | gevaerts | That might indeed cause lots of interesting weirdness |
| 13:09:49 | | Quit kunal (Read error: Connection reset by peer) |
| 13:09:51 | pamaury | 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 | pamaury | 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 | gevaerts | and possibly at the IOC bit |
| 13:12:46 | | Quit lyngaas (Ping timeout: 248 seconds) |
| 13:12:59 | pamaury | 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 | gevaerts | 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 | Torne | ooh |
| 13:18:12 | *** | Saving seen data "./dancer.seen" |
| 13:18:44 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 13:18:53 | pamaury | 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 | pamaury | gevaerts: do I create a separate task on FS ? |
| 13:21:01 | gevaerts | pamaury: I don't know. I'd just commit it, it sounds obviously correct to me |
| 13:21:39 | pamaury | ok, I'll poste to pastebin so that people can look at it |
| 13:22:52 | pamaury | http://pastebin.com/qM8Gd7XH |
| 13:23:58 | pamaury | 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 | gevaerts | as far as gotos go, this one isn't ugly I think |
| 13:25:21 | pamaury | the Lskip:continue is ugly but C doesn't allow empty statement after goto iirc |
| 13:25:32 | pamaury | *after a label |
| 13:26:58 | * | gevaerts wonders if FS #9969 might now also work properly |
| 13:28:54 | pamaury | it didn't work ? |
| 13:29:36 | gevaerts | it caused bus resets |
| 13:30:13 | pamaury | that's weird |
| 13:30:31 | pamaury | how is this possible ? It doesn't touch usb code... |
| 13:30:52 | gevaerts | yes and no. To use it you need to change an #if 0 in usb_storage.c |
| 13:31:59 | pamaury | the queue_broadcast one ? |
| 13:32:47 | gevaerts | 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 | pamaury | 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 | gevaerts | bad news |
| 13:34:23 | gevaerts | The bug seems to be harder to trigger, but I still have it |
| 13:35:32 | pixelma | could this also be the cause of the MacOS 10.4 USB problems? |
| 13:36:57 | gevaerts | pixelma: I doubt it |
| 13:37:04 | JdGordon | 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 | pamaury | arg, by harder you mean ? |
| 13:37:48 | pixelma | gevaerts: thought so |
| 13:37:58 | pixelma | but one can hope :) |
| 13:38:11 | gevaerts | pamaury: I mean my e200 wheel turning finger gets a lot of exercise before I get problems |
| 13:38:26 | gevaerts | pamaury: isn't there still a possible duplicate send in hid? |
| 13:38:59 | pamaury | yes there is, |
| 13:39:17 | gevaerts | maybe I'm hitting that one now then |
| 13:39:23 | pamaury | Can you try to prevent sending while a transfer is on in usb-hid ? |
| 13:39:51 | pamaury | 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 | gevaerts | 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 | pamaury | it looks ok |
| 13:47:48 | pamaury | that's a shame |
| 13:49:00 | gevaerts | 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 | gevaerts | 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 | gevaerts | so there definitely is a HID issue... |
| 13:52:41 | gevaerts | gah, HID is definitely buggy... |
| 13:53:26 | pamaury | 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 | gevaerts | I doubt it |
| 13:54:45 | gevaerts | 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 | gevaerts | I think that that points to a bug in usb_hid.c where it doesn't handle its internal queue properly |
| 13:55:16 | gevaerts | s/queue/ring buffer/ |
| 13:55:29 | pamaury | 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 | gevaerts | The way it is now, you don't know what state it's in and what is expected to happen next |
| 13:57:50 | gevaerts | Anyway, I think your patch is OK and should be committed |
| 13:58:14 | pamaury | ok, I'll do it later :) |
| 13:58:21 | pamaury | The hid one also |
| 14:00 |
| 14:02:59 | | Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) |
| 14:05:52 | wodz | 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 | JdGordon | wodz: what do you want to do? |
| 14:25:21 | JdGordon | a fully graphical bootloader? |
| 14:26:58 | JdGordon | easiest is probably making firmware/button.c compile for the bootloader |
| 14:29:06 | JdGordon | damn this laptop sucks... 60min battery life! |
| 14:29:11 | JdGordon | woops |
| 14:29:54 | | Join Schmogel [0] (~Miranda@p3EE21FE6.dip0.t-ipconnect.de) |
| 14:31:53 | | Part LinusN |
| 14:33:41 | linuxstb | 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 | wodz | linuxstb: yes I do |
| 14:44:05 | linuxstb | What do you want to do? I'm guessing other Coldfire bootloaders don't do what you want? |
| 14:45:23 | CIA-5 | New commit by pamaury (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 | pamaury | gevaerts: can I commit you hid fix ? |
| 14:49:37 | wodz | 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 | CIA-5 | New commit by pamaury (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 | linuxstb | 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 | wodz | You are holding play button to power up. |
| 14:52:41 | wodz | 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 | linuxstb | 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 | wodz | linuxstb: I don't quite understand question |
| 14:56:54 | linuxstb | 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 | linuxstb | So in effect "short press on PLAY" - boot Rockbox, and "very long press on play" - start OF. |
| 14:58:05 | wodz | 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 | wodz | generaly You have to hold press as long as crt0.S is finished |
| 14:59:00 | linuxstb | I'm guessing that's quite fast though? Or are there artificial delays? |
| 14:59:14 | wodz | its fast |
| 15:00 |
| 15:00:10 | wodz | brains stroming is always good :-) I have to test the ideas |
| 15:00:18 | linuxstb | 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 | wodz | what is default cluster size for FAT32 in windowsXP? |
| 15:12:01 | TheSeven | wodz: depends on the size of the partition, IIRC |
| 15:12:34 | TheSeven | pamaury: do those fixes resolve the HID trouble completely for ARC-based devices? |
| 15:13:00 | TheSeven | or is it just a first stage of a fix? |
| 15:13:16 | TheSeven | and are they likely to affect the nano2g hid trouble? |
| 15:13:32 | | Quit JdGordon (Ping timeout: 252 seconds) |
| 15:14:30 | wodz | TheSeven, 8Gb CF card |
| 15:14:59 | TheSeven | IIRC it always used 4K clusters on my 8GB ipod |
| 15:15:26 | TheSeven | why do you need to know it? |
| 15:15:56 | | Quit funman (Quit: free(random());) |
| 15:17:10 | wodz | 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 | TheSeven | wait, it's an iPod? |
| 15:17:57 | TheSeven | 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 | Torne | but http://support.microsoft.com/kb/140365 has MS's choice of cluster sizes |
| 15:18:50 | pamaury | 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 | pamaury | *really |
| 15:19:04 | TheSeven | 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 | wodz | MPIO hd200 it is early stage not commited yet |
| 15:19:34 | pamaury | TheSeven: but please, try it and give your feedback :) |
| 15:19:37 | TheSeven | pamaury: do you think it makes sense for me to re-test HID on nano2g, if there is less trouble now? |
| 15:19:39 | TheSeven | ok |
| 15:19:48 | Torne | 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 | Torne | (whereas windows does) |
| 15:20:16 | TheSeven | Torne: not even most partitioning tools for linux seem to be able to deal with big sectors |
| 15:20:24 | wodz | shit |
| 15:20:40 | * | wodz is looking for XP machine around |
| 15:20:48 | Torne | wodz: do you not know the sector size? |
| 15:20:51 | | Join evilnick_B_ [0] (~0c140464@rockbox/staff/evilnick) |
| 15:20:55 | Torne | you can tell mkfs.vfat to use whatever. |
| 15:21:16 | wodz | Torne: I lost my notes abot this |
| 15:21:27 | Torne | the disk will tell you if you ask ;) |
| 15:21:35 | | Quit evilnick_B (Ping timeout: 252 seconds) |
| 15:21:38 | Torne | it's in IDENTIFY somewhere |
| 15:22:03 | TheSeven | 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 | TheSeven | reading battery current for better runtime approximations isn't a NODO, is it? |
| 15:23:58 | Torne | no, it's just difficult :) |
| 15:24:14 | Torne | 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 | Torne | 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 | Torne | :) |
| 15:25:48 | TheSeven | what is it doing right now? |
| 15:26:01 | Torne | right now, neither |
| 15:26:11 | TheSeven | 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 | Torne | Not quite.. |
| 15:26:26 | Torne | It ignores the backlight current |
| 15:26:31 | Torne | unless the backlight is set to *never* shut off. |
| 15:26:35 | Torne | Which is a good approximation, really |
| 15:26:57 | Torne | 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 | TheSeven | hm, that won't fit different codecs well at all |
| 15:27:09 | Torne | 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 | Torne | which is someone's super long term average, usually computed using a codec with minimal/no boosting |
| 15:28:22 | Torne | 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 | Torne | 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 | Torne | my math is not so hot |
| 15:29:33 | Torne | 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 | Torne | er, i mean, by album or similar |
| 15:29:57 | Torne | not per track |
| 15:30:04 | TheSeven | it will smooth that out a bit, but not completely |
| 15:30:07 | Torne | so it does an hour or so at no boost, then an hour or so at high boost |
| 15:30:12 | Torne | alternating for 20 hours :) |
| 15:30:39 | Torne | 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 | Torne | 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 | Torne | but yeah, obviously there are a wide range of ways to average it out ;) |
| 15:31:35 | TheSeven | 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 | TheSeven | 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 | Torne | i'm imagining some way of taking user behaviour into account |
| 15:32:57 | TheSeven | user behavior in terms of what? |
| 15:33:08 | TheSeven | how much he is skipping around, having the backlight on, etc? |
| 15:33:17 | Torne | 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 | Torne | when listening to music only a very long term averge works pretty well |
| 15:33:57 | Torne | (i.e. battery-bench like usecases) |
| 15:34:27 | Torne | 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 | TheSeven | when rebuffering 32mb, for how long does the drive usually spin? |
| 15:34:50 | Torne | er |
| 15:34:54 | Torne | not long. |
| 15:35:12 | TheSeven | so a 5 second resolution might be not enough? |
| 15:36:06 | Torne | 5 seconds seems veyr unlikely to catch enough of the disk spinning to account for it, yeah |
| 15:36:36 | TheSeven | so let's do it on a second base |
| 15:37:15 | TheSeven | how fast do we want old measurements to decay? |
| 15:37:52 | Torne | stopped to buffer full on ipodvideo64mb takes about 9 seconds btw |
| 15:38:01 | Torne | and i think rebuffering would be slightly faster |
| 15:38:19 | Torne | most of the players have only half that big a buffer, also |
| 15:38:47 | Torne | I really don't kow |
| 15:38:57 | Torne | I'm just pondering a more complex method than sampling+averaging |
| 15:39:40 | Torne | 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 | TheSeven | that would need to know the bitrates of tracks in advance |
| 15:40:17 | TheSeven | a sampling and averaging algorithm will probably do better |
| 15:40:35 | Torne | no it wouldn't |
| 15:40:43 | Torne | you guess based on history |
| 15:40:58 | TheSeven | you don't have data about the future in any case |
| 15:41:10 | TheSeven | so we can at least try to make assumtions based on history |
| 15:41:23 | Torne | no, but you are losing a lot of data about the *present* by just averaging samples |
| 15:41:48 | TheSeven | well, those samples are weighed |
| 15:41:57 | Torne | 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 | TheSeven | the newest ones have the highest weight |
| 15:42:03 | Torne | because we're back to just playing music |
| 15:42:10 | Torne | and the screen is off |
| 15:42:17 | Torne | and yes, it'll pick that up over time |
| 15:42:26 | TheSeven | well, but the user will probably continue playing games another half an hour later |
| 15:42:30 | Torne | but how fast are you gonna have it decay? |
| 15:42:43 | Torne | if you have it decay quickly then it will sawtooth around rebuffers |
| 15:42:47 | TheSeven | the history-based estimate would take that into account |
| 15:43:02 | Torne | if you have it decay slowly then it will overestimate consumption after the UI stops being used for a long time |
| 15:43:06 | TheSeven | yes, it will always sawtooth a bit |
| 15:43:43 | TheSeven | and i see no reason why it should overestimate comsumption when decaying slowly |
| 15:43:43 | Torne | yah. but my point is that we *know* why it's changing |
| 15:44:03 | Torne | the upward spike on every rebuffer is not a mysterious factor, we initiated it |
| 15:44:19 | Torne | (and we know when it's coming, maybe even 30 minutes in advance) :) |
| 15:44:27 | TheSeven | if that spike is small enough, it would just don't care about it |
| 15:44:58 | TheSeven | we won't know when it's coming, if the user decides to mix things like flac and mp3 |
| 15:45:17 | Torne | we know when the next one is coming, almost always |
| 15:45:17 | TheSeven | that would cause estimation spikes |
| 15:45:22 | Torne | (except when people skip tracks) |
| 15:45:27 | TheSeven | i somehow would rather like it to sawtooth than to spike |
| 15:45:58 | TheSeven | 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 | Torne | well, no |
| 15:46:20 | Torne | ..yeah |
| 15:46:21 | Torne | :) |
| 15:46:23 | Torne | ahwell |
| 15:46:24 | * | Torne shurgs |
| 15:46:29 | Torne | i'm not saying don't do it |
| 15:46:41 | Torne | i'm just saying there is extra information we have thta might be able to be taken into account |
| 15:47:08 | Torne | because we know the common use cases for the device, in a way that a general purpose computer OS doesn't |
| 15:47:08 | TheSeven | 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 | Torne | *personally* i like it how it is, but i am not a very typical user, so that's not relevant |
| 15:48:02 | TheSeven | how many people will actually look at that estimation? |
| 15:48:04 | Torne | (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 | Torne | (so for my specific ipod the estimate is really good anyway, and would probably only get worse with dynamic estimation) :) |
| 15:49:05 | TheSeven | 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 | TheSeven | so you are basically doing ultra-long-term estimates |
| 15:49:53 | Torne | yah. i rarely use my player for anything but playback, so backlight or non-buffering disk spinups are irrelevant |
| 15:50:17 | Torne | nothing makes a significant difference to my battery life other than boost % and rebuffer frequency |
| 15:50:27 | Torne | and I have pretty good long temr estimates of both |
| 15:51:18 | Torne | I guess you could actually keep long term stats, if you were really determined :) |
| 15:51:25 | Torne | and work out the same thing without human intervention ;) |
| 15:51:40 | Torne | nothing says you actually have to forget history when the battery gets recharged |
| 15:52:06 | | Quit mitk (Quit: Leaving) |
| 15:52:59 | Torne | i am probably overcomplicating this, anyway |
| 15:53:11 | Torne | i suggest you write a decaying average thiny |
| 15:53:19 | Torne | and test it out with various parameters :0 |
| 15:54:04 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 15:54:22 | Torne | 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 | Torne | 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 | Torne | :) |
| 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:00 |
| 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 | Buschel | 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 | TheSeven | something like linky for wikipedia would be nice for FS numbers |
| 16:45:54 | TheSeven | (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 | TheSeven | 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:00 |
| 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 | pamaury | 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 | gevaerts | pamaury: while transferring data at the same time> |
| 17:11:43 | gevaerts | ? |
| 17:12:12 | pamaury | 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 | pamaury | gevaerts: did you try you usb indicator ? |
| 17:21:27 | pamaury | *your |
| 17:22:36 | | Quit Darkknight512 (Client Quit) |
| 17:22:46 | | Join Darkknight512 [0] (~63e16e06@giant.haxx.se) |
| 17:23:51 | gevaerts | no |
| 17:25:44 | ranma | /* Sansa can't be powered off while charging */ |
| 17:25:48 | ranma | /* #define HAVE_POWEROFF_WHILE_CHARGING */ |
| 17:26:10 | ranma | Any reason for this? OF allows poweroff while charging apparently... (on my C200v2) |
| 17:26:23 | Torne | is it really off, or just turning off the screen, or some kind of sleep mode? |
| 17:26:29 | Torne | The reason is right there |
| 17:26:44 | ranma | Any reason for that statement I mean |
| 17:26:55 | gevaerts | This might be inherited from the v1s |
| 17:26:56 | | Join _silentAssassin [0] (~mrigesh@iws3.iiita.ac.in) |
| 17:26:57 | ranma | It doesn't say why it's supposed to be not allow and OF allows it |
| 17:27:00 | Torne | 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 | Torne | when turned off (from rockbox) does it turn itself on when you connect power? |
| 17:27:40 | Torne | if so that suggests they are almost certainly right :) |
| 17:28:20 | Torne | (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 | pamaury | 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 | gevaerts | pamaury: have a look at some old gsoc ideas pages. I think I proposed that last year |
| 17:30:48 | ranma | 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 | Torne | ranma: is it really booting up, though |
| 17:31:05 | Torne | ? |
| 17:31:34 | ranma | It shows the sandisk bootloader, but as said, pending real confirmation. |
| 17:32:12 | Torne | well, try it |
| 17:32:26 | Torne | if you uncomment that define, it will stop preventing you from powering off |
| 17:32:37 | Torne | if you then find it just turns itself straight back on again, then it doesn't work. |
| 17:33:00 | ranma | 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 | ranma | Make that reinsert. |
| 17:33:34 | ranma | Ok, I'll try a rockbox image with #define HAVE_POWEROFF_WHILE_CHARGING |
| 17:33:44 | Torne | 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 | Llorean | 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 | Llorean | 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 | Torne | well, that too. is it actually charging :) |
| 17:35:14 | ranma | Llorean: At least it would be nice to show an info message to that extent in the GUI. |
| 17:35:54 | ranma | I was wondering before why I couldn't poweroff properly sometimes until I realized it's only with charger connected... |
| 17:36:11 | Torne | Anyway, all that define does is stop you powering off. |
| 17:36:18 | Torne | er, the lack of it, i mean |
| 17:36:37 | ranma | Yeah, I figured that much |
| 17:36:37 | Torne | 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 | ranma | 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 |
| 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 | saratoga | the AMS players have software controlled charging, so you won't be able to charge with the player off |
| 18:12:04 | Torne | ah :) |
| 18:15:14 | Torne | is it normal that the SBS flashes on and off when splashes and the like are happening? |
| 18:16:21 | Torne | my player is doing the committing datbase super long splash |
| 18:16:29 | Torne | which i guess is a bunch of shorter ones in a row |
| 18:16:41 | Torne | 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 | jae | ;) |
| 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 |
| 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 | funman | Torne: is there a reason why STORAGE_ALIGN_MASK isn't using CACHEALIGN macros ? |
| 19:04:49 | Torne | funman: because nobody involved in 9708 noticed them |
| 19:05:05 | funman | o |
| 19:05:07 | funman | ok* |
| 19:05:08 | Torne | so, i guess i actually mean "no" :0 |
| 19:05:11 | Torne | feel free to change it |
| 19:05:17 | Torne | in fact you are encouraged to do so :) |
| 19:05:24 | funman | well i could certainly |
| 19:05:47 | | Join Kitar|st [0] (Kitr88@BSN-142-107-58.dial-up.dsl.siol.net) |
| 19:05:49 | Torne | It might be better if it was more than just a mask defined, also |
| 19:05:51 | funman | but so far only PP defines PROC_NEEDS_CACHEALIGN, i need to figure why (perhaps something to do with the COP) |
| 19:06:09 | Torne | Well, only PP defines STORAGE_ALIGN_MASK |
| 19:06:13 | Torne | so.. yeah |
| 19:06:15 | funman | and ipodnano2g |
| 19:06:35 | Torne | Oh. yeah, i suggested to TheSeven he could reuse the 9708 code for that |
| 19:06:41 | Torne | Well, define it on nano2g |
| 19:06:43 | funman | and you don't know about my plan for sansa AMS |
| 19:06:47 | Torne | Yah |
| 19:06:59 | Torne | I just mean, is there any reason not to have the cachealign stuff defined on every target with a cache? |
| 19:07:03 | funman | right but PROC_NEEDS_CACHEALIGN has other implications so i don't want to enable it blindly |
| 19:07:06 | Torne | Oh, hm |
| 19:07:18 | Torne | i guess it actually goes and aligns a bunch of stuff, rihgt. |
| 19:07:25 | Torne | pardon me, i've been at work for too long ;) |
| 19:07:40 | Torne | hm |
| 19:07:46 | | Quit kunal (Quit: Ex-Chat) |
| 19:08:00 | | Join kunal [0] (~kunal@121.242.23.197) |
| 19:08:01 | Torne | I suspect the "right" answer is to have a stnadard way of specifying what cache alignment *is* for a given platform |
| 19:08:02 | funman | the comment in mpegplayer makes me think this is needed for dual core |
| 19:08:07 | Torne | i.e. 16-byte-aligned, 32-byte-aligned |
| 19:08:23 | Torne | 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 | Torne | and define STORAGE_ALIGN_WHATEVER for platforms that benefit from storage_* calls being aligned |
| 19:08:53 | funman | yup |
| 19:08:56 | Torne | such that htey are enable-able independantly |
| 19:09:02 | Torne | but get their definition of alignment from the same place. |
| 19:09:16 | funman | btw grep STORAGE_ALIGN_MASK only shows buffering.c, calls in fat.c are already aligned? |
| 19:09:26 | Torne | no, i've not gotten around to fixing anywhere else |
| 19:09:36 | Torne | normal non-buffering accesses are mostly *not* aligned atm |
| 19:09:38 | Torne | so DMA is not used |
| 19:09:47 | Torne | that's one of the things that's sitll left to do |
| 19:10:03 | Torne | 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 | Torne | fat.c is not quite the only place where it would be useful |
| 19:11:06 | Torne | there's things like the image loaders for album art, etc |
| 19:11:19 | Torne | 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 | Torne | 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 | funman | yup |
| 19:12:15 | Torne | again if you wanna go and align all the buffers in fat.c please do ;) |
| 19:12:47 | funman | i need to modify the AMS sd driver(s) because now they use an aligned extra buffer |
| 19:12:48 | Torne | 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 | Torne | if someone else does it first then goody for them :) |
| 19:17:25 | | Part RoronoaZoro ("Leaving") |
| 19:17:26 | Torne | but yeah thanks for pointing it out, i hadn't noticed. |
| 19:17:57 | CIA-5 | New commit by funman (r25330): mpegplayer: align video output data structure only on multicore |
| 19:18:06 | funman | thanks for the work ^^ |
| 19:18:21 | *** | Saving seen data "./dancer.seen" |
| 19:18:21 | Torne | psh, dreamlayers did most of the work :0 |
| 19:18:24 | Torne | but he seems to have vanished |
| 19:18:48 | Torne | 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 | funman | TheSeven, Torne: http://pastie.org/886989 |
| 19:26:40 | funman | hm actually STORAGE_ALIGN_MASK could go in system.h with other alignement attributes |
| 19:28:32 | funman | 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 | amiconn | 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 | linuxstb | 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 | amiconn | Iirc it does, but I'm not 100% sure |
| 19:52:02 | amiconn | Who uses the OF when (s)he has rockbox installed? |
| 19:52:25 | linuxstb | 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 | linuxstb | amiconn: Exactly. That's why I can't remember... |
| 19:52:39 | funman | linuxstb: ah i forgot to do that after they've been tested |
| 19:52:47 | funman | thanks for reminding |
| 19:52:53 | | Join DerPapst [0] (~DerPapst@p5797C96D.dip.t-dialin.net) |
| 19:53:07 | linuxstb | 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 | funman | they are RC because only a few people tested them so far |
| 19:54:00 | linuxstb | Then why are they on the download server? IMO, either they're released, or they're not... |
| 19:54:00 | amiconn | Well, on the H300 there's one situation when you might want to use the OF: USB host |
| 19:54:05 | funman | my fuze still says RC too |
| 19:54:46 | linuxstb | funman: Yes, I know. And they shouldn't be either (I've mentioned that in the past). |
| 19:55:24 | funman | 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 | funman | there's already a "bootloader_ams_v1" tag, i don't think "bootloader_amsv2_v1" would be fine |
| 19:58:22 | linuxstb | Just call it bootloader_sansaclipv2_sansaclipp_v1 |
| 19:58:32 | linuxstb | (or whatever the official target names are) |
| 19:59:59 | CIA-5 | New commit by funman (r25331): Tag release v1 of Clipv2 and Clip+ bootloaders |
| 20:00 |
| 20:00:52 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 20:01:03 | | Quit stripwax (Client Quit) |
| 20:02:26 | funman | Clipv1 bootloader says "Boot Ver. 1.0", Clipv2/+ say "Boot 1.0-RC" and e200v2/fuzev1 say "Boot Ver. 1.0RC" |
| 20:03:21 | funman | iirc mc2739 had rebuilt fuzev1/e200v2 bootloaders to change the version string, dunno what happened |
| 20:04:13 | linuxstb | 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 | funman | linuxstb: i didn't say they hadn't been tested |
| 20:07:55 | linuxstb | 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 | funman | 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 | ender` | include a build number in the version string? |
| 20:09:55 | funman | 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 | linuxstb | 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 | funman | 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 | topik | 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 | funman | 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 | topik | 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 | funman | wear levelling should be handled by SD card |
| 20:20:55 | topik | firmware is on the internal sd card? |
| 20:21:55 | funman | yes |
| 20:23:41 | topik | 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 | linuxstb | 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 | funman | i'm not going to work on the manuals now |
| 20:32:16 | funman | 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 | Llorean | topik: Do you know how to disable it? |
| 20:34:45 | topik | no, i was hoping someone who disassembled the OF had come across it |
| 20:35:37 | Bagder | 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 | linuxstb | funman: I'll give the manual a shot... |
| 20:40:23 | funman | thanks |
| 20:40:35 | gevaerts | Don't kill it entirely! |
| 20:40:39 | funman | who can test a bootloader on e200v2 and clipv2 ? |
| 20:41:48 | topik | Bagder: "that info" being the device's decision to do the "rebuilding database" action? |
| 20:41:56 | Bagder | yes |
| 20:41:58 | Luca_S | Bagder: I'd be interested in disabling the 'refreshing database' feature on my fuzev2... how can I dump the nand content? |
| 20:42:19 | Bagder | we just dd'ed it |
| 20:50:11 | | Quit planetbeing (Quit: planetbeing) |
| 20:51:12 | topik | the OF must respond in its code to the settings on the nand though |
| 20:51:55 | topik | 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 | Bagder | yes, but in the days we could just set the "right" value to trick the OF |
| 20:53:02 | topik | that's clever too |
| 20:54:58 | funman | ender`: would you try a clipv2 bootloader ? just check that it works and that it prints "Boot Ver. 1.0" |
| 20:58:56 | ender` | funman: sure |
| 20:59:20 | | Join perfectdrug [0] (~marko@p5B0EEC1C.dip.t-dialin.net) |
| 20:59:23 | funman | i can't upload files, just give me your email in private |
| 21:00 |
| 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 | funman | "best viewed in opera 3.x on windows 3.11" |
| 21:10:57 | linuxstb | Am I right in thinking the clipv1 and clipv2 look the same, but the clip+ is different? |
| 21:11:06 | funman | linuxstb: yes |
| 21:11:08 | | Join b0hoon [0] (~quassel@xdsl-7253.bielsko.dialog.net.pl) |
| 21:11:36 | CIA-5 | New commit by dave (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 | funman | 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 | linuxstb | 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 | Bagder | yes, it should be fairly automatic |
| 21:16:05 | Bagder | 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 | CIA-5 | New commit by dave (r25333): Sansa Clipv2 and Clip+ now have their own manuals. Also add "v1" to the label for the clipv1 |
| 21:16:56 | Bagder | where $name is the model name OR the specific 'manual' field in build.pm |
| 21:17:25 | linuxstb | OK, thanks. I've updated builds.pm. Anything else to do? |
| 21:17:36 | Bagder | 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 | linuxstb | Bagder: Can you easily force a manual build? Or shall we just wait until tomorrow? |
| 21:19:14 | Bagder | 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 | linuxstb | 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 | funman | linuxstb: same for fuze and e200? |
| 21:21:02 | linuxstb | Err, yes. Although I would have thought the e200 existed when Zagor did the big rename? |
| 21:21:09 | linuxstb | s/e200/e200v2/ |
| 21:21:30 | funman | 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 | linuxstb | funman: Yes, but we won't have manuals until tomorrow morning though. |
| 21:22:33 | funman | linuxstb: I see sansae200 sansam200 sansac200 sansaclip and sansafuze , all of them have a 'v2' model |
| 21:23:31 | linuxstb | 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 | funman | 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 | funman | 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 | linuxstb | 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 | CIA-5 | New commit by b0hoon (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 | CIA-5 | New commit by b0hoon (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 | funman | 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:00 |
| 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 | linuxstb | domonoky: Was the "online services" SoC project your suggestion? |
| 22:17:58 | domonoky | linuxstb: jup, nobody objected to it :-) |
| 22:18:37 | linuxstb | domonoky: I'm just wondering what you think the voice generating service would do? |
| 22:18:50 | linuxstb | (that isn't done by the voice files we already make available) |
| 22:19:34 | domonoky | linuxstb: more languages and voices for example. |
| 22:20:03 | linuxstb | Wouldn't it be better to generate them all nightly - i.e. expand the current system? |
| 22:20:10 | domonoky | but i am more interested in other services like fm-presets, or what ever a student can imagine :-) |
| 22:21:02 | domonoky | linuxstb: sure, thats also possible. if the combination doesnt go up too much. |
| 22:22:22 | domonoky | 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 | linuxstb | 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 | domonoky | 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 | linuxstb | Do we need both an online service and rbutil though? |
| 22:25:47 | linuxstb | I'm guessing rbutil is potentially better, as it can use commercial voices. |
| 22:26:13 | domonoky | yes, rbutil will always be better, but it has accessibility problems :-) |
| 22:26:34 | linuxstb | So the solution to rbutils accessibility problems is an online voice service? ;) |
| 22:26:59 | linuxstb | Could that be an SoC project? |
| 22:27:11 | domonoky | but i am really more keen on other webservices, i just added the voice one too for completeness :-) |
| 22:27:13 | linuxstb | 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 | domonoky | 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 | domonoky | 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 | linuxstb | And then an online service to generate voicefiles for rbutil? ;) |
| 22:30:05 | domonoky | hehe |
| 22:30:58 | domonoky | 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 | linuxstb | 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 | domonoky | i dont know if that is a good project, so many possible blockers. |
| 22:33:00 | linuxstb | s/blockers/opportunities for the student to show initiative/ |
| 22:33:01 | domonoky | For some issues, i posted workarounds in the tracker, but we didnt commit it, because they are too hackish :-) |
| 22:33:29 | linuxstb | 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 | gevaerts | linuxstb: with that reasoning, "Port rockbox to the Zune" would be a perfect project :) |
| 22:33:54 | domonoky | but i would love some SoC project with rbutil, just can image a good defined project at moment. |
| 22:34:06 | linuxstb | gevaerts: I'll go and add it... |
| 22:34:26 | domonoky | +t |
| 22:35:37 | linuxstb | 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 | linuxstb | 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 | xiainx | well, the project says to create a few new services from scracth |
| 22:42:53 | xiainx | 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:00 |
| 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 | Farthen | 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 | domonoky | xiainx: remember, that this is just a suggested goal. So the actual project a student does could get different goals. |
| 23:21:08 | domonoky | 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 | xiainx | yes, well I guess it depends to some degree on the complexity/quality of the service, doesn't it? |
| 23:29:30 | domonoky | sure |
| 23:30:48 | domonoky | if the students wants to create some complex/big project, he perhaps will only work on this. |
| 23:31:19 | domonoky | s/this/one |
| 23:32:05 | domonoky | 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 | xiainx | Yeah, I'm actually kind of interested in that project |
| 23:32:51 | domonoky | 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 | domonoky | 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 | xiainx | well, I'm kind of interested in the fmpresets database one, and/or the voicefiles one |
| 23:35:18 | xiainx | 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 | domonoky | xiainx: voicefiles can get pretty complicated if you want all the bells and whistles :-) ( i did the voice generation in rbutil) |
| 23:36:30 | xiainx | Oh, really? |
| 23:36:46 | xiainx | What exactly are these voicefiles for? RB's tts system? |
| 23:37:03 | AlexP | RB doesn't have a tts system :) |
| 23:37:07 | xiainx | yet |
| 23:37:27 | AlexP | maybe, but we would hardly be supplying voice files for something that doesn't exist |
| 23:37:29 | domonoky | xiainx: its rockboxs tts replacement. prerecorded audiofiles with menucontent. |
| 23:37:33 | | Quit jae (Client Quit) |
| 23:37:37 | xiainx | Ok |
| 23:37:53 | amiconn | 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 | domonoky | xiainx: rockbox can use this to readout its menus. (there is also a similar thing for files and folders) |
| 23:38:12 | xiainx | Right, okay, I see |
| 23:38:26 | amiconn | 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 | xiainx | So, you could use a tts system to generate the sound files, and store those using a database system? |
| 23:39:26 | domonoky | 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 | AlexP | Keep in mind also that this is three months full time work |
| 23:40:34 | domonoky | 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 | xiainx | 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 | xiainx | Right, that's what I'm wondering, is how much to aim to accomplish! |
| 23:43:00 | domonoky | xiainx: fmpresets service alone is probably not enough work. |
| 23:43:35 | xiainx | Ok |
| 23:44:06 | domonoky | 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 | bluebrother | a website for fm presets shouldn't be much work if it doesn't include fancy features |
| 23:44:52 | bluebrother | and integration in rbutil shouldn't be much work either. |
| 23:46:08 | xiainx | bluebrother: so you think there's time to tackle another project as well over the summer? |
| 23:46:19 | bluebrother | definitely. |
| 23:46:35 | | Quit jae (Quit: leaving) |
| 23:46:49 | bluebrother | 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 | xiainx | domonoky: Something like.... http://qrg.broker.freenet6.net |
| 23:47:14 | | Join jae [0] (~jae@jaerhard.com) |
| 23:47:16 | xiainx | domonoky: That seems to have mostly German frequencies though |
| 23:47:39 | xiainx | bluebrother: Okay, yeah like I said, it depends a lot on how powerful/feature-ful you want it to be |
| 23:48:07 | bluebrother | 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 | domonoky | 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 | bluebrother | 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 | bluebrother | further features are nice but not that important IMO. |
| 23:50:03 | xiainx | Okay |
| 23:51:20 | | Part b0hoon ("GTG. Bye.") |
| 23:51:42 | bluebrother | 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 | xiainx | 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 | bluebrother | no, but it isn't a complex or hard task either. |
| 23:53:12 | xiainx | 4 additional weeks, or 4 weeks total for the whole thing? |
| 23:53:26 | domonoky | 4 total |
| 23:53:29 | xiainx | Okay |
| 23:53:49 | bluebrother | theme site integration for rbutil was done in less than 2 weeks :) |
| 23:53:50 | domonoky | but thats ofcourse my view. others might see it different :-) |
| 23:54:20 | bluebrother | time estimations of course depend on the knowledge of the programmer :) |
| 23:54:25 | domonoky | bluebrother: not true. it was done first by me, and redone by you sometime later :-) |
| 23:54:51 | bluebrother | domonoky: well, as the Qt version was a complete rewrite I didn't count that at all. |
| 23:55:31 | domonoky | :-) |
| 23:56:06 | xiainx | and then what would the rest of the summer be spent doing? the tts thing? themepage? |
| 23:56:29 | bluebrother | 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 | domonoky | translationpages improvements would be nice too. |
| 23:57:10 | bluebrother | what needs to be done about translate.themes.org? |
| 23:57:24 | domonoky | we want bluebrothers rbutil translationpage finsihed and integrated into translate.themes.org :-) |
| 23:57:53 | domonoky | 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 | bluebrother | hmm, rbutilqt is already 2 3/4 years old. Time files ... |
icon identifies that the person is a core developer (has commit access).