#rockbox 2009-09-14

Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2009-09-14

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	Szeraax	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:00
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	saratoga_	anyone familar with the sim?
01:12:14	saratoga_	i'd like to adjust its memory
01:20:34	saratoga_	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	saratoga_	hmm nevermind, it seems to be working now
01:46:29	CIA-43	New commit by mt (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	mt	Could anyone close that task ? (I seem to have not got dev rights on FS yet.)
01:49:33	saratoga_	mt: done
01:50:11	saratoga_	if you email Zagor he can setup developer permissions on FS
01:50:21	mt	Thanks !
01:50:43	mt	I asked him one in a PM, but maybe he forgot.
01:50:51	mt	I'll e-mail him.
01:51:19	mt	FS #10182 (Addition of librm to svn) could be closed too.
01:52:57	saratoga_	pk done
01:52:57	saratoga_	ok
01:54:06	mt	Thanks :)
01:54:17	saratoga_	i dropped the filebuffer on the sim to 200KB but surprisingly it hasn't dead locked yet
01:54:53	saratoga_	its rebuffering 2-3 times a second
01:55:54	saratoga_	huh it just printed "failed to add handle" but didn't deadlock
01:56:25		Quit mcuelenaere ()
01:57:50	saratoga_	do logf's print in the sim?
01:59:23	mt	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:00
02:03:54	saratoga_	the clip is a nice target to test on, compiles so fast
02:06:37	mt	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	saratoga_	linuxstb: TheSeven has been looking for you
02:10:45	mt	hmm .. not too bad. ~6 minutes (clip sim build)
02:11:14	saratoga_	ouch
02:11:22	mt	:'(
02:14:07	saratoga_	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:00
03:10:40		Quit bubsy ("I'll be back somewhere in time")
03:13:29	kugel	saratoga_: what files did you try?
03:14:14	saratoga_	kugel: just been looping MP3s
03:14:32	saratoga_	been an hour or two without an glitches with a 100KB file buffer
03:15:05	saratoga_	sorry by looping I mean playing albums on repeat, not the same track
03:16:07	saratoga_	i don't know enough about how the sim differs for buffering though
03:16:35	saratoga_	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	saratoga_	i tried the same trick on the e200v1 and it deadlocks very quickly with a 200KB buffer
03:47:36	saratoga_	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	saratoga_	so its definately not an AMS specific problem, but it does not happen on the sim
03:51:55	saratoga_	boosting seems to be completely screwed up with a small buffer, though that may be unrelated
03:52:21	saratoga_	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:00
04:01:36	saratoga_	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	saratoga_	wow sim finally did deadlock, just takes a really, really long time
04:15:35	saratoga_	and I had logging enabled
04:16:31	JdGordon	great
04:16:41	JdGordon	tracking down the low mem problem?
04:18:30	saratoga_	assuming the one on the sim is the same, then yes
04:19:22	saratoga_	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	JdGordon	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	saratoga_	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	JdGordon	fix both!
04:21:53	saratoga_	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	JdGordon	that should be doable with some tricks...
04:22:52	JdGordon	but wouldnt that possibly invalidate the tests?
04:23:27	saratoga_	i assume the buffering system is deterministic
04:23:35	saratoga_	as long as I don't touch anything
04:23:38	JdGordon	maybe change the tick rate to much faster?
04:23:49	JdGordon	kernel-sdl.c would be my guess
04:24:14	saratoga_	another odd thing is that the buffer handle number continously increments, although only very slowly
04:24:17	saratoga_	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	saratoga_	in my case it failed at 40, although the max is defined to be 256
04:24:37	JdGordon	nico_P is the one you want to answer these...
04:24:47	saratoga_	yes i should email him
04:24:54	JdGordon	put what you find in an email for the dev-ml...
04:25:08	saratoga_	i wonder why the sim is so much more stable then devices
04:25:29	saratoga_	crashes that take seconds on the device take hours on the sim
04:25:30	JdGordon	it might still be a timing issue
04:25:41	JdGordon	I havnt got a consistant repro on my clip
04:26:19	saratoga_	the way you hit buttons while starting playback could change the outcome
04:26:39	JdGordon	really?!
04:26:52	saratoga_	i'm guessing but it seems reasonable
04:26:59	saratoga_	buffering is all tied into playback
04:27:18	saratoga_	and the order in which buffering happens depends on the state of all sorts of variables in playback
04:28:12	JdGordon	I thought the order was constant?
04:29:02	saratoga_	the order is constant but it often tries to buffer many times before succeeding with such small buffer sizes
04:29:11	saratoga_	though i could be misunderstanding the output
04:29:20	saratoga_	interested in a pastebin?
04:29:29	JdGordon	are you use its failing in buffering?
04:29:30	JdGordon	sure
04:29:49	saratoga_	no I'm not
04:31:48	saratoga_	http://pastebin.ca/1564899
04:31:56	saratoga_	last 20 minutes or so of output
04:32:26	JdGordon	you dont have a clip do you?
04:32:33	saratoga_	line 3199 is the first abnormal line i can see
04:32:37	saratoga_	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	JdGordon	ok cool
04:33:00	JdGordon	I tihnk the best way is logf to disk on target
04:33:24	JdGordon	always enabled for low mem untill we figure this out
04:33:46	saratoga_	line 3199 happens because either the second or third case in add_handle fails
04:34:44	JdGordon	can you paste is anywhere else?
04:34:45	saratoga_	sorry 2nd or third chance for add_handle to return a failure
04:35:00	saratoga_	pastebin.ca is a problem?
04:35:05	saratoga_	i could just email you the whole log
04:35:21	JdGordon	ah no, finally loaded
04:35:57	JdGordon	my guess is the handle number incrementing isnt a bug
04:36:07	JdGordon	based on KISS
04:36:51	saratoga_	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	JdGordon	I wonder if something dies if not enough audio data gets buffered and something gets confused there?
04:41:13	JdGordon	stupid question... are you useing the same folder for sim+clip?
04:41:51	JdGordon	maybe that doesnt make a difference...
04:42:18	saratoga_	no i'm using a different folder
04:42:30	saratoga_	you mean build folder right?
04:43:28	JdGordon	music folder
04:43:49	JdGordon	it should be consistant for a playlist... shouldnt it?
04:45:37	saratoga_	I think so
04:46:17	saratoga_	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	saratoga_	and using the sansa in between as long as i did't force an early rebuffering would not prevent the crash
04:46:49	saratoga_	although it would take almost 20 minutes to happen
04:47:41	JdGordon	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	JdGordon	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	saratoga_	i'm not sure, i don't have the slightest clue what all this code is actually doing
04:49:48	saratoga_	other then that it looks like a linked list of blocks in a ring buffer
04:50:11	saratoga_	is there some way to programatically start playback (perhaps using auto.rock?)
04:50:23	JdGordon	sure
04:50:43	JdGordon	"resume playback" start screen... or whip up a plugin to do it
04:51:01	JdGordon	or even simply add the code needed to main()
04:51:24	saratoga_	where does it store the resume information?
04:51:47	JdGordon	.playlist_control
04:52:00	JdGordon	so make a copy of that and it should be ok...
04:52:08	JdGordon	also nvram.bin maybe
04:52:29	saratoga_	what does that file do?
04:53:18	JdGordon	the combination is the resume info....
04:53:29	JdGordon	tucker time... back in a bit
04:53:36	saratoga_	i mean whats in it? its just binary data
04:53:38	saratoga_	ok
04:55:30	saratoga_	hopefully nico will have some idea whats going
04:59:34		Quit PSPdemon (Read error: 110 (Connection timed out))
05:00
05:02:22	kugel	saratoga_: maybe bryanjacobs has a clue too, not sure if he comes back though
05:03:53	saratoga_	ok found a combination that crashes the sim pretty quickly
05:04:09	saratoga_	lets see if the nvram.bin and playlist file are enough to reproduce it
05:07:16	kugel	saratoga_: wanna transfer it onto the clip?
05:07:34	kugel	or just the files for other to repro?
05:11:13	saratoga_	kugel: I'm still trying to figure out how useful it is
05:11:30	saratoga_	i did it twice now and the output is similar, but not the same
05:11:40	saratoga_	and it crashes at the end of the first track which is different then what i saw before
05:12:10	kugel	not entirely deterministic?
05:12:11	saratoga_	its interesting after about 5-10 buffering cycles the output of the two runs starts to diverge slightly
05:12:28	saratoga_	some buffer positions remain the same while others change
05:13:12	kugel	that could be cause and symptom actually
05:13:39	kugel	is the output the same for stuff that doesn't crash?
05:14:17	saratoga_	i think it'll always crash if you wait long enough with a small buffer
05:16:37	saratoga_	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	saratoga_	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	kugel	saratoga_: h is checked though, does the caller check the return?
05:24:17	saratoga_	yeah it does
05:24:51	saratoga_	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	kugel	what what I remember the lock happens when the buffer is empty, doesnt it?
05:25:57	saratoga_	it empties during the lock, i'm not sure what its state is when it does lock up
05:26:08	saratoga_	but probably empty since i don't think the buffering code would be running otherwise
05:27:29	saratoga_	oh wow ran it a third time and didn't get a deadlock
05:29:11	kugel	saratoga_: it always seemed to me as the lock would happen when rebuffering starts
05:29:41	kugel	it which case I wouldn't even expect the problem in bufopen
05:30:14	saratoga_	maybe it fails sooner and this is just the first thing I happened to catch
05:32:05	saratoga_	ugh why is playback endlessly trying to load metadata
05:32:27	saratoga_	it calls get_metadata at least once a second as far as I can tell
05:32:33	saratoga_	is that normal?
05:35:48		Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey)
05:35:50	saratoga_	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	saratoga_	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	JdGordon	the next track metadata should be loaded into a sepearte buffer
05:43:56	JdGordon	but yes, it does make sense that it keeps trying to buffer it
05:44:05	JdGordon	its the first bit of the next track that gets buffered
05:44:29		Quit Horscht ("Verlassend")
05:44:50	saratoga_	i don't see where it refills the current track?
05:45:09	saratoga_	as far as I can tell audio_load_track just keeps trying to load the next track
05:46:20	JdGordon	how big is the id3entry struct?
05:47:14	saratoga_	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	JdGordon	metadata.h
05:47:59	Johnny_ndr	why the wave files aren't included in the database ?
05:48:09	kugel	bufopen returns buffer full for id3 loading too
05:48:10	JdGordon	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	saratoga_	wav files don't have tags and so cannot be in the database
05:48:14	JdGordon	for it*
05:48:29	Johnny_ndr	Wave files can have tags
05:48:43	Johnny_ndr	I tagged all my wave files collections
05:48:55	saratoga_	you can put whatever tags you want on them but it doesn't mean anything can read them :)
05:49:08	Johnny_ndr	which means ?
05:49:29	saratoga_	JdGordon: do you mean mp3entry?
05:49:36	JdGordon	ah, yes
05:50:22	saratoga_	looks like its at least a few KB
05:50:34	saratoga_	what are you thinking?
05:50:49	JdGordon	re why its trying to load it so often
05:51:07	JdGordon	side point... its not actually crashing because the id3buf isnt big enough is it?
05:51:27	Johnny_ndr	well, I'll wait for next revisions on wave then
05:51:33	JdGordon	there is a MEMORYSIZE > 2 #if there
05:51:57	saratoga_	where is this?
05:52:03	JdGordon	metadata.h
05:52:06	JdGordon	in apps
05:52:14		Part Johnny_ndr
05:52:27	JdGordon	hmm... proibably not, it would be a different type of failure i tihnk
05:52:54	kugel	JdGordon: i don't think so, it was 300 for all targets not too long ago
05:53:02	JdGordon	if it was that it would be consistant for a track
05:53:03	kugel	lear increased it for long comments
05:53:58	kugel	saratoga_: so the buffering or playback is caught in a loop?
05:54:19	saratoga_	i'm not sure
05:54:58	saratoga_	i wasn't able to trace the call chain very far before my trick stopped being able to crash the sim
05:55:05	saratoga_	debugging on target might be a better idea
05:55:14	saratoga_	since that seems more consistently able to crash things
05:57:30		Quit tchan ("WeeChat 0.3.1-dev")
05:57:31	JdGordon	just stopped for metrack count:0, handle count:1, 3.8MB file rem
05:57:59	JdGordon	171/393K alloc usage
05:58:12	saratoga_	yeah thats what happens for me
05:58:27	JdGordon	damn, the audio buffer is tiny!
05:58:29	saratoga_	it runs down the buffer without being able to rebuffer it, since all attempts to allocate new buffers fail
05:58:41	kugel	saratoga_: it might be interesting to debug the filling variable
05:58:58	JdGordon	it doesnt make sense that it tried to add new ones... the current file isnt finishe
05:58:59	JdGordon	d
05:59:10	kugel	that should tell us whether it's buffering or finished or whatever when it locks
05:59:14	saratoga_	it tries to add the next track on every rebuffer
05:59:17	saratoga_	i don't know why
06:00
06:00:27	JdGordon	pastebin hates your huge paste :)
06:01:13	kugel	has anyone managed to get the lock with non-mp3?
06:01:28	saratoga_	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	kugel	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	Johnny_ndr	oh yeah, why everytime I wanna play an audio file, it asks for "erase dynamic list ?"
06:04:23	saratoga_	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	Johnny_ndr	and how do I fix this ?
06:05:28	JdGordon	turn off "ask to delete dunamic playlists"
06:05:30	Johnny_ndr	I just reflashing with the latest build
06:05:31	JdGordon	rtfm :)
06:05:35	Johnny_ndr	where ?
06:07:30	*	JdGordon wonders why the pcm buffer is so large compared to compressed
06:08:35	JdGordon	is there a memory leak on the "alloc" value? whatever that is?
06:09:03	Johnny_ndr	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	saratoga_	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	Johnny_ndr	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	saratoga_	when it deadlocks its endlessly calling buffering_low_buffer_callback
06:12:21	saratoga_	so its in playback.c at least
06:12:30	Johnny_ndr	Ok, waiting for next revision then, thanks
06:12:30	dirtydav	hello, anyone here know if its safe to delete ALL of the files on an ipod?
06:12:48	saratoga_	yes it is
06:12:58		Part Johnny_ndr
06:13:07	saratoga_	JdGordon: you want a log of it deadlocking with both playback.c and buffering.c logging?
06:13:28	JdGordon	meybe... thats a codec callback isnt it?
06:14:09	JdGordon	nope, buffering
06:14:13	dirtydav	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	JdGordon	not if you want to use it as a music player
06:14:35	saratoga_	your ipod won't be able to play music if you put some oddball file system on it
06:14:47	JdGordon	saratoga_: yeah, can you email me the log?
06:16:04	JdGordon	I think i can see a potential loop there, but your previous log doesnt show it
06:16:48	saratoga_	sent
06:16:58	dirtydav	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	saratoga_	this is a crash on track change and not the rarer crash mid track
06:17:08	saratoga_	fat32
06:17:29	dirtydav	ahh, fat32 only huh
06:18:26	JdGordon	fat12/16 also no?
06:20:09	saratoga_	yeah but maybe not without recompiling i don't remember
06:20:32	JdGordon	there is an obvious loop there :)
06:20:53	JdGordon	although I'd expect more messages between the "low buffer callback" lines
06:21:16	saratoga_	maybe thats a clue!
06:21:24	JdGordon	saratoga_: get playback.c:1489 to show the filling value
06:22:17	JdGordon	there are 3 places that callback can be called... one is in #if 0 so ignoreable
06:22:25	JdGordon	1365 and 1426 in bufferng.c
06:22:44	JdGordon	the first I dont think is the problem or there would be more debug (i tinhk)
06:22:46	saratoga_	logf("low buffer callback: %d", filling); ?
06:22:53	JdGordon	something like that
06:23:09	JdGordon	it does nothing if its not filling which makes no sense
06:23:11	JdGordon	i tihnk :p
06:23:42	saratoga_	1426 is in an IF 0 block?
06:23:59	JdGordon	sorry, i meant 1416 is the important one
06:24:23	***	Saving seen data "./dancer.seen"
06:25:27	saratoga_	well its running i'll just wait for it to crash
06:25:39	JdGordon	does this look completly wierd to you also... "if (filling == STATE_FULL \|\| filling == STATE_END_OF_PLAYLIST)"?
06:26:43	JdGordon	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	saratoga_	full means you can't add more tracks, end of playlist means theres no more tracks to add
06:31:05	saratoga_	so maybe its a valid condition
06:31:43	saratoga_	i'm tempted to see what happens if I change teh HZ/2 in queue_wait_w_tmo in audio_thread
06:31:54	saratoga_	maybe HZ/10 would deadlock sooner
06:32:16	JdGordon	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	saratoga_	yeah that does seem odd
06:33:12	saratoga_	i wonder why that callback would be called if theres really no more files left to buffer
06:33:28	JdGordon	buffering doesnt know there is nothing left to buffer
06:33:49	billenium	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	billenium	:D*
06:33:56	JdGordon	buffering needs to go back to only an API, playback needs to handle the actual logic :/
06:34:22	JdGordon	how did you shrink the audio buffer?
06:35:38	saratoga_	edit the makefile to have a smaller value for MEMORYSIZE
06:35:59	saratoga_	the audio buffer for the SIM is just 3/4 that value IIRC
06:36:05	JdGordon	I wonder if having 2 threads seemingly handle the playback/buffering makes anything simpler
06:36:34	saratoga_	or just edit buffer.c
06:36:37	saratoga_	thats probably easiest
06:36:54	saratoga_	or did you mean for actual players?
06:37:10	JdGordon	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	JdGordon	hehe doh, end of playlist :p
06:38:26	saratoga_	still waiting for a deadlock . . .
06:38:50	saratoga_	i wonder if I could run multiple sims in parallel and just wait for one to dead lock
06:40:10	JdGordon	just make sure the output goes to different files :p
06:41:32		Quit dirtydav ("Leaving")
06:42:55	JdGordon	"audio_load_track(): a track load is already in progress" might be a hint
06:44:17	saratoga_	yeah that does seem like a problem
06:45:03	saratoga_	hmm that never gets printed in any of my logs where i don't get a crash
06:46:09	JdGordon	although, quick look I cant see where that would be dangerous.. and presumwably it handles the broken playlist...
06:46:42	saratoga_	it looks like it calls audio_fill_file_buffer twice in quick succession
06:47:32	saratoga_	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	JdGordon	i wonder if buffering_handle_finished_callback() has a problem
06:54:15	JdGordon	thats where the audio_finish_load_track() is called from
06:54:54	JdGordon	umm
06:56:17	saratoga_	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	JdGordon	deadlock or infinite loop?
06:58:23	saratoga_	well same deadlock we normally get, but it infinitely looped "fwmark: No id3 for last track (r%d/w%d), aborting!"
06:58:30	saratoga_	instead of the other callback
06:59:02	saratoga_	but otherwise it was the same with bufopen failing as usual
07:00
07:00:16	JdGordon	same thing I think... filling is getting into a state its not expecting
07:00:24	JdGordon	whats the output right before that?
07:00:26	saratoga_	huh that loops whenever its not playing any audio
07:00:31	JdGordon	yeah
07:00:39	JdGordon	I tihnk that first if is wrong
07:00:50	saratoga_	it was trying to switch tracks
07:00:58	JdGordon	I've commented out that logf because I dont think its related
07:01:38	saratoga_	the one in set_filebuf_watermark?
07:03:20	JdGordon	yeah
07:07:34	JdGordon	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	JdGordon	there appears to be exactly no change in the sims buffering behaviour
07:09:18	JdGordon	very unscientific... but odd
07:09:22	saratoga_	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	saratoga_	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	JdGordon	thats not in the last log you sent me...
07:11:34	saratoga_	yeah it is
07:11:47	saratoga_	"buffer is full for now3" is what it prints when it gives up
07:11:54	saratoga_	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	JdGordon	ah right
07:13:02	saratoga_	although that function certainly looks like its ok for it to quit early
07:13:40	JdGordon	close(fd) is the only thing I wonder about
07:14:04	JdGordon	seems ok, wasteful, but ok
07:16:34	JdGordon	the BUFFER_EVENT_BUFFER_LOW event is either broken or redundant
07:20:17	saratoga_	"Clearing tracks 127/127" while playing the first track since starting the sim
07:21:24	saratoga_	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	JdGordon	can you put it in a real crash so you can get a stack trace in gdb?
07:23:25	saratoga_	sorry i mean deadlock
07:23:30	saratoga_	i haven't managed to get it to crash
07:23:45	saratoga_	and i don't really know how to use gdb
07:24:13	JdGordon	I keep having the urge to print out the entire buffer/playback code and draw lines everywhere to follow what happens
07:24:50	saratoga_	yeah
07:24:53	saratoga_	well i'm going to sleep
07:24:58	saratoga_	good night and good luck
07:25:12	JdGordon	send off an email with your finding?
07:25:14	JdGordon	+s?
07:25:24		Quit moos (Read error: 145 (Connection timed out))
07:25:54	saratoga_	i'm not really sure what we found out
07:26:06	JdGordon	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	saratoga_	JdGordon: email sent, feel free to add your thoughts
07:42:36	saratoga_	huh email got badly corrupted somehwo
07:42:45	JdGordon	haha
07:45:01	saratoga_	wow hotmail is fucked up tonight
07:47:15	saratoga_	that time it worked
07:47:41	JdGordon	no change here...
07:47:54	JdGordon	ah, 3rd time lucky
07:55:00		Quit saratoga_ ("Page closed")
08:00
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	amiconn	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	JdGordon	ok, that would explain why my covers work on target but not in the sim
08:31:16	JdGordon	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:00
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
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:00
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	DaveDavenport	http://images.sarine.nl/HDD6320/ <−− sorry for crappy foto's didn't have propper camera with me
12:00
12:13:20	mt	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	DaveDavenport	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
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	Korean	hi everyone
13:37:07	Korean	hello?
13:37:31	Korean	heeeeeeeeeeeeeeeeeeeeeeeeeelllllllllllllllllllllllllloooooooooooooo?
13:37:37	Korean	....
13:38:27	krazykit	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:00
14:01:43	mcuelenaere	DaveDavenport: did you add these pictures/information to the wiki?
14:07:20	DaveDavenport	mcuelenaere: everything is allready there
14:07:21	DaveDavenport	chip info
14:07:43	mcuelenaere	ok
14:08:30	DaveDavenport	hmmm I need to register to edit wiki?
14:08:56	mcuelenaere	yes
14:10:05	DaveDavenport	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	DaveDavenport	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	CIA-43	New commit by mcuelenaere (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:00
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
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	AlexP	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	kugel	AlexP: it looks like
16:34:38	AlexP	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	AlexP	It is now official :)
16:35:16	kugel	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	AlexP	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	n1s	yay freeze
16:36:25		Join jboy [0] (n=langzeit@p57915A54.dip.t-dialin.net)
16:36:44	n1s	I asked a couple of times in here but noone answered
16:37:05	*	kugel didn't notice
16:37:33	kugel	unfortunately we have a few bugs left :p
16:38:33	PSPdemon	...lol
16:38:54	rasher	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	rasher	I'll send off a mail with an appropriate subject to -dev, just to make sure everyone noticed
16:42:05	JdGordon	i dont think it will make any difference
16:42:47	rasher	fine, let's aim for 23rd then
16:43:08	JdGordon	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	rasher	Oh gosh, this means I'm late on the translation update mail also
16:44:42	kugel	I think it's fine to prolong the freeze and shorten the branch period, but we should aim for 23rd
16:46:24	rasher	oh
16:46:50	rasher	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	kugel	rasher: yup, the branch period is boring anyway :)
16:52:36	rasher	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:00
17:02:05	kugel	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	Zagor	bus-factor?
17:06:59	kugel	http://en.wikipedia.org/wiki/Bus_factor
17:08:02	Zagor	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	Zagor	I was tempted efter tweaking it for clip, but other things got in the way. maybe I should dig in again.
17:09:17	kugel	JdGordon and saratoga did last night
17:09:50	Zagor	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	petur	kugel: if Bin Laden ever bombs Stockholm, we might have a problem ;)
17:16:34	kugel	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	kugel	Blue_Dude: ping
17:38:09	Blue_Dude	kugel:pong!
17:38:29	kugel	Blue_Dude: have you seen FS #10572 ?
17:39:11	Blue_Dude	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	kugel	no
17:39:45	kugel	but I'm using the limiter, and occasionally timestrech, so I'd like to have that fixed
17:40:02	kugel	I think both use some sort of look-ahead mechanism
17:42:25	kugel	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	Blue_Dude	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	Blue_Dude	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	Blue_Dude	It'll take time :)
17:44:14	Blue_Dude	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	kugel	full-blown is a word you really should avoid here :)
17:47:33	Blue_Dude	How about "more fully featured than just a db setting"?
17:47:55	kugel	just "not as limited" :p
17:48:10	Blue_Dude	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
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	aidy	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	kugel	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	rasher	Well, more broken.
18:37:05	kugel	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	kugel	this is to fix FS #10451 btw
18:37:54	rasher	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	Grahack	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	gevaerts	Grahack: the plugin API only has functions that people actually needed in plugins, functions aren't added just because they can
18:58:05	domonoky	Grahack: we normally only put things we need into the plugin api, so perhaps nobody needed this function until now ?
18:58:36	gevaerts	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
19:00:08		Quit bertrik_work ("CGI:IRC")
19:00:53	Grahack	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	shriven	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	domonoky	shriven: if itunes cant restore it, you could try the manual way (see IpodManualRestore in the wiki)
19:43:10	shriven	ahh, thanks.. Tried that a few times now.
19:43:36	shriven	same result. : (
19:52:02	domonoky	shriven: then it looks like your out of luck.. maybe some hardware is broken.
19:52:54	shriven	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	domonoky	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	shriven	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	shriven	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
20:00:02	shriven	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:00
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	aidy	guys I'm getting ready with a proper touchscreen wps, yw
21:28:22		Quit jvd (Remote closed the connection)
21:30:47	mt	aidy: Nice :)
21:31:49	aidy	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	aidy	and it's not starting up anymore
21:32:49		Part brn2dth
21:32:52		Quit Stephenccc ("http://irc2go.com/")
21:37:48	aidy	holy p :(
21:39:21	aidy	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:00
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	salty-horse	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	archivator	salty-horse: it can also control playback if your music player supports that
22:12:34	archivator	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	domonoky	fp = fixed point ?
22:18:07	domonoky	or floating point ? :-)
22:18:15	archivator	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	archivator	libspeex uses kiss_fft which I find to be somewhat bloated
22:23:50	archivator	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	archivator	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	AsaelReiter	Hi
22:28:12	domonoky	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	domonoky	archivator: also libfaad had a cfft.c file ..
22:31:27	archivator	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	AsaelReiter	I think that the patch in FS #10589 is well. Can somebody check and commit it?
22:32:33	domonoky	archivator: wma had a fft too.. you just have to search the svn logs :-)
22:33:21	archivator	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	archivator	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	domonoky	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	AsaelReiter	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	AsaelReiter	and the food/argh_collision function check between a food/argh and one point.
22:42:03	AsaelReiter	the loop I wrote is very similar to these functions, but it checks between 2 food/arghs.
22:43:14	domonoky	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	domonoky	the need for this loop is because food/arghs can be bigger then 1 square/pixel ?
22:44:33	AsaelReiter	yes
22:46:11	AsaelReiter	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	domonoky	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	AsaelReiter	maybe I didn't understand your English, but I didn't change any code about the worms.
22:50:23	domonoky	yes, you didnt but i wonder if this works.
22:52:19	domonoky	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	domonoky	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:00
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	archivator	domonoky: I think it was the libwma one :) If only I could figure out how to use it :)
23:18:52	domonoky	:-)
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	aidy	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))

Previous day | Next day