| 00:00:31 | bluebrother | too bad that is missing from the wiki :( |
| 00:02:24 | | Join Thundercloud [0] (n=thunderc@82.132.136.182) |
| 00:03:00 | | Quit n1s ("Lämnar") |
| 00:06:20 | | Part CaptainKwel |
| 00:07:37 | | Join MethoS- [0] (n=lem@dyndsl-085-016-166-022.ewe-ip-backbone.de) |
| 00:08:13 | | Quit archivator () |
| 00:08:30 | | Quit midgey|web ("http://www.mibbit.com ajax IRC Client") |
| 00:11:16 | | Join midgey|web [0] (i=8dd54311@gateway/web/ajax/mibbit.com/x-9e376a88bf43aecd) |
| 00:15:16 | | Quit MethoS- (Remote closed the connection) |
| 00:17:22 | | Join planetbeing__ [0] (n=planetbe@24.86.172.128) |
| 00:18:55 | | Quit Thundercloud (Remote closed the connection) |
| 00:19:36 | | Join __lifeless [0] (n=lifeless@188.17.71.101) |
| 00:20:10 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 00:20:10 | | Quit pixelma (Nick collision from services.) |
| 00:20:21 | | Quit amiconn (Nick collision from services.) |
| 00:20:22 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 00:20:23 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 00:20:40 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 00:20:50 | | Quit flydutch ("/* empty */") |
| 00:20:53 | | Quit stripwax (Read error: 110 (Connection timed out)) |
| 00:21:30 | amiconn | bluebrother: See firmware/target/coldfire/iriver/lcd-remote-iriver.c: remote_tick() |
| 00:21:40 | amiconn | It's a certain resistance which is also influenced by the hold switch setting |
| 00:22:50 | | Quit ender` (" If at first you don't succeed, skydiving is not for you.") |
| 00:23:00 | | Quit evilnick_7 ("http://www.mibbit.com ajax IRC Client") |
| 00:25:47 | bluebrother | amiconn: thanks, though I was more looking for the hardware attachment. The hint with the remote might be the key :) |
| 00:25:59 | bluebrother | anyway, time to go for today. |
| 00:26:02 | | Quit MethoS-- (Read error: 113 (No route to host)) |
| 00:26:14 | | Quit bluebrother ("mibbit.com: tomorrow") |
| 00:28:29 | | Quit planetbeing_ (Read error: 110 (Connection timed out)) |
| 00:28:36 | | Quit mirak (Remote closed the connection) |
| 00:34:01 | | Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-5c225c618e997b9b) |
| 00:34:15 | | Quit matsl (Remote closed the connection) |
| 00:34:26 | | Quit shotofadds ("Leaving") |
| 00:34:44 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
| 00:35:06 | | Join _lifeless [0] (n=lifeless@90.151.215.92) |
| 00:36:55 | | Quit __lifeless (Connection timed out) |
| 00:37:59 | | Quit jgarvey ("Leaving") |
| 00:38:01 | *** | Saving seen data "./dancer.seen" |
| 00:38:52 | BradPhillips | Wiki edits done: http://www.rockbox.org/twiki/bin/view/Main/IpodAccessories |
| 00:39:00 | BradPhillips | Thanks for all your work guys. |
| 00:39:25 | | Quit Riku (Read error: 110 (Connection timed out)) |
| 00:42:18 | | Quit bertrik ("Leaving") |
| 00:42:36 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 00:43:41 | | Quit krazykit (Read error: 54 (Connection reset by peer)) |
| 00:44:16 | | Join krazykit [0] (n=kkit@ppp-70-236-44-223.dsl.ipltin.ameritech.net) |
| 00:44:16 | | Quit planetbeing__ () |
| 00:45:58 | | Join sarixe [0] (n=sarixe@pool-68-239-154-103.nwrk.east.verizon.net) |
| 00:59:50 | | Join syn4pse [0] (n=chatzill@user-69-1-40-117.knology.net) |
| 01:00 |
| 01:00:38 | | Quit faemir (Read error: 104 (Connection reset by peer)) |
| 01:00:38 | | Quit BradPhillips ("CGI:IRC (EOF)") |
| 01:00:44 | syn4pse | i am getting an Incompatible Version error when trying to run my plugin. Is there somewhere i should look? |
| 01:01:15 | | Quit barrywardell () |
| 01:03:10 | cool_walking_ | I think that means your .rock isn't in sync with the rest of your Rockbox build. |
| 01:03:37 | cool_walking_ | Try make clean and recompile |
| 01:05:06 | syn4pse | ok i'll give it a shot |
| 01:07:19 | syn4pse | funny, though, i patched a clean source tree. weird. |
| 01:10:07 | cool_walking_ | it worked? |
| 01:12:03 | syn4pse | not sure yet, it's an old machine i'm compiling on, a P3 |
| 01:12:24 | syn4pse | i'll let you know in about 20 minutes when i get back |
| 01:12:25 | amiconn | Unhelpful: Btw, *if* PF needs to be an overlay on hwcodec, it probably means that it needs to be turned into a SUBDIR plugin as well |
| 01:13:06 | Unhelpful | that should be simple, it's only the one source :) |
| 01:13:13 | | Quit ibseco (Read error: 113 (No route to host)) |
| 01:13:50 | amiconn | This is for two reasons. (1) An overlay plugin needs its own .make file. (2) The loader plugin takes the filename of the original plugin (source and binary) |
| 01:14:29 | amiconn | But we'll see. |
| 01:15:11 | Unhelpful | right, i saw how overlays work when i did plugin API init. if the plugin itself fits in the buffer, we might just ifdef around using the audio buffer instead of the plugin buffer for all of the dynamic memory |
| 01:16:10 | Unhelpful | ah, get_metadata was the one i remembered existing but not being exported on hwcodec |
| 01:16:33 | amiconn | Yeah, no plugin on hwcodec used it so far |
| 01:17:04 | preglow | man, just tried native usb |
| 01:17:07 | preglow | sweet as hell |
| 01:17:07 | amiconn | Just un-ifdef it (and don't forget to bump both api versions, as this un-ifdefing is backwards incompatible) |
| 01:17:40 | Unhelpful | already done on my local branch - plugin code+statics is <32KiB, it appears. |
| 01:17:48 | | Quit jhMikeS (Nick collision from services.) |
| 01:17:54 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 01:18:04 | amiconn | niice |
| 01:18:10 | Unhelpful | probably a *huge* savings in the native splash bitmap for mono instead of color |
| 01:19:13 | | Quit parafin (Read error: 104 (Connection reset by peer)) |
| 01:19:41 | | Join parafin [0] (i=parafin@paraf.in) |
| 01:20:05 | rasher | preglow: Yeah, it's really really really nice. |
| 01:20:17 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
| 01:20:51 | Unhelpful | it makes me not mind using my e200 as a test target :) |
| 01:21:00 | | Quit FlynDice (Remote closed the connection) |
| 01:21:26 | | Quit midgey|web ("http://www.mibbit.com ajax IRC Client") |
| 01:22:54 | | Part toffe82 |
| 01:23:23 | Unhelpful | i think that using audio buffer if PLUGIN_BUFFER_SIZE is <=64KiB, otherwise plugin buffer, is probably reasonable... are there any targets using fairly large screens, especially color ones, with the really tiny plugin buffer? |
| 01:32:39 | | Quit parafin (Read error: 104 (Connection reset by peer)) |
| 01:34:04 | | Join parafin [0] (i=parafin@paraf.in) |
| 01:34:52 | Unhelpful | working in ondio sp sim... and builds for target, though of course i can't test. |
| 01:37:27 | Llorean | Unhelpful: No, there are only the Archos targets with smaller plugin buffers among currently supported targets AFAIK. In the future the Clip is going to be limited, but it may not even need a compressed audio buffer by the time it makes it to supported, so it's pretty hard to guess what the situation there will be like |
| 01:38:40 | Unhelpful | no compressed audio buffer? how would that work, direct reads from flash into a decode buffer? |
| 01:39:12 | Llorean | Yup |
| 01:39:51 | Unhelpful | hrm, would there be a benefit to applying that to non-tinymem flash targets? |
| 01:40:02 | syn4pse | i tried making clean but i still get "incompatible version" when i try to run my plugin |
| 01:40:19 | Llorean | Unhelpful: it seems to hurt the battery life in its current form. If it proves not to, then yes there would be. |
| 01:40:48 | | Join jj19000 [0] (n=477f192b@gateway/web/cgi-irc/labb.contactor.se/x-7af58c412b22b6d5) |
| 01:41:13 | Llorean | Just making the plugin buffer larger is beneficial to many plugins (at the cost of being harmful to music). On these targets you could basically take the "all spare memory is plugin buffer" approach |
| 01:41:27 | Llorean | This would let things like the jpegviewer display larger images without needing to stop music, etc. |
| 01:41:36 | amiconn | Llorean: I'd expect continuous flash reading to hurt battery life. The flash chips do auto-suspend when not being accessed for a few milliseconds. With continuous reading that's not going to happen |
| 01:41:54 | amiconn | Iow, I think that proper buffering will always be beneficial |
| 01:43:03 | Unhelpful | amiconn: if you're up for testing it, i have a patch for hwcodec pictureflow |
| 01:43:29 | jj19000 | hi im a total newb here but i would like to know if there is a proposed release date for the port to the sansa clip |
| 01:43:35 | amiconn | A smallish audio buffer might be sufficient though, perhaps a few dozen seconds of compressed audio |
| 01:43:41 | Llorean | jj19000: No. It's impossible to predict when it will be ready. |
| 01:44:00 | jj19000 | oh.ok. |
| 01:44:05 | jj19000 | thx |
| 01:44:19 | Llorean | amiconn: Well, I can't imagine it helps _too_ many plugins anyway |
| 01:44:47 | * | Llorean does build with a 50% larger plugin buffer for his Gigabeats anyway. |
| 01:45:00 | jj19000 | are they working on it?hope im not buggin u |
| 01:45:05 | jj19000 | you* |
| 01:45:33 | Llorean | jj19000: Again, impossible to say. it's entirely volunteer effort in spare time. Nobody's reported any progress recently though, or you'd see it in the forum thread |
| 01:47:08 | jj19000 | ok,i have a sansa clip and if there is a way that i can help that would not brick it, i will |
| 01:47:26 | syn4pse | where might i find the possible causes of a "incompatible version" error for a plugin (all others work fine, this is for my plugin) |
| 01:48:25 | Unhelpful | syn4pse: i'd rebuild the plugin, probably. the plugin loader checks if the core's plugin API version matches the one with which the plugin was build, since changing the plugin API can break plugins |
| 01:49:13 | syn4pse | hmm i wonder what i've done wrong, i'm building this from fresh source |
| 01:50:07 | syn4pse | maybe i made a dumb error, i'll go back and check |
| 01:50:16 | Unhelpful | i don't know, but generally a make clean, a rebuild, and installing both the rockbox and the plugin binaries should make sure that they're built to the same API version |
| 01:50:22 | Llorean | Maybe your plugin isn't compiling, so you didn't overwrite the old one when you copied over? |
| 01:51:24 | syn4pse | perhaps that is the problem. |
| 01:51:33 | syn4pse | think i should wipe .rockbox on the ipod? |
| 01:51:43 | syn4pse | and i'll look to see if it compiles |
| 01:52:54 | | Quit Rob2223 () |
| 01:53:28 | | Join Rob2222 [0] (n=Miranda@p4FDCC1D9.dip.t-dialin.net) |
| 01:55:02 | jj19000 | Llorean:is there a way i can help any one? |
| 01:55:16 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 01:55:38 | Llorean | jj19000: Not really unless you can actually do the programming work to implement things |
| 01:56:08 | jj19000 | timeframe on that? |
| 01:56:53 | Llorean | On what? When you'll be able to do the programming work? |
| 01:57:47 | jj19000 | no,sorry for not clarifying,how much time would i need to put into it? |
| 01:58:09 | Llorean | That depends a lot on you. What you know already, how you are at learning. It's not a small job, at all. |
| 01:59:30 | jj19000 | ok,i am a very fast learner,and i dont know if this relates,but i have put in a bit of time on visual basic and vc# |
| 02:00 |
| 02:00:27 | Llorean | Well, basically the process is 1) Learn to compile Rockbox, 2) Put compiled Rockbox on your clip and see what does and does not work, 3) Investigate what doesn't work, attempting to learn what is necessary to solve the problems as you go. |
| 02:00:35 | Llorean | You're going to need to learn C and probably ARM assembly.] |
| 02:01:01 | jj19000 | is c even hard to learn? |
| 02:02:43 | Llorean | That's very subjective. |
| 02:03:27 | jj19000 | what do you mean |
| 02:03:29 | jj19000 | ? |
| 02:03:48 | Llorean | I mean "Just because I think it's one way doesn't mean you will" |
| 02:04:16 | jj19000 | ok |
| 02:05:26 | jj19000 | and the ARM part? |
| 02:05:48 | jj19000 | i know it has sumthing to do with proccessors |
| 02:06:06 | jj19000 | right? |
| 02:06:11 | ze | ARM _assembly_ |
| 02:07:51 | | Join avis [0] (n=ident@pdpc/supporter/student/avis) |
| 02:09:56 | jj19000 | hello?Llorean? |
| 02:09:58 | | Join Llorean1 [0] (n=DarkkOne@adsl-70-241-29-2.dsl.hstntx.swbell.net) |
| 02:11:16 | jj19000 | Llorean? |
| 02:11:43 | Llorean1 | jj19000: Ze already answered what it is. |
| 02:11:53 | Llorean1 | Google's also full of information on it. |
| 02:12:07 | | Quit Llorean (Nick collision from services.) |
| 02:12:09 | | Nick Llorean1 is now known as Llorean (n=DarkkOne@adsl-70-241-29-2.dsl.hstntx.swbell.net) |
| 02:14:38 | | Quit jj19000 ("CGI:IRC (EOF)") |
| 02:15:16 | | Join jj19000 [0] (n=477f192b@gateway/web/cgi-irc/labb.contactor.se/x-03f207c0bd86dec6) |
| 02:15:22 | | Nick jj19000 is now known as jj1901 (n=477f192b@gateway/web/cgi-irc/labb.contactor.se/x-03f207c0bd86dec6) |
| 02:15:25 | | Quit moos ("Rockbox rules the DAP world") |
| 02:15:53 | | Nick jj1901 is now known as jj19000 (n=477f192b@gateway/web/cgi-irc/labb.contactor.se/x-03f207c0bd86dec6) |
| 02:16:27 | jj19000 | sorry Llorean computer went nuts on me there for a second |
| 02:16:40 | jj19000 | logged me off |
| 02:17:52 | Llorean | jj19000: Google can tell you lots about ARM assembly |
| 02:17:52 | soap | If I submit a patch for generic (cross-platform) "Battery Runtime Scale Factor" - what are the odds of it getting accepted. |
| 02:18:17 | Llorean | soap: What kind of setting will it be. |
| 02:18:25 | soap | My idea is this: Depending on settings used, your runtime can vary dramaticly from the stock discharge curve per target. |
| 02:18:42 | jj19000 | ok then i will return in a few minuites |
| 02:18:47 | Llorean | Are you going to have them pick something like "80%" to say "I'm getting 80% of expected time" or are you going to have them pick "14h" so that it gives the remaining time as "battery % * 14 hours" |
| 02:19:10 | soap | My idea for a solution is to have a field _only in the config file_ of 1-100 (%). Which will be a scale factor applied to the calculated remaining runtime. |
| 02:20:21 | soap | This is one of those things I do not think needs a menu item, as for most people it will be a set-and-forget. The few who will want to toggle the settings can do it with .cfg files, and I'm trying to minimize the bloat inflicted upon people who don't give two shits about the setting in general. |
| 02:21:20 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 02:23:25 | | Quit tessarakt ("Client exiting") |
| 02:24:46 | | Join Llorean [0] (n=DarkkOne@adsl-70-241-29-2.dsl.hstntx.swbell.net) |
| 02:25:53 | | Join JdGordon [0] (n=jonno@c-98-203-252-78.hsd1.wa.comcast.net) |
| 02:27:53 | Llorean | soap: I think if there's a scale factor it should be more intuitive. An option where the "expected" runtime is highlighted by default and the other values are .95, .9, .85, .8 etc of it. |
| 02:28:01 | Llorean | I don't like config-only options. |
| 02:28:20 | Llorean | Another way to do it is to do some "real" math and try to approximate the runtime penalty of various CPU intensive features and have no option involved. |
| 02:29:24 | soap | you mean have a covert scaler, and (for example) every eq band would lower said scaler x%? |
| 02:29:36 | rasher | Is someone running a copy of the current themesite that I could look at? |
| 02:29:46 | soap | current being? |
| 02:29:56 | rasher | The one in SVN, possibly. The old one works too, I guess |
| 02:32:12 | | Join planetbeing_ [0] (n=planetbe@174.6.121.106) |
| 02:34:27 | Llorean | soap: Basically, yes. |
| 02:35:59 | | Quit jj19000 ("CGI:IRC") |
| 02:36:35 | | Join midgey [0] (n=tjross@71.238.148.140) |
| 02:38:03 | *** | Saving seen data "./dancer.seen" |
| 02:40:01 | soap | Is such a feature really going to get approval if the binsize is so much larger? I pictured this as a fringe use item, and that's why I was thinking along the line I was thinking - to minimize its impact. |
| 02:40:39 | Llorean | I can't imagine it raising the binsize much either way, but I dunno |
| 02:40:59 | Llorean | I mean yeah, the "clever" one would be more than your way, but I just don't like having config-only settings still |
| 02:41:50 | soap | I'll look into it. Damn and here I thought I had a task I could bite off. ;) |
| 02:42:03 | Llorean | Hahaha |
| 02:42:10 | Llorean | Well, a menu setting should be pretty trivial. |
| 02:43:57 | | Quit goffa (Read error: 104 (Connection reset by peer)) |
| 02:45:39 | soap | menu I can do. Your auto-compute-impact-on-runtime-of-settings one would be tough. |
| 02:47:57 | soap | For example. When playing musepack, replaygain probably has no impact on battery life at all, as you likely still haven't triggered boost (except when buffering, etc) - but if you have an EQ band on, now you're out of your (PP speaking here) free 30Mhz, (call MPC 24, call RG 5, call EQ 10Mhz) and now RG's impact on boost ratio will be seen in its full glory and runtime will be impacted by RG. |
| 02:51:19 | Unhelpful | soap: well, it's just a matter of whether you're hitting the threshold or not there, isn't it? the decode cost is contstant until you hit a threshold, and each additional bit of processing has a linear contribution after you exceed that threshold |
| 02:51:34 | | Quit sarixe ("Leaving") |
| 02:51:47 | soap | A threshold which moves depending on the specifics of the track being played. |
| 02:52:35 | Unhelpful | yay, adding complexity :/ |
| 02:53:55 | Llorean | soap: you could simply have a counter for "expected MHZ needed" and add the costs for filters/etc to that, and a small formula to convert it into an approximated drain. |
| 02:53:57 | soap | Which is why I think my original proposal (a simple user-set scale factor) is in the sweet spot of the "80/20" split. Accomplishes 80% of the ideal result with 20% of the code. |
| 02:54:16 | Llorean | Probably true. |
| 02:54:28 | Llorean | My point was more "I think if it's not going to have a menu option, it needs to not require user input" |
| 02:54:51 | soap | right - you'd need to calc "expected MHZ" and "known mA" (backlight, accessory power, BCM, etc) |
| 02:55:26 | Llorean | Yes, but most of those are constant. |
| 02:55:29 | soap | and then convert the expected MHz into mA and merge |
| 02:55:29 | Unhelpful | you could have an exponentially weighted running average of boost ratio, even. with a fairly long average, it might decently account for the user's typical usage of features/codecs. |
| 02:55:34 | Llorean | So mhz * cost per mhz + constants. |
| 02:57:00 | soap | Unhelpful: so ignore "MHz costs" - go simply with weighted average of actual MHz consumed + known constants? |
| 02:57:41 | Unhelpful | can't some of the "constant" costs turn on an off? surely the backlight cost depends on how much time it spends on, which depends on how often the user interacts? |
| 02:57:43 | soap | ("MHz costs" = known MHz hits per feature taking threshold into consideration) |
| 02:58:15 | Llorean | I don't think we can ever account for backlight cost. |
| 02:58:20 | soap | right - which leads us back to either setting a fixed scale factor or calculating a "dumb" dynamic scale factor based on historical usage. |
| 02:59:08 | Unhelpful | well, we have a few *truly* fixed costs, i'd think? and each of the variable costs can have its own EWMA, they're cheap to calculate and cheap to store. |
| 02:59:22 | soap | really slick to write to a "mA log" every time the disk is hit, and exp. scale the last N entries and use that. |
| 02:59:52 | soap | calc the log file entries off of the user-reported capacity of battery and read percentages. |
| 03:00 |
| 03:00:55 | soap | If you did it that way - the bin/mem size could be almost entirely shifted to the users, with minimal impact (menu entry) on the non-users. |
| 03:01:15 | soap | as opposed to cluttering everybody's bin with all the calcs per feature. |
| 03:02:08 | | Join goffa [0] (n=goffa@216.220.23.105) |
| 03:02:30 | | Join __lifeless [0] (n=lifeless@94.51.201.82) |
| 03:09:17 | | Quit syn4pse ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
| 03:16:38 | | Quit __lifeless (Read error: 145 (Connection timed out)) |
| 03:19:17 | | Quit _lifeless (Read error: 113 (No route to host)) |
| 03:19:37 | | Join Ridayah_ [0] (n=ridayah@173-19-228-175.client.mchsi.com) |
| 03:20:18 | Unhelpful | soap: if you store the features in a list or table, you can use the same code to update each regardless of how many are involved. what are the big "non-CPU dynamic costs"... backlight and disk spin? |
| 03:20:26 | | Quit Ridayah (Read error: 104 (Connection reset by peer)) |
| 03:21:28 | | Nick Ridayah_ is now known as Ridayah (n=ridayah@173-19-228-175.client.mchsi.com) |
| 03:22:25 | Llorean | Unhelpful: Volume, possibly. Not necessarily "big" but "non-CPU". |
| 03:23:53 | Unhelpful | how? some targets have a variable amp stage, while others have a fixed amp stage and a variable attenuator? |
| 03:28:06 | Llorean | I don't know how in any technical sense. I just remember it being reported that a battery bench at -20 vs 0 seemed to show measurable difference. This could've been the usual measurement error, I didn't catch how difference it was |
| 03:32:46 | Unhelpful | hrm. if we can't measure the actual change in usage, we can't account for it, anyway, though |
| 03:35:20 | | Join _lifeless [0] (n=lifeless@90.150.119.103) |
| 03:36:31 | | Quit jhulst (Remote closed the connection) |
| 03:36:46 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
| 03:36:48 | saratoga | i doubt replaygain has a measurable impact on battery life |
| 03:39:02 | | Quit awake_ (Read error: 110 (Connection timed out)) |
| 03:39:36 | | Join awake_ [0] (n=Zzz@c122-106-54-254.rivrw1.nsw.optusnet.com.au) |
| 03:45:54 | | Join yhuang [0] (n=yhuang@unaffiliated/yhuang) |
| 03:47:46 | soap | Unhelpful: backlight, disk spin, LCD controller (at least the 5Gs can be turned off), accessory power (again 5G / nano), LCD remote, normal remote? |
| 03:48:24 | soap | saratoga: you don't expect it to take at least 1Mhz? |
| 03:49:46 | | Quit HackyKid (Read error: 60 (Operation timed out)) |
| 03:53:40 | | Quit BUMBACL0T (Connection timed out) |
| 03:55:51 | | Join BUMBACL0T [0] (n=ORF@unaffiliated/bumbacl0t) |
| 04:00 |
| 04:05:27 | | Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) |
| 04:06:22 | | Join midijunkie41 [0] (n=Miranda@pD9E54149.dip0.t-ipconnect.de) |
| 04:06:37 | Unhelpful | soap: that's quite a short list. i'd say the hit, if we have a generic EWMA-update function and ways to fetch the state of each factor, would be pretty small for always tracking all of them... getting their state and contribution would be deeper into rockbox core than i've ventured yet, though. |
| 04:08:15 | | Join blkhawk- [0] (n=blkhawk@f051132242.adsl.alicedsl.de) |
| 04:10:22 | | Quit BlakeJohnson86 (Remote closed the connection) |
| 04:13:34 | | Join tarbo_ [0] (n=me@unaffiliated/tarbo) |
| 04:15:09 | | Quit yhuang ("Leaving") |
| 04:16:13 | saratoga | soap: at worst it should be one mul per sample, which is still only 88200 muls a second, less then 1 MHz |
| 04:16:21 | saratoga | and anyway i think the mul probably has to happen anyway |
| 04:16:26 | | Quit tarbo (Connection timed out) |
| 04:16:27 | soap | yes, Unhelpful, there is then the fact of determing a mA value for the static hits, and a mA value for each MHz on each target. |
| 04:16:31 | saratoga | but i haven't looked so i could be wrong |
| 04:16:32 | | Quit rocko ("Leaving") |
| 04:17:19 | soap | ok, saratoga, that does sound awfully low - so perhaps it was a poor choice of example by me - but it made my point well enough to get Unhelpful to bring up the key word threshold. |
| 04:17:39 | soap | *key word "threshold". |
| 04:17:40 | | Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) |
| 04:17:59 | Unhelpful | soap: true... for ones that have a simple on/off configuration, it's easy to have a struct on_off_current_cost, although it clearly needs a better name :) |
| 04:19:26 | | Quit Aurix_Lexico (Remote closed the connection) |
| 04:19:59 | soap | thank you for this discussion, and helping me work through my thoughts on this. I'm a bit distracted now, though, thinking about just doing a decaying average of some sort, persistant across reboots on disk. |
| 04:21:05 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 04:21:16 | | Quit Homedawg68 ("—I-n-v-i-s-i-o-n— 3.1 (December '08)") |
| 04:23:13 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 04:24:14 | | Quit midijunkie (Read error: 101 (Network is unreachable)) |
| 04:24:15 | | Quit blkhawk (Read error: 113 (No route to host)) |
| 04:25:13 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@f051132242.adsl.alicedsl.de) |
| 04:26:50 | | Quit midijunkie41 (Read error: 110 (Connection timed out)) |
| 04:29:31 | | Join Barahir_ [0] (n=jonathan@BAAd099.baa.pppool.de) |
| 04:35:04 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 04:35:39 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 04:38:05 | *** | Saving seen data "./dancer.seen" |
| 04:40:27 | | Quit Barahir (Read error: 110 (Connection timed out)) |
| 04:40:37 | | Join Chesteta [0] (i=Chesteta@dyn216.wireless-104.ndsu.NoDak.edu) |
| 04:43:52 | | Quit timc (Remote closed the connection) |
| 04:48:25 | | Join timc [0] (n=aoeu@124.93.243.83) |
| 04:52:50 | | Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) |
| 05:00 |
| 05:04:24 | | Quit Seed ("cu, Andre") |
| 05:25:03 | | Quit Horschti ("Verlassend") |
| 05:28:06 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-88e5edcf5da7653d) |
| 05:29:51 | | Quit Llorean (Read error: 54 (Connection reset by peer)) |
| 05:29:58 | | Join yhuang [0] (n=yhuang@unaffiliated/yhuang) |
| 05:30:04 | | Join Llorean [0] (n=DarkkOne@adsl-70-241-29-2.dsl.hstntx.swbell.net) |
| 05:30:35 | | Quit yhuang (Client Quit) |
| 05:30:56 | | Join yhuang [0] (n=yhuang@unaffiliated/yhuang) |
| 05:35:56 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
| 05:38:03 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 05:47:43 | | Join killan_ [0] (n=nnscript@c-02fc70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 05:48:06 | | Quit killan (Read error: 54 (Connection reset by peer)) |
| 05:56:32 | gibbon_ | soap, Unhelpful: wouldn't it me much easier to have two tracking averages? a bit like load average in the linux kernel? one accounts the actual battery drain (like its estimated for the battery level anyway) for the last ... well, lets say 5 minutes of rockbox usage, another does the same for about 60minues ... |
| 05:57:28 | gibbon_ | that way, the impact of a singe feature can be visualized to the user in a very simple way, spikes are cut off... |
| 05:57:36 | Unhelpful | what would that accomplish, vs using a weighted moving average of a reasonable length? |
| 05:58:18 | Unhelpful | i thought the goal was to make time-remaining estimates accurate, not to let the user visualize per-feature runtime impacte |
| 05:59:26 | gibbon_ | Unhelpful: maybe i get soap's idea terribly wrong... but the user could choose between two modes of battery level display... one that is based on a short term average, so its fairly accurate considering continous use of the device in the accounted fashion... |
| 06:00 |
| 06:00:10 | gibbon_ | the other more or less based on a long term average... maybe for people who don't fiddle with their settings that much |
| 06:00:47 | Unhelpful | what i was talking about was smoothing out the impact of usage-based, not feature-based costs |
| 06:01:13 | gibbon_ | ok, then i got - at least - you wrong ;) |
| 06:01:19 | Unhelpful | for example, the backlight for most users comes on for so many seconds after they interact with the device - how much they cause it to turn on is not a setting. |
| 06:02:45 | gibbon_ | a mid term average would catch that, i guess... users who often use their backlight (by interacting) most likely will do so as a part of their common usage |
| 06:03:45 | gibbon_ | iirc this is done in modern laptops in the same way |
| 06:05:19 | | Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) |
| 06:06:46 | gibbon_ | what i don'T get in soaps idea is the scale factor... if you use power-intensive "features" of the device... may be the backlight, may be the remote, the battery actually drains. so if you factorize remaining battery life (where the features mentioned already have impact on - in a physical way), isn't everything accounted for twice? |
| 06:08:03 | gibbon_ | maybe i would have to read some code to understand how the remaining battery level (not the time left) is calculated to understand... |
| 06:08:15 | Unhelpful | no, the scale factor as i understood it would be a simplistic means for *approximating* the impact of those variables on true time left. |
| 06:08:41 | gibbon_ | before it happens..? |
| 06:09:47 | gibbon_ | to me this sounds like this value had to be automaticalls adjusted backwards as the impact really happens |
| 06:12:12 | gibbon_ | well... nevermind... i will think about it - maybe it will get more clearer after the first coffee... |
| 06:12:21 | gibbon_ | but thanks for pointing that out |
| 06:15:06 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 06:38:08 | *** | Saving seen data "./dancer.seen" |
| 06:39:42 | | Quit sbhsu (Read error: 104 (Connection reset by peer)) |
| 06:45:44 | Unhelpful | (from other channel) would we be moving the beginning, or the end, of the plugin buffer? |
| 06:47:13 | Llorean | I assume the beginning since the end is always at the end of RAM right? |
| 06:48:02 | Unhelpful | but moving the beginning means either changing the plugin load address, which we have to fix at compile time, or else having two areas of "free" plugin buffer, one above the loaded plugin code, and one below it. |
| 06:48:18 | Llorean | Well yeah, but we can fix it at compile time. |
| 06:48:22 | Llorean | I don't see why that's a problem? |
| 06:50:12 | Llorean | Plugin buffer size is defined per-target in the config, right? So instead of just having them all defined the same size, we give the ones with significantly more RAM a slightly larger define. |
| 06:50:12 | Unhelpful | i'm confused... are we talking about runtime adjustment of the plugin buffer size based on *free* audio buffer, or compile time adjustment base on (essentially) the amount of available memory? i took you to mean the former. |
| 06:50:20 | Llorean | compile-time based on total memory |
| 06:51:49 | Llorean | Though a way to 'buffer' the files that couldn't fit in the plugin buffer would be neat too I suppose. |
| 06:53:22 | Unhelpful | well, something i'd like to see would be the addition of a try-to-free call to the buf* API in core. we can already use bufalloc to make handle allocations in plugins, adding a flag, or a function to call, that could dump some audio from the buffer if we can do so without impacting playback might be useful. |
| 06:54:16 | Llorean | Would something be able to be kept in the buffer indefinitely or would it need to be moved every rebuffer? |
| 06:57:17 | Unhelpful | that's another thorny issue - i believe bufalloc allocations are moved on rebuffer, so that's *not* a way to get a chunk of fixed memory. is *everything* on the audio buffer movable? could we, say, free some amount of it, compact it all down, and then move the end of the audio bufer, and hand that chunk off to a plugin or some other user until it says it's done with it? |
| 06:59:06 | Llorean | Dunno. |
| 06:59:21 | Unhelpful | it would provide a playback-friendly way to allocate a fixed range of memory, for things that need more than the plugin buffer, but don't want to interrupt playback. things that will be playing their own audio, or similar, can still just grab the whole audio buffer. |
| 06:59:41 | Llorean | Yeah |
| 07:00 |
| 07:00:09 | Unhelpful | i tossed around the idea with Nico_P a week or so ago of stopping playback, moving the audio buffer end, and rebuffering. there's nothing that offers that right now, but it would be *possible* to implement. |
| 07:00:28 | Llorean | I don't think a temporary stop of playback while the plugin launches is particularly bad, either. |
| 07:00:31 | Llorean | Rather than a permanent one. |
| 07:03:00 | Unhelpful | and, as was argued with AA reloads on WPS change, it's in immediate response to a user action, so it's not very surprising. |
| 07:03:21 | Llorean | Well you could even prompt like I think jpegviewer does. |
| 07:03:35 | Llorean | "This action requires a brief halt in playback, press select to continue or any other key to cancel" |
| 07:08:45 | | Join jj19000 [0] (n=477f192b@gateway/web/cgi-irc/labb.contactor.se/x-318ab2110580e0d0) |
| 07:09:17 | jj19000 | Llorean? |
| 07:09:40 | jj19000 | Anyone? |
| 07:10:34 | jj19000 | is anyone out there? |
| 07:11:58 | jj19000 | hello? ........ HELLO???? |
| 07:12:36 | midgey | jj19000: there are plenty of people in the room.... |
| 07:13:10 | Unhelpful | geez. there are people here, maybe you should just state what you want, and see if anybody can help with whatever it is? |
| 07:13:25 | jj19000 | oh...sorry |
| 07:14:14 | jj19000 | you see im trying to compile a bootloader for the sansa clip.my 1st Q is:has it ever been done? |
| 07:15:27 | midgey | yes it has |
| 07:16:03 | jj19000 | ok...is there an available one anywhere? |
| 07:16:04 | Unhelpful | maybe you should check the wiki or new ports thread for clip on the forum. yes, people are able to boot rockbox, and use it to some degree, on clip. i don't think it's really in a state that non-developers would want to use. |
| 07:16:47 | midgey | there's none available, you'll have to build it yourself |
| 07:16:55 | midgey | well at least nothing official |
| 07:17:00 | midgey | i'm not sure about otherwise |
| 07:17:01 | | Quit kkurbjun ("Leaving.") |
| 07:17:49 | jj19000 | ok ... can anyone here help me with compiling bootloaders in cygwin? |
| 07:18:06 | jj19000 | im halfway there already |
| 07:18:31 | midgey | what OS are you on? |
| 07:18:43 | jj19000 | windows xp |
| 07:19:25 | midgey | and how are you attempting to build? |
| 07:19:37 | jj19000 | hold on...... |
| 07:21:31 | cool_walking_ | http://build.rockbox.org/dist/build-clip/rockbox.zip exists. I think it's still being built, even though it's not listed on the site. |
| 07:22:20 | jj19000 | sorry everyone but i got 2 go |
| 07:23:11 | | Quit jj19000 ("CGI:IRC") |
| 07:25:28 | | Join kkurbjun [0] (n=kkurbjun@c-24-9-80-197.hsd1.co.comcast.net) |
| 07:25:33 | Unhelpful | 1858 |
| 07:30:02 | | Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) |
| 07:32:57 | | Join lymeca [0] (n=lymeca@213-213-141-71.xdsl.is) |
| 07:33:14 | lymeca | So I read about some USB change, then I installed the latest build on my 5.5G 80GB iPod |
| 07:33:54 | lymeca | I see now that it no longer reboots into the Apple firmware's Disk Mode in order to transfer files. It shows the Rockbox USB cable picture and I can transfer data. |
| 07:33:58 | lymeca | That's cool. |
| 07:34:08 | lymeca | But it doesn't seem to be charging... that's not cool. |
| 07:34:20 | lymeca | I don't have a wall adapter and USB is the only way I charge my iPods. |
| 07:35:09 | lymeca | I am temporarily getting around this by manually booting into disk mode by holding down Select+Play at boot. |
| 07:35:28 | lymeca | Please tell me I'm doing something wrong, or the Rockbox USB transfer mode will also charge the device soon? |
| 07:37:29 | cool_walking_ | I've had my iPod 5G plugged in to this computer (in UMS mode) all day. I just checked, and it's on 95%. When I plugged it in this morning it was ~30%. So it must charge. |
| 07:38:35 | | Join zelak [0] (n=zelakt@user-12lci6r.cable.mindspring.com) |
| 07:38:56 | zelak | hello, is it possible to remove the ipod software completely from the ipod? (2nd gen mini) |
| 07:39:25 | gibbon_ | lymeca: is it the wall adapter the one provided by apple? |
| 07:39:55 | lymeca | Uhh, sure. Whatever it is it's what allows me to plug the iPod directly into the wall. |
| 07:40:03 | lymeca | I DON'T have one so it's kind of irrelevant. |
| 07:40:09 | gibbon_ | ah... |
| 07:40:30 | gibbon_ | misread that... i am going to stay quiet for the rest of the day i think |
| 07:41:40 | | Quit zelak (Client Quit) |
| 07:42:06 | | Join Riku [0] (n=Lss@cm130.delta141.maxonline.com.sg) |
| 07:45:35 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 07:46:10 | | Quit planetbeing_ () |
| 07:49:20 | | Join homielowe [0] (n=homielow@d206-116-134-81.bchsia.telus.net) |
| 07:57:42 | | Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) |
| 08:00 |
| 08:01:19 | | Quit kadoban (Remote closed the connection) |
| 08:01:20 | | Quit Riku (Read error: 104 (Connection reset by peer)) |
| 08:05:15 | | Join planetbeing_ [0] (n=planetbe@24.86.172.128) |
| 08:10:09 | | Quit bmbl (Read error: 104 (Connection reset by peer)) |
| 08:10:57 | | Quit yhuang (Read error: 104 (Connection reset by peer)) |
| 08:20:47 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@c-98-203-252-78.hsd1.wa.comcast.net) |
| 08:25:05 | | Join Mouser_X [0] (i=cf9bb00a@gateway/web/ajax/mibbit.com/x-68bc35293e7369e3) |
| 08:26:38 | Mouser_X | I'm not registered to the Rockbox Mailing list, but I do read it occasionally. As such, I wanted to give my 2 cents on this: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-03/0071.shtml |
| 08:26:49 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
| 08:27:02 | Mouser_X | I do "Insert Next" in reverse order somewhat frequently. |
| 08:27:08 | Mouser_X | It's annoying... |
| 08:27:47 | Mouser_X | (In truth, I've never used the "insert" option. I've *always* used either "insert next" or "insert last".) |
| 08:27:51 | | Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
| 08:28:32 | Mouser_X | Llorean and JdGordon: ^ Since you two are the ones doing the most discussion, you're probably the two that would be most interested in my input. |
| 08:29:27 | Mouser_X | The insert option I *REALLY* want is an "Insert At" option, that would allow me to select where in the current playlist to insert the selected item. |
| 08:30:18 | Llorean | You couldn't really "insert at" with one-button anyway. |
| 08:30:22 | cool_walking_ | Mouser_X: I do the same thing quite commonly, but I use "queue next" instead of "insert next" out of habit. |
| 08:30:51 | Llorean | Mouser_X: So you Insert Next in the opposite order you want to hear them, rather than Inserting in the order you wish to listen? Why's that? |
| 08:31:17 | Mouser_X | Almost exclusively, I listen to music by the album (read: game) they're in. Sometimes the "insert last" isn't what I want, because I want to listen to the selected item after the current album (not current track) is done, but I already have other songs after the current album. |
| 08:31:35 | Llorean | Yes, but that's a single Insert Next. |
| 08:31:47 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:32:07 | Llorean | If you followed that with an "Insert" (not Last), the next thing you inserted would come after the album/song you'd used "Insert Next" on, but before everything else in your playlist. |
| 08:32:10 | Llorean | It's sequential. |
| 08:32:21 | Mouser_X | Once I'm done with the current album, yes it is. But in most cases, by the time the current album is over, I can't edit the playlist (busy) or I've forgotten. |
| 08:32:30 | Mouser_X | And that wasn't in answer to your question. |
| 08:32:36 | Mouser_X | I was getting to that. |
| 08:32:49 | | Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 08:32:53 | Llorean | But do you use multiple "Insert Next" in a row? |
| 08:33:02 | Mouser_X | Often, yes. |
| 08:33:07 | Llorean | Like, doing three, four, or several dozen in one session of browsing? |
| 08:33:17 | Llorean | Why do you favour it over "Insert" exactly? |
| 08:33:30 | Mouser_X | Probably because I don't know how to use insert. |
| 08:33:48 | Llorean | Just "Insert Next" the first song you want to hear, then "Insert" the song you want to hear after that and so on. |
| 08:33:56 | Llorean | Instead of doing them in reverse order, you do them in the actual order you want to hear them. |
| 08:33:57 | Mouser_X | Due to it's varied nature (it changes depending on whatever insert action was used last, I think.) |
| 08:34:16 | Llorean | It doesn't actually change what it does. |
| 08:34:25 | Llorean | What it does is "Insert after the last thing you inserted" |
| 08:34:48 | Llorean | This can be different places depending on what you inserted last, but the behaviour doesn't change. |
| 08:35:49 | Llorean | In _most_ cases you only need one "Insert Next" or "Insert Last" followed by one or many "Inserts" unless, as I said in the discussion, you want to add things in reverse order for some reason. |
| 08:35:55 | Mouser_X | When I do "Insert Next" this is how I use it: I want to listen to multiple albums, but in order (say, Megaman 1-6 for example). If I do "Insert Next" on MM1, and then "Insert Next" on MM2, (and so on), then they're backwords. (let me type me next line before replying please) |
| 08:36:23 | Mouser_X | If I understand you correctly, I can do "Insert Next" on MM1, and then "Insert" on MM2, then MM3, then MM4 etc.? |
| 08:36:32 | Llorean | Yes |
| 08:36:35 | Mouser_X | Ah. |
| 08:36:39 | Mouser_X | That's helpful. |
| 08:36:56 | Llorean | So after you'd set the first album it'd be a single button press for each following one with this patch |
| 08:37:06 | Mouser_X | Hmmm. |
| 08:38:06 | | Join MTee [0] (n=MTee@41.233.151.29) |
| 08:38:09 | *** | Saving seen data "./dancer.seen" |
| 08:38:36 | Mouser_X | I'm now re-thinking my use of the insert functions. |
| 08:38:51 | MTee | linuxstb : ping |
| 08:39:00 | Llorean | For *most* cases, "Insert" is going to be what you use the most of among the various "Insert Blah" functions. |
| 08:39:15 | Mouser_X | (Mostly attempting to see if I can think up a viable reason for using "Insert Next" many times.) |
| 08:39:41 | Mouser_X | (^ For my use, I'll point out.) |
| 08:39:44 | Llorean | The main reason for using it a second time is if you change your mind about what you want to hear "Next" and need to move the pointer back to right after the current song. |
| 08:39:49 | Mouser_X | *usage habits |
| 08:40:12 | Llorean | Basically, the only time you *have* to use it more than once is if you do something wrong. |
| 08:40:18 | Mouser_X | Yes. |
| 08:40:25 | Mouser_X | That's what I was thinking. |
| 08:40:47 | Llorean | Meanwhile, if "Insert Next" is the default, it narrows down the usefulness of the button a lot. Same with "Insert Last" and "Insert Shuffled" |
| 08:41:00 | Mouser_X | How difficult would an "Insert At" option be to implement, anyway? |
| 08:41:00 | Llorean | I also honestly do not know where the "Insert" will go after an "Insert Shuffled" |
| 08:41:14 | Mouser_X | Heh. Good point. |
| 08:41:46 | pixelma | Llorean: I really don't want to take part in the discussion behind it in the ML (the question which would be the best suited action on a spare button) but: I use "Insert shuffled" the most |
| 08:41:57 | Llorean | Mouser_X: Well, an "Insert At" would need some new UI I imagine. |
| 08:42:12 | Mouser_X | No, I wasn't necessarily disagreeing with you on the "insert" being the 1 button press (that'd be nice, especially now that I have a better understanding of its use), but more that there are actually people who use "Insert Next" consecutively. |
| 08:42:49 | Llorean | Mouser_X: I think their use habit could adapt to using "Insert" instead, and still speed up their playlisting time. |
| 08:43:02 | | Quit BHSPitMonkey ("Ex-Chat") |
| 08:43:21 | Llorean | pixelma: I don't doubt some people do (me being one of them, I like my shuffle) but I do think the biggest overall advantage to users comes from plain "Insert" on the button, if anything's going to be put on it. |
| 08:43:53 | Llorean | And it may just be faster to turn off shuffle from the quickscreen, tap "insert" on several albums, then turn it on actually. |
| 08:44:12 | pixelma | aha, but it really sounded a bit like you would speak for all |
| 08:44:20 | Mouser_X | How I envision an "Insert At" would be to select the item you want, go to playlist options, and select "Insert At" instead of "Insert/Next/Last". Once selected it takes you to the current playlist, and allows you to select a location (similar to moving a song in the playlist). Then it inserts at that location. |
| 08:44:51 | Mouser_X | I don't know how Rockbox works in general, but I don't think that would require implementation of extra GUI elements. |
| 08:44:59 | Llorean | pixelma: I'm speaking my opinion that I think the function that would benefit from instant availability the most would be "Insert" among all the Insert * choices. |
| 08:45:40 | Mouser_X | Llorean: I think I'd have to agree, now that I have a better idea of how to use it. |
| 08:46:13 | amiconn | The advantage of 'Insert shuffled' over global shuffle is that it's much faster to use, and you cannot forget to disable shuffle again. |
| 08:46:32 | Mouser_X | (Also, when I said I don't know how Rockbox works, I meant "in the background." I've been using Rockbox since about 1 month (or less?) after the Gigabeat F had audio working.) |
| 08:47:22 | * | Mouser_X loves his video game formats. |
| 08:47:28 | * | amiconn practically only uses 'Insert shuffled' or plain file selection, none of the other 'Insert...' options |
| 08:48:03 | Mouser_X | I use "Insert Last" and "Insert Next" a lot. I've only used the "shuffle" option once. |
| 08:48:05 | Mouser_X | Ever. |
| 08:48:17 | pixelma | Llorean: for some targets it's not easier to turn shuffle on from the quickscreen... turning it on generally would also give a different result to how I use it (with "Insert shuffled" on a folder I can have the one shuffled playlist while listening albums in order usually, and "Insert shuffled" will put the track(s) behind the already playing track, I'm not sure what will happen when you turn it on globally |
| 08:48:49 | * | Mouser_X replaced the "shuffle" option in the quickscreen/menu with brightness settings. |
| 08:48:52 | Llorean | pixelma: I don't think these targets have a spare "Record" button short press though. :) |
| 08:49:07 | Llorean | The quick screen should probably get a button before we go using one on "Insert" |
| 08:49:39 | Llorean | The problem right now is that building playlists to save on the device is a much more tedious process than it needs to be. A single-button insert solves most of that difficulty almost immediately (if anyone ever comes up with easier to use text input, that'd be the other half) |
| 08:49:53 | pixelma | which is why I don't really wanted to take part in the discussion but wanted to say something about this one statement |
| 08:50:05 | pixelma | s/wanted/want |
| 08:50:30 | Llorean | I don't think everyone uses Insert the most. I just think Insert has the best reason to be one-button among the choices there. |
| 08:50:40 | Mouser_X | If you're looking for usage statistics, I'd like to point out that I almost never use the volume buttons on my Gigabeat (the ones on the side), because the face buttons already do that. The buttons on the side aren't as accessible, so I don't use them. Same goes for the "next" and "previous" buttons on the side as well. |
| 08:52:14 | Mouser_X | Thus, if given the option, I'd replace those functions with something more useful (such as accessing the playlist, or inserting items, or something). |
| 08:52:48 | Mouser_X | I realize you're against configurable buttons, and that's not what I'm arguing for. If I was arguing for anything, it'd be a reconsideration of what those buttons do. |
| 08:53:01 | Llorean | Mouser_X: In _general_ we try not to stray too far from what the labels on or around the buttons suggest they do. In this case, several players have an action on long press of the record button, but not short press. It's a case of deciding what to do for a button that has no "purpose" at all |
| 08:53:20 | Mouser_X | (Because right now, I find their redundancy to be useless. At least, they are for me.) |
| 08:53:52 | Mouser_X | Yes, I was aware of that. I was just throwing more pennies at the discussion in general. |
| 08:54:14 | Llorean | Mouser_X: But what about the people who argue the fact buttons are redundant, because at least the side buttons are labelled? ;) |
| 08:54:20 | | Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") |
| 08:54:32 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 08:54:39 | Mouser_X | I assume you mean face, not fact. |
| 08:54:45 | pixelma | hmm... I think that the c200 still has a shortcut to the recording screen on a short press of the rec button. I don't remember if this was from the browsers/lists or from the WPS or both. But it reminds me of the c200 keymap patch... :\ |
| 08:54:46 | Llorean | Yes, face, sorry. |
| 08:55:28 | Llorean | pixelma: Maybe after 3.2 is released we could just apply the patch to SVN and see how well it goes over (and what problems, if any significant ones, people have with it)? |
| 08:55:35 | Llorean | The c200 keymap, that is |
| 08:55:50 | | Join Rob2223 [0] (n=Miranda@p4FDCC1DA.dip.t-dialin.net) |
| 08:56:14 | Mouser_X | For those who argue that, I'd tell them to suck it up. The face buttons are more standard (among their function and the overall supported targets), and they're easier to get to. |
| 08:56:26 | linuxstb | MTee: ? |
| 08:56:31 | Mouser_X | (Not 100% serious, but I am mostly.) |
| 08:56:45 | Llorean | Mouser_X: That's a matter of opinion though. For some of us the side is equally easy (or easier) to use regularly. |
| 08:57:02 | pixelma | well, it still needs work - I'm still not really satisfied with it. In fact, I only use a small part of it myself and one aditional thing that's not published there in my builds (WPS context menu on long select) |
| 08:57:12 | Llorean | Basically, that's a case of "my preference against yours" in a situation where there's no real reason they'd need to be exclusive. |
| 08:58:04 | pixelma | Mouser_X: the side volume buttons also work in the browsers though |
| 08:58:16 | Mouser_X | Ah, right. I forgot about that. |
| 08:58:30 | Mouser_X | See? I told you I (essentially) never use them. |
| 08:58:34 | Mouser_X | :P |
| 08:58:53 | MTee | linuxstb : I'm trying to loop through the data packets , and display the related information. What I do is read in the packet length then lseek(fd,packet_length,SEEK_CUR), this is supposed to reach the next data packet, but it doesn't. |
| 09:00 |
| 09:00:49 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 09:00:58 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-1f2a9b5ceea2b6d6) |
| 09:01:04 | Mouser_X | Question regarding plugins: I've never heard the actual argument against settings for plugins. The reason I ask, is because for some plugins, I can think of some good reasons to allow settings for them. In my mind though, if such a thing were implemented, I would sort of expect there to be a config file that has sane defaults. This file could then be edited/changed using a *.rock plugin. |
| 09:01:16 | Mouser_X | *settings for codecs |
| 09:01:31 | pixelma | Mouser_X: I _never_ use them as I don't even have a Gigabeat... :P |
| 09:01:32 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
| 09:01:47 | Mouser_X | Specifically, I'm thinking of NSF, SID, GBS (not commited for good reason), ADX, and others. |
| 09:02:10 | | Quit keby (Read error: 60 (Operation timed out)) |
| 09:02:32 | Mouser_X | SID looping endlessly is not useful at all to me. In fact, I removed all the SID files from my Gigabeat because it was far too much hassle to listen to them, so I never did. |
| 09:03:41 | Mouser_X | NSF has NSFe, which is helpful. But there's a very limited selection of available NSFe files out there. |
| 09:03:55 | Mouser_X | (GBS and other formats don't even have that.) |
| 09:05:13 | Mouser_X | Note: If I can get the VMWare Rockbox/Linux image to be useful, I'll be making the attempt to get the GBS patch ( FS #7331 ) working again. |
| 09:05:53 | * | Mouser_X is learning C++. |
| 09:06:05 | | Join keby [0] (n=keby@cpe-24-243-7-225.satx.res.rr.com) |
| 09:06:15 | Mouser_X | (I realize C++ isn't C, but hopefully it's close enough to get me going in the right direction.) |
| 09:08:12 | MTee | linuxstb : is there something wrong (conceptually) with how I'm skipping ? |
| 09:08:35 | | Join barrywardell [0] (n=barrywar@79.97.77.138) |
| 09:09:14 | | Quit midgey () |
| 09:11:32 | | Quit Mouser_X ("mibbit.com: Oops. I didn't intend to be here as long as I was.") |
| 09:12:15 | linuxstb | MTee: I don't know the details of RealMedia streams. Maybe the packet length includes the size of the header you've already read? Also, have you tried looking at the source to the vlc or ffmpeg realmedia parsers? |
| 09:13:47 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:14:03 | MTee | linuxstb : I've tried lseek with packet_length - skipped, and got the same problem, but no I haven't checked this in ffmpeg, I'll look there. |
| 09:14:19 | | Quit gevaerts (Nick collision from services.) |
| 09:14:31 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 09:24:49 | MTee | linuxstb : when reading in a variable of size (uint8) do I just use char as the variable type, or should I write a function like read_uint8() and use uint8 as the type ? |
| 09:25:39 | linuxstb | char != uint8 - char is either signed or unsigned (it's CPU/compiler dependent), uint8 is unsigned. |
| 09:26:01 | kadoban | also, technically char doesn't have to be 8 bits |
| 09:26:17 | kadoban | but is pretty much always :) |
| 09:27:21 | linuxstb | So yes, best to use uint8 (and include stdint.h or inttypes.h, I never know which one...) |
| 09:27:52 | MTee | ok, thanks |
| 09:32:53 | | Join Thundercloud [0] (n=thunderc@82.132.136.188) |
| 09:38:36 | | Join midijunkie [0] (n=Miranda@pD9547A13.dip0.t-ipconnect.de) |
| 09:40:51 | | Quit parafin (Read error: 104 (Connection reset by peer)) |
| 09:46:06 | | Quit midijunkie ("?(???~•~)?") |
| 09:47:15 | | Join __lifeless [0] (n=lifeless@90.150.119.103) |
| 09:48:25 | | Join HackyKid [0] (i=HackyKid@wlan073112.nbw.tue.nl) |
| 09:50:53 | | Nick Barahir_ is now known as Barahir (n=jonathan@BAAd099.baa.pppool.de) |
| 09:50:58 | | Quit Thundercloud (Remote closed the connection) |
| 09:57:51 | | Join thickinit [0] (n=thickini@cpe-76-190-210-165.neo.res.rr.com) |
| 09:59:06 | | Join Munkie [0] (n=29b13251@gateway/web/cgi-irc/labb.contactor.se/x-82b882d246af1bbd) |
| 10:00 |
| 10:05:16 | | Quit _lifeless (Read error: 113 (No route to host)) |
| 10:08:00 | | Quit Munkie ("CGI:IRC (EOF)") |
| 10:19:43 | | Quit keby (Read error: 60 (Operation timed out)) |
| 10:20:41 | | Quit z35 ("Leaving") |
| 10:21:56 | | Join keby [0] (n=keby@cpe-24-243-7-225.satx.res.rr.com) |
| 10:23:10 | scorche | just as a reminder, next week is org application week...we still have some fleshing out to do on this page if anyone feels up to add some ideas: http://www.rockbox.org/twiki/bin/view/Main/SummerOfCode2009 |
| 10:26:35 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
| 10:35:48 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
| 10:38:11 | *** | Saving seen data "./dancer.seen" |
| 10:49:23 | | Quit Chesteta (Read error: 110 (Connection timed out)) |
| 10:51:45 | | Quit barrywardell () |
| 11:00 |
| 11:10:24 | | Join Sedgewick [0] (n=Sedgewic@81.200.132.126) |
| 11:18:21 | | Quit JdGordon|zzz (Read error: 110 (Connection timed out)) |
| 11:18:38 | | Join barrywardell_ [0] (n=barrywar@dhcp-892b3c51.ucd.ie) |
| 11:21:37 | | Quit linuxstb (Read error: 113 (No route to host)) |
| 11:30:44 | | Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) |
| 11:32:16 | | Part LinusN |
| 11:32:23 | | Quit keby (Read error: 60 (Operation timed out)) |
| 11:33:08 | | Join courtc_ [0] (n=court@unaffiliated/courtc) |
| 11:33:14 | | Quit courtc (Read error: 60 (Operation timed out)) |
| 11:34:55 | | Join tempbon_ [0] (i=gibbon_@could.become.a.servant4you.org) |
| 11:35:23 | | Join petur2 [50] (n=petur@rockbox/developer/petur) |
| 11:35:36 | | Quit petur (Nick collision from services.) |
| 11:35:41 | | Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) |
| 11:36:21 | | Quit jhMikeS (grisham.freenode.net irc.freenode.net) |
| 11:36:21 | NSplit | grisham.freenode.net irc.freenode.net |
| 11:36:21 | | Quit martian67 (grisham.freenode.net irc.freenode.net) |
| 11:36:21 | | Quit gibbon_ (grisham.freenode.net irc.freenode.net) |
| 11:36:21 | | Quit chrippa (grisham.freenode.net irc.freenode.net) |
| 11:36:30 | NHeal | grisham.freenode.net irc.freenode.net |
| 11:36:30 | NJoin | jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 11:36:30 | NJoin | martian67 [0] (i=user5490@about/linux/regular/martian67) |
| 11:36:35 | | Join keby [0] (n=keby@cpe-24-243-7-225.satx.res.rr.com) |
| 11:37:44 | NJoin | chrippa [0] (n=chrippa@evangelion.se) |
| 11:38:01 | | Quit jhMikeS (Read error: 54 (Connection reset by peer)) |
| 11:45:06 | | Quit martian67 (grisham.freenode.net irc.freenode.net) |
| 11:46:53 | | Quit rocko ("Leaving") |
| 11:47:31 | NJoin | martian67 [0] (i=user5490@about/linux/regular/martian67) |
| 11:48:22 | | Quit HackyKid (Read error: 110 (Connection timed out)) |
| 12:00 |
| 12:00:45 | | Quit nuonguy ("This computer has gone to sleep") |
| 12:10:22 | | Join akur [0] (n=akur@bl6-153-99.dsl.telepac.pt) |
| 12:12:14 | | Join dfkt_dt [0] (i=dfkt@chello062178002170.1.11.univie.teleweb.at) |
| 12:13:01 | | Join Darksair [0] (n=user@125.33.194.229) |
| 12:13:15 | | Part akur |
| 12:19:58 | | Quit dfkt_dt (Read error: 60 (Operation timed out)) |
| 12:20:27 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 12:31:54 | | Join joerack_ [0] (n=joerack@host218-215-dynamic.9-87-r.retail.telecomitalia.it) |
| 12:33:20 | | Part gartral |
| 12:38:15 | *** | Saving seen data "./dancer.seen" |
| 12:38:21 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 12:39:15 | | Join dfkt [0] (i=dfkt@chello062178002170.1.11.univie.teleweb.at) |
| 12:41:46 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 12:42:07 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 12:50:49 | | Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 12:53:46 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
| 12:56:15 | | Quit barrywardell_ (Remote closed the connection) |
| 12:56:29 | | Join barrywardell [0] (n=barrywar@dhcp-892b9b88.ucd.ie) |
| 12:57:06 | | Quit barrywardell (Client Quit) |
| 12:58:44 | | Quit dfkt (Read error: 145 (Connection timed out)) |
| 12:58:57 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:00 |
| 13:08:47 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 13:09:15 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:17:26 | | Part joerack_ ("Ex-Chat") |
| 13:33:39 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 13:33:46 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:34:35 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 13:34:57 | | Join MrSpeedy [0] (n=misko@92.52.42.149) |
| 13:35:08 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:36:55 | | Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 13:37:11 | | Quit robin0800 (Remote closed the connection) |
| 13:37:56 | MrSpeedy | hi guys, is there possibility to make sansa c2xx rockbox to show *.JPG album arts in WPS instead of cover.bmp? |
| 13:41:35 | | Join akur1 [0] (n=akur@bl9-152-52.dsl.telepac.pt) |
| 13:43:50 | | Part akur1 |
| 13:48:15 | | Quit dfkt_dt (Read error: 60 (Operation timed out)) |
| 13:48:33 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 13:58:34 | martian67 | MrSpeedy, no |
| 13:59:07 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 14:00 |
| 14:00:03 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 14:00:18 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 14:03:52 | | Join tyfoo [0] (n=tyfoo@77-20-31-238-dynip.superkabel.de) |
| 14:11:21 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
| 14:24:20 | | Quit planetbeing_ () |
| 14:28:15 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 14:31:51 | | Quit Darksair (Read error: 104 (Connection reset by peer)) |
| 14:35:40 | | Quit BlakeJohnson86 (Read error: 110 (Connection timed out)) |
| 14:38:17 | *** | Saving seen data "./dancer.seen" |
| 14:39:31 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 14:39:53 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:00 |
| 15:00:03 | | Quit kachna|lappy (Read error: 110 (Connection timed out)) |
| 15:03:15 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 15:08:25 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
| 15:09:15 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-7cd0b738ebb2f792) |
| 15:17:37 | | Quit intrados_ (Read error: 104 (Connection reset by peer)) |
| 15:21:57 | | Part MrSpeedy |
| 15:22:25 | | Join intrados_ [0] (n=intrados@cpe-71-67-133-85.woh.res.rr.com) |
| 15:30:32 | | Join gartral1 [0] (n=gareth@75.33.91.251) |
| 15:36:25 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-c0b746971a614dc7) |
| 15:36:54 | | Nick evilnick is now known as evilnick_7 (i=0c140464@gateway/web/ajax/mibbit.com/x-c0b746971a614dc7) |
| 15:37:53 | | Join pyro_maniac [0] (i=foobar@p57BB8FB5.dip0.t-ipconnect.de) |
| 15:43:50 | | Join fyrestorm [0] (n=fyre@cpe-24-90-81-53.nyc.res.rr.com) |
| 15:49:00 | | Quit awake_ (Read error: 104 (Connection reset by peer)) |
| 15:49:30 | | Quit amiconn (Read error: 104 (Connection reset by peer)) |
| 15:49:32 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 15:49:42 | | Join awake_ [0] (n=Zzz@c122-106-54-254.rivrw1.nsw.optusnet.com.au) |
| 15:50:54 | | Join midijunkie [0] (n=Miranda@pD9547A13.dip0.t-ipconnect.de) |
| 15:52:34 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
| 16:00 |
| 16:01:57 | | Join Darksair [0] (n=user@125.33.194.229) |
| 16:04:55 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 16:05:17 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:05:59 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
| 16:06:33 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 16:06:45 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:11:28 | | Quit dfkt (Read error: 60 (Operation timed out)) |
| 16:11:44 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:25:27 | | Join pyro_maniac1 [0] (i=foobar@p57BB99B0.dip0.t-ipconnect.de) |
| 16:29:02 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 16:29:17 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:30:33 | | Join kushalone [0] (n=kushal@12.169.180.178) |
| 16:31:14 | | Quit kushalone (Broken pipe) |
| 16:31:21 | | Join kushalone [0] (n=kushal@12.169.180.178) |
| 16:33:19 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
| 16:36:41 | | Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-768e87cd412e3390) |
| 16:36:57 | evilnick_7 | I just managed to get the weird static-y noises on a v1 e280 for the first time |
| 16:38:20 | *** | Saving seen data "./dancer.seen" |
| 16:41:20 | | Quit pyro_maniac (Read error: 110 (Connection timed out)) |
| 16:41:58 | | Quit petur ("damn...") |
| 16:42:16 | | Join akur [0] (n=akur@bl9-152-52.dsl.telepac.pt) |
| 16:42:23 | | Part akur |
| 16:42:54 | | Quit moos ("Rockbox rules the DAP world") |
| 16:43:40 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 16:43:55 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:47:42 | | Join MethoS- [0] (n=lem@host-091-097-243-240.ewe-ip-backbone.de) |
| 16:48:26 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 16:49:07 | | Quit Seed (Client Quit) |
| 16:49:52 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 16:50:17 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 16:50:25 | | Join {phoenix} [0] (n=dirk@p54B46BD5.dip.t-dialin.net) |
| 16:51:06 | | Nick tempbon_ is now known as gibbon_ (i=gibbon_@could.become.a.servant4you.org) |
| 16:55:37 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
| 16:55:58 | | Join Llorean [0] (n=DarkkOne@adsl-70-241-29-2.dsl.hstntx.swbell.net) |
| 16:57:59 | | Quit Qball ("leaving") |
| 17:00 |
| 17:01:54 | kugel | Rockbox USB is wonderful |
| 17:02:17 | | Quit dfkt (Read error: 145 (Connection timed out)) |
| 17:02:21 | kugel | With it, my DVB-T receiver finally manages to actually see my sansa and play the music off it |
| 17:02:28 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 17:02:34 | kugel | the OF failed at that |
| 17:02:39 | kugel | fails even |
| 17:02:42 | markun | cool |
| 17:04:45 | | Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") |
| 17:07:56 | | Quit Zagor ("Don't panic") |
| 17:12:27 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 17:12:39 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 17:22:42 | | Quit SirFunk (Connection timed out) |
| 17:23:07 | | Join flydutch [0] (n=flydutch@host25-43-dynamic.5-87-r.retail.telecomitalia.it) |
| 17:23:35 | | Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) |
| 17:25:34 | | Part gartral1 |
| 17:33:00 | | Quit FlynDice (Read error: 60 (Operation timed out)) |
| 17:39:10 | | Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) |
| 17:43:45 | | Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-bbf92b8de5ce4106) |
| 17:44:33 | | Join JdGordon [0] (n=jonno@c-98-203-252-78.hsd1.wa.comcast.net) |
| 17:49:24 | | Join gregzx [0] (n=chatzill@dtl156.neoplus.adsl.tpnet.pl) |
| 17:54:39 | | Part CaptainKwel |
| 17:55:16 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 17:55:32 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 17:55:57 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 17:56:22 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 18:00 |
| 18:01:26 | | Join parafin [0] (i=parafin@paraf.in) |
| 18:02:02 | | Join FlynDice [0] (n=jack@c-24-19-225-90.hsd1.wa.comcast.net) |
| 18:04:52 | | Join archivator [0] (n=archivat@77.70.28.57) |
| 18:07:50 | saratoga | why do we build the e200v2 bootloader, and the fuze mainbuild but not hte e200v2 main build |
| 18:08:32 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 18:08:39 | | Quit dfkt_dt (Read error: 145 (Connection timed out)) |
| 18:08:56 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 18:09:58 | kugel | saratoga: because first all bootloaders were added. Later we asked to build normal builds too, but we basically only asked for fuze and clip |
| 18:10:37 | kugel | and I don't really think that both fuze and e200 have to be build, particularly if/when my unify drivers patch goes in |
| 18:11:09 | kugel | (until they're supported of course) |
| 18:12:02 | | Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) |
| 18:15:40 | | Join BigBambi_ [0] (n=alex@152.27.192-77.rev.gaoland.net) |
| 18:19:35 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 18:19:43 | | Quit Xerion (Connection reset by peer) |
| 18:19:54 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 18:20:11 | | Quit kugel (Nick collision from services.) |
| 18:20:14 | | Join kugel__ [0] (i=kugel@e179080218.adsl.alicedsl.de) |
| 18:20:17 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 18:20:53 | | Quit kugel__ (Client Quit) |
| 18:21:09 | | Join kugel_ [0] (i=kugel@e179080218.adsl.alicedsl.de) |
| 18:21:15 | archivator | Has anyone tested my rbutil patch yet? |
| 18:21:15 | | Nick kugel_ is now known as kugel (i=kugel@e179080218.adsl.alicedsl.de) |
| 18:22:42 | | Join jj19000 [0] (n=477f17d7@gateway/web/cgi-irc/labb.contactor.se/x-219921de2a0db3e4) |
| 18:24:02 | | Quit BigBambi (Read error: 110 (Connection timed out)) |
| 18:24:09 | jj19000 | does anyone here know where i can get a bootloader for the sansa clip? |
| 18:24:18 | | Quit lymeca (Read error: 104 (Connection reset by peer)) |
| 18:26:27 | jj19000 | anyone? |
| 18:26:57 | The-Compiler | jj19000: i'm not sure but I think the sansa version is really alpha ;) |
| 18:27:01 | gevaerts | jj19000: people can read logs. Don't ask every two minutes |
| 18:27:36 | jj19000 | sorry gevaerts |
| 18:27:41 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:28:05 | jj19000 | thank you-the compiler |
| 18:28:58 | jj19000 | anyone know how to compile one in cygwin? |
| 18:31:59 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
| 18:33:41 | gevaerts | The-Compiler: do you expect to be able to send mail to the -dev ml soon? If not, I'd like to send a quick summary about your devcon proposal myself |
| 18:34:27 | The-Compiler | gevaerts: feel free, I have enough of stress atm and gonna look at that in a week or so ;) |
| 18:35:38 | gevaerts | The-Compiler: ok. I'll include the text from http://pastebin.com/m2680ef6 and add the (possible) closing time constraints and alternative location |
| 18:36:05 | The-Compiler | sure thing |
| 18:36:17 | jj19000 | i am running windows xp,if that helps. |
| 18:36:46 | The-Compiler | You really shouldn't try to run Rockbox on a Sansa Clip yet, if it even works |
| 18:37:27 | jj19000 | why,i mean,will it brick it? |
| 18:37:50 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 18:38:21 | *** | Saving seen data "./dancer.seen" |
| 18:44:05 | jj19000 | what are the chances of rockbox bricking my sansa clip? |
| 18:44:42 | | Quit Darksair ("Everything that has a beginning has an end.") |
| 18:44:44 | gevaerts | The-Compiler: is http://pastebin.com/m4378de3e accurate enough? |
| 18:45:12 | gevaerts | jj19000: http://www.rockbox.org/twiki/bin/view/Main/CygwinDevelopment tells about how to use cygwin |
| 18:46:01 | The-Compiler | gevaerts: fine ;) |
| 18:46:11 | jj19000 | ive read that through and through,and i see nothing about compiling a bootloader. |
| 18:47:09 | gevaerts | jj19000: maybe you missed the very last line |
| 18:47:14 | | Quit homielowe () |
| 18:47:23 | gevaerts | The-Compiler: great. Sent! |
| 18:47:26 | domonoky | jj19000: its the same process as building a main binary. You just have to select bootloader instead of normal in the configure script. |
| 18:48:21 | jj19000 | thank you domonoky |
| 18:48:30 | jj19000 | i will go do that. |
| 18:48:41 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:48:55 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 18:50:01 | bertrik | kugel, you have a fuze right? does it show the the time and date in the OF? and if so, does it show the same time/date as in rockbox? |
| 18:50:14 | bertrik | domonoky, same question, except for the m200v4 |
| 18:50:57 | kugel | bertrik: no, the time in rockbox is always messed up |
| 18:51:08 | * | domonoky can not start the OF on his m200v4, it never ends the database scan, if rockbox has written to the flash before :-) |
| 18:51:10 | kugel | I didn't bother to correct it recently, nor to play around |
| 18:51:22 | kugel | I'd be very suprised though if it was different to the e200v2 |
| 18:52:00 | bertrik | I have reason to believe that the fuze and e200v2 OF count seconds since jan 1st 1970 instead of jan 1st like the older sansas |
| 18:52:09 | kugel | domonoky: really? So, it's rendered useless? I assume you cannot update rockbox this way |
| 18:52:14 | bertrik | *instead of jan 1st 1980 |
| 18:52:43 | domonoky | kugel: no problem to update. usb-mode still works fine. |
| 18:52:54 | kugel | hm wait, if it works as on my fuze the database refresh doesn't come up when you insert usb before |
| 18:53:12 | | Join JdGordon| [0] (i=836b0049@gateway/web/ajax/mibbit.com/x-289438eb5cbd0f22) |
| 18:53:58 | jj19000 | domonoky:i did that,now it says "created makefile" ,what do i do next? |
| 18:54:01 | kugel | bertrik: the only funny thing: 23rd sept 2007 is 1 year before 3.0 |
| 18:54:04 | domonoky | it also works again, when i clean the flash. But dont want todo that now.. |
| 18:54:43 | domonoky | jj19000: the same, as building a normal build. Look into our nice wiki, or wait till we release it... |
| 18:54:57 | saratoga | Bagder: for completeness, could you add the e200v2 to the build table? |
| 18:55:26 | jj19000 | ok,thank you,will do! |
| 18:55:34 | | Quit BUMBACL0T (Connection timed out) |
| 18:56:26 | kugel | saratoga: do you think the e200v2 is worth another 2 colums on this uber-wide build table? It's basically e200v2 == fuze in most concerns |
| 18:56:38 | kugel | also, then the m200v4 should probably added too, etc |
| 18:57:21 | bertrik | kugel, hmm, coincidence ... :P ? |
| 18:57:47 | bertrik | maybe we should think about swapping rows and colums in the build table |
| 18:57:54 | kugel | definitely not, just another sign that they like us |
| 18:58:16 | kugel | bertrik: no...then I need to scroll 30min to see the delta table |
| 18:59:05 | | Quit sarixe ("Leaving") |
| 18:59:29 | domonoky | kugel: all m200v4 builds are there. and adding the missing e200v2 builds would be good. So we make sure dont break things. |
| 18:59:53 | kugel | oh, didn't notice |
| 19:00 |
| 19:01:10 | kugel | domonoky: speaking of e200v2, have you had a chance to look at my unify driver patch? it drives me crazy that the scrollwheel on the e200v2 doesn't work with my fuze wheel code which works just nicelky |
| 19:01:13 | kugel | nicely* |
| 19:01:32 | domonoky | nope, i didnt find time for that. |
| 19:01:38 | kugel | and btw, I consider it as a bug if you can't wrap lists using on the e200v2 |
| 19:01:53 | kugel | s/using// |
| 19:02:13 | domonoky | yes, i also think the wheel should wrap. on players where you navigate with the buttons, it also wraps. |
| 19:03:22 | kugel | well, the wrapping works quite perfectly on my fuze (if you scroll towards the end, it doesn't wrap unless you're turning the wheel slowly at the end), but FlynDice keeps reporting that this doesn't work at all on the e200v2 (it always wraps) |
| 19:04:11 | kugel | which doesn't make sense considering my approach of generating repeats |
| 19:04:19 | kugel | to me, that is |
| 19:07:44 | bertrik | kugel, what time does your fuze show in rockbox now? |
| 19:08:07 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 19:08:25 | saratoga | i sent funman a fuze, so maybe we'll see some new commits from him soon |
| 19:08:26 | bertrik | I mean date, approximately |
| 19:08:46 | | Quit Sedgewick ("off") |
| 19:09:02 | * | domonoky applaudes to saratoga :-) |
| 19:10:22 | bertrik | I hope the old sd bank switching code works for the ams sansas too |
| 19:11:11 | * | freqmod_gq has tried to use the old sd bank switching code without success on the new ams sansas |
| 19:11:18 | freqmod_gq | maybe i didn't try hard enought |
| 19:11:19 | archivator | rasher: I figured out how to speed up/down festival's synthesis. Trying it as we speak :) |
| 19:11:19 | freqmod_gq | * |
| 19:11:27 | freqmod_gq | *enough |
| 19:11:42 | domonoky | kugel: i think we somehow need to change/improve/rewrite the scrolling code for fuze/e200v2, we can easily miss wheel changes. (on e200v2 you only get all readings if you scroll very slowly) |
| 19:12:16 | domonoky | archivator: nice. |
| 19:12:38 | kugel | domonoky: tell me how |
| 19:12:50 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
| 19:13:09 | bertrik | freqmod_gq, oh I wasn't aware of your attempts, maybe we should document stuff like that, even when unsuccessful |
| 19:13:50 | kugel | Do you think I'm not aware of the problems with polling the wheel? But on the other hand, I don't think it's essential to get all readings, we can get an accaptable wheel with the current code (slightly optimized) too |
| 19:14:13 | domonoky | we at least need to somehow handle missed wheel events. at moment the code ignores all wheel changes, till it gets again a reading which is 1 before or after your last reading. That causes this strange wheel movements sometime. |
| 19:14:20 | kugel | also, I have the impression that the OF doesn't do better at all |
| 19:15:23 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 19:15:32 | domonoky | one improvement could perhaps be, to just keep moving in the current direction, if we get a reading which isnt 1 before or after the last reading. |
| 19:15:36 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 19:15:37 | freqmod_gq | bertrik: np, here is the diff http://pastebin.ca/1353689 |
| 19:15:38 | kugel | the fuze didn't have any acceleration or list wrapping before some recent OF updates |
| 19:15:38 | archivator | domonoky: Apparently they changed the parameter name in upstream. The new manual is not out yet :( |
| 19:15:46 | | Join miepchen^schlaf [0] (n=miepel@p579EC9E8.dip.t-dialin.net) |
| 19:16:43 | kugel | domonoky: anyway, I'd like to use the same driver before doing any bigger change |
| 19:16:44 | domonoky | kugel: we want to be better then the OF ofcourse :-) |
| 19:17:20 | | Quit dfkt_dt (Connection timed out) |
| 19:17:24 | freqmod_gq | bertrik: i did a sourt f dma write as well, but i don't know if i still have the diff |
| 19:17:37 | freqmod_gq | *sort of |
| 19:17:52 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 19:19:19 | freqmod_gq | i think it is this http://pastebin.ca/1343931 |
| 19:20:04 | bertrik | freqmod_gq, nice, although I can't experiment with it myself, I only have a 1 GB clip |
| 19:20:08 | kugel | domonoky: so, I'd appreciate if you try my patch |
| 19:20:26 | freqmod_gq | :S |
| 19:21:11 | domonoky | kugel: :-) when i find time for it, i will do it. |
| 19:22:12 | kugel | freqmod_gq: you seem to ignore the response of the sd in your sent_cmd call |
| 19:23:07 | freqmod_gq | well, i did not understand how to get it, or i didn't get anything useful i think. (most likely the first) |
| 19:24:08 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 19:24:33 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 19:24:39 | | Join BUMBACL0T [0] (n=ORF@unaffiliated/bumbacl0t) |
| 19:24:46 | kugel | I'm not really convinced of your code, to be honest |
| 19:24:56 | freqmod_gq | it is probably a very weak attempt |
| 19:25:14 | kugel | but I surely appreciate the effort! |
| 19:27:21 | freqmod_gq | mostly i just copied the write code and tried to write the bank to the ata-interface as sansa did. (in the last part i linked) |
| 19:28:13 | freqmod_gq | as far as i can remeber that only resulted in the playing pausing the track after 2 secounds, then i had to unpause it for another 2 secounds |
| 19:28:47 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 19:31:05 | * | freqmod_gq gived up on fixing the clip waiting on funman or kugel to fix it, and moved on to write an protobuffer rpc port in cpp |
| 19:32:35 | | Join midijunkie41 [0] (n=Miranda@pD9547A13.dip0.t-ipconnect.de) |
| 19:33:10 | bertrik | playback isn't really reliable yet, so testing sd access by looking at playback behaviour is not a really good way |
| 19:33:44 | | Join miepchen^schla [0] (n=miepel@p579EC9E8.dip.t-dialin.net) |
| 19:34:24 | | Quit jj19000 ("CGI:IRC") |
| 19:34:46 | freqmod_gq | I think playback works well on clip, except for the corrupted files, but i get currupted md5sums too |
| 19:35:41 | bertrik | oggs seems to play fine, but I get some stutter/skips on mp3s |
| 19:35:57 | saratoga | hacking up the disktest plugin is probably a good way to test, better htne playback anyway |
| 19:36:03 | | Join gartral [0] (n=gareth@adsl-75-33-91-251.dsl.bcvloh.sbcglobal.net) |
| 19:36:30 | | Part gartral |
| 19:36:56 | | Quit midijunkie (Read error: 60 (Operation timed out)) |
| 19:37:27 | | Part pyro_maniac1 ("Leaving.") |
| 19:37:57 | n1s | saratoga: i've been meaning to ask you: you have mentioned the "tremolo" modified version of tremor a couple of times and i wonder if you think it has anything we could use and if you are planning to merge any of it into rockbox? |
| 19:38:21 | freqmod_gq | speex plays fine, at least the bits that it gets correnct (which is not strange as it is designed for (UDP) package loss) |
| 19:39:40 | saratoga | n1s: I'd like to but the auther dithered on granting us GPLv3 access and I haven't heard from him since I asked |
| 19:42:01 | saratoga | also its based on the tremor-lowmem branch, not straight tremor, so there are many differences |
| 19:42:35 | * | domonoky did some testdisk.c tests on his e200v2 some time ago, but couldnt find the bug. Symptoms are: the testdisc.c check failes on the first compare it makes. If i write the data to disk, always the first few bytes were wrong, everything else looked fine. just writing file with some numbers, always generates correct files. |
| 19:42:35 | saratoga | but yes its still on my todo list |
| 19:43:03 | n1s | saratoga: ah, a "v2" vs "v2 or later" thing? |
| 19:43:22 | saratoga | n1s: yes |
| 19:43:54 | saratoga | his improvements should be merged into our tremor, or at least used as inspiration if he won't relicense them, but theres plenty else to keep me busy with codecs so i haven't followed up on it recently |
| 19:46:28 | | Quit miepchen^schlaf (Read error: 113 (No route to host)) |
| 19:51:00 | kugel | domonoky: that seems to match my testdisk run (hence I added the flawed on the SansaAMS wiki page) |
| 19:51:32 | | Quit __lifeless (Remote closed the connection) |
| 19:51:35 | domonoky | kugel: yes, looks pretty much like some memory problems.. but who knows.. |
| 19:53:52 | saratoga | why memory problems? |
| 19:54:04 | | Join _lifeless [0] (n=lifeless@90.150.119.103) |
| 19:54:15 | saratoga | if the first few bytes are wrong that sounds like timing issues in the driver |
| 19:56:07 | | Join arohtar [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) |
| 19:56:51 | kugel | saratoga: maybe the one line "MCI_DATA_TIMER(drive) = 0x1000000; /* FIXME: arbitrary */" should be adjusted? |
| 19:58:51 | domonoky | what test_disc does is: generate a sequence into memory, write the mem to file. read the file into mem again, and compare against the generation sequence. If i write my numbers into the buffer, and let test_disc write the buffer to file. The first few bytes are wrong. if i write directly into the file, its fine. |
| 20:00 |
| 20:00:51 | saratoga | are there any cache concerns on AMS chips and hardware? |
| 20:01:11 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 20:01:24 | amiconn | test_disk uses both aligned and unaligned memory blocks, so the driver might have a problem with unaligned data |
| 20:01:31 | saratoga | since theres only 1 core I assume the L1 is coherent with the SD controller, but maybe not? |
| 20:02:09 | amiconn | If the SD driver uses DMA, caching issues might be another reason |
| 20:04:56 | domonoky | it uses dma. |
| 20:06:44 | kugel | saratoga: the data cache isn't active. |
| 20:06:54 | kugel | And I don't think L1 can be shared, can it? |
| 20:07:12 | saratoga | kugel: L1 can't be shared |
| 20:07:18 | saratoga | you're sure its not active? |
| 20:07:44 | kugel | the mmu isn't active, and the data cache cannot be active without mmu |
| 20:08:38 | | Quit MethoS- (Remote closed the connection) |
| 20:09:24 | kugel | saratoga: that also explains the huge performance difference between clip and fuze/e200v2 |
| 20:09:32 | kugel | for codecs that is |
| 20:09:53 | | Join MethoS- [0] (n=lem@host-091-097-243-240.ewe-ip-backbone.de) |
| 20:11:50 | kugel | saratoga: btw, I implemented the lcd_enable_hook for the disable wps update patch |
| 20:12:41 | saratoga | kugel: i saw that |
| 20:12:53 | | Quit faemir (Read error: 110 (Connection timed out)) |
| 20:13:05 | saratoga | did MikeS have any other concerns? |
| 20:13:18 | saratoga | i'd really like to see that patch go in once theres agreement that it does everything it needs to |
| 20:13:30 | saratoga | [i know almost nothing about that part of rockbox so I can't really comment] |
| 20:13:40 | kugel | well, it adds a hell lot of |
| 20:14:01 | kugel | #ifdefs due to the unregestering of the hook (which I'm fairly sure isn't needed, actually) |
| 20:22:17 | | Quit SirFunk (Read error: 60 (Operation timed out)) |
| 20:23:40 | | Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) |
| 20:24:13 | | Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 20:26:06 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
| 20:28:20 | | Quit kushalone ("Leaving") |
| 20:29:10 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 20:38:01 | | Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-935c86e3dc9b535e) |
| 20:38:22 | *** | Saving seen data "./dancer.seen" |
| 20:40:27 | | Join z35 [0] (n=z35@h200.80.91.75.dynamic.ip.windstream.net) |
| 20:41:18 | | Join albinoblackrabbi [0] (n=519b4220@gateway/web/cgi-irc/labb.contactor.se/x-a5bda731ef9d938b) |
| 20:41:21 | | Quit Xerion (Connection timed out) |
| 20:41:21 | | Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) |
| 20:42:49 | | Join The3_14ed|r [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 20:43:22 | | Quit albinoblackrabbi (Client Quit) |
| 20:44:28 | | Quit Dhraakellian (Nick collision from services.) |
| 20:44:32 | | Nick The3_14ed|r is now known as Dhraakellian (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 20:46:36 | | Quit arohtar (Client Quit) |
| 20:46:50 | | Join faemir [0] (n=faemir@88-106-169-118.dynamic.dsl.as9105.com) |
| 20:49:18 | | Quit bs66_1 (Read error: 110 (Connection timed out)) |
| 20:49:41 | | Join bs66_ [0] (n=sysuser@79.138.210.78.bredband.tre.se) |
| 20:49:46 | | Join pyro_maniac [0] (n=jens@i59F779B8.versanet.de) |
| 20:52:27 | | Quit dfkt_dt (Read error: 110 (Connection timed out)) |
| 20:52:50 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 20:56:53 | | Join planetbeing_ [0] (n=planetbe@24.86.172.128) |
| 21:00 |
| 21:01:36 | | Quit Nico_P (Remote closed the connection) |
| 21:01:41 | | Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") |
| 21:03:27 | | Nick miepchen^schla is now known as miepchen^schlaf (n=miepel@p579EC9E8.dip.t-dialin.net) |
| 21:04:57 | | Quit midijunkie41 (Read error: 110 (Connection timed out)) |
| 21:12:37 | | Join midijunkie [0] (n=Miranda@pD9547A13.dip0.t-ipconnect.de) |
| 21:13:19 | | Join Thundercloud [0] (n=thunderc@82.132.136.191) |
| 21:14:21 | | Nick courtc_ is now known as courtc (n=court@unaffiliated/courtc) |
| 21:18:31 | | Join Chesteta [0] (i=Chesteta@dyn216.wireless-104.ndsu.NoDak.edu) |
| 21:19:27 | | Join MrSpeedy [0] (n=misko@92.52.42.149) |
| 21:19:32 | Chesteta | hey I noticed last night that for the e200v2 starting with r20170 things do not compile correctly |
| 21:19:52 | Chesteta | anyone else having the same experience? |
| 21:20:09 | bertrik | I have no trouble compiling for e200v2 |
| 21:20:55 | archivator | Chesteta: try doing a make clean (or veryclean) before compiling.. |
| 21:21:34 | Chesteta | I created a new build directory... is that sufficient? |
| 21:22:33 | archivator | What error are you getting? |
| 21:23:32 | saratoga | he posted that its dying during building the languages |
| 21:23:34 | Chesteta | one sec... ill do a pastebin in a sec |
| 21:23:42 | saratoga | so its probably just a bad SVN check out or similar |
| 21:24:11 | | Quit MrSpeedy (Remote closed the connection) |
| 21:24:57 | archivator | Chesteta: does a svn up show any conflicts? |
| 21:25:17 | Chesteta | one sec; im running the build again; i hadn't saved the error last night |
| 21:25:33 | | Nick BigBambi_ is now known as BigBambi (n=alex@rockbox/staff/BigBambi) |
| 21:25:53 | Chesteta | I think it was error code 2 :/ |
| 21:27:01 | kadoban | Chesteta: the final error codes from make aren't very helpful. look up a ways for the first error |
| 21:27:40 | bertrik | just did a clean build of e200v2, no problems, I'll try with an empty ccache again |
| 21:28:31 | Chesteta | hmmm maybe i had a bad update; im still running the make however usually by now it would have errored out |
| 21:29:23 | | Join ZincAlloy [0] (n=d9eec41c@gateway/web/cgi-irc/labb.contactor.se/x-a3aa6cbe558e83a1) |
| 21:31:39 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
| 21:32:37 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 21:33:37 | | Quit midijunkie ("?(???~•~)?") |
| 21:36:03 | | Quit pyro_maniac (Read error: 110 (Connection timed out)) |
| 21:36:34 | pixelma | ZincAlloy: seen the discussion in the dev ML about the theme licensing (I believe cabbiev2 was your work originally with some others helping with ports, right)? |
| 21:42:39 | ZincAlloy | pixelma: I noticed there was some discussion. I'm gonna give it a read.. |
| 21:43:39 | | Join yhuang [0] (n=yhuang@unaffiliated/yhuang) |
| 21:47:00 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 21:47:41 | Chesteta | I no longer get an error on the build but when running "make zip" i get many errors |
| 21:48:01 | Chesteta | DWIDTH spec > max FONTBOUNDINGBOX |
| 21:49:09 | Chesteta | there are alot of warnings saying characters will be clipped |
| 21:49:35 | Llorean | Those are just warnings, and are to be expected and ignored now. |
| 21:49:55 | Chesteta | ok cool |
| 21:50:49 | | Quit thickinit ("Lost terminal") |
| 21:51:13 | | Part domonoky |
| 21:51:23 | | Join webguest34 [0] (n=477f17d7@gateway/web/cgi-irc/labb.contactor.se/x-0e5766b479d7f53f) |
| 21:51:55 | Chesteta | yea; saratoga, I apologize for the trouble with my post last night; I will refrain from posting in the New Port forum unless I work on the port or am answering a question (when someone asks someone to test and report back) |
| 21:53:20 | webguest34 | i am having problems compiling a sansa clip fwpatcher,is there one readily available? |
| 21:53:55 | saratoga | no |
| 21:54:25 | ZincAlloy | pixelma: and you're right about cabbiev2.. |
| 21:54:46 | saratoga | didn't we GPL cabbiev2? |
| 21:55:18 | linuxstb | webguest34: What's your problem? You need to have the Rockbox toolchain installed (easiest way is running tools/rockboxdev.sh - select at least ARM) |
| 21:56:47 | webguest34 | ok,i am compiling under win xp home and cygwin....i get the following error when compiling form source code.....***no rule to make target ' bootloader h100.bin' needed by resource.o |
| 21:57:21 | webguest34 | bootloader-h100.bin* |
| 21:57:50 | linuxstb | What are you trying to compile? For the Clip you need rbutil/mkamsboot/ |
| 21:58:32 | webguest34 | fwpatcher |
| 21:58:37 | ZincAlloy | pixelma: but I only made the artwork for the colour version. the greyscale and black and white versions use different artwork. |
| 21:58:47 | saratoga | fwpatcher is for iriver |
| 21:58:54 | linuxstb | webguest34: Why? What instructions said to use that? |
| 21:59:22 | pixelma | ZincAlloy: yeah, I took part in the porting effort for those myself |
| 21:59:39 | webguest34 | its just me guessing |
| 21:59:49 | webguest34 | im a total newb at this |
| 22:00 |
| 22:00:08 | saratoga | webguest34: you probably shouldn't be doing this at all |
| 22:00:24 | ZincAlloy | pixelma: oh, of course... good work! :) |
| 22:00:40 | webguest34 | well,im REALLY interested in this... |
| 22:01:06 | webguest34 | ive already compiled my own fw |
| 22:01:20 | webguest34 | for the clip |
| 22:02:05 | | Quit webguest34 ("CGI:IRC") |
| 22:02:08 | | Join webguest34 [0] (n=477f17d7@gateway/web/cgi-irc/labb.contactor.se/x-c1042478a4a34bd5) |
| 22:02:18 | | Quit webguest34 (Client Quit) |
| 22:02:21 | | Join webguest34 [0] (n=477f17d7@gateway/web/cgi-irc/labb.contactor.se/x-5a28e047ec8ed9de) |
| 22:02:28 | Llorean | webguest34: being REALLY interested doesn't really prevent you from running into problems. While the process is as safe as we can make it now, trying to guess things rather than taking the time to read everything written about it and ask clear questions afterward is a good way to do something wrong. While we can make the right steps as failure proof as possible, we can't prevent people from doing things completely wrong and messing up the |
| 22:02:44 | | Quit webguest34 (Client Quit) |
| 22:02:48 | | Quit Chesteta () |
| 22:04:17 | | Join redwolf1910 [0] (n=477f17d7@gateway/web/cgi-irc/labb.contactor.se/x-1a8bf64740a380a1) |
| 22:05:28 | redwolf1910 | hi again,im the guy w/ the sansa clip problem |
| 22:05:50 | BigBambi | redwolf1910: Did you see what Llorean said? |
| 22:06:01 | redwolf1910 | no |
| 22:06:06 | Llorean | redwolf1910: being REALLY interested doesn't really prevent you from running into problems. While the process is as safe as we can make it now, trying to guess things rather than taking the time to read everything written about it and ask clear questions afterward is a good way to do something wrong. While we can make the right steps as failure proof as possible, we can't prevent people from doing things completely wrong and messing up th |
| 22:06:45 | BigBambi | Llorean: Cut off at "messing up th" - I suspect the end is messing up their player though :) |
| 22:06:54 | BigBambi | redwolf1910: Especially when a target is under development and not supported yet |
| 22:06:55 | redwolf1910 | i see..... |
| 22:07:07 | Llorean | "messing up their player." yes. |
| 22:07:08 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
| 22:07:58 | Llorean | redwolf1910: It doesn't even play music reliably yet, so if you're not planning on doing actual programming, you're going to find significant glitches and bugs getting in the way of simply using your player |
| 22:08:49 | redwolf1910 | i know i have to learn C.....and learn about ARM....... |
| 22:10:07 | saratoga | if you want to learn to program thats great, but you should start off smaller then working on a new port |
| 22:10:22 | redwolf1910 | like? |
| 22:10:28 | BigBambi | redwolf1910: I'd do some learning before randomly trying things, that way the chances of crewing things up are smaller |
| 22:10:46 | BigBambi | Anything - find an online C tutorial |
| 22:11:11 | BigBambi | Programming for these limited embedded devices is on the difficult end of the scale - not the ideal place to start |
| 22:12:14 | redwolf1910 | do i have to download any softs? |
| 22:12:34 | saratoga | to program? yes |
| 22:13:01 | redwolf1910 | like......visual c++? |
| 22:13:13 | BigBambi | redwolf1910: This isn't the place for a programming tutorial |
| 22:13:16 | | Quit yhuang (Read error: 110 (Connection timed out)) |
| 22:13:33 | BigBambi | redwolf1910: But Rockbox is written in C, not Visual C++ |
| 22:13:33 | Llorean | redwolf1910: If you've compiled Rockbox already, and you have a text editor, you have the bare minimum tools necessary. |
| 22:13:36 | Llorean | Anything else you use is up to you. |
| 22:14:06 | redwolf1910 | i know...im asking what programs are best for the job. |
| 22:14:11 | | Quit dfkt_dt (Read error: 60 (Operation timed out)) |
| 22:14:29 | | Join draft [0] (n=draft@dsl-tkubrasgw1-fe2dfa00-68.dhcp.inet.fi) |
| 22:14:39 | draft | howdy |
| 22:14:45 | redwolf1910 | ok Llorean |
| 22:14:55 | redwolf1910 | thx to you |
| 22:15:02 | draft | i'm trying to install Rockbox in 1st gen iPod and i'm having some problems.. can anyone help me? |
| 22:15:08 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 22:15:13 | BigBambi | sure, just ask |
| 22:15:58 | draft | BigBambi: just gimme a second.. i'll try once more. |
| 22:18:14 | | Quit draft (Read error: 104 (Connection reset by peer)) |
| 22:19:02 | redwolf1910 | IF....i were to put rockbox on the clip, what would i need besides the clip? |
| 22:21:02 | saratoga | redwolf1910: have you read the instructions yet? |
| 22:21:34 | redwolf1910 | oh goodness..........no....... hold on. |
| 22:21:47 | redwolf1910 | going there now |
| 22:25:38 | | Quit saratoga ("CGI:IRC (EOF)") |
| 22:31:01 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 22:32:13 | | Quit redwolf1910 ("CGI:IRC (EOF)") |
| 22:38:26 | *** | Saving seen data "./dancer.seen" |
| 22:40:07 | | Join Lss [0] (n=Lss@59.189.141.130) |
| 22:45:29 | | Quit BigBambi ("Please insert girder") |
| 22:45:56 | | Quit Horscht ("Verlassend") |
| 22:47:19 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 22:47:28 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 22:49:08 | | Join draft [0] (n=draft@dsl-tkubrasgw1-fe2dfa00-68.dhcp.inet.fi) |
| 22:49:10 | | Join BigBambi [0] (n=alex@152.27.192-77.rev.gaoland.net) |
| 22:50:41 | | Join dfkt_dt [0] (i=dfkt@unaffiliated/dfkt) |
| 22:53:18 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 22:54:11 | | Quit archivator () |
| 22:55:26 | gevaerts | It seems that the ipod OF presents 4k-sector-disks as having 2k sectors over USB, so they get formatted with 2K sectors. Rockbox USB asks the disk how many blocks it has (actually, ata.c does the real work), and disk.c finds out how big those blocks are |
| 22:56:27 | gevaerts | disk.c uses the FAT sector size for this, which happens to be 2K on these disks, while the block count assumes 4K sectors, so one of these is wrong |
| 22:56:56 | gevaerts | I'd say the block count is the one that's wrong, because otherwise we lose compatibility with the OF |
| 22:58:21 | | Quit stripwax (Read error: 110 (Connection timed out)) |
| 22:58:55 | * | gevaerts thinks |
| 22:59:58 | | Join fml [0] (n=4fd3f48a@gateway/web/cgi-irc/labb.contactor.se/x-d41f5fe6ddee5513) |
| 23:00 |
| 23:00:25 | gevaerts | This needs an ATA specialist... |
| 23:00:26 | Lss | is it just me or is it not possible to find files transfered to an ipod via itunes under rockbox |
| 23:00:35 | Lss | i dont think i managed to find it |
| 23:00:41 | Llorean | Lss: It's perfectly possible, they're just hidden and renamed. |
| 23:00:49 | Lss | i see |
| 23:01:10 | Lss | possible for the file view to display them? even if its renamed? |
| 23:01:12 | fml | Has anybode taken a look at the patch added to FS #9931 ? It adds the possibility to set line spacing in RB and is proposed as a cure for "too big" glyphs. I'm reluctant to add something like this to RB. Any opinions? |
| 23:02:50 | | Quit petur (Remote closed the connection) |
| 23:02:53 | amiconn | gevaerts: Don't confuse logical sectors (fat) and physical sectors (ata) |
| 23:03:15 | gevaerts | amiconn: actually, I was wrong. The problem is something else |
| 23:04:13 | amiconn | If an ata disk has large physical sectors, it still returns the number of 512-byte sectors for compatibility, only that accessing sectors which are smaller than the physical one becomes slow |
| 23:04:15 | Llorean | Lss: Yes, as I said they're simply hidden. If you tell File View to show all files then you'll see them. |
| 23:04:25 | Llorean | Lss: I'm almost positive this is in the Ipod FAQ on the wiki |
| 23:04:32 | | Join draft_ [0] (n=draft@dsl-tkubrasgw1-fe39dc00-45.dhcp.inet.fi) |
| 23:04:33 | gevaerts | This is an LBA48 problem after all |
| 23:04:38 | amiconn | The original G5.5 80GB disk has a firmware bug that makes it refuse partial sector transfers |
| 23:05:00 | amiconn | gevaerts: Rockbox doesn't support LBA48 by default, but can be told to |
| 23:05:20 | Llorean | amiconn: There's a reported problem with LBA48 enabled and the USB stack on a 240GB disk |
| 23:05:34 | gevaerts | amiconn: I know. The problem is that ata_get_info() (my code) doesn't do it properly |
| 23:05:39 | n1s | fml: i agree, an independently changeable line space is not a fix for clipped fonts |
| 23:05:48 | | Quit {phoenix} (Remote closed the connection) |
| 23:06:13 | n1s | I think a font should have lines as tall as the tallest glyph |
| 23:07:27 | amiconn | gevaerts: I think that the storage drivers should have a function that returns the size in sectors |
| 23:07:51 | amiconn | The ata driver calculates it, but then only uses it for boundary checks |
| 23:08:00 | amiconn | total_sectors |
| 23:08:10 | Llorean | n1s: This makes some fonts as much as 1.5 times their current height for the benefit of one or two glyphs. This can be frustrating for people who want to use the font's 24 point characters but end up having to reserve the equivalent space of a 36 point font for it. |
| 23:08:32 | Llorean | n1s: It basically makes some font nearly unusable for people who don't need those glyphs. |
| 23:08:40 | Llorean | It's kinda a "no win" situation. |
| 23:08:41 | gevaerts | Yes, and ata_get_info() doesn't use total_sectors and instead reads it again from identify_info, ignoring LBA48... |
| 23:08:42 | n1s | Llorean: then those glyphs should be fixed |
| 23:08:46 | Lss | i have trouble with unicode filenames on the default wps |
| 23:08:53 | Lss | i have to switch to the unicode one |
| 23:08:59 | Lss | on my 5.5g ipod |
| 23:09:04 | JdGordon| | thats not surprisiing |
| 23:09:09 | * | gevaerts fixes ata_get_info() to just use total_sectors |
| 23:09:20 | soap | Could we just issue two versions of the "offending" fonts? |
| 23:09:29 | soap | A clipped and a "respaced" version? |
| 23:09:30 | Llorean | n1s: How do you fix a glyph needing more space other than by providing it more space? |
| 23:10:05 | Llorean | Lss: Unicode is a font issue. Not all fonts have every unicode character (in fact, only one does that we have) |
| 23:10:41 | Lss | if i didnt remember wrongly its the layout not being suitable |
| 23:10:53 | Lss | i have to both switch to unicode as font |
| 23:10:56 | Lss | and change the wps |
| 23:11:07 | fml | Llorean, n1s: In some fonts, an accented O is smaller that the normal O so that an accented O still fits in. |
| 23:11:20 | Llorean | Lss: The layout is not suitable for larger fonts... it can't automatically adapt to any font size. |
| 23:11:42 | n1s | Llorean: i'm no expert but if it *needs* 1.5 times the space of the other glyphs clipping away a large chunk of the glyph won't be very nice either |
| 23:11:48 | fml | But my point is that it's a question of the font and not of the RB's rendering engine |
| 23:12:07 | evilnick_7 | gevaerts: I'm having a few issues copying from a Sansa e280 uSD card to a beast (both using Rockbox USB) |
| 23:12:20 | n1s | fml: i think that is the most sensible way to deal with it |
| 23:12:34 | n1s | a 24 pixel font should not be taller than 24 pixels |
| 23:12:42 | fml | Hence I'd like to provide an option for those users who want to have the font 1.5 times taller |
| 23:12:59 | evilnick_7 | gevaerts: I'll manage to copy a certain amount and then get the (Windows) error "Cannot copy [name of file] - path is too deep" |
| 23:13:34 | | Quit Thundercloud (Remote closed the connection) |
| 23:15:00 | | Quit dfkt (Read error: 145 (Connection timed out)) |
| 23:15:15 | | Join draft__ [0] (n=draft@dsl-tkubrasgw1-fe2dfa00-68.dhcp.inet.fi) |
| 23:15:51 | gevaerts | evilnick_7: that sounds like the traditional windows 255 byte (or how much is it?) total path length issue. You'll need to either use shorter paths or another OS to get at them |
| 23:16:01 | gevaerts | in other words, not related to usb |
| 23:16:03 | amiconn | Or another program |
| 23:16:30 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 23:16:35 | amiconn | Windows *does* support long paths, but not every windows app does. Windows explorer is among them |
| 23:16:35 | evilnick_7 | gevaerts: It's nothing to do with that, it happens on different files each time,so that's why I assumed that it was related to Rockbox USB? |
| 23:16:45 | amiconn | Try robocopy - it handles long paths just fine |
| 23:17:36 | fml | n1s: with the new options you'll be able to generate a 36 pixel font from a, say, 24 pixel BDF font. It's your responsibility then to correctly name the generated .fnt file (the BDF file has "24" in the name) |
| 23:17:57 | evilnick_7 | I'll try a few other apps when I have chance (and internet) |
| 23:18:30 | gevaerts | maybe just check manually how long the total path is |
| 23:18:49 | n1s | fml: i don't see an option to do that as a solution either, we should ship font's that are what they claim |
| 23:20:05 | Llorean | n1s: Our fonts are what they claim, the problem is that the Rockbox font rendering can't allow lines to overlap like other font rendering systems can. |
| 23:20:36 | Llorean | We respect the actual ascent and descent values of the font, the problem is "ascent" and "descent" tell you how to space lines, but don't equal the maximum space apart lines would need to be to avoid overlap. |
| 23:20:53 | evilnick_7 | gevaerts: G:\new_music\Arcade Fire\2004-09-14 - Funeral\04 - Neighborhood #3 (Power Out) - Arcade Fire.mpc |
| 23:21:03 | | Quit matsl (Remote closed the connection) |
| 23:22:24 | gevaerts | evilnick_7: is that the source or target path, or are they both of simiral length? |
| 23:22:28 | fml | n1s: we do it now and we'll do it in the future (in the "officially shipped" fonts). But some of them will be clipped. If a user would rather have a taller font but with less clipped glyphs (or clipped to a lesser degree) he can build the fonts himself using the new (yet to be implemented) options |
| 23:23:19 | evilnick_7 | gevaerts: That's the source, destination is: F:\mpc\new_music\Arcade Fire\2004-09-14 - Funeral\04 - Neighborhood #3 (Power Out) - Arcade Fire.mpc |
| 23:24:11 | gevaerts | OK, so four more. 106 characters if I count right. |
| 23:25:22 | gevaerts | I'd still be interested to see what happens if you use a different program to copy them |
| 23:25:37 | evilnick_7 | Is there any chance it could be any kind of "timing issue"? And Windows reports it as the wrong error message? Having used the beast as an external drive there are lots of disk access "pauses" when running portable Firefox. |
| 23:26:07 | gevaerts | I somehow doubt that. |
| 23:26:56 | gevaerts | evilnick_7: also maybe run chkdsk on both drives |
| 23:27:20 | evilnick_7 | gevaerts: The beast was checked last night, so I'll check both again to be on the safe side. |
| 23:27:47 | | Quit draft_ (Read error: 110 (Connection timed out)) |
| 23:28:21 | | Quit evilnick_7 ("http://www.mibbit.com ajax IRC Client") |
| 23:30:41 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-6ebd85caf1d2000b) |
| 23:31:34 | | Quit draft (Connection timed out) |
| 23:31:54 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 23:33:41 | | Join LambdaCalculus37 [0] (i=408176ca@rockbox/staff/LambdaCalculus37) |
| 23:34:59 | | Join webguest87 [0] (n=47441ff7@gateway/web/cgi-irc/labb.contactor.se/x-1750bf85d0ec064e) |
| 23:35:36 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 23:38:21 | webguest87 | sup |
| 23:38:55 | | Quit webguest87 (Client Quit) |
| 23:39:23 | | Quit dfkt_dt (Connection timed out) |
| 23:41:22 | | Quit tyfoo (Read error: 104 (Connection reset by peer)) |
| 23:41:48 | | Join dfkt_dt [0] (n=dfkt@unaffiliated/dfkt) |
| 23:44:58 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 23:46:40 | | Quit fml ("CGI:IRC") |
| 23:48:57 | | Quit jgarvey ("Leaving") |
| 23:50:58 | | Join peanus [0] (n=peanus@190.40.124.177) |
| 23:51:05 | peanus | ohai guise |
| 23:51:43 | | Quit draft__ (Read error: 131 (Connection reset by peer)) |
| 23:52:58 | stripwax | What might cause an Invalid Instruction error right at startup (after Rockbox logo)on a clean svn local build? (after svn up, svn diff, make clean, make..). Could there be something that make clean doesn't clean? |
| 23:53:18 | stripwax | Latest build from RockboxUtility seems to work fine so I'm guessing something 'funny' with my build |
| 23:53:41 | stripwax | (and my local builds we fine until fairly recently, last few days or so) |
| 23:54:00 | stripwax | ^we^were |
| 23:56:19 | bluebrother | ok, anyone interested in updating the rbutil translation before release? I want to release tomorrow evening (i.e. in 20something hours) |
| 23:56:36 | peanus | I am having an install issue, and I think someone here knows what to do. ..... Installing on: A 30gb (2048) iPod, Installing With: Macbook running 10.5 ...... I already: (1) formatted the ipod to FAT32 on a windows machne, (2) set the path, path correctly in the installer to the ipod. ..... the problem: brutil returns the error "No iPod Detected, Permission for disc access denied!" |
| 23:56:43 | peanus | what do it do? |
| 23:57:10 | bluebrother | run rbutil with sudo |
| 23:57:12 | domonoky | run it with root/admin right. |
| 23:57:20 | bluebrother | or from a root console |
| 23:57:47 | peanus | ....how? |
| 23:58:07 | * | bluebrother goes stealing broken ellipsae |
icon identifies that the person is a core developer (has commit access).