--- Log for 14.09.109 Server: orwell.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 18 days and 1 hour ago 00.07.18 Join kushalone [0] (n=kushal@12.169.180.178) 00.11.35 Join freqmod [0] (i=quasselg@dhcp208-240.ed.ntnu.no) 00.14.53 Join PaulJam [0] (n=Paule@p54BECF93.dip.t-dialin.net) 00.19.28 Quit stripwax_ ("http://miranda-im.org") 00.20.55 Join bubsy [0] (n=bubsy@94.139.72.137) 00.21.58 Quit matsl (Read error: 110 (Connection timed out)) 00.23.57 Quit KBH (Read error: 54 (Connection reset by peer)) 00.24.19 *** Saving seen data "./dancer.seen" 00.24.54 Join dfkt_ [0] (i=dfkt@chello062178002170.1.11.univie.teleweb.at) 00.25.10 Join KBH [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) 00.26.25 Join toffe82_ [0] (n=chatzill@adsl-71-132-86-123.dsl.sntc01.pacbell.net) 00.27.25 Quit Dhraakellian (Read error: 60 (Operation timed out)) 00.28.42 Quit AndyI (Read error: 54 (Connection reset by peer)) 00.28.55 Quit ender` (" Man created gods. The opposite remains to be proved. -- Serge Gainsbourg") 00.28.58 # well saratoga_ domonoky kugel and krazykit THANK YOU!!! This little exercise has let me learn a bunch about various processes and best of all, I'll be able to take my mp3 player with me. Thanks again. 00.29.19 Join freqmod_qu [0] (i=quassel@dhcp208-240.ed.ntnu.no) 00.29.21 Join Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 00.29.26 Join AndyI [0] (n=pasha_in@212.14.205.32) 00.29.33 Join ch4os_ [0] (n=ch4os@gentoo/user/ch4os) 00.29.43 Quit freqmod (Remote closed the connection) 00.30.37 Quit freqmod_qu (Remote closed the connection) 00.30.47 Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 00.30.48 Quit toffe82 (Read error: 60 (Operation timed out)) 00.30.54 Nick toffe82_ is now known as toffe82 (n=chatzill@adsl-71-132-86-123.dsl.sntc01.pacbell.net) 00.31.59 Quit ch4os (Read error: 145 (Connection timed out)) 00.33.54 Quit dirtydav ("Leaving") 00.34.23 Quit efyx_ (Read error: 110 (Connection timed out)) 00.36.59 Nick hellDragon is now known as HellDragon (i=jd@Wikipedia/HellDragon) 00.41.51 Quit dfkt (Read error: 110 (Connection timed out)) 00.45.17 Part domonoky 00.45.24 Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) 00.53.05 Quit Szeraax ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 00.58.45 Quit PaulJam (Read error: 104 (Connection reset by peer)) 01.06.15 Quit froggyman ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 01.06.50 Quit Farthen (Nick collision from services.) 01.07.11 Join Farthen_ [0] (n=chatzill@e176155001.adsl.alicedsl.de) 01.07.17 Nick Farthen_ is now known as Farthen (n=chatzill@e176155001.adsl.alicedsl.de) 01.11.57 Nick shaggy-h is now known as chrism (n=kiwi@host-87-74-127-193.dslgb.com) 01.12.09 # anyone familar with the sim? 01.12.14 # i'd like to adjust its memory 01.20.34 # does the sim simulate the same amount of memory for buffering? looking at the clip sim the buffering thread info is different 01.29.30 Quit kushalone ("Leaving. I cannot promise to be back but most likely will.") 01.37.37 Join mt [0] (n=Miranda@rockbox/developer/mt) 01.40.46 Quit liar (Remote closed the connection) 01.43.45 # hmm nevermind, it seems to be working now 01.46.29 # New commit by 03mt (r22698): Blackjack: Fix keymap for Gigabeat F as button 'A' and button 'Select' were swapped. (FS#10563 by Clément Pit-Claudel) 01.48.36 # Could anyone close that task ? (I seem to have not got dev rights on FS yet.) 01.49.33 # mt: done 01.50.11 # if you email Zagor he can setup developer permissions on FS 01.50.21 # Thanks ! 01.50.43 # I asked him one in a PM, but maybe he forgot. 01.50.51 # I'll e-mail him. 01.51.19 # FS#10182 (Addition of librm to svn) could be closed too. 01.52.57 # pk done 01.52.57 # ok 01.54.06 # Thanks :) 01.54.17 # i dropped the filebuffer on the sim to 200KB but surprisingly it hasn't dead locked yet 01.54.53 # its rebuffering 2-3 times a second 01.55.54 # huh it just printed "failed to add handle" but didn't deadlock 01.56.25 Quit mcuelenaere () 01.57.50 # do logf's print in the sim? 01.59.23 # Iirc there's an "#ifdef SIMULATOR #define logf DEBUGF" in logf.h ?, or you could just define that in the file(s) you need to debug. 02.03.54 # the clip is a nice target to test on, compiles so fast 02.06.37 # Sadly I'm currently on a Virtual machine and my computer is in a crappy state, so what may be fast for others is barely average for me :( 02.07.35 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 02.08.03 # linuxstb: TheSeven has been looking for you 02.10.45 # hmm .. not too bad. ~6 minutes (clip sim build) 02.11.14 # ouch 02.11.22 # :'( 02.14.07 # i wonder whats different about buffering in the sim that makes it more stable then on the clip even when it has less memory 02.24.21 *** Saving seen data "./dancer.seen" 02.35.28 Quit gevaerts (Nick collision from services.) 02.35.41 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 02.49.08 Join AndyIL [0] (n=pasha_in@212.14.205.32) 02.49.09 Quit AndyI (Read error: 104 (Connection reset by peer)) 02.52.07 Quit dfkt_ (Read error: 104 (Connection reset by peer)) 03.10.40 Quit bubsy ("I'll be back somewhere in time") 03.13.29 # saratoga_: what files did you try? 03.14.14 # kugel: just been looping MP3s 03.14.32 # been an hour or two without an glitches with a 100KB file buffer 03.15.05 # sorry by looping I mean playing albums on repeat, not the same track 03.16.07 # i don't know enough about how the sim differs for buffering though 03.16.35 # need to ask bagder when hes around 03.17.17 Quit mt () 03.43.00 Join froggyman [0] (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 03.47.12 # i tried the same trick on the e200v1 and it deadlocks very quickly with a 200KB buffer 03.47.36 # typically with a minute or so, although i can skip tracks normally until that happens so i don't think its specific to the end of the file 03.47.58 # so its definately not an AMS specific problem, but it does not happen on the sim 03.51.55 # boosting seems to be completely screwed up with a small buffer, though that may be unrelated 03.52.21 # i think it boosted for a minute straight with 98% full pcm buffer, then unboosted and stayed that way 03.54.03 Join bubsy [0] (n=bubsy@94.139.72.137) 04.01.36 # huh theres hardly any difference between how playback/buffering works on the sim and on devices 04.02.11 Quit chandoo ("Leaving") 04.02.30 Quit BHSPitLappy (Remote closed the connection) 04.06.17 Quit TheSeven (Nick collision from services.) 04.06.31 Join The_Seven [0] (n=theseven@dslb-084-056-146-074.pools.arcor-ip.net) 04.06.39 Nick The_Seven is now known as TheSeven (n=theseven@dslb-084-056-146-074.pools.arcor-ip.net) 04.11.20 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 04.13.04 Quit froggyman ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 04.15.22 # wow sim finally did deadlock, just takes a really, really long time 04.15.35 # and I had logging enabled 04.16.31 # great 04.16.41 # tracking down the low mem problem? 04.18.30 # assuming the one on the sim is the same, then yes 04.19.22 # as far as I can tell, the first indication that something is wrong comes when add_handle fails during a call to bufopen while not buffering ID3 04.19.36 # wouldnt it be great if its a wierdness which happens in a very small memory range? like 1.2MB->3MB or soemthing :) 04.19.49 Join moos [0] (i=mostafa@rockbox/staff/moos) 04.19.57 Join Lss [0] (n=Lss@cm204.delta92.maxonline.com.sg) 04.20.12 # hmm theres two ways add_handle can fail and the return code isn't checked so I'm not sure which it is 04.20.49 # fix both! 04.21.53 # i need a way to make the sim play faster so that I don't have to wait all night to rerun it 04.22.32 # that should be doable with some tricks... 04.22.52 # but wouldnt that possibly invalidate the tests? 04.23.27 # i assume the buffering system is deterministic 04.23.35 # as long as I don't touch anything 04.23.38 # *maybe* change the tick rate to much faster? 04.23.49 # kernel-sdl.c would be my guess 04.24.14 # another odd thing is that the buffer handle number continously increments, although only very slowly 04.24.17 # i'm not sure if thats a leak or if they're supposed to do that 04.24.22 *** Saving seen data "./dancer.seen" 04.24.28 # in my case it failed at 40, although the max is defined to be 256 04.24.37 # nico_P is the one you want to answer these... 04.24.47 # yes i should email him 04.24.54 # put what you find in an email for the dev-ml... 04.25.08 # i wonder why the sim is so much more stable then devices 04.25.29 # crashes that take seconds on the device take hours on the sim 04.25.30 # it might still be a timing issue 04.25.41 # I havnt got a consistant repro on my clip 04.26.19 # the way you hit buttons while starting playback could change the outcome 04.26.39 # really?! 04.26.52 # i'm guessing but it seems reasonable 04.26.59 # buffering is all tied into playback 04.27.18 # and the order in which buffering happens depends on the state of all sorts of variables in playback 04.28.12 # I thought the order was constant? 04.29.02 # the order is constant but it often tries to buffer many times before succeeding with such small buffer sizes 04.29.11 # though i could be misunderstanding the output 04.29.20 # interested in a pastebin? 04.29.29 # are you use its failing in buffering? 04.29.30 # sure 04.29.49 # no I'm not 04.31.48 # http://pastebin.ca/1564899 04.31.56 # last 20 minutes or so of output 04.32.26 # you dont have a clip do you? 04.32.33 # line 3199 is the first abnormal line i can see 04.32.37 # I do have a clip 04.32.47 # * JdGordon still waiting for it to load 04.32.49 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 04.32.50 # ok cool 04.33.00 # I tihnk the best way is logf to disk on target 04.33.24 # always enabled for low mem untill we figure this out 04.33.46 # line 3199 happens because either the second or third case in add_handle fails 04.34.44 # can you paste is anywhere else? 04.34.45 # sorry 2nd or third chance for add_handle to return a failure 04.35.00 # pastebin.ca is a problem? 04.35.05 # i could just email you the whole log 04.35.21 # ah no, finally loaded 04.35.57 # my guess is the handle number incrementing isnt a bug 04.36.07 # based on KISS 04.36.51 # even if it is a bug it increments so slowly you'd probably never run out of handles, unless it triggers some other problem first 04.40.59 # I wonder if something dies if not enough audio data gets buffered and something gets confused there? 04.41.13 # stupid question... are you useing the same folder for sim+clip? 04.41.51 # maybe that doesnt make a difference... 04.42.18 # no i'm using a different folder 04.42.30 # you mean build folder right? 04.43.28 # music folder 04.43.49 # it *should* be consistant for a playlist... shouldnt it? 04.45.37 # I think so 04.46.17 # actually remembering a previous bug, I did once find a playback bug that was fully reproducable by simply playing the first track in a folder 04.46.26 Quit bgupta (Read error: 60 (Operation timed out)) 04.46.34 # and using the sansa in between as long as i did't force an early rebuffering would not prevent the crash 04.46.49 # although it would take almost 20 minutes to happen 04.47.41 # so the playback engine *should* be deterministic right? so if you're a big enough masocist you could work out exactly the debug output you should be getting and work backwards? 04.48.36 # actually... a possible way to triger it is to maybe force buffering to fail so it only ever has one handle in the buffer... that might lead to something useful? 04.48.51 # * JdGordon hopes he isnt giving out too many red herrings :p 04.49.34 # i'm not sure, i don't have the slightest clue what all this code is actually doing 04.49.48 # other then that it looks like a linked list of blocks in a ring buffer 04.50.11 # is there some way to programatically start playback (perhaps using auto.rock?) 04.50.23 # sure 04.50.43 # "resume playback" start screen... or whip up a plugin to do it 04.51.01 # or even simply add the code needed to main() 04.51.24 # where does it store the resume information? 04.51.47 # .playlist_control 04.52.00 # so make a copy of that and it should be ok... 04.52.08 # also nvram.bin maybe 04.52.29 # what does that file do? 04.53.18 # the combination is the resume info.... 04.53.29 # tucker time... back in a bit 04.53.36 # i mean whats in it? its just binary data 04.53.38 # ok 04.55.30 # hopefully nico will have some idea whats going 04.59.34 Quit PSPdemon (Read error: 110 (Connection timed out)) 05.02.22 # saratoga_: maybe bryanjacobs has a clue too, not sure if he comes back though 05.03.53 # ok found a combination that crashes the sim pretty quickly 05.04.09 # lets see if the nvram.bin and playlist file are enough to reproduce it 05.07.16 # saratoga_: wanna transfer it onto the clip? 05.07.34 # or just the files for other to repro? 05.11.13 # kugel: I'm still trying to figure out how useful it is 05.11.30 # i did it twice now and the output is similar, but not the same 05.11.40 # and it crashes at the end of the first track which is different then what i saw before 05.12.10 # not entirely deterministic? 05.12.11 # its interesting after about 5-10 buffering cycles the output of the two runs starts to diverge slightly 05.12.28 # some buffer positions remain the same while others change 05.13.12 # that could be cause and symptom actually 05.13.39 # is the output the same for stuff that doesn't crash? 05.14.17 # i think it'll always crash if you wait long enough with a small buffer 05.16.37 # for what its worth on all my runs, if the line around 950 in buffering.c that begins with "struct memory_handle *h = add_handle(size-adjusted_offset, can_wrap, false); " returns h = NULL, then playback will deadlock 05.17.40 # although it can take a second or two for it to happen 05.18.34 Quit alexbobp (Client Quit) 05.21.38 Join alexbobp [0] (n=alex@75.42.224.116) 05.23.55 # saratoga_: h is checked though, does the caller check the return? 05.24.17 # yeah it does 05.24.51 # it catches the failure, but as far as I can tell this type of fail only happens just before it deadlocks, so its probably a symptom 05.25.32 # what what I remember the lock happens when the buffer is empty, doesnt it? 05.25.57 # it empties during the lock, i'm not sure what its state is when it does lock up 05.26.08 # but probably empty since i don't think the buffering code would be running otherwise 05.27.29 # oh wow ran it a third time and didn't get a deadlock 05.29.11 # saratoga_: it always seemed to me as the lock would happen when rebuffering starts 05.29.41 # it which case I wouldn't even expect the problem in bufopen 05.30.14 # maybe it fails sooner and this is just the first thing I happened to catch 05.32.05 # ugh why is playback endlessly trying to load metadata 05.32.27 # it calls get_metadata at least once a second as far as I can tell 05.32.33 # is that normal? 05.35.48 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 05.35.50 # huh it endlessly tries to open the metadata for the next track while playing the current one, even though the buffer is much too small 05.38.33 # i guess the buffering thread assumes theres always enough memory to buffer at least the rest of the current track and the start of the next, and then fails gracefully (???) otherwise 05.39.25 Quit CaptainKwel (Remote closed the connection) 05.42.08 Quit BHSPitMonkey (Remote closed the connection) 05.43.43 # the next track metadata should be loaded into a sepearte buffer 05.43.56 # but yes, it does make sense that it keeps trying to buffer it 05.44.05 # its the first bit of the next track that gets buffered 05.44.29 Quit Horscht ("Verlassend") 05.44.50 # i don't see where it refills the current track? 05.45.09 # as far as I can tell audio_load_track just keeps trying to load the next track 05.46.20 # how big is the id3entry struct? 05.47.14 # where is that located? 05.47.33 Join Johnny_ndr [0] (n=Johnny_n@fm-ip-118.137.91.206.fast.net.id) 05.47.46 # metadata.h 05.47.59 # why the wave files aren't included in the database ? 05.48.09 # bufopen returns buffer full for id3 loading too 05.48.10 # probably another non issue, but iirc its pretty big.. so it could be failing a few times before there is enough room fo i 05.48.13 # wav files don't have tags and so cannot be in the database 05.48.14 # for it* 05.48.29 # Wave files can have tags 05.48.43 # I tagged all my wave files collections 05.48.55 # you can put whatever tags you want on them but it doesn't mean anything can read them :) 05.49.08 # which means ? 05.49.29 # JdGordon: do you mean mp3entry? 05.49.36 # ah, yes 05.50.22 # looks like its at least a few KB 05.50.34 # what are you thinking? 05.50.49 # re why its trying to load it so often 05.51.07 # side point... its not actually crashing because the id3buf isnt big enough is it? 05.51.27 # well, I'll wait for next revisions on wave then 05.51.33 # there is a MEMORYSIZE > 2 #if there 05.51.57 # where is this? 05.52.03 # metadata.h 05.52.06 # in apps 05.52.14 Part Johnny_ndr 05.52.27 # hmm... proibably not, it would be a different type of failure i tihnk 05.52.54 # JdGordon: i don't think so, it was 300 for all targets not too long ago 05.53.02 # if it was that it would be consistant for a track 05.53.03 # lear increased it for long comments 05.53.58 # saratoga_: so the buffering or playback is caught in a loop? 05.54.19 # i'm not sure 05.54.58 # i wasn't able to trace the call chain very far before my trick stopped being able to crash the sim 05.55.05 # debugging on target might be a better idea 05.55.14 # since that seems more consistently able to crash things 05.57.30 Quit tchan ("WeeChat 0.3.1-dev") 05.57.31 # just stopped for metrack count:0, handle count:1, 3.8MB file rem 05.57.59 # 171/393K alloc usage 05.58.12 # yeah thats what happens for me 05.58.27 # damn, the audio buffer is tiny! 05.58.29 # it runs down the buffer without being able to rebuffer it, since all attempts to allocate new buffers fail 05.58.41 # saratoga_: it might be interesting to debug the filling variable 05.58.58 # it doesnt make sense that it tried to add new ones... the current file isnt finishe 05.58.59 # d 05.59.10 # that should tell us whether it's buffering or finished or whatever when it locks 05.59.14 # it tries to add the next track on every rebuffer 05.59.17 # i don't know why 06.00.27 # pastebin hates your huge paste :) 06.01.13 # has anyone managed to get the lock with non-mp3? 06.01.28 # this time it died while trying to load a track, in which case it happened in audio_finish_load_track in playback.c 06.02.33 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.02.58 # good luck guys, I'm getting a bit of sleep 06.03.16 Join Johnny_ndr [0] (n=Johnny_n@118.137.91.206) 06.03.16 Quit kugel (Remote closed the connection) 06.03.52 # oh yeah, why everytime I wanna play an audio file, it asks for "erase dynamic list ?" 06.04.23 # i bet its stuck endlessly bouncing back and forth between audio_finish_load_track and the event queue in the placback thread 06.05.12 # and how do I fix this ? 06.05.28 # turn off "ask to delete dunamic playlists" 06.05.30 # I just reflashing with the latest build 06.05.31 # rtfm :) 06.05.35 # where ? 06.07.30 # * JdGordon wonders why the pcm buffer is so large compared to compressed 06.08.35 # is there a memory leak on the "alloc" value? whatever that is? 06.09.03 # I see, very funny =p 06.09.06 Part Johnny_ndr 06.09.38 Join Johnny_ndr [0] (n=Johnny_n@118.137.91.206) 06.09.40 # PCM is large so that if you have a thread that doesn't yeild for a couple hundred ms it doesn't make the audio skip 06.09.59 # so dynamic playlist can't be turned off ? 06.10.11 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 06.11.18 Join dirtydav [0] (n=puppy@c-24-35-101-80.customer.broadstripe.net) 06.11.47 # when it deadlocks its endlessly calling buffering_low_buffer_callback 06.12.21 # so its in playback.c at least 06.12.30 # Ok, waiting for next revision then, thanks 06.12.30 # hello, anyone here know if its safe to delete ALL of the files on an ipod? 06.12.48 # yes it is 06.12.58 Part Johnny_ndr 06.13.07 # JdGordon: you want a log of it deadlocking with both playback.c and buffering.c logging? 06.13.28 # meybe... thats a codec callback isnt it? 06.14.09 # nope, buffering 06.14.13 # a friend said an ext-2 linux file system would be quicker then FAT32 is this true? would I gain any hard drive speed on an ipod like this? 06.14.29 # not if you want to use it as a music player 06.14.35 # your ipod won't be able to play music if you put some oddball file system on it 06.14.47 # saratoga_: yeah, can you email me the log? 06.16.04 # I think i can see a potential loop there, but your previous log doesnt show it 06.16.48 # sent 06.16.58 # hmm, what file systems can rockbox run on? or would the ipod not work with it? (or just leave it as-is) 06.17.01 # this is a crash on track change and not the rarer crash mid track 06.17.08 # fat32 06.17.29 # ahh, fat32 only huh 06.18.26 # fat12/16 also no? 06.20.09 # yeah but maybe not without recompiling i don't remember 06.20.32 # there is an obvious loop there :) 06.20.53 # although I'd expect more messages between the "low buffer callback" lines 06.21.16 # maybe thats a clue! 06.21.24 # saratoga_: get playback.c:1489 to show the filling value 06.22.17 # there are 3 places that callback can be called... one is in #if 0 so ignoreable 06.22.25 # 1365 and 1426 in bufferng.c 06.22.44 # the first I dont think is the problem or there would be more debug (i tinhk) 06.22.46 # logf("low buffer callback: %d", filling); ? 06.22.53 # something like that 06.23.09 # it does nothing if its not filling which makes no sense 06.23.11 # i tihnk :p 06.23.42 # 1426 is in an IF 0 block? 06.23.59 # sorry, i meant 1416 is the important one 06.24.23 *** Saving seen data "./dancer.seen" 06.25.27 # well its running i'll just wait for it to crash 06.25.39 # does this look completly wierd to you also... "if (filling == STATE_FULL || filling == STATE_END_OF_PLAYLIST)"? 06.26.43 # I wonder if that shouldnt be "if (filling != STATE_FILLING)" 06.30.32 # * JdGordon agrees we need to find a way to speed up playback :) 06.30.50 # full means you can't add more tracks, end of playlist means theres no more tracks to add 06.31.05 # so maybe its a valid condition 06.31.43 # i'm tempted to see what happens if I change teh HZ/2 in queue_wait_w_tmo in audio_thread 06.31.54 # maybe HZ/10 would deadlock sooner 06.32.16 # but getting into that callback means we have detected we are low and need to rebuffer 06.32.19 Join billenium [0] (n=billeniu@c-98-237-8-252.hsd1.pa.comcast.net) 06.33.00 # yeah that does seem odd 06.33.12 # i wonder why that callback would be called if theres really no more files left to buffer 06.33.28 # buffering doesnt know there is nothing left to buffer 06.33.49 # I was looking through my latest edition of MAXIMUMPC and what do i see, but an article on rockbox/how to install it/notable features. Good job D: 06.33.53 # :D* 06.33.56 # buffering needs to go back to only an API, playback needs to handle the actual logic :/ 06.34.22 # how did you shrink the audio buffer? 06.35.38 # edit the makefile to have a smaller value for MEMORYSIZE 06.35.59 # the audio buffer for the SIM is just 3/4 that value IIRC 06.36.05 # I wonder if having 2 threads seemingly handle the playback/buffering makes anything simpler 06.36.34 # or just edit buffer.c 06.36.37 # thats probably easiest 06.36.54 # or did you mean for actual players? 06.37.10 # no, for the sim 06.37.25 # * JdGordon looks at his clip and sees it stopped again, 0,0,0,1,0 06.37.38 # hehe doh, end of playlist :p 06.38.26 # still waiting for a deadlock . . . 06.38.50 # i wonder if I could run multiple sims in parallel and just wait for one to dead lock 06.40.10 # just make sure the output goes to different files :p 06.41.32 Quit dirtydav ("Leaving") 06.42.55 # "audio_load_track(): a track load is already in progress" might be a hint 06.44.17 # yeah that does seem like a problem 06.45.03 # hmm that never gets printed in any of my logs where i don't get a crash 06.46.09 # although, quick look I cant see where that would be dangerous.. and presumwably it handles the broken playlist... 06.46.42 # it looks like it calls audio_fill_file_buffer twice in quick succession 06.47.32 # presumably on the first tick it tries to rebuffer, this somehow fails, and on the next tick it tries again and then eventually deadlocks 06.54.04 # i wonder if buffering_handle_finished_callback() has a problem 06.54.15 # thats where the audio_finish_load_track() is called from 06.54.54 # umm 06.56.17 # i just had it deadlock in set_filebuf_watermark 06.57.22 # * JdGordon doesnt understand how track_load_started could be set to false 06.57.54 # deadlock or infinite loop? 06.58.23 # well same deadlock we normally get, but it infinitely looped "fwmark: No id3 for last track (r%d/w%d), aborting!" 06.58.30 # instead of the other callback 06.59.02 # but otherwise it was the same with bufopen failing as usual 07.00.16 # same thing I think... filling is getting into a state its not expecting 07.00.24 # whats the output right before that? 07.00.26 # huh that loops whenever its not playing any audio 07.00.31 # yeah 07.00.39 # I tihnk that first if is wrong 07.00.50 # it was trying to switch tracks 07.00.58 # I've commented out that logf because I dont think its related 07.01.38 # the one in set_filebuf_watermark? 07.03.20 # yeah 07.07.34 # apparently buffering_low_buffer_callback() is totally useless!... I've commented its code out and I dont get the stall I expected 07.08.07 # there appears to be exactly no change in the sims buffering behaviour 07.09.18 # very unscientific... but odd 07.09.22 # looking at my logs, pretty much everyone had audio_finish_load_track fail, i think due to it being called when the buffer was already full 07.09.43 # i wonder if its just a matter of audio_finish_load_track not getting called again if the first one doesn't suceed 07.10.27 # thats not in the last log you sent me... 07.11.34 # yeah it is 07.11.47 # "buffer is full for now3" is what it prints when it gives up 07.11.54 # well i added the 3 so I could see where it gives up 07.12.05 Join PSPdemon [0] (n=PSPdemon@c-66-177-37-36.hsd1.fl.comcast.net) 07.12.13 # ah right 07.13.02 # although that function certainly looks like its ok for it to quit early 07.13.40 # close(fd) is the only thing I wonder about 07.14.04 # seems ok, wasteful, but ok 07.16.34 # the BUFFER_EVENT_BUFFER_LOW event is either broken or redundant 07.20.17 # "Clearing tracks 127/127" while playing the first track since starting the sim 07.21.24 # well i can readily crash it again but i'm not really sure what to look at 07.21.44 Part safetydan ("Leaving.") 07.21.55 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 07.22.18 # can you put it in a real crash so you can get a stack trace in gdb? 07.23.25 # sorry i mean deadlock 07.23.30 # i haven't managed to get it to crash 07.23.45 # and i don't really know how to use gdb 07.24.13 # I keep having the urge to print out the entire buffer/playback code and draw lines everywhere to follow what happens 07.24.50 # yeah 07.24.53 # well i'm going to sleep 07.24.58 # good night and good luck 07.25.12 # send off an email with your finding? 07.25.14 # +s? 07.25.24 Quit moos (Read error: 145 (Connection timed out)) 07.25.54 # i'm not really sure what we found out 07.26.06 # someone might have an idea 07.33.36 Join moos [0] (i=mostafa@rockbox/staff/moos) 07.40.52 Join ademille [0] (n=ademille@c-24-10-232-214.hsd1.ut.comcast.net) 07.41.06 # * JdGordon is suddenly curious aobut the order of logf's 07.41.18 Part ademille 07.41.30 # JdGordon: email sent, feel free to add your thoughts 07.42.36 # huh email got badly corrupted somehwo 07.42.45 # haha 07.45.01 # wow hotmail is fucked up tonight 07.47.15 # that time it worked 07.47.41 # no change here... 07.47.54 # ah, 3rd time lucky 07.55.00 Quit saratoga_ ("Page closed") 08.12.19 Part toffe82 08.24.25 *** Saving seen data "./dancer.seen" 08.28.23 Quit J-23 (Read error: 104 (Connection reset by peer)) 08.28.27 # JdGordon: VFAT is never case sensitive, just case preserving. That is part of its specs 08.28.33 Join J-23 [0] (n=zelazko@unix.net.pl) 08.31.14 # ok, that would explain why my covers work on target but not in the sim 08.31.16 # thanks 08.34.40 Quit pixelma (Remote closed the connection) 08.34.40 Quit amiconn (Remote closed the connection) 08.36.23 Join pixelma [0] (i=quassel@rockbox/staff/pixelma) 08.36.25 Join amiconn [0] (i=quassel@rockbox/developer/amiconn) 08.39.51 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.41.52 Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) 08.46.37 Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) 08.50.02 Quit xavieran__ (Read error: 104 (Connection reset by peer)) 08.53.47 Join petur [50] (n=petur@rockbox/developer/petur) 09.07.29 Nick chrism is now known as shaggy-h (n=kiwi@host-87-74-127-193.dslgb.com) 09.09.12 Join PaulJam [0] (n=Paule@p54BEC2C0.dip.t-dialin.net) 09.10.32 Join xavieran [0] (n=xavieran@ppp118-208-209-164.lns10.mel6.internode.on.net) 09.16.36 Quit FlynDice (Remote closed the connection) 09.25.15 Quit bertrik (Read error: 113 (No route to host)) 09.33.09 Join GodEater__ [0] (n=9372e2b4@rockbox/staff/GodEater) 09.33.38 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 09.34.51 Quit matsl (Read error: 60 (Operation timed out)) 09.35.26 Quit xavieran (Remote closed the connection) 09.40.32 Join xavieran [0] (n=xavieran@ppp118-208-209-164.lns10.mel6.internode.on.net) 09.53.33 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 09.58.58 Quit parafin (orwell.freenode.net irc.freenode.net) 09.58.58 NSplit orwell.freenode.net irc.freenode.net 09.58.58 Quit markun (orwell.freenode.net irc.freenode.net) 09.58.58 Quit bubsy (orwell.freenode.net irc.freenode.net) 09.58.58 Quit LinuxMafia (orwell.freenode.net irc.freenode.net) 09.58.58 Quit kadoban_ (orwell.freenode.net irc.freenode.net) 09.58.58 Quit cg_ (orwell.freenode.net irc.freenode.net) 09.58.58 Quit FOAD (orwell.freenode.net irc.freenode.net) 09.58.58 Quit scorche (orwell.freenode.net irc.freenode.net) 09.58.58 Quit jvd (orwell.freenode.net irc.freenode.net) 09.58.58 Quit tarbo (orwell.freenode.net irc.freenode.net) 09.58.58 Quit aevin (orwell.freenode.net irc.freenode.net) 09.58.58 Quit Utchybann (orwell.freenode.net irc.freenode.net) 09.58.58 Quit Erant (orwell.freenode.net irc.freenode.net) 09.58.58 Quit meermanr (orwell.freenode.net irc.freenode.net) 09.58.58 Quit Hadaka (orwell.freenode.net irc.freenode.net) 09.58.59 Join aexin [0] (i=eivindsy@decibel.pvv.ntnu.no) 09.58.59 Join Hadaka_ [0] (n=naked@naked.iki.fi) 09.59.01 NHeal orwell.freenode.net irc.freenode.net 09.59.01 NJoin meermanr [0] (n=meermanr@robmeerman.co.uk) 09.59.03 Join jvd_ [0] (n=syscrash@209.126.180.153) 09.59.03 Join markun_ [50] (n=markun@rockbox/developer/markun) 09.59.08 Nick Hadaka_ is now known as Hadaka (n=naked@naked.iki.fi) 09.59.10 Join Utchybann_ [0] (n=lolo@AStrasbourg-251-1-25-102.w82-126.abo.wanadoo.fr) 09.59.11 NJoin LinuxMafia [0] (n=awatt@CPE00222d132940-CM00222d13293c.cpe.net.cable.rogers.com) 09.59.56 NJoin scorche [50] (n=scorche@rockbox/administrator/scorche) 10.00.07 NJoin kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) 10.00.55 NJoin tarbo [0] (n=me@unaffiliated/tarbo) 10.03.53 NJoin cg_ [0] (n=cromos@cable-kmi-fe71de00-186.dhcp.inet.fi) 10.04.01 Join FOAD [0] (n=dok@82.93.10.238) 10.05.21 Quit feisar- (Read error: 104 (Connection reset by peer)) 10.07.27 Join feisar- [0] (i=jljhook@irkki.fi) 10.08.37 Join mt [0] (n=Miranda@rockbox/developer/mt) 10.08.48 Part mt ("I'm a happy Miranda IM user! Get it here: http://miranda-im.org") 10.09.03 Join mt [0] (n=Miranda@rockbox/developer/mt) 10.20.18 Nick markun_ is now known as markun (n=markun@rockbox/developer/markun) 10.24.27 *** Saving seen data "./dancer.seen" 10.39.38 Quit ChanServ (shutting down) 10.39.55 Join ChanServ [0] (ChanServ@services.) 10.39.55 Mode "#rockbox +o ChanServ " by irc.freenode.net 10.39.55 DBUG sent MODE #rockbox -o ChanServ 10.39.55 *** Server message 485: 'logbot ChanServ #rockbox :User is immune from kick/deop' 10.47.17 Quit PaulJam (Read error: 104 (Connection reset by peer)) 10.54.36 Join liar [0] (n=liar@83.175.83.185) 11.35.02 Join Rob2222 [0] (n=Miranda@p4FDCD9D9.dip.t-dialin.net) 11.36.49 Join DaveDavenport [0] (n=qball@unaffiliated/qball) 11.50.02 # http://images.sarine.nl/HDD6320/ <-- sorry for crappy foto's didn't have propper camera with me 12.13.20 # Should FS#10601 be closed ? 12.24.29 *** Saving seen data "./dancer.seen" 12.29.48 Quit GodEater__ ("CGI:IRC") 12.31.18 Quit TheSeven (Remote closed the connection) 12.31.47 # hmm shame though it is on the new ports list, the philips isn't in the configure menu 12.32.42 Join TheSeven [0] (n=theseven@dslb-084-056-146-074.pools.arcor-ip.net) 12.35.03 Quit TheSeven (Client Quit) 12.36.06 Join TheSeven [0] (n=theseven@dslb-084-056-146-074.pools.arcor-ip.net) 12.37.58 Join bughunter2 [0] (n=bughunte@unaffiliated/bughunter2) 12.58.37 Quit krazykit ("brb, grub2") 13.00.25 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 13.02.10 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 13.02.16 Join TopyMobile [0] (n=topy@80.0.179.133) 13.03.52 Quit TopyMobile (Client Quit) 13.04.01 Join TopyMobile [0] (n=topy@cpc1-ward9-2-0-cust132.10-2.cable.virginmedia.com) 13.05.15 Join AndyI [0] (n=pasha_in@212.14.205.32) 13.07.01 Quit AndyIL (Read error: 145 (Connection timed out)) 13.12.41 Join AsaelReiter [0] (n=d59730fa@gateway/web/cgi-irc/labb.contactor.se/x-ozvjlmzrbrrfvmtk) 13.25.19 Quit AsaelReiter ("CGI:IRC (EOF)") 13.36.17 Quit robin0800 (Remote closed the connection) 13.36.41 Join Korean [0] (n=3ae2219d@91.191.140.131) 13.36.59 # hi everyone 13.37.07 # hello? 13.37.31 # heeeeeeeeeeeeeeeeeeeeeeeeeelllllllllllllllllllllllllloooooooooooooo? 13.37.37 # .... 13.38.27 # Korean, do you have a question? 13.41.29 Quit mt (Read error: 113 (No route to host)) 13.43.00 Join parafin [0] (i=parafin@paraf.in) 13.45.48 Quit krazykit ("work") 13.49.52 Quit rvvs89 (Read error: 104 (Connection reset by peer)) 13.51.57 Quit Korean ("CGI:IRC (EOF)") 13.53.03 Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) 14.01.43 # DaveDavenport: did you add these pictures/information to the wiki? 14.07.20 # mcuelenaere: everything is allready there 14.07.21 # chip info 14.07.43 # ok 14.08.30 # hmmm I need to register to edit wiki? 14.08.56 # yes 14.10.05 # grrr I lost the patched I got a long time ago, compiling rockbox for my philips 14.10.27 Quit mcuelenaere (orwell.freenode.net irc.freenode.net) 14.10.27 NSplit orwell.freenode.net irc.freenode.net 14.10.27 Quit Utchybann_ (orwell.freenode.net irc.freenode.net) 14.10.27 Quit Beta2K (orwell.freenode.net irc.freenode.net) 14.10.27 Quit daurnimator (orwell.freenode.net irc.freenode.net) 14.10.27 Quit jordan` (orwell.freenode.net irc.freenode.net) 14.10.27 Quit crwl (orwell.freenode.net irc.freenode.net) 14.10.27 Quit Galois (orwell.freenode.net irc.freenode.net) 14.10.27 Quit Torne (orwell.freenode.net irc.freenode.net) 14.10.27 Quit DaveDavenport (orwell.freenode.net irc.freenode.net) 14.11.06 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 14.12.13 Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 14.12.13 NHeal orwell.freenode.net irc.freenode.net 14.12.13 NJoin DaveDavenport [0] (n=qball@unaffiliated/qball) 14.12.13 NJoin Utchybann_ [0] (n=lolo@AStrasbourg-251-1-25-102.w82-126.abo.wanadoo.fr) 14.12.13 NJoin Beta2K [0] (n=beta@d24-36-68-97.home1.cgocable.net) 14.12.13 NJoin daurnimator [0] (i=daurnima@freenode/staff/daurnimator) 14.12.13 NJoin jordan` [0] (i=gromit@78.235.252.137) 14.12.13 NJoin Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 14.12.13 NJoin Galois [0] (i=djao@efnet.math.uwaterloo.ca) 14.12.13 NJoin crwl [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 14.13.23 # aa lovely netsplits 14.15.44 Join GodEater__ [0] (n=9372e2b4@rockbox/staff/GodEater) 14.24.30 *** Saving seen data "./dancer.seen" 14.25.37 Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) 14.27.33 Nick jvd_ is now known as jvd (n=syscrash@209.126.180.153) 14.27.40 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 14.29.40 # New commit by 03mcuelenaere (r22699): Fix ccpmp.bin backup in ChinaChippatcher (thanks to Aaron DeMille) 14.30.29 Join teru [0] (n=teru@59.133.112.132) 14.32.12 Join krazykit [0] (n=kkit@65.96.199.177) 14.42.40 Quit DaveDavenport (Read error: 104 (Connection reset by peer)) 14.47.45 Join DaveDavenport [0] (n=qball@ipd50a4125.speed.planet.nl) 15.01.17 Quit crwl (orwell.freenode.net irc.freenode.net) 15.01.17 NSplit orwell.freenode.net irc.freenode.net 15.01.17 Quit Galois (orwell.freenode.net irc.freenode.net) 15.01.17 Quit Torne (orwell.freenode.net irc.freenode.net) 15.01.17 Quit Beta2K (orwell.freenode.net irc.freenode.net) 15.01.17 Quit mcuelenaere (orwell.freenode.net irc.freenode.net) 15.01.17 Quit Utchybann_ (orwell.freenode.net irc.freenode.net) 15.01.17 Quit daurnimator (orwell.freenode.net irc.freenode.net) 15.01.17 Quit jordan` (orwell.freenode.net irc.freenode.net) 15.02.28 NHeal orwell.freenode.net irc.freenode.net 15.02.28 NJoin mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) 15.02.28 NJoin Utchybann_ [0] (n=lolo@AStrasbourg-251-1-25-102.w82-126.abo.wanadoo.fr) 15.02.28 NJoin Beta2K [0] (n=beta@d24-36-68-97.home1.cgocable.net) 15.02.28 NJoin daurnimator [0] (i=daurnima@freenode/staff/daurnimator) 15.02.28 NJoin jordan` [0] (i=gromit@78.235.252.137) 15.02.28 NJoin Torne [0] (i=torne@lowell.wolfpuppy.org.uk) 15.02.28 NJoin Galois [0] (i=djao@efnet.math.uwaterloo.ca) 15.02.28 NJoin crwl [0] (n=crawlie@a91-156-100-168.elisa-laajakaista.fi) 15.09.12 Quit Beta2K (Remote closed the connection) 15.09.12 Quit mcuelenaere (Read error: 104 (Connection reset by peer)) 15.09.28 Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) 15.11.08 Join PaulJam [0] (n=Paule@p54BEFB64.dip.t-dialin.net) 15.11.51 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 15.14.23 Join Beta2K [0] (n=beta@d24-36-68-97.home1.cgocable.net) 15.15.30 Quit antil33t (Read error: 104 (Connection reset by peer)) 15.15.48 Join antil33t [0] (n=Mudkips@119.224.12.185) 15.39.08 Quit PaulJam (Nick collision from services.) 15.39.15 Join PaulJam_ [0] (n=Paule@p54BEFB64.dip.t-dialin.net) 15.41.46 Join vodi [0] (n=vodi@91-113-1-169.adsl.highway.telekom.at) 15.43.47 Join panni_ [0] (i=hannes@ip-95-222-19-21.unitymediagroup.de) 15.43.50 Part vodi 15.53.01 Quit robin0800 (Read error: 110 (Connection timed out)) 15.53.41 Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) 15.57.32 Quit tchan ("WeeChat 0.3.1-dev") 16.00.48 Quit TopyMobile (Remote closed the connection) 16.01.07 Join explore [0] (n=msparker@pool-173-57-115-183.dllstx.fios.verizon.net) 16.01.29 Join evilnick [0] (i=0c140464@gateway/web/freenode/x-tvmavpyhbvjdrmdw) 16.06.17 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 16.07.31 Join DerPapst [0] (n=DerPapst@91-64-221-175-dynip.superkabel.de) 16.09.19 Quit fyrestorm (Read error: 104 (Connection reset by peer)) 16.14.07 Join Blue_Dude [0] (n=chatzill@adsl-235-222-153.mco.bellsouth.net) 16.16.54 Join webguest35 [0] (n=bc3c610b@gateway/web/cgi-irc/labb.contactor.se/x-ysjfgqpmkbvsudsg) 16.20.17 Join TopyMobile [0] (n=topy@80.0.179.133) 16.21.41 Quit GodEater__ ("CGI:IRC") 16.21.53 Quit webguest35 ("CGI:IRC (Ping timeout)") 16.24.32 *** Saving seen data "./dancer.seen" 16.24.54 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 16.25.24 Join n1s [0] (n=n1s@rockbox/developer/n1s) 16.25.24 Quit robin0800 (Remote closed the connection) 16.32.37 # So we are in freeze then (going by the mailing list)? 16.33.38 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.33.45 Join jfc [0] (n=john@66.82.208.2) 16.34.32 # AlexP: it looks like 16.34.38 # Right 16.34.45 Topic "We are now in Feature Freeze for 3.4! | Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community" by ChanServ (ChanServ@services.) 16.34.58 # It is now official :) 16.35.16 # it's amazing that that nobody cared about it yet (I personally thought that we are in the freeze since sept 9th, sort of implicitly) 16.36.06 # I think it is mainly that people either forget (I did) or don't want to unilaterly make the decision that means we end up with lots of are we aren't we type stuff 16.36.10 # yay freeze 16.36.25 Join jboy [0] (n=langzeit@p57915A54.dip.t-dialin.net) 16.36.44 # I asked a couple of times in here but noone answered 16.37.05 # * kugel didn't notice 16.37.33 # unfortunately we have a few bugs left :p 16.38.33 # ...lol 16.38.54 # Should we freeze for a week from now, or just freeze a few days and branch to release on the 23rd? 16.38.58 Join barrywardell [0] (n=barry@barry-workstation.ucd.ie) 16.39.31 # I'll send off a mail with an appropriate subject to -dev, just to make sure everyone noticed 16.42.05 # i dont think it will make any difference 16.42.47 # fine, let's aim for 23rd then 16.43.08 # there are a few small skin bugs I'd like sorted out, but hopefully kugel can get to them :) my coding time is going to be short for the next while 16.43.14 # * JdGordon gone 16.44.12 # Oh gosh, this means I'm late on the translation update mail also 16.44.42 # I think it's fine to prolong the freeze and shorten the branch period, but we should aim for 23rd 16.46.24 # oh 16.46.50 # I guess we can move that around a bit 16.46.59 # * gevaerts can't really help with the release this time 16.48.25 Join toffe82 [0] (n=chatzill@12.169.218.14) 16.52.08 # rasher: yup, the branch period is boring anyway :) 16.52.36 # I'm not very convinced it's needed 16.53.17 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 16.54.24 Quit moos (Read error: 131 (Connection reset by peer)) 16.54.25 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 16.55.26 Join moos [0] (i=mostafa@rockbox/staff/moos) 16.56.28 Join JdGordon_ [0] (i=ae91e348@gateway/web/freenode/x-qhplhkspbskbaukf) 16.58.03 Quit teru ("Quit") 17.02.05 # JdGordon_: I put a very hack at FS#10599, any ideas how to do it cleanly? 17.03.36 Quit JdGordon_ (Ping timeout: 180 seconds) 17.05.23 # * kugel is depressed about our bus-factor for the buffering code :) 17.05.38 Nick ch4os_ is now known as ch4os (n=ch4os@gentoo/user/ch4os) 17.06.23 # bus-factor? 17.06.59 # http://en.wikipedia.org/wiki/Bus_factor 17.08.02 # ah. well we're pretty much there already, aren't we? no single person is standing up and "owns" the buffering code. 17.08.51 # I was tempted efter tweaking it for clip, but other things got in the way. maybe I should dig in again. 17.09.17 # JdGordon and saratoga did last night 17.09.50 # ah, excellent 17.10.34 Quit Zagor ("Don't panic") 17.14.08 Join Ubuntuxer [0] (n=johannes@dslb-188-101-010-180.pools.arcor-ip.net) 17.15.29 # kugel: if Bin Laden ever bombs Stockholm, we might have a problem ;) 17.16.34 # hehe 17.23.21 Join Omlet [0] (n=Omlet05@115.224-200-80.adsl-dyn.isp.belgacom.be) 17.31.38 Join MethoS- [0] (n=clemens@134.102.106.250) 17.37.29 Quit Ubuntuxer ("Leaving.") 17.37.53 # Blue_Dude: ping 17.38.09 # kugel:pong! 17.38.29 # Blue_Dude: have you seen FS#10572 ? 17.39.11 # kugel: Saw it, but I've never used timestretch. Have no idea how it works or how to fix interactions. Any ideas? 17.39.23 # no 17.39.45 # but I'm using the limiter, and occasionally timestrech, so I'd like to have that fixed 17.40.02 # I think both use some sort of look-ahead mechanism 17.42.25 # Blue_Dude: btw, FS#10484 is another bug caused by this vicious unclear track transition time (I remember you wanted to take a look at it?) 17.42.29 # I'm in the middle of changing the limiter to a full-blown DRC with programmable parameters. I'm also changing the way gain is applied. Right now gain is applied first, using the fact that there's at least two bits of headroom. That shouldn't, but could, lead to overflows. 17.43.39 # I'm also going through playback and pcmbuf line by line to break out voice mixing to a later stage. At the same time I hope to fix the track transition problem. 17.43.49 # It'll take time :) 17.44.14 # Version 3.6? 17.46.22 Join darkham [0] (n=darkham@host137-176-dynamic.52-79-r.retail.telecomitalia.it) 17.46.48 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 17.47.06 # full-blown is a word you really should avoid here :) 17.47.33 # How about "more fully featured than just a db setting"? 17.47.55 # just "not as limited" :p 17.48.10 # Gotcha. 17.52.42 Quit petur ("work->home") 17.54.54 Quit DaveDavenport (Remote closed the connection) 17.55.05 Join DaveDavenport [0] (n=qball@213.10.65.37) 17.55.34 Join JdGordon_ [0] (i=836b004d@gateway/web/freenode/x-vmftnddjxwvdpxkf) 17.55.44 Quit JdGordon_ (Client Quit) 17.56.56 Join JdGordon_ [0] (i=836b004d@gateway/web/freenode/x-pvkymkwlqclluuid) 18.00.23 Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 18.02.01 Join aidy [0] (n=aidy@mail.rty.ca) 18.02.05 # hiiiiii 18.02.39 Join mt [0] (n=Miranda@rockbox/developer/mt) 18.04.57 Quit explore ("leaving") 18.07.25 Join Utchybann__ [0] (n=lolo@AStrasbourg-251-1-85-254.w82-126.abo.wanadoo.fr) 18.09.09 Quit Utchybann_ (Read error: 110 (Connection timed out)) 18.13.10 Join Hillshum [0] (n=hillshum@75-165-233-121.slkc.qwest.net) 18.19.57 # * kugel successfully added a more target-like button reading for the sim 18.20.13 # with button_[init|read]_device() 18.21.01 Join bertrik [0] (n=5a911fc2@91.191.140.131) 18.23.44 Join bertrik_work [0] (n=5a911fc2@gateway/web/cgi-irc/labb.contactor.se/x-ttueqpxasrhdcida) 18.24.34 *** Saving seen data "./dancer.seen" 18.25.53 Quit bertrik (Client Quit) 18.29.24 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 18.31.21 Join Lynx_ [0] (i=574fb717@gateway/web/freenode/x-zawhxtifylhaeegn) 18.32.40 # * rasher fears his named-pipe control patch will get broken 18.32.49 # Well, more broken. 18.37.05 # rasher: wasn't one of JdGordon's ideas that your patch will be less broken if the sim would use a less special button handling? 18.37.17 # this is to fix FS#10451 btw 18.37.54 # I don't think it'll matter much. I pretty much bypass button reading 18.47.25 Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) 18.55.39 Join wincent [0] (n=wincent@host-091-097-059-130.ewe-ip-backbone.de) 18.56.59 # Blue_Dude (while you are in pcmbuf.c) or anyone: is there a technical reason why pcmbuf_beep(unsigned int frequency, size_t duration, int amplitude) is not in the plugin API ? 18.57.56 # Grahack: the plugin API only has functions that people actually needed in plugins, functions aren't added just because they can 18.58.05 # Grahack: we normally only put things we need into the plugin api, so perhaps nobody needed this function until now ? 18.58.36 # there could be another reason of course 18.59.03 Quit ender` (Read error: 54 (Connection reset by peer)) 18.59.23 Join webguest49 [0] (n=bc3c610b@gateway/web/cgi-irc/labb.contactor.se/x-joftogjlnwsndqpz) 19.00.08 Quit bertrik_work ("CGI:IRC") 19.00.53 # ok thanks, so it should not be impossible (except the "another reason") :) 19.01.19 Quit robin0800 (Remote closed the connection) 19.03.34 Quit MethoS- (Remote closed the connection) 19.04.52 Quit webguest49 ("CGI:IRC (Ping timeout)") 19.04.57 Join ender` [0] (i=krneki@foo.eternallybored.org) 19.05.46 Join shriven [0] (n=shriven@rdu.crosscomm.net) 19.12.07 # Hello. Just a preface... My ipod may be bricked, but I'm not sure. iTunes cannot successfully restore it. Now... I have the ipod (60gb, 5g) formatted and am able to use ipodpatcher to load the firmware, and copied .rockbox into place. But when I restart the ipod it always comes up saying that my ipod is broken and to use iTunes to restore it. Anyone have any ideas? 19.14.37 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.18.31 Quit ender` (Read error: 104 (Connection reset by peer)) 19.18.48 Join ender` [0] (i=krneki@foo.eternallybored.org) 19.19.04 Join ageless [0] (n=jason@70.99.150.214) 19.19.24 Quit wincent (Read error: 60 (Operation timed out)) 19.29.46 Join bluebrother [0] (n=dom@f053153246.adsl.alicedsl.de) 19.33.54 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 19.36.48 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 19.41.27 Quit Hillshum (Read error: 110 (Connection timed out)) 19.42.53 # shriven: if itunes cant restore it, you could try the manual way (see IpodManualRestore in the wiki) 19.43.10 # ahh, thanks.. Tried that a few times now. 19.43.36 # same result. : ( 19.52.02 # shriven: then it looks like your out of luck.. maybe some hardware is broken. 19.52.54 # yea... I'm wondering if whatever the firmware is stored on is broken.... iTunes always report the ipod as having a version 1.1.2, even after I completely format and supposedly load a new firmware 19.56.10 # the normal firmware is on the harddisk, and rewritten with a manual restore (if you dont mess up :-) ). But the emergency usb-mode may be in some flash chip. 19.56.53 # hmmm yea, I just don't know what else would cause it to always think it has a version of 1.1.2.... I probably did screw it up somehow, just not sure how. 19.58.40 # iirc it happened when I was trying to upgrade to apple's 1.1.2, but I don't think it ever worked. I had had rockbox on it before that without any problems, then decided to switch back to apple's firmware 20.00.02 # Ok, thanks for the thoughts. 20.00.17 Quit shriven () 20.03.25 Quit Lynx_ ("Page closed") 20.05.23 Join Zagor [0] (n=bjst@87.227.35.46) 20.10.28 Quit barrywardell (Remote closed the connection) 20.16.47 Quit TopyMobile (Remote closed the connection) 20.19.20 Nick ch4os is now known as szymon (n=ch4os@gentoo/user/ch4os) 20.24.38 *** Saving seen data "./dancer.seen" 20.35.23 Join wincent [0] (n=wincent@host-091-097-059-130.ewe-ip-backbone.de) 20.38.37 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 20.44.58 Quit kugel ("exit(0);") 20.45.37 Join Stephenccc [0] (n=Stephenc@86-45-85-104-dynamic.b-ras2.srl.dublin.eircom.net) 20.46.00 Quit JdGordon_ (Ping timeout: 180 seconds) 20.51.04 Join explore [0] (n=msparker@173.57.115.183) 20.52.41 Quit pixelma (Nick collision from services.) 20.52.43 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 20.52.51 Quit amiconn (Nick collision from services.) 20.52.55 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 20.53.02 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 20.53.03 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 20.54.16 Join captainkewl [0] (i=2669ecc2@gateway/web/freenode/x-sconooyqbdgnfwhv) 20.57.57 Join Hillshum [0] (n=hillshum@75-165-233-121.slkc.qwest.net) 20.58.20 Quit FOAD (Remote closed the connection) 21.04.59 Join FOAD [0] (n=dok@dinah.blub.net) 21.07.48 Quit moos ("Allez De La Poutre, vamos ! :)") 21.09.21 Quit PaulJam_ (".") 21.11.11 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.11.22 Quit kugel (Remote closed the connection) 21.12.23 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.14.38 Join archivator [0] (i=Delyan@vlan-132-18-160.comnet.bg) 21.16.38 Quit kugel (Client Quit) 21.16.48 Join kugel [0] (n=kugel@rockbox/developer/kugel) 21.22.47 Join toffe82_ [0] (n=chatzill@12.169.218.14) 21.24.38 Quit toffe82 (Read error: 110 (Connection timed out)) 21.24.45 Nick toffe82_ is now known as toffe82 (n=chatzill@12.169.218.14) 21.28.07 # guys I'm getting ready with a proper touchscreen wps, yw 21.28.22 Quit jvd (Remote closed the connection) 21.30.47 # aidy: Nice :) 21.31.49 # except that inkscape just crashed 21.31.51 Quit bluebrother (Nick collision from services.) 21.31.52 Join brn2dth [0] (n=brn2dth@63.245.17.11) 21.31.55 Join bluebroth3r [0] (n=dom@rockbox/developer/bluebrother) 21.32.02 # and it's not starting up anymore 21.32.49 Part brn2dth 21.32.52 Quit Stephenccc ("http://irc2go.com/") 21.37.48 # holy p :( 21.39.21 # why on earth doesn't that thing have autosave 21.39.26 Join JdGordon_ [0] (i=836b004d@gateway/web/freenode/x-gihwvggqnnffgsmz) 21.43.10 Quit bughunter2 ("Leaving.") 21.43.28 Join froggyman [0] (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 21.45.00 Join petur [50] (n=petur@rockbox/developer/petur) 21.48.27 Join jvd [0] (n=syscrash@209.126.180.153) 21.54.59 Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) 21.55.33 Quit LambdaCalculus37 () 21.55.39 Part Grahack 21.57.41 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 21.57.59 Part Grahack 22.08.15 Quit krazykit ("Connection reset by beer") 22.08.48 Join salty-horse [0] (n=ori@bzq-79-181-121-32.red.bezeqint.net) 22.09.27 # I fiddled with the sansa's volume controls while charging it, and it controlled the computer's volume. nice :) 22.09.49 Join Anon419 [0] (n=Anonymou@86-45-85-104-dynamic.b-ras2.srl.dublin.eircom.net) 22.10.47 Nick Anon419 is now known as Stevie_ie (n=Anonymou@86-45-85-104-dynamic.b-ras2.srl.dublin.eircom.net) 22.10.48 # salty-horse: it can also control playback if your music player supports that 22.12.34 # A looooong time ago someone pointed me to a fp fft implementation that used to be in one of the codecs. Anyone have any idea what codec or at least which revision I should start searching from? 22.16.58 Quit JdGordon_ (Ping timeout: 180 seconds) 22.17.58 # fp = fixed point ? 22.18.07 # or floating point ? :-) 22.18.15 # fixed point :) 22.21.11 # * domonoky sees some fft code in libspeex, i think most codecs use a dct instead of a fft. 22.23.13 # libspeex uses kiss_fft which I find to be somewhat bloated 22.23.50 # I'm pretty sure nothing else uses fft right now 22.24.18 Join AsaelReiter [0] (n=d59730fa@gateway/web/cgi-irc/labb.contactor.se/x-twzqxthsyrecgoby) 22.24.41 *** Saving seen data "./dancer.seen" 22.24.51 # But I'm also 100% sure something used FFT in the past and got refactored to use different routines. The library it used, however, was very compact and, more importantly, the transformation was in-place. 22.26.49 Quit stripwax ("http://miranda-im.org") 22.27.51 # Hi 22.28.12 # svn logs shows libatrac had a fft.c file, maybe it was this codec ? 22.30.48 Join krazykit [0] (n=kkit@c-24-218-166-241.hsd1.ma.comcast.net) 22.31.08 # archivator: also libfaad had a cfft.c file .. 22.31.27 # domonoky: perhaps but that would also mean my memory is horrible - this fft.c was directly imported from ffmpeg and the code is far from readable .. :( 22.31.57 # I think that the patch in FS#10589 is well. Can somebody check and commit it? 22.32.33 # archivator: wma had a fft too.. you just have to search the svn logs :-) 22.33.21 # Yeah, I should probably switch over to a svn repo (I'm using git-svn right now but my gitfu is not up to the task) 22.33.29 # Thanks for your time! 22.35.33 Quit toffe82 (Read error: 60 (Operation timed out)) 22.35.56 # * domonoky didnt need any svnfu for this task with tortoisesvn, just a few mouseclicks :-) 22.36.40 Quit salty-horse (Read error: 104 (Connection reset by peer)) 22.37.23 Join salty-horse [0] (n=ori@bzq-79-181-121-32.red.bezeqint.net) 22.38.21 # AsaelReiter: a few comments to this patch: the for loops could need some { }, and why dont those loop use the food/argh_collion function ? 22.39.40 Quit n1s (Read error: 104 (Connection reset by peer)) 22.40.24 # there is only one line inside of the loop, so the {} are not needed. 22.40.42 Join toffe82 [0] (n=chatzill@12.169.218.14) 22.41.09 # and the food/argh_collision function check between a food/argh and one point. 22.42.03 # the loop I wrote is very similar to these functions, but it checks between 2 food/arghs. 22.43.14 # AsaelReiter: sure, the { } isnt needed, but it would be nicer, especially with those wrapped lines. 22.44.08 Quit merbanan (Read error: 110 (Connection timed out)) 22.44.24 # the need for this loop is because food/arghs can be bigger then 1 square/pixel ? 22.44.33 # yes 22.46.11 # when I maximized the foods and minimized the arghs (to make it easy:) ), a lot of foods covered arghs. 22.47.18 Quit Utchybann__ ("I like core dumps") 22.47.23 Join Utchybann__ [0] (n=lolo@AStrasbourg-251-1-85-254.w82-126.abo.wanadoo.fr) 22.47.48 # hm, from the code i wonder if it works if you touch a food/argh with the worm not at the center, when food/argh_collision() only checks one pixel 22.49.55 # maybe I didn't understand your English, but I didn't change any code about the worms. 22.50.23 # yes, you didnt but i wonder if this works. 22.52.19 # i would think it would make more sense to check against the full size of a food/argh in those collision functions, and still use the corner check when creating new food/argh 22.52.47 Part salty-horse ("Leaving") 22.53.21 Join Erant [0] (i=erant@plz.stfu.kthnx.org) 22.53.37 # AsaelReiter: if you have a 3x3 food, and steer the worm through the side of it (so you dont touch the center pixel) does it work ? 22.53.38 Join omerozero [0] (n=97331a9e@gateway/web/cgi-irc/labb.contactor.se/x-lwvaqdleasqohpcy) 22.55.21 Quit AsaelReiter ("CGI:IRC (Ping timeout)") 22.58.10 Nick froggyman is now known as frogyman (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 22.58.18 Part frogyman 22.59.44 Join TopyMobile [0] (n=topy@cpc1-ward9-2-0-cust132.10-2.cable.virginmedia.com) 23.06.35 Quit omerozero ("CGI:IRC (EOF)") 23.11.42 Part bertrik ("Ik ben weg") 23.15.35 Join frogyman [0] (n=48454bb4@91.191.140.131) 23.18.37 # domonoky: I think it was the libwma one :) If only I could figure out how to use it :) 23.18.52 # :-) 23.19.14 Quit frogyman (Client Quit) 23.19.54 Quit evilnick ("Page closed") 23.26.39 Join frogyman [0] (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 23.27.51 Nick frogyman is now known as froggyman (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 23.28.45 Quit Horscht ("Verlassend") 23.30.30 Quit bluebroth3r ("leaving") 23.31.51 Quit froggyman ("ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458]") 23.32.08 Join froggyman [0] (n=chatzill@pool-72-69-75-180.chi01.dsl-w.verizon.net) 23.36.21 Join stripwax [0] (n=Miranda@87.194.34.169) 23.37.52 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 23.38.25 Join safetydan [0] (n=deverton@rockbox/developer/safetydan) 23.40.37 Quit petur ("Zzzzz") 23.42.09 Join jboy_ [0] (n=langzeit@p57915D03.dip.t-dialin.net) 23.47.35 Nick aexin is now known as aevin (i=eivindsy@unaffiliated/aevin) 23.48.12 # mockup for D2 theme http://omploader.org/vMmN0cg (bmp http://omploader.org/vMmN0cQ ) 23.52.42 Quit matsl (Read error: 110 (Connection timed out)) 23.53.13 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 23.55.31 Quit bertrik ("De groeten") 23.58.43 Quit jboy (Read error: 110 (Connection timed out))