| 00:06:08 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 00:07:21 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 00:20:08 | | Join wpyh [0] (n=william@125.163.88.253) |
| 00:20:31 | Buschel_ | even the downloaded r19589-build stops playback after 1h 15min. tested without active battery bench. |
| 00:20:50 | Buschel_ | I will now test the build from december, 24th. |
| 00:21:00 | Buschel_ | good night |
| 00:21:03 | | Quit Buschel_ () |
| 00:23:55 | | Join Adminy [0] (n=chatzill@d57-106-195.home.cgocable.net) |
| 00:24:01 | | Nick Adminy is now known as eragon (n=chatzill@d57-106-195.home.cgocable.net) |
| 00:24:42 | | Nick eragon is now known as ahhit (n=chatzill@d57-106-195.home.cgocable.net) |
| 00:24:56 | | Nick ahhit is now known as in-use (n=chatzill@d57-106-195.home.cgocable.net) |
| 00:25:27 | | Quit Acky (Connection timed out) |
| 00:25:28 | in-use | i was just wondering if someone could anwser a ? i have about rockbox |
| 00:25:41 | in-use | does it work on the sansa veiw? |
| 00:26:00 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 00:26:46 | | Part in-use |
| 00:26:51 | | Join in-use [0] (n=chatzill@d57-106-195.home.cgocable.net) |
| 00:27:21 | | Quit {phoenix} (Remote closed the connection) |
| 00:30:38 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 00:32:49 | | Join davidbarry [0] (n=davidbar@ip68-229-199-173.ok.ok.cox.net) |
| 00:33:16 | | Quit Acksaw (Connection timed out) |
| 00:33:27 | davidbarry | I've got a 5g ipod with rockbox on it(love it by the way) and I was wondering how to keep it from making a data connection when I plug in via usb. Is there anyway to have it charge only when connected via usb? |
| 00:36:03 | gevaerts | davidbarry: You need to hold a button while connecting. The manual knows which one (search for "power") |
| 00:36:16 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 00:39:29 | | Join saratoga [0] (n=62e14d04@gateway/web/cgi-irc/labb.contactor.se/x-c4cbdbd5ab2a3694) |
| 00:40:36 | | Quit Acky (Read error: 60 (Operation timed out)) |
| 00:40:57 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 00:42:41 | davidbarry | Thanks for the help. Checked the manual and it says to hold down the menu key as I plug it in but it doesn't do anything, just connects like normal. Is there a certain time I need to begin holding it(when the usb icon shows up?) I'm not sure it matters, but I'm running Opensuse 11.1 if that would have any impact |
| 00:43:58 | gevaerts | You need to hold it from before pluging in |
| 00:44:14 | *** | Saving seen data "./dancer.seen" |
| 00:45:29 | davidbarry | That did the trick, thanks a lot for the assistance! |
| 00:46:08 | | Quit soap (Read error: 60 (Operation timed out)) |
| 00:50:50 | | Quit ender` (" A man without religion is like a fish without a bike.") |
| 00:51:08 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 00:53:24 | | Join grndslm [0] (n=grndslm@24-119-80-142.cpe.cableone.net) |
| 00:57:12 | | Quit Acksaw (Connection timed out) |
| 00:59:05 | | Quit balou (Read error: 110 (Connection timed out)) |
| 01:00 |
| 01:00:30 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 01:13:57 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-119-108.ewe-ip-backbone.de) |
| 01:16:51 | kugel | Unhelpful: hey yo, you messed with pf lately, so I wondered if you could a have a look at/test (potentially commit if it's fine) FS #8335 |
| 01:18:27 | | Quit culture (Read error: 110 (Connection timed out)) |
| 01:18:44 | Unhelpful | is the last resync still clean vs svn? |
| 01:19:00 | kugel | the resizing part is probably not needed for a long time, but I like the album text setting and the setting if resize is applied |
| 01:19:16 | kugel | no idea, I'll try and put a sync'd one |
| 01:19:43 | Unhelpful | if it doesn't need it, that's fine |
| 01:20:10 | | Join balou [0] (i=balou@cl-1844.ham-01.de.sixxs.net) |
| 01:20:50 | kugel | Unhelpful: but maybe putting a sync'd is easier than checking if the version on the task is in sync? ;) |
| 01:21:25 | | Quit in-use ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 01:23:39 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
| 01:23:52 | | Join gromit`` [0] (n=gromit@ALagny-154-1-63-173.w81-249.abo.wanadoo.fr) |
| 01:24:21 | kugel | Unhelpful: so you said, the search for cover.XxY.bmp is basically useless right? (I agree) |
| 01:26:51 | | Quit parafin (Nick collision from services.) |
| 01:27:00 | | Join parafin [0] (i=parafin@paraf.in) |
| 01:27:22 | Unhelpful | kugel: *with* the height/2 change, yes, since it's a size basically determined per-target at compile-time |
| 01:28:11 | Unhelpful | i'd like to know what other people think of the height/2 change, and i think i might like how i did the center margin change better, but i haven't looked at your patch yet. |
| 01:29:23 | Unhelpful | i'd rather make +0 == sides-touch-center, since -40 will (i think) not work the same on all targets. also, it makes the option value "meaningful", since it becomes an offset from edges of the center cover. |
| 01:31:02 | | Join tvelocity [0] (n=tony@athedsl-341834.home.otenet.gr) |
| 01:31:26 | | Quit gromit` (Read error: 110 (Connection timed out)) |
| 01:33:36 | Unhelpful | also, if resize is optional, should we then keep the check for cover.WxH.bmp? |
| 01:33:45 | kugel | Unhelpful: so, I updated |
| 01:34:19 | kugel | Unhelpful: from my experience height/2 looks very good (on my e200) |
| 01:35:03 | Unhelpful | it looks good on my S60 as well, though i think the effect is really designed with landscape layout in mind. |
| 01:35:30 | kugel | " make +0 == sides-touch-center" sounds reasonable to me, I haven't looked into it though |
| 01:35:52 | kugel | Unhelpful: I imagine it looks even better on landscape |
| 01:36:25 | Unhelpful | well, it was roughly at that on the largest landscape targets, if you used the suggested 100x100 size |
| 01:36:41 | kugel | why do you think -40 will not work on all targets? have you tested? |
| 01:37:39 | kugel | I admit I haven't tested on every target, but those 2-3 seem to behave similar (iirc) |
| 01:37:43 | Unhelpful | no, but i've looked at how the center margin adustment is applied |
| 01:38:26 | kugel | I think every value is rather arbitary without telling what it's about |
| 01:38:51 | kugel | artificial even |
| 01:40:13 | Unhelpful | well, it should, as i read it, be in screen pixels, and it's based on the average (not maximum) album art width. that alone makes it pretty hard to figure out what "0" means in the current scheme. |
| 01:40:34 | Unhelpful | making "0" == a max-width album in center touches the side albums seems very sensible, to me. |
| 01:41:13 | Unhelpful | and leaving things not clearly defined if you're not using the resizer doesn't bother me, since they're really not clearly defined right now. |
| 01:41:26 | kugel | sure, 0 suggest that there's no margin between center and side slides |
| 01:41:50 | kugel | and it's far from that |
| 01:43:37 | kugel | Unhelpful: so, basically, you may decide. I can have a look into putting that into FS #8335, or you do it yourself with your pending pf patch |
| 01:46:26 | Unhelpful | does anybody else have an opinion to contribute here? i generally get the impression that PF is mostly considered a demo/toy at this point, so that changes in how it behaves might be a little more allowable than in other areas... but if i commit what we're talking about, people already using PF are going to see it change, because the meaning of a config value will change. |
| 01:47:10 | kugel | I don't change the meaning, I only change the default value |
| 01:47:19 | kugel | (with the current patch) |
| 01:47:40 | Unhelpful | which is the major thing in favor of the way you do it, in my mind |
| 01:48:07 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust202.bagu.cable.ntl.com) |
| 01:48:12 | Unhelpful | but, on the other hand, the value doesn't have a "meaning" that can be readily understood by the user, right now, and it might be worth breaking configs to change that. |
| 01:48:17 | kugel | well, it doesn't change that the meaning is unclear to the user |
| 01:48:48 | kugel | I'd surely welcome to make this setting a understandable one |
| 01:49:47 | kugel | but on the other side, maybe the user doesn't care about what it means, and just pick one that fits without thinking about |
| 01:50:10 | Unhelpful | and for those users, the change i propose is A Bad Thing. |
| 01:50:33 | kugel | probably |
| 01:51:41 | kugel | not too bad though |
| 01:52:04 | kugel | he'll need to reset it once, that doesn't hurt much imo |
| 01:53:52 | * | kugel just notices that task is already a year old |
| 01:54:20 | Unhelpful | i'm inclined to agree, and after that, it's set in a way that makes sense for everybody. i'm going to be too busy to really work on it for a few hours to come, anyway. i think it would probably be reasonable to commit it if there aren't complaints by then... but then, i don't expect to be hearing much from other devs on *anything* tonight, and that makes me a little nervous about just tossing it in. |
| 01:54:24 | | Join QUICKSTART [0] (n=QUICKSTA@pool-72-88-172-78.nwrknj.east.verizon.net) |
| 01:54:28 | kugel | and it was partly committed already twice :) only the fixes though, since it was pre-release both times |
| 01:55:27 | kugel | Unhelpful: sure, no need to hurry. I didn't ask for commit, just for a look at it :) |
| 01:56:52 | kugel | Unhelpful: even though it doesn't remove/change functionality, just extends existing ones by a setting |
| 02:00 |
| 02:03:36 | | Quit Acky (Connection timed out) |
| 02:04:15 | | Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-090-140.ewe-ip-backbone.de) |
| 02:09:24 | | Quit tyfoo (Read error: 145 (Connection timed out)) |
| 02:10:25 | * | JdGordon is 99% sure he can now replicate the statusbar pixel-for-pixel in WPS syntax :) |
| 02:10:54 | JdGordon | including the options for graphical or text batt/vol display |
| 02:11:36 | Unhelpful | JdGordon: related to the "use bitmap strip for numeric" FS item at all? |
| 02:14:50 | | Quit davidbarry ("Leaving") |
| 02:15:14 | | Quit _lifeless (Remote closed the connection) |
| 02:17:19 | | Join _lifeless [0] (n=lifeless@90.151.41.226) |
| 02:26:01 | JdGordon | Unhelpful: yep.. that was the last thing needed (to get the small font) |
| 02:30:15 | kugel | JdGordon: is it smaller than sysfont? |
| 02:30:33 | * | kugel thought it was sysfont |
| 02:31:59 | JdGordon | yeah, its smaller |
| 02:32:10 | JdGordon | currently its hardcoded bmp |
| 02:35:01 | Unhelpful | then i definitely approve of making it a configurable, loadable bmp. :D |
| 02:35:47 | JdGordon | can you think of any chars you might want in this smaller font than :-% ? |
| 02:36:05 | JdGordon | ive got it limited to 7 chars which im hoping is enough |
| 02:36:51 | Unhelpful | 7 besides the digits 0-9? |
| 02:37:29 | JdGordon | yeah |
| 02:38:00 | JdGordon | I'm alloweming themers to add up to 7 chars they want to the end of the bmp strip, but if its just going to b those 3 i might just hardcode it |
| 02:39:08 | | Join CellKill [0] (n=CellKill@h226.206.255.206.cable.srcy.cablelynx.com) |
| 02:39:40 | kugel | JdGordon: you never know what language specific separators and stuff people might use |
| 02:39:49 | Unhelpful | i can't honestly imagine what else they would do with it, unless you give them a full font, and that's just multifont done badly :/ |
| 02:39:54 | | Part CellKill |
| 02:41:16 | JdGordon | yeah, this is poor mans multifont untill its done right |
| 02:41:34 | JdGordon | which is why I want to limit it to almost no chars other than numbers |
| 02:41:56 | Unhelpful | right, then it has a very clear, specific use, and people won't be tempted to do multifont on top of it. |
| 02:42:21 | Unhelpful | you might want to add / to your list of other chars, just to make it usable for very tiny track/totaltracks display |
| 02:42:40 | kugel | you think people would care less about multifont with that, i.e. delaying the introduction more? |
| 02:43:01 | kugel | btw: I've had a small look at a proper multifont, and I see a possibility |
| 02:43:07 | JdGordon | or the oposite could happen... that people really want multifont because of it |
| 02:43:17 | kugel | but I need to understand that lru thing more before |
| 02:43:33 | JdGordon | the only thing stopping multifont is the fontcache... |
| 02:44:06 | JdGordon | na, bugger that lru stuff... get a working fontcache first, then get it working with lru |
| 02:44:13 | JdGordon | although it shouldn be that hard |
| 02:44:16 | kugel | yea, the font cache is a lru (least recently used) buffer |
| 02:44:17 | *** | Saving seen data "./dancer.seen" |
| 02:44:51 | kugel | and that puts the most recently used glyphs into ram |
| 02:45:36 | kugel | I see no reason why that buffer couldn't hold glyphs of multiple fonts. and the struct already contains a pad-to-4byte-boundary member which could be used for the index |
| 02:46:11 | Unhelpful | i'd like to see more sensible tagging with multifont, ie, let users specify up to N fonts in WPS, which are numbered in order, rather than this business of fonts per-context. but, then, i imagine the primary use of multifont being to have more than one font in WPS, not a different font for menu, browser, wps, etc, etc. |
| 02:46:20 | kugel | JdGordon: I don't understand. the font cache is lru. so you need to have it working with that, otherwise it's not proper |
| 02:46:35 | kugel | the rejected multifont had a lru for each userfont |
| 02:46:51 | JdGordon | kugel: multifont has to deal with different sized proportiaonal fonts as well as square glyphs... |
| 02:47:01 | JdGordon | all in one buffer |
| 02:47:16 | JdGordon | and I mean getting it working first with a huge buffer (as a demo) before fixing it properly |
| 02:47:25 | kugel | well, the viewport contains the font number, and that's the same as the index in the lru struct |
| 02:48:03 | JdGordon | Unhelpful: yeah, I image if it ever happens fonts in the w will be like the current bmp tagging.loading |
| 02:48:06 | | Quit thegeek (Read error: 54 (Connection reset by peer)) |
| 02:48:18 | kugel | so if you have the font number from the viewport the glyph of the correct userfont will be used automatically |
| 02:48:53 | kugel | JdGordon: having it working in a huge buffer is basically what the old multifont did |
| 02:48:58 | Unhelpful | JdGordon: any opinion on our pictureflow discussion, by the way? |
| 02:49:41 | JdGordon | Unhelpful: no, i wasnt awake enough to follow it... im sure whatever you decide is fine :) |
| 02:50:12 | JdGordon | kugel: having a massive buffer (but a single one) which could then be changed to lru and much smaller is completyly different to the old patch |
| 02:50:32 | Unhelpful | fair enough. i'll give people until things slow down here to yell about it. reverts are always possible if people hate it. |
| 02:51:14 | kugel | well, inventing another buffer for temporary use sounds like a unneeded detour to me |
| 02:51:36 | kugel | why don't make it work with lru in the first place if that's the requirement to get it in? |
| 02:51:44 | kugel | s/don't/not/ |
| 02:52:01 | JdGordon | thats the way my brain works... get a demo/proof-of-concept working, then fix it |
| 02:52:12 | JdGordon | all this while its out of tree thouhg... |
| 02:52:40 | JdGordon | also, becuase if you have bugs you dont kow if its lru not working, or something else |
| 02:53:58 | | Quit Thundercloud (Remote closed the connection) |
| 02:55:41 | kugel | hm, that approach doesn't appeal me very much, but it's surely worth considering |
| 02:56:47 | kugel | Unhelpful: maybe you test it before making a decision if it's such a hard thing for you ;) |
| 02:57:40 | Unhelpful | how do you think i've kept my commit scores low so far? |
| 02:58:03 | kugel | hehe :) |
| 02:59:21 | | Join thegeek [0] (n=nnscript@85-89-4.72.3p.ntebredband.no) |
| 03:00 |
| 03:01:29 | | Quit faemir ("Leaving") |
| 03:03:36 | | Quit moos (Read error: 110 (Connection timed out)) |
| 03:04:59 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 03:15:14 | JdGordon | hmm... if the old number of chars drawn is more than the new number it doesnt clear the last one... |
| 03:15:23 | JdGordon | not sure how to fix that :( |
| 03:16:49 | Llorean | gevaerts: Video support on the same level as audio support doesn't really mean a significant visible change though. Other than playlist support, current video support is pretty transparent since you still just click on them. |
| 03:17:13 | Llorean | The impression I get is that for a major-version bump, it needs to be a change big enough that *everyone* sees it, like a new UI. |
| 03:17:16 | kugel | JdGordon: btw: that feature sounds like that what the sandisk of has for their radio screen |
| 03:17:30 | kugel | it's not configurable in their version of course |
| 03:17:31 | | Join keanu [0] (n=keanu@unaffiliated/keanu) |
| 03:17:34 | JdGordon | ? |
| 03:17:48 | * | keanu wonders who remembers me |
| 03:17:48 | keanu | lol |
| 03:17:50 | kugel | but the radio screen has huge, anti-aliased numbers which look more like bitmaps |
| 03:17:58 | kugel | keanu: I do! |
| 03:18:23 | | Quit Thundercloud (Remote closed the connection) |
| 03:18:30 | kugel | JdGordon: no, seriously, that would be a great addition for the radio screen too |
| 03:18:41 | keanu | hey kugel |
| 03:18:45 | keanu | was hoping you'd be on ;) |
| 03:18:51 | * | keanu has his new fuze in his hands |
| 03:18:54 | kugel | hehe :) |
| 03:19:00 | kugel | oh nice |
| 03:19:28 | kugel | that's great news |
| 03:19:46 | keanu | curious about how to get the (of course, incomplete) rockbox firmware on it though |
| 03:20:07 | Unhelpful | kugel: what about cleaning up the AA fonts patch? |
| 03:20:11 | kugel | well, it's all in svn :) |
| 03:20:21 | JdGordon | hmm.. seen as this is specifically for numbers.. should I add a "max chars" option and always right justify the drawn number? |
| 03:20:23 | keanu | yeah, but i can't find info on it :P |
| 03:20:30 | kugel | Unhelpful: cleanup is nice, but it's not blocking it |
| 03:20:33 | keanu | unless i'm looking in the wrong place |
| 03:20:45 | kugel | Unhelpful: just have a look at mpegplayer with a aa font |
| 03:21:02 | Unhelpful | is that really the only commit blocker for it? hm. :/ |
| 03:21:05 | * | kugel thinks there should be a proper howto in the wiki |
| 03:21:19 | keanu | there should be or there possibly already is? ;) |
| 03:21:20 | Unhelpful | kugel: write one! ;D |
| 03:21:31 | | Quit tyfoo2 ("Carpe diem") |
| 03:21:36 | kugel | Unhelpful: well, there was no real talk about it anyway, but sure, it has no chance with that bug |
| 03:21:57 | keanu | advcomp2019, you don't have to pm me :P |
| 03:22:06 | kugel | keanu: there's "some" information, but certainly not enough |
| 03:22:10 | Llorean | Unhelpful: Kugel described it as having many bad variable names (variables with the same name doing different things in different places, or different names for the same functino) |
| 03:22:24 | keanu | kugel, yeah |
| 03:22:26 | Llorean | I haven't looked at it, but I'd say cleanup *is* a blocker if it doesn't meet decent standards. |
| 03:22:58 | kugel | Llorean: well, it's basically having the same variable names as the existing font rendering code |
| 03:23:10 | Llorean | kugel: Unless getting Rockbox on the Fuze is drastically different than the other V2s, it looks like there's enough info in the wiki |
| 03:23:24 | Llorean | kugel: So the current code has this problem already? |
| 03:23:32 | kugel | anyway, I'd surely volunteer for the cleanup, but that mpegplayer bug is still a bit over my head |
| 03:24:06 | Unhelpful | i haven't looked at the rockbox end of it. i'd like convttf, or whatever the util was, take the actual output line height on the command line. i think that's doable, since it seems to be a matter of what to do with some values that come from freetype |
| 03:24:38 | kugel | Llorean: it's basically like that: I'm not able to fix the mpegplayer bug, because I cannot really compare the old font code and the aaf one because I understand *neither* of both |
| 03:24:40 | keanu | Llorean, Didn't notice that it was in the SansaV2 article - I was looking in the SansaFuze article for the bootloader install section |
| 03:25:08 | kugel | but there's definitely some more or less obvious similiarities |
| 03:25:39 | keanu | yeah |
| 03:26:31 | keanu | kinda sucks though - I can't find my IEMs, so I'm stuck with the packaged earbuds |
| 03:26:34 | keanu | they hurt my ears |
| 03:26:38 | * | keanu slightly going off topic |
| 03:26:49 | Llorean | keanu: Please, don't. |
| 03:26:59 | * | kugel points to #rockbox-community |
| 03:27:11 | keanu | oh yeah :P |
| 03:27:28 | keanu | sorry about that Llorean - been a long time since I've been in here |
| 03:30:44 | kugel | keanu: I'm adding a little disclaimer+guide combo on the SansaV2 page |
| 03:30:52 | keanu | k |
| 03:30:57 | kugel | I'm tired myself of repeating that again and again ;) |
| 03:36:17 | | Join sarixe [0] (n=sarixe@ool-43540968.dyn.optonline.net) |
| 03:50:26 | | Join ameyer [0] (n=ameyer17@adsl-75-57-190-24.dsl.emhril.sbcglobal.net) |
| 03:53:14 | | Quit DerDome (Nick collision from services.) |
| 03:53:17 | | Join DerDome1 [0] (n=DerDome@dslb-082-083-201-130.pools.arcor-ip.net) |
| 03:53:29 | | Nick DerDome1 is now known as DerDome (n=DerDome@dslb-082-083-201-130.pools.arcor-ip.net) |
| 04:00 |
| 04:06:46 | | Join manx``` [0] (n=M@user-160uasn.cable.mindspring.com) |
| 04:08:28 | JdGordon | Llorean: (re user defineable extra chars in the patch) yes and no... you and i might agree that -:/ are the only ones worth using, but someone might have different ideas... the extra code to make it customizable is definetly worth it |
| 04:08:55 | | Quit QUICKSTART (Remote closed the connection) |
| 04:10:06 | Llorean | JdGordon: I'm not sure I agree. What other numeric tags use other characters? |
| 04:10:17 | JdGordon | I dont know |
| 04:11:26 | JdGordon | I will concede that having the extra chars at the end makes the wps line longer than needed |
| 04:11:37 | JdGordon | but still, you dont edit it very often |
| 04:12:17 | Llorean | How do you even use the extra characters if you're just associating as trip with a WPS tag? |
| 04:12:37 | * | wpyh didn't find a way to automatically boot into the ipod OF when usb is plugged in :( |
| 04:13:27 | | Quit agaffney (Read error: 54 (Connection reset by peer)) |
| 04:13:28 | JdGordon | Llorean: ? |
| 04:13:47 | | Join agaffney [0] (n=agaffney@gentoo/developer/agaffney) |
| 04:14:06 | Llorean | JdGordon: how do you use the custom characters, I thought you just followed your tag with a numeric tag? |
| 04:14:21 | JdGordon | I changed it so it always uses the string that the tags generate |
| 04:14:54 | Llorean | Ah |
| 04:15:00 | JdGordon | doing %xn|...|cH%xn|...|:%xn|...|cM will get you a ncie looking clock |
| 04:15:16 | Llorean | I dunno, seems a little dubious having custom characters. |
| 04:15:21 | Llorean | Why not just do multifont at that point? |
| 04:15:39 | JdGordon | well yeah, no question multifont is better.. this is a stand in untill that happens |
| 04:16:14 | JdGordon | thats also why I've limited it to so few chars |
| 04:18:31 | | Join bslote [0] (n=bslote@ip70-162-0-207.ph.ph.cox.net) |
| 04:22:30 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ef7b2a90c26df463) |
| 04:23:58 | Llorean | JdGordon: I think using it for numeric tags *probably* makes sense even with multifont |
| 04:24:22 | Llorean | Since you can make them colored and look more a part of the UI. |
| 04:24:33 | Llorean | but I think whatever it ends up being should be something we want alongside multifont. |
| 04:27:51 | | Part manx``` ("Leaving") |
| 04:30:05 | Unhelpful | getting aa-fonts would also nix the "the-bitmap-can-be-prettier-than-a-font" argument for doing it with a bitmap strip |
| 04:30:34 | kugel | multicolor chars!! |
| 04:31:35 | Unhelpful | ...is that the only reason that would be left if we had aa+multi? i can't say it's compelling. |
| 04:32:56 | kugel | it was a joke.. |
| 04:33:27 | | Quit bslote (Nick collision from services.) |
| 04:33:42 | Unhelpful | kugel: i knew, actually. or suspected, anyway |
| 04:34:27 | | Join bslote [0] (n=bslote@on-campus-114-215.vpn.arizona.edu) |
| 04:36:36 | Unhelpful | reading your patch, i'd say the album title config should definitely go in. i'm still leaning toward changing the meaning of the center margin setting, rather than the default. and i'm not sure if the resize should use the core scaler or not... |
| 04:38:36 | Unhelpful | putting in *either* resizer will make things a bit messy for a later merge of the greylib pictureflow, but not impossible |
| 04:40:21 | kugel | Unhelpful: well, I just fixed the resizing so that it at least resizes |
| 04:40:48 | | Quit Schmogel (Read error: 110 (Connection timed out)) |
| 04:40:50 | kugel | Unhelpful: if the core resizer is going to be used, I don't break the possibility |
| 04:41:30 | kugel | I don't intend to decide pro smooth_scaling, just make it resizing for now (until you commit your patch and remove it again ;) ) |
| 04:41:59 | | Join gromit` [0] (n=gromit@ALagny-154-1-60-179.w81-249.abo.wanadoo.fr) |
| 04:42:37 | Unhelpful | right, it looks like it amounts to putting an option in the config for resize, and passing that to create_bmp, rather than always false... plus whatever fixups you have in create_bmp |
| 04:43:26 | Unhelpful | ideally, i'd like to see the "core" scaler available in pluginlib if it's not built in core, preferably in a way that's fairly friendly to using either easily |
| 04:43:27 | kugel | I didn't change much there, just get it working (and only resize if it's needed), the diff looks messier than it is |
| 04:44:18 | *** | Saving seen data "./dancer.seen" |
| 04:45:41 | kugel | Unhelpful: don't take things as set in stone after committing the patch (if you commit it) |
| 04:45:52 | Unhelpful | it looks that way. i'm inclined to commit yours, simply because it's configurable, then sync mine against it and make sure the config still works. |
| 04:46:32 | kugel | sounds good :) |
| 04:47:55 | Unhelpful | i'd *like* to put in a working greylib pictureflow, but i'm still not sure about the 1KB binsize gain on greyscale targets - mainly a "is it worth it to have the HQ scaler in core for them" issue |
| 04:48:28 | | Join Marrrrrrk [0] (n=psycopat@cpe-75-186-75-27.cinci.res.rr.com) |
| 04:48:34 | kugel | how's that related? |
| 04:49:19 | bslote | I'm interested in contributing to the SansaV2 port; who do I need talk to to get the AMS datasheet? |
| 04:49:27 | Unhelpful | well, it's semi-related. greylib picture flow depends on pluggable scaler output + HQ core scaler on greyscale targets. |
| 04:49:32 | | Join Darksair [0] (n=user@58.192.32.35) |
| 04:49:54 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
| 04:49:56 | Unhelpful | *or* on a not-yet-coded implementation of pluggable scalers + HQ pluginlib scaler |
| 04:49:58 | kugel | bslote: Bagder is your man |
| 04:50:33 | kugel | the pluginlib scaler is pretty HQ imho |
| 04:50:37 | JdGordon | Llorean: I'm not sure I agree... multifont should be able to do this alot better without any problems |
| 04:50:46 | kugel | for color targets that is ;) |
| 04:51:40 | Unhelpful | kugel: and there's the issue, loaders are only 2bit on greyscale targets |
| 04:51:44 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
| 04:51:51 | kugel | Unhelpful: how much does the ram increase? /me thinks that number is a bit more important |
| 04:52:31 | Unhelpful | i believe only the binary size actually increases... but the core binary code is *always* in RAM, is it not? |
| 04:52:42 | kugel | yea |
| 04:52:58 | kugel | ram increase is always binsize increase+more |
| 04:54:04 | * | kugel still doesn't quite get why only the HQ one is working for greylib |
| 04:54:48 | Unhelpful | because there's little point doing nearest-neighbor scaling, with only 2bpp output, to use it in greylib |
| 04:55:50 | | Quit Marrrrrrk () |
| 04:56:11 | | Quit soap (Remote closed the connection) |
| 04:56:13 | kugel | I suggest doing a proof-of-concept preview |
| 04:56:48 | Llorean | JdGordon: Multifont can't do multicolor or shaded fonts. |
| 04:56:49 | kugel | I think we can discuss on the increase better if we see what it's bringing |
| 04:57:11 | Llorean | JdGordon: Bitmapped numbers can be made in the same style as bitmapped icons |
| 04:58:07 | Unhelpful | kugel: it's done. it looks great in pictureflow, at least on sim. the improvement isn't going to be as nice for core album-art, because it's still 2bpp output... but maybe some test images would help. |
| 04:59:30 | | Join gromit`` [0] (n=gromit@ALagny-154-1-6-200.w83-112.abo.wanadoo.fr) |
| 05:00 |
| 05:02:27 | | Quit gromit` (Connection timed out) |
| 05:03:40 | kugel | Unhelpful: I'm looking forward to pictureflow on my (soon to be arrived) clip :D |
| 05:03:57 | Unhelpful | um... that's mono, isn't it? |
| 05:04:10 | kugel | isn't greylib for mono too? |
| 05:05:31 | Unhelpful | yes, but mono targets don't build *any* scaling support at present. it's not even remotely difficult to fix, it would just be a matter of changing the conditions for building the scalers, and pictureflow, so that they're not based on mono-vs-nonmono |
| 05:06:01 | Unhelpful | omit them for the more lowmem mono targets, include for others, basically |
| 05:06:13 | kugel | clip is lowmem :( |
| 05:07:00 | Unhelpful | *how* lowmem are we talking? can you reasonably use albumart on it? |
| 05:07:16 | kugel | I have no idea :P |
| 05:07:40 | kugel | depends on what the watermark remake yields I suppose |
| 05:08:11 | Unhelpful | could always make the scaler build based on having AA instead of having color-or-greyscale |
| 05:10:59 | kugel | hm no |
| 05:11:23 | Unhelpful | right now, PF only works for albumart, anyway. and while it's certainly *possible* to provide the scaler in pluginlib for targets where it can't be justified in core, i have to wonder if pictureflow on such a target can fit in the plugin buffer with the scaler linked into the plugin |
| 05:11:24 | JdGordon | Llorean: hmm, yeah, but once we have mutlifont, its not such a big ump to 24bit colour fonts |
| 05:12:18 | kugel | Unhelpful: yea, maybe I should not be looking forward too hard :( |
| 05:13:44 | Unhelpful | what happens if you "just" enable AA on clip? |
| 05:14:34 | kugel | no idea :P |
| 05:14:38 | | Join Soap [50] (n=Soap@rockbox/staff/soap) |
| 05:14:54 | kugel | the clip didn't arrive yet (hence I said "soon to be arrived") |
| 05:15:46 | Unhelpful | hrm, right, you could see if it would build, but there's not much to do about deciding if it can work. |
| 05:15:46 | keanu | kugel, fresh compile with only buttonwheel_almost_working-kugel.patch added causes keymaps to still not work |
| 05:15:48 | | Quit DerDome (Read error: 110 (Connection timed out)) |
| 05:15:51 | keanu | unless i'm breaking something : |
| 05:15:54 | keanu | :P* |
| 05:16:24 | Unhelpful | it looks like the binsize goes up 876B on ipod4g, vs svn. |
| 05:18:15 | kugel | keanu: I have no idea, I'll have a look later |
| 05:19:00 | keanu | kugel, is it possible it's because i have rockbox on the internal memory vs a mSD card? |
| 05:19:00 | * | keanu seems to remember seeing in the thread that people were booting rockbox from an mSD card |
| 05:19:19 | kugel | no, I don't think so |
| 05:19:32 | keanu | weird |
| 05:19:49 | keanu | ok, new question |
| 05:20:13 | keanu | is it possible it's because i compiled the bootloader before adding the button support? |
| 05:20:45 | kugel | no, shouldn't make any difference |
| 05:20:51 | keanu | k |
| 05:20:56 | * | keanu compiles a new bootloader anyway |
| 05:21:03 | keanu | ...or not |
| 05:21:08 | keanu | compile error |
| 05:21:24 | keanu | (hold_button undeclared) |
| 05:21:45 | keanu | http://pastebin.com/m7ca5dfc9 |
| 05:22:21 | kugel | yea, possible |
| 05:22:32 | kugel | I was too lazy to add proper #ifdefs |
| 05:22:44 | kugel | I didn't build a bootloader with it |
| 05:22:50 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 05:23:07 | | Quit bmbl (Remote closed the connection) |
| 05:23:37 | keanu | lol |
| 05:23:48 | * | keanu removes rockbox for now |
| 05:26:47 | kugel | keanu: :( |
| 05:26:55 | Unhelpful | kugel: bah, i forgot to save the actual rockbox-info.txt from both builds. binsize delta is +896B for HQ scaler and pluggable scaler output on ipod4g, and there's no additional RAM used, except for whatever is allocated from the audio or plugin buffer while loading bitmaps |
| 05:27:27 | keanu | kugel, i'll reinstall it later (probably tomorrow |
| 05:27:54 | keanu | i just want to play music :P |
| 05:28:36 | kugel | keanu: maybe the patch lucent uploaded is flawed. I didn |
| 05:28:49 | kugel | didn't make the patch, he just created it from my pastebin |
| 05:28:53 | keanu | ah |
| 05:29:02 | keanu | could be |
| 05:29:52 | * | kugel still needs to find a way to generates irqs from the wheel, then it'll be perfect |
| 05:30:06 | Unhelpful | i thought you had that, sort of? |
| 05:30:28 | | Quit Soap ("Leaving") |
| 05:32:50 | kugel | nah, it's not working |
| 05:36:42 | keanu | later kugel |
| 05:36:46 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.5/2008121622]") |
| 05:38:43 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
| 05:50:06 | Unhelpful | some comparison covers: http://unhelpful.cleansoap.org/cover-01-lq.png http://unhelpful.cleansoap.org/cover-01-hq.png http://unhelpful.cleansoap.org/cover-02-lq.png http://unhelpful.cleansoap.org/cover-02-hq.png http://unhelpful.cleansoap.org/cover-03-lq.png http://unhelpful.cleansoap.org/cover-03-hq.png http://unhelpful.cleansoap.org/cover-04-lq.png http://unhelpful.cleansoap.org/cover-04-hq.png |
| 05:50:22 | | Join axionix [0] (n=axion@cpe-67-242-94-6.nycap.res.rr.com) |
| 05:50:40 | Unhelpful | the -hq versions are all with the area/linear scalers ported from the color targets, the -lq are with the nearest-neighbor scaler current in svn for greyscale targets |
| 05:52:13 | Unhelpful | the -lq looks a bit brighter and more detailed in some cases, but you can also see, in #03 especially, that the same aliasing that causes the appearance of increased detail can also lose detail - one of the whiskers is broken |
| 05:52:26 | | Quit bslote (Read error: 110 (Connection timed out)) |
| 05:53:49 | | Join iswm [0] (n=bslote@ip70-162-0-207.ph.ph.cox.net) |
| 05:54:11 | | Nick iswm is now known as bslote (n=bslote@ip70-162-0-207.ph.ph.cox.net) |
| 05:54:49 | Unhelpful | aside from the changes in quality and binsize, i also consider the HQ scaler more maintainable. by trying to do fewer things at once, because of the separation of vertical vs horizontal and up vs down scaling, it's quite a bit easier to follow, and there's also the maintenance benefit of much of the code being shared with color targets |
| 05:55:57 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 06:00 |
| 06:00:16 | | Join GodEater [0] (i=765a2226@gateway/web/ajax/mibbit.com/x-8c1b91804cebe91c) |
| 06:05:29 | | Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) |
| 06:06:30 | | Quit amiconn (Nick collision from services.) |
| 06:06:32 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 06:07:40 | | Quit pixelma (Read error: 110 (Connection timed out)) |
| 06:14:08 | | Quit HellDragon (Connection reset by peer) |
| 06:14:26 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
| 06:17:43 | | Quit GodEater ("http://www.mibbit.com ajax IRC Client") |
| 06:44:21 | *** | Saving seen data "./dancer.seen" |
| 06:49:15 | | Quit Darksair ("Emacs = ESC-Meta-Alt-Ctrl-Shift") |
| 07:00 |
| 07:00:41 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 07:28:36 | | Join lucent [0] (i=lucent@66.111.62.170) |
| 07:29:03 | Unhelpful | i don't quite follow the comment in plugin.h about sorting in any new functions "waiting" at the end of the table... are we supposed to be sorted by function name, except for newly-added ones? |
| 07:29:39 | * | lucent observes "people are online and it's christmas holiday time... interesting." |
| 07:30:15 | lucent | Unhelpful: API compatibility? |
| 07:30:18 | lucent | or unrelated |
| 07:31:25 | lucent | struct { a; b; c; }; is compatible to previous struct { a; b; }; |
| 07:31:35 | Unhelpful | lucent: well, the comment is above PLUGIN_MIN_API_VERSION, which is to be incremented whenever compatibility is broken... so i *think* it's meant to say that while that's being done, why not sort things? |
| 07:31:56 | lucent | ha, yeah okay, that might make sense to me |
| 07:32:07 | lucent | I'm not writing those words so I don't know what to suggest |
| 07:32:29 | | Quit Rob2223 (Read error: 104 (Connection reset by peer)) |
| 07:33:00 | Unhelpful | sorting the struct seems potentially error-prone to me, as it's declared in one file, and populated with actual rockbox core functions in another... |
| 07:33:30 | | Join Rob2222 [0] (n=Miranda@p4FDCDBE4.dip.t-dialin.net) |
| 07:34:52 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 07:35:38 | JdGordon | Unhelpful: what your supposed to do is fix plugin.c and plugin.h at te same time if you change the api in a way which would break compatibility |
| 07:35:52 | | Join Rob2222 [0] (n=Miranda@p4FDCDBE4.dip.t-dialin.net) |
| 07:35:54 | JdGordon | otherwise, just add your function at the end and bump the min api version |
| 07:36:03 | JdGordon | sorry, current, not min |
| 07:37:13 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 07:37:15 | Unhelpful | "fix" as in sort any new funcs added at the end since the last compatibility break? |
| 07:38:34 | Unhelpful | i would assume by function name...? |
| 07:39:05 | lucent | Unhelpful: I think we've established the intent of that comment |
| 07:39:24 | lucent | if you're alright with it, let it rest... is there a more specific issue you would like to resolve today? |
| 07:39:52 | | Join peter_ [0] (n=chatzill@66.60.188.6) |
| 07:40:24 | peter_ | Hi, I was curious as to the state of ipod nano 4th gen ports. |
| 07:40:24 | JdGordon | Unhelpful: yes.. but they are sorted by their "function"... LCD funcs together, misc together, database together, etc |
| 07:40:36 | JdGordon | peter_: you mean the lack thereof |
| 07:40:45 | Unhelpful | well, actually, i was prepping to commit an API-breaking change, and wanted to make sure i was doing the right thing there. it looks like nobody's added anything that needs to be sorted recently. |
| 07:40:46 | peter_ | Is it a totally futile exercise to attempt? |
| 07:40:54 | lucent | it's not futile |
| 07:41:00 | peter_ | Just not done? |
| 07:41:06 | Unhelpful | which didn't show in my diff, since there's nothing changed near the end of the struct |
| 07:41:06 | lucent | nobody I know of has the knowledge and the time and the motivation to try |
| 07:41:12 | Unhelpful | not being worked on right now |
| 07:41:14 | peter_ | Ah |
| 07:41:32 | peter_ | So Apple did something to prevent things like installing rockbox on them. |
| 07:41:34 | lucent | new rockbox ports are done by persons who have the knowledge, time, and motivation to do it themselves |
| 07:41:43 | lucent | there's also that |
| 07:41:49 | peter_ | Bastiches |
| 07:42:04 | lucent | which a lot of developers take as an insult, I gather |
| 07:42:22 | peter_ | I'm assuming that trying to install the nano 1 gen rockbox on a 4th gen results in a lack of core cunctionality. ;) |
| 07:42:30 | JdGordon | Unhelpful: the same is supposed to apply to global_settings struct in settings.h but that comment "add new stuff below here and sort later" is half way up :/ |
| 07:42:31 | peter_ | functionality, even |
| 07:42:46 | JdGordon | it wont work |
| 07:42:50 | JdGordon | it wont let you install it |
| 07:42:58 | lucent | peter_: if you want a vendor to dance around and pee on the fire with, SanDisk offers a quality product with their Clip and Fuze players, there's a possibility that those players will receive rockbox support |
| 07:43:11 | peter_ | Cool. |
| 07:43:15 | peter_ | Thanks much. |
| 07:43:18 | lucent | that's straying off-topic for this chan though :) |
| 07:43:36 | Lss | yes i tried the clip and fuze they are really very good |
| 07:43:40 | lucent | #rockbox-community for all other non-supported user inquiries, and have a warm / safe holiday! |
| 07:43:52 | peter_ | You as well, thanks. |
| 07:43:53 | Lss | if you upgrade the stock buds its a pretty killer portable setup |
| 07:44:02 | | Quit peter_ (Client Quit) |
| 07:45:33 | lucent | Lss: which models do you own? |
| 07:46:00 | Lss | i tested them at an audio store i frequent |
| 07:46:02 | Lss | both of the |
| 07:46:03 | Lss | them |
| 07:46:06 | lucent | ah |
| 07:46:14 | Lss | nice place to hang out you get to try loads of things |
| 07:46:20 | lucent | I'm rounding up a list of developers who own Fuze / Clip hardware |
| 07:46:20 | Lss | even had a chance to use the kenwood |
| 07:46:24 | Lss | THE kenwood |
| 07:46:33 | * | lucent looks vacant |
| 07:46:45 | lucent | audiophile crap? |
| 07:46:49 | Lss | if you ask me its cheap enough to buy |
| 07:46:53 | Lss | yup |
| 07:46:58 | Lss | let me find a link |
| 07:48:04 | Lss | http://bluetin.com/catalog/kenwood-media-keg-hd60gd9ec-limited-gold-edition-60gb-hdd-media.html < found it |
| 07:48:18 | ameyer | heh, media keg |
| 07:48:19 | | Join Rob2222 [0] (n=Miranda@p4FDCDBE4.dip.t-dialin.net) |
| 07:48:44 | lucent | uh |
| 07:48:48 | Unhelpful | this definitely belongs in -community |
| 07:48:58 | ameyer | yes, yes it does |
| 07:49:10 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 07:49:16 | lucent | Lss: oh well about the Clip / Fuze |
| 07:49:19 | Lss | oh ok oops |
| 07:49:24 | lucent | if you pick one up let someone know |
| 07:49:33 | Lss | sure |
| 07:50:12 | lucent | I have my hopes up for fdinel and kugel to work their coding voodoo and improve things in the next 1-2 months |
| 07:50:31 | lucent | would be sure nice to have a stable and commercially produced target in rockbox again |
| 07:50:36 | lucent | Lss: are you a coder? |
| 07:51:22 | Lss | not really im a mechanical eng student haha |
| 07:51:38 | Lss | the only language im remotely good at is python |
| 07:57:48 | lucent | Python is a good language for corporations |
| 07:57:55 | lucent | I'm not a fan of meaningful whitespace |
| 07:57:58 | | Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 07:59:32 | | Quit Xerion (Read error: 60 (Operation timed out)) |
| 07:59:32 | | Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) |
| 07:59:41 | lucent | Lss: so far I've heard reports on 1GB,2GB Clip, 4GB,8GB Fuze |
| 08:00 |
| 08:00:25 | lucent | other AMS Sansa units are interesting to get feedback on, but especially the Fuze and Clip since those are the commercially successful units |
| 08:00:35 | Lss | only reason why i picked up python was because the fedora installer was coded with it |
| 08:00:51 | Lss | it was helpful when i later found out i could use it in blender and gimp if i wanted to |
| 08:03:15 | saratoga | this is an on topic channel |
| 08:04:16 | | Join Rob2222 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 08:08:29 | | Quit saratoga ("CGI:IRC (EOF)") |
| 08:18:38 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 08:35:40 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 08:37:02 | amiconn | Unhelpful: The main binary is in ram by default on all currently existing targets as far as default installations and the delta calculations are involved, but it's not always there. |
| 08:38:02 | Unhelpful | flash and execute-in-place is the exception i'm imagining? |
| 08:38:05 | amiconn | On several targets where rockbox can be flashed there is an option to run rockbox directly from ROM (currently Archos Player, Ondio SP, and iriver H1x0) |
| 08:38:46 | amiconn | Originally all archoses were capable of running rombox, but for the others rockbox became too large to fit in there |
| 08:40:13 | Unhelpful | and i've probably made things fit a bit tighter now. i'm rather surprised by how much one more argument cost on the mono targets, though... but i didn't want the read_bmp_* argument list to vary across platforms :/ |
| 08:41:36 | amiconn | A single extra argument usually doesn't cost much. On SH the exception is when you cross the "magic" limit of 4 (max. 32 bit) arguments |
| 08:42:07 | amiconn | Then gcc switches to using stackparms (up to 4 SH uses regparms) |
| 08:43:08 | Unhelpful | and passing the format plugin bumped us to 5 in read_bmp_* :/ |
| 08:44:23 | *** | Saving seen data "./dancer.seen" |
| 08:44:27 | amiconn | Hmm, for that, the increase is quite small |
| 08:44:59 | * | amiconn remembers when Slasheri added something to tagcache that bumped one function's number of parameters to 5 |
| 08:45:15 | amiconn | That caused +700 bytes on archos :\ |
| 08:45:42 | Unhelpful | i almost wonder if having the greylib plugin, which doesn't even build on mono, in core would cost less than adding the parameter. probably only on the SH targets, i would think. |
| 08:46:22 | amiconn | ? |
| 08:47:19 | Unhelpful | if the greylib output_row function were in core, it could be selected via format, without the extra argument for the plugin pointer. which would save the tiny increase on SH, but probably increase everywhere else. |
| 08:47:26 | amiconn | The greylib does build on mono - that's where it even originated |
| 08:47:46 | Unhelpful | but at present, the scaler, and output functions for it, do not |
| 08:48:11 | amiconn | It's just that currently pictureflow doesn't build on mono, because it depends on HAVE_ALBUMART |
| 08:48:57 | | Join Rob2222 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 08:49:07 | Unhelpful | i'm also not entirely sure it could be made to work on mono. if the scaler is built in pluginlib for that, it would eat a good chunk of the plugin buffer. |
| 08:49:48 | amiconn | (1) depends on what a good chunk is. There are (is) also a large-mem mono target |
| 08:50:09 | Unhelpful | i suppose i should close the related FS tasks for the committed scaler work... as "accepted"? |
| 08:50:17 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 08:50:44 | amiconn | (2) There's always the possibility to get extra ram for data when stopping playback. On archos, some plugins which are too large for the plugin buffer even use that extra ram for code, by using the "overlay" loader |
| 08:51:11 | amiconn | (iirc rockboy, chessbox and zxbox atm) |
| 08:52:27 | Unhelpful | re (1), i'd talked to kugel about that earlier - the scaler might be worth making conditional on something other than mono. if there's memory, dithered AA might very well be tolerable on mono, and greylib may be nice as well |
| 08:52:49 | Unhelpful | or, if the dithered mono is really too awful for words, scaling in pluginlib |
| 08:53:47 | amiconn | I wonder what the cost (for plugins) would be if the scaler is just always put in the pluginlib for greylib use |
| 08:54:41 | Unhelpful | the pluginlib is linked static, isn't it? i'm fairly sure any functions or structures from it that aren't referenced by the plugin code are discarded. |
| 08:55:23 | amiconn | I don't know - does pictureflow need special support from the core to work (e.g. special fields that aren't present when compiling without AA)? |
| 08:56:10 | amiconn | Unhelpful: Yes, it's static, compiled with -ffunction-sections -fdata-sections, and plugins are linked with garbage collection, i.e. all unused sections are dropped |
| 08:56:49 | Unhelpful | right now, pictureflow doesn't work at all without AA |
| 08:57:48 | amiconn | I know that it doesn't work atm - I would like to know if it could be made to work without extensive support in the core |
| 08:59:22 | Unhelpful | you'd need to either duplicate read_bmp_* in pluginlib, with scaler support, or add a pointer argument to them to pass them a scaler from pluginlib, if there's no scaler in core. |
| 08:59:59 | Unhelpful | there may be other ways, that's all i've thought of so far. the former would obviously have the least impact on core |
| 09:00 |
| 09:00:00 | amiconn | I'm more concerned about the database access involved in AA... |
| 09:00:54 | Unhelpful | now *that* i don't know about. i *think* you could port the search-for-AA-files into pluginlib without major changes, but i've only barely looked at it. |
| 09:02:34 | amiconn | Well, if it is possible, it might be worth making the bmp loader and scaler code shareable between core and plugins, so that mono targets can have a loader with smooth resizing and greylib support in plugins without affecting the core's binsize |
| 09:03:15 | | Join Rob2222 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 09:03:58 | * | amiconn is curious about the scaler's speed on a slow CPU |
| 09:06:17 | Unhelpful | unfortunately, targets i own are all PP. it's very clearly slower on the e200 than the S60, but it's fairly fast for reasonably sized input on both. |
| 09:06:24 | | Quit Rob2222 (Read error: 104 (Connection reset by peer)) |
| 09:06:42 | JdGordon | there is no real reason pictureflow cant be made to scan the hard disk looking for files which could be AA.. but then track listings get difficult |
| 09:06:56 | * | amiconn is trying to understand the clever dither matrix trick |
| 09:09:46 | Unhelpful | amiconn: it's based on how the bayer dither matrix is generated. each two bits of it come from one bit of the x and y coordinates. i worked out how to calculate and combine the two components, but then i realize that the Y component and the X component are the same, except that they X component sets both bits of each 2-bit pair, and the Y component only sets the higher bit. |
| 09:10:32 | Unhelpful | but multiplying the table value to get either component seemed very likely to be less cheap than setting both bits, and masking out the unwanted ones for Y |
| 09:10:47 | | Join Rob2222 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 09:12:59 | Unhelpful | the 3*N ^ 2*N pattern i figured out via trial-and-error by examining the 2x2 matrix, then tested to make sure it applied to the larger one |
| 09:15:10 | amiconn | So you (effectively) replaced a shift->add->lookup sequence by 2*lookup->and->xor, and saved 240 bytes of the table this way. And if y is pre-dithered for each row, it's even faster |
| 09:16:19 | Unhelpful | i assume it would be faster, i haven't actually tested that, though. |
| 09:16:36 | * | amiconn also just assumed that |
| 09:17:18 | amiconn | In reality it depends on the stupidity^wcleverness of gcc |
| 09:18:14 | | Join stoffel_ [0] (n=sfr@p57B4FBB7.dip.t-dialin.net) |
| 09:18:45 | Unhelpful | indeed, it could move the Y offset into the dither matrix out of the loop when compiling the large-table version, so that the shift is only done per-row, and then just the add and lookup per pixel |
| 09:19:38 | | Join Rob2223 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 09:20:17 | Unhelpful | i'd expect an add to be at best as fast as a bitwise logic op |
| 09:21:00 | amiconn | You said that dithered mono output wouldn't look too bad - did you try it? |
| 09:21:34 | amiconn | The m:robe 100 is the only (afair) large-mem mono target - perhaps it'd make sense to have it support AA? |
| 09:21:48 | | Join Buschel [0] (n=abc@p54A3C9F3.dip.t-dialin.net) |
| 09:22:34 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 09:22:48 | Buschel | hi folks, even the daily build from december, 24th, stops playback after 1h 15min... |
| 09:23:22 | Buschel | nobody has this issue? one special thing I do is to leave the WPS and stay in the menu for runtime tests |
| 09:23:59 | Buschel | I will try a run with active WPS now... |
| 09:24:09 | Unhelpful | i said *might* not. i suspect the void-and-cluster dither would show a larger advantage over bayer in that case than it does on 2bpp. i could try both on an m:robe sim.... it would be a good excuse to stay away from jpeg. |
| 09:25:46 | Unhelpful | or perhaps easier to just dither a few images down to b/w to test, rather than go through all that implementation to find out that it's bad |
| 09:27:03 | | Quit JdGordon (Remote closed the connection) |
| 09:31:19 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:35:17 | | Join Rob2222 [0] (n=Miranda@p4FDCE2FB.dip.t-dialin.net) |
| 09:39:30 | | Quit Rob2223 (Read error: 104 (Connection reset by peer)) |
| 09:42:18 | | Quit stoffel_ ("leaving") |
| 09:51:28 | | Join gromit` [0] (n=gromit@ALagny-154-1-69-18.w86-203.abo.wanadoo.fr) |
| 09:51:52 | | Join daurnimator [0] (n=quae@unaffiliated/daurnimator) |
| 09:55:53 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 09:57:28 | | Quit thegeek (Read error: 110 (Connection timed out)) |
| 10:00 |
| 10:03:10 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 10:04:35 | | Quit jhMikeS (Nick collision from services.) |
| 10:04:41 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 10:25:32 | | Join fanta2 [0] (n=fanta2@CPE-121-210-232-191.qld.bigpond.net.au) |
| 10:25:50 | | Quit BHSPitLappy (Remote closed the connection) |
| 10:26:53 | | Quit fanta2 (Client Quit) |
| 10:27:27 | | Join fanta2 [0] (n=fanta2@CPE-121-210-232-191.qld.bigpond.net.au) |
| 10:28:09 | | Join fredddy [0] (n=freddy@p3E9E3BBD.dip0.t-ipconnect.de) |
| 10:30:39 | fanta2 | I've got a question about pointers that I can't work out: I've got a pointer to a character array, and I'm trying to turn the first four bytes into an unsigned int. This is what I'm using: uint32_t filesizeremaining = *((uint32_t*)buffer) - sizeof(struct ptp_container_header); |
| 10:31:14 | fanta2 | buffer contains 0x76F3, but no matter what I do filesizeremaining contains 12 (which happens to be the size of ptp_container_header) |
| 10:31:24 | fanta2 | any idea what I'm doing wrong? |
| 10:34:19 | Unhelpful | have you tried outputting the value of *((uint32_t*)buffer) to verify that that's working correctly? also, beware endianness issues - you should know what byte-order the file format uses and use one of the available functions to convert that to host byte-order |
| 10:35:58 | amiconn | You also need to be aware of alignment issues. Several architectures don't support reading integers unaligned. This applies to most rockbox targets (ARM, SH1). Coldfire supports it |
| 10:36:14 | fanta2 | yep, logf says it's 30451 which equals 0x76F3; and the input data is coming over USB so it should be little endian same as my sansa e200 |
| 10:37:37 | fanta2 | could it be an alignment issue? I thought it'd just throw an error if I tried accessing unalligned data; besides I'm using the audio buffer which seems to be aligned correctly for unsigned integers |
| 10:38:22 | amiconn | Wrong alignment would cause an exception (data abort on arm) |
| 10:38:43 | amiconn | But I think that you got the pointer math wrong |
| 10:39:26 | * | Buschel slaps his forehead |
| 10:39:30 | fanta2 | thought so, I had data abort issues too. I'm guessing my math's bad also, but I'm using the exact same code (*((uint32_t*)buffer)) to get the value through logf, and it works there |
| 10:39:46 | Buschel | ouch, it was the repeat-option which was set to off :/ |
| 10:39:59 | amiconn | Hmm, probably not |
| 10:40:30 | fanta2 | it might be worth noting that I'm using a fairly out of date SVN revision, but I don't think that'd be causing errors of this kind |
| 10:41:16 | | Join knigma [0] (n=d1c13008@gateway/web/cgi-irc/labb.contactor.se/x-6ec868e5ab5ecf42) |
| 10:42:47 | | Quit knigma (Client Quit) |
| 10:44:24 | *** | Saving seen data "./dancer.seen" |
| 10:45:40 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 10:45:51 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
| 10:48:50 | | Quit fanta2 () |
| 10:49:48 | | Quit sarixe ("Connection reset by the motherfucking peer") |
| 10:53:45 | n1s | Unhelpful: great work on the bmp scaling. Couldn't FB_DATA_SZ be defined as sizeof(fb_data) ? |
| 10:55:05 | Unhelpful | n1s: it could, but i don't think sizeof is valid in #if conditions, and there were cases where i thought that would be convenient... though i don't recall if i actually did *use* it that way at all. |
| 10:55:31 | n1s | aha |
| 10:56:51 | n1s | also you seem to have forgotten to commit test_greylib_bitmap_scale. |
| 10:56:55 | n1s | c |
| 10:57:31 | Unhelpful | hah. the same trouble that i had with the flyspray patch :/ |
| 10:58:56 | | Quit Buschel (Read error: 60 (Operation timed out)) |
| 10:59:04 | amiconn | sizeof() isn't available in the preprocessor |
| 11:00 |
| 11:00:07 | | Join Buschel [0] (n=abc@p54A3C9F3.dip.t-dialin.net) |
| 11:01:25 | | Join MethoS- [0] (n=clemens@host-091-096-212-070.ewe-ip-backbone.de) |
| 11:03:24 | n1s | amiconn: thanks |
| 11:04:29 | Unhelpful | amiconn: ran a test using both void-and-cluster and bayer dithering, with a 64x64 greyscale image as input, dithering down to 1-bit red-only. the results are pretty wretched all around, i can save some if you want to see. |
| 11:09:54 | * | amiconn had to google void-and-cluster dithering |
| 11:10:11 | amiconn | So far I only knew ordered dither and error diffusion (f-s) |
| 11:11:04 | amiconn | On a related matter, would it be difficult to make the smooth resize (for greylib) use different factors for X and Y, in order to account for non-square LCD pixels? |
| 11:13:59 | * | amiconn had an idea regarding PF on non-AA targets (and as an option on AA-enabled targets as well) |
| 11:14:11 | | Join gregzx [0] (n=chatzill@dsz251.neoplus.adsl.tpnet.pl) |
| 11:14:37 | amiconn | PF could be made to work without the database at all, just browsing folders like the rockbox core does if you're not using the db |
| 11:15:43 | amiconn | It would rule out the optional alternative places for AA bitmaps and require them to be stored along the albums themselves when using that method, but it should be fairly simple |
| 11:15:52 | Unhelpful | amiconn: it's just another way to generate an ordered dither matrix. it does a somewhat better job of avoiding obviously-visible patterns. |
| 11:16:51 | Unhelpful | i considered trying larger AA, but really, much larger than 64x64 on m:robe 100 and you've no room in your WPS for anything else. |
| 11:17:46 | Unhelpful | also, for different factors per dimension, we'd really just have to tweak recalc_dimension |
| 11:18:20 | Unhelpful | the scaler itself knows absolutely nothing about selecting output size, it just scales each dimension up or down as requested |
| 11:19:08 | | Join miepchen^schlaf [0] (n=miepel@p579EC951.dip.t-dialin.net) |
| 11:20:11 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 11:23:24 | | Quit tvelocity ("Αποχώρησε") |
| 11:25:58 | Unhelpful | n1s: just committed the missing plugin, thanks for the headsup. |
| 11:26:54 | n1s | Unhelpful: np, that sort of thing bites everyone from time to time :) |
| 11:30:19 | Unhelpful | i wasn't even thinking about the added file, or i would've patched my changes onto my svn repo for the commit - there seems to be no way at all to set svn keywords in git-svn |
| 11:37:18 | | Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 11:37:24 | | Quit linuxstb (Nick collision from services.) |
| 11:37:28 | | Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) |
| 11:37:37 | | Join {phoenix} [0] (n=dirk@p54B47E32.dip.t-dialin.net) |
| 11:46:42 | Unhelpful | amiconn: what about dropping the fifth parameter on the lowmem mono targets, and using a macro to hide the difference? something like FPLUGIN(p) that's defined empty on those targets? that would get back the small binsize gain without making the code too nasty to read/write. |
| 11:56:01 | | Quit MethoS- (Remote closed the connection) |
| 11:58:32 | | Join MethoS- [0] (n=clemens@host-091-096-212-070.ewe-ip-backbone.de) |
| 12:00 |
| 12:01:53 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
| 12:04:00 | | Quit {phoenix} (Remote closed the connection) |
| 12:04:11 | | Quit MethoS- (Remote closed the connection) |
| 12:07:13 | | Join {phoenix} [0] (n=dirk@p54B47E32.dip.t-dialin.net) |
| 12:11:03 | | Quit {phoenix} (Remote closed the connection) |
| 12:20:21 | | Join Darksair [0] (n=user@58.192.39.33) |
| 12:25:55 | | Quit gevaerts (Nick collision from services.) |
| 12:26:07 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 12:34:26 | | Quit Buschel (Read error: 54 (Connection reset by peer)) |
| 12:34:39 | | Join Buschel [0] (n=abc@p54A3C9F3.dip.t-dialin.net) |
| 12:44:28 | *** | Saving seen data "./dancer.seen" |
| 12:44:59 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 12:44:59 | | Quit FOAD (Read error: 54 (Connection reset by peer)) |
| 12:45:09 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 12:45:59 | | Quit lnf3ct (Remote closed the connection) |
| 13:00 |
| 13:09:37 | | Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) |
| 13:24:27 | | Quit AndyIL (Read error: 60 (Operation timed out)) |
| 13:24:40 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 13:25:09 | | Join pvagner_ [0] (n=Miranda@85.248.12.203) |
| 13:29:29 | | Join {phoenix} [0] (n=dirk@p54B47E32.dip.t-dialin.net) |
| 13:31:13 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-5e1a21e3ccc09ffc) |
| 13:36:02 | | Join hammetpb22 [0] (n=Miranda@110.243.broadband10.iol.cz) |
| 13:36:05 | | Quit Buschel (Read error: 60 (Operation timed out)) |
| 13:41:35 | gevaerts | Llorean: maybe it depends on habits. If you have lots of short videos (cartoons, ...) playlist integration is kind of important . If you add multi-codec support to that, I personally think it matches your visibility requirement |
| 13:42:10 | gevaerts | Also note that no 2.5 user saw big changes in 3.0 :) |
| 13:42:37 | | Join j-noise [0] (i=3d02c1b9@gateway/web/ajax/mibbit.com/x-a12754bad8bd7aac) |
| 13:46:23 | Llorean | gevaerts: I was the one arguing many who thought they were using 2.5 saw no big changes in 3.0. Even if the options expanded, the UI didn't significantly change for 2.5 users afaik. |
| 13:46:49 | hammetpb22 | Hello, anything new in porting rockbox to iriver E100? |
| 13:46:58 | Llorean | hammetpb22: Nobody is working on it. |
| 13:46:58 | gevaerts | Llorean: that's true too of course |
| 13:47:40 | hammetpb22 | So there is no chance that it will run rockbox in future. ? |
| 13:48:03 | Llorean | hammetpb22: I didn't say that. If nobody ever does work on it, there's no chance. Nothing prevents people from trying, just nobody wants to it seems. |
| 13:48:10 | | Part j-noise |
| 13:48:23 | | Join j-noise [0] (i=3d02c1b9@gateway/web/ajax/mibbit.com/x-a12754bad8bd7aac) |
| 13:48:41 | j-noise | hi all :D |
| 13:50:17 | Llorean | gevaerts: I just think supporting a new SoC (not just individual players, but either a new architecture or a new integrated SoC) is a leap, rather than an incremental change, and might be better served by an intentional version number jump of some sort, rather than the incremental ones you get with the timed releases. |
| 13:50:23 | gevaerts | Anyway, my main point is that the difference between HWCODEC and SWCODEC audio is about the same as between mpeg support and loadable video codec support from the user point of view, so the questions are (a) was the 2->3 because of SWCODEC a correct decision, and (b) is video support "core" enough to warrant the same treatment? |
| 13:50:26 | itcheg | is this entry in svn http://svn.rockbox.org/viewvc.cgi?view=rev;revision=18939 correlate with http://www.rockbox.org/tracker/task/5737 and if yes should it be closed? |
| 13:50:59 | | Join Juice^ [0] (n=Juice@179.81-166-167.customer.lyse.net) |
| 13:51:06 | Llorean | itcheg: Have you tested whether sudoku saves the scratchpad? |
| 13:51:56 | gevaerts | itcheg: since the commit and the bug are from the same person, maybe the best thing to do is to add a note to the bug |
| 13:52:02 | | Part j-noise |
| 13:52:06 | Llorean | gevaerts: Well, *my* point was more, if that's enough to warrant a major version increment I think significant leaps in hardware support (and potential targets, which is why I'm more focusing on SoCs than individual added players) probably should count too. |
| 13:52:39 | itcheg | was going to test it (havn't updated since before that commit) but thought it might be obvious |
| 13:52:41 | Llorean | The current lean seems to be "Don't touch the major version number unless people won't be able to tell they're using the same software any more" and I don't really agree with that. |
| 13:53:00 | gevaerts | I agree. That would be a bit too extreme |
| 13:53:24 | Llorean | gevaerts: I think the move from "audio player" to "universal media player" is probably one of about 3 major version number changes we can get with the current potential definition. |
| 13:53:40 | hammetpb22 | I am blind, so rockbox is only way for me, how to use all functions of my mp3 player. So i would be quite happy when it will work with E100 player. Unfortunately i don't have any programming skills so i can't work on ittarbUnhelpful |
| 13:54:50 | Llorean | gevaerts: I think the current definition would work for a GUIfied UI (probably including touchscreen support eventually, but that's probably not going to increment the number without the more GUI look), integration as a full media player, and possibly integrated text-to-speech. I think just about anything else qualifies as just a "minor improvement" in the overall scale, especially if judged in apparent impact from a user perspective. |
| 13:55:16 | gevaerts | I'm just not sure if a new SoC is change enough, because it may not be visible at all for non-devs. If you look at e.g. the AMS, from an end-user point of view, just more players from an already supported family get supported |
| 13:55:21 | amiconn | The 1.x -> 2.0 transition was rather arbitrary afaik |
| 13:55:52 | Llorean | But I think that if you only ever increment the minor version number (since ours is Major.Minor without any of that extra .Blah.blah.blah) it looks to a lot of people like you're maintaining, not developing. |
| 13:56:23 | * | gevaerts thinks |
| 13:56:43 | gevaerts | Actually, changing the default theme is *very* visible... |
| 13:56:50 | Llorean | This is true. |
| 13:57:17 | * | gevaerts isn't sure what this actually implies |
| 13:57:21 | Llorean | Not much. :) |
| 13:57:34 | | Quit jhMikeS (Read error: 104 (Connection reset by peer)) |
| 13:57:57 | gevaerts | It *could* imply that we can bump major versions whenever we want by just committing a new background bmp :) |
| 13:58:23 | Llorean | I'm not trying to push for a major version bump soon or anything |
| 13:58:37 | Llorean | But I think it might be wise to talk about it, so as a group everyone kinda fleshes out what page we're on for what it means. |
| 13:58:44 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 13:59:26 | Llorean | Since, by-project, it can mean anything from "we bump it each (year / X iterations)" to "we bump it when we rewrite from the ground up, and it's not really the same program any more" |
| 13:59:30 | Llorean | And there's a lot of space between the two |
| 14:00 |
| 14:00:16 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 14:00:45 | gevaerts | I think you're correct about there only being two or three foreseeable bumps with the current scheme, but I also think that since they are pretty independent it's likely that they won't occur together, so that gives us two major versions, and if you look at them, at least one of them is pretty long term, so you also look at several years |
| 14:01:32 | gevaerts | So I expect that we could well be looking at about one major version per one or two years for the next four years, if we use this set of criteria |
| 14:02:05 | * | gevaerts thinks that this is fine for now, and we can look at other reasons for version bumps once we run out |
| 14:02:57 | Llorean | I dunno. I guess to me, "SWCODEC" in a "user-perspective" sense is really "Rockbox runs on more players" too. |
| 14:03:37 | gevaerts | Yes, but different looking players from new manufacturers too |
| 14:04:08 | * | gevaerts thinks that an SWCODEC Archos port would warrant 4.0 :) |
| 14:04:41 | pixelma | the AV300 one? ;) |
| 14:04:53 | Llorean | Well, TCC targets would be different-looking players from new-lines. |
| 14:04:58 | gevaerts | Once it's supported, yes :) |
| 14:05:15 | pixelma | although that could be a dual swcodec/hwcodec player, IIUC |
| 14:05:21 | gevaerts | Even better :) |
| 14:06:03 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
| 14:07:29 | gevaerts | Llorean: I think that "new targets" is a bit of a grey area for major releases. Some groups may qualify, but others may not, but I'm not sure about where to draw the line |
| 14:07:58 | * | linuxstb likes the simplicity of Ubuntu's version numbering - simply using Year.Month... |
| 14:08:14 | gevaerts | i.e. suppose for the sake of the argument that the Fuze and Clip wouldn't exist. Does e200v2 and c200v2 support deserve a major version bump? |
| 14:08:54 | Llorean | gevaerts: I think that's something that can be a gray area. |
| 14:09:02 | gevaerts | It can indeed |
| 14:10:09 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 14:10:16 | Llorean | But I think that's something we can just decide on by a case for case basis anyway. The point I was just trying for is, I think when the project jumps in "size" for supported and potentially supported players, it's pretty significant. |
| 14:11:52 | amiconn | Imo the swcodec addition was pretty significant because it bumped the number of supported targets from 6 to >20 (of which some are rather popular ones) |
| 14:12:13 | amiconn | It also added the ability to play a ton of different formats |
| 14:12:15 | Llorean | amiconn: But we were going to do 3.0 the first time when it merely added H100/H300 |
| 14:13:05 | amiconn | ...and the database (which seems to be an important feature for some users) |
| 14:13:08 | | Quit parafin (Read error: 60 (Operation timed out)) |
| 14:13:22 | gevaerts | The problem with new targets is that they may well tend to come in small numbers each time. Is a 25->27 jump in supported targets worth a major release? |
| 14:13:36 | gevaerts | Of course we can work around that by doing fewer minor releases :) |
| 14:13:42 | Llorean | gevaerts: I think it's almost more the number of potential targets it brings. |
| 14:14:08 | amiconn | We need another 3-year wait to warrant bumping the major number ;) |
| 14:14:33 | Llorean | gevaerts: Once you've got one "Supported" and 3 or 4 on the verge of supported from the same base of work. |
| 14:14:59 | gevaerts | Maybe. We need to look at this on a case by case basis |
| 14:15:08 | Llorean | So 4.0 adds some TCC target, and 4.1, 4.2, etc add one more each if it's ready. |
| 14:15:13 | Llorean | It's definitely a case-by-case thing, yes. |
| 14:15:38 | Llorean | I was just trying to clarify whether Major needs to be strictly tied to features, or also possibly tied to "range of supported hardware" |
| 14:15:51 | Llorean | Since we're essentially an OS, I think "supporting more stuff" *is* a feature. |
| 14:15:57 | * | amiconn mentions the meizus... |
| 14:16:19 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 14:24:11 | | Part hammetpb22 |
| 14:27:48 | | Quit Juice^ ("Leaving") |
| 14:28:15 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
| 14:28:46 | Nico_P | my beast's side buttons seem to have stopped working |
| 14:34:18 | | Quit Seed ("cu, Andre") |
| 14:39:30 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
| 14:41:49 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-92caa95763fb3e2d) |
| 14:44:30 | *** | Saving seen data "./dancer.seen" |
| 14:48:47 | | Quit {phoenix} (Remote closed the connection) |
| 14:48:48 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 14:49:04 | | Quit LambdaCalculus37 (Client Quit) |
| 14:50:02 | | Join DerDome [0] (n=DerDome@dslb-082-083-201-130.pools.arcor-ip.net) |
| 14:51:37 | | Join Horschti [0] (n=Horscht@p4FD4F803.dip.t-dialin.net) |
| 14:51:53 | | Quit Horscht (Nick collision from services.) |
| 14:53:12 | | Join {phoenix} [0] (n=dirk@p54B47E32.dip.t-dialin.net) |
| 15:00 |
| 15:03:07 | | Join bugonshoe [0] (n=syflom@202.76.159.4.dynamic.rev.eftel.com) |
| 15:03:08 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 15:05:21 | bugonshoe | hi |
| 15:07:59 | | Join Buschel [0] (n=abc@p54A3E35A.dip.t-dialin.net) |
| 15:11:21 | | Quit pvagner_ (Read error: 60 (Operation timed out)) |
| 15:16:46 | | Join casainho [0] (n=chatzill@87.196.210.210) |
| 15:17:14 | casainho | hello :-) |
| 15:17:41 | casainho | can someone please tell me if there is a way to build RB with debug option, the -g on makefile? |
| 15:24:31 | | Join tyfoo [0] (n=tyfoo@dyndsl-095-033-101-001.ewe-ip-backbone.de) |
| 15:24:51 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 15:28:08 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
| 15:36:08 | | Quit linuxstb (Read error: 113 (No route to host)) |
| 15:41:26 | | Quit casainho ("ChatZilla 0.9.84 [Firefox 3.0.5/2008121622]") |
| 15:47:14 | | Join soap [50] (n=soap@rockbox/staff/soap) |
| 15:51:16 | Buschel | anybody against closing FS #9570? |
| 15:54:17 | | Join thegeek [0] (n=nnscript@85-89-4.72.3p.ntebredband.no) |
| 15:56:20 | | Join parafin [0] (i=parafin@paraf.in) |
| 15:56:48 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
| 15:58:01 | kugel | Buschel: you mentioned gui boost, what happened to that? |
| 15:58:22 | kugel | there has been some discussion on gui boost recently |
| 15:59:10 | kugel | fdinel: hey |
| 15:59:22 | fdinel | kugel: hi |
| 16:00 |
| 16:00:21 | kugel | fdinel: I wonder if you could have a look at the isrs in the of, I'm basically out of ideas on how to trigger an irq from the scrollwheel |
| 16:00:32 | Buschel | kugel: FS #8668 is still working :) I am using it since more than half a year now. |
| 16:00:44 | Buschel | kugel: nevertheless there are some issues with plugins etc. |
| 16:01:01 | kugel | Buschel: sadly, it's not working so good on the e200, the backlight stays on if you used the scrollwheel at last |
| 16:01:21 | Buschel | kugel: hmm, never knew that... |
| 16:01:40 | * | Buschel wonders whether he never knew or just forgot |
| 16:02:32 | kugel | maybe that's due to that the e200 scrollwheel support is basically seperate from the other buttons (e.g. it handles backlight seperately too) |
| 16:02:41 | kugel | I've only had a small look |
| 16:03:20 | Buschel | kugel: does the e200 also have issues with jerky gui @24MHz? |
| 16:04:04 | kugel | not sure, I don't think so (I've only tried it a very short period, i.e. gui_boost.patch without the gui boost) |
| 16:04:24 | kugel | but I'm fairly sure the text editor was rendered quite unusable |
| 16:06:58 | Buschel | well, today I used an official build to check for an issue and I was disappointed how laggy the gui was. With the patch it is much faster. But I do not seem to be the standard user with only music playback and browsing folders. |
| 16:08:31 | kugel | well, the issue is much more present on the ipod video |
| 16:09:08 | kugel | the screen is 2x as big |
| 16:09:19 | | Quit Thundercloud (Remote closed the connection) |
| 16:09:41 | Buschel | yes, that's what I have heard. It doesn't appear to be a major problem on other devices. Nevertheless the battery saving at least for PP is interesting −− especially after the dual core optimization for mp3. |
| 16:10:50 | kugel | Buschel: maybe you talk with saratoga about a gui boost, he's basically in favor for that too but has a few other ideas on how to implement |
| 16:10:51 | | Quit ajb (Remote closed the connection) |
| 16:11:24 | kugel | I think the main problem is that boosting isn't free on coldfire, and gui boost should only happen with free boosting |
| 16:12:03 | kugel | and maintaining 2 different boosting mechanisms (i.e. no gui boost on cf, but on pp) isn't so liked |
| 16:13:36 | | Join mellery [0] (n=mike@pool-71-191-192-228.washdc.fios.verizon.net) |
| 16:14:10 | | Join Dekkard [0] (n=psykobab@99-161-186-163.lightspeed.livnmi.sbcglobal.net) |
| 16:14:50 | Buschel | ok, then I will wait to meet saratoga here :) didn't talk to him for a long time now |
| 16:16:00 | Dekkard | new user here.. pretty freekin cool..kudos to the devs |
| 16:16:39 | kugel | Buschel: http://www.rockbox.org/irc/log-20081213 and the next day there's some discussion about it |
| 16:17:09 | Buschel | opening |
| 16:25:53 | soap | ahh yes, the next day's log, Buschel, starting @ 1:08 is where even more theoretical discussion kicks in. |
| 16:26:42 | Buschel | well, it is quite theoretical at the end of dec., 13, too ;-) |
| 16:28:10 | | Quit Nico_P (Remote closed the connection) |
| 16:30:29 | | Join ajb [0] (n=user@cpc2-cmbg5-0-0-cust252.cmbg.cable.ntl.com) |
| 16:32:37 | Buschel | never saw such long and intense discussion about the gui boost. and I am still reading... |
| 16:34:59 | kugel | Buschel: I figured it might be interesting for you :) |
| 16:35:29 | | Join Nibbler [0] (n=Nibbler@e181098106.adsl.alicedsl.de) |
| 16:40:28 | kugel | fdinel: do you think it might be possible using dmac? |
| 16:41:07 | kugel | I just saw this DBOP dma request line on the HardwareMapping page for e200 |
| 16:44:35 | *** | Saving seen data "./dancer.seen" |
| 16:45:48 | Buschel | kugel: the discussion about gui boost is still open, correct? or were there any decisions made? |
| 16:45:59 | Buschel | at least I did not see any commits... |
| 16:46:31 | kugel | no, I don't know about any decision, I don't think there's one |
| 16:47:17 | | Quit _lifeless (Read error: 104 (Connection reset by peer)) |
| 16:47:19 | | Join __lifeless [0] (n=lifeless@90.151.41.226) |
| 16:47:21 | | Quit __lifeless (Remote closed the connection) |
| 16:47:34 | | Join Riku [0] (n=Lss@cm203.delta90.maxonline.com.sg) |
| 16:49:31 | | Quit faemir (Remote closed the connection) |
| 16:49:45 | | Join _lifeless [0] (n=lifeless@90.151.41.226) |
| 16:50:01 | Buschel | I am in favour of 2 clocking speeds (24MHz + 80MHz) and boosting on GUI activity with timeout. To avoid conflicts with plugins/games/etc the GUI boost may not happen when having any plugin running. |
| 16:50:15 | Buschel | Generic and easy way. |
| 16:50:31 | soap | So can we expect just outright total dominance over Sansa v1 stock runtime now? |
| 16:52:35 | | Quit Lss (Read error: 60 (Operation timed out)) |
| 16:52:53 | bugonshoe | god damn i love the pitch setting |
| 16:56:44 | | Join Rob2222 [0] (n=Miranda@p4FDCDA95.dip.t-dialin.net) |
| 17:00 |
| 17:02:15 | | Join hammetpb22 [0] (n=Miranda@110.243.broadband10.iol.cz) |
| 17:04:26 | Buschel | FS #9570 closed |
| 17:13:53 | | Join faemir [0] (n=faemir@88-106-244-173.dynamic.dsl.as9105.com) |
| 17:16:35 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.5/2008120122]") |
| 17:16:44 | fdinel | kugel: it might, I'm not sure, I can have a look later on today |
| 17:18:08 | * | Buschel is running a battery bench with HDD via UDMA Mode 2 on his 5.5G :-) |
| 17:18:11 | Buschel | let's see |
| 17:19:02 | Tuplanolla | :) |
| 17:19:12 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 17:19:31 | kugel | Buschel: I wonder if this is only for disk targets, or for PP in general |
| 17:21:51 | Buschel | kugel: I am not sure... You could easily test it via the disk_plugin after appliying the patch ;-) |
| 17:22:32 | kugel | Buschel: yea I could, I hoped for a quick answer though ;) |
| 17:23:39 | Buschel | kugel: but the positive effect to battery lifetime (which I expect and hope for) will be only visible with HDD targets. |
| 17:24:00 | kugel | Buschel: doesn't look like it brings something for my e200, given that ata-sd-pp.c isn't modified |
| 17:25:56 | kugel | Buschel: I think faster data transfers are a positive effect of its own even if it doesn't increase battery life |
| 17:26:13 | crwl | upgrading to current build with my e280 didn't go too well, got data abort at 00009364 (0) soon after resuming playback |
| 17:26:47 | Buschel | kugel: that's right. maybe I am too much focussed on batt life ;-) |
| 17:28:35 | kugel | Buschel: also, on flash we're boosting too on refilling the buffer, so there should be a battery life increase by having a shorter boost time |
| 17:29:21 | | Join sqgl [0] (i=sqgl@015.a.001.syd.iprimus.net.au) |
| 17:30:27 | Buschel | kugel: but cpu boosting is not that expensive as a running HDD. the savings should be minimal for non-HDD targets |
| 17:31:11 | kugel | not that significat yea, but maybe not minimal too ;) |
| 17:31:45 | Buschel | kugel: ok, let's use your wording ;-) |
| 17:42:08 | | Quit aurix_lexico (Read error: 104 (Connection reset by peer)) |
| 17:42:53 | sqgl | Does Rockbox running on Sansa C250 allow pitch-corrected variable speed playback? |
| 17:43:48 | sqgl | (can't download the pdf manual from rockbox.org for some reason) |
| 17:44:24 | | Join aurix_lexico [0] (n=adam@140bus188.tampabay.res.rr.com) |
| 17:44:42 | soap | (enter dreaming mode) is there any chance in hades that PP DMA mode might magically fix the SD corruption problems of the Sansas? |
| 17:45:17 | crwl | sqgl, i guess all swcodec targets have pitch adjustment (someone correct me if i'm wrong) |
| 17:45:34 | soap | and Buschel, did I miss in the logs if you figured out why your previous 5.5 runtime tests failed? |
| 17:45:55 | sqgl | not on my old archox recorder |
| 17:46:11 | sqgl | *archos |
| 17:46:39 | sqgl | not pitch independent of speed |
| 17:47:11 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 17:47:48 | amiconn | sqgl: He said *swcodec*. Archos recorder his hwcodec, hence variable speed without changed pitch is impossible |
| 17:47:54 | amiconn | s/his/is/ |
| 17:48:48 | sqgl | OK, i learn two things in one go. thanks. |
| 17:56:51 | sqgl | And maybe now you learn something: |
| 17:57:10 | sqgl | i managed to dl the PDF manual aferall and it says it is not possible |
| 17:57:43 | sqgl | "it is not possible to change the pitch without changing the playback speed and vice-versa" |
| 17:58:20 | sqgl | http://download.rockbox.org/release/3.1/rockbox-sansae200-3.1.pdf |
| 17:58:29 | sqgl | page 33 |
| 17:59:13 | sqgl | So does that mean that none of the rockbox supported mp3 players can do it? |
| 18:00 |
| 18:00:23 | | Join Schmogel [0] (n=Miranda@p3EE21FB1.dip0.t-ipconnect.de) |
| 18:07:17 | | Quit {phoenix} (Remote closed the connection) |
| 18:09:49 | | Quit grndslm (Read error: 110 (Connection timed out)) |
| 18:11:50 | pixelma | soap: I think Buschel said that the battery bench "failed" because "repeat" was set to off, should be somewhere in today's log |
| 18:12:05 | soap | thanks |
| 18:13:41 | soap | ahh, I had clicked-to-highlight "Buschel_" in the log, not "Buschel" |
| 18:16:17 | sqgl | Llorean said a year ago that time stretching was theoretically possible but nobody had implemented it yet. |
| 18:16:59 | sqgl | (that is from my logfile of #rockbox-community Dec 08 2008 |
| 18:20:07 | sqgl | Maybe i should get off my lazy ass and do it myself rather than wait for someone else to do it. |
| 18:22:52 | | Quit mellery ("Ex-Chat") |
| 18:23:02 | sqgl | crwl, you at least can confrim that the codec allows for it eh? So just needs implementation in rockbox as Llorean suggested? |
| 18:25:41 | scorche|sh | sqgl: read what multiple people have said...they are all talking about *SWCODEC* devices...as amiconn said, since the recorder is hwcodec, it is not possible |
| 18:26:31 | pixelma | sqgl also said something about his c250... |
| 18:28:38 | scorche|sh | yeah...was getting to that, but got distracted |
| 18:29:13 | scorche|sh | sqgl: for the c250, you can try a patch on flyspray - #8894 |
| 18:30:30 | sqgl | yes, c250, the Archos unit was mentioned as an aside. |
| 18:30:58 | sqgl | thanks for flyspray tip |
| 18:31:11 | | Quit Darksair (Remote closed the connection) |
| 18:44:38 | *** | Saving seen data "./dancer.seen" |
| 18:57:44 | | Part sqgl ("Leaving") |
| 18:58:53 | Buschel | soap: back again now. and yes, after updating rockbox my repeat setting was lost. therefor after playing the album -> stop plaback -> timoeut -> shut down |
| 18:59:01 | Buschel | soap: the bench is running fine now :) |
| 19:00 |
| 19:01:18 | kugel | Buschel: the default setting changed, that might be the reason |
| 19:02:19 | Buschel | kugel: sounds reasonable. The dumb thing is that I've checked all the other settings... This was the only one I forgot... |
| 19:03:40 | | Quit Febs (Read error: 60 (Operation timed out)) |
| 19:05:18 | kugel | Buschel: yea, running a battery bench with default settings isn't a good idea anymore |
| 19:06:34 | amiconn | Buschel: Imo it is useful to save a .cfg manually from time to time. Such a .cfg contains all settings, regardless whether they're default or not |
| 19:07:32 | | Join elric50 [0] (n=48f390e7@gateway/web/cgi-irc/labb.contactor.se/x-c82a510c5f1f431e) |
| 19:08:48 | | Join toffe82 [0] (n=chatzill@adsl-76-240-239-95.dsl.frs2ca.sbcglobal.net) |
| 19:12:19 | elric50 | guys i'm having a heck of a time trying to set up my rockbox on my version 5 ipod i think i have it then i mess with the playlist and i screw it all up |
| 19:21:07 | | Quit elric50 ("CGI:IRC (EOF)") |
| 19:37:02 | | Join anewuser [0] (i=anewuser@unaffiliated/anewuser) |
| 19:40:56 | | Join gregzx [0] (n=chatzill@dsz251.neoplus.adsl.tpnet.pl) |
| 19:41:24 | | Join __lifeless [0] (n=lifeless@94.50.187.247) |
| 19:44:20 | | Quit _lifeless (Read error: 60 (Operation timed out)) |
| 19:46:19 | | Join stoffel_ [0] (n=sfr@p57B4DF26.dip.t-dialin.net) |
| 19:49:09 | | Quit kugel (Remote closed the connection) |
| 19:50:39 | | Quit Nibbler (Read error: 60 (Operation timed out)) |
| 19:53:11 | | Quit Dekkard (Remote closed the connection) |
| 20:00 |
| 20:13:43 | | Part hammetpb22 |
| 20:15:29 | | Quit Buschel (Read error: 60 (Operation timed out)) |
| 20:25:12 | | Join Strife89 [0] (n=michael@204.116.245.152) |
| 20:30:51 | | Join vitja [0] (n=vitja@79.120.98.174) |
| 20:33:48 | | Join {phoenix} [0] (n=dirk@p54B47E32.dip.t-dialin.net) |
| 20:43:56 | | Quit Strife89 ("Huzzah!") |
| 20:44:40 | *** | Saving seen data "./dancer.seen" |
| 20:51:29 | | Quit jhMikeS (Nick collision from services.) |
| 20:51:35 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 21:00 |
| 21:00:25 | | Join massiveH [0] (n=massiveH@pool-70-105-170-139.nwrknj.fios.verizon.net) |
| 21:00:40 | | Quit massiveH (Read error: 104 (Connection reset by peer)) |
| 21:03:11 | | Join Aiffe260 [0] (n=43523e62@gateway/web/cgi-irc/labb.contactor.se/x-9ff5e7087f8e9d78) |
| 21:03:23 | Aiffe260 | hi |
| 21:03:38 | Aiffe260 | hi' |
| 21:04:02 | Aiffe260 | hi |
| 21:04:12 | Aiffe260 | hewllo |
| 21:04:19 | Aiffe260 | i need help |
| 21:04:49 | krazykit | Aiffe260, you need to ask a question if you want help |
| 21:05:00 | Aiffe260 | why is rockbox not reading aiff and flac files? |
| 21:05:50 | krazykit | do these files play correctly on your computer? |
| 21:06:40 | | Quit Aiffe260 (Client Quit) |
| 21:08:01 | | Join Helpiiiia [0] (n=Helpiiii@ool-43523e62.dyn.optonline.net) |
| 21:08:26 | | Quit Helpiiiia (Read error: 104 (Connection reset by peer)) |
| 21:10:28 | | Join Helpiiiia [0] (n=Helpiiii@ool-43523e62.dyn.optonline.net) |
| 21:10:50 | Helpiiiia | hi |
| 21:11:01 | Helpiiiia | my rockbox is not readsing aiff and flac files |
| 21:11:14 | Helpiiiia | does not play them |
| 21:11:29 | linuxstb | What happens when you select one? |
| 21:11:39 | Helpiiiia | it does not show up on the player |
| 21:11:56 | linuxstb | In the "Files" option or the "Database" ? |
| 21:13:03 | Helpiiiia | hah, nevermind, i just needed to restart the player |
| 21:13:35 | Helpiiiia | why everytime i selec a track ir says erase dynamuic playlist |
| 21:15:32 | Helpiiiia | aiff doesnt show the album name and stuff, it just says untagged |
| 21:19:59 | | Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-108-189.ewe-ip-backbone.de) |
| 21:24:19 | linuxstb | Helpiiiia: Regarding the "erase dynamic playlist" prompt, the manual describes playlists in Rockbox. |
| 21:27:42 | | Quit Helpiiiia (Read error: 104 (Connection reset by peer)) |
| 21:29:29 | | Join saratoga [0] (i=62e14d04@gateway/web/ajax/mibbit.com/x-a4ff9df95440d859) |
| 21:30:05 | saratoga | seems i've missed Buschel |
| 21:30:15 | saratoga | but for the logs i'll sumarize: |
| 21:30:35 | saratoga | I suggested a system where GUI activity slightly increases the normal clock rate rather then explicitly boosting |
| 21:31:00 | saratoga | amiconn suggested trying to get boosting faster on PP so that GUI code could simply boost for fractions of a second |
| 21:31:24 | saratoga | either system woudl hopefully alow reducing the core clock rate |
| 21:31:27 | saratoga | at least on PP |
| 21:32:35 | | Join Helpiiiia [0] (n=Helpiiii@ool-43523e62.dyn.optonline.net) |
| 21:32:57 | Helpiiiia | can you repeat that my connection was lost |
| 21:33:14 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 21:33:41 | saratoga | on a side note, I found power measurements for CF, and you could in theory improve battery life on these targets significantly with some sort of selective gui boosting too, though maybe people are less interested in that |
| 21:33:42 | krazykit | Helpiiiia, the channel is logged so you can go back and read what was said |
| 21:34:08 | saratoga | since CF already gets good battery life |
| 21:34:17 | | Quit tyfoo (No route to host) |
| 21:34:47 | Helpiiiia | and do you know if aiff is suppose to stay untagged? |
| 21:34:59 | saratoga | AIFF can't be tagged |
| 21:35:05 | Helpiiiia | oh okay kool |
| 21:35:24 | Helpiiiia | just flAC (out of the losslesS? |
| 21:35:27 | saratoga | if you want to use the database you should not use formats like AIFF that cannot be tagged |
| 21:35:54 | | Join mirak [0] (n=mirak@85-170-148-23.rev.numericable.fr) |
| 21:35:56 | | Join hammetpb22 [0] (n=Miranda@110.243.broadband10.iol.cz) |
| 21:36:22 | Helpiiiia | is flac the same audio quality as wav or aiff? |
| 21:36:46 | krazykit | yes, flac is lossless (and has smaller file sizes than uncompressed audio) |
| 21:37:12 | Helpiiiia | cool, ill just use thatone because it can be tagged |
| 21:37:33 | Helpiiiia | thanks for all the help |
| 21:38:34 | Helpiiiia | the rockbox its pretty cool because it doesnt have that anoyying fade in feture the sansa has |
| 21:39:54 | | Quit stoffel_ ("leaving") |
| 21:42:05 | Helpiiiia | the log is not loading |
| 21:43:10 | | Join tvelocity [0] (n=tony@athedsl-10990.home.otenet.gr) |
| 21:43:27 | | Join ae88925 [0] (n=tpratt@c-98-217-36-143.hsd1.ma.comcast.net) |
| 21:46:22 | Helpiiiia | does the album art adjust itself or do i need to edit the originalk image? |
| 21:47:23 | saratoga | http://www.rockbox.org/twiki/bin/view/Main/AlbumArt |
| 21:48:30 | Helpiiiia | and what about the erase dynamic playlist message everytime i selec a track? |
| 21:49:59 | Helpiiiia | is there any way to disable that? |
| 21:52:29 | linuxstb | Helpiiiia: What about this version of the log? http://www.rockbox.org/irc/current.txt |
| 21:54:30 | ae88925 | Why might I not be able to see files from within rockbox, but I can see them when my player is connected to my PC via USB? (In the VIDEO directory) |
| 21:55:36 | | Quit Helpiiiia (Read error: 104 (Connection reset by peer)) |
| 21:56:07 | n1s | ae88925: check your "Show files" setting |
| 22:00 |
| 22:02:26 | | Join matsl [0] (n=matsl@host-90-239-82-108.mobileonline.telia.com) |
| 22:04:52 | | Quit miepchen^schlaf () |
| 22:07:00 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 22:13:20 | | Quit thegeek (Read error: 145 (Connection timed out)) |
| 22:15:38 | | Join filesdown4 [0] (n=58476814@gateway/web/cgi-irc/labb.contactor.se/x-589f9af975c1cfb1) |
| 22:16:05 | filesdown4 | hello_ |
| 22:16:52 | filesdown4 | some download links on the rockbox website are not working, i need the fonts pack |
| 22:17:41 | | Join thegeek [0] (n=nnscript@85-89-4.72.3p.ntebredband.no) |
| 22:19:22 | | Join Buschel [0] (n=abc@p54A3D6DF.dip.t-dialin.net) |
| 22:22:11 | saratoga | working here |
| 22:23:28 | | Part aurix_lexico |
| 22:26:06 | filesdown4 | http://download.rockbox.org/daily/fonts/rockbox-fonts.zip does not work for me |
| 22:29:39 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
| 22:31:46 | n1s | not working for me, possibly one mirror is bad |
| 22:31:53 | n1s | Bagder: ping |
| 22:32:23 | saratoga | wget says one of the mirrors is bad, but happily pulls it from another after a delay |
| 22:32:45 | | Quit XavierGr (Nick collision from services.) |
| 22:32:56 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 22:34:39 | Bagder | I can't even connect to the 64.72.118.218 one |
| 22:35:29 | filesdown4 | saratoga can you copy the wget line you typed in? I am not familiar with wget |
| 22:35:34 | filesdown4 | thanks |
| 22:36:27 | Bagder | curl -O -H "Host: download.rockbox.org" http://80.87.134.17/daily/fonts/rockbox-fonts.zip works (obviously not using wget...) |
| 22:36:54 | filesdown4 | indeed, thanks |
| 22:38:07 | filesdown4 | wait, no it dies not work . gives 404 |
| 22:38:16 | filesdown4 | dies = does |
| 22:39:18 | Bagder | not for me |
| 22:40:19 | n1s | I get "Not Found" for http://80.87.134.17/daily/fonts/rockbox-fonts.zip too |
| 22:40:50 | Bagder | n1s: you need the "custom" Host: header added |
| 22:41:00 | n1s | aha |
| 22:41:46 | Bagder | that's just a way to access a single server in the round robin dns |
| 22:42:10 | Bagder | dig/nslookup on download.rockbox.org will list the three ips that are involved |
| 22:42:13 | n1s | yes, that works fine |
| 22:42:29 | | Join webguest84 [0] (n=4a2eea7b@gateway/web/cgi-irc/labb.contactor.se/x-ed70d94356740316) |
| 22:43:32 | filesdown4 | i dont understand - add the Host:header where? |
| 22:43:32 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-067b04d3159f8f51) |
| 22:44:41 | Bagder | in the http request, thus the -H stuff in the curl command line |
| 22:44:42 | *** | Saving seen data "./dancer.seen" |
| 22:48:11 | n1s | hmm, the manual says that fonts are included in release zips but this is not true, is it a manual bug or a release bug? |
| 22:49:10 | webguest84 | hi im new here and was looking through the pdf manual and was wondering if i need to how to set it back to its original system? |
| 22:49:20 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
| 22:49:37 | | Quit Riku (Read error: 104 (Connection reset by peer)) |
| 22:49:44 | | Quit Seed ("cu, Andre") |
| 22:49:50 | n1s | webguest84: the manual covers uninstallation |
| 22:50:34 | webguest84 | under what bookmark would it be under? |
| 22:51:14 | n1s | the end of the installation chapter |
| 22:51:41 | webguest84 | thanks |
| 22:53:34 | | Quit ae88925 ("Leaving") |
| 22:53:55 | | Join aurix_lexico [0] (n=adam@140bus188.tampabay.res.rr.com) |
| 22:54:01 | n1s | Bagder: do you think release zips should include all the fonts? |
| 22:54:19 | Bagder | no, I don't think I do |
| 22:54:45 | | Part hammetpb22 |
| 22:55:04 | n1s | ok, it's the manual that needs fixing then |
| 22:56:19 | webguest84 | so i need a plugin to watch video?? |
| 22:57:15 | n1s | webguest84: yes, and yes it is already installed if you did the installation correctly |
| 22:57:44 | webguest84 | and its only one kind? |
| 22:58:10 | n1s | yes, it supports mpeg 1 and 2 |
| 22:59:41 | webguest84 | how is the quality of mpeg in you opinion? iv never used it |
| 23:00 |
| 23:00:37 | n1s | it's fine imo the display of the player is the biggest limitation and why i don't use it much also this is sort of off topic :) |
| 23:01:43 | | Join Barahir [0] (n=jonathan@Xded8.x.pppool.de) |
| 23:02:34 | saratoga | woah i didn't know ffmpeg had a fixed point mp3 decoder |
| 23:02:39 | saratoga | perhaps we can steal parts of it |
| 23:03:05 | Barahir | hi |
| 23:04:34 | Barahir | i made a rockbox installation for my girlfriend, she was listening to music and then the player stopped and no key has any effect. is there any special combination of key-pressing to reboot or something like this? |
| 23:04:46 | Barahir | its rockbox on the Olympus m:robe 100 |
| 23:05:38 | n1s | Barahir: IIRC it has a reset hole that you can insert something like a straightened paperclip into to reset it |
| 23:07:45 | filesdown4 | i notice that the regular downloads are working again - phew |
| 23:08:50 | Barahir | thanks, i'll try |
| 23:11:07 | | Quit Buschel (Read error: 60 (Operation timed out)) |
| 23:14:01 | Barahir | @nls: thanks from her, it worked and shes happy again ;-) |
| 23:14:39 | Barahir | n1s: |
| 23:14:54 | n1s | great ;) |
| 23:19:39 | | Quit fredddy (Remote closed the connection) |
| 23:22:06 | | Quit anewuser (Client Quit) |
| 23:24:24 | | Quit n1s () |
| 23:28:59 | webguest84 | what about e260s? are they supported? |
| 23:29:20 | | Quit ameyer (Remote closed the connection) |
| 23:30:50 | saratoga | depends which one you have, see the front page |
| 23:32:26 | | Quit nplus (Remote closed the connection) |
| 23:33:41 | webguest84 | v1.02.18A but when i use rockbox utility it dosnt work |
| 23:34:46 | saratoga | MSC mode? |
| 23:37:46 | | Join webguest58 [0] (n=4889b2e3@gateway/web/cgi-irc/labb.contactor.se/x-435c6004e9542a03) |
| 23:38:01 | webguest58 | |
| 23:38:02 | webguest84 | yes it is on msc |
| 23:38:48 | | Quit webguest58 (Client Quit) |
| 23:39:12 | advcomp2019 | webguest84, a rhapsody version |
| 23:40:20 | | Quit matsl (Remote closed the connection) |
| 23:41:08 | advcomp2019 | oops.. never mind |
| 23:42:56 | | Join fml [0] (n=4fd3c089@gateway/web/cgi-irc/labb.contactor.se/x-db9d0b65aa28335d) |
| 23:43:44 | fml | Hello. Where can I read the discussion and the possible ("right") solutions to the multifont feature? |
| 23:44:31 | | Part aurix_lexico |
| 23:44:53 | webguest84 | so it dosnt support e260? |
| 23:45:04 | bslote | not if it's a v2 |
| 23:46:14 | advcomp2019 | webguest84, if it has v1.02.18, it should be supported |
| 23:46:25 | fml | I looked at the lru and font_cache code and think that I understand it 90%. The rest wouldn't be a problem. But how would multiple fonts work? Do we want to have a single big cache for all fonts in use? Or one cache per font? |
| 23:47:05 | saratoga | one big cache for all fonts |
| 23:47:49 | fml | saratoga: why? To save space? |
| 23:50:05 | saratoga | fml: I just know the last multifont patch was rejected for having seperate caches |
| 23:50:09 | fml | saratoga: so the big cache should be able to give the bits of the char with the given code of the font with the specified "handle"? And a font would have to be "registered" in the cache before (the handle would be the result of the registration)? |
| 23:50:23 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 23:50:42 | saratoga | you should ask kugel he was talking about it yesterday (or check the logs) |
| 23:52:34 | | Join nplus [0] (n=nplus@141.25.Globcom.Net) |
| 23:53:12 | fml | saratoga: ah, the task has been rejected, that's why I didn't find it via the simple search (FS #4733). Hmm... 217 comments... I'm not sure I want to read them all :-) I'll read the logs |
| 23:55:35 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
| 23:55:58 | fml | Llorean: maybe you could point me at a wiki page (if one exists) with the outline of the "right" solution? |
| 23:57:11 | robin0800 | does commit r19579: provide charging on portal players? |
icon identifies that the person is a core developer (has commit access).