| 00:02:28 | eWill | n1s:you said, "runtime estimate will never be very accurate". Care to ballpark a margin of error? |
| 00:03:16 | n1s | no |
| 00:03:32 | eWill | anyone? Wild guess? |
| 00:04:31 | Llorean | eWill: It's impossible to ballpark since it depends on your use patterns, including filetypes, as well as the condition of your battery and even things like the ambient temperature. |
| 00:04:41 | Llorean | The best person to ballpark the margin of error for a given device is its owner after experience. |
| 00:04:55 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 00:05:41 | | Quit jgarvey (Client Quit) |
| 00:10:30 | | Join krabador [0] (~krabador@host183-177-dynamic.27-79-r.retail.telecomitalia.it) |
| 00:12:12 | | Quit sideral (Quit: Leaving.) |
| 00:12:58 | *** | Saving seen data "./dancer.seen" |
| 00:14:28 | | Nick MortalScan is now known as MortalScan_Troll (~mortalsca@109.169.55.155) |
| 00:15:20 | | Join Keripo [0] (~Keripo@eng254.wireless-resnet.upenn.edu) |
| 00:20:04 | | Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) |
| 00:21:10 | | Quit wodz (Quit: Leaving) |
| 00:25:49 | | Join T44 [0] (~Topy44@f049076218.adsl.alicedsl.de) |
| 00:26:53 | eWill | Is this true: If I modify a source file, and a commit is made that changes that source file, my modified one won't be touched if I "svn update". |
| 00:27:43 | eWill | I should have said, "updated" instead of "touched" |
| 00:28:36 | | Quit Topy44 (Ping timeout: 240 seconds) |
| 00:28:39 | n1s | no, svn will try to merge the two files |
| 00:28:49 | n1s | if it fails it will create a conflict |
| 00:30:57 | eWill | and notify me of the conflict? |
| 00:31:31 | n1s | yes, it prints a "C" for conflict, "G" for successful merge and "U" for regular updates |
| 00:37:04 | | Quit n1s (Quit: Lämnar) |
| 00:37:25 | eWill | I want to do a fast battery bench (so i can build the voltage/percent table). Here's my plan: repeat a file encoded to a format that RB decodes slow; turn backlight to "ON"; raise brightness to max; use the EQ. Any other suggestions? |
| 00:38:51 | | Quit bertrik (Ping timeout: 272 seconds) |
| 00:39:20 | Bushmills | low impedance headphone with volume set to max? |
| 00:40:37 | Bushmills | though i think, running f.e. a fractal zoom consumes more CPU than decoding a media file |
| 00:41:16 | CIA-45 | New commit by pixelma (r28840): Manual - Sansa e200 player images: update the labels for scrolling ('back' and 'fwd' instead of 'up' and 'down') to match the c code and naming in the ... |
| 00:43:13 | pixelma | is this worth a backport? |
| 00:43:24 | CIA-45 | r28840 build result: All green |
| 00:45:49 | | Quit Staphylo (Quit: Bye les gens =)) |
| 00:45:56 | eWill | wouldn't playing an audio file that my player can't decode in realtime max-out the CPU? |
| 00:46:37 | eWill | like a fully compressed APE? |
| 01:00 |
| 01:06:22 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 01:06:58 | | Join DerPapst [0] (~Alexander@p5DE5B64F.dip.t-dialin.net) |
| 01:13:19 | [Saint] | Gah....bloody iPod Colour data aborts trying to init database :/ |
| 01:22:39 | [Saint] | Need to wait until I can build my own binary to see what its choking on...It'd be really nice if the .map file was packaged with the daily builds/all builds. |
| 01:22:47 | [Saint] | could save some time. |
| 01:38:20 | | Join simonrvn [0] (simon@197.112-ppp.3menatwork.com) |
| 01:42:52 | | Join telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com) |
| 02:00 |
| 02:01:48 | | Quit Kitar|st (Ping timeout: 255 seconds) |
| 02:02:46 | | Quit tchan1 (Quit: WeeChat 0.3.3-dev) |
| 02:07:57 | | Join Kitar|st [0] (~Kitarist@BSN-182-85-30.dial-up.dsl.siol.net) |
| 02:08:02 | | Join Zarggg_ [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 02:12:03 | | Quit Zarggg (Ping timeout: 265 seconds) |
| 02:12:59 | *** | Saving seen data "./dancer.seen" |
| 02:15:07 | | Join edboyer93 [0] (~eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) |
| 02:16:06 | | Join Jeshikah [0] (~4a69ab57@giant.haxx.se) |
| 02:16:59 | Jeshikah | i know this might seem like stupid question, but i came across a plugin mentioned in the manual that i don't have on my device |
| 02:18:00 | | Quit krabador (Ping timeout: 255 seconds) |
| 02:18:32 | | Quit chattr (Quit: gone) |
| 02:18:33 | | Quit Jeshikah (Client Quit) |
| 02:18:48 | | Join Jeshikah [0] (~4a69ab57@giant.haxx.se) |
| 02:19:13 | Jeshikah | where can i get the rockboy plugin? the gb/gbc emulator? |
| 02:21:18 | krazykit | read the manual more closely. rockboy is a viewer plugin. just click on a rom. |
| 02:22:17 | Jeshikah | ah. so basically i just put the roms and it opens it like it would a video file? |
| 02:22:35 | krazykit | yes |
| 02:22:45 | Jeshikah | great, thank you very much ^^ |
| 02:24:39 | | Join chattr [0] (~mike@244.87.189.72.cfl.res.rr.com) |
| 02:29:00 | | Quit kugel (Remote host closed the connection) |
| 02:30:07 | | Join krabador [0] (~krabador@host156-24-dynamic.247-95-r.retail.telecomitalia.it) |
| 02:37:04 | Jeshikah | oh one question: can the rockboy handle gba roms too? has it been tested with gba roms? i ask cuz i know many emulators that can play gbc roms can also |
| 02:37:21 | Llorean | No. |
| 02:37:22 | Jeshikah | example visualboy advance) |
| 02:46:38 | | Join madalu [0] (~user@unaffiliated/madalu) |
| 02:54:58 | | Quit Jeshikah (Quit: CGI:IRC 0.5.9 (2006/06/06)) |
| 03:00 |
| 03:00:43 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 03:04:51 | | Quit telliott (Ping timeout: 276 seconds) |
| 03:08:35 | | Quit madalu (Remote host closed the connection) |
| 03:08:38 | soap | scorche, you said you could view the moderation log. Who deleted Hendricks266's post? |
| 03:12:41 | soap | Llorean, I see the directory approach as giving 80+% of users a simple path to exactly what they need, and the "all files" toggle approach as giving 100% of users kinda what they need. |
| 03:13:01 | Llorean | soap: I'm not understanding. |
| 03:13:13 | Llorean | What does the directory approach offer that the all files one doesn't? |
| 03:13:18 | soap | segmentation |
| 03:13:41 | soap | esay segmentation. One behavior for one class of files and one behavior for the other class of files. |
| 03:13:49 | soap | *easy |
| 03:13:51 | Llorean | But is that really useful/necessary? |
| 03:14:32 | Llorean | Is it particularly harmful if files auto-resume when selected? An "insert shuffled" wouldn't auto-resume, or an "insert" or even selecting a playlist, but clicking on a specific file would. |
| 03:14:35 | soap | I believe it is simply because it is the approach seen elsewhere in the "marketplace" and I feel it is an extension of many people's mental groupings. |
| 03:15:12 | Llorean | I don't know that "it's how they do it on the Clip+" is really that big of a reason to do it. |
| 03:15:19 | soap | and apple |
| 03:15:31 | Llorean | And it's also not a reason not to take it a step further. |
| 03:15:32 | | Quit thegeek (Read error: Connection reset by peer) |
| 03:15:34 | soap | (of course it isn't directory based there, but the pathway to it is similar) |
| 03:15:59 | Llorean | I mean, nobody's really said why they think it wouldn't work well for all files. I don't get the "100% of users kinda what they need" statement. |
| 03:16:08 | soap | I wouldn't characterize the "all files" toggle as "a step further" but rather an entirely different approach. |
| 03:16:15 | Llorean | What toggle? |
| 03:16:55 | soap | Am I mistaken in believing your "F" is a selectable option? Or are you saying do it universally? |
| 03:17:01 | Llorean | Universally |
| 03:17:10 | soap | let me reread |
| 03:17:14 | Llorean | Auto-resume all files, but have very explicit situations in which a file is auto resumed. |
| 03:17:59 | soap | ie on a new class of insertion? |
| 03:18:27 | Llorean | A new class of insertion, or if a file is launched by single-clicking "select" (or equivalent) on it. |
| 03:18:42 | Llorean | Do not auto-resume if the file is reached by directory change, next track in the playlist, or any other automatic means. |
| 03:19:12 | Llorean | The new class of insertion is, to me, a way to bring some of the "auto resume mid-playlist" functionality in, and not a key part of what I'm suggesting. |
| 03:19:27 | Llorean | Just a way to bridge the gap between no mid-playlist resumes and having them. |
| 03:19:34 | soap | Which means explicit insertion of all. "Directory" methodology means implicit new behavior. |
| 03:19:46 | soap | *which means explicit insertion of all is required. |
| 03:19:56 | Llorean | Explicit insertion *if* you want mid-playlist resumes. |
| 03:20:01 | soap | right |
| 03:20:03 | Llorean | As in, resume file 1, then resume file 2 then resume file 3 |
| 03:20:11 | soap | correct |
| 03:20:14 | Llorean | I'm against automatic mid-playlist resume even with your segmentation proposal |
| 03:20:22 | Llorean | It still doesn't resolve any of the problems with it i've brought up. |
| 03:20:27 | soap | As I said, it's how other do it. |
| 03:20:36 | Llorean | Do they? |
| 03:20:52 | soap | yes, Apple treats podcasts and audiobooks "special". |
| 03:20:59 | Llorean | If I have three chapters of a book on my ipod, queued up in a playlist, seek in 3 minutes of chapter two, then play chapter 1, it'll be 3 minutes into chapter two when it loads that file? |
| 03:21:20 | soap | they "segment" music away. Apparently Sansa is playing around with something similar, but file based instead of database based. |
| 03:21:33 | Llorean | soap: I know the iPod auto-resumes podcasts. |
| 03:21:39 | Llorean | But does it really auto-resume mid playlist, and with books too? |
| 03:21:52 | soap | That final query I can't say. I do ask that you limit the questions to one at a time. |
| 03:22:30 | soap | one sec, gotta check on something unrelated. |
| 03:22:48 | Llorean | I still think mid-playlist resuming is much more of a fringe case than people just wanting to select a podcast and have it pick up where they left off. |
| 03:22:57 | Llorean | And not think about having to train their syncing program to put it in special folders or whatnot |
| 03:23:56 | Llorean | Queuing a file isn't difficult at all, and I'd say asking people who want mid-playlist resume to queue is a lot more "user friendly" than asking people to restrict themselves to certain organizational structure and to be careful because mid-playlist resume will happen whether they want it or not. |
| 03:24:34 | saratoga | soap: I deleted it, I didn't bother PM'ing him |
| 03:25:47 | soap | Llorean, let's throw it back at the OP / patch man. Personally I think the debate is well framed as "explicit" vs "implicit" methodology. |
| 03:26:25 | soap | saratoga, I'll pm him. I know it was a fucking idiotic noob statement, but I always try to steer them once. |
| 03:27:06 | Llorean | soap: Well, I think it's also a case of ease of use. I feel my way it a lot easier to use over all, since it doesn't require your files be organized any specific way *in advance* or anything. While your way is vacation-doable you have to use the file browser's copy and paste if you've done anything wrong. |
| 03:27:35 | saratoga | i usually just PM if if move the post, but if its stupid/offtopic/whatever i don't bother since then people feel like they can bug me with more questions |
| 03:27:43 | Llorean | Also, my way allows access to the functionality of your way, while your way doesn't allow access to the functionality of my way which means I'm stuck with a feature working a way I don't want and no way to resolve that. |
| 03:28:17 | Llorean | soap: I don't know what you mean by "throw it back at the OP"? He's made it clear his use case is for playlists with multiple resume points within them, so I don't think he's going to be in favour of reducing the capability for that. |
| 03:28:55 | soap | saratoga, I hear that. I have no problem taking on the role of "someone to take the time to explain the explicit rules" while you do real work. ;) |
| 03:30:04 | saratoga | Fred Bauer's new test_codec results for the fuzev1 after his clocking changes are really interesting |
| 03:30:10 | soap | Llorean, on your second point I really don't care, no offense, what either of our expectations are of his reaction. I still think an explicit outline of the counter proposal is polite. |
| 03:30:36 | Llorean | soap: I don't understand. |
| 03:30:40 | saratoga | they're pretty close to the fuzev2 |
| 03:31:08 | saratoga | looks like adding that unboosted option to test codec really encouraged people to think about clocking more :) |
| 03:31:19 | soap | Llorean, I'm not sure where I could clarify, but I'm willing to try. |
| 03:31:27 | Llorean | soap: What are we going back to him for? |
| 03:31:55 | Llorean | The question is whether this is the way we want such a feature implemented. No offense to him, but does his opinion matter in that question beyond what his preferred implementation is (which he's demonstrated)? |
| 03:32:37 | Llorean | The feature breaks down to "which files", "should it be optional", "should how it behaves be configurable", and lastly "which configuration options should be offered?" |
| 03:33:18 | Llorean | Your description has been "all files in a specific location", "yes by physical location of file", "no, behave the same for all files in the folder" and "none" from what I understand. |
| 03:33:26 | Llorean | Though the last two I've inferred and may be quite wrong about |
| 03:34:18 | Llorean | His patch is "any files", "it is, based on a variety of criteria", "yes", and "criteria for resuming, when to resume, parameters for automatic resuming decisions, parameters for when to store a resume point, etc" |
| 03:36:18 | soap | his opinion, no. He offered, you countered. I think it is polite to explicitly counter and allow him a known to "counter-counter" against. An explicit opportunity to address concerns either through code or argument. As it is now there is no clear consensus statement in the thread. |
| 03:36:19 | | Quit designate72 (Read error: Operation timed out) |
| 03:36:36 | Llorean | soap: I've pretty explicitly described my position in the emails, I thought |
| 03:37:06 | soap | and I don't believe your position is posted as "the answer". That's all I'm asking for. |
| 03:38:09 | Llorean | I have no idea what you mean by that... |
| 03:41:59 | Llorean | Do you want a post that is simply framed as my counter proposal? I did include it in one of my posts, but I haven't posted it explicitly. |
| 03:42:21 | Llorean | I've mostly focused on where I feel there are drawbacks and how I would address them in the hopes that other people might see the difficulties and attempt to address them in other ways. |
| 03:42:26 | | Quit Keripo (Quit: Leaving.) |
| 03:43:08 | soap | <Llorean> Do you want a post that is simply framed as my counter proposal? I did include it in one of my posts, but I haven't posted it explicitly. |
| 03:43:18 | soap | yes, that is all I'm asking. The thread is a mess IMHO. |
| 03:43:38 | Llorean | But I don't think we should be focusing on proposals, but "what we want from this feature" |
| 03:44:07 | Llorean | I don't want it to descend into his idea vs my idea, but rather look at what his idea is trying to address and try to decide if that's what we want to address (if it is, his idea's fine) and if not, then start working on how to address it. |
| 03:44:18 | Llorean | Just throwing out proposals doesn't work well if we haven't yet agreed on what problem to solve. |
| 03:44:42 | saratoga | should i close bug reports about ipod accessories and point them at the wiki or do we take bug reports on those now? |
| 03:45:08 | soap | saratoga, I thought we took them in the one IAP task only. |
| 03:45:46 | soap | since they aren't supposed to be "bugs" but rather dumps of debug information gathered with accessories not owned by the developers. |
| 03:46:15 | soap | (unless there is a regression, which is a situation I haven't seen addressed) |
| 03:47:20 | soap | Llorean, as I see it, it is not just "throwing out proposals", it is steering the debate. |
| 03:48:07 | | Quit sasquatch (Quit: WeeChat 0.3.2) |
| 03:48:32 | | Join sasquatch [0] (~username@p4FF2D6FE.dip.t-dialin.net) |
| 03:51:40 | Llorean | soap: Okay, I've tried to address what I could. |
| 03:52:12 | Llorean | I'd say a regression is a bug. |
| 03:55:25 | soap | yea, I don't know the specifics of what saratoga is asking about. I just recall previously a desire stated to consolidate all IAP info into the IAP task. Lack of support for an previously unknown device can't really be a bug. I was saying that regression, if it popped up, could be though. |
| 03:55:54 | Llorean | Yeah, I don't know if that's how we do it now, but collecting them in one task sounds like a "how we should do it" kind of thing |
| 03:56:22 | saratoga | the one task tells you how to collect debug info, so i guess it makes more sense anyway |
| 03:56:27 | soap | Llorean, I think that's a wonderful email. It consolidates all the points into a single "target" as opposed to responding to bits and pieces here and there. |
| 03:56:28 | saratoga | otherwise the bug reports are kind of useless |
| 03:57:18 | Llorean | soap: See, from my perspective it's the bits and pieces that should be addresses. Whether or not it should be configurable is to an extent an independent point from which files should use it, unless it's decided that which files should be configurable, etc. |
| 03:57:18 | soap | though you might as well called me David Hall since that's the email account I had been using previously. ;) |
| 03:57:23 | Llorean | It's really several features. |
| 03:57:38 | Llorean | Auto resume, auto selection of auto resume files, intelligent resume decisions while playing back. |
| 03:57:51 | soap | you don't see a value in consolidating all those subthreads? |
| 03:58:05 | Llorean | Consolidating them seems to make it a package deal. |
| 03:58:14 | Llorean | I'm not sure it should be treated as a single feature that's all or nothing |
| 03:58:35 | Llorean | I'd almost say we need to explicitly divide it into separate threads after deciding what the actual features are. |
| 03:58:38 | soap | I don't think a single email denotes a single "take it or leave it" feature. |
| 03:58:47 | soap | I just think it organizes the debate. |
| 03:59:21 | Llorean | Possibly. I think it frames the debate. "We're talking about a whole thing here" |
| 03:59:31 | soap | and, yea, let it split up once the "terms of debate" are agreed upon. |
| 04:00 |
| 04:00:05 | soap | I see it as "regrouping and refocusing" after a fragmented conversation. |
| 04:00:13 | Llorean | That makes sense. |
| 04:00:34 | Llorean | I think what it *is* depends on how the other people in the discussion respond to it though. :-P |
| 04:03:02 | | Quit InsDel (Read error: Connection reset by peer) |
| 04:07:30 | | Quit MethoS- (Remote host closed the connection) |
| 04:09:28 | soap | now we can wait and see. ;) |
| 04:13:00 | *** | Saving seen data "./dancer.seen" |
| 04:13:48 | | Join DerPapst1 [0] (~Alexander@p5DE5A163.dip.t-dialin.net) |
| 04:14:51 | | Quit DerPapst (Ping timeout: 240 seconds) |
| 04:20:17 | | Quit krabador (Quit: Sto andando via) |
| 04:22:28 | | Join Llorean1 [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 04:22:32 | scorche | soap: when was it supposedly deleted? |
| 04:22:33 | | Quit Llorean1 (Client Quit) |
| 04:22:39 | | Join Llorean1 [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 04:22:54 | soap | saratoga, answered the question. Thanks, though. |
| 04:23:26 | | Quit Llorean (Disconnected by services) |
| 04:23:31 | | Nick Llorean1 is now known as Llorean (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) |
| 04:23:34 | | Quit Llorean (Changing host) |
| 04:23:34 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 04:25:30 | | Quit crwl (Ping timeout: 240 seconds) |
| 04:27:24 | | Quit amiconn (Disconnected by services) |
| 04:27:24 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:27:24 | | Quit pixelma (Disconnected by services) |
| 04:27:26 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:27:29 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:27:42 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:30:58 | | Join factor_ [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:31:04 | | Quit TheSeven (Ping timeout: 250 seconds) |
| 04:31:33 | | Quit factor_ (Remote host closed the connection) |
| 04:32:12 | | Join factor__ [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:33:13 | | Quit factor__ (Read error: Connection reset by peer) |
| 04:33:24 | | Join factor_ [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:35:46 | | Quit factor_ (Read error: Connection reset by peer) |
| 04:35:55 | | Join icarusfactor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:35:57 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 04:37:00 | | Quit icarusfactor (Remote host closed the connection) |
| 04:37:32 | | Join Barahir [0] (~jonathan@frnk-590f65ec.pool.mediaWays.net) |
| 04:38:12 | | Join icarusfactor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:39:53 | | Part icarusfactor |
| 04:40:36 | | Quit Barahir_ (Ping timeout: 250 seconds) |
| 04:45:31 | | Quit MortalScan_Troll (Ping timeout: 240 seconds) |
| 04:50:03 | | Join icarusfactor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:51:01 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 04:51:05 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 04:51:30 | | Quit icarusfactor (Client Quit) |
| 04:51:53 | | Quit panni_ (Read error: Connection reset by peer) |
| 05:00 |
| 05:04:59 | | Quit DerPapst1 (Quit: Leaving.) |
| 05:15:57 | | Join CaptainKewl [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 05:23:25 | | Join LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net) |
| 05:23:27 | | Quit LambdaCalculus37 (Changing host) |
| 05:23:27 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 05:27:03 | LambdaCalculus37 | Would anyone have any objections if I lowered the default contrast for the iPod 3G down from 50 to 35? It's very hard to see the LCD straight on with that high of a contrast setting by default. |
| 05:27:25 | JdGordon | not at this time of day |
| 05:28:26 | LambdaCalculus37 | JdGordon: I know, most everyone's asleep by now. |
| 05:32:38 | saratoga | make sure theres only 1 kind of screen, IIRC some of the defaults are chosen as a compromise between screen types on the ipods |
| 05:34:09 | Llorean | LambdaCalculus37: Too dark or too light? |
| 05:34:18 | Llorean | I can never remember if higher numbers on mono means more or less black |
| 05:34:19 | LambdaCalculus37 | Llorean: Too dark. |
| 05:34:39 | Llorean | It may be one of the compromises saratoga mentioned then |
| 05:37:23 | | Quit Rob2222 (Ping timeout: 250 seconds) |
| 05:38:12 | LambdaCalculus37 | Llorean: in firmware/target/arm/ipod/lcd-gray.c, the greyscale iPods have #defines for each target (start from line 73). |
| 05:38:52 | Llorean | LambdaCalculus37: Yeah, but I seem to recall some people with one of the grayscale iPods (and I *really* want to say 3G) having the screen completely white and unreadable |
| 05:39:05 | Llorean | I'd check when that contrast value was set and see if there commit message clarifies things |
| 05:39:38 | Llorean | LambdaCalculus37: Some of the iPods have multiple screen types that aren't distinguished in code or necessarily distinguishable, I think |
| 05:41:22 | LambdaCalculus37 | The last revision to the file was r26208 by torne, and it was to increase the default contrast of the iPod 3G. |
| 05:42:31 | Llorean | It'd probably be nice to know how apple gets the contrast right between versions |
| 05:46:11 | saratoga | theres some way to check which screen different ipods have and then adjust the defaults |
| 05:46:27 | saratoga | IIRC some of the older ipods do this, as does the nano2g |
| 05:47:56 | LambdaCalculus37 | At least torne mentioned this wasn't the best fix in the comment; I quote: "It seems there is some significant variance between different greyscale ipods of the same model, so it's unlikely that *any* value will be great for everyone. I'm hoping that this is just high enough that the lightest screens aren't totally blank, but not dark enough that the darkest screens are entirely unreadably black ;) |
| 05:47:56 | LambdaCalculus37 | " |
| 05:48:22 | LambdaCalculus37 | Except that I got an iPod 3G where the default contrast was just too dark. |
| 05:58:06 | saratoga | http://www.rockbox.org/wiki/IpodHardwareInfo#Basic_hardware_comparison |
| 05:58:19 | saratoga | i guess you could find someone with a different LCD contrast setting and ask them for their hardware revision number |
| 05:59:03 | LambdaCalculus37 | saratoga: Ahh, good call. |
| 05:59:29 | * | LambdaCalculus37 checks his |
| 06:00 |
| 06:00:00 | LambdaCalculus37 | HW rev: 0x00030001; PP version: PP5002D |
| 06:00:44 | Llorean | LambdaCalculus37: If you could tilt it and read it, I think that's not "entirely unreadably black" (in the sense that my impression of the white screens was that some couldn't be seen at all without use of the voice interface or a hand written .cfg to fix them) |
| 06:04:47 | saratoga | same revision i have, mine needs a contrast around 35 to look good |
| 06:05:36 | LambdaCalculus37 | saratoga: I set mine to 35 as well. |
| 06:06:18 | saratoga | IIRC amiconn had the other kind |
| 06:06:53 | LambdaCalculus37 | amiconn: (for the logs) Can you check your iPod 3G and tell me what the HW revision of it is? |
| 06:10:19 | | Quit JesusFreak316 (Ping timeout: 240 seconds) |
| 06:13:02 | *** | Saving seen data "./dancer.seen" |
| 06:15:28 | LambdaCalculus37 | saratoga: In the meantime, I'm going to post a patch to change the default contrast back to 35 for the iPod 3G on Flyspray. |
| 06:16:19 | | Quit the_Kyle (Ping timeout: 240 seconds) |
| 06:19:31 | saratoga | i don't think you need to post a patch for that |
| 06:20:37 | * | LambdaCalculus37 cancels his post |
| 06:20:43 | saratoga | you could probably just look at FS #11034 if you somehow forgot what the number was |
| 06:26:16 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) |
| 06:32:51 | | Join the_Kyle [0] (~kyle@71.23.64.127) |
| 06:34:14 | | Quit [Saint] (Disconnected by services) |
| 06:34:16 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.224) |
| 06:48:07 | | Join Curulan [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 06:49:32 | CIA-45 | New commit by saratoga (r28841): Commit FS #11810 by Alexander Meshcheryakov. Boosts the CPU and limits LCD update rate while recursively scanning files in the properties plugin, ... |
| 06:51:38 | | Quit Zarggg_ (Ping timeout: 260 seconds) |
| 06:51:51 | CIA-45 | r28841 build result: All green |
| 06:54:28 | | Quit saratoga (Quit: Page closed) |
| 06:55:08 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 06:57:18 | | Quit amee2k (Ping timeout: 255 seconds) |
| 06:58:57 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 07:00 |
| 07:00:53 | | Quit ReimuHakurei_ (Quit: BRB FBI) |
| 07:01:08 | | Join ReimuHakurei [0] (~reimu@74.112.212.15) |
| 07:44:28 | | Quit factor (Ping timeout: 276 seconds) |
| 07:52:24 | | Join Horscht [0] (~Horschti@p4FD4CBC7.dip.t-dialin.net) |
| 07:52:24 | | Quit Horscht (Changing host) |
| 07:52:24 | | Join Horscht [0] (~Horschti@xbmc/user/horscht) |
| 07:54:43 | | Quit Horschti (Ping timeout: 240 seconds) |
| 07:57:06 | | Join bmbl [0] (~bmbl@unaffiliated/bmbl) |
| 07:57:36 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 07:59:36 | amiconn | Llorean: SDXC is probably backwards compatible hardware wise, but the sd* standards also specify the file system to use (which is silly, imo) |
| 08:00 |
| 08:00:25 | amiconn | SDXC specifies exFAT - which rockbox doesn't support, and neither does linux afaik |
| 08:01:12 | amiconn | etoolongscrollback |
| 08:02:41 | | Join esperegu [0] (~quassel@145.116.15.244) |
| 08:06:21 | eWill | I think there's something wrong with the manual (pdf format). Searching for the word "shuffled" returns zero results; Copy (from the manual) the word "shuffled", then paste and the word "shued" is pasted; search for "shued" returns all instances of "shuffled". |
| 08:07:09 | eWill | I'm using Foxit pdf reader. |
| 08:08:07 | | Join Keripo [0] (~Keripo@eng146.wireless-resnet.upenn.edu) |
| 08:10:33 | amiconn | LambdaCalculus37: I don't have a 3G, only a 1G and a 2G |
| 08:10:41 | eWill | could someone just try searching for the word "shuffled" and see if it works for them? |
| 08:11:02 | | Quit LambdaCalculus37 (Quit: This computer has gone to sleep) |
| 08:11:14 | amiconn | Default contrast on the greyscale ipods is a real problem, as different hw revisions require different contrast values |
| 08:13:03 | amiconn | These revisions are not only dependent on the hw revision value; at least for some models gpio checks are necessary. Unfortunately I lost the respective rom routine code :\ |
| 08:13:06 | *** | Saving seen data "./dancer.seen" |
| 08:13:30 | amiconn | I still have the table, but not the code that accesses it |
| 08:13:57 | | Quit Keripo (Quit: Leaving.) |
| 08:15:09 | eWill | File browser Hotkey is not working right (I think). If set to "Insert", it inserts, but moves you to the WPS −− this isn't meant to be is it? |
| 08:17:57 | the_Kyle | I believe if you're inserting a single file, you are moved to the WPS, but if you already have a file playing, you stay in the file browser when you insert another. |
| 08:18:28 | eWill | then it's broken |
| 08:19:10 | the_Kyle | This is the same functionality I get if I select insert from the playlist menu if nothing is playing. |
| 08:19:40 | eWill | and it does the same thing if a song _is_ playing −− right? |
| 08:20:18 | the_Kyle | No. I believe it keeps you in the file browser if a song is playing. I'm checking just to be sure. |
| 08:22:13 | | Join Keripo [0] (~Keripo@fkb015.wlan.vpul.upenn.edu) |
| 08:22:35 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 08:22:48 | the_Kyle | Confirmed. If nothing is playing and I select insert from the playlist menu, I am taken to the WPS and the song begins to play. While that song is playing, if I go to the file browser and repeat the same steps, the next song is inserted and I am still in the file browser. Hotkey is the same. |
| 08:23:34 | eWill | what target? |
| 08:23:39 | the_Kyle | Clip+ |
| 08:24:13 | the_Kyle | But I suspect this functionality would be the same on all targets. |
| 08:26:06 | eWill | the_Kyle: it's even doing this on the sim |
| 08:26:43 | the_Kyle | I think it's the same on all targets. Try a different sim to confirm. |
| 08:27:10 | the_Kyle | This is core, so shouldn't change on a different target as far as I know. |
| 08:27:49 | | Quit Keripo (Quit: Leaving.) |
| 08:28:17 | the_Kyle | It would seem that the desired behavior would leave us in the file browser unless we hit the WPS key, even if nothing is playing. |
| 08:28:18 | | Join sideral [0] (~sideral@unaffiliated/sideral) |
| 08:28:19 | | Quit BHSPitMonkey (Read error: Connection reset by peer) |
| 08:29:31 | the_Kyle | Also, stopping playback with the power button while in the file browser shouldn't back us up to the parent directory also, but that's probably unrelated. |
| 08:35:04 | eWill | I just build the Ipod Video. I don't think it has a "Home" key. Do most targets have one? |
| 08:36:34 | eWill | *built |
| 08:36:56 | the_Kyle | I'm not sure about ipod video. I think most targets do, but I'm only familiar with clip+ because it's the player I have. |
| 08:37:44 | the_Kyle | Keys on different targets will most likely map differently. |
| 08:39:20 | the_Kyle | For example, the clips have wps and browser hotkeys mapped, but the define is commented out. I had to customize my build to get the hotkeys. |
| 08:39:23 | eWill | the_Kyle: I tried all the buttons. So the clip+ is running. I don't see a Hotkey setting in the menu....? |
| 08:39:53 | eWill | you just answered me |
| 08:40:24 | | Quit Judas_PhD (Remote host closed the connection) |
| 08:40:42 | the_Kyle | uncomment #define HAVE_HOTKEY and rebuild. WPS hotkey is mapped to down repeat and browser hotkey is unmapped if I recall. |
| 08:40:54 | | Quit esperegu (Remote host closed the connection) |
| 08:41:07 | | Quit liar (Ping timeout: 240 seconds) |
| 08:41:19 | the_Kyle | I remapped both hotkeys to home+up. Works quite nicely here, and is finger friendly. |
| 08:41:37 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 08:42:04 | the_Kyle | Keymap is in apps/keymaps/keymap-clip.c |
| 08:42:53 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 08:42:55 | the_Kyle | I'm not sure if remapping the hotkeys or uncommenting the #define will work on the sim though. I only tried it on a real clip+. |
| 08:44:48 | * | the_Kyle doesn't know why the hotkeys are left undefined in the clips. All I've gotten is guesses about running out of buttons so far, but I'm using unmapped combinations. |
| 08:46:42 | | Join kevku [0] (~kevku@2001:7d0:0:f000::135d) |
| 08:47:40 | * | the_Kyle forgot to mention that the #define that needs to be uncommented is the last line of firmware/export/config/sansaclipplus.h. |
| 08:47:50 | eWill | the_Kyle: would you mind uploading your keymap-clip.c? |
| 08:48:20 | the_Kyle | eWill: Not a problem. Where should I upload? |
| 08:48:29 | eWill | pastebin.ca? |
| 08:50:25 | | Join Guest83802 [0] (~bjst@rockbox/developer/Zagor) |
| 08:51:11 | eWill | or anywhere |
| 08:52:08 | | Nick Guest83802 is now known as Zagor (~bjst@rockbox/developer/Zagor) |
| 08:52:32 | the_Kyle | It says it filtered 6 characters. something about being outsie of ascii text guidelines or something. Here's hoping it works. |
| 08:53:18 | eWill | link? |
| 08:53:35 | * | the_Kyle is waiting for the link. |
| 08:53:55 | the_Kyle | Browser is stuck. |
| 08:54:30 | the_Kyle | it tole me the connection was reset. Trying again. |
| 08:54:32 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:54:32 | | Quit bertrik (Changing host) |
| 08:54:32 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 08:55:47 | the_Kyle | eWill: http://pastebin.ca/2021030 |
| 08:56:22 | * | the_Kyle hopes it got the whole file. |
| 09:00 |
| 09:02:48 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 09:03:56 | the_Kyle | eWill: Be sure to uncomment #define HAVE_HOTKEY in firmware/export/config/sansaclipplus.h. If this line stays commented, you still won't see a hotkey menu in your sim. |
| 09:04:08 | eWill | i did. thanks |
| 09:06:13 | eWill | the_Kyle: |
| 09:06:30 | eWill | the clip+ BMP doesn't have lables on the keys |
| 09:07:23 | eWill | i didn't mean to type your name with no text after it |
| 09:07:32 | the_Kyle | Not a problem |
| 09:07:47 | * | the_Kyle is visually impaired, so was unaware of bmp issues. |
| 09:08:35 | * | the_Kyle uses voice functions and knows where buttons are by touch. |
| 09:08:52 | eWill | what did you say you mapped the file browser hotkey to? |
| 09:09:12 | the_Kyle | Both file browser and wps are mapped to home+up. |
| 09:09:23 | the_Kyle | or home+play. |
| 09:10:34 | eWill | the_Kyle: |
| 09:10:49 | eWill | what does your home key do on WPS? |
| 09:10:54 | eWill | by itself |
| 09:11:37 | the_Kyle | It takes you to the menu. Holding it takes you to the quick screen. |
| 09:16:54 | eWill | the_Kyle: ok I figured out the keys. 8 = up, * = home. (you have to hold * first to get hotkey to work!). Conclusion: same thing as my real Fuze v2 −− hotkey inserts, but takes me to WPS (even if song is playing). |
| 09:18:07 | * | the_Kyle checks with hotkey on my clip+. I thought it worked the same as using the menu. |
| 09:19:54 | the_Kyle | Confirmed. Hotkey is always going to wps here. |
| 09:20:24 | the_Kyle | Menu function, however, goes to wps only if no song is playing. |
| 09:22:01 | * | the_Kyle thought both context/playlist/insert and hotkey insert called the same function, but it seems they are slightly different. |
| 09:22:48 | * | eWill is still glad for info he got on how to remap keys −− something he's been wanting to explore |
| 09:23:33 | | Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )) |
| 09:23:45 | the_Kyle | Not a problem. I'm not that moch of a programmer, and I found the keymapping to be very easy to understand. |
| 09:23:50 | the_Kyle | much* |
| 09:26:02 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 09:26:19 | eWill | I'm trying to build the sim in Cygwin: simdisk/.rockbox: No such file or directory at /home/will/rockbox/tools/buildzip.pl line 129 |
| 09:27:39 | the_Kyle | Hmm. I'm not at all sure about that one. |
| 09:28:12 | the_Kyle | I'm running mine on Linux. I did make fullinstall for the sim. |
| 09:28:38 | * | the_Kyle isn't sure that made a difference. |
| 09:28:50 | the_Kyle | fullinstall doesn't work on a real player. |
| 09:29:31 | the_Kyle | But if I remember correctly, fullinstall is what creates simdisk. |
| 09:29:34 | eWill | you have to use fullinstall on the sim. |
| 09:30:06 | the_Kyle | And fullinstall is giving you the buildzip error? |
| 09:30:21 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 09:30:25 | | Quit bertrik (Ping timeout: 276 seconds) |
| 09:31:18 | the_Kyle | Are you building inside of your source tree, or did you create a different build directory? |
| 09:31:21 | eWill | yeah. I'm now running Cygwin install to reinstall zip and unzip...? |
| 09:31:30 | eWill | new build dir |
| 09:31:49 | the_Kyle | Everything looks good, unless you have a missing package. |
| 09:32:38 | pixelma | you have to use "make install" but not "fullinstall". The difference is that "fullinstall" adds the complete list of fonts, "install" just the ones needed by included themes |
| 09:33:38 | the_Kyle | pixelma: Thanks. Sounds like that could solve eWill's problem. |
| 09:33:59 | wodz | ehh, I just spotted another software i2c implementation in our tree :/ |
| 09:34:01 | pixelma | well, you need to zip and unzip anyway |
| 09:34:10 | wodz | TheSeven: ping |
| 09:34:11 | pixelma | be able to |
| 09:34:17 | | Join petur [0] (d408b802@rockbox/developer/petur) |
| 09:34:38 | the_Kyle | This is true. If zip and unzip are missing, nothing will work. |
| 09:35:09 | | Part sideral |
| 09:35:36 | eWill | I already had zip and unzip, but reinstalled, and just ran "make install" −− same problem. You DO run "make" first −− right? |
| 09:36:00 | the_Kyle | eWill: Yes. Make and then make install. |
| 09:37:32 | eWill | buildzip.pl line 129: if ((!$app) && $src && (abs_path($bindir) eq abs_path($src))) { |
| 09:39:45 | * | the_Kyle wonders why it seems to be complaining about simdisk/.rockbox when it's supposed to be creating this tree. Stupid question, but are you still in the build dir when you do make and make install? |
| 09:40:49 | eWill | yeah |
| 09:40:51 | * | the_Kyle knows little to nothing about cygwin. |
| 09:41:32 | * | the_Kyle is a Linux fanboy, so is pretty much stumped at this point. |
| 09:42:57 | the_Kyle | Do you have a simdisk directory inside your build dir at all? |
| 09:43:07 | the_Kyle | Did it get that far? |
| 09:43:54 | eWill | yeah, but I just deleted everything in the build dir and am trying again. |
| 09:44:10 | the_Kyle | When in doubt... |
| 09:48:26 | | Join pamaury [0] (~quassel@dhcp-129-228.residence.ens-lyon.fr) |
| 09:48:29 | | Quit pamaury (Changing host) |
| 09:48:29 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 09:50:42 | eWill | if you configure chose your target, and select (S)imulator. In _Cygwin_ does that build a windows or linux binary? |
| 09:51:10 | pixelma | it should build a Windows binary |
| 09:53:31 | pixelma | I wonder if you somehow aren't allowed to create a hidden directory (one with a . in front) in your case. Building sims in cygwin definitely worked for me but I'll try with an updated source tree now, will take some time |
| 09:53:59 | eWill | Installing your build in your 'simdisk' dir |
| 09:54:01 | eWill | simdisk/.rockbox: No such file or directory at /home/will/rockbox/tools/buildzip.pl line 129 |
| 09:54:02 | eWill | make: *** [install] Error 9 |
| 09:56:18 | the_Kyle | In Windows, hidden files and directories use a special hidden file attribute. I believe the only potential problem is that files and directories that start with a dot are not hidden unless the hidden attribute is set in the filesystem. The file or directory should be created successfully. |
| 09:56:57 | the_Kyle | I could be wrong, however, since the last version of Windows I used was XP. What version are you running? |
| 09:57:33 | eWill | win7 x64 |
| 09:58:26 | the_Kyle | That may explain things somewhat, considering that the filesystem is different on 7 as far as I know. It was supposed to be more flexible though, not less. |
| 09:59:33 | pixelma | maybe some 64bit thing, I can only test 32bit and am currently running a test on XP so maybe results differ |
| 09:59:48 | eWill | I can run the sim, but (in the sim window) it says, "no .rockbox directory" "installation incomplete", while the console output is: |
| 09:59:51 | eWill | Can't open font: /.rockbox/fonts/12-Adobe-Helvetica.fnt |
| 09:59:52 | eWill | read_bmp_file: can't open '/.rockbox/icons/tango_small.bmp', rc: -1 |
| 09:59:54 | eWill | read_bmp_file: can't open '/.rockbox/icons/tango_small_viewers.bmp', rc: -1 |
| 09:59:56 | eWill | read_bmp_file: can't open '/.rockbox/backdrops/cabbiev2.bmp', rc: -1 |
| 10:00 |
| 10:00:37 | the_Kyle | Try creating the .rockbox directory under simdisk and try make install again. See if Windows itself gives you an error. |
| 10:01:38 | pixelma | those are not fatal errors, I wonder though why it wants something about backdrops as the monochrome screens can't have them at all |
| 10:01:53 | eWill | oh i'm building the fuze |
| 10:02:12 | eWill | i built the clip+ in a linux VM |
| 10:02:18 | the_Kyle | pixelma: The errors are just being generated because there's no .rockbox directory at all. |
| 10:02:40 | TheSeven | wodz: gnip |
| 10:02:42 | eWill | there _is_ a .rockbox dir, and all three of those files are present |
| 10:03:21 | eWill | the_Kyle: re-creating the .rockbox dir didn't work. |
| 10:03:51 | pixelma | then it may be a file permission problem, could you check it on the .rockbox folder? |
| 10:03:53 | eWill | all *4* of those files |
| 10:04:05 | * | the_Kyle is truly stumped now. The assumption was that the directory didn't exist. Since it does, and it says it doesn't we have a very strange problem indeed. |
| 10:04:06 | pixelma | or the individual files |
| 10:04:51 | the_Kyle | If it's a file permission problem, it should say "permission denied" rather than "no such file or directory." |
| 10:05:07 | wodz | TheSeven: You said nobody took photos of codec die used in ipod classic. I think I have access to equipment needed to do such things (although I never did this before) |
| 10:05:11 | eWill | pixelma: ah. I clicked on "Security" for .rockbox: "The permissions on .rockbox are incorrectly ordered, which may cause some entries to be ineffective." |
| 10:05:35 | the_Kyle | Well, I was about to say it is worth a look. |
| 10:05:43 | wodz | I have access to SEM microscope as well as to optical crystalographic one |
| 10:05:56 | wodz | sulfuric acid bath is not the problem either |
| 10:06:26 | TheSeven | i already have someone else who did a few uncaps etc., but who doesn't have a broken ipod board right now |
| 10:06:47 | TheSeven | i'll ask him what kind of equipment he has currently and then get back to one of you |
| 10:06:56 | wodz | ok |
| 10:07:02 | TheSeven | (i have a mechanically damaged ipod classic board lying around) |
| 10:09:53 | pixelma | eWill: I don't know why you end up with such unclean permissions, but I do remember troubles with them too in cygwin. |
| 10:10:33 | wodz | pcf50606 drivers - what a mess |
| 10:10:56 | wodz | touching i2c mean touching half of lowlevel stuff in rb |
| 10:11:10 | | Join ReimuHakurei_ [0] (~reimu@74.112.212.15) |
| 10:11:13 | | Quit ReimuHakurei (Read error: Connection reset by peer) |
| 10:13:07 | *** | Saving seen data "./dancer.seen" |
| 10:13:25 | eWill | what director is being referred to in this: simdisk/.rockbox: No such file or directory at /home/will/rockbox/tools/buildzip.pl line 129 |
| 10:14:52 | eWill | *directory |
| 10:16:23 | the_Kyle | simdisk/.rockbox. But it doesn't specify its parent, so it's usually assumed to be . |
| 10:16:45 | the_Kyle | Should be your build dir. |
| 10:21:29 | | Quit mc2739 (Ping timeout: 260 seconds) |
| 10:33:30 | | Join DerPapst [0] (~Alexander@dslb-088-069-155-236.pools.arcor-ip.net) |
| 10:36:12 | | Quit JdGordon (Ping timeout: 240 seconds) |
| 10:36:15 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 10:37:12 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 10:37:32 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 10:37:43 | | Join n1s [0] (~n1s@nl118-174-240.student.uu.se) |
| 10:37:43 | | Quit n1s (Changing host) |
| 10:37:43 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 10:46:29 | eWill | guys, I feel like an idiot, and I'm really sorry. The .rockbox dir did exist, but it wasn't in /simdisk. So I deleted everything, ran "make && make install", _moved_ .rockbox into /simdisk, re-ran "make && make install", and it worked. (also it moved "/.rockbox" into "/simdisk". |
| 10:47:24 | eWill | the_Kyle pixelma |
| 10:48:45 | eWill | that is: it re-built /.rockbox and moved it into /simdisk. |
| 10:49:20 | | Quit user890104 (Ping timeout: 272 seconds) |
| 10:49:30 | the_Kyle | eWill: Good that you got it working. |
| 10:49:45 | pixelma | cygwin moved it or you did? |
| 10:50:21 | pixelma | btw. I got the same error now in my test build, looks like there is something wrong |
| 10:51:17 | eWill | pixelma: I tried to make, and it was created at root of build dir. I moved it into /simdisk. Now I ran "make && make install" and durring the process it recreated .rockbox at root of build dir, finally moving it to /simdisk. |
| 10:54:07 | eWill | pixelma: so I deleted everything in /simdisk/.rockbox, but left the dir .rockbox. Builds fine. So I guess all you have to do is create /simdisk/.rockbox before you build, and all will work. |
| 10:54:28 | eWill | *italics unintentional |
| 10:54:29 | | Join DX3 [0] (~Dre@92.30.196.196) |
| 10:57:28 | pixelma | no, you shouldn't need to move anything manually and I don't remember seeing the problem before |
| 10:57:38 | | Quit afk (Ping timeout: 250 seconds) |
| 10:58:19 | eWill | I know it's not normal, I'm just giving temporary way to build it. |
| 11:00 |
| 11:00:54 | eWill | also, you don't need to move anything, just create dir "/simdisk/.rockbox" in you build dir before you build. |
| 11:02:27 | pixelma | shouldn't be necessary either, maybe there's a timing problem or so |
| 11:04:25 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 11:05:50 | n1s | or a cygwin problem |
| 11:07:10 | pixelma | it worked before |
| 11:10:22 | eWill | The manual has a bug. In this screencap I selected and copied the word "shuffled" (in bold near the bottom), then pressed CTRL+F and pasted into the white text box you see at the bottom-left. One problem I know is that you can't search for the word "shuffled". http://img153.imageshack.us/img153/9049/clipboardimage1.png |
| 11:11:39 | gevaerts | That's annoying, sure, but I'm not sure if I'd call it a bug |
| 11:11:47 | gevaerts | It's just tex using a nice-looking ligature |
| 11:12:06 | eWill | you mean it's intentional? |
| 11:12:20 | n1s | no, it's an unfortunate side effect |
| 11:12:42 | eWill | So don't bother with a bug report? |
| 11:13:22 | pixelma | some PDF readers deal with it correctly. It's not nice and should be solved as it is hindering a search in the PDF |
| 11:13:38 | pixelma | there already is a similar bug report for "fi" |
| 11:13:51 | pixelma | or was |
| 11:14:10 | eWill | Document Reader in Ubuntu, and Foxit Reader in Windows both fail. |
| 11:14:20 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 11:14:30 | n1s | well, it's more of a bug in the pdf generating tools than in our manual iiuc |
| 11:15:42 | gevaerts | TeX is originally meant for good looking typesetting, not for searching :) |
| 11:15:59 | | Quit JdGordon (Quit: Leaving.) |
| 11:20:06 | pixelma | ok, the bug report was already closed http://www.rockbox.org/tracker/task/9651 - maybe time to reopen it? |
| 11:20:16 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 11:21:33 | gevaerts | Not sure |
| 11:21:46 | gevaerts | That one was about the html version |
| 11:23:09 | pixelma | hmm, yes, saw that now. Maybe the fix for this broke the other? And I'm pretty sure I saw something about "fi" too but can't find it in the tracker now, it may have been in the forums then |
| 11:24:50 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 11:25:02 | | Join InsDel [0] (~haqr.net@unaffiliated/insdel) |
| 11:25:49 | pixelma | ah yes, http://forums.rockbox.org/index.php/topic,25071.0.html |
| 11:26:12 | * | pixelma wonders if bluebroth3r knows more |
| 11:28:07 | pixelma | I also still wonder if my commit this night is worth a backport |
| 11:30:28 | gevaerts | I'd say it's not essential, but since there's zero risk of it breaking anything it can go in if someone does the work :) |
| 11:31:23 | eWill | does "backport" mean insert the change into a previous release? |
| 11:32:19 | gevaerts | No |
| 11:32:40 | gevaerts | It means committing the change to the active release branch, to be included in the next point release |
| 11:33:53 | pixelma | checking in the changes into the release branch for a point release (3.7.X) that should contain bug fixes to 3.7 (in contrast to SVN build which can also contain new features) |
| 11:34:41 | n1s | and new bugs! |
| 11:35:03 | pixelma | never! ;) |
| 11:37:56 | wodz | Do we have datasheet for pcf5060x series? I found only for pcf50603 but it is incomplete (lacking register map). |
| 11:38:40 | | Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) |
| 11:38:41 | wodz | the comment in pcf5060x.h says v2.2 is available somehow |
| 11:39:54 | wodz | found :-) |
| 11:44:48 | pixelma | it's possible that the problem with the .rockbox dir in cygwin exists for longer and I never noticed as I always build in the same folders and only do a "make clean" in the worst case and this doesn't touch the simdosk dir structure (and shouldn't) |
| 11:45:51 | pixelma | well, I do build some other sims (other targets) in new folders from time to time so it can't be soo long ago |
| 11:47:36 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
| 11:51:11 | | Nick Sudos_ is now known as Sudos (~windstar_@c-68-38-20-238.hsd1.nj.comcast.net) |
| 11:51:12 | | Quit cozmic (Read error: Connection reset by peer) |
| 11:51:14 | | Join cozmic_ [0] (cozmic@89-160-133-29.du.xdsl.is) |
| 11:57:12 | | Quit factor (Quit: Leaving) |
| 12:00 |
| 12:02:10 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 12:03:01 | eWill | File browser hotkey > Insert: takes you immediately to WPS. There is a patch shouldn't (think it needs resynced) it be commited?: http://www.rockbox.org/tracker/task/11344 |
| 12:08:27 | Torne | LambdaCalculus37: please don't change it back to 35, 35 is totally blank on other ipods, even 45 was unusably pale |
| 12:08:30 | Torne | oh, he's gone |
| 12:08:52 | Torne | we really, really need to work out how to detect the lcd type |
| 12:09:24 | Torne | the problem is the bootloader always uses hte default, with no way of changing it |
| 12:09:36 | Torne | so bootloader errors become impossible to read |
| 12:12:43 | eWill | I'm trying to eliminate the "Refreshing Your Media" from my fuze v2. Would a question about that be concidered RB-related? |
| 12:13:11 | *** | Saving seen data "./dancer.seen" |
| 12:13:27 | n1s | not really |
| 12:23:20 | Torne | you can't in any reasonable or sensible way. wait for the rockbox usb stack to be supported. |
| 12:28:46 | | Quit krazykit (Ping timeout: 272 seconds) |
| 12:30:15 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 12:33:32 | | Quit bmbl (Quit: Verlassend) |
| 12:34:58 | eWill | Torne: all you have to do is delete the ##PORT# dir and fill the device till there is less than 177MB free space (on a 4GB fuze v2). |
| 12:36:50 | Torne | "all you have to do" :) |
| 12:37:16 | Torne | alternatively you could wait until the issues with usb on rockbox are sorted and then the problem no longer exists :) |
| 12:42:16 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 12:42:26 | | Quit LambdaCalculus37 (Remote host closed the connection) |
| 12:43:58 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 12:44:41 | eWill | Torne: I solved my problem. I needed a way to create a file of arbitrary size instantly. Here is the solution for Windows: fsutil file createnew <filename> <size in bytes> Still looking for a *nix solution. |
| 12:45:09 | Torne | dd if=/dev/zero of=somefile bs=1048576 count=numberofmegabytes |
| 12:47:55 | | Quit krazykit (Ping timeout: 260 seconds) |
| 12:47:58 | eWill | Torne: that isn't instant. |
| 12:48:04 | Torne | why would it be? |
| 12:48:11 | Torne | you can't write out a file isntantly |
| 12:48:19 | eWill | you can in Windows |
| 12:48:21 | Torne | no you can't. |
| 12:48:25 | Torne | You can write out a *sparse* file isntantly |
| 12:48:29 | Torne | but that also works on unix |
| 12:48:31 | eWill | i just gave you the command |
| 12:48:35 | Torne | sparse files don't exsit on FAT |
| 12:49:14 | Torne | so that will be instant on NTFS, but take exactly as long as dd on FAT |
| 12:49:31 | | Quit soap (Read error: Connection reset by peer) |
| 12:49:50 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 12:49:53 | Torne | FAT has no concept of a file taking up space unless it contains data |
| 12:50:27 | eWill | dammit |
| 12:51:32 | Torne | It is physically possible, I guess; you would just have to allocate the blocks in the FAT without writing any data into them, and the resulting file would contain whatever happened to be on those sectors of the disk before |
| 12:51:40 | Torne | but that's not what fsutil does |
| 12:52:08 | Torne | it explicitly creates a file cotnaining zeros; on a filesystem with sparseness it can do that without allocating any real blocks, but that also won't solve your problem since a sparse file *doesn't take up any space* |
| 12:52:32 | Torne | a 1GB sparse file of zeros doesn't reduce the available space on the filesystem by 1GB :) |
| 12:53:16 | Torne | i should've picked a smaller number to confirm my belief, also, my stupid card reader is now writing out a bazillion zeros and it doesn't respond to ^C |
| 12:55:18 | | Quit InsDel (Ping timeout: 264 seconds) |
| 12:55:37 | pixelma | reminds me of the good old times when setting the System folder on a c200v1 was the way to prevent the OF's database refresh |
| 12:56:06 | pixelma | or at least shorten it so it only splashes an error message and aborts |
| 12:56:08 | eWill | Torne: CTRL+Break? |
| 13:00 |
| 13:01:42 | | Quit The_Pwny (Quit: Clap on! , Clap off! Clap@#&$NO CARRIER) |
| 13:05:54 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 13:10:23 | | Join xavieran [0] (~xavieran@ppp118-209-175-101.lns20.mel6.internode.on.net) |
| 13:19:25 | | Join earcar [0] (~carmine@93-39-232-82.ip78.fastwebnet.it) |
| 13:24:58 | | Join teru [0] (~teru@KD059133111160.ppp.dion.ne.jp) |
| 13:25:31 | | Quit n1s (Quit: Lämnar) |
| 13:27:35 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 13:31:14 | eWill | File browser hotkey > Insert: takes you immediately to WPS. There is a patch shouldn't (think it needs resynced) it be commited?: http://www.rockbox.org/tracker/task/11344 |
| 13:33:53 | | Join panni_ [0] (hannes@ip-178-203-85-85.unitymediagroup.de) |
| 13:35:24 | | Quit BlakeJohnson86 (Read error: Connection reset by peer) |
| 13:37:17 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 13:37:46 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 13:39:14 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 13:43:06 | | Quit bluebroth3r (Ping timeout: 276 seconds) |
| 13:49:48 | | Join Rob2222 [0] (~Miranda@p4FFF1953.dip.t-dialin.net) |
| 13:50:32 | | Quit TheSeven (Ping timeout: 250 seconds) |
| 13:51:55 | Torne | eWill: looks fairly sensible, but my build machine exploded so I can't easily test/commit anything at present |
| 13:52:06 | Torne | anyone want to check that one out? seems sane |
| 13:52:18 | Torne | er, by that one I mean FS #11344 |
| 13:56:30 | | Join tejas [0] (~tejas@triband-mum-120.61.0.6.mtnl.net.in) |
| 13:57:30 | | Part tejas |
| 14:00 |
| 14:04:38 | | Quit petur (Quit: IT is going to 'fix' this PC.. ;)) |
| 14:08:00 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 14:08:45 | | Quit antil33t (Read error: Connection reset by peer) |
| 14:08:53 | | Join antil33t [0] (~Mudkips@124-197-51-80.callplus.net.nz) |
| 14:09:00 | | Quit factor (Read error: Connection reset by peer) |
| 14:12:43 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 14:13:14 | *** | Saving seen data "./dancer.seen" |
| 14:30:35 | | Quit panni_ (Read error: Connection reset by peer) |
| 14:33:58 | | Join mortalscan [0] (~mortalsca@109.169.55.155) |
| 14:35:48 | | Join bmbl [0] (~bmbl@dsl21-184.pool.bitel.net) |
| 14:35:49 | | Quit bmbl (Changing host) |
| 14:35:49 | | Join bmbl [0] (~bmbl@unaffiliated/bmbl) |
| 14:37:06 | | Join sideral [0] (~sideral@unaffiliated/sideral) |
| 14:45:49 | | Join petur [0] (d408b802@rockbox/developer/petur) |
| 14:46:11 | | Quit sideral (Remote host closed the connection) |
| 14:46:47 | | Join sideral [0] (~sideral@unaffiliated/sideral) |
| 14:49:10 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 15:00 |
| 15:07:16 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 15:39:38 | | Part sideral |
| 15:52:51 | | Quit teru (Quit: Quit) |
| 15:54:10 | | Quit Guest24228 (Read error: Operation timed out) |
| 15:58:27 | | Join madalu [0] (~user@67-197-63-212.rh2.dyn.cm.comporium.net) |
| 15:58:30 | | Quit madalu (Changing host) |
| 15:58:30 | | Join madalu [0] (~user@unaffiliated/madalu) |
| 15:58:38 | | Join Feisar [0] (jljhook@irkki.fi) |
| 15:59:05 | | Nick Feisar is now known as Guest11901 (jljhook@irkki.fi) |
| 15:59:11 | | Part LinusN |
| 16:00 |
| 16:03:21 | | Quit antil33t (Read error: Connection reset by peer) |
| 16:03:31 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 16:04:37 | | Quit DX3 (Quit: I was raided by the FBI and all I got to keep was this lousy quit message!) |
| 16:08:39 | | Join Dreamxtreme [0] (~Dre@92.30.196.196) |
| 16:13:17 | *** | Saving seen data "./dancer.seen" |
| 16:15:26 | | Quit Guest11901 (Ping timeout: 265 seconds) |
| 16:17:01 | | Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
| 16:17:09 | | Quit Guinness (Read error: No route to host) |
| 16:17:10 | | Quit madalu (Remote host closed the connection) |
| 16:32:37 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 16:33:30 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 16:33:57 | | Quit Guinness` (Ping timeout: 240 seconds) |
| 16:39:31 | | Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) |
| 16:40:07 | | Quit evilnick_B (Quit: Page closed) |
| 16:42:14 | saratoga | pictureflow on the Fuze is pretty cool, but its too hard to quit |
| 16:42:29 | saratoga | i got into it and it took me forever to find the rockbox menu's again |
| 16:42:58 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 16:44:52 | | Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
| 16:46:15 | | Part Zagor |
| 17:00 |
| 17:01:35 | | Join eWill_ [0] (~chatzilla@adsl-99-139-148-192.dsl.dytnoh.sbcglobal.net) |
| 17:01:47 | | Join Keripo [0] (~Keripo@eng022.wireless-resnet.upenn.edu) |
| 17:02:45 | | Quit eWill (Ping timeout: 240 seconds) |
| 17:02:47 | | Nick eWill_ is now known as eWill (~chatzilla@adsl-99-139-148-192.dsl.dytnoh.sbcglobal.net) |
| 17:04:40 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
| 17:07:28 | | Join eWill_ [0] (~chatzilla@adsl-76-250-133-54.dsl.dytnoh.sbcglobal.net) |
| 17:07:56 | | Quit eWill_ (Client Quit) |
| 17:08:45 | | Quit eWill (Ping timeout: 240 seconds) |
| 17:18:00 | | Join marines [0] (~marines@marvin.uplink.cz) |
| 17:18:01 | | Quit krazykit (Quit: eat a bag of dicks, at&t) |
| 17:26:02 | pixelma | this change to buildzip http://svn.rockbox.org/viewvc.cgi/trunk/tools/buildzip.pl?r1=28160&r2=28159&pathrev=28160 causes the .rockbox folder to be created directly in your build folder (not in the simdisk subfolder) when compiling in a fresh builddir under cygwin, any idea why this is the case? |
| 17:26:28 | | Quit Keripo (Quit: Leaving.) |
| 17:27:10 | | Join eWill [0] (~chatzilla@adsl-76-250-133-54.dsl.dytnoh.sbcglobal.net) |
| 17:27:53 | eWill | I want to do a battery bench, but drain the player as fast as possible. Does the LCD being on effect the voltage reading much? |
| 17:30:17 | | Join Keripo [0] (~Keripo@eng022.wireless-resnet.upenn.edu) |
| 17:30:29 | Llorean | eWill: If you'd started the battery bench yesterday, you probably would've finished it already. Is there a reason it must be the fastest possible? |
| 17:31:24 | eWill | I don't see a reason to drag it out? Also, I'd like to be awake when it shuts off so I can get a charge into it immediately (lipo). |
| 17:32:03 | Llorean | They don't shutdown at "empty" and it won't take damage if it doesn't get charged for a day after it empties. |
| 17:32:32 | Llorean | They seriously don't expect people to have to know that an empty battery can get damaged and are designed generally to be safe. If you plan to leave it weeks or months without charging after it turns off, that's different. |
| 17:34:22 | Torne | Yeah, as long as you charge it again within about 2-4 weeks it'll be fine. |
| 17:34:41 | Torne | it won't selfdischarge to a dangerous level for probably a month |
| 17:34:47 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 17:34:51 | eWill | I knew they weren't empty, it's good to know i have time. 2-4 weeks. Wow. |
| 17:34:58 | Torne | selfdischarging is *slow* |
| 17:35:12 | eWill | but doesn't it speed up as the voltage lowers? |
| 17:35:27 | Torne | not to a particularly fast speed |
| 17:36:01 | Torne | also the shutoff voltage for a given mp3 player is going to be substantially above the point where the cells are at risk |
| 17:36:13 | Torne | usually ~3.1V or so at least |
| 17:36:47 | Torne | the manufacturer usually guarantees them down to 3.0V |
| 17:36:54 | Torne | and in practise you can go past that a bit without worrying |
| 17:38:05 | | Join krazykit` [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 17:38:21 | | Quit krazykit (Disconnected by services) |
| 17:38:23 | | Nick krazykit` is now known as krazykit (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 17:40:38 | eWill | So do any of you lower your cut-off voltage for your personal player? How much extra time do you get? |
| 17:42:55 | pixelma | I don't think a lot of people do this at all, if there is one person at all |
| 17:43:19 | Torne | The cutoff voltage in rockbox is not to protect the cells |
| 17:43:35 | Torne | It's to make sure there's enough power left to spin up the storage and write out settings and resume position |
| 17:43:44 | Torne | i.e. to ensure a "clean" shutdown instead of a hard poweroff |
| 17:43:47 | eWill | ah |
| 17:44:07 | Torne | If you lower the cutoff voltage all that will happen is it'll run for slightly longer then it'll hard-poweroff when the regulators fail to be able to generate eonugh power from the lowered battery voltage |
| 17:44:20 | Torne | and that'll *still* be some distance away from the danger point for the cell |
| 17:44:37 | Torne | a lipoly that's discharged down to 3.08V or whatever can't power a 3.3V buck regulator any more :) |
| 17:45:50 | Torne | I'm not certain that this is true for *every* target, but certainly the vast majority of them will power themsleves off by simple regulator failure in plenty of time to save the batteries, whatever rockbox does or doesn't do. |
| 17:46:56 | eWill | understood |
| 17:47:34 | Torne | i'm not sure why you are wanting to do a battery bench as fast as possible in the first place, thoguh |
| 17:47:45 | Torne | the point of the battery bench is to determine what a typical runtime for the player is |
| 17:47:56 | Torne | which you'd do by having your normal settings, not ones specifically intended to run it down faster |
| 17:48:29 | Torne | it's not for testing the *battery*, it's for testing the effectiveness of rockbox's power management and the efficiency of our code :) |
| 17:48:39 | eWill | all I need is the voltage levels to build an accurate percentage table for the source code. |
| 17:48:59 | Torne | oh, i see. |
| 17:49:10 | Torne | in which case you want to ideally do something that leaves the battery drain constant |
| 17:49:21 | eWill | true |
| 17:49:25 | Torne | i.e. no playback |
| 17:49:30 | eWill | oops |
| 17:49:32 | Torne | and for maximum efficiency, minimal load as well |
| 17:49:41 | Torne | playback means buffering and the like, which means load fluctuates |
| 17:49:54 | Torne | er, maximum *accuracy* even |
| 17:50:04 | Torne | but the load level probably doesn't matter too much |
| 17:50:18 | Torne | unless the battery is ancient it won't change the measured voltage much |
| 17:50:20 | Llorean | I'd go for high efficiency so that you end up with a lot of readings at each percentage |
| 17:50:34 | Torne | Yeah, so player idle, with backlight off, etc |
| 17:50:49 | Torne | that will unfortunately take much longer |
| 17:50:52 | Torne | but it's more accurate |
| 17:50:54 | Llorean | Maybe idle with backlight on? |
| 17:51:01 | Torne | that's probably ok too |
| 17:51:11 | Torne | but yeah, playback is gonna make the load decidedly lumpy |
| 17:51:19 | Torne | sice it'll have to do loads more work than average every time it rebuffers |
| 17:51:24 | eWill | thank you |
| 17:52:23 | | Join Feisar [0] (jljhook@irkki.fi) |
| 17:52:49 | | Nick Feisar is now known as Guest62744 (jljhook@irkki.fi) |
| 17:58:51 | | Quit Guest62744 (Ping timeout: 265 seconds) |
| 18:00 |
| 18:05:14 | | Quit petur (Quit: Page closed) |
| 18:13:20 | *** | Saving seen data "./dancer.seen" |
| 18:23:03 | | Quit Horscht (Quit: Verlassend) |
| 18:30:43 | | Quit antil33t (Read error: Connection reset by peer) |
| 18:30:53 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 18:42:04 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 18:46:05 | | Join Strife89TX [0] (~cstrife89@207.144.201.128) |
| 18:50:30 | | Join LambdaCalculus37 [0] (~3f74f70d@rockbox/staff/LambdaCalculus37) |
| 18:51:33 | | Quit eWill (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) |
| 18:57:14 | saratoga | would it be possible to make the DSP code insert a single 0 sample whenever pausing so theres no posisbility of a DC offset in rockbox? |
| 18:58:31 | LambdaCalculus37 | b0hoon: (for the logs) Does the GoGear HDD6330 have a car adapter mode? I don't remember off the top of my head of it does. |
| 18:58:56 | saratoga | i think all players have it |
| 18:59:21 | saratoga | it may not actually work as expected though depending on how the bootloaders react to AC power |
| 18:59:51 | LambdaCalculus37 | saratoga: Just wanted to make sure so I can add the option for the manual. |
| 19:00 |
| 19:02:49 | pixelma | I doubt that all players have it, e.g. the Ondio doesn't really charge but give you a way to run off of USB power |
| 19:09:36 | | Quit TheSeven (Ping timeout: 276 seconds) |
| 19:15:44 | pixelma | LambdaCalculus37: if you are lucky and this is something you can in- or exclude based on a feature, then it may already be correct |
| 19:16:55 | LambdaCalculus37 | pixelma: I'll look on my HDD6330 again tonight. |
| 19:19:27 | | Quit mortalscan (Ping timeout: 250 seconds) |
| 19:21:10 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-68-199.tampfl.fios.verizon.net) |
| 19:21:50 | | Quit JesusFreak316 (Remote host closed the connection) |
| 19:25:54 | | Quit efyx (Read error: No route to host) |
| 19:26:07 | | Quit DerPapst (Quit: Leaving.) |
| 19:26:19 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 19:26:32 | | Quit earcar (Quit: earcar) |
| 19:27:04 | | Join mortalscan [0] (~mortalsca@109.169.55.155) |
| 19:29:21 | | Join freddyb [0] (~chatzilla@216.8.239.112.etczone.com) |
| 19:29:25 | | Quit benedikt93 (Quit: updating pchat) |
| 19:29:38 | | Quit LambdaCalculus37 (Quit: we're off to find a shrubbery!) |
| 19:31:07 | | Quit efyx (Read error: Connection reset by peer) |
| 19:32:59 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 19:34:39 | | Join Jerom [0] (~jerome@95.171.147.5) |
| 19:36:04 | | Quit wodz (Ping timeout: 260 seconds) |
| 19:36:30 | | Quit mortalscan (Ping timeout: 265 seconds) |
| 19:39:18 | | Join mortalscan [0] (~mortalsca@109.169.55.155) |
| 19:40:30 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 19:44:07 | | Join Horscht [0] (~Horschti@p4FD4CBC7.dip.t-dialin.net) |
| 19:44:07 | | Quit Horscht (Changing host) |
| 19:44:07 | | Join Horscht [0] (~Horschti@xbmc/user/horscht) |
| 19:44:29 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 19:52:45 | freddyb | Saratoga: I've been running my Fuze at 23.25/23.25MHz and 61/124MHz and it still performs very well. Even mpegplayer is fast enough for me. Give me some time and I'll try to see how much battery life is affected. |
| 19:54:47 | freddyb | I also ran some tests on anti-aliased fonts and it seems that AA fonts render about 50-70% as fast as non-AA fonts. |
| 19:55:50 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-218-251.pools.arcor-ip.net) |
| 19:56:33 | | Nick Rondom_ is now known as Rondom (~rondom@lvps178-77-79-47.dedicated.hosteurope.de) |
| 19:58:09 | | Join DerPapst [0] (~Alexander@p5DE5A76F.dip.t-dialin.net) |
| 20:00 |
| 20:02:55 | Llorean | freddyb: How fast is "fast enough for me"? |
| 20:03:10 | | Join TheLemonMan [0] (~lem0n@ppp-81-129.98-62.inwind.it) |
| 20:03:30 | Llorean | The nice thing about mpegplayer is that there's sample videos on the download server, and you can disable framerate limiting and frame skipping to get relatively clear numbers for how it's performing. |
| 20:04:11 | saratoga | mpegplayer is really fast on the the fuze, so its probably not an issue |
| 20:04:17 | saratoga | APE or AAC+ might be though |
| 20:05:08 | saratoga | freddyb: your test results are interesting because they suggest that boosted performance is extremely poor on the fuze, but unboosted performance is quite good |
| 20:05:26 | Llorean | saratoga: Well, having an actual number can't hurt and only takes a few minutes to test, though. |
| 20:05:47 | freddyb | I tried Dune and got 29.5ish I tried Futurama and got rates from 29 down to 22. Elephant's Dream runs about 30.5 unlimited. |
| 20:06:10 | Llorean | That sounds like barely fast enough then... |
| 20:06:18 | freddyb | I'm not sure why Fututama is slower... |
| 20:06:38 | freddyb | Elephants Dream is really only 24fps, tho. |
| 20:07:05 | Llorean | Yeah, but if the upper limit on framerate is about 30fps, that doesn't give much leeway. |
| 20:07:08 | saratoga | 124 might be a little low, although with a 3 level boost scheme it would be fine IMO |
| 20:07:21 | Llorean | Yeah, with a 3 level boost and 124 being mid-level it's probably okay. |
| 20:07:34 | saratoga | just use higher clock for mpegplayer and ape |
| 20:07:35 | Llorean | I'm just saying, you don't want the maximum speed to be "just barely above realtime" |
| 20:07:40 | freddyb | Saratoga: I should have suspected that memory couldn't keep up with high multiples. |
| 20:07:49 | saratoga | yeah most likely |
| 20:08:26 | freddyb | Llorean: You really don't notice any dropped frames, the audio is unbroken. |
| 20:08:33 | saratoga | this reminds me, mpegplayer on the fuzev2 and other armv5 devices could pretty easily be made faster by just tweaking the armv6 asm code a bit to remove a handful of v6 only instructions |
| 20:10:35 | Llorean | freddyb: With your sample videos maybe, but you should always plan for a little extra leeway, rather than hoping that the slowest you can get the CPU while not being below 29.97 on your test files will be good enough. |
| 20:10:37 | bertrik | I thought the fuze needed a high PCLK (62 MHz) for smooth scrollwheel operation |
| 20:11:09 | Llorean | freddyb: The skipped frames may not be noticeable in futurama, which is animation anyway, but may be more noticeable in other things depending on the distribution of them. |
| 20:11:18 | Llorean | Also, was that the 4:3 or the 16:9 elephant's dream? |
| 20:11:48 | freddyb | This is just my opinion but if I can get more battery life, it's worth it even if I drop a few frames on movies unless it gets to the point that you can visually see lagging or jerking. |
| 20:12:29 | Llorean | freddyb: But you're forcing that decision on others. Generally if we're matching or outperforming the OF we then shouldn't introduce inconvenience or reduced functionality just for battery life. |
| 20:12:43 | freddyb | Llorean: 224x176 469kbps. |
| 20:12:49 | Llorean | What's the fuze's screen? |
| 20:12:55 | Llorean | I thought the fuze was 320x240 |
| 20:13:00 | gevaerts | no |
| 20:13:02 | pixelma | 220x176 |
| 20:13:06 | Llorean | Okay |
| 20:13:15 | Llorean | So it's the 4:3 |
| 20:13:22 | *** | Saving seen data "./dancer.seen" |
| 20:14:50 | freddyb | Llorean: you know that motion pictures are only 24fps? |
| 20:14:58 | Llorean | freddyb: And TV is 29.97 |
| 20:15:05 | gevaerts | TV is 25! |
| 20:15:08 | pixelma | freddyb: I agree that numbers would be better, to me it doesn't sound very comforting |
| 20:15:11 | Llorean | How about "up to 29.97" |
| 20:15:39 | Llorean | I'm all for better battery life, but not at the cost of reducing offered functionality. |
| 20:16:44 | saratoga | Llorean: i think its premature to discuss this since we don't even know if its desirable to reduce the boost clock ... |
| 20:17:10 | saratoga | if it is we can simply use different clocks for mpegplayer, until then its silly to speculate |
| 20:17:51 | gevaerts | It's not just mpegplayer though |
| 20:17:57 | bertrik | saratoga, svn r11765 does already reduce the boosted clock, right? |
| 20:18:11 | Llorean | saratoga: And it's worth bringing up now, since if it's not brought up now what if someone who thinks of this isn't around later? |
| 20:18:27 | gevaerts | It could mean the difference between being able to to use lots of dsp with high-CPU codecs and having to use high-CPU codecs without any dsp |
| 20:18:47 | Llorean | Do we have a way to test_codec with DSP? |
| 20:19:00 | Llorean | Or do we have an assumption like, "faster than realtime by at least X%" that's generally considered good enough? |
| 20:19:08 | saratoga | Llorean: yes we do |
| 20:19:45 | saratoga | bertrik: yes |
| 20:19:56 | gevaerts | There's a difference between "good enough" and "still better than some other players, but worse than last week" |
| 20:21:18 | Llorean | I just caught the language of "fast enough for me" and thought that it should be discussed what fast enough is for different people. |
| 20:21:29 | Llorean | Since without a discussion of it at some point, it may not come up at a later discussion of the patch. |
| 20:21:32 | saratoga | this has actually been discussed quite a few times |
| 20:21:57 | saratoga | gevaerts: yes but its not really an issue |
| 20:22:36 | gevaerts | saratoga: for people who play APE with five EQ bands in use, crossfeed, and pitch adjustment, it is :) |
| 20:22:43 | saratoga | no that should still work |
| 20:23:12 | saratoga | c3000 with 5 EQ bands should still be fine, and c4000 won't work now anyway |
| 20:23:18 | Llorean | As long as the ability for mpegplayer to get the speed it needs to playback consistently is in place before a slowdown is implemented that would otherwise make it likely to drop below the framerate of the videos I'm happy. |
| 20:23:25 | gevaerts | ok then |
| 20:23:40 | saratoga | 5 EQ bands is like 15 MHz |
| 20:23:49 | Llorean | But as long as the player's physically capable of playing video without dropped frames, I can't see it as being reasonable to make it do so without extremely significant battery life gains (or being in an extremely poor battery life position to begin with) |
| 20:24:00 | saratoga | but really if we're going to have another boost level for mpegplayer might as well have it for ape too |
| 20:24:19 | Llorean | By "do so" I meant "drop frames" just to clarify |
| 20:24:30 | gevaerts | Switching to a different boosted level for specific cases shouldn't be too hard I think |
| 20:24:40 | gevaerts | A lot easier than a generic multi-level boost anyway |
| 20:24:57 | saratoga | amiconn had other ideas, but I wanted to just have a codec and plugin API call that increases the boost clock |
| 20:25:06 | saratoga | since its simple |
| 20:25:21 | Llorean | Seems like a good idea. |
| 20:25:32 | * | gevaerts nods |
| 20:25:53 | saratoga | e.g. APE calls ci->boost_high(true) which either increases the boost clock or evaluates to a NOP if the device only has 2 levels |
| 20:25:58 | pixelma | do more boost levels really gain this much in everyday use? |
| 20:26:13 | | Join Feisar [0] (jljhook@irkki.fi) |
| 20:26:22 | pixelma | I just wonder if it's really worth it |
| 20:26:25 | saratoga | pixelma: funny you ask, I suggested we check if that was the case before arguing about this |
| 20:26:40 | | Nick Feisar is now known as Guest75111 (jljhook@irkki.fi) |
| 20:26:51 | | Part marines |
| 20:27:10 | saratoga | but basically we've been sitting on this idea for 3 years now because we never had any evidence that it was worthwhile on any hardware |
| 20:27:28 | saratoga | although i suspect it will be on the AMS players and possibly the Nano2G |
| 20:27:32 | Llorean | saratoga: Aren't gains (generally) from decreasing unboosted speed in many cases? |
| 20:27:53 | saratoga | in this case they'd be from running the CPU clock at a lower multiple of the memory clock |
| 20:28:07 | saratoga | where its more efficient (theoretically) |
| 20:29:11 | freddyb | bertrik: Scrollwheel seems fine at low clocks. |
| 20:29:38 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 20:29:49 | bertrik | oh maybe it was the e200v2, ask kugel |
| 20:30:09 | saratoga | aren't the e200v2 and fuzev1 identical with respect to the scroll wheel? |
| 20:33:24 | saratoga | heh dsp_arm.S isn't scheduled correctly for anything but ARM7 |
| 20:34:00 | | Quit Strife89TX (Quit: Leaving briefly.) |
| 20:34:38 | saratoga | if the EQ can use 16 bit coefficients it can also be massively faster on arm9E |
| 20:34:53 | saratoga | but i guess its already about 2MHz per EQ band so maybe theres not much point in speeding it up more |
| 20:35:38 | freddyb | test_codec is not affected by audio settings, right? |
| 20:35:54 | saratoga | depends which option you choose |
| 20:35:59 | saratoga | the DSP one is, the regular one is not |
| 20:37:16 | | Quit Keripo (Quit: Leaving.) |
| 20:38:22 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 20:41:38 | freddyb | Is there already a way to do a battery bench for mpegplayer? |
| 20:45:06 | | Join InsDel [0] (~haqr.net@unaffiliated/insdel) |
| 20:46:03 | CIA-45 | New commit by saratoga (r28842): Avoid an obvious stall on everything newer then arm7tdmi. Note: this can probably be made a lot faster on newer arm targets. |
| 20:46:19 | freddyb | One reason I was looking at a lower top frequency was that I wanted to improve battery life for video. |
| 20:46:26 | saratoga | can't mpegplayer repeat? |
| 20:46:37 | | Quit Dreamxtreme (Read error: Connection reset by peer) |
| 20:46:38 | saratoga | FWIW I doubt you'll see much improvement, battery life in video is dominated by the screen |
| 20:47:23 | | Join Dreamxtreme [0] (~Dre@92.30.196.196) |
| 20:47:27 | | Quit Dreamxtreme (Read error: Connection reset by peer) |
| 20:47:56 | * | TheSeven wonders who/what broke the nano2g headphone detection |
| 20:48:03 | CIA-45 | r28842 build result: 5 errors, 0 warnings (saratoga committed) |
| 20:48:07 | saratoga | damn it preglow needs to get online so i can ask him how this EQ works |
| 20:48:48 | saratoga | gonna guess my change to arm ASM didn't really break the ipod simulator |
| 20:49:28 | gevaerts | It does seem unlikely |
| 20:49:46 | saratoga | yeah just some random build glitch as far as I can tell |
| 20:51:45 | gevaerts | Still weird |
| 20:52:34 | saratoga | this EQ asm makes arm11 sad |
| 20:53:20 | gevaerts | oh |
| 20:53:30 | gevaerts | It's not actually broken... |
| 20:54:00 | gevaerts | It's just that those note: lines make the build system think that something went wron |
| 20:54:04 | gevaerts | g |
| 20:54:26 | CIA-45 | New commit by theseven (r28843): Fix headphone detection on iPod Nano 2G being inverted (regression from r28800) |
| 20:56:22 | CIA-45 | r28843 build result: 10 errors, 0 warnings (theseven committed) |
| 20:56:52 | * | TheSeven pokes Stummi |
| 20:56:58 | TheSeven | what on earth is this compiler doing? |
| 20:57:14 | gevaerts | nothing |
| 20:57:20 | * | gevaerts is fixing it |
| 20:57:27 | TheSeven | but why does it output these lines? |
| 20:57:40 | TheSeven | i don't think anyone has asked it where those things are defined... |
| 20:57:41 | gevaerts | gcc 4.3 outputs those apparently |
| 20:57:55 | * | gevaerts reproduced it locally |
| 20:58:09 | TheSeven | notes about symbols being defined, with no apparent reason *why* it's saying that? |
| 20:58:19 | CIA-45 | New commit by gevaerts (r28844): Ignore note: lines that some gcc versions like to output |
| 20:58:40 | gevaerts | I hope that's correct... |
| 20:59:11 | * | pixelma wonders if now is a good time to repeat the question about r28160 from earlier |
| 20:59:17 | gevaerts | Bagder: could you svn up the build server, or at least the checklog.pl file there? |
| 20:59:22 | | Join Dreamxtreme [0] (~Dre@92.30.196.196) |
| 21:00 |
| 21:00:45 | gevaerts | Bagder: maybe first review that diff. I'm not *that* good at perl |
| 21:01:46 | pixelma | if it doesn't make the build table vanish as LambdaCalculus' commit semi-recentlly, you are all set ;) |
| 21:02:27 | gevaerts | hm, yes, I could probably commit a change to tools/configure that runs an svn update in the right place, and then revert that :) |
| 21:04:22 | pixelma | speaking of perl... the revision I asked about changed something in buildzip.pl, want to have a look why this causes the .rockbox dir to be created outside the simdisk subfolder in a fresh builddir under cygwin? ;) |
| 21:04:55 | | Quit Jerom (Ping timeout: 264 seconds) |
| 21:05:43 | TheSeven | bugger |
| 21:05:56 | TheSeven | there is only one device on the ipod classic's first i2c bus |
| 21:06:04 | TheSeven | (which is the pmu) |
| 21:06:17 | TheSeven | and the second bus doesn't work at all => is the codec hiding there? |
| 21:07:12 | bertrik | TheSeven, some codecs are write-only, but I would still expect them to ack an i2c transaction |
| 21:07:28 | TheSeven | hm, i did a trivial read scan |
| 21:07:38 | TheSeven | so you have a point :) |
| 21:07:57 | * | TheSeven should dig deeper into the driver |
| 21:08:09 | TheSeven | and probably fix that issue preventing me from using the second bus |
| 21:17:20 | | Quit jgarvey (Ping timeout: 240 seconds) |
| 21:21:56 | | Join Jerom [0] (~jerome@95.171.147.5) |
| 21:24:37 | | Quit Jerom (Client Quit) |
| 21:24:53 | | Join Jerom [0] (~jerome@95.171.147.5) |
| 21:25:52 | | Quit Jerom (Client Quit) |
| 21:26:10 | | Join Jerom [0] (~jerome@95.171.147.5) |
| 21:26:15 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 21:26:28 | | Quit benedikt93 (Quit: Bye ;)) |
| 21:26:41 | | Quit Jerom (Client Quit) |
| 21:27:00 | | Join Jerom [0] (~jerome@95.171.147.5) |
| 21:27:07 | | Quit JdGordon (Ping timeout: 260 seconds) |
| 21:27:22 | saratoga | huh replaygain could be a lot faster on arm9 too |
| 21:28:04 | | Quit bmbl (Quit: Verlassend) |
| 21:28:15 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 21:29:37 | saratoga | stripwax: ping |
| 21:30:03 | stripwax | pong |
| 21:30:28 | | Quit Jerom (Client Quit) |
| 21:30:29 | saratoga | stripwax: how hard would it be to reverse the tricks you added to the mdct lib to save memory for targets that don't have IRAM? |
| 21:30:49 | saratoga | i suspect that on arm11 the old way would be quite faster since theres no IRAM and sequential accesses are much faster |
| 21:32:00 | stripwax | interesting. probably not too hard. that's related to FS #11268 right? |
| 21:32:23 | * | TheSeven reminds saratoga that there might be ARM11 targets with IRAM one day (iPod Nano 4G) |
| 21:32:25 | saratoga | stripwax: not specifically |
| 21:32:25 | stripwax | oh wait. i'm thinking of libtremor. which tricks did I add to the mdct lib? |
| 21:32:43 | saratoga | you ported the tremor trig table trick to it |
| 21:33:02 | saratoga | the old ffmpeg version used much larger tables with more regular memory access patterns |
| 21:33:06 | stripwax | crikey, that old chestnut. |
| 21:33:15 | stripwax | um. |
| 21:33:20 | saratoga | buschel and I noticed that liba52 memory scaling is much different then all the other mdct codecs |
| 21:33:21 | stripwax | 'difficult' but not impossible. |
| 21:33:29 | saratoga | and it uses the fft, but not the mdct code |
| 21:33:38 | saratoga | instead it uses its own trig tables arranged like ffmpeg's |
| 21:33:41 | | Join Trunkz|ZzZ [0] (~Trunkz@136.148.234.21) |
| 21:34:15 | saratoga | unfortunately our mdctlib is now quite well optimized for arm7/arm9 but in a lot of ways we've made it worse on newer arm targets |
| 21:34:22 | stripwax | gotcha. |
| 21:34:29 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
| 21:34:33 | Trunkz|ZzZ | I take it the forums is the only place to find out about any possible information on the rockbox-ipod classic effort? |
| 21:34:45 | stripwax | yeah, it's probably not great on any targets without iram trig tables |
| 21:34:47 | saratoga | freemyipod.com |
| 21:34:53 | Trunkz|ZzZ | thanks saratoga |
| 21:34:56 | | Nick Trunkz|ZzZ is now known as Trunkz (~Trunkz@136.148.234.21) |
| 21:34:57 | | Quit Trunkz (Changing host) |
| 21:34:57 | | Join Trunkz [0] (~Trunkz@unaffiliated/trunkz) |
| 21:35:14 | saratoga | on arm11 the key is basically using lots of ldm, avoding using registers right after you load or multiply to them, and and avoding random memory access patterns |
| 21:35:22 | stripwax | ffmpeg had three tables, iirc. two for the fft part, and a separate one for the mdct. |
| 21:35:42 | saratoga | IMO its probably enough to just special case the 2048 point transform |
| 21:35:45 | n1s | stripwax: if you have time, could you look at FS #11268 some time? |
| 21:35:52 | stripwax | one of the tricks (reusing the fft tables for the mdct bit, using interpolation ... which I nicked from the original libtremor) could probably still be kept |
| 21:35:55 | saratoga | and unwind the memory accesses for that one, even if it doubles the table sizes |
| 21:36:11 | saratoga | since its the only performance critical one |
| 21:36:30 | saratoga | on arm11 and to some extent arm9 its worthwhile to waste a lot of ram if it allows for more sequential loads |
| 21:36:37 | stripwax | n1s - ulp. yep. unfortunately i just don't have the time currently :( |
| 21:37:02 | n1s | stripwax: no, problem |
| 21:37:09 | n1s | eh no problem |
| 21:37:10 | saratoga | yeah i'm in no hurry to look at this either |
| 21:37:24 | saratoga | mp3 is going first, but eventually i want to improve the mdct lib |
| 21:37:31 | | Join Gareth [0] (~gareth@www.wiked.org) |
| 21:37:44 | saratoga | pretty soon i think i'll get mp3 faster then vorbis on some targets and thats no good ... |
| 21:38:10 | stripwax | haha |
| 21:38:36 | saratoga | armv5 and armv6 actually have some interesting instructions, just they're not too easy to use |
| 21:38:47 | saratoga | this mp3 project has been a nightmare |
| 21:38:55 | n1s | saratoga: i managed to make a function that does the mdct doubling and windowing at the same time for tremor but havent' written the asm yet |
| 21:39:10 | saratoga | stripwax and i argued abotu doing that a while ago |
| 21:39:57 | saratoga | just make sure you write asm thats not awful on arm11 if you do |
| 21:40:24 | stripwax | n1s - the benefit comes from reduced load/store presumably? |
| 21:40:53 | Trunkz | oh goodie |
| 21:41:00 | Trunkz | so atleast we're getting somesort of support on that front. |
| 21:41:01 | saratoga | hmm the menus in testcodec are broken |
| 21:41:19 | n1s | stripwax: yes, almost one load and store per sample in the block so about 2 loads and 2 stores per output sample |
| 21:43:00 | | Quit Trunkz (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
| 21:43:48 | n1s | the second half of the mdct doubling (the in place one) took a while to get right and as i've written it now it requires 8 different pointers so i need to make it somewhat cleverer to have enough regs |
| 21:44:12 | | Quit preglow (Ping timeout: 250 seconds) |
| 21:44:19 | | Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) |
| 21:44:29 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
| 21:45:12 | saratoga | n1s: i think you broke test_codec a week or two ago |
| 21:45:41 | stripwax | n1s - some of that might be made easier (or harder...) if the imdct_half generates the half output into a different part of the full output array (beginning, middle, end) |
| 21:46:12 | saratoga | n1s: when i select speed test with DSP it actually selects the item below that (speed test folder with dsp) |
| 21:46:13 | stripwax | just because i made imdct_half generate into the current place doesn't mean that's optimal for your change |
| 21:46:39 | n1s | saratoga: that change fixed the checksum thing for me that got broken with your earlier change |
| 21:46:41 | | Quit tchan (Read error: Operation timed out) |
| 21:46:45 | stripwax | although hm, i guess i might not understand what you mean by 'inplace' |
| 21:47:04 | saratoga | hmm no maybe i broke it |
| 21:47:34 | stripwax | you cache the half-imdct for the next block, and then need to (re)unfold it to do the next block's overlap? so your gain would be halved since you process the same half-imdct twice? |
| 21:48:06 | n1s | stripwax: right now the imdct_half places the output in the upper half of the output buffer, half of this is used to fill in the lower half and half is used to fill in the upper half but it is already in the upper half so it's quite complicated |
| 21:48:17 | saratoga | can't we just use the ffmpeg algorithm for this? |
| 21:48:27 | saratoga | IIRC theres is optimal in terms of mutliplications |
| 21:48:38 | stripwax | right. i think tremor put it into the middle and then moved things around eithers ide of that |
| 21:48:39 | saratoga | i think our wmapro decoder did this correctly |
| 21:48:42 | n1s | saratoga: the tradeoff is memory iiuc |
| 21:48:49 | stripwax | yeah, mults is fixed |
| 21:48:54 | saratoga | as in loads and stores? |
| 21:49:02 | stripwax | you still have to window every sample on the output side (not on the half-imdct side) |
| 21:49:11 | stripwax | yep |
| 21:49:17 | saratoga | the ffmpeg version uses the imdct half trick and is fully general in that it will work with any transform size |
| 21:49:26 | saratoga | mt ported it last summer |
| 21:49:46 | stripwax | the challenge is making vorbis do that |
| 21:49:48 | n1s | saratoga: yes but i think ffmpeg stores the half mdct in a separate buffer and doubles into a new buffer |
| 21:50:10 | stripwax | and the vorbis window is not symmetric |
| 21:50:17 | n1s | so you need half again as much memory |
| 21:50:25 | stripwax | dunno about wmapro |
| 21:51:34 | n1s | the way oi wrote my mdct-double+pwindow function with a special case for the symmetric window case (both overlapped blocks same size9 as this happens more than 90 % of al blocks |
| 21:51:40 | n1s | s/oi/i |
| 21:52:14 | saratoga | i don't think the wma ones are symmetric are they? |
| 21:52:23 | saratoga | been too long |
| 21:53:07 | n1s | the problem with moving the mdct output in the buffer is that the lower half is used for the input to the mdct |
| 21:55:12 | n1s | but for non iram challenged targets, doing it with separate buffers would almost certainly be faster |
| 21:55:36 | saratoga | the ffmpeg way seems to use 2048 input samples and some number of output samples i can't easily see because the buffer is shared with a bunch of other things |
| 21:56:04 | saratoga | i was actually going to switch wma std over to the wma pro version but never got around to it |
| 21:56:11 | saratoga | maybe theres a better way though |
| 22:00 |
| 22:02:00 | | Quit cozmic_ (Ping timeout: 240 seconds) |
| 22:02:02 | | Quit evilnick_B (Quit: Page closed) |
| 22:06:10 | n1s | hmm, now looking at this tremor iram dram stuff again, it seems we overlapp add into the dram buffer, that would be faster if it could be done into the iram buffer, and i dont' see why it couldn't |
| 22:08:20 | | Join cozmic [0] (cozmic@89-160-133-29.du.xdsl.is) |
| 22:12:05 | | Quit stripwax (Quit: http://miranda-im.org) |
| 22:13:26 | *** | Saving seen data "./dancer.seen" |
| 22:15:37 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:31:04 | | Quit simonrvn (Read error: No route to host) |
| 22:31:27 | n1s | pixelma: i'm closing FS #11811 (it's about a string missing from the german translation, thought you might be interested but it's certainly not a bug) |
| 22:34:33 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 22:36:38 | | Join simonrvn [0] (simon@197.112-ppp.3menatwork.com) |
| 22:40:21 | bertrik | I edited that task a bit (changed it from a patch to a bug), the original title was very non-specific |
| 22:42:12 | n1s | i still think it should be cloesd |
| 22:42:47 | n1s | langs getting out of sync isnt' a bug |
| 22:43:12 | n1s | but i was hoping soeone woudl comment |
| 22:43:56 | gevaerts | Well, it suggests a translation, so it's a half-patch in a way |
| 22:44:07 | pixelma | I really don't have the time to do anything about it today |
| 22:44:13 | pixelma | with a half name too |
| 22:44:21 | n1s | pixelma: do you want it to remain open? |
| 22:44:37 | wodz | lovely - h300 uses 2 distinct i2c software drivers + one coldfire channel, h100 uses one i2c software driver + one coldfire channel |
| 22:44:46 | pixelma | I'll try to remember it, not sure n1s |
| 22:45:10 | * | gevaerts asks for the patch |
| 22:45:43 | n1s | i'll leave it alone then but it's just a missing string it will show up in the next translation update |
| 22:45:55 | pixelma | indeed |
| 22:47:30 | | Quit TheSeven (Read error: Connection reset by peer) |
| 22:48:27 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 22:51:46 | | Quit m|c (Ping timeout: 265 seconds) |
| 22:51:46 | | Quit ack` (Ping timeout: 265 seconds) |
| 22:51:46 | | Quit AlexP (Ping timeout: 265 seconds) |
| 22:51:58 | | Quit Bushmills (Ping timeout: 245 seconds) |
| 22:52:15 | | Quit knittl (Ping timeout: 265 seconds) |
| 22:53:52 | | Quit ReimuHakurei_ (Read error: Connection reset by peer) |
| 22:55:03 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 22:57:23 | | Quit simonrvn (*.net *.split) |
| 22:57:23 | | Quit literal (*.net *.split) |
| 22:57:23 | | Quit saratoga (*.net *.split) |
| 22:57:23 | | Quit Rob2222 (*.net *.split) |
| 22:57:23 | | Quit crwl (*.net *.split) |
| 22:57:23 | | Quit Kitar|st (*.net *.split) |
| 22:57:23 | | Quit mordocai (*.net *.split) |
| 22:57:24 | | Quit GodEater (*.net *.split) |
| 22:57:24 | | Quit Battousai (*.net *.split) |
| 22:57:24 | | Quit mikroflops (*.net *.split) |
| 22:57:24 | | Quit preglow (*.net *.split) |
| 22:57:24 | | Quit Horscht (*.net *.split) |
| 22:57:24 | | Quit efyx (*.net *.split) |
| 22:57:24 | | Quit komputes (*.net *.split) |
| 22:57:24 | | Quit pixelma (*.net *.split) |
| 22:57:24 | | Quit amiconn (*.net *.split) |
| 22:57:24 | | Quit Stummi (*.net *.split) |
| 22:57:24 | | Quit bzed (*.net *.split) |
| 22:57:24 | | Quit TheLemonMan (*.net *.split) |
| 22:57:24 | | Quit DerPapst (*.net *.split) |
| 22:57:24 | | Quit hebz0rl (*.net *.split) |
| 22:57:24 | | Quit factor (*.net *.split) |
| 22:57:24 | | Quit BlakeJohnson86 (*.net *.split) |
| 22:57:24 | | Quit pamaury (*.net *.split) |
| 22:57:24 | | Quit Curulan (*.net *.split) |
| 22:57:24 | | Quit guymann (*.net *.split) |
| 22:57:24 | | Quit pjm0616 (*.net *.split) |
| 22:57:24 | | Quit kkit|sh (*.net *.split) |
| 22:57:25 | | Quit yosafbridge (*.net *.split) |
| 22:57:25 | | Quit Bawitdaba (*.net *.split) |
| 22:57:25 | | Quit maraz (*.net *.split) |
| 22:57:25 | | Quit jae_ (*.net *.split) |
| 22:57:25 | | Quit ranmachan (*.net *.split) |
| 22:57:25 | | Quit ThomasAH (*.net *.split) |
| 22:57:25 | | Quit soap (*.net *.split) |
| 22:57:25 | | Quit Judas_PhD (*.net *.split) |
| 22:57:25 | | Quit Strife89 (*.net *.split) |
| 22:57:25 | | Quit aevin (*.net *.split) |
| 22:57:25 | | Quit merbanan (*.net *.split) |
| 22:57:25 | | Quit Torne (*.net *.split) |
| 22:57:25 | | Quit rasher (*.net *.split) |
| 22:57:25 | | Quit parafin (*.net *.split) |
| 22:57:26 | | Quit n1s (*.net *.split) |
| 22:57:26 | | Quit kevku (*.net *.split) |
| 22:57:26 | | Quit ved_ (*.net *.split) |
| 22:57:26 | | Quit Rondom (*.net *.split) |
| 22:57:26 | | Quit Galois (*.net *.split) |
| 22:57:26 | | Quit Bagder (*.net *.split) |
| 22:57:26 | | Quit TBCOOL (*.net *.split) |
| 22:57:26 | | Quit Slasheri (*.net *.split) |
| 22:57:27 | | Quit edboyer93 (*.net *.split) |
| 22:57:27 | | Quit Hadaka (*.net *.split) |
| 22:57:27 | | Quit shai (*.net *.split) |
| 22:57:27 | | Quit zu_ (*.net *.split) |
| 22:57:27 | | Quit Utchy (*.net *.split) |
| 22:57:27 | | Quit 5EXABW64X (*.net *.split) |
| 22:57:27 | | Quit wodz (*.net *.split) |
| 22:57:27 | | Quit InsDel (*.net *.split) |
| 22:57:27 | | Quit mortalscan (*.net *.split) |
| 22:57:27 | | Quit Guinness (*.net *.split) |
| 22:57:28 | | Quit dfkt (*.net *.split) |
| 22:57:28 | | Quit liar (*.net *.split) |
| 22:57:28 | | Quit the_Kyle (*.net *.split) |
| 22:57:28 | | Quit linuxstb (*.net *.split) |
| 22:57:28 | | Quit froggyman (*.net *.split) |
| 22:57:28 | | Quit mystica555_ (*.net *.split) |
| 22:57:28 | | Quit Farthen (*.net *.split) |
| 22:57:28 | | Quit Loto (*.net *.split) |
| 22:57:28 | | Quit stripwax (*.net *.split) |
| 22:57:28 | | Quit sasquatch (*.net *.split) |
| 22:57:28 | | Quit Gareth (*.net *.split) |
| 22:57:28 | | Quit ender` (*.net *.split) |
| 22:57:28 | | Quit BHSPitMonkey (*.net *.split) |
| 22:57:28 | | Quit Guest75111 (*.net *.split) |
| 22:57:29 | | Quit antil33t (*.net *.split) |
| 22:57:29 | | Quit user890104 (*.net *.split) |
| 22:57:29 | | Quit MagusG (*.net *.split) |
| 22:57:29 | | Quit burn (*.net *.split) |
| 22:57:29 | | Quit timccc (*.net *.split) |
| 22:57:29 | | Quit part (*.net *.split) |
| 22:57:29 | | Quit ps-auxw (*.net *.split) |
| 22:57:59 | | Join ack [0] (~ack@mingbai.org) |
| 22:57:59 | | Join ReimuHakurei_ [0] (~reimu@74.112.212.15) |
| 22:57:59 | | Join knittl [0] (~knittl@thehappy.de) |
| 22:57:59 | | Join miceh [0] (~mtq@h1439481.stratoserver.net) |
| 22:57:59 | | Join Zarggg_ [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 22:57:59 | | Join simonrvn [0] (simon@197.112-ppp.3menatwork.com) |
| 22:57:59 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 22:57:59 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 22:57:59 | | Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) |
| 22:57:59 | | Join Gareth [0] (~gareth@www.wiked.org) |
| 22:57:59 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 22:57:59 | | Join InsDel [0] (~haqr.net@unaffiliated/insdel) |
| 22:57:59 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 22:57:59 | | Join Guest75111 [0] (jljhook@irkki.fi) |
| 22:57:59 | | Join TheLemonMan [0] (~lem0n@ppp-81-129.98-62.inwind.it) |
| 22:57:59 | | Join DerPapst [0] (~Alexander@p5DE5A76F.dip.t-dialin.net) |
| 22:57:59 | | Join hebz0rl [0] (~hebz0rl@dslb-088-065-218-251.pools.arcor-ip.net) |
| 22:57:59 | | Join Horscht [0] (~Horschti@xbmc/user/horscht) |
| 22:57:59 | | Join mortalscan [0] (~mortalsca@109.169.55.155) |
| 22:57:59 | | Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 22:57:59 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 22:57:59 | | Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
| 22:57:59 | | Join kevku [0] (~kevku@arch.tunnel.ipv6.estpak.ee) |
| 22:57:59 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 22:57:59 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 22:57:59 | | Join Rob2222 [0] (~Miranda@p4FFF1953.dip.t-dialin.net) |
| 22:57:59 | | Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 22:57:59 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 22:57:59 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 22:57:59 | | Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) |
| 22:57:59 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 22:57:59 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 22:57:59 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 22:57:59 | | Join the_Kyle [0] (~kyle@71.23.64.127) |
| 22:57:59 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe10fb00-173.dhcp.inet.fi) |
| 22:57:59 | | Join pixelma [0] (quassel@rockbox/staff/pixelma) |
| 22:57:59 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 22:57:59 | | Join sasquatch [0] (~username@p4FF2D6FE.dip.t-dialin.net) |
| 22:57:59 | | Join edboyer93 [0] (~eboyer93@pool-71-185-65-59.phlapa.fios.verizon.net) |
| 22:57:59 | | Join Kitar|st [0] (~Kitarist@BSN-182-85-30.dial-up.dsl.siol.net) |
| 22:57:59 | | Join Hadaka [0] (~naked@naked.iki.fi) |
| 22:57:59 | | Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) |
| 22:57:59 | | Join Stummi [0] (Stummi@rockbox/developer/Stummi) |
| 22:57:59 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 22:57:59 | | Join mordocai [0] (~mordocai@66.119.9.243) |
| 22:57:59 | | Join Strife89 [0] (~Strife89@adsl-80-184-118.mcn.bellsouth.net) |
| 22:57:59 | | Join burn [0] (~burn@cl-1079.bru-01.be.sixxs.net) |
| 22:57:59 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 22:57:59 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 22:57:59 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 22:57:59 | | Join bzed [0] (~bzed@devel.recluse.de) |
| 22:57:59 | | Join mystica555_ [0] (~mike@c-75-70-179-25.hsd1.co.comcast.net) |
| 22:57:59 | | Join literal [0] (hinrik@v.nix.is) |
| 22:57:59 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
| 22:57:59 | | Join part [0] (part@62.220.235.11) |
| 22:57:59 | | Join timccc [0] (~timccc@112.166.15.141) |
| 22:57:59 | | Join zu_ [0] (~zu@ks355000.kimsufi.com) |
| 22:57:59 | | Join guymann [0] (~charles@69.0.8.105) |
| 22:57:59 | | Join pjm0616 [0] (~user@110.9.28.120) |
| 22:57:59 | | Join Loto [0] (~nfs@xbmc/user/Loto) |
| 22:57:59 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
| 22:57:59 | | Join Utchy [0] (~Utchy@rps6752.ovh.net) |
| 22:57:59 | | Join 5EXABW64X [0] (fred@ircop.efnet.at) |
| 22:57:59 | | Join ved_ [0] (ved@ddsbox.co.cc) |
| 22:57:59 | | Join Rondom [0] (~rondom@lvps178-77-79-47.dedicated.hosteurope.de) |
| 22:57:59 | | Join Galois [0] (djao@efnet-math.org) |
| 22:57:59 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 22:57:59 | | Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) |
| 22:57:59 | | Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) |
| 22:57:59 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 22:57:59 | | Join merbanan [0] (~banan@c-94-255-221-143.cust.bredband2.com) |
| 22:57:59 | | Join Torne [0] (torne@rockbox/developer/Torne) |
| 22:57:59 | | Join kkit|sh [0] (krazykit@silenceisdefeat.com) |
| 22:57:59 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
| 22:57:59 | | Join Bawitdaba [0] (~Sphinx@cpe-74-70-40-135.nycap.res.rr.com) |
| 22:57:59 | | Join maraz [0] (maraz@kapsi.fi) |
| 22:57:59 | | Join jae_ [0] (~jae@jaerhard.com) |
| 22:57:59 | | Join ranmachan [0] (ranma@yumi.tdiedrich.de) |
| 22:57:59 | | Join ThomasAH [0] (~thomas@aktaia.intevation.org) |
| 22:57:59 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 22:57:59 | | Join parafin [0] (parafin@paraf.in) |
| 22:57:59 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 22:57:59 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 22:57:59 | | Join mikroflops [0] (~yogurt@h-34-59.A238.priv.bahnhof.se) |
| 22:58:05 | | Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) |
| 23:00 |
| 23:04:14 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 23:05:32 | | Quit simonrvn (Read error: No route to host) |
| 23:05:42 | | Join Bushmills [0] (~Bushmills@scarydevilmonastery.net) |
| 23:06:04 | | Quit jgarvey (Quit: Leaving) |
| 23:07:09 | CIA-45 | New commit by wodz (r28845): HD300 - hacky workaround which makes USB bridge work in rockbox |
| 23:07:20 | | Quit stripwax (Ping timeout: 276 seconds) |
| 23:08:19 | | Quit factor (Ping timeout: 250 seconds) |
| 23:08:59 | | Quit TheLemonMan (Quit: free(me)) |
| 23:09:00 | CIA-45 | r28845 build result: 15 errors, 0 warnings (wodz committed) |
| 23:09:24 | wodz | hmm |
| 23:09:52 | * | gevaerts pings Bagder again |
| 23:10:23 | gevaerts | wodz: build system vs gcc 4.3 thing |
| 23:10:25 | Bagder | I rather not mess with the build server |
| 23:10:34 | gevaerts | This is a simple change! |
| 23:10:54 | | Join mulenmar [0] (~mulenmar@74-132-43-137.dhcp.insightbb.com) |
| 23:11:06 | gevaerts | And it only changes how points are counted really (it adds a special case for this note: thing) |
| 23:11:28 | | Join r34per [0] (~ce36cfd0@giant.haxx.se) |
| 23:12:59 | | Quit r34per (Client Quit) |
| 23:13:07 | Bagder | right, but I still have zagor do that as I'm not sure how he does those things these days |
| 23:13:15 | gevaerts | ok |
| 23:13:46 | gevaerts | As long as people know they aren't to blame... |
| 23:15:07 | n1s | shouldn't we block known bad compilers or known bad clients? |
| 23:15:28 | gevaerts | it |
| 23:15:34 | gevaerts | This is neither |
| 23:15:51 | gevaerts | The compiler just outputs some lines that the build system doesn't expect |
| 23:15:58 | n1s | oh |
| 23:16:01 | wodz | it isn't bad it just throws additional notes |
| 23:16:54 | gevaerts | If it was a bad client, I'd block it right away |
| 23:16:55 | n1s | so we should grep the lines for "error" |
| 23:17:08 | n1s | or "warning" |
| 23:17:21 | gevaerts | Well, I did commit a fix, it just needs to be updated on the server |
| 23:17:39 | wodz | BTW what exactly this 'note' mean? |
| 23:17:50 | gevaerts | And we want Zagor for that, so it will have to be like this until somewhere tomorrow I guess |
| 23:18:46 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 23:18:59 | n1s | gevaerts: aha, sorry for not following :) |
| 23:19:47 | | Quit mulenmar (Quit: Leaving) |
| 23:19:51 | gevaerts | We *could* block that client for the night, but I'm not convinced that that's a good idea |
| 23:19:51 | | Join designate72 [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 23:20:37 | n1s | no, not that important |
| 23:21:11 | * | TheSeven wonders why this started happening this suddenly |
| 23:21:14 | TheSeven | new build client? |
| 23:21:23 | | Join mulenmar [0] (~mulenmar@74-132-43-137.dhcp.insightbb.com) |
| 23:21:38 | gevaerts | yes |
| 23:21:39 | wodz | or gcc update |
| 23:21:47 | gevaerts | no, it's gcc 4.3 that does this |
| 23:22:23 | n1s | it's in the new mikmod plugin |
| 23:22:34 | gevaerts | yes, that too |
| 23:23:00 | gevaerts | But this build client is newer |
| 23:24:04 | | Join Chesteta [0] (~4394a340@giant.haxx.se) |
| 23:25:29 | wodz | maybe there is a gcc switch to suppress this 'note' lines? |
| 23:25:39 | wodz | as a temp solution? |
| 23:26:00 | gevaerts | again, for half a day? Not worth it I think |
| 23:26:22 | | Quit Chesteta (Client Quit) |
| 23:29:38 | Dreamxtreme | hrm i'll ask this in here |
| 23:30:03 | Dreamxtreme | how come when i unplug the ipod right away it says around 90% battery |
| 23:30:06 | wodz | interesting - google doesn't know much about gcc 'note' warnings |
| 23:30:16 | Dreamxtreme | do i need to do a Batt_bench? |
| 23:30:37 | wodz | or live with what you have |
| 23:31:18 | wodz | Dreamxtreme: what ipod? hd based? |
| 23:32:32 | | Nick ved_ is now known as ved (ved@ddsbox.co.cc) |
| 23:33:08 | Dreamxtreme | yea |
| 23:33:14 | Dreamxtreme | 5.5G |
| 23:33:22 | | Quit efyx (Quit: Quitte) |
| 23:35:00 | wodz | Turn it on and wait a bit - battery level should rise. HD takes quite a bit of current and battery voltage drops. When hd spins down voltage will recover to some degree. |
| 23:35:12 | wodz | There is nothing we can do about this |
| 23:35:23 | | Join factor [0] (~factor@r74-195-220-23.msk1cmtc02.mskgok.ok.dh.suddenlink.net) |
| 23:36:20 | | Join Luca_S [0] (~57113b1a@giant.haxx.se) |
| 23:36:47 | Dreamxtreme | o ok |
| 23:37:16 | Luca_S | wodz: in the latest commit, is it correct #ifndef BOOTLADER ? |
| 23:37:34 | wodz | Luca_S: good catch |
| 23:37:57 | Luca_S | :) that's the proof that I code better when I'm drunk (like now) |
| 23:39:01 | CIA-45 | New commit by wodz (r28846): fix typo, thanks to Luka_S for catching this |
| 23:41:09 | CIA-45 | r28846 build result: 5 errors, 0 warnings (wodz committed) |
| 23:45:17 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 23:50:25 | | Quit froggyman (Quit: Ex-Chat) |
| 23:50:46 | | Join froggyman [0] (~seth@98.115.0.7) |
| 23:50:47 | | Quit froggyman (Changing host) |
| 23:50:47 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 23:54:55 | | Join JdGord [0] (~jonno@58.108.106.31) |
icon identifies that the person is a core developer (has commit access).