--- Log for 31.08.110 Server: asimov.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 16 days and 1 hour ago 00.00.03 # kugel: from my understanding it does not fully reset and refill the buffer, but only loads 1 chunk. but the data is not buffered anymore. 00.00.32 # No, rebuffer_handle is only called if it isn't buffered yet, but it should be soon. And the queue_send is to make sure it is. 00.02.02 # Buschel: you describe that it needs to seek from the end to the beginning; it seems the if() is wrong if that case goes through it 00.03.02 # But it looks like ringbuf_add should be used there, and find_handle should be called again, since queue_send do sleep. 00.03.04 # shouldn't newpos be smaller than h->offset here? 00.03.54 # kugel: The codec seeks to somewhere near the file-end. Then it seeks back to somewhere near file-begin using reset/buffer. The very first rebuffer attempt afterwards enters the if()-statement -- and that's when the codec exits with gargabe data. 00.04.12 Quit pamaury (Remote host closed the connection) 00.04.52 # * S_a_i_n_t doesn't understand: http://www.rockbox.org/tracker/task/11582?project=1&type=4&order=dateopened&sort=desc 00.05.19 # *garbage 00.05.38 Quit jgarvey (Quit: Leaving) 00.06.55 # Buschel: I'm not sure if it is the seek back to the beginning that is the problem; in this case it is to well beyond the first chunk. 00.09.03 # Lear: Well, the error occurs with the first call of rebuffer_handle() after the seek back to the beginning. 00.09.36 # Lear: The seek back is not entering the if()-statement within rebuffer_handle(). So, I assume the seek back is fine. 00.10.09 # So it is the first seek after the rebuffer_handle back to the beginning, so to speak? 00.10.09 # Lear: I assume the code within the if()-statement is somehow faulty 00.10.30 # rebuffer_handle is only called from bufseek(), why should there be another bufseek() after the one that goes to the beginning? 00.10.41 # Lear: exactly 00.11.52 Quit Zarggg (Quit: Zarggg) 00.11.58 # kugel: you should really try to use the problematic file. the seek is not seeking the file-beginning, but to a special position for a sub-header within the bitstream. it is reasonable that another seek is happening afterwrda when starting to decode the file 00.12.36 # I have no idea about audio formats, listening to that file doesn't help me 00.12.37 # * Buschel gets another (and the last!) beer 00.13.04 # kugel: no, not listening. it does not play without my hotfix 00.13.34 # kugel: at least on iPod Video and sansa e200 (w/o dircache) 00.14.15 # * preglow sips his gin&tonic 00.14.29 # pretending it still feels like summer 00.14.48 # preglow: it is pretty damn cold here in southwest germany :/ 00.15.27 # isn't exactly stellar here either, rain and grey skies 00.15.40 Join h3po [0] (~h3po@p4FDE9309.dip0.t-ipconnect.de) 00.16.55 # There's a seek to locate the first audio frame, and that is within the first chunk after offset (which now is at mdat start). 00.18.54 Quit h3po1 (Ping timeout: 276 seconds) 00.18.56 # Lear: ringbuf_add isn't appropriate here (IIUC) because h->ridx, h->offset and newpos aren't representing the position in the buffer, but the position in the file 00.19.15 # but you might be right about calling find_handle() again 00.19.17 # Lear: When I printf-debugged I saw the the problematic rebuffering was used to seek +8 byte (relative to mdat start) 00.19.52 # Buschel: Makes sense, yes. 00.23.17 # kugel: h->ridx and h->data is a buffer index. Newpos is an absolute file position, so that math looks really bad to me. 00.23.49 # oh 00.25.04 Join krazykit [0] (~kkit@206.183.185.8) 00.25.05 # yes indeed 00.25.07 # Buschel: Maybe a proper fix would be something like "h->ridx = ringbuf_add(h->data, newpos - h->offset);"? 00.26.13 # that could be worth a try 00.26.32 # testing... 00.27.20 # looks good :) 00.29.25 # seems to solve the issue as well 00.29.31 Join krabador [0] (~laura@host131-20-dynamic.251-95-r.retail.telecomitalia.it) 00.29.59 # Then there's all the find_handle calls that probably need to be added. :) 00.30.11 # But I I _really_ need to go to be now... 00.30.42 # Lear: I will submit yuir proposal to fix the issue. 00.30.46 # *your 00.30.56 # Ok. 00.31.07 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) 00.31.33 # another find_handle within that if() shouldn't be needed, buffer_handle() doesn't change it 00.32.20 # i'm trying to make voice work on clipv1 without success so far 00.34.42 # Is anyone interested at looking at a new plugin? http://www.rockbox.org/tracker/task/11585 00.34.47 Join Zarggg [0] (~zarggg@70.44.12.90.res-cmts.sm.ptd.net) 00.35.34 # New commit by 03Buschel (r27950): Fix FS#11586. Corrects rebuffering behaviour which did not allow to play several m4a files. Thanks to Magnus Holmgren. 00.37.05 Join kaiscene [0] (kaiscene@ool-18e45d82.dyn.optonline.net) 00.37.22 # r27950 build result: All green 00.38.18 Quit bmbl (Quit: Bye!) 00.38.20 # clone4crw: #define RES_SILVER_MUL 1/100 isn't going to work as expected 00.38.46 # ah clips are queued and played asynchronously 00.39.02 # also remove PLUGIN_HEADER 00.39.11 # btw, why does your plugin not work in the sim? 00.40.26 # remove plugin_header? ok 00.41.10 # I really don't know why it doesn't work in the sim. i start rockboxui from the command line, and after a while it reports a bunch of SDL errors 00.41.18 # why are all your functions indented? 00.41.35 # should they not be? 00.41.43 # run it with gdb, you've probably make it crash somewhere 00.42.28 # hm .. voice works but not playback 00.42.34 # (with current build) 00.42.38 # the functions itself not, but what's in the functions (i.e. |int foo()\n|{\n|--->int i;) 00.42.49 # -> audiobuf size is - (minus) 198K 00.43.42 Part froggyman 00.43.54 # i'm recompiling an e200 sim right now - i'll try gdb 00.43.57 Quit shai (Ping timeout: 245 seconds) 00.44.56 Quit evilnick (Quit: Page closed) 00.46.10 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 00.46.15 # kugel: anything else? 00.47.16 Quit {phoenix} (Remote host closed the connection) 00.48.19 Join froggyman [0] (~4845cf9e@unaffiliated/froggyman) 00.48.20 Quit froggyman (Client Quit) 00.51.37 # clone4crw: well, it's not quite finished yet 00.52.49 Quit h3po (Read error: Connection reset by peer) 00.53.15 Quit bluebrother (Disconnected by services) 00.53.19 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 00.54.08 # Yeah, I know. I really wanted to put it out there after sitting on it for so long 00.54.50 *** Saving seen data "./dancer.seen" 00.54.59 Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) 00.57.00 # clone4crw: I was actually looking at that plugin right now ;) 00.57.05 # New commit by 03funman (r27951): audio_reset_buffer: check audiobuffer size not only in DEBUG builds ... 00.57.09 # I cleaned up one of your bitmaps for you. 00.57.14 # Just about to post it. 00.57.46 # Sounds great. 00.57.52 # clone4crw: the biggest issue I see is that you're trying to store fractions in ints 00.58.11 # yes, i'm still a bit unsure of how to do some things in C 00.58.17 Join Guest50782 [0] (~seth@pool-72-69-207-158.chi01.dsl-w.verizon.net) 00.59.47 # r27951 build result: 0 errors, 71 warnings (funman committed) 01.00.25 Quit Jerom (Read error: Connection reset by peer) 01.00.34 Nick Guest50782 is now known as froggyman (~seth@pool-72-69-207-158.chi01.dsl-w.verizon.net) 01.00.46 Quit froggyman (Changing host) 01.00.46 Join froggyman [0] (~seth@unaffiliated/froggyman) 01.00.49 # do we really need such a useless check? 01.01.01 # why useless? 01.01.27 Join saratoga [0] (9803c22e@gateway/web/freenode/ip.152.3.194.46) 01.01.44 # adding support for %zd/%zu in format.c costs 124 bytes on clipv1 01.02.01 # we really need some kind of unit testing for the playback engine 01.02.37 # New commit by 03funman (r27952): panicf() is declared in panic.h 01.03.17 # clone4crw: also, you can't just declare a string constant and then write to that. It might work with some runtimes and compilers, but it *will* break eventually 01.04.41 # r27952 build result: All green 01.04.59 # I wouldn't be surprised if that's where your sim segfaults come from 01.08.01 # funman: btw, I meant to ask you, why did you add lcd_putsxyf to the plugin api instead of to the multi screen api (you asked to remove lcd_putsf from the plugin api minutes before) 01.08.11 # New commit by 03funman (r27953): format: supports %zd (ssize_t) and %zu (ssize_t) 01.08.14 # New commit by 03funman (r27954): don't cast to int when not needed 01.09.09 # kugel: i don't know, what's different between lcd_putsf() and screens->putsf() ? 01.09.23 # no difference 01.09.52 # mostly i didn't know about the screens API before starting this work 01.09.58 # clone4crw: Another thing, I'm pretty sure you don't mean "(BUTTON_UP || BUTTON_SCROLL_BACK) 01.10.01 # " 01.10.02 # r27953 build result: All green 01.10.12 # you can loop over rb->screens[] instead of calling lcd_putsf and lcd_remote_putsf separately 01.10.28 Join dfkt [0] (dfkt@unaffiliated/dfkt) 01.10.39 # well, it's just a set of variables and function pointers for lcd_[remote_]* functions 01.11.06 # there's also a similar api for greylib 01.11.40 # r27954 build result: All green 01.12.19 # clone4crw: The new image is in a comment I just added to your patch on the tracker. 01.12.54 # When I get more time, I might clean up the other one too...I just did that one because it was the image appropriate for my screen size :D 01.13.15 # funman: did va_arg(ap, ssize_t) not work= 01.13.17 # ?* 01.13.50 # oops typo, thanks 01.14.36 # gevaerts: yep. i got that mixed up. i'll fix the indentations, too. 01.14.55 # even though most of those button declarations aren't being used yet 01.15.02 # New commit by 03funman (r27955): typo in r27953 spotted by kugel: s/long/ssize_t/ 01.16.44 # r27955 build result: All green 01.18.36 # kugel: the idea was to use the same case than long but for some platforms sizeof(long) != sizeof(size_t) 01.19.09 # yea, I understand that (IIRC gevaerts tried the reuse-long-case approach alredy) 01.19.15 # S_a_i_n_t: Think you'll add a keymap for the Nano? 01.19.34 # but ssize_t might also not work on all platforms (it's a unix type) 01.20.21 Quit krabador (Quit: Sto andando via) 01.20.59 # we could remove it if it cause problems 01.22.12 # clone4crw: Not presently...but, in time, yeah. Unless you beat me to it. 01.22.37 # or calculate it from size_t 01.23.19 # adding a keymap for the Nano kills multiple birds with one stone....pretty sure all iPods use the same keymap. 01.23.24 # clone4crw: ^ 01.23.46 # clone4crw: how many keys do you need? consider pluginlib_actions if you only need 5 or so 01.23.48 # good point 01.24.09 # gaverts: Yeah, stupid me. fixed the constant char thing, the sims now work 01.24.40 # The only reason I defined so many was for later when we could have a calculator-like keypad for input 01.24.42 # with pluginlib_actions you kill *all* birds at once 01.24.57 # kugel: Good point ;) 01.27.51 # clone4crw: "char * the_resistance_is = "The resistance is "" doesn't work, while "char the_resistance_is[] = "The resistance is "" does. also you don't need to reserve 35 chars for the result, you can simply use snprintf() 01.28.43 # I mean, you need to reserve some space, but it doesn't need to be an array of spaces 01.28.56 # clone4crw: Give me a yell if you need more images done, I'll probably re-do & post the 220x176x16 later on tonight...if you need other images for other targets, just let me know the dimensions. 01.29.10 # is char total_resistance_str [35] ok? 01.29.13 # PS: I'm terrible with greyscale/monochrome images ;) 01.29.25 # buf[35]; snprintf(buf, sizeof(buf), "The resistence is %d", resistence); 01.29.40 # But...this plugin won't really work on non-colour targets, so, I suppose that isn't a problem. 01.30.01 # Yeah, I was thinking in that case it would just be textual output 01.35.09 # well, when you know what sizes you'll need...gimme a yell. 01.35.20 # ok 01.35.26 # I'll re-do the 220x176x16 later on as I said earlier. 01.35.49 # (not that I think you didn't do a good job...however) 01.36.15 # I had a worse one to start out with, then whipped up the current one in GIMP 01.37.38 # I almost want the bands themselves to be BMPs with a slight curve to them, giving the whole thing a more 3D effect, but I'll focus on getting the whole thing finished first :p 01.39.12 Join bunnyboi [0] (~androgyne@cpe-72-224-19-157.nycap.res.rr.com) 01.39.33 Quit bunnyboi (Read error: Connection reset by peer) 01.44.59 # i have it semi-working now 01.49.50 Quit lostlogic (Quit: leaving) 01.51.24 Quit MagusG (Read error: Connection reset by peer) 01.51.35 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 01.52.00 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 01.53.26 Quit Transformer (Excess Flood) 01.55.36 # I just put a fixed version on the tracker 01.56.10 # it seems to work fine but spelling fails after 10 letters or so 02.07.06 # FS#11587 - Voice for SWCODEC and low memory 02.10.13 Quit funman (Quit: free(random());) 02.11.08 Quit lestatar (Ping timeout: 240 seconds) 02.12.56 Join lestatar [0] (~chatzilla@cpe-72-229-41-214.nyc.res.rr.com) 02.15.03 Quit dfkt (Read error: Connection reset by peer) 02.15.04 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 02.20.37 Quit lestatar (Ping timeout: 258 seconds) 02.21.30 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 02.21.43 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 02.21.52 Part JdGordon| 02.29.32 Join captainkewllllll [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.30.09 Quit captainkewllllll (Client Quit) 02.33.11 # where does it fail? 02.33.50 Quit MagusG (Read error: Connection reset by peer) 02.34.39 Join MagusG [0] (magusg@c-76-97-148-35.hsd1.ga.comcast.net) 02.35.03 Quit kugel (Remote host closed the connection) 02.48.24 Quit komputes (Remote host closed the connection) 02.54.52 *** Saving seen data "./dancer.seen" 03.04.39 Join G4Oblivion [0] (~48281c8e@giant.haxx.se) 03.06.54 # I've done testing and found that r27020 is what has been causing the "*PANIC* stkov nand" errors on nano 2g. 03.07.31 Join madalu [0] (~matt@unaffiliated/madalu) 03.08.32 # I only have one nano I can test this on so if anyone would like to test this I have uploaded r27019 and r27020 here: http://www.mediafire.com/?93izuhsbho39b80 03.08.53 # Users that would also like to revert back to r27019 can use that. 03.09.37 Quit G4Oblivion (Quit: CGI:IRC (EOF)) 03.10.49 Part madalu 03.29.26 Join powell14ski_ [0] (~powell14s@c-174-51-160-240.hsd1.co.comcast.net) 03.37.50 Quit dfkt_ (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 03.39.03 Quit GeekShadow (Quit: The cake is a lie !) 03.40.42 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 03.41.00 # is "ew" from the forums in here? 03.41.10 # S_a_i_n_t: ping me when you come online 03.41.19 Part JdGordon| 03.51.33 Quit simonrvn (Quit: bbiab) 04.03.22 # hehehe...irony. 04.03.46 # JdGordon: (though I know you're not here...) Pong. 04.04.21 Join huffpuff [0] (~matthew@h181.29.188.173.dynamic.ip.windstream.net) 04.04.56 # TheSeven: Pingeroony? 04.05.30 Join simonrvn [0] (simon@211.148-ppp.3menatwork.com) 04.06.16 # TheSeven: G4Oblivion has done some testing apparently, and seems to think that the Nano2G Stkov NAND panic was introduced in r27020 04.08.40 # I lost all my testing results in "The Great HDD Failure of Last Week", but, I seem to remember my testing telling me that there were good revisions well after that....but, I also got different results on different trials...so, I don't know what to expect. 04.11.11 # Right now I'm trying to bisect the "skipping multiple tracks *really* fast causes Undefined Instruction" bug, and not having a bunch of luck there either. 04.14.13 Join steve|m1 [0] (~steve@p4FD45883.dip.t-dialin.net) 04.14.13 Quit steve|m (Disconnected by services) 04.14.46 Nick steve|m1 is now known as steve|m (~steve@p4FD45883.dip.t-dialin.net) 04.19.51 # New commit by 03jdgordon (r27956): Should fix the line alternator issue described in http://forums.rockbox.org/index.php?topic=25545 04.22.22 # r27956 build result: All green 04.22.45 Join G4Oblivion [0] (~48281c8e@giant.haxx.se) 04.23.42 Join timccccc [0] (~lisa@121.159.100.28) 04.24.08 # @ S_a_i_n_t: I just built the newest revision of rockbox and manually changed the nand-nano2g.c to match r27019's and I am not getting the crashes anymore. 04.24.09 Quit amiconn (Disconnected by services) 04.24.09 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.24.24 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.24.49 # I know little to nothing of programming though. I have no idea why it caused the crashes 04.24.57 Quit pixelma (Disconnected by services) 04.25.00 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.25.02 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.25.54 Quit TheSeven (Ping timeout: 258 seconds) 04.28.00 # r27020 is definitely whats causing the crashes. 04.28.28 # G4Oblivion: Could you please post a diff of your changes? 04.28.36 # (assuming you know how to diff) 04.29.06 # My solution was to more than double the NAND stack. 04.29.13 # Works, but, hardly ideal. 04.29.34 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.30.39 # I _think_ the default NAND stack size is ~0x400, at 0x800 I could still get it to panic in some circumstances...but at 0x1000 its fine. 04.30.39 # I have no idea how to post a diff 04.30.57 # again, hardly an ideal "fix" ;) 04.31.14 # G4Oblivion: You know how to make a diff? 04.31.17 # all I did was revert the changes made in r27020 with the newest revision 04.31.20 # nope 04.31.30 # "svn diff > diffname.patch" 04.31.46 Join Barahir [0] (~jonathan@frnk-590f70a8.pool.mediaWays.net) 04.31.49 # (without quotation marks) 04.32.04 # Barely know linux =/ 04.33.53 # I ran that in my rockbox folder and got a diffname.patch 04.33.59 # is that what you want 04.34.23 # you ran it in the source directory? and, yes. 04.34.33 # pastebin it, please. 04.34.45 # S_a_i_n_t: Just added better LCD support for the Nano in the resistor plugin, FYI 04.35.33 # http://pastebin.com/H2nBpGAj 04.35.35 Quit Barahir_ (Ping timeout: 276 seconds) 04.35.57 # clone4crw: Awesome, I shall have a look. I'll also get on with "prettying up" the other bitmap, maybe do some more on the other one I started initially also. 04.36.22 # I know it's irrelevant, but, I like things to look good. 04.36.38 # It could look like crap and still be a cool, functional plugin ;) 04.36.57 # G4Oblivion: Thanks. 04.37.24 # No problem. Hope it gets fixed soon. 04.38.14 # As do I, I'm really glad you've managed to narrow it to one particular revision. I couldn't do that myself. 04.38.25 # S_a_i_n_t: Well, of course. But if we were all for utilitary, and not looks, we'd all be using window managers that look like Windows 98 04.38.28 # My good/bad revisions kept changing on me. 04.39.00 # revisions I knew to be good, randomly paniced on boot, ones I knew to be bad...booted fine. 04.39.25 # ...it was really very frustrating. 04.40.02 # G4Oblivion: TheSeven can't reproduce it *at all*, which is *really* weird. 04.40.15 # I just started doing it to things that affect/might affect the nano 04.40.20 # Out of interest G4Oblivion, what capacity is your Nano2G? 04.40.26 # 2GB 04.40.43 # I just got ubuntu the other day. First time using a linux system. 04.40.56 # Aha...right. 04.41.14 # I have 2 and 4GB Nanos, and TheSeven's is an 8GB. 04.41.36 # I can reproduce the panic on both, but, TheSeven can't on his 8GB 04.41.50 # why the capacity would change anything...I have no idea, but, apparently it does. 04.42.19 # Apple isn't one to change something thats already working. I don't know why it would be different. 04.44.13 # It puzzles me also, appart from the NAND capacity, there *shouldn't* be anything different between my Nanos, your Nano, and TheSeven's Nano...but, apparently there is. 04.44.43 # And I can't see how the NAND capacity is a factor in this. 04.44.50 # * S_a_i_n_t shrugs 04.46.48 Quit BlakeJohnson86 (Ping timeout: 245 seconds) 04.46.54 # Well, I hope it gets figured out. If TheSeven or someone can't find a fix soon, might want to revert 27020. The nano is probably considered unusable right now. 04.47.32 # Its getting late so I'm going in for the night. 'night 04.47.40 # G4Oblivion: A simpler "fix" is to change the default NAND stack size to 0x1000 04.48.42 Quit G4Oblivion (Quit: CGI:IRC (EOF)) 04.49.47 Join BlakeJohnson86 [0] (~bjohnson@173-140-162-85.pools.spcsdns.net) 04.49.48 # firmware\target\arm\s5l8700\ipodnano2g\nand-nano2g.c, line 94, change from "static long nand_stack[DEFAULT_STACK_SIZE];" to "static long nand_stack[0x1000];" 04.49.52 # awww, crap. too late. 04.50.03 Quit timccccc (Ping timeout: 258 seconds) 04.54.53 *** Saving seen data "./dancer.seen" 04.59.33 Quit clone4crw (Quit: leaving) 05.04.16 Join clone4crw [0] (~calvin@96-42-90-88.dhcp.roch.mn.charter.com) 05.06.48 Quit clone4crw (Client Quit) 05.07.30 Quit BlakeJohnson86 (Ping timeout: 240 seconds) 05.08.57 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 05.09.48 Join anewuser [0] (anewuser@unaffiliated/anewuser) 05.17.24 Quit kaiscene () 05.18.59 Join [Saint] [0] (S_a_i_n_t@203.184.1.132) 05.19.26 Quit S_a_i_n_t (Ping timeout: 255 seconds) 05.22.15 Join bunnyboi [0] (~androgyne@cpe-72-224-19-157.nycap.res.rr.com) 05.22.26 Quit bunnyboi (Read error: Connection reset by peer) 05.23.56 Nick [Saint] is now known as S_a_i_n_t (S_a_i_n_t@203.184.1.132) 05.25.19 Quit Horscht (Quit: Verlassend) 05.28.46 Quit Zarggg (Quit: Zarggg) 05.33.45 Quit ps-auxw (Ping timeout: 258 seconds) 05.37.26 Quit S_a_i_n_t (Ping timeout: 255 seconds) 05.45.08 Join ps-auxw [0] (~arneb@p4FF7F37F.dip.t-dialin.net) 05.56.09 Join sweetandy [0] (~sweetandy@unaffiliated/sweetandy) 05.56.12 Join milz [0] (~kyle@d173-181-32-196.abhsia.telus.net) 05.57.46 Quit Judas_PhD (Ping timeout: 265 seconds) 06.07.23 Quit milz (Remote host closed the connection) 06.08.44 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 06.09.37 Quit huffpuff (Quit: leaving) 06.09.56 # * JdGordon| thinks it should be possible to scan a sublines tokens for a %t() hiding inside conditionals (up to some max depth) and not waste too much cpu time 06.10.15 # that would fix the issue with %t(0) inside conditionals 06.10.57 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 06.14.20 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 06.15.55 Join milz [0] (~kyle@d173-181-32-196.abhsia.telus.net) 06.18.15 Quit milz (Remote host closed the connection) 06.21.11 Part sweetandy ("This space intentionally left blank.") 06.26.16 Quit MagusG (Ping timeout: 272 seconds) 06.54.55 *** Saving seen data "./dancer.seen" 06.55.52 Join funman [0] (~fun@rockbox/developer/funman) 06.56.36 # hi, i got FS#11587 (voice for clipv1) working, i'll waita bit before committing someone wants to comment 06.56.51 # also perhaps it would make sense to use it on other targets to reclaim a bit of memory 06.58.29 # whats the downside, more disk spin ups? 07.00.34 # yes, so i think it would make sense only on flash targets, where memory isn't that important .. so i guess a blind user has to try 07.01.54 # there are 64 entries buffered so it depends how frequently you go in the menus i think 07.04.36 # after this goes in we can move the clipv1 to stable and focus on the last issue: battery life 07.05.25 # i think testing the amsv1 targets again with boosting between 31 and (approximately) 100Mhz might give interesting battery life 07.05.56 # since 62 is too high for low boost, but 250MHz results in very poor performance per clock due to memory 07.06.25 # memory clock is (nearly) at the max on amsv1 already 07.06.50 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 07.06.51 # so it would be 62 (unboosted) and 124 (boosted) ? 07.08.57 # 32 unboosted, 124 boosted 07.09.00 # would be interesting I think 07.18.08 # i'll try with 32/128 & pclk @ 32MHz 07.19.51 Join Zarggg [0] (~zarggg@70.44.12.90.res-cmts.sm.ptd.net) 07.20.21 # clipv1 boots noticeably slower, might not be worth to do it on fuzev1/e200v2 07.26.35 Join Chronon [0] (~chronon@c-67-171-217-43.hsd1.or.comcast.net) 07.33.45 # funman: thats with 32 pclk boosted too? 07.35.06 # yes 07.36.30 Join stoffel [0] (~quassel@p57B49E6C.dip.t-dialin.net) 07.43.36 Join l403 [0] (~l@gw8.vslesy.cz) 07.45.04 Join fyrestorm [0] (~nnscript@cpe-68-173-233-99.nyc.res.rr.com) 07.46.05 # just started the bench 07.52.04 # hm it just crashed 07.52.45 # i'll try with no voice loaded 08.03.30 Quit solexx_ (Ping timeout: 260 seconds) 08.05.14 Join solexx [0] (~jrschulz@e176110144.adsl.alicedsl.de) 08.05.54 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.10.43 Quit Not-iH8sn0w (Ping timeout: 240 seconds) 08.13.47 Join Not-iH8sn0w [0] (~iH8sn0w@CPE001e58fb11c8-CM000f9fa76cf2.cpe.net.cable.rogers.com) 08.16.43 Quit Chronon (Ping timeout: 240 seconds) 08.19.15 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.4.62) 08.24.25 Join Kitar|st [0] (Kitarist@BSN-182-63-238.dial-up.dsl.siol.net) 08.26.24 Quit Rob2223 (Read error: Connection reset by peer) 08.26.57 Join Rob2222 [0] (~Miranda@p4FDC9557.dip.t-dialin.net) 08.30.29 # another crash with same symptoms: backlight goes on and i see the wps, pressing a button reboots 08.31.29 # saratoga: iirc you made a change to enable the backlight on panics? 08.31.44 # funman: no i gave up when I couldn't figure out how to do it 08.33.03 Quit r0b- (Ping timeout: 264 seconds) 08.33.39 # ah it's ranma in r26917 (only for AMS), but it misses something 08.34.46 # we need lcd_update() after enabling backlight else it has the old content 08.37.12 Quit S_a_i_n_t (Ping timeout: 276 seconds) 08.41.16 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.44.11 # segfault in lcd_puts_scroll_style_offset() 08.44.26 # although screen was off 08.44.56 Join ender` [0] (krneki@foo.eternallybored.org) 08.46.08 # this is just with the clock changed? 08.47.28 # yes but it i didn't try with current build. i just changed the theme to cabbiev2 to check if it was my theme 08.49.11 # New commit by 03funman (r27957): AMS: update the LCD on system exception to be sure the content is up to date ... 08.50.14 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.50.42 # funman: For voice on lowmem you might want the same mechanism as on archos, i.e. not a separate voice buffer, but loading voice to the audio buffer after stopping playback 08.51.10 # r27957 build result: 0 errors, 14 warnings (funman committed) 08.51.21 # This means no voice during playback, but you don't need a separate voice buffer 08.51.28 Quit scorche (Disconnected by services) 08.51.38 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 08.53.30 # New commit by 03funman (r27958): include lcd.h , forgotten in r27957 08.55.00 *** Saving seen data "./dancer.seen" 08.55.02 # mpegplayer isn't realtime on the fuze with the change, 15 fps if i read correctly 08.55.13 # r27958 build result: All green 08.56.19 Quit Kitar|st (Ping timeout: 240 seconds) 08.56.43 # is there a id3-tag-editor for rockbox? 08.57.10 # no 08.59.45 Quit anewuser (Quit: FAMICOMPO 7 - August 15 Through August 31 JST - http://midr2.under.jp/compo/vol7/index.html) 09.01.46 Join Kitar|st [0] (Kitarist@BSN-143-107-130.dial-up.dsl.siol.net) 09.06.33 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.152) 09.12.36 Quit funman (Quit: free(random());) 09.18.32 Join [Saint] [0] (S_a_i_n_t@203.184.1.14) 09.19.15 Quit S_a_i_n_t (Ping timeout: 264 seconds) 09.19.27 Nick [Saint] is now known as S_a_i_n_t (S_a_i_n_t@203.184.1.14) 09.26.33 Join Rob2223 [0] (~Miranda@p4FDCBF32.dip.t-dialin.net) 09.28.32 Join giovanni_ [0] (~giovanni@93.37.240.206) 09.28.54 # hello! 09.28.56 Join petur [0] (~petur@rockbox/developer/petur) 09.30.33 Quit Rob2222 (Ping timeout: 276 seconds) 09.32.56 # I just updated the theme 'FullTouch' for ondavx777, please take a look, I am very pleased with the result. 09.34.22 # And, if there is someone who ca do it, please, rename the theme from 'FullTouch 0.1' to 'FullTouch', thanks 09.37.30 # giovanni_: why didn't you just replace the theme? 09.37.42 # why rename it with +0.1? 09.41.43 Quit TheSeven (Ping timeout: 240 seconds) 09.47.07 Quit S_a_i_n_t (Ping timeout: 240 seconds) 09.48.08 # ji 09.48.12 # hi... 09.48.30 # because I didn't understand well how to update a theme 09.49.42 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.6.119) 09.49.43 # S_a_i_n_t: Now I've learned 09.54.39 Join T44 [0] (~Topy44@g228140127.adsl.alicedsl.de) 09.58.54 Quit Topy44 (Ping timeout: 265 seconds) 10.00.31 Quit JdGordon| (Quit: leaving) 10.02.51 Join Jaykay [0] (~chatzilla@p5DC576EB.dip.t-dialin.net) 10.05.08 Join rob [0] (~nnscript@adsl-76-235-191-177.dsl.klmzmi.sbcglobal.net) 10.05.47 Quit kadoban (Remote host closed the connection) 10.06.51 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 10.07.00 Quit user890104 (Read error: Connection reset by peer) 10.07.06 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 10.15.05 Quit lostlogic (Read error: Connection reset by peer) 10.15.25 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 10.52.03 Quit sasquatch (Quit: WeeChat 0.3.2) 10.52.27 Join sasquatch [0] (~username@p4FF2D6E5.dip.t-dialin.net) 10.55.04 *** Saving seen data "./dancer.seen" 11.10.01 Quit user890104 (Ping timeout: 272 seconds) 11.12.11 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.21.05 Join TheSphinX^ [0] (~cold@p54A5BE7A.dip.t-dialin.net) 11.24.03 Quit simabeis_ (Ping timeout: 264 seconds) 11.26.38 Join simabeis [0] (~simabeis@lobmenschen.de) 11.29.54 Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-130.pools.arcor-ip.net) 11.40.44 Quit l403 (Ping timeout: 240 seconds) 11.41.26 Join l403 [0] (~l@gw8.vslesy.cz) 11.45.58 Quit jae (Ping timeout: 272 seconds) 11.46.36 Join jae [0] (~jae@jaerhard.com) 11.57.50 # I've optimized my theme for the ondas DAP, this theme is touch screen friendly so probably will be good also on the android port.http://forums.rockbox.org/index.php?topic=25098.msg168459#msg168459 12.06.40 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 12.15.04 Join einhirn [0] (~Miranda@p54850656.dip0.t-ipconnect.de) 12.16.16 Quit bmbl (Ping timeout: 258 seconds) 12.16.18 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 12.16.43 Join MagusG [0] (~no@c-71-59-57-46.hsd1.ga.comcast.net) 12.19.36 Join _s1gma [0] (~d.d.derp@77.107.164.131) 12.35.11 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 12.41.57 Join user890104 [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 12.55.05 *** Saving seen data "./dancer.seen" 12.59.58 Part LinusN 13.18.13 Quit fxb__ (Ping timeout: 276 seconds) 13.29.21 Join LinusN [0] (~linus@rockbox/developer/LinusN) 13.29.23 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.36.59 Join esperegu [0] (~quassel@145.116.15.244) 13.56.46 Join h3po [0] (~h3po@p4FDE8C84.dip0.t-ipconnect.de) 14.01.00 Quit S_a_i_n_t (Ping timeout: 245 seconds) 14.10.58 Quit parafin (Ping timeout: 246 seconds) 14.12.12 Join parafin [0] (parafin@paraf.in) 14.26.33 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 14.29.27 Quit Zarggg (Quit: Zarggg) 14.49.28 Quit balintx (Ping timeout: 265 seconds) 14.55.09 *** Saving seen data "./dancer.seen" 14.56.28 Quit bmbl (Read error: Connection reset by peer) 14.58.04 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 14.58.38 Quit giovanni_ (Quit: Sto andando via) 14.59.33 Quit togetic (Ping timeout: 265 seconds) 15.00.52 Join balintx [0] (~balintx@fibhost-67-58-201.fibernet.hu) 15.06.43 Join user890104_ [0] (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 15.08.13 Join bug2000 [0] (~bug@unaffiliated/bug2000) 15.08.31 # Where do I get Sansa Clip boot loader v2.0? The file linked in the manual seems to be v1.0 15.08.48 Quit user890104 (Ping timeout: 272 seconds) 15.15.20 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.73) 15.16.16 Quit TheSphinX^ (Quit: XChat) 15.16.16 Quit dfkt (Read error: Connection reset by peer) 15.16.21 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.19.25 Nick user890104_ is now known as user890104 (Venci@Venci-Notebook-LAN.ipv6.6bez10.info) 15.21.30 Join DexterLB [0] (~angel@95-42-14-209.btc-net.bg) 15.21.37 # hello 15.21.43 # how do I disable the database? 15.22.52 Quit S_a_i_n_t (Ping timeout: 264 seconds) 15.22.56 Quit krazykit (Quit: Connection reset by beer) 15.24.18 Quit DexterLB (Quit: So long and thanks for all the fish!) 15.24.29 Join S_a_i_n_t [0] (~st.lasciv@203.184.0.34) 15.25.49 Quit h3po (Quit: Leaving.) 15.29.40 Join {phoenix} [0] (~dirk@p57AA5F71.dip.t-dialin.net) 15.34.25 Join [Saint] [0] (S_a_i_n_t@203.184.0.70) 15.34.31 Join anewuser [0] (anewuser@unaffiliated/anewuser) 15.34.31 Quit S_a_i_n_t (Ping timeout: 276 seconds) 15.35.56 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 15.36.05 # [Saint]: ping? 15.36.36 # <[Saint]> yo. 15.37.08 # hey, free to test a fix for that %t(0) issue? 15.38.21 # <[Saint]> Not right this very second...but, if you pastebin it, I could do it at some point overnight. 15.38.48 # ok, will do 15.39.04 # <[Saint]> ...sorry, I would, but...kinda busy with IRL stuff :/ 15.39.14 # I'm not exactly happy with this fix though :/ 15.39.15 # no worries 15.41.00 Quit hebz0rl (Quit: Ex-Chat) 15.41.24 Join Strife89 [0] (~Strife89@64.134.150.78) 15.41.52 Join krazykit [0] (~kkit@206.183.182.189) 15.42.15 # [Saint]: http://www.rockbox.org/tracker/task/11588 15.42.58 Join giovanni_ [0] (~giovanni@93.37.240.206) 15.47.06 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.48.55 Nick [Saint] is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.70) 15.50.22 Part LinusN 16.03.03 # bug2000: http://download.rockbox.org/bootloader/sandisk-sansa/clip/ 16.03.34 # mc2739: It's 1.0 16.06.23 # bug2000: hmm, you are correct. I guess they ever got uploaded to the server. 16.06.44 # ping funman and he should be able to help you out 16.07.27 # Yey memoserv! ^_^ 16.15.51 Quit T44 (Quit: Leaving) 16.22.52 Quit jae (Ping timeout: 264 seconds) 16.23.08 Join jae [0] (~jae@jaerhard.com) 16.29.02 Quit jae (Ping timeout: 265 seconds) 16.29.38 Join jae [0] (~jae@jaerhard.com) 16.39.25 Join fip [0] (~inti@wirenat2.strw.leidenuniv.nl) 16.40.31 Quit giovanni_ (Quit: Sto andando via) 16.41.29 Quit pamaury (Remote host closed the connection) 16.42.30 Quit jae (Ping timeout: 265 seconds) 16.42.50 Join jae [0] (~jae@jaerhard.com) 16.51.01 Part fip 16.54.40 Quit bmbl (Quit: Bye!) 16.55.11 *** Saving seen data "./dancer.seen" 17.00.05 Join [sko] [0] (~sko]@p57A9847D.dip0.t-ipconnect.de) 17.03.15 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 17.03.23 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 17.03.56 Part Zagor 17.07.38 Quit [sko] (Ping timeout: 265 seconds) 17.08.00 Join [sko] [0] (~sko]@p57A985DF.dip0.t-ipconnect.de) 17.08.42 Join pamaury [0] (~quassel@sal63-1-82-243-96-220.fbx.proxad.net) 17.08.42 Quit pamaury (Changing host) 17.08.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.19.18 Join G4Oblivion [0] (~48281c8e@giant.haxx.se) 17.20.55 # Removing "call_storage_idle_notifys(false);" in nand-nano2g.c line 726 and its brackets fixed the *PANIC* stkov nand crashes. 17.21.47 # G4Oblivion: I haven't caught up with TheSeven yet, but, I suspect he'll find an elegant solution. 17.22.10 # Ok. Just letting it be known that thats whats causing the problems. 17.22.10 # It's all his code in nand-nano2g.c anyway IIUC 17.22.14 # G4Oblivion: that's what I suspected 17.22.15 # * docgnome sighs 17.22.20 # i hate getting stuff from usps 17.22.22 # so sloooow 17.22.26 # my question is just what has changed with that callback 17.22.38 # it used to work some hundred revisions ago, and it still works for me 17.22.46 # if anyone can bisect it, i would be very glad 17.22.54 # g4 did 17.23.01 # I posted about it earlier 17.23.04 # did he get an exact revision number? 17.23.09 # * TheSeven apparently missed it 17.23.10 # Yes. r27020 17.23.10 # apparently, yes. 17.25.43 # G4Oblivion: You left before I could finish telling you, but, my "fix" for the panic was/is to change DEFAULT_STACK_SIZE to 0x1000 ;) 17.25.51 # Do people who suffer from this use the database or the scrobbler feature? 17.26.13 # gevaerts: I use database, but, I've never scrobbled in my life 17.26.47 # I saw that. My temporary fix is working fine for me though. 17.26.47 # G4Oblivion: Can you please see if you can confirm a bug I'm seeing? 17.26.59 # now this is strange 17.27.02 # There aren't *that* many places that register idle callbacks, and if commenting out the call_storage_idle_notifys() call "fixes" the issue, one of them could be the problem 17.27.04 # Sure. 17.27.22 # so this has been happening all the time since we added that callback? 17.27.33 # why is it using more stack for some people and not for others? 17.27.41 # G4Oblivion: Try skipping traks (whilst playing) as fast as you possibly can...it *should* crash with an undefined instruction. 17.27.49 # apparently this happens when something called by the callback tries to actually write to a file 17.28.06 # which points towards the stack size increase actually being the right fix for it, not just a workaround 17.28.11 # Should I do this with default rockbox or 0x1000? 17.28.22 # G4Oblivion: Doesn't matetr. 17.28.31 # it's unrelated AFAIK 17.28.38 # Ok. let me go grab my nano 17.29.06 # TheSeven: 0x1000 seems a little bit extreme though. 17.29.20 # try 0xc00 17.29.39 # 0x800 is needed for the fsinfo sector buffer alone, and the must be some bytes left for other things 17.29.41 # You shouldn't have to increase DEFAULT_STACK_SIZE. Just the nand_stack in nand-nano2g.c should be enough 17.29.45 # it's what I had to push it to to guarantee it wouldn't panic, but, I'll try that. 17.29.48 # i'd probably go for default + 0x800 17.30.14 # gevaerts: let's get rid of those damn on-stack sector buffers 17.30.18 # isn't default 0x400? 17.30.24 # yep 17.30.34 # so...1200 total? 17.30.38 # 0xc00 17.30.43 # it is, yes 17.30.56 # I started a song in database and tried skipping tracks as fast as I could and did not get a crash. 17.31.05 # fuck. 17.31.09 # I mean..good. 17.31.10 # gevaerts, pamaury: i have proof of concept code for that in embios, which uses a central static (and properly synchronized) scratch buffer in all places that used to use on-stack buffers 17.31.18 # but, weird I'm seeing it on all my 2Gs 17.31.34 # could it be your config? 17.31.53 # G4Oblivion: I can reproduce it with default settings 17.32.06 # on multiple different buikds, aslo. 17.32.09 # * TheSeven can't 17.32.10 # *builds. 17.32.15 # I gotta go. I will test it more later. 17.32.22 # TheSeven: Really? Aaaawww...shit. 17.32.23 # G4Oblivion: if you trigger lots of activity, it will be less likely to crash I think 17.32.31 # the Nano2G is just a barrel of laughs no? 17.33.09 # gevaerts: With my Nanos, skipping say 6~10 tracks in a row will almost guaranteed crash the player. 17.33.10 Quit G4Oblivion (Quit: CGI:IRC (EOF)) 17.33.30 # S_a_i_n_t: do you do ratings? 17.33.43 # this isn't doing "skip..think about it for a bit...skip another, listen to that for a short time...skip again" 17.33.43 # I mean, "gather runtime data"? 17.33.53 # but rather "skip, skip, skip, skip" etc. 17.34.02 # gevaerts: yes. 17.34.13 # but, that's not a default setting, is it? 17.34.16 # S_a_i_n_t: can you make it crash if you disable that? 17.34.22 # no, I think it's off by default 17.34.22 # I can reproduce with a default .cfg 17.34.31 # hm 17.35.49 # gevaerts: The Nano2G is some cruel bitch...really. This NAND bug that's been plagueing many a user, is completely unreproducable by TheSeven 17.36.11 # so it kinda doesn't surprise me that I have a weird unreproducable bug also ;) 17.36.18 # S_a_i_n_t: there's a call to register_storage_idle_func() in apps/tagcache.c, and one in apps/playlist.c. If you comment those out, does it still crash? What if you comment them out separately? 17.36.34 # S_a_i_n_t: did you confirm that it happened for you with the very same build i am using, which i sent you some days ago? 17.36.53 # gevaerts: I'll have to get back to you on that one...doing IRL work, not RB stuff at the moment. 17.37.09 # There are also registrations from battery_bench, scrobbler, and settings, but settings should be irrelevant I think, and the other two aren't used by default 17.37.10 # gevaerts: my suspicion is that everything triggering an fsinfo update, so probably everything that allocates a new cluster, will trigger it 17.37.16 # TheSeven: Yeah...that build failed for me. 17.37.24 # now that's interesting 17.37.24 # TheSeven: but then why aren 17.37.29 # I suspected it would. 17.37.29 # 't some people seeing it? 17.37.50 # it must be related to some files on the player 17.38.06 # or maybe cluster size 17.38.29 # S_a_i_n_t: note that if you comment those out, some bits will not save data, so don't use those builds for too long 17.38.31 # TheSeven: That's what I thought...but, I tried it with *just* the OF and the RB installation...still panic'd 17.39.09 # TheSeven: perhaps you don;t see it, as you have no OF? 17.39.10 # * TheSeven has a superfloppy-formatted 8k cluster size ipod 17.39.30 # i doubt that stuff outside of .rockbox is related to it 17.39.37 # (besides maybe music files) 17.39.41 # Ah, hmmm. 17.40.15 # well...as I said, I tried it with just RB and the OF, and still it panic'd at boot. 17.40.30 # how is your ipod formatted/partitioned? 17.40.36 # occasionally I can get to the menu, but as soon as I scroll, or select something...boom. 17.41.01 # TheSeven: They're all "as it comes" from iTunes/Windows 17.41.41 # aha... that may be related then 17.42.01 # at least it would explain why i'm not experiencing it with iloader 17.42.11 # didn't use an rb bootloader for ages 17.43.18 # The GF has temporarily misplaced (for an extended period of time) the iLoadered Nano2G I have floating around. 17.43.34 # methinks it to be in the car, somewhere. 17.43.44 Quit Strife89 (Read error: Connection reset by peer) 17.43.58 Join Strife89 [0] (~Strife89@64.134.150.78) 17.45.44 # well, it's pretty clear. update_fsinfo() uses an on-stack sector, i.e. 0x800 bytes. The idle callback thread uses a 0x400 bytes stack. That *can't* work 17.46.21 # hm, no 17.46.24 # * gevaerts is confused 17.46.34 # It's a 0x400*sizeof(long) stack 17.49.40 # * or /? 17.50.04 # well, long[DEFAULT_STACK_SIZE] 17.50.11 # / would make way more sense 17.50.34 # which means char[DEFAULT_STACK_SIZE*sizeof(long)] if you want bytes 17.50.42 # ah, so it's just 0x400?` 17.50.53 # yes, but it's 0x400 longs 17.50.56 # * TheSeven thought you meant that DEFAULT_STACK_SIZE == 0x400*sizeof(long) 17.51.20 # hmm, so it's apparently two sector buffers then 17.51.45 # writing a direntry that causes a cluster allocation? that might have two of them 17.52.27 Quit rob (Disconnected by services) 17.52.41 # update_fsinfo() is usually called at the end of functions that don't have big stack usage themselves, so it *should* be safe against that if I read the code correctly 17.53.34 # ah, no 17.54.35 # fat_create_dir() and fat_rename() are suspect 17.55.00 # They use a sector buffer of their own, and call fat_flush() which calls update_fsinfo() which also has a sector buffer 17.55.53 Quit anewuser (Quit: FAMICOMPO 7 - August 15 Through August 31 JST - http://midr2.under.jp/compo/vol7/index.html) 17.56.49 # their own sector buffer isn't needed at that place any more, is it? 17.57.23 # could adding a set of braces to reduce its scope help? or will the compiler still keep it allocated until the end of the function for performance reasons? 17.57.25 # no idea 17.57.38 # ah, yes, a new block might help 17.59.47 # what do you think is more likely to happen in a storage idle callback? creating a dir or renaming something? 17.59.53 Join r0b- [0] (~nnscript@adsl-76-235-191-177.dsl.klmzmi.sbcglobal.net) 17.59.55 # renaming 18.00.25 # One of them is saving the playlist control file, the other is saving some database things. Neither even involves directories 18.00.32 # hmm, things being written to a temp file and then swapped around for safety? 18.00.42 # yes, that's what I'm thinking 18.02.00 Quit petur (Quit: *plop*) 18.04.05 Quit Strife89 (Quit: Departure.) 18.04.12 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.08.08 Quit bug2000 (Ping timeout: 276 seconds) 18.08.47 Join Lear [0] (chatzilla@rockbox/developer/lear) 18.11.57 # * TheSeven should probably add some logging 18.12.11 Quit [sko] (Read error: Connection reset by peer) 18.12.26 Quit lostlogic (Quit: leaving) 18.13.48 # actually we should add a way to dump the logf buffer, or just the entire memory, after a panic via usb or something 18.17.21 # better to just set up a console via usb 18.17.31 # you can't count on anything working after a panic has happened 18.17.38 # i wrote a patch ages ago that just continuously dumped the logf buffer to disk 18.17.55 # that's not very helpful if the storage code is broken :) 18.19.33 # i think there are ways to do usb-based post-mortem memory dumps that are more likely to succeed than the printing of the panic message 18.20.21 # and a usb console will either slow down things dramatically or lose the last (and probably most important) part of the log 18.24.58 Quit l403 (Ping timeout: 265 seconds) 18.25.22 Join fxb__ [0] (~felixbrun@h1252615.stratoserver.net) 18.26.11 Join lostlogic [0] (~lostlogic@rockbox/developer/lostlogic) 18.27.08 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.34.51 Join [Saint] [0] (S_a_i_n_t@203.184.0.70) 18.35.06 # <[Saint]> man, what a time to fall off the net :/ 18.35.06 Quit S_a_i_n_t (Ping timeout: 252 seconds) 18.35.27 # <[Saint]> fxb__: I can't reach http://www.felixbruns.de/iPod/firmware/ , is it known broken? 18.35.44 Join l403 [0] (~l@gw8.vslesy.cz) 18.35.52 # <[Saint]> Or, can you suggest anywhere else I can pull a .ipsw file? 18.42.39 # [Saint]: i can acces that page, but the list of ipod firmware is empty 18.43.08 # ah, works now 18.47.00 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.47.59 # <[Saint]> n1s: I can't acess it, nor can "downforeveryoneorjustme"...weird. 18.48.18 # <[Saint]> I guess it has something to do with my locality. 18.48.46 Quit Barahir (Ping timeout: 240 seconds) 18.49.31 # [Saint]: I can access it now but couldn't earlier - did you try a forced refresh or a different browser? 18.50.28 # <[Saint]> pixelma: Yes, I tried different browsers...and tried deleting my caches, etc. :/ 18.50.44 Join Barahir [0] (~jonathan@frnk-590f6a32.pool.mediaWays.net) 18.50.46 # <[Saint]> downforeveryoneorjustme can reach it now...but I still can't :/ 18.50.58 # <[Saint]> I assume I'll be able to in time, not important I guess. 18.51.32 Nick [Saint] is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.70) 18.55.15 *** Saving seen data "./dancer.seen" 19.01.50 Join h3po [0] (~h3po@p4FDE8C84.dip0.t-ipconnect.de) 19.09.28 Join Jerom [0] (~jerome@95.171.131.249) 19.11.04 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.20.41 Quit {phoenix} (Remote host closed the connection) 19.24.51 # TheSeven: I just notices you ping me, I don't understand what you mean 19.25.40 # Ah yes I get it. You would like to copy their model/code ? Or it's just a though to justify the approach ? 19.26.13 # I guess it would be easier to debug if the simulator could emulate a driver with a file, I begun this but did not finished it 19.26.41 # TheSeven: How about a gdb stub for usb? 19.27.19 # For archos we have a gdb stub for serial, and iirc one arm target has one for usb already 19.27.37 # that's roughly what i'm thinking about, but i haven't investigated how such a thing works yet 19.28.14 Join fragilematter [0] (~barbu_dor@92.86.178.90) 19.28.17 Quit tchan (Ping timeout: 264 seconds) 19.28.23 Join bunnyboi [0] (~androgyne@cpe-72-224-19-157.nycap.res.rr.com) 19.32.25 Join toffe82 [0] (~chatzilla@12.169.218.14) 19.35.01 Quit andash (Read error: Operation timed out) 19.35.24 Quit S_a_i_n_t (Ping timeout: 240 seconds) 19.38.39 Quit guymann (Quit: -uDNav world time) 19.43.00 # hello everyone 19.43.19 Join Buschel [0] (~chatzilla@p54B66022.dip.t-dialin.net) 19.43.51 # I've got a quick question: have any of you experienced ogg vorbis decoding problems, especially on the e200v2? 19.44.30 # Can anyone with a clip+ or a fuze v1 check if FS#11476 is reproducible? (musepack sv8 seek instability) 19.44.41 # I cannot reproduce this at all... 19.45.39 # sv8 files are availabel here -> http://samples.mplayerhq.hu/A-codecs/musepack/sv8/ 19.46.20 Join Lear_ [0] (chatzilla@rockbox/developer/lear) 19.48.04 Join Lear__ [0] (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net) 19.48.36 Quit Lear (Ping timeout: 272 seconds) 19.48.45 Nick Lear__ is now known as Lear (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net) 19.50.02 Join evilnick [0] (~evilnick@mobile-166-137-139-226.mycingular.net) 19.50.23 # bluebroth3r, domonoky: I suspect we can do FS#11580 (the ipod video merge) more or less independently from a new rockbox utility release 19.51.22 # If the merge is first but we leave both build for a while, the transition will be transparent. If the new rockbox utility configuration is first, people will just get a 32mb build for a while. 19.51.34 Quit Lear_ (Ping timeout: 265 seconds) 19.52.43 # commit 19.55.14 # I'd like one or two more test reports. Right now I only have two. One from creposucre on a 5G 64G, and one on my 5G 30G, but I don't really use mine, so if random things break (which I don't expect), I wouldn't notice 19.57.22 Join Buschel_ [0] (~chatzilla@p54B66022.dip.t-dialin.net) 19.57.36 Join andash_ [0] (~andash@unaffiliated/andash) 19.58.49 Quit Buschel (Ping timeout: 265 seconds) 19.58.49 Nick Buschel_ is now known as Buschel (~chatzilla@p54B66022.dip.t-dialin.net) 19.59.42 # gevaerts: good point 20.01.03 # bluebroth3r: if I commit in the next one or two days, I guess I'll just leave both builds around until rockbox utility is ready 20.02.28 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 20.03.08 Part Transformer 20.03.54 Quit bunnyboi (Quit: IRC is just multiplayer notepad) 20.11.02 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.147) 20.12.21 Quit Buschel (Ping timeout: 240 seconds) 20.12.25 Quit evilnick (Quit: evilnick) 20.23.09 Join Buschel [0] (~chatzilla@p54B66022.dip.t-dialin.net) 20.26.19 Quit Jerom (Quit: Leaving.) 20.26.36 Quit andash_ (Read error: Operation timed out) 20.27.11 Join Jerom [0] (~heidi@95.171.131.249) 20.27.20 Quit kadoban (Ping timeout: 265 seconds) 20.27.50 Quit Dreamxtreme (Quit: I was raided by the FBI and all I got to keep was this lousy quit message!) 20.28.42 Join fip [0] (~inti@5356EAD1.cable.casema.nl) 20.28.56 Join kaiscene [0] (kaiscene@ool-18e45d82.dyn.optonline.net) 20.29.42 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 20.30.41 Join andash [0] (~andash@unaffiliated/andash) 20.32.41 Quit andash (Read error: Operation timed out) 20.33.41 Join andash [0] (~andash@h-120-242.A254.priv.bahnhof.se) 20.33.41 Quit andash (Changing host) 20.33.41 Join andash [0] (~andash@unaffiliated/andash) 20.34.35 Quit kadoban (Ping timeout: 265 seconds) 20.38.49 Join evilnick [0] (~evilnick@mobile-166-137-137-205.mycingular.net) 20.39.30 Quit stoffel (Remote host closed the connection) 20.47.20 Quit andash (Read error: Operation timed out) 20.50.03 # gevaerts: You have a couple of reports in the test builds forum, no? 20.50.17 Join andash_ [0] (~andash@unaffiliated/andash) 20.50.46 # AlexP: well, soap's report seems more like "The initial numbers look OK" 20.51.50 # Nothing has gone wrong in my extensive testing :) 20.52.16 Quit andash_ (Read error: Operation timed out) 20.52.31 # * gevaerts accuses AlexP of not having an ipod video! 20.52.44 # That's a minor detail :) 20.53.47 Join andash [0] (~andash@h-120-242.A254.priv.bahnhof.se) 20.53.47 Quit andash (Changing host) 20.53.47 Join andash [0] (~andash@unaffiliated/andash) 20.53.52 # It does qualify what you mean by "extensive" though :) 20.54.10 Part evilnick 20.54.21 # On the other hand, the 64mb build *really* shouldn't see any changes 20.55.16 *** Saving seen data "./dancer.seen" 20.55.37 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 20.58.15 # Maybe I should just learn to live dangerously every now and then... 20.59.26 Join [sko] [0] (~sko]@p57A985DF.dip0.t-ipconnect.de) 21.00.53 Quit n1s (Ping timeout: 276 seconds) 21.03.25 # gevaerts: It is obviously good to ask for testers first, but I suspect something like this won't see widespread testing until it is committed 21.06.36 # * gevaerts kicks CIA-81 21.07.40 # ow 21.07.50 # CIA-81: get on with it! 21.08.12 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.08.14 # We don't need lazy bots! We can be lazy on our own if needed! 21.08.51 # New commit by 03gevaerts (r27959): remove the memory specification from ipod video builds in preparation of r27960. The 64mb build will be removed later when supporting infrastructure ... 21.08.51 # New commit by 03gevaerts (r27960): Unify 32mb and 64mb ipod video builds - FS#11580 ... 21.08.51 # r27960 build result: All green 21.10.56 Quit andash (Read error: Operation timed out) 21.11.31 Part fragilematter 21.11.49 # Yay, md5sum tells me that the ipodvideo and ipodvideo64mb builds are now exactly identical :) 21.14.59 # it would still be nice to handle the default battery capacity 21.15.55 # Yes, but I don't see a nice (and clean) way to do that right now 21.19.32 # One problem is that the settings code really isn't made to support non-constant default values 21.19.41 # Good work chaps 21.19.42 # gevaerts: what was the status regarding ata.c and (MEM == 64)? with your change this special treatment is also used for the 32MB variant of te ipod video 21.19.53 # gevaerts: is this special treatment still needed? 21.21.20 # Buschel: I have no idea if it's still needed or not. The svn logs show that it's been enabled and disabled several times. The only thing I know is that I believe that *if* it's needed, not enabling it on the 32MB builds is a bug, since those can run with the 80GB large sector drives too 21.21.58 # gevaerts: true, the fix was introduced for large HDDs... 21.24.02 # Yes. The commit message says "for iPod 5.5g 60GB and/or 80GB", and the code checks for 64MB... 21.27.19 # Buschel: actually, you should know all about this. You're the one who opened FS#8568 :) 21.28.03 # yes, but I own a 30GB variant. The user who actually had problems was Horscht. 21.28.35 # presumably the problem was that the locking required for the large sector stuff was really slow 21.28.50 # hence replacing it with a weird custom spinlock 21.29.14 # in which case it's probably really slow any time the large sector code is actually used.. 21.29.54 # Is this stuff still needed for the large HDD's? Or is obselete with the large-HDD-support changes (r25646)? 21.30.23 # hrm? 21.30.31 # was that me? 21.30.43 # yes :-) 21.30.50 # i just hacked it so it only actually uses the emulation code if it has to 21.31.10 # the "large hdd support"w as mostly just turning lba48 on by default on everything 21.31.26 # it still needs to do all the same stuff for the drive that has the problem 21.32.22 # ok, at least we might remove the "&& MEM == 64" then. as this is true now. 21.32.41 # didn't you already remove that, gevaerts? 21.32.59 # no. I decided to leave that out of this patch, since it's really unrelated 21.33.02 # ah 21.33.13 # someone should test it without that code and see if it actually makes any difference 21.33.27 # it seems weird having a single weird custom spinlock thing that's only used by one target in one place 21.33.39 # if we can throw it away entirely we can drop those odd macros out of kernel.c 21.34.09 # Yes, so we really need to find someone with that sort of ipod :) 21.34.13 # (and time) 21.34.40 # Horscht: you there? 21.34.42 # :) 21.34.57 # Buschel: gevaerts probably is hinting at me ;) 21.35.11 # * gevaerts wouldn't dare! 21.35.21 # hinting is a waste of time 21.35.25 # Torne: test it! 21.35.30 # See, much better :) 21.35.41 # can't be bothered at the moment 21.35.43 # talk is cheap :) 21.35.45 # hehe :) 21.35.59 # Torne: send me your ipod. I'll test :) 21.36.11 # i need my ipod for french electro house music 21.36.24 # apparently not anything else any more, according to my last.fm history 21.37.54 Quit TheSeven (Ping timeout: 265 seconds) 21.41.28 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.42.14 Quit stripwax (Client Quit) 21.43.16 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.44.46 Join captainkewllll [0] (2669ecc2@gateway/web/freenode/ip.38.105.236.194) 21.45.09 Quit gevaerts (Ping timeout: 240 seconds) 21.49.05 Join AndyI [0] (~pasha_int@212.14.205.32) 21.52.16 Quit [sko] (Quit: Leaving.) 21.52.23 Join yelped [0] (~ad44250b@giant.haxx.se) 21.53.00 # New Fuze+ Released : http://www.sandisk.com/microsites/sansafuzeplus/index.html 21.53.22 Quit Buschel (Ping timeout: 265 seconds) 21.53.47 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 21.55.34 # I suspect funman will have some lengthy nights in the following weeks :) 21.58.50 # i saw theres a new phillips mp3 player running android, so in theory we could run on that too 21.59.39 # yay! it uses a non-proprietary port 22.01.19 # Not so yay is the lack of full reviews so far. 22.01.52 # When the Clip+ was released ABI had their review up the same day. 22.02.16 # However they still didn't review Cowon J3 yet. 22.02.47 # The're very behind on a lot of things, however they did promise to get better. 22.10.03 # what's new in Fuze+? 22.10.06 # Just µSD? 22.10.09 # and new firmware? 22.10.58 Join h3po1 [0] (~h3po@p4FDE8D83.dip0.t-ipconnect.de) 22.11.23 Quit h3po1 (Client Quit) 22.13.50 Quit h3po (Ping timeout: 276 seconds) 22.14.09 # µSD isn't new. 22.14.56 # More Formats; AAC for audio, WMV, H.264, Flip, for Video. 22.15.11 # New design. 22.15.17 # More Capacity. 22.15.31 # Better, Bigger OLED screen. 22.15.42 # k 22.16.06 # uses a micro USB connection like the clip 22.16.46 # I thought it was mini USB on the Clip 22.16.49 # yelped: where does it say oled? 22.16.50 # I guess that means they gave up on docks. 22.17.26 # it says LCD right on the page yelped linked 22.17.58 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 22.18.08 # Kohlrabi: Bigger screen, touch stuff. Fuze already had µSD. 22.19.29 # k 22.19.44 # very disappointing in other words 22.19.56 # http://www.dapreview.net/comment.php?comment.news.4715 22.20.01 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 22.20.02 # Most certainly no upgrade for existing users 22.20.04 # kaiscene, the clip doesn't use micro USB, it has mini USB 22.20.14 # * gevaerts doesn't really like power cuts 22.20.15 # But looking at Clip+ vs. Clip, probably the UI got a facelift, too 22.20.28 # i always confuse the two. micro/mini usb 22.21.44 Quit leavittx_ (Ping timeout: 240 seconds) 22.22.06 Quit leavittx (Ping timeout: 240 seconds) 22.23.09 # The screenshot from Dapreview says OLED. 22.26.50 Join krabador [0] (~darkham@host99-54-dynamic.244-95-r.retail.telecomitalia.it) 22.27.22 Quit bmbl (Quit: Bye!) 22.30.42 Join andash [0] (~andash@h-120-242.A254.priv.bahnhof.se) 22.30.42 Quit yelped (Quit: CGI:IRC (EOF)) 22.30.42 Quit andash (Changing host) 22.30.42 Join andash [0] (~andash@unaffiliated/andash) 22.31.24 Quit stripwax (Quit: http://miranda-im.org) 22.35.28 Join leavittx [0] (~leavittx@89.221.199.187) 22.35.31 Join guymann [0] (~charlie@66-159-136-17.adsl.snet.net) 22.35.40 Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) 22.38.58 Quit Jaykay (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]) 22.46.49 Join evilnick [0] (~evilnick@mobile-166-137-139-122.mycingular.net) 22.47.21 Join [Saint] [0] (S_a_i_n_t@203.184.0.206) 22.48.14 Join fyre^OS [0] (~nnscript@cpe-68-173-233-99.nyc.res.rr.com) 22.49.21 Quit fyrestorm (Ping timeout: 245 seconds) 22.49.50 # * Horscht returns 22.50.05 # what did Buschel want earlier? 22.50.23 Quit S_a_i_n_t (Ping timeout: 272 seconds) 22.50.52 Quit evilnick (Client Quit) 22.51.02 # Horscht: do you remember FS#8568 ? 22.51.23 # We'd like to find out if the workaround introduced back then is still needed 22.52.21 # ah, the "let-my-harddrive-spin-insanely-long"-issue? 22.53.03 # that's the one! 22.53.14 Quit bertrik (Ping timeout: 265 seconds) 22.53.18 # ok, I do remember it, yes 22.53.46 Quit jae (Read error: Operation timed out) 22.53.52 # so, what do I need to do in order to help you? 22.54.03 # compile a build with a certain patch? 22.54.08 # Yes, basically 22.54.15 Join evilnick [0] (~evilnick@mobile-166-137-139-122.mycingular.net) 22.54.24 # And compare that with a standard build 22.54.47 # I just hope that my virtual machine still works... 22.55.07 # haven't compiled rockbox in a while... 22.55.11 # I can provide a build if that helps 22.55.17 *** Saving seen data "./dancer.seen" 22.55.27 # probably faster that way... 22.55.47 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 22.57.46 # I wonder if/how the PP caches work with the dual memory mapping in the ipods 22.58.11 # currently, I am running an "ancient" build anyways.... a mid july build 22.58.47 # Horscht: http://www.evonet.be/~gevaerts/rockbox-test.zip 22.59.13 # That's r27960 with that workaround disabled 22.59.21 # that was quick, my VM hasn't booted by now 23.02.15 Join hebz0rl [0] (~hebz0rl@dslb-088-065-053-130.pools.arcor-ip.net) 23.03.10 # oh, great... now my wps wont work anymore :p 23.03.32 # You could try the upgrade tool 23.04.00 # did you chamge the wps code again? 23.04.07 Join jae [0] (~jae@jaerhard.com) 23.04.15 # hm, wait 23.04.22 # anyways: "regular" build = 1:20 seconds until spindown 23.04.24 # * gevaerts doesn't remember when the last change was 23.04.54 # gonna test your build now 23.07.36 Part fip 23.09.24 Quit krabador (Quit: Sto andando via) 23.11.19 Quit evilnick (Quit: evilnick) 23.12.34 # hm... just above 2 minutes... but hardly any consistent disk activity, just a small "read" every 3 - 4 seconds 23.12.48 Join G4Oblivion [0] (~chatzilla@user-142g74e.cable.mindspring.com) 23.13.20 # Maybe try copying a few files using both builds? 23.13.30 # (preferably the same files each time) 23.13.48 # Anyway, two minutes is a lot more than 1:20... 23.13.48 # wait, copying? 23.14.14 # You can copy files in the file browser :) 23.14.32 # I think we might be mixing up issues here. The issue I though we were talking about was heavy and long disk activity during music buffering 23.14.47 # It is, yes 23.15.06 # But I'd expect a file copy to show that as well 23.15.46 # make fails when I use -j2. current build from svn. http://pastie.org/1129972 23.15.53 # [Saint]: I could not reproduce your track skipping bug. 23.16.41 # Horscht: what is your spin down timeout set to? 23.17.53 # hm, default is five seconds. If we're talking about two minute times, five seconds is negligible 23.17.54 # kugel: the caches undoubtedly *don't* work with the dual memory mapping :0 23.18.05 Join clone4crw [0] (~calvin@96-42-90-88.dhcp.roch.mn.charter.com) 23.18.07 Join huffpuff [0] (~matthew@h181.29.188.173.dynamic.ip.windstream.net) 23.18.10 # kugel: so it's important that any 16byte part of memory is only accessed via one mirror or the other 23.18.22 # gevaerts, default. 5 seconds 23.18.41 # i retested with the current build, 1:20 minues 23.18.54 # your patched build: 2 minutes 23.18.56 # ok, so it's really a 40 second difference 23.19.06 # That means it's *not* gone away 23.19.14 Quit G4Oblivion (Quit: ChatZilla 0.9.86 [Firefox 4.0b4/20100818120848]) 23.19.40 # not entirely, no. It seems to have gotten less severe, though 23.20.04 # Yes, but I don't think we can remove the workaround 23.20.39 # well the next question is what's the actual issue :) 23.20.41 # my initial reports from the flyspray say 1:20 v 2:30 and iirc it was *heavy* disk activity for the whole 2 minutes back then 23.21.02 # Horscht: we use DMA now, though, so timings won't be comparable 23.22.25 # and now... i have to find a way to get my wps running again 23.24.12 Quit Rob2223 (Read error: Connection reset by peer) 23.25.51 Join Rob2222 [0] (~Miranda@p4FDCBF32.dip.t-dialin.net) 23.26.18 # Torne: could this be somehow vaguely related to the extremely slow font loading issue? 23.26.36 # gevaerts: quite probably 23.26.41 # well ok 23.26.42 # maybe 23.27.22 # Not very directly of course, but they're both about disk IO slowness on this drive 23.28.25 Join Om3ga [0] (~tttdddw93@ip72-219-28-228.br.br.cox.net) 23.28.36 # hello 23.28.38 # hm, since the filesystem uses 2K blocks, *most* reads should be sector-aligned I suspect, so the partial sector thing shouldn't be needed very often 23.28.44 Quit Not-iH8sn0w (Ping timeout: 240 seconds) 23.28.59 # problem with my sansa fuze 23.29.12 Join Bug2000 [0] (~bug@unaffiliated/bug2000) 23.30.14 # Om3ga: we'll need more details to be able to help :) 23.31.01 Join Dreamxtreme [0] (~Dreamxtre@92.30.98.82) 23.31.10 Join stephen__ [0] (~stephen@86.41.6.54) 23.31.22 Join evilnick [0] (~evilnick@mobile-166-137-139-122.mycingular.net) 23.31.40 # my sansa.. 23.31.47 # screen is blank 23.32.11 # the screen would only appear after 5 seconds of pressing a button 23.32.21 # just for a few seconds 23.32.32 # Torne: doesn't the PPs have magic memory regions which are the uncached pendant of the normal region? 23.32.46 # pixelma, ping 23.33.04 # kugel: only because the cache controller is set up that way 23.33.37 # right, I'm thinking the mirror of the 32MB could be some uncached variant 23.33.43 # problem with my sansa fuze 23.33.47 # my sansa.. 23.33.50 # screen is blank 23.33.54 # the screen would only appear after 5 seconds of pressing a button 23.33.59 # kugel: naw, we are just setting up the cache controller to think there is 64MB 23.34.21 Quit jae (Ping timeout: 255 seconds) 23.34.31 # kugel: I suspect an uncached codec buffer would be *quite* noticeable 23.34.49 Join Not-iH8sn0w [0] (iH8sn0w@CPE001e58fb11c8-CM000f9fa76cf2.cpe.net.cable.rogers.com) 23.35.25 # Om3ga: there's no need to repeat your question every two minutes. As soon as someone who can help sees it, they'll tell you 23.35.37 # ok. 23.35.40 # thx. 23.36.18 # i'll wait. 23.36.51 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.37.38 # Om3ga, what were you doing that made the screen go blank ? 23.39.03 Join jae [0] (~jae@93.186.200.13) 23.39.46 # hmm 23.39.56 # pixelma, (for the logs) I updated my comment on flyspray, you were correct with the revision numbers I got mixed up. 23.40.00 # i was charging my sansa with rockbox on it 23.40.08 # I also think it is to do with the remotes 23.40.11 # then my screen just went out. 23.40.21 # Torne: if I read ata.c correctly, phys_sector_mult!=1 just means that we have to be careful with aligning transfers, but actual sector sizes and thins like that are the same? 23.40.23 # have you held the power button for 30 secs ? 23.40.30 # Om3ga, ^^ 23.40.33 # hmm, i think i tried that 23.40.43 # i'll try it again 23.40.46 # gevaerts: er 23.40.50 # do it while its on ? 23.40.54 # it will turn on 23.40.58 Quit stripwax (Client Quit) 23.41.14 # Torne: I mean for the ata registers and things like that 23.41.19 # gevaerts: yes 23.41.21 # is it just the scrren thats blank ? does the click wheel light up ? 23.41.28 # gevaerts: the interface both to rockbox and hte hardware is exactly the same 23.41.33 # yep 23.41.34 # you jhust have to be careful not to do stuff that's invalid 23.41.36 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.41.37 # the wheel lights up 23.41.49 # its a fuze v2 23.41.58 # 4 gb 23.42.46 # hmmm not sure what you could try then, sounds like the screen is gone ? your best bet is to wait till funman arrives. 23.43.07 # oh no, not completely 23.43.23 # if my battery is 25% or lower, it will return 23.43.30 # or 23.43.41 # 5 seconds after i press a button 23.43.47 Quit stripwax (Client Quit) 23.43.59 # if my battery is low, my screen will work normally. 23.44.06 # is this just in rockbox ? 23.44.08 Quit huffpuff (Quit: leaving) 23.44.27 # no 23.44.31 # OF 23.44.32 # in the of too ? 23.44.39 # original firmware 23.44.42 # hardware problem then by the sounds of it 23.44.42 # yea 23.44.57 Join evilnick_ [0] (~evilnick@mobile-166-137-137-045.mycingular.net) 23.45.01 # yea, i installed rockbox on my v2 23.45.16 # then charged my sansa with rockbox operating 23.45.17 # stephen__: thanks for the info 23.45.26 Join Zarggg [0] (~zarggg@70.44.12.90.res-cmts.sm.ptd.net) 23.45.49 # just hope it gets sorted soon. 23.46.02 # wanted to get some x5 themes updated 23.46.03 Join huffpuff [0] (~matthew@h181.29.188.173.dynamic.ip.windstream.net) 23.46.42 Quit evilnick (Ping timeout: 258 seconds) 23.47.42 # Horscht: is this 1:20 or two minutes *just* buffering, or does that include e.g. boot time, dircache scan, wps load, ... 23.47.42 Quit stephen__ (Quit: Leaving) 23.47.45 # ? 23.48.32 Quit BlakeJohnson86 (Ping timeout: 245 seconds) 23.48.32 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 23.48.40 Join BlakeJohnson86 [0] (~bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 23.48.43 Nick evilnick_ is now known as evilnick (~evilnick@mobile-166-137-137-045.mycingular.net) 23.49.33 Quit jgarvey (Quit: Leaving) 23.50.28 Quit bertrik (Read error: Connection reset by peer) 23.50.46 Quit stripwax (Client Quit) 23.53.42 Quit domonoky (Read error: Connection reset by peer) 23.58.33 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 23.58.57 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)