--- Log for 04.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 5 hours ago 00.00.55 # huh using ldm is actually a bit slower for me then doing single loads ont he clipv2 00.01.16 Join jacekowski [0] (jacekowski@jacekowski.org) 00.01.23 # i wonder whats going on here 00.02.12 # New commit by 03gevaerts (r25459): Add IO priority handling. Currently all IO has equal priority, except the dircache scanning thread which is lower. This fixes the slow boot problem ... 00.04.22 # also why is memory so much faster on the e200v1 then on the clipv2 00.04.53 # gevaerts: why was the IF_MD part needed exactl now? 00.05.03 # saratoga: do you test boosted? 00.05.10 # kugel: where do you mean? 00.05.22 # kugel: no both unboosted 00.05.24 Quit xiainx (Quit: Good Bye!) 00.05.33 # saratoga: unboosted is horribly slow as far as I noticed 00.05.41 # * bertrik spots a 1:37 min build 00.05.52 # gevaerts: "Lots of the changes are due to changing storage_(read|write)sectors() from macros to wrapper functions. This means that they have to be called with IF_MD2(drive,) again." 00.07.07 # saratoga: pressing up/down boosts and unboosts just like in test_boost 00.07.12 # yeah i saw 00.07.18 # we need a higher resolution timer 00.07.42 # kugel: well, due to lots of interesting preprocessor magic, the drive argument was getting eaten without IF_MD2() in the macro case. That doesn't work for wrapper functions 00.07.43 # or bigger BUF_SIZE 00.07.44 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 00.08.02 # gah, sim... 00.08.14 # saratoga: why? 00.08.26 # the step sizes are quite large 00.09.36 # gevaerts: the trade-off was to be able to do STORAGE_FUNC() in some places? 00.09.45 # no 00.09.58 # hah ldm is 2x slower on the 200v1, so i'm doing something wrong 00.10.05 # STORAGE_FUNC() was to avoid another lot of #ifdefs 00.10.29 # "ldmda %[ptr]!, {r0, r1, r2, r3};" 00.10.34 # that should decrease the ptr variable by 16 bytes right? 00.10.37 # New commit by 03gevaerts (r25460): Don't define HAVE_IO_PRIORITY for the sim 00.11.06 # saratoga: not increase? 00.11.16 # da = decrement after 00.11.24 # ah, ok 00.11.40 # kugel: in storage.h, there are things like #define storage_get_info(drive, info) ata_get_info(IF_MD2(drive,) info) 00.11.51 # I saw that 00.11.54 # Having the IF_MD2() there is enough 00.11.59 # kugel: http://pastebin.com/V2fwBcRs 00.12.05 # see anything wrong in there? 00.12.26 # If you then change storage_get_info() to be a wrapper function, the IF_MD() is pushed back to the caller, where it used to be before the macros 00.12.46 # saratoga: any reason you go backwards? 00.13.01 # kugel: just how i wrote the loo 00.13.02 # p 00.13.32 # ok, now the real fun... 00.14.10 # saratoga: I'm no expert in inline assembly, but line 11 looks strange to me 00.17.57 Join Buschel [0] (~ab@p54A3C47F.dip.t-dialin.net) 00.18.17 # New commit by 03gevaerts (r25461): Fix some forgotten storage_(read|write)_sectors() calls 00.18.30 # saratoga: shouldn't ldmda be ldmdb (decrease before)? 00.18.59 # Buschel: does it matter? 00.19.56 # saratoga: if i am not totally wrong you may call the loop 1 time too much 00.20.04 # ah 00.20.21 # so use "ldmdb %[ptr]!, {r0, r1, r2, r3};" 00.20.53 # saratoga: yep 00.21.36 # saratoga: hmm, i was wrong: the loop will end correctly. but you will access buf[] out of range with the first call of ldma. 00.21.51 # saratoga: that moves the pointer down by 4 words, and stores r0-r3 counting up from the new location 00.25.32 # if you're looping backward starting from just beyond end-of-buffer you want ldmdb 00.25.56 # saratoga: you are doing r0 = ptr, r1 =ptr+1, ..., r3 = ptr+3. ldmda will decrease ptr after r3=..., ldmdb will decreas ptr before the first r0=... 00.26.09 # *decrease 00.26.36 # but either way its the same thing right since i just discard the values? 00.28.52 # #define BUF_SIZE ((PLUGIN_BUFFER_SIZE-(10<<10)) / (sizeof(int))) 00.28.56 # i don't understand this line 00.30.45 # well, the plugin buffer minus 10k (for the code of the plugin). / sizeof(int) because I made an int array 00.30.49 # ah ok 00.31.11 # you couldn't just do PLUGIN_BUFFER_SIZE- 10000 :) 00.31.33 # I guess I could :) 00.32.08 # 10<<10 != 10000 00.32.10 # just out of curiosity 00.32.40 # would there be any way to program an mp3 player to be used as an external sound card? 00.33.09 # dockimble: yes 00.33.11 # yes but its very close and 10KB is only approximate anyway 00.33.13 # saratoga: I think you need to align the buffer properly if you do burst access, otherwise the loop might exceed the actual buffer 00.33.49 # New commit by 03funman (r25462): Clipv2: read hold switch correctly 00.33.50 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 00.34.06 # * kugel isn't sure how to properly implement the scrollwheel irq without a useful timer 00.34.25 # wonder how.... 00.34.40 # What does the scrollwheel have to do with a timer at all? 00.34.56 # doing 32 repeats works much better on PP 00.34.56 # dockimble: have a look at http://www.rockbox.org/tracker/task/11108 00.35.19 Quit evilnick (Read error: Connection reset by peer) 00.36.14 # gevaerts: a most strange patch, that one. Just and FYI: a shortcut for thread_get_current() is THREAD_CURRENT, which thread_id_entry respects. 00.36.17 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 00.36.42 # * "THREAD_ID_CURRENT" rather 00.36.44 # amiconn: to tell the difference between 2 wheel changes 00.36.51 # ? 00.36.52 # jhMikeS: oh, right. that might have been a bit shorter 00.37.07 # okis, thanks 00.37.51 # The wheel just fires interrupts whenever it's moved, doesn't it? 00.37.54 # the time difference between two wheel changes (i.e. two interrupts), to make BUTTON_REPEAT generation and acceleration work properly 00.38.05 # http://pastebin.com/V8fQrA74 00.38.13 # the top loop is half as fast as the bottom 00.38.15 # and i have no idea why 00.38.20 # On 1st/2nd Gen ipod we're using wheel interrupts, independently of any timer 00.38.40 # ok, wow i am way too drunk to understand this now 00.38.41 # We're not generating repeat or ding acceleration 00.38.46 # it'll have to wait 00.39.53 # saratoga: Ahem, the top loop reads 16 values/iteration while the bottom one only reads 8 00.39.54 Nick Strife1989 is now known as Strife89 (~michael@adsl-154-2-63.mcn.bellsouth.net) 00.40.06 # gevaerts: it's works with any function taking a thread id, since those all pass through thread_id_entry inside 00.40.47 # amiconn: but the number of iterations should change, correct? 00.40.55 # so that each does the same number of loads 00.41.22 # saratoga: compiler optimization? "x" is assigned different values within the same loop. 00.41.43 # Ah, there's two loops. 00.41.45 # let me see what objdump says 00.41.48 # amiconn: I would like to, though 00.42.00 # It depends on the value of BUF_SIZE 00.42.27 # Also, is buf declared volatile? 00.42.36 # yep 00.42.43 # Otherwise the compiler will optimize away reads in the 2nd case 00.43.05 # the reads happen but the asm looks really weird 00.43.05 Join r2k000 [0] (~r2000@sjs-130-65-109-108.sjsu.edu) 00.43.20 Quit GeekShadow (Read error: Connection reset by peer) 00.43.21 # http://pastebin.com/jYdAtXDZ 00.43.25 # what the hell is gcc doing 00.43.32 # the usb external sound card code just needs some sort of automatic script, so that those of us with mp3 players with busted screens might use them for that 00.43.33 # On arm9 using ldm should give the same speed as plain ldr (slight variation due to instrcution caching is possible) 00.43.38 # New commit by 03gevaerts (r25463): use THREAD_ID_CURRENT instead of thread_get_current() 00.43.40 # ugh, what happened to the last build round? 00.44.58 # how the hell is doing a bunch of ldr and add opps faster then doing an LDM 00.47.02 # BUF_SIZE = 8? 00.47.09 # Disassembled the other variant? 00.47.25 # Btw, stating "memory" as a clobber is incorrect. You're just reading 00.48.20 # Also I'd use \n instead of ; . Otherwise you might run into the line length limit of the assembler for long asm() blocks 00.48.21 # BUF_SIZE is 10KB less then the plugin buffer 00.50.00 Part froggyman 00.52.26 # huh just doing a single ldmdb without unrolling gives a huge speed up on PP 00.52.50 # almost 3x as fast 00.53.45 # so i must have been miscounting before 00.56.04 # That's what's expected on arm7 00.56.33 # 4x ldr -> 12 cycles. ldm to 4 registers -> 6 cycles 00.56.57 # I guess in the former case gcc also does its silly additions 00.57.00 # yeah i'm just confused why it didn't work the first time i tried 00.57.39 # Disassembling is often the first thing I do in order to understand such things 00.58.00 # Even if the loop body is asm, gcc is still able to place some silliness around it 00.58.09 # i skimmed the dissassembly and didn't see anything obviously wrong, but my arm is pretty rusty so i probably missed something 01.00.02 # Not arm related, but when I did the mmx asm for libdemac, I tried using gcc intrinsics first. The result was horrible... 01.00.13 # kugel: using ldm is much faster on arm7 and no faster on arm9 01.00.17 # So I went for asm()... 01.00.20 # do you want me to commit it? 01.02.02 *** Saving seen data "./dancer.seen" 01.02.37 Join jennifur [0] (~bunnytaur@cpe-72-224-19-1.nycap.res.rr.com) 01.04.20 Quit jennifur (Client Quit) 01.08.52 # saratoga: maybe that also explains the little speed ups from your tremor patch on the test platforms 01.09.19 # thats definitely some of it, lots of what we did was just using ldm properly 01.10.00 # btw when using test_mem, increasing the number of repetitions helps the accuracy a lot 01.11.14 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 01.14.25 # now i'm getting the ldm is faster on the clipv2 01.14.27 # New commit by 03Buschel (r25464): Make test_mem.c and test_boost.c compilable on targets without BUTTON_UP. 01.14.29 # i don't know whats going on 01.15.21 Part geertvdijk 01.16.41 # http://pastebin.com/ZabSaujQ 01.16.47 # thats my patch if someone else wants to test 01.19.11 Quit merbanan (Ping timeout: 246 seconds) 01.19.20 # saratoga: why don't you just set ptr = &buf[0] outside the inner loop and use ldmia? 01.19.46 # Buschel: because I've been randomly trying things until i got something that worked at all :) 01.20.01 # i'm actually building ldmia right now 01.20.07 # with 01.20.13 # :o) 01.22.02 # i get about about 900KB/s and 9000KB/s on the clipv2 with that patch btw 01.24.49 Quit jd (Read error: Connection reset by peer) 01.25.07 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 01.25.07 Quit jd (Changing host) 01.25.07 Join jd [0] (~jd@Wikipedia/HellDragon) 01.26.23 # saratoga: btw, you can use stmia for writing as well 01.28.50 Quit amiconn (Disconnected by services) 01.28.52 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 01.29.10 Quit pixelma (Disconnected by services) 01.29.11 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 01.29.14 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 01.29.30 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 01.32.08 Quit roolku (Ping timeout: 246 seconds) 01.35.35 Quit anewuser () 01.40.14 Quit Buschel () 01.40.54 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 01.41.11 Quit ender` (Quit: All general statements are false. -- The Ultimate Law) 01.42.34 Quit angelwolf71885 (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 01.43.08 Quit kugel (Remote host closed the connection) 01.50.27 Join _deXter [0] (~dexter@193.136.33.132) 01.55.16 Join kugel [0] (~kugel@rockbox/developer/kugel) 01.55.31 # gevaerts: well, the io priority thing gets me to the menu ~1 second faster, and to playback ~4 seconds faster, good stuff! 01.56.03 # excellent! 01.56.28 # init_tagcache seems to take 400ms regardless of whether load to ram is enabled, with no autoupdate 01.56.55 # that happens regardless of the priorities though 01.59.44 # 13 seconds total from pressing power to playback resuming is not too bad :) 02.00.12 # slow bootloaders! 02.00.46 # 7 seconds on my gigabeat F 02.00.54 # hmm 02.01.24 # that one has the bootloader in flash 02.01.44 # dunno that it's *all* the bootloader. 02.01.57 # it's maybe 2.5s from power to logo 02.02.15 # the chart shows 394 ticks to get to root menu 02.02.46 # thats about 150 here 02.03.20 # it's a faster CPU of course 02.03.29 # and a less crappy disk 02.03.31 # on the beast the bootup is quite a bit quicker. it used to stick on the splash for awhile. I have no times handy though. 02.04.08 # <5s on a sansa fuze :) 02.04.41 # kugel: a sansa fuze is only two seconds faster than my disk-based player? That's *bad*! 02.05.08 # I haven't tested after your commit actually 02.05.17 Join r2k000_ [0] (~r2000@sjs-cc-wifi-ctrl4-nat.sjsu.edu) 02.05.20 # jhMikeS: Beast is pretty slow these days 02.05.31 # it won't change much on flash 02.05.42 # Earlier I measured 16 seconds from bootloader to music resuming (before gevaerts' commit 02.05.44 Quit r2k000_ (Remote host closed the connection) 02.05.47 # It is now 8 seconds 02.06.00 Quit dockimble (Quit: Leaving) 02.06.07 # AlexP: And surely most of that is OF now. 02.06.08 Join r2k000_ [0] (~r2000@sjs-130-65-109-108.sjsu.edu) 02.06.10 Quit bertrik (Ping timeout: 258 seconds) 02.06.14 Quit TheSeven (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 02.06.17 # Llorean: This is from RB bootloader showing 02.06.20 # Oh 02.06.20 # AlexP: compared to itself or to new targets that appeared on my absense? 02.06.23 # Wow, mine never got that slow 02.06.30 # And the OF section is very quick with single boot 02.06.38 # Ah, mine's still dual boot 02.06.55 Quit r2k000_ (Client Quit) 02.06.58 # jhMikeS: Itself, from what I remember in a fuzzy haven't bothered to measure way 02.07.08 # But I'm not the only one with that impression 02.07.16 # Llorean: this is to music actually playing, not to the wps showing 02.07.22 # yes 02.07.28 # gevaerts: True, I just boot to the menu then manually resume 02.07.29 # Using headphones :) 02.07.33 # So my experience is surely quite different. 02.07.43 # It was 6 and 9 seconds IIRC to menu appearing 02.07.53 # i.e. 6 now, 9 without gevaerts 02.08.16 # 6.5s with dircache 9.6 s with patch + dircache 6.5 s 02.08.24 # Llorean: me too normally, but I switched it to autoresume for testing 02.08.25 # AlexP: I use single boot and didn't notice much change w/o dircache from earlier revisions. I've no times either, so long as it feels ok, it's ok imho. 02.08.36 # er, that paste was misleading 02.08.54 # jhMikeS: Well gevaerts halving the time tonight certainly helps :) 02.09.13 Quit r2k000 (Ping timeout: 264 seconds) 02.09.20 # "6.5s with dircache 9.6 s with patch + dircache 6.5 s" should have had "without dircache 02.09.23 # first 02.09.36 # gevaerts: what theme? 02.10.08 # The measurements I just gave were with settings reset 02.10.19 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 02.10.19 # AlexP: 'deed. it was easy to tell. I kept dircache off for awhile because of the sheer number of files on my drive. 02.10.34 # kugel: I use my own 02.10.52 # jhMikeS: Yeah, mine is bound to be a bit slower too - 120 GB disk nearly full of lossy files 02.11.31 Quit jd (Quit: Ω) 02.11.41 # hm, why is switching themes so slow? 02.12.48 # on my fuze it's fast, on my e200 it's rather slow but horrible slow with music playing 02.13.10 # Well, slow as in it's been two minutes now 02.13.21 # That's... that's pretty slow. 02.13.29 # * gevaerts suspects a bug 02.13.29 Quit bmbl (Quit: Bye!) 02.14.26 Join jd [0] (jd@bas1-montreal33-1279639532.dsl.bell.ca) 02.14.26 Quit jd (Changing host) 02.14.26 Join jd [0] (jd@Wikipedia/HellDragon) 02.15.14 # 5.09s messured 02.15.34 # hm, it's not slow. It freezes... 02.15.54 Quit jd (Read error: Connection reset by peer) 02.16.20 # * gevaerts installs a clean build first 02.18.27 # gevaerts: I just tried it on beast because that's what on-hand. It took a second or so. 02.18.53 # Can you try while audio is playing? That seems to make it freeze here 02.19.54 # gevaerts: no problem here 02.19.56 # * kugel never understood why theme loading is so horrible slow on his e200v1 with music playing 02.20.02 # easily 30-40s 02.20.42 # I just replaced the bin only over a build from a couple days ago 02.23.05 Join r2k000 [0] (~r2000@sjs-130-65-109-108.sjsu.edu) 02.25.06 # It's 100% reproducible here 02.27.11 # hm, not 100% maybe, but still 02.27.31 # any settings that might affect it? maybe I should be more agressive about it? 02.27.54 # dircache doesn't change things 02.29.03 # apart from that I don't see much special 02.30.30 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 02.31.09 Join digitxp [0] (~Casey@c-68-38-210-23.hsd1.nj.comcast.net) 02.31.19 # does it depend on buffering? also, playback and the disk use the DMA but that probably would crash all the time if that were it. :\ 02.31.26 # hello peoples 02.33.19 Quit pixelma (Ping timeout: 265 seconds) 02.33.20 Quit amiconn (Ping timeout: 265 seconds) 02.33.23 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 02.33.45 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 02.33.51 Join pixelma [0] (quassel@rockbox/staff/pixelma) 02.34.27 # gevaerts: nope, I can't get a hang. 02.34.47 # I'm now testing r25458 to see if it's my fault 02.34.56 # It's now stuck 02.35.21 # anyone notice that some of the daily manuals return 404's? 02.35.45 # (namely sandisks and toshibas) 02.36.46 # jhMikeS: the lcd just turned white and striped, so I'm pretty sure it's not just waiting slightly longer than normal... 02.37.01 # gevaerts: the core isn't supposed to run above a certain voltage for more than a year accumulated time and so dropping the core voltage has to get done. I hope it isn't just CPU decay from that. :o 02.37.19 Quit Darkknight512 (Quit: ChatZilla 0.9.86 [Firefox 3.5.9/20100315083431]) 02.37.45 # jhMikeS: this is on an F. Anyway I doubt if you'd get this sort of effect from that 02.38.09 # gevaerts: oh! I thought you had an S. ?? 02.38.14 # haha 02.38.17 # I have both :) 02.38.22 # me too :) 02.39.35 # What I'm doing is just going to Browse Theme Files, and then go through the list one by one while the music is playing. Sooner or later it freezes 02.42.03 # digitxp: weird. The people who can have a look at it have gone to sleep though 02.42.15 # ok, then I'll get on the same page here and check that out. :) 02.48.00 # I want to praise the devs 02.48.15 # I get all the thrill of a broken computer 02.48.34 # without any of the actual problems/risk :) 02.48.42 # scratch problems 02.48.53 Quit _deXter (Quit: Lost terminal) 02.49.28 Quit r2k000 (Quit: r2k000) 02.53.03 Quit amiconn (Disconnected by services) 02.53.05 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 02.53.13 Quit pixelma (Disconnected by services) 02.53.14 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 02.53.27 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 02.53.34 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 02.58.56 Quit pixelma (Ping timeout: 265 seconds) 02.59.02 Quit amiconn (Ping timeout: 260 seconds) 03.00.22 Join amiconn [0] (quassel@rockbox/developer/amiconn) 03.00.26 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 03.00.34 Join pixelma [0] (quassel@rockbox/staff/pixelma) 03.02.06 *** Saving seen data "./dancer.seen" 03.04.27 Quit SirFunk (Read error: Connection reset by peer) 03.04.28 # gevearts: I went around the list about 8 times on GBF without any problems. With/without dircache. 03.12.19 Join flyback [0] (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 03.14.01 Quit amiconn (Ping timeout: 246 seconds) 03.14.24 Quit pixelma (Ping timeout: 265 seconds) 03.14.51 Join SirFunk [0] (~Sir@97-92-38-108.dhcp.aldl.mi.charter.com) 03.17.15 Nick flyback is now known as f1yback (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 03.21.35 Quit GeekShadow (Quit: The cake is a lie !) 03.21.35 Join pixelma [0] (quassel@rockbox/staff/pixelma) 03.21.50 Join amiconn [0] (quassel@rockbox/developer/amiconn) 03.25.42 Quit SirFunk (Remote host closed the connection) 03.36.39 Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 03.39.03 Quit kugel (Remote host closed the connection) 03.46.56 Join fyrestorm [0] (~nnscript@cpe-68-173-235-189.nyc.res.rr.com) 03.48.25 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 03.48.34 Quit adnyxo (Read error: Connection reset by peer) 04.06.15 Quit kramer3d (Quit: Leaving) 04.08.01 Quit z35 (Ping timeout: 246 seconds) 04.09.28 Join z35 [0] (~z35@ool-18bd3f51.dyn.optonline.net) 04.15.22 Quit z35 (Ping timeout: 246 seconds) 04.18.56 Quit Strife89 (Quit: See ya.) 04.19.26 # looking at the arm9e reference manual, a lot of our ASM code is probably slower then it needs to be on 9E because of the various pipeline interlocks 04.19.42 # fortunately most of the code looks pretty easy to fix, just rearranging ops 04.20.25 # for instance, the synth filter for mp3 does lots of load then multiply operations over and over 04.20.58 # the loads should probably be grouped so that their result isn't needed on the next instructions, which will save a pipeline stall 04.22.23 # the mp3 imdct does a lot of that too 04.27.16 # saratoga: that is an issue with the s3c and imx31, I know that much. it doesn't seem to hurt the lesser arms to do it. 04.27.43 # yeah they're not pipelined enough to matter 04.28.20 # looking at the timings, arm9E is probably no faster for typical load-mul-store code we do in all our codecs then arm9 because the pipelining isn't taken into account 04.30.14 Join Rob2222 [0] (~Miranda@p4FDCA927.dip.t-dialin.net) 04.33.06 # the new mdct actually looks pretty good though 04.33.22 # i guess since its pretty light on multiplies anyway 04.34.17 Quit Rob2223 (Ping timeout: 265 seconds) 04.37.10 Join InterestedRocker [0] (~424192b6@giant.haxx.se) 04.39.07 Quit InterestedRocker (Client Quit) 04.50.16 Part digitxp 04.58.58 Join Barahir_ [0] (~jonathan@gssn-5f75656e.pool.mediaWays.net) 05.02.07 *** Saving seen data "./dancer.seen" 05.02.13 Quit Barahir (Ping timeout: 240 seconds) 05.07.22 Quit antil33t (Read error: Connection reset by peer) 05.12.59 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 05.20.18 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 05.43.01 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 05.47.28 Quit Adubb (Quit: "The mind and body must be subjected to extreme stimulus, by means of drugs and music." - HST) 05.54.31 # funman: http://www.rockbox.org/wiki/CodecPerformanceComparison#Telechips_TCC7801_ARM926EJ_S 05.54.40 # the D2 is also really, really fast like amsv2 05.55.12 Join Adubb [0] (~aldubuc@67.201.160.144) 05.56.17 # the D2 has SRAM for its internal memory and performs the same or maybe a little slower then the AMSv2 05.56.29 # strongly suggests that at very least the IRAM on the AMSv2 has become faster 06.00.32 # huh does the D2 actually use its IRAM? 06.05.00 # it sets it up in the lds file, but it doesn't seem to get linked in the codecs 06.05.26 Join froggyman [0] (~me@unaffiliated/froggyman) 06.07.00 Quit saratoga (Quit: Page closed) 06.07.43 # is there anyone on who can help me compile a version of rockbox that will work with a 240GB hard drive? I have the dev kit set up already 06.11.48 Join saratoga [0] (~9803c20d@gateway/web/freenode/x-vmdvurtumaznhphy) 06.12.01 # im going to have to go back to the apple firmware if i cant get it to work :-( 06.12.46 # ive been using rockbox since i got my archos in like 2005, i really dont want to go back to stock firmware 06.13.15 # was there a question in there somewhere? 06.13.30 # yeah you quit right before it 06.13.31 # 01is there anyone on who can help me compile a version of rockbox that will work with a 240GB hard drive? I have the dev kit set up already 06.13.47 # Why not say specifically what problem you're having 06.13.58 # There's no way for anyone to know if they can help you without knowing what the problem is. 06.14.13 # unsupported max_boot_sector size 4096 06.14.25 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 06.14.29 # tried this but it didn't work for me: http://www.rockbox.org/mail/archive/rockbox-archive-2010-02/0042.shtml 06.14.45 # Is that a message you're getting, or? 06.14.49 # You need to be a bit more specific. 06.15.05 # People in here can't read minds, and "it didn't work" doesn't tell much. 06.15.39 # yes since i installed the default rockbox firmware/bootloader it refuses to boot and gives the error i just said 06.16.15 # And it still gives the exact same message if you install a modified bootloader and build as per those instructions? 06.16.54 # the first time i tried, yes. this most recent time it complained about the checksum not matching 06.17.22 # The checksum not matching usually means you've built for the wrong device. 06.19.26 # there's only like 3 defines you need to change, its not rocket science. 06.19.26 Nick f1yback is now known as flyback (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 06.19.26 # I've seen this explained a few times, maybe search the logs 06.19.26 # well thats what I thought, i found the file to modify and recompiled just fine, but it still refuses to boot rockbox 06.19.26 # ill try searchign 06.19.26 # scott666: Did you install an updated *bootloader* and not just an updated build? 06.19.26 # yes 06.19.26 DBUG Enqueued KICK scott666 06.19.26 # with ipodpatcher.exe 06.20.52 # this is iPod 5.5G? 06.21.02 # no, just 5th. formerly a 60GB 06.21.54 # is that still called the "Video"? 06.21.57 # heres a question: do i need to run Make twice (once normal once for bootloader)? or does this happen when you do a normal make anyway 06.22.03 # yes, not the classic 06.22.17 # you can't make a bootloader and a normal build at the same time 06.22.18 # I'll just send you the config file if you want... 06.22.25 # so you don't need to run it twice 06.22.36 # although you'll have to compile both obviously 06.22.46 Quit panni_ (Read error: Connection reset by peer) 06.22.52 # saratoga: You need to do a separate configure and a separate make, probably best to do it in its own build folder 06.22.57 # Er, not saratoga, scott666 06.23.09 # hmm, maybe thats contributiing 06.23.15 # ive been doing it in the same folder 06.23.22 # you need to do make zip for each as well? 06.23.32 # zip is just the main build 06.23.37 # ok 06.23.46 # it won't actually work for the bootloader since theres nothing to zip 06.24.11 # it let me do it and it replaced rockbox.zip 06.24.16 # so you're really sure you actually installed a new bootloader? 06.25.29 # it sounds like you haven't actually compiled one from these questions 06.25.29 # what does the bootloader version number say when your player boots up 06.25.29 # yes im sure, ive run ../tools/configure twice to get a bootloader as well as a normal, ive just been doing it in the same build folder 06.25.48 # and then ipodpatcher.exe with the i copied from the build dir 06.26.01 # you *can* build the bootloader/build in the same build folder. 06.26.17 # i know, ive done it 06.26.20 # heh 06.27.00 # yeah but if make zip didn't error out you probably didn't do it correctly 06.27.11 # once of the times make complained about an error in fat.c, lemme see if i can get it to do that again 06.29.59 # okay: In function 'ata_transfer_sectors': error: 'CMD_WRITE_MULTIPLE_EXT' undeclared (first use in this function etc.) 06.30.45 # this is with #define HAVE_LBA48 in my ipdvideo.h config file 06.31.15 # but at some point it did compile with LBA48> 06.33.16 # i dont think so, i think i just didnt notice the error the first time 06.33.45 # so you never actually compiled anything? 06.34.24 # i commented out that line and just changed MAX_PHYSICAL_SECTOR_SIZE to 4096 06.34.26 # that didnt fix it though 06.35.18 # Making it clear you didn't actually just use the changes in the link is another one of those things we should've been told at the beginning. 06.35.24 # Again, the whole "can't read minds" thing. 06.35.51 # What SVN revision are you trying to compile, and do you have any other patches applied to your code? 06.35.52 # well, i tried to 06.36.06 # first i tried on fresh svn, now im working with 3.5.1 06.36.11 # no other patches 06.36.29 # also when i asked if you're sure you isntalled the bootloader, and told you how to check, and you didn't check because you knew better 06.36.38 # thats one of those things 06.36.44 # i missed the you telling me how to check part 06.37.24 # if you like i could take a screen capture of the cmd window i have saying the bootloader was written to the device 06.38.04 # just check the version on your player 06.38.07 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 06.38.14 # forgot to mention that error was from firmware/drivers/ata.c:428 06.38.24 # my player wont boot rockbox 06.38.36 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 06.38.45 # The bootloader version comes before Rockbox boots, which is what he's asking for. 06.39.11 # sorry, its 3.5.1 06.41.34 # i think thats the version for the rockbox build, not the bootloader 06.42.19 # well, maybe thats why it doesnt work 06.42.59 # actually if you can't boot rockbox, i guess it would have to be the bootloader 06.43.07 # did it say "boot ver" or something like that 06.44.19 # no, Rockbox boot loader. Version: 3.5.1 Ipod version:0x000B0005 06.44.56 # thats an odd version string, not sure what it means 06.45.56 # im building a fresh bootloader 06.46.44 # is there a way to copy paste out of cygwin? 06.47.07 # right clikc and mark, same as windows command lines i think 06.47.09 # Please don't paste stuff into the channel if you do have to paste something 06.47.14 # Use pastebin.ca or similar. 06.47.30 # i know, wasnt planning to paste it in this window 06.52.40 # http://pastebin.ca/1856339 06.53.34 # if you do an "svn diff" from the root of your check out, are any other files changed? 06.56.12 # ummm, where exactly do i run that? 06.56.26 # i got svn: '.' is not a working copy 06.56.34 # from the root of your source check out 06.56.35 # i meantioned im running 3.5.1 right? 06.56.47 # yes 06.57.18 # scott666: Try with a current SVN checkout instead, it will make it easier to check things like this. 06.58.17 # 1 sec 06.59.35 # the reason i switched from svn to the release waws to rule out any bugs that might have entered since that, i really have no idea how much activity theres been since then though 06.59.49 # its downloading right now though 07.01.26 # its amazing how many more targets there are since the last time i compiled 07.02.08 *** Saving seen data "./dancer.seen" 07.03.17 # okay, fresh svn download, attemping to Make a new bootloader with the updated ipodvideo.h file 07.03.46 # hey, it made it past ata.c thats a good sign 07.04.41 # bootloader went okay, trying normal now 07.13.15 # no errors, lets hope it works this time 07.16.46 Join r2k000 [0] (~r2000@c-67-164-21-71.hsd1.ca.comcast.net) 07.18.48 Join nabule [0] (~nabule@222.90.192.130) 07.19.25 Part nabule 07.19.42 Part r2k000 07.20.26 # *PANIC* Unsupported physical secor size: 4096 07.20.45 Join r2k000 [0] (~r2000@c-67-164-21-71.hsd1.ca.comcast.net) 07.21.38 # post the output of svn diff and check that the bootloader version is updated 07.21.46 # And you *definitely* changed it to 2048? 07.21.55 # i used the file you sent me 07.22.04 # Err..yes, what saratoga said. 07.22.17 # I thought you said it didn;t come through right? 07.22.38 # you said you only had ~130 lines of it. 07.22.43 # So that was bound to fail. 07.24.13 # http://pastebin.ca/1856355 07.24.22 # you sent it a second time, that one worked 07.24.59 # Okay, those changes are different from the ones in the linked email 07.25.37 # remove all that crap except the LBA changes 07.25.41 # then try that 07.25.48 # I think the 4096 sector size is necessary 07.25.56 # Depending on the actual physical sector size of your drive 07.26.04 # an email on the mailing list says it isnt but ill try anyway 07.26.10 # That being said, 2048 almost certainly isn't right, and I don't know why you changed it to that. 07.26.19 # youd have to ask S_a_i_n_t 07.26.25 # i had 4096 in my file 07.26.31 # scott666: You really shouldn't follow two sets of directions at once. 07.26.48 # Especially making if you don't communicate in here and let us know you're doing other things. 07.26.52 Quit xavieran (Read error: Connection reset by peer) 07.26.56 # Again, "can't read minds" 07.27.03 # im not trying them at once, im trying them one at a time 07.27.12 # S_a_i_n_t pmed me which is why you're out of the loop 07.27.18 # i really think you should ignore everyone but me 07.27.29 # and just try the lba change 07.27.39 # At the very least, you should pick one person to listen to and make it clear whose steps you're following. 07.27.53 # saratoga: Those large drives have larger physical sectors, don't they? 07.28.09 # i see no reason to assume they need that define 07.28.15 # re-makeing with 4096 as the sector size 07.28.28 # afaik its just a work around for the 80GB ipod which doesn't apply here 07.28.40 # saratoga: http://www.rockbox.org/mail/archive/rockbox-archive-2010-02/0042.shtml 07.28.56 # I think that's a workaround for the 80gb drive, but I think it also applies to the newer 120gb+ drives for 5Gs 07.29.15 # But LBA48 on its own is worth a shot, at least. 07.29.37 # Wouldn't the obvious answer be to simply find out what the physical sector size is on the drive first? 07.29.39 # ive tried that, got the same error 07.29.55 # I would assume, though, that if the error message is that the size is 4096 and that it isn't supported, enabling support would be essential. 07.30.09 # again, i assumed the same thing and tried that first 07.30.34 # thats not to say i didnt make some error though 07.32.16 # this is what i get when i install the bootloader: http://pastebin.ca/1856361 07.32.33 # says the sector size is 512 which seems odd 07.33.00 # Logical sector size and physical sector size are two different things. 07.33.05 # That's probably logical. 07.33.10 # ah, ok 07.33.14 # yeah i wonder if it works if you just remove all those defines 07.33.15 # Don't know for sure, though 07.33.40 # ill try that again next, waiting for it to recompile so i can try with 4096 again 07.33.59 # is there a way to tell it not to compile all these plugins that obviously havent changed? 07.34.10 # *re-compile 07.35.26 # or do i need even need to bother putting a new .rockbox dir on until the bootloader works/ 07.35.39 # You should. 07.35.49 # ok, ill keep doing that then 07.37.18 # New commit by 03mc2739 (r25465): Add missing entry to project history 07.38.12 # okay, so next you want me to compile with both the sector defines commented out but LBA48 still in? 07.39.11 Join Boldfilter [0] (~Boldfilte@adsl-82-103-236.jax.bellsouth.net) 07.41.18 Quit xiainx (Ping timeout: 258 seconds) 07.41.40 # haha scratch that, it works! 07.42.01 Quit Boldfilter (Client Quit) 07.42.20 Join Boldfilter [0] (~Boldfilte@adsl-82-103-236.jax.bellsouth.net) 07.42.25 # thanks guys 07.42.29 Part Boldfilter 07.43.00 # now i just need my new headphone jack and click wheel to arrive from china 07.43.05 Join Boldfilter [0] (~Boldfilte@adsl-82-103-236.jax.bellsouth.net) 07.44.17 Quit Boldfilter (Client Quit) 07.44.48 Join Horschti [0] (~Horscht2@xbmc/user/horscht) 07.45.14 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 07.47.42 Quit Horscht (Ping timeout: 240 seconds) 07.51.16 Join FlynDice [0] (~FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) 07.54.11 Quit shai (Quit: Leaving) 08.04.12 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 08.05.44 Part froggyman 08.12.32 Quit S_a_i_n_t () 08.13.27 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.232) 08.16.25 Quit xiainx (Ping timeout: 276 seconds) 08.16.44 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 08.17.50 # AAC-HE takes 185.80MHz on the Nano2G (arm9) verses just 99.27MHz on the D2 (ARM9E) 08.17.59 # amazing difference 08.19.00 # although the Gigabeat F (same CPU as the Nano 2G) decodes it at 127.14MHz 08.19.09 # so something is clearly weird about it on the Nano2G 08.20.31 # Is there any reason why an .sbs shouldn't update at the same rate as a WPS? 08.21.18 Quit pixelma (Ping timeout: 245 seconds) 08.21.25 Quit amiconn (Ping timeout: 265 seconds) 08.31.30 Join drostie [0] (~marathon@5ED17066.cable.ziggo.nl) 08.33.36 Join pixelma [0] (quassel@rockbox/staff/pixelma) 08.36.41 Quit pixelma (Disconnected by services) 08.36.42 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 08.37.01 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 08.37.19 # Gah! This is driving me mental! I have a disk access/playmode animation in my .wps that I've moved into my .sbs as well. It alternates at 0.1 second intervals. It works absolutley fine in the .wps, but in the .sbs the update rate seems *WAY* slower and causes drawing issues. 08.38.06 # In the wps its a fluid animation, in the .sbs I can see every frame chugging along. 08.39.46 Join amiconn [0] (quassel@rockbox/developer/amiconn) 08.40.13 Quit saratoga (Changing host) 08.40.14 Join saratoga [0] (~9803c20d@rockbox/developer/saratoga) 08.40.16 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.42.24 Quit arbingordon (Quit: `) 08.51.11 Quit xiainx (Ping timeout: 240 seconds) 08.55.09 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.00.51 # S_a_i_n_t: the sbs doesnt update anywhere near that speed 09.01.02 # once per button press... not 10Hz 09.02.06 # Is the D2 software USB? 09.02.12 *** Saving seen data "./dancer.seen" 09.02.46 # Also, any reason it doesn't have the same volume range fix as the iPod 5G? 09.03.33 # its software USB 09.04.08 # i don't think its 100% working though 09.04.28 # Well, it's definitely not enabled 09.04.38 # I was wondering if it was disabled because we don't have enough hardware info, or because the main filesystem is read only? 09.04.54 # probably because its not stable enough to be used safely 09.05.33 # JdGordon: Bugger...well, at least its not some hole in my code though. 09.05.51 # I take it the update speed of the .sbs is lower for a specific reason? 09.06.09 # well, its a waste to make it update more frequently 09.06.29 # not for my disk access animation it isn't ;) 09.06.52 # for the theme I'll never be able to uplaod ;) 09.07.09 # although, we may be able to fix that up... let the sbs specify its update freq in the code 09.07.29 # Ohhhhh, sounds *purdy* 09.08.19 # one minor problem is that each screen does its own timeout... in the menus its 1 update per second 09.08.27 # I tihnk the browsers are 10Hz 09.08.34 # there is no single standard 09.08.43 # (which would be simple to change) 09.10.38 Part scott666 09.15.11 Quit linuxstb (Ping timeout: 240 seconds) 09.16.13 # At a guess, it seems like the main menu updates every ~0.3 seconds or so. 09.16.31 # Doesn't sound like much, but enough to mess up an animation pretty bad. 09.16.54 # I thought all the screens updated at the same rate, and I was messing up the .sbs code. 09.17.06 # nope 09.17.35 # Well, I know that *now* ;) 09.17.38 # main menu will update at least once per second 09.17.48 # otherwise once per button press 09.17.55 # I'm actually kinda dissappointed it's not my fault, it's be easier to fix :P 09.18.15 # s/it's/it'd/ 09.18.26 # no, I lie 09.18.44 # the sbs does its own checks to not update too often also, which seems like overkill 09.19.08 # #define DEFAULT_UPDATE_DELAY (HZ/7) WTF? 09.19.45 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 09.20.15 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 09.23.48 # S_a_i_n_t: apps/gui/statusbar-skinned.c line 138... comment that out and let me know if it looks better 09.25.46 # OK, will do. 09.26.12 # no rush of course.. I'll be afk till tuesday night :/ 09.26.23 # but I tihnk getting rid of that update check makes sense 09.26.39 # especially if it doesnt hit the battery (which going by my bench's it wont) 09.27.13 # you'll notice a change if you scroll through the list and your animation seems to speed up 09.27.47 # I think the assumption was that it probably *would* drain the battery updating too much, but if your theme is *full* of animation...(like mine), you probably don;t care much about battery life ;P 09.27.52 Quit xiainx (Ping timeout: 258 seconds) 09.30.18 Quit linuxstb (Ping timeout: 276 seconds) 09.31.30 Quit phanboy4 (Ping timeout: 265 seconds) 09.32.32 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.33.43 # S_a_i_n_t: sure, but it looks like a basic sbs with just the inbuilt bar uses no more/less batt life than a full cabbie with AA 09.33.55 Quit tomers (Ping timeout: 265 seconds) 09.35.50 # Wow, how the heck does that work? 09.36.07 # It just doesn't seem right, but...wow 09.36.54 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 09.39.35 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 09.39.35 # * JdGordon starts his last bench 09.40.12 Quit JdGordon (Quit: Leaving.) 09.47.26 Quit xiainx (Ping timeout: 268 seconds) 09.48.06 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 09.52.13 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 09.57.18 Join stoffel [0] (~quassel@p57B4C62F.dip.t-dialin.net) 09.58.15 Quit linuxstb (Ping timeout: 276 seconds) 10.02.36 Join ender` [0] (krneki@foo.eternallybored.org) 10.08.50 Join linuxstb [0] (~linuxstb@94-193-103-239.zone7.bethere.co.uk) 10.08.56 Quit linuxstb (Changing host) 10.08.56 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.08.56 Quit xiainx (Ping timeout: 260 seconds) 10.13.48 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 10.20.15 Join roolku [0] (~roolku@cpc2-sgyl16-0-0-cust17.sgyl.cable.virginmedia.com) 10.25.45 Quit xiainx (Ping timeout: 264 seconds) 10.26.35 Quit evilnick (Ping timeout: 265 seconds) 10.27.34 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 10.28.48 Quit linuxstb (Ping timeout: 276 seconds) 10.29.47 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 10.31.20 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.32.39 # New commit by 03alle (r25466): Make the displayed hotkey settings scroll (fix FS#11170) 10.36.51 Quit linuxstb (Read error: Operation timed out) 10.40.50 Join Kitr88 [0] (~Kitr88@89.142.86.66) 10.41.57 Quit xiainx (Ping timeout: 264 seconds) 10.44.21 Quit Kitar|st (Ping timeout: 264 seconds) 10.45.20 Quit Kitr88 (Ping timeout: 260 seconds) 10.47.09 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 10.50.29 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.50.52 Join Kitar|st [0] (Kitr88@BSN-182-36-64.dial-up.dsl.siol.net) 10.57.04 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 10.59.35 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.02.16 *** Saving seen data "./dancer.seen" 11.02.57 Quit bluebroth3r (Ping timeout: 264 seconds) 11.08.24 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 11.08.38 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 11.25.19 # saratoga - dropping-in the patched libvorbisidec in an environment that had the unpatched one previously, seems to cause application errors for apps that use this - in particular, mpd complains with "symbol lookup error: /usr/local/lib/libvorbisidec.so.1: undefined symbol: LIKELY" 11.25.35 # a rebuild of mpd would probably fix, but is that expected? 11.25.48 # stripwax: i have no idea 11.26.19 # Is the new lib supposed to be compatible with the existing one? 11.26.26 # Hm, I guess not actually. 11.26.37 # that likely error sounds like a gcc problem 11.26.44 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.26.50 # since gcc should understand what likely means, its one of its macros 11.26.52 Quit Xerion (Ping timeout: 246 seconds) 11.27.00 # gcc? it's not a compile-time error, though .... 11.27.03 # load-time 11.27.21 # it sounds like it interpreted likely as a function define? 11.27.29 # "make example" worked fine though 11.27.30 # S_a_i_n_t: the update rate of the sbs is limited in the browsers, otherwise browsing through the menus might be a pain in the arse 11.27.45 # unless the compilation of the dynamic libraries is broken here 11.27.55 Quit xiainx (Ping timeout: 246 seconds) 11.28.20 # in any case, LIKELY is #defined to be empty 11.28.36 # I'll try a clean make/rebuild and see what happens .. 11.28.45 # maybe we should just remove the likely macros 11.28.53 # i doubt they make a measureable difference and they're gcc specific 11.29.39 # saratoga - hm, but os_types.h *already* #defines LIKELY to be empty. 11.29.52 Quit r2k000 (Quit: r2k000) 11.30.00 # saratoga: LIKELY is not a gcc macro, it's a wrapper macro for something that resolves to a gcc built-in 11.30.05 # is it possible your app was compiled against some much older version of tremor? 11.30.51 # in any event, it shouldn't survive the preprocessor, so something is wrong when it's in the binary 11.31.18 # not sure what you mean by 'much older' - has there been any recent releases of tremor? the app was previously compiled against the headers from the nslu2 package, fwiw. 11.31.28 # which is afaict the same as Tremor trunk 11.32.32 # I suppose if os_types.h #defines LIKELY then it's not included properly in all places where it's used 11.33.24 # ah, good point... 11.33.51 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 11.34.22 # we still need to try the original ASM'ed mdct too to see how much of a difference it makes 11.34.42 # in the patched code, only fft-ffmpeg.c and mdct-ffmpeg.c use LIKELY -- and not clear if either of them #include os_types.h ... 11.35.02 # the original rockbox ASM'ed one? 11.35.47 # stripwax: it should be included directly if it uses something in there anyway, imo 11.36.05 # kugel - right, i'm not sure that it does 11.36.07 # yes the original one, i want to see how it perfoms in tremor 11.36.35 # saratoga - i was actually running the original rockboxed one on the nslu2 for quite some time :) plus a few other bits and pieces 11.36.48 # let me try building the libtremor_example for the original code 11.36.49 # feel like benchmarking it? 11.37.06 # I have no idea if it's the 'latest version' in any meaningful sense, but I will try 11.37.17 # I'll use the same testfile as last time 11.39.47 # * stripwax wonders if his LIKELY problems are actually due to the *old* rockbox mdct on his nslu2! 11.40.00 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 11.40.42 # maybe my mpd build is actually *expecting* LIKELY to be defined (due to some cruddy bug on my side)... will know soon enough. But yeah, we should just remove the whole LIKELY stuff from the tremor patch 11.42.16 # stripwax: no, it's libvorbis 11.42.44 # mm? 11.44.06 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.44.12 # the dynamic linker doesn't know where symbols come from, so it can't show that a missing symbol is missing in one of the linked libraries 11.44.49 # it can only show in which binary/lib the symbols are missing 11.45.18 # right, so i think my mpd build is dodgy if it's trying to load a symbol named LIKELY from the lib 11.46.05 # anyway, sorry, I'm veering offtopic a bit here. I'll get some benchmarks from the patched tremor vs rockbox mdct tremor in a sec. 11.46.21 # then it would show symbol "lookup error: /path/to/mpd: undefined symbol: LIKELY" 11.46.54 # did you try simply including os_types.h where LIKELY is used? 11.47.02 # i removed LIKELY from the code and rebuilt ... 11.47.08 # and it still happened ... 11.47.15 # strange 11.47.57 # but from what I've noticed, all mpd defines (the gcc macros too) are lower case and prefixed with mpd_ so it seems unlikely 11.49.30 # right, that's why I think it's a problem with my local mpd, which was originally compiled against a manually-patched version of tremor with the rockbox mdct code. I probably screwed up, that's all. 11.49.32 Quit xiainx (Ping timeout: 268 seconds) 11.50.05 # I originally thought it was a problem with the patch; now I think it's a problem with me instead. 11.52.32 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.00.58 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 12.02.01 Quit roolku () 12.03.17 Quit xiainx (Ping timeout: 248 seconds) 12.08.40 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.12.17 # saratoga - i see the old rockbox mdct coming in at 38.42MHz and the new one coming in at 32.8MHz - but that's not quite a like-for-like comparison ; you don't happen to have a 'clean' patch against tremor trunk to add in the rockbox mdct and nothing else? 12.13.01 # nemmind, not hard. 12.13.04 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 12.13.30 # stripwax: the aatch is basically just the rockbox mdct and windowing code 12.13.38 # and i doubt the windowing code makes much difference on arm9 12.14.48 # I think there must be something else kicking around in my local version, because 38.42Mhz sounds slower than the reports for the unpatched trunk version 12.15.27 # unless the old rockbox mdct asm is slower than the trunk C, which I find hard to believe. 12.16.13 # did your old version have arm_assem defined? 12.16.27 # that'll make other parts slower even if the mdct gets faster from your changes 12.17.06 # yes 12.21.37 # hrm, -fomit_frame_pointer couldn't cause that sort of symptom, could it? (my old build had that defined, but the new one does not) 12.22.35 # you could also try commenting out the call to the mdct in each, just to see how many Mhz the mdct itself uses 12.22.53 # true 12.23.21 # i'll just add the old rockbox mdct into the same code as your patched version so I'm actually comparing apples to apples. 12.23.22 Quit xiainx (Ping timeout: 245 seconds) 12.25.59 # might as well put that online somewhere in case anyone wants to try it 12.26.11 # yeah 12.26.42 # i'll also make a copy of the mdctexp tremor patch so that it includes just the new mdct.. 12.28.29 # otherwise too many moving parts for a meaningful comparison of just the mdct 12.29.40 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.31.21 Join Meekrab [0] (~Meekrab@S01060013468957f1.ed.shawcable.net) 12.31.48 # Hi! 12.31.59 # Ok so I have a few questions. 12.32.07 # I havea Gigabeat S and a Zune. 12.32.42 # Has anyone figured out the protection on the zune yet? 12.32.46 # no 12.33.35 # I'm pretty good at programming but I have no Idea the differences between the zune's bootloader and the GS's bootloader... 12.33.56 # one has a security flaw the other doesn't 12.34.33 # from my settop box hacking days, I see that my zune will load an nk.bin and unpack it into ram... but if the signature is incorrect it quickformats the HDD and asks you to plug it in. 12.35.27 # I may have found a way to wrap the NK.bin with some arbitrary code (ala xbox hack) and get rockbox working that way, but alas it may require dissasembly of an official microsoft firmware... 12.35.55 # how did you find a way if you haven't done any dissassembly? 12.36.57 # I did 12.37.53 # I know for a fact that the Gigabeat S runs a Wince5 kernel but the IMX31L will only run signed code... 12.38.58 # sofar the only two ways to legitimately run anything non MS on the zune is by either jtagging it or trying to find a buffer overflow 12.39.31 # and thats like finding a needle in a haystack because the zune firmware is pretty nicely done, concidering its microsoft 12.39.35 # so what did you find? 12.40.01 # A veeeerryy small exploit right as it looks for the signature of the NK.bin 12.40.22 # something on the lines of a disc swap if you will 12.40.45 # if we can find a way to load the SHA256 key on top of rockboxes it may load up fully 12.41.06 Quit stoffel (Ping timeout: 252 seconds) 12.41.52 # Oh yeah and another interesting note 12.42.12 Quit kugel (Ping timeout: 252 seconds) 12.42.37 # I decided to plug in the MK3008GAL Hard disk from my dead ipod video into my Zune, it formatted it automatically and told me to plug it into the computer as if it were brand new. 12.43.27 # so it seems that if it doesnt find a certian set of files it just executes a delete MBR and waits for input. 12.43.56 # the gigabeat s reformats the disk if it doesn't like the partition layout 12.44.11 # Meekrab: You may want to speak to Torne next time he's around. He's done a lot of investigation into the Gigabeat S, to try to find exactly why it spontaneously decides to reformat. 12.44.16 # and also sometimes for no obvious reason 12.44.33 # it seems it has a hard coded SHA256 in the binfiles 12.44.43 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.44.52 # He's made some notes here - http://www.rockbox.org/wiki/GigabeatSOriginalLoader 12.45.26 # the spontaneous reformats seem to be the results of fragmentation because the Kernel may be written to by accident under certain circumstances... 12.47.31 Quit xiainx (Ping timeout: 276 seconds) 12.47.40 # There should be a way to make the menu+up point to an NK.bin which points to another binary in the media partition.... 12.49.05 # Too bad I dont have a zif to 2.5" adaptor. otherwise I could take a look at the contents of my zune's HDD 12.50.25 Quit saratoga (Quit: Page closed) 12.51.51 Join stoffel [0] (~quassel@p57B4C62F.dip.t-dialin.net) 12.52.42 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 12.53.10 # Grr if i only knew more ARM stuff 12.53.29 # I know how to run arbitrary on X86 wince, like settops or the like... 12.56.20 # Hmm, Is it possible that the zune uses Wince6? 12.59.37 # Meekrab: I don't think anyone here has ever looked at the Zune, or has much experience with WinCE. Quite often, one person works out how to hack a device, then others do the actual work to write drivers and port Rockbox. That was the case for the Gigabeat S. 13.00.07 # Well, anyone want to help me crack this nut? 13.02.14 # theres a 20pin header on the backside of the planar 13.02.19 *** Saving seen data "./dancer.seen" 13.02.27 # Meekrab: The people who I think may be interested are not around at the moment. So please stay around, or check the logs later - http://www.rockbox.org/irc/ 13.03.16 Quit stripwax (Quit: http://miranda-im.org) 13.03.20 # O_O 13.03.27 # Why didnt I think of this beofe 13.03.32 # The wifi unit 13.03.44 # surely theres bugs there 13.04.01 # or perhaps the RDS? 13.05.22 # Howbout TIFF? 13.05.38 # they used it on the PSP to run hello world 13.05.48 # Do you have access to everything for disassembly? i.e. the bootloader plus the main firmware? 13.05.58 # not everything 13.06.13 # I can see the boot process and loading into ram but I cant poke anything in ram 13.06.26 # just over jtag 13.07.03 # main firmware can be downloaded from the net and dissasembled, but I cant see it in actual motion due to some protection 13.07.43 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 13.09.51 # saratoga - on nslu2, the old rockbox mdct_arm.S doesn't seem to bring any advantages. 13.10.15 # does the zune use the SGI implementation libTIFF? 13.10.16 # (over the non-asm stock C functions) 13.10.35 # Meekrab - how would we know? ... 13.10.46 # * stripwax is guessing that we don't know 13.10.48 # usually by looking in the credits menu... 13.11.00 # Meekrab - do you have a Zune? 13.11.24 # Meekrab: i think you misunderstand the security here, also ;) 13.11.27 # my zune is currently at the "plug into computer" screen 13.11.35 # the i.MX31 part in the Gigabeat S is not in secure mode 13.11.41 # Oic. 13.11.42 # and I would be surprised if the one in the Zune was 13.11.48 # *facepalm 13.13.16 # 11:45 < Meekrab> the spontaneous reformats seem to be the results of fragmentation because the Kernel may be written to by accident under certain circumstances... 13.13.20 # saratoga - I get 8m0s to decode a 60minute track with unpatched trunk tremor from svn.xiph.org; 8m1s (ish) to decode using the old rockbox mdct_arm.S; 7m24s (ish) to decode using the FasterMDCT patch (which includes non-imdct stuff) 13.13.20 # also this is nonsense 13.13.30 # we don't even mount the firmware partition 13.13.48 # and fragmentation is irrelevant 13.13.49 # saratoga - trying a few runs to even things out of course 13.14.54 # the problem with the gigabeat S is that the bootloader implements the error handler as "reformat the drive" 13.15.07 # so if absolutely *anything* goes wrong during boot, it will kill it, pretty much ;) 13.15.12 # where did "Kernel may be written to by accident under certain circumstances..." 13.15.15 # come from lol 13.15.22 # I must have pasted that 13.15.29 # (including things which can't possibly be fixed by formatting the drive, e.g. flash corruption) 13.16.10 # what I meant to say was the error handling would detect this as something up and trying to fix it and asking for a reformat. 13.16.26 # *by asking 13.16.33 # yes, but we *don't* write to the firmware partition 13.16.48 # though it gets exposed over usb, so someone could accidentally touch it that way 13.16.51 # im sorry, its 5AM and I've been tearing apart my brain boneing up on ARM terminology 13.17.10 # but it's too widespread a problem for that to be it, really. 13.17.30 # someone already linked you to the wiki page with my research so far on the S's loader 13.17.39 # what about locking the drive in some sort of read only state? 13.17.54 # what does that mean? 13.18.24 # prevent the drive from formatting itself, to see what it would do in the event of a failed format. 13.18.48 # We know what it does 13.18.50 # It hangs. 13.19.01 # but readonly vs readwrite is a software thing not a hardware thing, surely. and if the gigabeat bootloader, which we didn't write, does something in software, we can't prevent it anyway. 13.19.05 # The format is controlled by a flag in the flash config area 13.19.14 # you can turn it off, and it won't format any more. 13.19.25 # but all it does is skip formatting :) 13.19.37 # does it hang into some sort of wait or does it halt and catch fire 13.19.41 # whatever fatal error caused it to decide to want to still applies. 13.19.49 # it still tries to jump to recovery.bin 13.20.19 # so it doesn't work any better.. 13.20.29 # it just means you have to take the disk out and fix it externally. 13.20.39 # so, that's unlikely to be a very interesting avenue to explore. 13.21.10 Join dacari [0] (~3e3983b4@giant.haxx.se) 13.21.14 Quit dacari (Client Quit) 13.21.36 # the code for pmcboot_secure is not very complicated, really. 13.21.40 Join tredstone [0] (~3e3983b4@giant.haxx.se) 13.21.45 # Hi 13.21.47 # there's not a huge scope for them to have done something wrong. 13.22.05 # the version on the beast doesn't range check the load addresses for the chunks of nk.bin, which is how we run on that 13.22.17 # you just overwrite the instruction that fails the signature check with one that always passes :) 13.22.33 # but my understanding (though I haven't looked) is that the Zune's version of pmcboot does have proper bounds checks on this 13.22.52 # so you can't overwrite any of the ram the bootloader is using. 13.23.03 # thats what I was saying eariler 13.23.14 # I cant look at any of that ram 13.23.22 # look? 13.23.28 # jhMikeS, could I have a clarification of context on your quote from ~12 hours ago: " gevaerts: the core isn't supposed to run above a certain voltage for more than a year accumulated time and so dropping the core voltage has to get done. I hope it isn't just CPU decay from that. :o" 13.23.58 # you have a jtag connection? 13.25.30 # yeah, that 20pin connection between the planar and HDD, pins 4,5 are Serial RX and Serial TX, TRST - 8 13.25.31 # TDI - 9 13.25.31 # TMS - 10 13.25.31 DBUG Enqueued KICK Meekrab 13.25.31 # TCK - 11 13.25.31 # TDO - 13 13.25.42 Quit tredstone (Client Quit) 13.26.07 # can you see the core? 13.26.38 # 6 is CMOS level voltage (3.3~3.2v) 13.26.56 # ground is 17-20 13.27.18 # nope, its protected 13.27.31 # right, so that's useless then :) 13.27.43 # if icd is fused off then yeah, you can't do anythig useful with it 13.29.08 # i assume you at least have a copy of pmcboot_secure.bin for the zune 13.30.05 # so, get disassembling :) 13.30.38 # PMCR0 = 0x00000000 13.30.42 # that doesnt make sense. 13.30.48 # wtf 13.33.47 # what? 13.34.14 Quit xiainx (Ping timeout: 276 seconds) 13.34.28 # in the boot sequence, it tells me the PMCR0 is blank, the Dword is 01 and then it inits the fm tuner 13.36.21 # and? 13.37.23 # its weird 13.37.30 # what's weird about it? 13.37.31 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 13.37.39 # zero is a valid value for that register 13.37.58 # but that doesnt seem right 13.38.00 # if DVFEN and DPTEN are zero all the other bits are irrelevant 13.38.02 Quit stripwax (Quit: http://miranda-im.org) 13.39.43 # also this debug output is pretty arbitrary and random, you realise 13.40.15 # if it's similar to the beast port, then what trace is enabled/disabled is fairly arbitrary :) 13.40.26 # yeah 13.40.31 # its like drawing a card 13.41.53 # SysInit: GDTBase=811d40e8 IDTBase=811f5860 KData=811fd800 13.41.53 # Windows CE Kernel for i486 Built on Jun 24 2004 at 18:23:42 13.41.53 # g_pPageDir = 81200000 13.41.53 # X86Init done, OEMAddressTable = 80223f98. 13.42.18 # Je246, yeah its just the mamba bootloader 13.42.24 # oops wrong channel 13.42.40 # er what? 13.42.57 # (also please don't paste) 13.43.23 # was just explaining the i486 bootloader from the mamba hardware settop box (ip1101) 13.44.18 # I'm tired. and I'm out of coffe, 13.44.22 # night' 13.44.53 Quit Meekrab (Quit: Want to be different? Try HydraIRC -> http://www.hydrairc.com <-) 13.45.16 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 13.49.09 # hm, I have fuzev2 scrollwheel with interrupt working but it's too sensitive for my taste :( 13.50.14 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 13.52.05 # saratoga - yep, after a few more time trials, I don't see the rockbox old mdct_arm.S giving any significant speedup on nlsu2 13.52.08 Quit xiainx (Ping timeout: 264 seconds) 13.52.33 # approx 8m0s for both stock and rockbox old mdct_arm, to decode 60minutes at 266MHz 13.52.42 Quit stripwax (Quit: http://miranda-im.org) 13.57.09 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 14.00.00 Quit linuxstb (Ping timeout: 258 seconds) 14.02.16 Quit Highlander (Quit: Quitte) 14.06.44 # AlexP: what did you change \\ to? I removed it and there's now only a blank line between paragraphs in the code. The PDF output has paragraphs (indented) but no blank lines between them, is there some trick to get one (except \\ obviously) or should I just ignore it? 14.07.45 Quit shai (Quit: Leaving) 14.07.54 # pixelma: You have to change the paragraph rules in preamble.tex, but that changes the whole document, so at the same time you need to find/change all the \\ \\* needed in all the source 14.08.16 # pixelma: For now I'd use \\, and when I get a bit of time I'll do them all at once 14.08.21 # Or someone else can :) 14.08.22 # pixelma: what do you want to achieve ? 14.08.39 # pamaury: Blank lines in between paragraphs 14.08.39 Quit piotrekm (Read error: Connection reset by peer) 14.08.42 # remove \\ 14.08.55 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 14.09.19 # Between all paragraphs ? 14.10.51 # You can try \setlength{\parskip}{} 14.11.25 # AlexP: ok, I'll add them in the introduction text at the beginning again because it looks a bit unstructured without. But there were some completely unnecessary ones in the menu item description that had no effect at all 14.11.57 # pamaury: I know, but thatchanges the whole document so you have to go through and remove all the current forced breaks 14.12.09 # pamaury: It isn't difficult to do, it just needs a bit of time 14.12.19 # Ah indeed ;) just do replace \\ by \par 14.13.31 Join Annaa [0] (~Annaa@110.23.99.45) 14.13.34 # http://tinypic.zapto.org/2kn4m8.png?t=1270382747 do my breasts look to big? 14.13.35 Part Annaa 14.15.39 Quit pixelma (Ping timeout: 240 seconds) 14.16.29 Quit amiconn (Ping timeout: 258 seconds) 14.16.36 Quit stoffel (Ping timeout: 246 seconds) 14.17.49 Join pixelma [0] (quassel@rockbox/staff/pixelma) 14.17.55 Join amiconn [0] (quassel@rockbox/developer/amiconn) 14.19.32 Quit Rob2222 (Ping timeout: 265 seconds) 14.21.30 Join Rob2222 [0] (~Miranda@p4FDCA927.dip.t-dialin.net) 14.24.18 # "debugging" the broken build was funny... I couldn't find out first because the error appeared later in the main rockbox.tex which is just a list, then changed something else which was unrelated but which I wanted to change anyway - then the error output was different and (even though not in my new changes) helped me find the mistake... 14.34.41 Quit pamaury (Quit: Page closed) 14.35.13 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 14.38.18 # kugel: Sorry its so late. I've commented out the line that JdGordon told me to (sanity check for the .sbs refresh rate?), and nothing seems fishy with the menus so far. 14.38.27 # Animation is running a lot better though. 14.38.56 # sure, but there are targets with slower cpus and displays where it's getting annoying 14.39.03 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 14.40.58 # Aha...he (JdGordon) said it may be worthwhile looking into a way for the .sbs to specify its own refresh rate. 14.41.09 # For me at least, it could come in handy. 14.43.20 Quit merbanan (Ping timeout: 240 seconds) 14.43.50 # I'd never actually noticed the refresh rate was different until I tried putting an animation that alternates frames at 0.1 second intervals. It made for some pretty ugly drawing issues. 14.45.46 # without blocking some updates the sbs is updated on every button press, meaning to go through the whole lot if the skin engine and multiple screen updates for every selected item in the lists 14.46.07 # in the wps, the sbs refresh block is removed so it updates always when the wps is updated 14.47.36 # we could consider allowing 10 updates per second but I would rather not remove the fresh rate limitation 14.48.42 # ten updates per second would do for animation I guess... the animation I had was at 0.1 second intervals, but seemed to update every ~0.3/4 seconds. 14.48.48 # And looked really awful. 14.49.35 # I wonder how the wps deals with such frequent updates, IIRC it only updates every 200ms (unless you press a button) 14.49.52 # Yourself and JdGordon seem to be the "GUI guys" so, its up to you guys if its worth it or not ultimately I guess. 14.50.12 # I guess 0.2 timeout would not work for you? 14.50.26 # It seems fint (at 0.1second) on the WPS, unless its just taking the lowest value it can. 14.50.42 # s/fint/fine/ 14.51.19 # 0.2 would be better than "at least once per second, or at button press" 14.51.32 # I could just alter the WPS animation to the same speed. 14.51.57 # the wps button max timeout is 200ms, it only updates on timeouts (and a timeout happens if a button is pressed or the max timeout is exceeded). the only way for the wps to update more often is if it contains a peakmeter 14.52.34 # Hmmm, so even if I set it to 0.1, its still at 0.2? 14.52.48 # well, if that works for the WPS, then the .sbs should be fine with it. 14.53.40 # I don't know for sure, but I would be clueless if 0.1s actually works for the wps ;) 14.54.17 # it seems to...but I guess the difference between 0.1 and 0.2 seconds is barely perceptable ;) 15.02.21 *** Saving seen data "./dancer.seen" 15.03.53 # is there a way to skip of database refresh on e200v1 ? 15.05.23 # Rockbox should already do this if the bit that needs to be zeroed is known for your exact OF version (I believe SanDisk changed it from time to time) 15.07.55 Quit parafin (Quit: So long and thanks for all the fish) 15.08.12 Join parafin [0] (parafin@paraf.in) 15.10.39 Join paulk_ [0] (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) 15.10.48 # pamaury: you boot the OF? 15.11.21 # pamaury, pixelma I think this doesn't always work, IIRC you need to clear some configuration block to make sure the refresh bit is always in the same location 15.11.23 # Hello ! I can't found the archive with the rb 3.5.1's source code on rockbox.org . Is that normal ? 15.11.43 # kugel: I'm experimenting with usb, so sometimes yes, to recover :) 15.11.43 # yes 15.11.48 # paulk_: ^ 15.11.55 # ok, but why ? 15.12.10 # because there's svn 15.12.30 # kugel: it's better to direct download it 15.13.01 # I don't disagree, and several people asked for it, but nobody ever put a source archive back online 15.13.13 # ok… 15.13.56 # svn has several advantages though, so I'd go with it 15.14.44 # ok, but I can't find 3.5.1 on svg, just 3.5. 15.15.18 # http://svn.rockbox.org/viewvc.cgi/tags/ 15.15.35 # pamaury, see rbutil/sansapatcher/sansapatcher.c line 917 15.16.25 # kugel: thanks, I was looking at http://svn.rockbox.org/viewvc.cgi/branches/ 15.17.46 # released stuff is always under tags 15.21.54 Join Schmogel [0] (~Miranda@p3EE20036.dip0.t-ipconnect.de) 15.26.40 # ok 15.28.13 # bertrik: thanks, I'll have a look. that's not very important, however, I had forgotten that I had put 40000 files on my e200 to do some test and the OF database fresh is quite slow :) 15.39.47 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 15.39.49 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 15.40.03 Join mitk [0] (~mitk@chello089078013146.chello.pl) 15.52.40 # New commit by 03pixelma (r25467): Cleanup goban.tex. My main goal was to get the button table code into a readable state - following the structure I suggested on ManualGuidelinesTalk. ... 15.54.36 Join Sajber^ [0] (~Sajber^@211.142.216.81.static.tab.siw.siwnet.net) 15.54.47 # paulk_: http://download.rockbox.org/release/3.5.1/ has the source 15.55.01 # kugel: we do have the source for releases 15.55.21 # gevaerts: ok, but they're not on the web page 15.55.38 Quit Sajber^ (Read error: Connection reset by peer) 15.55.53 # hm, looks like a bug 15.57.01 # New commit by 03pixelma (r25468): Refine the file formats table which explains what plugins are used to open which files so that the table is only included in manuals of targets which ... 15.58.54 # New commit by 03pixelma (r25469): Remove the Recorders and Players opt around the A-B part of the repeat mode tag because all targets can use A-B repeat now (and show this in the WPS). 16.02.30 # gevaerts: oops, my bad 16.04.27 Quit xiainx (Ping timeout: 276 seconds) 16.06.39 # hm, I suspect that the freeze I was seeing yesterday is related to album art, or (more likely) sbs, or a combination of both 16.15.03 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 16.15.03 # * pamaury grumbles about control transfer handlers being called from interrupt handler but will soon be obliged to do the same with iso transfers :( 16.25.35 Join funman [0] (~fun@rockbox/developer/funman) 16.30.36 Quit blairb (Quit: Leaving) 16.32.37 # funman: FS#11172 :) 16.34.22 Join veeloc [0] (~veeloc@pool-173-66-219-137.washdc.fios.verizon.net) 16.36.16 # cool! (bookmarking it) 16.36.17 Nick krazykit` is now known as krazykit (~kkit@ppp-70-236-45-216.dsl.ipltin.ameritech.net) 16.36.24 Join xiainx [0] (~xiainx@69.70.196.158) 16.39.24 Quit veeloc (Quit: is idle) 16.43.50 # funman: you're supposed to test it, not to bookmark :p 16.44.30 Quit pjm0616 (Quit: reconnecting) 16.45.07 # right :) 16.45.08 Quit funman (Quit: free(random());) 16.46.15 Join pjm0616 [0] (~user@61.250.113.98) 16.56.32 # What file contains the Fm Radio's menu ? 16.58.19 # Please 17.00.12 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 17.00.41 Join robin0800_ [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 17.02.22 *** Saving seen data "./dancer.seen" 17.02.29 Quit robin0800 (Remote host closed the connection) 17.03.43 # paulk_: I would guess apps/recorder/radio.c 17.04.13 # gevaerts: this file just contains : do_menu(&radio_settings_menu, NULL, NULL, false) 17.04.21 # radio.h then? 17.04.45 # why don't you just grep for radio_settings_menu ? 17.05.10 # gevaerts: I think I'll do that 17.05.40 # * gevaerts wants lru_sort() 17.07.54 # I found what I was searching for ! 17.14.36 # gevaerts: isn't an lru sorted? 17.14.54 # kugel: well, yes, but not in a useful way for some operations 17.15.00 Quit xiainx (Ping timeout: 276 seconds) 17.15.21 # I just had an idea : I saw that the record button is unused for the radio screen, so I set-up rockbox to launch the record screen with radio as source when the record button is pressed. It's faster than "SELECT | BUTTON_REPEAT > Recording". 17.15.23 # hm, it's probably not that simple 17.16.42 # kugel: the problem I'm looking at is the slow font loading at boot, which is (at least partly) caused by the glyph cache being in lru order, which means that actually loading the glyphs from the font file is horribly slow on disk targets 17.17.11 # Sorting the lru cache by glyph id would fix that, but of course make the loaded cache be in the wrong order... 17.18.08 # are sure? 17.20.17 # well, it looks like it anyway 17.21.28 # isnt the problem the lots of small reads rather than the order? 17.21.58 # I don't think so 17.22.44 Join goffa [0] (~goffa@70.33.8.114) 17.23.14 # loaded the new rockbox on my gigabeat s last night ... 17.23.29 # congrats 17.23.34 Join xiainx [0] (xiainx@wpa106012.Wireless.McGill.CA) 17.23.36 Join froggyman [0] (~me@unaffiliated/froggyman) 17.23.45 # A slight difference to the OF 17.23.47 # when i try to generate a new dir list with the random folder advance plugin 17.23.52 # the thing crashes 17.23.59 # same if i try to make a playlist 17.24.08 # wondering if my hard drive is dying.. or if there's a bug 17.25.14 # on the random folder advance it displays *panic* stokov main 17.25.34 # What version? 17.25.44 # let me check 17.25.52 # how deep is your directory structure? 17.26.10 # gevaerts, not that I'm suggesting it for commit - but would simply bumping up the size of the glyph cache prevent the slower loading (which IIUC is caused by loading specific glyphs out-of-order?) 17.26.12 # gevaerts: Torne sounded like that 17.26.15 # 25457-100403 17.27.07 # soap: as far as I understand it, that will prevent the slower loading for fonts that entirely fit the new size 17.27.18 # in other words, it won't ever work for unifont 17.27.23 # gavaerts its a few deep... probably 5 dirs at times 17.28.00 # like music\artist\album\cd1\possible subdir ... that's about max 17.28.02 # unifont is bigger than the max font cache size one could specify? Is that what you are saying? 17.28.06 # goffa: in that case I'd recommend (a) checking the filesystem, and (b) using tab completion in your irc client 17.28.27 # lol... sorry about that 17.28.42 # I think the best would be to dump the cache as is along with a crc of the font file to invalidate the cache if needed 17.29.01 # goffa: Works fine here with r25459 17.29.12 # soap: unifont is 2MB 17.29.21 # rockbox have a disc scan util built in by chance? 17.29.23 # goffa: And mine is organised in the same way as yours 17.29.27 Quit evilnick (Ping timeout: 265 seconds) 17.29.31 # goffa: No 17.29.39 # yeah... i've been kind of suspecting this thing for a while 17.29.49 # sucks.. because its a 120gb 17.29.59 # kugel: that's one possible solution, yes 17.30.10 Join evilnick [0] (~evilnick@ool-457bccf5.dyn.optonline.net) 17.30.15 # gevaerts, and... what IF I made the font cache 4MB? 17.30.25 Quit S_a_i_n_t (Ping timeout: 265 seconds) 17.30.36 # soap: that would work. Do you also want some battery life? 17.30.40 # goffa: Try a discscan then again, and let us know 17.30.40 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.160) 17.30.54 # now to figure out how to do fat32 in linux 17.31.07 # gevaerts, I wasn't trying to debate practicality - just possibility. Besides, I have 64MB of RAM. ;) 17.32.07 # goffa: fsck.vfat 17.32.09 # well.. i'll let that run 17.32.12 # yeah.. found it 17.32.30 # with -a or -r if you want it to actually fix anything 17.32.37 # ah.. thanks 17.34.14 # yeah.. this thing would crash at odd times ... usually when deleting a file (not consistantly) 17.34.19 # kugel: I'm not entirely sure if the font cache has pointers in it or not 17.34.25 # gevaerts: a single binary blob (especially if we dma align the buffer) is clearly the fastest solution isn't it? 17.34.27 # thanks for the help btw 17.34.33 # oh, definitely 17.37.10 Quit flydutch (Quit: /* empty */) 17.39.07 # ah.. yeah... finding shit now ... time to hit ebay it's looking like 17.39.38 # 120 still about the biggest size for these without needing some kind of adapter? 17.40.10 # The S has a problem with the OF 17.40.25 # Bigger discs will physically fit, but the OF will reject them 17.40.36 # And Rockbox would be fine with them otherwise 17.40.59 # goffa: filesystem corruption usually isn't because of hardware issues... 17.41.17 # I can't remember the details though 17.50.30 # gevaerts: what usually causes it then 17.51.07 # bugs, random cosmic rays, crashes, disconnecting at the wrong moment,... 17.51.08 # AlexP: i'll probably wind up getting the same drive then... just had to ask 17.51.49 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 17.56.01 Join veeloc [0] (~veeloc@pool-173-66-219-137.washdc.fios.verizon.net) 17.56.44 # goffa: I'd fix the corruption and use the same disk first - as gevaerts says it is rarely due to hardware failure 17.57.17 Nick Beta2K is now known as Beta2K_ (~Beta2K@d24-36-126-101.home1.cgocable.net) 17.58.09 # yeah... i figure i have to start looking ... just so i can have one on hand 17.58.47 # although i fully intend to try to keep this thing going 18.03.01 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 18.05.15 Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 18.05.46 Join moos [0] (moos@rockbox/staff/moos) 18.09.06 Join RadicalR2 [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 18.09.10 Quit RadicalR (Ping timeout: 245 seconds) 18.10.01 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 18.11.44 Join anewuser [0] (anewuser@unaffiliated/anewuser) 18.13.55 Quit RadicalR2 (Ping timeout: 265 seconds) 18.14.07 # I'd like to update a FM Preset on rockbox.org. How can I do that ? 18.17.27 Join jeffp [0] (~jeffp@barmen.interhost.no) 18.18.55 Part jeffp 18.19.14 Join jeffp [0] (~jeffp@barmen.interhost.no) 18.21.31 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 18.25.44 # paulk_: It is a wiki, you can just edit it 18.25.58 # AlexP: yes, I've done the modification 18.26.17 # I don't understand the question then 18.26.46 # Oh, you mean you have done it since 18.26.49 # OK then :) 18.37.19 Quit xiainx (Ping timeout: 246 seconds) 18.39.17 Join stoffel [0] (~quassel@p57B4C62F.dip.t-dialin.net) 18.39.41 Part jeffp 18.46.28 Quit goffa (Read error: Connection reset by peer) 19.02.24 *** Saving seen data "./dancer.seen" 19.04.03 Quit kugel (Remote host closed the connection) 19.06.14 # bluebrother: I've update the French translation and put a new version on Flyspray (same task). If you want to commit it, feel free to do so. I'm really unsure about the remaining strings so I'm not sure I will translate them 19.07.34 # pamaury: ok. IMO it's better to have the translation somewhat updated than not at all, and I can't do anything about it as I don't speak french. So I'll commit it later. Unless you do it yourself before :) 19.08.17 # I can't commit from here so please do it ;) 19.08.38 # ok. 19.10.16 # btw, did you use the webinterface for translating? If so, is there anything that's problematic when using it? Or is it ok? 19.12.45 # First I used the webinterface but then I saved the file and used QtLinguist because it's easier. The webinterface is ok but it can't beat a dedicated tool :) 19.13.44 Join Highlander_ [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 19.13.57 # that's definitely true. So at least it meets its intentional use :) 19.23.20 # * pamaury is really puzzled, iso transfers are somewhat mysterious, especially when exactly half of packets disappear ! 19.23.50 # could that be some problem with the toggle bit? 19.25.10 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 19.26.03 # I don't know, when I set everything to the limit (3 packets of 1024 bytes per frame) everything is ok but if I send less that that to the device (typically 32 bytes per frame) then half of them are lost. It could have to do with the number of packets per frame but the device can't forsee the data size ! 19.29.36 Join xiainx [0] (xiainx@wpa062009.Wireless.McGill.CA) 19.30.48 Join Strife89 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) 19.36.18 Join mikroflops_ [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 19.36.24 Quit bmbl (Quit: Bye!) 19.37.51 # pamaury: I will look at it if there are still missing strings 19.38.35 # moos: ok thanks, there are missing ones, mainly about TTS that I don't know how to translate 19.39.17 # ohoh, ok, will have a go at it in a few 19.39.37 Quit mikroflops (Ping timeout: 260 seconds) 19.39.40 Join jnss [0] (janes@gateway/shell/sign.io/x-mrljedgszmrribbg) 19.45.30 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 19.48.41 Quit geertvdijk (Remote host closed the connection) 19.49.02 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 19.52.19 # * pamaury is even more puzzled by the solution he found to this problem... 19.57.09 Join goffa [0] (~goffa@70.33.8.114) 19.57.18 Join funman [0] (~fun@rockbox/developer/funman) 19.57.30 # Ladies and Gentlemen, usb audio WORKS !!!!!!!!!! 19.57.31 # wow 19.57.56 # \o/ 19.58.10 # \o/ awesome :) Much work to be done but at least it works 20.04.14 # congrats! 20.05.39 Join CaptainKewl [0] (jds@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 20.09.03 Quit funman (Quit: free(random());) 20.12.35 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 20.13.15 Quit mitk (Quit: Leaving) 20.14.48 Quit stoffel (Remote host closed the connection) 20.14.52 Quit n1s (Quit: Lämnar) 20.16.10 Join bint [0] (~bint@190.172.139.238) 20.17.28 Part jnss 20.17.50 # hello 20.17.51 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 20.18.08 # anyone? 20.18.12 # im fuckin bored 20.18.20 # travelling with this ugly girl 20.18.33 # she's smokin all day long and stinks 20.18.36 # what should i do= 20.18.41 # bint: this is an on-topic channel 20.18.47 # oh shit 20.18.50 # where can i go chat? 20.20.03 # wherever you like. Not here 20.20.41 # HMM 20.20.50 # isn't there any like chat channel 20.21.50 # finding chat channels is off-topic here 20.23.38 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 20.24.13 Quit robin0800_ (Remote host closed the connection) 20.26.45 Quit kramer3d (Ping timeout: 258 seconds) 20.27.28 # u suck 20.27.30 Part bint 20.35.09 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 20.40.13 # what's with the name of apps/plugins/pdbox/PDa/extra/zerox~.c ? 20.40.23 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.41.12 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 20.42.11 # Zagor: iirc the pdbox files with ~ deal with waveforms 20.43.45 # how ... creative 20.46.42 # yea, it is that 20.50.03 Join r2k000 [0] (~r2000@c-67-164-21-71.hsd1.ca.comcast.net) 20.55.20 Quit piotrekm (Ping timeout: 276 seconds) 20.57.19 Quit adnyxo (Read error: Connection timed out) 20.58.00 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 21.01.33 Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) 21.02.25 *** Saving seen data "./dancer.seen" 21.02.44 Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) 21.04.06 # can I combine the "Milestones and Project plan" section with the "Subdivide the working period in several parts" section? I'd repeat myself a lot if not 21.04.14 # (re: GSoC application) 21.05.56 # New commit by 03zagor (r25470): Added source and font links to manual download page. Cleaned up the links a little. 21.06.11 # kugel: I don't think that's a problem 21.06.36 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 21.16.20 Quit Strife89 (Read error: Connection reset by peer) 21.16.45 Join Strife89 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) 21.17.15 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 21.20.00 # FlynDice: if you have time, see http://pastebin.com/z9TeQJXX for the modification I propose about the sd code. I hope this little piece of code is clearer than the explaination I gave last time. I didn't check this code because I don't have a SHDC card. 21.24.18 # * pixelma points out that the wiki page she's referring to is actually called LatexGuidelinesTalk :\\ 21.24.32 # in the commit message that is 21.29.31 Quit Strife89 (Quit: Easter get-together.) 21.32.30 # pamaury: it's a bit hard to distinguish the API changes from the isochronous additions in your tree. We'll need to update other drivers to deal with the changes... 21.34.16 Quit guymann (Ping timeout: 240 seconds) 21.34.56 # gevaerts: all changes in the api are in usb-drv.h, clearly described, only usb-drv-arc is ported of course. We could have a new #define HAVE_NEW_USB_API :) 21.35.25 Join guymann [0] (~charlie@66-159-137-10.adsl.snet.net) 21.36.07 # soap: Clarification from MCIMX31.pdf : 2 Supply voltage is considered “overdrive” for voltages above 1.47 V. Operation time in overdrive—whether switching or 21.36.07 # not—must be limited to a cumulative duration of 1.25 years (10,950 hours) or less to sustain the maximum operating voltage 21.36.07 # without significant device degradation—for example, 25% (average 6 hours out of 24 yours per day) duty cycle for 5-year rated 21.36.07 DBUG Enqueued KICK jhMikeS 21.36.07 # equipment. To tolerate the maximum operating overdrive voltage for 10 years, the device must have a duty cycle of 12.5% or 21.36.07 # less in overdrive (for example 3 out of 24 hours per day). Below 1.47V, duty cycle restrictions may apply for equipment rated 21.36.08 *** Alert Mode level 1 21.36.08 # above 5 years. 21.36.56 Quit anewuser () 21.38.24 # gevaerts: I don't know how much it represents to port all drivers but it's probably not negligeable, that's why I propose to have a switch for this new api 21.38.25 Quit linuxstb (Ping timeout: 258 seconds) 21.38.29 # *much work 21.38.32 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 21.39.06 # pamaury: well, it depends on how clean you can make the set of ifdefs needed 21.39.34 # the _nonblocking() change is fairly trivial I guess, so we could do that 21.40.04 # My current code emulates the old api with the new one, it's only a matter of adding code within #ifdef (the usb_drv_{select_mode,allocate_slots}, whose name are probably not very well chosen) 21.40.36 # You seem to have a spurios change in logf.c 21.41.15 # Oh, don't worry the changes in my repo are not up to date (I can't push from where I am) and I even changed usb-drv-arc today so the code is not clean 21.41.37 Join kugel_ [0] (~kugel@e178098254.adsl.alicedsl.de) 21.41.53 Quit kugel (Disconnected by services) 21.41.57 Nick kugel_ is now known as kugel (~kugel@e178098254.adsl.alicedsl.de) 21.42.01 Quit kugel (Changing host) 21.42.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.42.11 # Apart from the other driver issues, I think the changes are fine 21.43.47 # Ok I need to go, you can continue to comment the changes, I'll read them later. 21.44.07 # I was actually planning to look for a bug elsewhere :) 21.44.30 # jhMikeS: do you have a theme installed that includes an sbs? I think I suspect those 21.46.09 *** Alert Mode OFF 21.47.40 Join MaadMan [0] (~MaadMan@188-194-48-219-dynip.superkabel.de) 21.47.54 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 21.47.54 # * bluebrother grumbles at http://www.winehq.org/site/docs/wine-faq/index#HOW-CAN-I-DETECT-WINE 21.48.41 # bluebrother: that means you should ask them to fix broken usb enumeration in wine 21.49.22 # gevaerts: I'm rather confident that after fixing that other issues will come up. Especially once we manage to add MTP support. 21.49.54 # so no, I _really_ don't want to run the windows binary in wine, and I _really_ want to be able informing the user that there's a linux binary of the program around. 21.50.21 # bluebrother: I know, but if you ask them about these issues a few times, I suspect they might get the message :) 21.51.31 # Ah, they live in #winehq 21.51.59 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 21.55.19 # jhMikeS: some more testing seems to point to the freezing occuring when switching *away* from http://themes.rockbox.org/index.php?themeid=258&target=gigabeatfx 21.56.03 # hm, interesting. It's not frozen now, but since a few minites the "Loading 21.56.21 # " splash is there, and I get a few seconds of music alternated with a few more seconds of silence 21.56.33 # * bluebrother wonders if it's a valid way to trust on portability differences between windows and linux: http://www.winehq.org/docs/winelib-guide/portability-issues 21.56.46 # gevearts: I only have the RB "OEM" themes on that one 21.57.17 # jhMikeS: if I skip that one theme, I don't see issues either 21.58.16 # Oh, it finished switching! 21.58.46 # gevaerts: I don't have that one there. Just: cabbiev2, DockPod Aqua, iCatcher, rockbox_default, Rockboxed, Unicatcher 21.59.45 # * gevaerts decides to try the sim 21.59.48 # iCatcher can hang a little though when loading 22.04.43 # something it takes a few seconds, but I can't get duppel, away to to it, to "hang" though I might hear music restart twice when going to it 22.09.15 # bluebrother: couldnt you run wine from within rbutil and assume windows if it's not found? 22.10.02 # wine from within rbutil? 22.10.28 # ah, by checking for the binary? Well, that won't work if wine isn't in PATH 22.11.42 # that's very unlikely I'd say (you couldn't just double-click a .exe then IIUC?). does it need to work 100% of the time? 22.12.20 # I can't reproduce this in the sim 22.12.37 # or detect if a wineserver process is running? 22.12.57 # * gevaerts thinks that kugel might know something about sbs loading 22.13.49 # hm, I think that all won't work, since it would give false-positives if rbutil itself isn't run under wine but other apps 22.14.05 Join jd [0] (jd@74.13.169.41) 22.14.05 Quit jd (Changing host) 22.14.05 Join jd [0] (jd@Wikipedia/HellDragon) 22.14.29 # gevaerts: uhm yes, but I have no idea why particular themes would load slower 22.14.46 # kugel: well, "slower" isn't the issue. Sometimes it just freezes 22.15.02 # It 22.15.17 # no idea about that either 22.17.13 # have you checked the disk/filesystem? 22.17.46 # yes, several times during the past days :) 22.19.05 # it's probably time for lots of splashes 22.21.54 # kugel: any idea where I should start looking? 22.22.17 # have you figured out if it's the wps or the sbs? 22.22.59 # well, it seems to happen when I move away from the one theme that has an sbs 22.23.01 # * pixelma wonders why she gets a rockbox.iaudio and no rockboxui.exe when trying to build a win sim under linux using the "w" option in an advanced build 22.23.03 Join Bagder [0] (~daniel@rockbox/developer/bagder) 22.23.04 # anyway, skin_data_load() is the function that handles the loading 22.24.08 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 22.27.35 Quit kramer3d (Ping timeout: 260 seconds) 22.29.58 Quit Zagor (Quit: Leaving) 22.31.31 # bluebrother: Is your worry about wine just from http://forums.rockbox.org/index.php?topic=24402.0 or have there been others? 22.32.09 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 22.33.53 # yay, now the screen is just corrupted... 22.34.13 Quit timaeus (Quit: Page closed) 22.35.16 # linuxstb: it's the post that reminded me of the issue. I've seen people try to run it on wine in the past a few times 22.35.44 # fun, now the screen refuses to show any "d" 22.35.58 # I remember a post somewhere (don't think it was our forum) where someone complained about autodetection and installation not working, and he tried running it with wine :/ 22.36.20 # * gevaerts sees files like "test_coec_log_01.txt" 22.37.41 # gevaerts: I'm not sure the skin engine is the cause here 22.37.59 # kugel: it goes wrong after the settings (?) code prints "Loading..." and before it enters skin_data_load() 22.38.08 # bluebrother: doesn't Qt offer runtime detection of the os? 22.38.34 # * jhMikeS just wonders what's different on gevearts' F than his own here. 22.38.38 # kugel: I'm not sure either. All I know is that there seem to be some stray pointers every now and then 22.39.08 # kugel: that doesn't work at all. Runtime detection of the OS should return Windows when running on wine, obviously. 22.39.27 # and I guess you're referring to the OS macros Qt offers. But that's macros, so no runtime detection 22.39.44 # jhMikeS: my config right now is http://pastie.org/902994 22.39.44 # however, the solution the guys in #winehq suggested works fine so I'm going for that. 22.39.55 # no, my idea was runtime detection but implement different behaviors with the macros 22.40.22 # it wasn't so obvious that it should returns windows to me 22.40.59 # bluebrother: what solution? 22.41.11 # well, IMO it's pretty obvious: wine is trying to emulate Windows, so a syscall retrieving the windows version should return a valid windows version 22.41.27 # kugel: the solution I haven't mentioned here yet ;-) Check for a registry key 22.42.16 # sure you haven't mentioned it, that's why I'm asking ;) 22.48.08 Join cjcopi [0] (~craig@charon.craig.copi.org) 22.48.51 # jhMikeS: could you try with http://themes.rockbox.org/index.php?themeid=687&target=gigabeatfx ? That's a new version that actually loads the correct font (the old version still used the old font names) 22.49.14 # gevaerts: duplicated! cleared my settings to stock, loaded your config + druppel, rebooted, started playback, crash when switching back to cabbiev2 22.50.46 # Since I added splashes, the most common symptom is a corrupted font 22.50.49 # gevaerts: so now you want me to try that link to see if it stops? I duped your results before that. 22.51.43 # jhMikeS: not sure. Does it use nimbus 14? You might also still have the old fonts installed in which case it won't make any difference 22.52.27 Quit kramer3d_ (Quit: Leaving) 22.52.34 # gevaerts: it seemed to be stuck with the stock system font 22.52.53 # OK, that's useful to know 22.53.15 # I was beginning to suspect that maybe it was something in the font loading, but that seems unlikely then 22.54.07 # * gevaerts thinks that this is a weird bug 22.54.21 # I have 19-Nimbus.fnt only. I don't think I have that installed 22.54.32 # *Nimbus 14 22.55.02 # maybe it's from the font pack. Anyway, if you can reproduce it, the font is not important 22.55.55 # Maybe the antiskip setting makes it more likely to hit? I don't really see any other setting that should make a difference 22.56.16 # you had the correct font I take it? I don't have it at all, so you're likely correct. 22.56.30 # yes, I do have it 22.57.12 # jhMikeS: you need the font package 22.57.13 # ok, just sanity checking. settings seem relevant. I suppose I'll pastebin mine. 23.00.57 # gevaerts: what i just saved before changing to your config: http://pastie.org/903017 23.01.30 Quit paulk_ (Read error: Connection reset by peer) 23.02.29 *** Saving seen data "./dancer.seen" 23.03.23 # * gevaerts wonders why he has gather runtime data set to on 23.04.06 Quit xiainx (Ping timeout: 240 seconds) 23.05.02 # jhMikeS: can you see if "gather runtime data" makes a difference? That seems to be the one that does it here 23.06.03 # sure 23.07.41 # where's that one located again? lol (i don't use it) 23.08.05 # General->Database 23.08.42 # New commit by 03bluebrother (r25471): Try to detect Wine. ... 23.08.44 # hm, I have it disabled now, and it just froze 23.10.48 # I just switch from druppel to cabbiev2 and it did it again. First the fonts were trashed (metadata display trashed) then it poped, locked and the screen turned white. 23.12.22 # I just had it send noise to my ears 23.13.01 Nick Highlander_ is now known as Highlander (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 23.17.25 # probably too much smurfing... 23.17.37 # sorry, couldn't resist 23.17.38 # druppel->cabbiev2 switch is pretty reliable 23.18.07 # smurfs!! those wretched, vile, blue creatures! 23.19.06 # OK, I've now reproduced it with default settings, i.e. an empty config.cfg 23.22.18 Quit liar (Ping timeout: 258 seconds) 23.22.51 Quit MaadMan (Read error: Connection reset by peer) 23.25.30 # kugel: Do we have the same problem with the buttonlight for the fuzev2 with GPIOD being used for both uSD interface and general I/O? 23.25.59 # So what makes "druppel" special? 23.26.26 # FlynDice: not the same problem, but the buttonlight pin is the same as the internal-external-storage select pin (gpiob5) 23.26.27 # gevaerts: the sbs and floating listview with metadata always visible I suppose 23.26.43 # which is probably why the buttonlight blinks when playing something off the microsd 23.27.23 # gevaerts, jhMikeS: still not reproducible in the sim? 23.27.35 # hmm ... this happened to me before don't remember how i fixed it ... i have a corrupt dir in the file system... its basically a mirror of root 23.27.46 # if i attempt to delete that dir it'll delete everything out of root 23.28.30 # FlynDice: that was a yes and no :) so far there's nothing special on gpiod except the power and home button (but that seems to work so far) 23.28.30 # perhaps when switching away, metadata is being accessed that is no longer present? 23.28.46 # kugel: So There shouldn't be a problem if we just leave XPD configured as the uSD interface. Do you think that's accurate? If that wont cause a problem I've got the clip+ uSD functioning again. 23.28.59 # kugel: I haven't managed anyway 23.30.00 # FlynDice: just go for it, I'll report failure :p 23.30.14 # jhMikeS: could be. It does a rebuffer (due to different AA size) 23.30.23 # I'm sure you will ;-) 23.30.38 # Although when I had the splashes, it looked like the crash happened before it even started on that 23.30.48 # I'll give it a try here shortly. 23.31.02 # the rebuffer happens at the very end of skin loading (but once per skin) 23.34.31 # is druppel supposed to switch to 14-nimbus? it seems to not load it but I can load that from Theme Settings->Font ok 23.35.21 # jhMikeS: the "old" (i.e. until an hour ago) version referred to nimbus-14 23.35.52 # aha, ok. now I just get the system font 23.36.58 # Ah, news! 23.37.15 # I managed to reproduce it by loading 15-Adobe-Helvetica while in druppel 23.39.36 # hmmm...I can't seem to get results that way. did it take awhile? 23.39.53 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.40.09 # first time 23.40.43 # is there any protection against text output when overwriting the old font? 23.43.17 Quit Highlander (Quit: Quitte) 23.45.27 # hm, I can't manage to reproduce it just by switching fonts anymore, but I also don't seem to have it if I first switch to the right font and then switch themes 23.46.52 # * gevaerts *always* speaks too soon 23.48.33 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 23.48.37 # no worry, I do that *alot* 23.49.17 # what can we try next? 23.51.36 # I don't know. Any nice way to make sure nothings writing into naughty places? 23.52.21 # check all theme-related data makes sense when used, somehow