#rockbox 2011-08-29

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 2011-08-29

00:05:05	***	Saving seen data "./dancer.seen"
00:09:04	pamaury	has anything started to examine the clip zip firmware ?
00:14:06	bertrik	pamaury, yes
00:14:42	pamaury	who is doing that ?
00:14:47	bertrik	there is already a basic framework to build the bootloader (with stubs for the lcd/backlight driver and a guesswork implementation for the buttons) :D
00:15:11	pamaury	yes I know but it doesn't mean someone has really started to look for the differences :)
00:15:19	evildaemon	So, now that that's solved, I actually have another issue, which, if fixed, will mean I can use Rockbox on my nano. The issue is that when I first start up Rockbox after installation. (This was on a 2nd and 1st gen) The database initialization screws up, and says I have 443 tracks in my database. (When I have zero.) When I try and "Play" a track on the 2nd gen (Which did have tracks) I get an error message with what I can only assum
00:16:06	pamaury	But basically we are sure that it's the same soc right ?
00:16:17	bertrik	I am looking at the OF and trying to implement an LCD driver now, saratoga is also looking at the OF
00:16:26	bertrik	sure enough
00:16:51	bertrik	the codec registers and pmu registers seem to match at least
00:16:53	evildaemon	Clip zip? Did Sanza put out a new media player?
00:17:03	bertrik	and it has the same amount of memory as the clip+
00:17:15	bertrik	a lot of the GPIOs even seem to match up
00:17:22	pamaury	nice, I hope there will be no nasty differences that will bite us :)
00:17:49	bertrik	I think I'll buy one as soon as it becomes available for sale in the EU
00:17:54	pamaury	The screen of the clip zip is nice
00:18:09	pamaury	I'm tempted to buy one now ^^
00:18:48	bertrik	pamaury, not so sure, in the pictures in the abi review thread, it appears to have some crosstalk, but I'm not seeing that in other reviews and it could just be an artifact of photography
00:18:59		Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se)
00:19:14	bertrik	the OF is already prepared to accept two different kinds of LCD by the way
00:19:28	gevaerts	evildaemon: the number shown by the database initialisation is the number of files, not audio tracks. Also, there's a bug that makes the initialisation fail (or at least do interesting things) if it finds no audio tracks at all
00:20:14	bertrik	pamaury, the tricky and dangerous part in my opinion is to get our dualboot code working
00:20:31	evildaemon	Thank you for clarifying the first part.
00:20:36	pamaury	yes, the amsv2 bootloader is f a tricky part
00:20:37	evildaemon	Explains a great deal.
00:21:08	evildaemon	But, I still had this problem even when I had tracks on the pod?
00:21:20	gevaerts	evildaemon: you also got cut off at "message with what I can only assum". IRC does have a line length limit
00:21:20	bertrik	in contrast to the clip+, the clip zip again uses a 2x3 key scan matrix for some of the buttons
00:21:47	evildaemon	"assume to be an ARM assembly op code."
00:22:42	bertrik	pamaury, I did already prepare mkamsboot to patch the OF with our bootloader, the missing thing is the dualboot part
00:23:13	pamaury	I wonder if the usb part is the same, same part => same problems :(
00:23:21	bertrik	Our amsinfo tool parsed the OF without any problem by the way :)
00:24:05	pamaury	Did you also disassembled the clipv2/+ os ? Can you tell if it's the same or it is really different ?
00:24:24	pamaury	(I'm interested in the usb part of course)
00:25:25	bertrik	I haven't looked at the usb part yet, mostly buttons, radio and lcd so far
00:25:40	gevaerts	evildaemon: right. If you get that sort of thing with a current build (or the latest release), we wouldn't mind a bug report with as many details as you have. It's probably a good idea to check the filesystem for errors first though
00:26:47	evildaemon	The 2nd gen's filesystem was screwed, haven't tried the first gen yet.
00:27:40	evildaemon	1st gen works. shrug
00:27:52	gevaerts	If you have filesystem corruption, we won't even try to promise correct playback...
00:27:58	evildaemon	Lol.
00:28:01	evildaemon	Duh.
00:28:20	gevaerts	Ideally we'd handle that better, but that's not too easy
00:28:23	evildaemon	I just assumed that the database thing was indicative of the same problem.
00:28:45	evildaemon	But it's not, so I'm happy.
00:28:48	evildaemon	Thanks guys.
00:29:34	gevaerts	We'd like that one to be fixed too of course, but not that many people understand the database code well enough to fix it while being confident nothing else breaks...
00:29:58	evildaemon	As long as this thing can play .ogg/.flac now, it was worth the trouble.
00:29:59	pamaury	bertrik: ok, tell me if you see something related to usb :)
00:30:18		Quit simonlnu (Ping timeout: 260 seconds)
00:31:04	bertrik	I can look for stuff using a specific base address
00:31:34	pamaury	Try to have a look at the same one has in the clip+
00:32:07	bertrik	nope, there's nothing referencing 0xc6000000 in the main firmware block
00:32:39	pamaury	in the clip+ OF there are just a few lines, all the rest is done via a base pointer so it's hard to follow
00:33:01	pamaury	I seem to remember the entry point was in the dbop handler or something similar
00:38:05		Quit ChickeNES (Quit: Computer has gone to sleep.)
00:38:37		Quit ender` (Quit: Why shouldn't truth be stranger than fiction? Fiction, after all, has to make sense. -- Mark Twain)
00:38:57		Quit pamaury (Remote host closed the connection)
00:40:29		Quit bertrik (Quit: :tiuQ)
00:53:42	CIA-14	New commit by jethead71 (r30373): codec_main() prototype inside codec_crt0.c is no longer needed since it's in codecs.h now.
00:55:57	CIA-14	r30373 build result: All green
01:00
01:04:40		Join Galois [0] (djao@efnet-math.org)
01:12:13		Quit TheLemonMan (Quit: leaving)
01:14:06		Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it)
01:14:06		Quit TheLemonMan (Client Quit)
01:14:26		Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it)
01:18:47	saratoga	pamaury: just skimming the fuzev2 and clipzip usb_functio files, they're nearly identical
01:18:50		Quit neferty (Ping timeout: 252 seconds)
01:19:12	saratoga	the first half looks like they took the same precompiled binary and just relinked it (e.g. only the return addresses seem to be changed)
01:19:31		Join neferty [0] (~andor@173.242.127.201)
01:19:49	saratoga	the second half looks like they recompiled some of the functions with minor changes or an updated header or something as there are minor changes (different register numbers flipped around, etc)
01:22:48		Quit sideral (Quit: Leaving.)
01:23:03		Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
01:41:06		Quit Zarggg_ (Quit: Rebooting client...)
01:42:34		Join ageis [0] (~ageis@c-76-127-201-198.hsd1.ma.comcast.net)
01:43:47		Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
02:00
02:03:30	JdGordon	[Saint]: it isnt only that the specific part of the manual is well written (I'm fairly sure most of the manual is), its also how discoverable the information actually is
02:04:30	JdGordon	given it is so big, and we know people think its TL;DR, unless people actually read it cover to cover most info is completly ignored
02:05:10	***	Saving seen data "./dancer.seen"
02:05:11	*	JdGordon had to click through 3 links to find the section on config files just now
02:05:22	JdGordon	and thats knowing where in the menu structre it lives
02:24:15		Quit jhMikeS (Read error: Connection reset by peer)
02:29:13		Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
02:41:34		Quit TheLemonMan (Quit: leaving)
02:41:52		Join TheLemonMan [0] (~giuseppe@ppp-83-10.26-151.libero.it)
02:42:25		Quit TheLemonMan (Client Quit)
02:45:28		Quit MethoS- (Remote host closed the connection)
03:00
03:03:47		Quit kadoban (Ping timeout: 245 seconds)
03:24:14		Quit mgue (Ping timeout: 276 seconds)
03:25:17		Join mgue [0] (~mgue@p5DDA1787.dip.t-dialin.net)
03:47:33		Quit mgue (Ping timeout: 240 seconds)
03:49:08		Quit [Saint] (Ping timeout: 250 seconds)
03:50:15		Quit nick-p (Quit: Leaving)
03:58:51		Join [Saint] [0] (~st.lasciv@203.100.215.45)
04:00
04:05:12	***	Saving seen data "./dancer.seen"
04:06:36		Quit ageis (Ping timeout: 240 seconds)
04:06:59		Join ageis [0] (~ageis@c-76-127-201-198.hsd1.ma.comcast.net)
04:20:11		Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net)
04:30:47		Quit amiconn (Disconnected by services)
04:30:48		Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:30:48		Quit pixelma (Disconnected by services)
04:30:50		Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:30:52		Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:31:08		Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:43:26		Join Blue_Dude [0] (~chatzilla@adsl-74-235-206-237.mco.bellsouth.net)
04:45:37	Blue_Dude	Just wanted to throw this out there: something recently (last few days) broke speed and pitch. Playback freezes when attempting to play back at anything other than 100%/100%. I'll file a bug report, but I don't know if I have the time to chase down the cause or the revision.
04:46:17	*	[Saint] points accusingly at jhMikeS...
04:46:23	[Saint]	"He probably did it!" ;)
04:47:30		Quit [7] (Disconnected by services)
04:47:43		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04:51:04	Blue_Dude	Probably. :)
04:51:24	Blue_Dude	Now immortalized as FS #12250.
04:51:25	fs-bluebot	http://www.rockbox.org/tracker/task/12250 Playback freezes when using speed or pitch change (bugs, new)
04:51:47	[Saint]	Silly question...but, verified with SVN head?
04:51:56	[Saint]	there was some poking around last night.
04:52:44	Blue_Dude	Hm... Lemme go back with a completely clean checkout and try again. I don't think it will matter but it can't hurt to check.
04:53:09		Quit Galois (Remote host closed the connection)
04:53:26		Join Galois [0] (djao@efnet-math.org)
04:54:02		Join PurlingNayuki [0] (~PurlingNa@113.97.68.216)
04:55:47	Blue_Dude	Another (?) problem: a kernal panic when playing back a particular mp3 file at 140% speed. No clue what causes that. Good news is that the panic is now gone. Bad news is that it freezes like all the others.
04:59:09		Join simonlnu [0] (3rjyM1OEA7@unaffiliated/simonrvn)
05:00
05:06:19		Quit simonlnu (Ping timeout: 260 seconds)
05:11:18		Join simonlnu [0] (wXFXzg9VZ4@unaffiliated/simonrvn)
05:12:13	Blue_Dude	Yeah, still munged up with a clean install. Was worth a try.
05:14:01		Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk)
05:16:10		Quit simonlnu (Ping timeout: 260 seconds)
05:19:28	*	jhMikeS
05:19:37	jhMikeS	has been playing things at different speeds
05:19:42	PurlingNayuki	Is the freezing better than panic? :P
05:20:38	jhMikeS	it's not doing either
05:20:49	jhMikeS	I'll try another device
05:22:48	Blue_Dude	I'm working from a e200 device. I haven't tried a sim.
05:24:16		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
05:24:22	jhMikeS	aha, it happens with tdspeed, not with normal resampling
05:24:56	jhMikeS	not freezing but not able to fill the sample buffer
05:25:22	jhMikeS	which maxes out the thread priority, making the UI sticky
05:25:25	Blue_Dude	Yeah, I'm going off the pitch quickscreen and bookmarks. Both of which go off of tdspeed.
05:25:50		Join simonlnu [0] (7TFWnpQ4bI@unaffiliated/simonrvn)
05:25:54	jhMikeS	maybe tdspeed made assumptions about buffer sizes?
05:26:01	Blue_Dude	"Freeze" might have been a bad word. It's not locked up, but playback stops and eventually the UI drops.
05:26:09		Quit PurlingNayuki (Quit: PurlingNayuki)
05:32:24	jhMikeS	might want to check before pcm buffer updates?
05:34:46	Blue_Dude	FYI, I reverted to an older checkout (r30000, just 'cause it's nice and round) and the slowdown and panics are gone. Which is not surprising since it's using the old engine, but now you know.
05:36:10	[Saint]	Not that useful, but, good to know ;)
05:36:16	jhMikeS	I know it worked while working on engine updates, for mixer and pcm buffer, not so sure which it didn't like, if any
05:37:03	Blue_Dude	No, not useful at all really, but the player works until the bug is chased down. :)
05:38:27	jhMikeS	if tdspeed can't deal with pretty much arbitrary sizes buffers or something, then it's just outright broken anyway
05:38:27	Blue_Dude	I listen to a lot of voice material and depend on speed.
05:38:45	*	[Saint] can't resist.
05:38:52	[Saint]	"Drugs are bad...mmmmmkay?"
05:39:02	Blue_Dude	Oh, no you don't...
05:39:05	jhMikeS	@-@
05:39:07	Blue_Dude	Never mind, you went there.
05:39:56	Blue_Dude	I'll just chew on these size 8 1/2's for a few minutes.
05:41:49	jhMikeS	well, I'm building to r30365 and will see if r30366 is upsetting the delicate flower
05:42:17	*	[Saint] sees a comment in the forums from saratoga and wonders if dircache actually makes a notable difference in a flash based player, or if the extra buffer would be of more value.
05:43:10	[Saint]	in a HDD player, sure...dircache FTW. But in my flash based players I just disable it.
05:43:16	jhMikeS	probably with opening and closing file descriptors, since that seems unduly slow
05:43:53	[Saint]	Hmmm. I wonder if there's a meaningful way I can test this myself.
05:44:15	jhMikeS	test_disk
05:44:21		Join Rob2222 [0] (~Miranda@p4FFF2876.dip.t-dialin.net)
05:46:28		Quit Horschti (Quit: Verlassend)
05:47:31	[Saint]	Oh, yeah...right. I should have been more specific. Without assuming you all have a doorway into my thoughts (you don't want this).
05:48:02	[Saint]	I was thinking along the lines of a double-blind test where I attempted to identify if dircache was enabled, or disabled.
05:48:11		Quit Rob2223 (Ping timeout: 240 seconds)
05:50:47	jhMikeS	I could probably tell by looking at the buffering screen :)
05:56:06	jhMikeS	seems it doesn't like r30366
05:59:01		Quit jfc (Read error: Operation timed out)
06:00
06:05:13	***	Saving seen data "./dancer.seen"
06:05:47		Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net)
06:09:04		Quit ChickeNES (Client Quit)
06:13:46		Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com)
06:15:21		Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
06:18:15		Quit Scromple (Ping timeout: 246 seconds)
06:18:19		Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
06:19:43		Quit Scr0mple (Ping timeout: 245 seconds)
06:21:11		Quit Blue_Dude (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603])
06:26:57		Quit user829385 (Quit: Leaving.)
06:35:10		Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude)
06:36:19		Join [Saint_AndChat] [0] (~Saint]@203.100.215.45)
06:37:22	Blue_Dude	Also FYI, r30365 works correctly with regard to tdspeed (you knew that already), but also crashes with an "undefined instruction" panic when trying to play back a particular mp3 file at 140% speed. Dunno yet why it does that. No problems at 100% speed and the file passes a corruption test.
06:37:32		Quit Blue_Dude (Client Quit)
06:40:58	jhMikeS	tdspeed needs to give a proper output estimate. space near the end of the buffer, while it may have that much free, is not necessarily contiguous, since it has a small guardbuffer rather than automatic wrap
06:42:48		Quit nick-p (Quit: Leaving)
06:57:15		Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
06:59:27		Quit Scromple (Ping timeout: 264 seconds)
07:00
07:26:52		Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net)
07:44:38		Quit liar (Read error: Connection reset by peer)
07:45:43		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
07:45:55		Quit ChickeNES (Quit: Computer has gone to sleep.)
08:00
08:05:15	***	Saving seen data "./dancer.seen"
08:10:00		Quit powell14ski_ (Quit: powell14ski_)
08:45:09		Join Zagor [242] (~bjst@rockbox/developer/Zagor)
08:47:18		Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net)
08:48:23		Quit ChickeNES (Client Quit)
08:50:00		Join ChickeNES [0] (~ChickeNES@99-133-145-177.lightspeed.cicril.sbcglobal.net)
08:57:36		Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
08:57:36		Quit bertrik (Changing host)
08:57:36		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
08:57:46		Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it)
08:58:07		Quit ChickeNES (Quit: Computer has gone to sleep.)
09:00
09:00:03		Join Bagder [241] (~daniel@rockbox/developer/bagder)
09:01:05		Join ender` [0] (~ender@foo.eternallybored.org)
09:11:09		Quit TheLemonMan (Quit: leaving)
09:11:30		Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it)
09:11:50		Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net)
09:11:50		Quit pamaury (Changing host)
09:11:50		Join pamaury [0] (~quassel@rockbox/developer/pamaury)
09:17:30		Join n1s [0] (~quassel@rockbox/developer/n1s)
09:21:43		Quit Scr0mple (Quit: Leaving)
09:23:27		Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net)
09:29:13		Quit bertrik (Ping timeout: 240 seconds)
09:30:41		Quit n17ikh (Quit: ZNC - http://znc.sourceforge.net)
09:39:05		Join LinusN [0] (~linus@giant.haxx.se)
09:40:20		Quit [Saint_AndChat] (Remote host closed the connection)
09:43:21	[Saint]	Can someone compile/upload for me please...clean, svn head, 240x320 and 480x800 RaaA .apk if its not too much trouble?
09:44:13	*	[Saint] wished RaaA was in the build system.
09:44:45	[Saint]	Or that his build machine didn't need a new PSU.
09:44:59	[Saint]	*wishes
09:55:15	pamaury	I think we compile most (if not all) files with -fomit-frame-pointer right ? Did anyone think about implementing backtracing on panic ?
09:58:16	n1s	yes we compile everything with -fomit-frame-pointer
10:00
10:01:52	n1s	i think we have quite some asm using the fp reg so i wonder how gcc would handle that
10:03:39	pamaury	But in C functions, the compiler can tell the offset of the stack pointer to the return address, so it's probably possible to do it
10:03:49		Join Buschel [0] (~chatzilla@p54B66FFB.dip.t-dialin.net)
10:03:56	pamaury	for asm functions, it's indeed more difficult
10:05:01	pamaury	On the other hand, our panic screen is basically useless in many cases so backtrace would be nice
10:05:17	***	Saving seen data "./dancer.seen"
10:05:24	n1s	sure it would be nice
10:06:50	n1s	i wonder if we would like to have it enabled always, since it would mean slightly worse code
10:07:45	pamaury	I don't know, it depends on the size of data you need to backtrace
10:09:17	pamaury	but it also means that you have to do a debug build to get the information
10:31:42		Join JdGord [0] (~AndChat@42.62.218.156)
10:43:25	pamaury	I really should not stash important changes and go for holydays, now I'm lost in my own code :)
10:45:35		Join casainho [0] (~chatzilla@bl20-221-34.dsl.telepac.pt)
10:47:39		Quit JdGord (Quit: Bye)
10:53:35	pamaury	does someone know where I can find some documentation about the debug sections produced in debug compilation ?
10:56:58	user890104	[Saint]: did you find someone to make you the builds you need?
10:57:41	[Saint]	user890104: I didn't, no.
10:58:06	user890104	ok, i think i can help you then
10:58:14	[Saint]	Thanks, appreciated.
10:58:27	[Saint]	No rush, or obligation...but I'd appreciate it.
10:58:40	user890104	these are portrait and not landscape, right?
10:58:58		Quit TheLemonMan (Quit: Lost terminal)
10:59:11	[Saint]	Correct.
10:59:41	user890104	ok, building
11:00
11:01:46		Join TheLemonMan [0] (~giuseppe@ppp-146-29.26-151.libero.it)
11:08:29		Nick bug2000 is now known as bug (~bug@unaffiliated/bug2000)
11:08:37		Nick bug is now known as bug2000 (~bug@unaffiliated/bug2000)
11:12:07		Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
11:14:03	kugelp	n1s: our asm on ARM doesn't depend on the fp reg being free anymore iirc
11:15:39	kugelp	backtrack is probably difficult since panics can called from from the code (several stacks) and in exception handlers (another different stack)
11:15:55	kugelp	backtrace*
11:17:38	pamaury	true, but perhaps that can be solved (at partially)
11:18:24	kugelp	I think we can use gcc to get the direct caller though
11:18:52	pamaury	you mean using the debug info ?
11:19:23	kugelp	some builtin
11:20:05	pamaury	Perhaps, but we want the full trace, the direct caller is not always relevant
11:27:52		Join mt [0] (~mt@rockbox/developer/mt)
11:30:57	*	JdGordon is zonked
11:48:22		Join MrNorrell [0] (~7d3cad45@giant.haxx.se)
11:49:54		Quit MrNorrell (Client Quit)
11:52:47		Join MrNorrell [0] (~7d3cad45@giant.haxx.se)
11:56:15		Quit MrNorrell (Client Quit)
12:00
12:05:19	***	Saving seen data "./dancer.seen"
12:19:25		Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
12:35:22		Join user829385 [0] (~aoeu@112.166.15.141)
12:38:59	[Saint]	kugel: Ping?
12:39:18	kugel	[Saint]: ?gniP
12:39:51	[Saint]	user890104 is having some "issues" building RaaA...
12:39:53	[Saint]	[22:33] <user890104> make: /home/venci/android-sdk-linux_x86/platform-tools/aapt: Command not found
12:39:53	[Saint]	[22:33] <user890104> make: *** [/home/venci/rockbox/build-raaa-480x800/bin/resources.ap_] Error 127
12:40:17	[Saint]	this doesn't exist in the current SDK, is it too new?
12:40:54	[Saint]	"this" == android-sdk-linux_x86/platform-tools
12:41:19	[Saint]	that dir isn't present in the latest SDK
12:41:38	kugel	you need to install the platform tools first
12:42:19	[Saint]	he's run ./android, with the same params as the installtoolchain script.
12:42:43	[Saint]	"./android update sdk −−no-ui −−filter platform,tool"
12:43:02	[Saint]	and (according to him) this dir is not present.
12:43:38	kugel	the platform-tools is not there indeed, that's created with the installation of the platform tools package
12:43:50	[Saint]	user890104: Do you care to coment, so I'm not talking on your behalf?
12:43:58	[Saint]	Apparently there's some step you're missing.
12:44:05	kugel	I don't know the filter for that (let me remind you that I never used or touched installToolchain.sh :) )
12:44:08	user890104	i have platforms/android-4/tools/aapt and platforms/android-3/tools/aapt instead in the sdk dir
12:44:15	[Saint]	kugel: But, shouldn't ""./android update sdk −−no-ui −−filter platform,tool"" create this?
12:44:51	kugel	I don't know the android command line
12:45:14	[Saint]	all that says is "instal platform tools, and all the platform packages"
12:45:29	[Saint]	(without bugging me with a UI)
12:45:54	kugel	ah, add platform-tool to that list
12:46:20	kugel	i.e. ./android update sdk −−no-ui −−filter platform,tool
12:46:26	kugel	ffs, damn irssi
12:46:45	kugel	./android update sdk −−no-ui −−filter platform,tool,platform-tool
12:47:28	[Saint]	Aha, right. I had to direct him to the commandline ./android install, due to X issues.
12:47:52	kugel	user890104: ^
12:48:03	user890104	yeah, done that, thanks
12:48:04	[Saint]	I pulled that from ememory, then checked it against installtoolchains, it seems installtoolchains doesn't install platform-tools wither.
12:48:13	[Saint]	*memory
12:48:21	[Saint]	*either
12:48:22	kugel	I can see that yes
12:48:27	[Saint]	damn keyboard.
12:54:38		Quit mt (Ping timeout: 260 seconds)
13:00
13:02:03		Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk)
13:04:50		Quit kadoban (Ping timeout: 264 seconds)
13:06:47		Quit avacore (Read error: Operation timed out)
13:07:53		Join _Zagor [242] (~bjst@rockbox/developer/Zagor)
13:08:24		Quit Zagor (Ping timeout: 252 seconds)
13:09:10		Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk)
13:20:08		Nick _Zagor is now known as Zagor (~bjst@rockbox/developer/Zagor)
13:31:37		Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
13:42:44		Join MethoS- [0] (~clemens@134.102.106.250)
13:42:49		Part LinusN
13:43:04		Join LinusN [0] (~linus@giant.haxx.se)
13:45:24		Quit ender` (Read error: Connection reset by peer)
13:46:55		Join ender` [0] (~ender@foo.eternallybored.org)
13:53:45		Quit nick-p (Quit: Leaving)
14:00
14:05:20	***	Saving seen data "./dancer.seen"
14:07:37		Join ptrkmj_ [0] (~chatzilla@95-25-84-98.broadband.corbina.ru)
14:08:53	tguinot	The file "binutils-2.20.1.tar.bz2" downloaded by the rockboxdev shell script is considered broken for me
14:09:50	tguinot	the url is http://www.rockbox.org/gcc/binutils-2.20.1-ld-thumb-interwork-long-call.diff
14:10:49	JdGordon	broken how?
14:10:59	[Saint]	I think you'll need to be more specific on how you consider it to be broken.
14:12:15	tguinot	sorry
14:12:33	tguinot	ROCKBOXDEV: extracting binutils-2.20.1.tar.bz2
14:12:38	tguinot	"bzip2: Compressed file ends unexpectedly; perhaps it is corrupted"
14:12:57	[Saint]	Download it manually.
14:14:01	tguinot	ok
14:20:55	tguinot	(Also, the script trys to download file binutils-2.20.1.tar.bz2 from http://mirrors.kernel.org but it doesn't exist anymore, it's binutils-2.20.1a.tar.bz2 now (since 26th august) )
14:28:52		Part LinusN
14:29:06		Join LinusN [0] (~linus@giant.haxx.se)
14:31:16	Buschel	arghh, test_codec is totally fucked up if HAVE_ADJUSTABLE_CPU_FREQ is defined :/
14:34:24	Buschel	menu entries beyond "boost" are doing weird things
14:40:33		Join T44 [0] (~Topy44@f049067004.adsl.alicedsl.de)
14:44:16		Quit Topy44 (Ping timeout: 245 seconds)
14:50:49	kugel	gevaerts: hey, I just read the mail that I successfully passed gsoc! Thank you a lot.
14:53:22	tguinot	[Saint]: should I report the file name error in the script ? or maybe it is updated automatically
14:55:13		Quit ptrkmj_ (Quit: ChatZilla 0.9.87 [Firefox 3.6.20/20110803131630])
14:55:48	JdGordon	which compiler is that for? a new binutils version probably means we need to verify targets using it dont break
15:00
15:00:21	kugel	2.20.1 is used on cf and arm iirc
15:00:36	CIA-14	New commit by buschel (r30374): Fix logic of test_codec for targets with HAVE_ADJUSTABLE_CPU_FREQ.
15:00:37	kugel	but 2.20.1a sounds like re-packaging so probably not an issue
15:03:48	CIA-14	r30374 build result: All green
15:29:45	n1s	but why the hell did they kill the old version?
15:30:30	n1s	they keep like every version since 1996 but deleted the one we use
15:30:34	[Saint]	kugel: Congratulations, from myself, and from many others I'm sure.
15:30:43	[Saint]	It sounds soppy, but I'm proud of you.
15:35:25	n1s	they are replaced on the official gnu ftp too, something must have been really wrong with them
15:40:17		Join mt [0] (~mt@41.234.33.83)
15:45:01		Quit mt (Ping timeout: 264 seconds)
15:48:32	CIA-14	New commit by buschel (r30375): Final commit to get test_codec working properly for both freq-scaling and non-freq-scaling targets.
15:48:46	Buschel	test_codec menu and statemachine is a mess...
15:49:59		Join mt [0] (~mt@41.234.33.83)
15:51:25	CIA-14	r30375 build result: All green
15:54:45	kugel	[Saint]: thank oyu
16:00
16:01:31		Quit mt (Ping timeout: 264 seconds)
16:02:27		Quit Bagder (Quit: Konversation terminated!)
16:05:21	***	Saving seen data "./dancer.seen"
16:06:28		Quit antil33t (Read error: Connection reset by peer)
16:06:40		Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
16:06:47	[Saint]	kugel: <warning, soppy content follows> No, really...thank you. You've brought many great things to this project </soppy content>
16:06:53		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
16:14:25	kugel	gevaerts: I should have time the next 2 weeks, so I wait for an OK to commit the buflib patches
16:14:49		Quit Poodlemastah (Quit: ZNC - http://znc.in)
16:15:07		Join Poodlemastah [0] (~Poodlemas@h-241-205.a218.priv.bahnhof.se)
16:15:48		Join mgue [0] (~mgue@p5DDA3B7F.dip.t-dialin.net)
16:18:19	kugel	I also must not forget to upload the code to google :\
16:18:19		Quit ageis (Read error: Connection reset by peer)
16:21:09		Join y4n [0] (y4n@unaffiliated/y4ndexx)
16:21:09		Quit simonlnu (Read error: Connection reset by peer)
16:21:20		Quit liar (Read error: Connection reset by peer)
16:21:27		Join simonlnu [0] (d6DH4Q57Bo@unaffiliated/simonrvn)
16:23:10		Quit MethoS- (Remote host closed the connection)
16:23:16		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
16:25:48		Quit Poodlemastah (Quit: ZNC - http://znc.in)
16:26:07		Join Poodlemastah [0] (~Poodlemas@h-241-205.a218.priv.bahnhof.se)
16:28:44		Quit mgue (Ping timeout: 240 seconds)
16:30:30		Join mgue [0] (~mgue@p5DDA1645.dip.t-dialin.net)
16:31:01		Quit simonlnu (Ping timeout: 250 seconds)
16:31:56		Quit antil33t (Read error: Connection reset by peer)
16:32:16		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
16:35:34		Quit markun (Ping timeout: 268 seconds)
16:38:30		Join simonlnu [0] (P4vjJlN0nJ@unaffiliated/simonrvn)
16:39:09		Part LinusN
16:42:16		Join [Saint_AndChat] [0] (~Saint]@203.100.215.45)
16:47:56		Quit factor (Quit: Leaving)
17:00
17:05:57		Part Zagor
17:06:28	gevaerts	kugel: I'd say committing now (or soon) is fine
17:10:53		Quit liar (Ping timeout: 258 seconds)
17:12:27		Quit y4n (Disconnected by services)
17:12:33		Join y4n [0] (y4n@unaffiliated/y4ndexx)
17:12:46		Quit tchan (Quit: WeeChat 0.3.5)
17:16:51		Quit simonlnu (Remote host closed the connection)
17:17:48		Quit y4n (Read error: Connection reset by peer)
17:18:43		Join y4n [0] (y4n@unaffiliated/y4ndexx)
17:21:20		Quit y4n (Client Quit)
17:29:22		Quit [Saint_AndChat] (Remote host closed the connection)
17:42:06		Quit casainho (Remote host closed the connection)
17:42:38		Join casainho [0] (~chatzilla@2.81.221.34)
17:47:48		Quit casainho (Remote host closed the connection)
17:48:23		Join casainho [0] (~chatzilla@bl20-221-34.dsl.telepac.pt)
17:49:12		Quit Keripo (Ping timeout: 260 seconds)
17:55:10		Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu)
18:00
18:03:20		Join y4n [0] (y4n@unaffiliated/y4ndexx)
18:05:22	***	Saving seen data "./dancer.seen"
18:06:03		Join MethoS- [0] (~clemens@134.102.106.250)
18:08:26		Quit user890104 (Read error: Connection reset by peer)
18:09:35		Join user890104 [0] (~Venci@6bez10.info)
18:13:24		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
18:14:55		Quit MethoS- (Remote host closed the connection)
18:21:19		Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
18:30:25	bertrik	What should lcd_update_rect do with invalid coordinates?
18:31:08	bertrik	1) assume it won't happen, 2) not update the lcd, 3) correct the coordinates or 4) throw a panic or something similar ?
18:36:00		Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
18:37:56	bertrik	I think I'll go for 3) (and 2) if they're still not valid after correction)
18:41:42		Quit ReimuHakurei_ (Read error: Connection reset by peer)
18:41:52		Join ReimuHakurei [0] (~kudo@wireless.sit-co.net)
18:43:47		Quit ReimuHakurei (Read error: Connection reset by peer)
18:44:02		Join ReimuHakurei [0] (~kudo@wireless.sit-co.net)
18:55:54	*	bertrik wonders why we have prototypes like lcd_write_command/lcd_write_command_e/lcd_write_command_ex and lcd_write_data in lcd.h
18:56:28	bertrik	nobody calls these functions except the lcd drivers themselves
18:56:43		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
18:56:54		Quit casainho (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603])
19:00
19:01:39		Join Strife89 [0] (~Strife89@207.144.201.128)
19:13:48		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
19:19:26		Join froggyman_ [0] (~seth@50.105.142.145)
19:20:04		Quit froggyman (Read error: Connection reset by peer)
19:24:36		Quit antil33t (Read error: Connection reset by peer)
19:25:00		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
19:39:56		Quit antil33t (Read error: Connection reset by peer)
19:40:18		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
19:43:08		Quit bluebrother (Disconnected by services)
19:43:10		Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
19:45:05		Quit fs-bluebot (Ping timeout: 245 seconds)
19:46:11		Join fs-bluebot [0] (~fs-bluebo@g231120173.adsl.alicedsl.de)
19:47:57		Join Horscht [0] (~Horscht@xbmc/user/horscht)
19:48:01		Join simonlnu [0] (QwJqhIJggf@unaffiliated/simonrvn)
19:54:17		Join ptrkmj [0] (~chatzilla@95-27-214-13.broadband.corbina.ru)
19:55:48		Join tchan [0] (~tchan@lunar-linux/developer/tchan)
20:00
20:04:34		Join biopyte [0] (~kiwi@89.204.153.253)
20:05:26	***	Saving seen data "./dancer.seen"
20:06:13		Quit Keripo (Quit: Leaving.)
20:06:28		Join Lear [0] (chatzilla@141.191.216.81.static.g-hn.siw.siwnet.net)
20:07:02		Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu)
20:07:40	biopyte	Hi, I just bought a mini speaker for my sansa clip. i wonder if i could use the clip as an alarm clock, in a way that it boots up at a certain time. I guess not. Probably the clip has to be turned on allt he time in order to function as an alarm clock. but that would also consume a lot of energy if its turned on the whole night. could someone comment on this, pleae?
20:08:18		Quit y4n (Read error: Connection reset by peer)
20:09:26	[Saint]	biopyte: I suggest reading the manual.
20:09:50	[Saint]	Even googleing "Rockbox+Manual+Alarm" will give you all the info you need.
20:11:02	[Saint]	System - Time and Date - Wake-Up Alarm
20:11:23	biopyte	ok
20:11:57	biopyte	imjust checked the manual. i dont see that it would answer my particular question
20:12:25	biopyte	wake-up alarm ... got it
20:12:25	biopyte	thanks
20:12:50	[Saint]	Why would the manual not answer your question?
20:12:59	biopyte	cool
20:13:07	[Saint]	Its a manual, it contains very detailed info on all the players settings.
20:13:34	biopyte	it's ok ... said I found it
20:17:21	biopyte	bye
20:17:26		Quit biopyte (Quit: Leaving)
20:17:48	[Saint]	I know, I'm just wondering what made you think that the manual wasn't the best place to, or wouldn't answer you, specific question.
20:17:52	[Saint]	bah!
20:34:03		Join y4n [0] (y4n@unaffiliated/y4ndexx)
20:43:46		Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.)
20:45:50		Join [Saint] [0] (~st.lasciv@203.100.215.45)
21:00
21:01:48		Quit y4n (Read error: Connection reset by peer)
21:02:47		Join y4n [0] (y4n@unaffiliated/y4ndexx)
21:18:24		Join ReimuHakurei_ [0] (~kudo@wireless.sit-co.net)
21:18:52		Quit ReimuHakurei (Read error: Connection reset by peer)
21:18:58		Nick froggyman_ is now known as froggyman (~seth@50.105.142.145)
21:19:06		Quit froggyman (Changing host)
21:19:06		Join froggyman [0] (~seth@unaffiliated/froggyman)
21:22:05		Quit ptrkmj (Quit: ChatZilla 0.9.87 [Firefox 3.6.20/20110803131630])
21:26:39		Quit Lear (Quit: ChatZilla 0.9.87 [Firefox 7.0/20110824172139])
21:41:03		Quit ReimuHakurei_ (Ping timeout: 240 seconds)
21:42:19		Join ReimuHakurei [0] (~kudo@wireless.sit-co.net)
21:45:23		Quit ReimuHakurei (Read error: Connection reset by peer)
21:45:52		Join ReimuHakurei [0] (~kudo@wireless.sit-co.net)
21:49:55	amiconn	bertrik: lcd_write_* are asm functions for several drivers, hence the prototype
21:50:38	amiconn	As for lcd_update_rect() - it's supposed to crop the coordinates to valid range, and if height or width end up being zero, just return
21:54:42		Quit ReimuHakurei (Ping timeout: 250 seconds)
21:55:27		Quit y4n (Quit: The world around me drops away, replaced by worlds being created and destroyed by my imagination.)
22:00
22:02:29	bertrik	[Saint], odd, because the clipv1 doesn't have a wake-up alarm as far as I can tell
22:02:58	bertrik	clipv2 and clip+ (AMSv2) do have it
22:05:27	***	Saving seen data "./dancer.seen"
22:06:23	bertrik	found the SPI settings for the clip zip, the clip zip lcd driver is now nearly done except for actually testing it on a real device :D
22:07:33	n1s	details :)
22:09:15	bertrik	actually making it work is left as an exercise to the reader
22:15:08		Join ptrkmj [0] (~chatzilla@95-26-18-158.broadband.corbina.ru)
22:16:53	ptrkmj	Is support for True Audio on RB as good as it is for FLAC and WavPack?
22:20:17	Llorean	ptrkmj: I'm not even sure what you're asking.
22:21:50		Join powell14ski_ [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net)
22:22:33	ptrkmj	Well, I'm trying to figure out what codec would be the best for use with Rockbox. So far I chose 3 candidates: FLAC, WavPack, and True Audio.
22:22:59	Llorean	Given that they're all lossless, so that you can transcode files between them with ease, you could just try them all.
22:23:26	Llorean	Since it's hard for us to know what you're valuing about each of them, it's hard for anyone to know what you'd consider "as good" support.
22:23:46	ptrkmj	Probably, I would not see any difference.
22:23:50	ptrkmj	Right.
22:25:44		Quit niekie (Read error: Connection reset by peer)
22:26:13	ptrkmj	Which of the above codecs would be best regarding battery time?
22:26:50	Llorean	Depends on the player. Large filesizes tends to hurt more on hard disk based players, slower decoding speed tends to hurt more on players where disk access is "cheaper" in terms of battery cost.
22:27:37	ptrkmj	I have an had disk based ipod 5g
22:28:15	ptrkmj	So the FLAC is going to hurt more?
22:28:21	Llorean	Probably whichever one gets the best filesizes with your music, though if there's not a huge difference in filesize, again, the more optimized one might be best. You'd really just need to do some testing with your actualy music.
22:28:48	Llorean	Since filesize differences can vary greatly with the audio encoded.
22:29:35	ptrkmj	I doubt that filesizes wil vary significantl
22:30:26	ptrkmj	The smallest filesize would be achieved with Monkey's Audio Normal mode
22:30:43	ptrkmj	but it's the hardest to decode
22:31:14	Llorean	As I said, you'd really just need to do some testing.
22:31:40	ptrkmj	I probably won't since I'm too lazy :)
22:31:41	Llorean	My biggest suggestion would be doing a proper blind or double blind test against some high quality lossy encoders. Typically on portable hardware it's very, hard to tell the difference anyway
22:32:15	n1s	flac is by far faster than both tta and wavpack
22:32:42	n1s	so uses less cpu time, so if the file sizes are similar it will probably get the best runtime
22:33:18	Llorean	FLAC is almost "free" to decode on some devices, decoding fast enough that the CPU almost never boosts.
22:34:33	ptrkmj	Using lossy format would require doing extra encoding. Storage is cheap so I don't want to bother.
22:34:44	evildaemon	Speaking of flac, I don't mean to bother everyone in here again, but I'm having another issue. It can be summed up as: When i save .ogg files to my rockbox'd 1st gen ipod nano, it converts the .ogg to a .flac, increasing the file size for presumably no good reason. Is this normal?
22:36:03	Llorean	evildaemon: Whatever you're talking about has nothing to do with Rockbox.
22:36:05	ptrkmj	Do you know any comparisons similar to that:
22:36:24	Llorean	Rockbox runs on the player, and has no interaction with the file transfers. It's just a dumb disk as far as the PC is concerned.
22:36:30	ptrkmj	http://synthetic-soul.co.uk/comparison/lossless
22:36:31	ptrkmj	(it's from 2008)
22:36:50	evildaemon	Llorean: Fair enough. It's probably an issue with my music software then.
22:38:23	n1s	ptrkmj: http://www.rockbox.org/wiki/CodecPerformanceComparison#Portal_Player_40ARM7TDMI_41 has performance comparisons for various codecs on the cpu used in the ipod video
22:38:35		Quit Stummi (Quit: Bye!)
22:40:51	ptrkmj	thanks, it will come useful
22:41:46	*	amiconn summons thomasjfox
22:41:57	ptrkmj	indeed, FLAC is a piece of cake for CPU
22:43:17	ptrkmj	2.5 more efficient than WavPack
22:43:24	ptrkmj	*times
22:43:59	ptrkmj	True Audio decoder seems not optimized
22:44:11	n1s	correct
22:44:22	n1s	well, not very much at least
22:46:32	saratoga	i think its been optimized some since that test
22:48:17	saratoga	oh i guess not
22:50:15	amiconn	True audio is rather difficult to optimize due to its structure
22:50:35	amiconn	(source code structure, not format structure)
22:51:31	amiconn	Iirc it calls many functions for each sample
22:51:47	amiconn	(instead of looping over a block of samples)
22:51:57	ptrkmj	it performs comparably to WavPack on PC
22:54:29	ptrkmj	What is the meaning of the 4rd column in CodecPerformanceComparison charts? Do portable CPU have variable clock freq.?
22:55:25	n1s	it's the number of MHz of the cpu that is needed for realtime decoding
22:55:48	n1s	some of the cpus does have variable speed
22:56:11	ptrkmj	so it's an estimate?
22:56:28	n1s	no, it's a calculated number
22:57:02	n1s	max speed/realtime factor
22:58:40	ptrkmj	hmm, is this useful in any way? % of realtime is probably enough to judge the performance
22:59:21	n1s	it's just a different representation of the same thing, yes
22:59:52	saratoga	its a more interesting number then % realtime
22:59:58	Buschel	yes
23:00
23:00:10	saratoga	since its linear in performance
23:00:38	saratoga	verses scaling with 1/x
23:02:52	ptrkmj	I wonder how would simple WAV perform
23:03:13	n1s	iirc it needs about 1MHz
23:03:31	n1s	which is basically the codec shuffling data
23:03:56	n1s	not very interesting though
23:04:22	ptrkmj	Probably would drain battery faster than compressed codecs on HD-based targets
23:04:29	saratoga	yeah
23:04:46	saratoga	wav is probably just a test of how fast the ram is on your player
23:06:01	CIA-14	New commit by bertrik (r30376): sansa clipzip: implement more functions in the lcd driver
23:08:25	CIA-14	New commit by bertrik (r30377): sansa clipzip: correct GPIO used for backlight
23:09:01	CIA-14	r30376 build result: All green
23:09:22		Quit n1s (Remote host closed the connection)
23:12:21	CIA-14	r30377 build result: All green
23:16:59		Quit Strife89 (Quit: Heading home.)
23:20:31		Quit Keripo (Quit: Leaving.)
23:21:14		Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu)
23:24:02		Quit Keripo (Client Quit)
23:28:24	ptrkmj	http://flac.sourceforge.net/comparison_all_ratio.html
23:28:26	ptrkmj	Can you tell me the difference between 'Total' and 'CPU' times?
23:28:43		Join Keripo [0] (~Keripo@eng340.wireless-resnet.upenn.edu)
23:29:44		Join leavittx [0] (~leavittx@cl-534.mbx-01.si.sixxs.net)
23:30:53		Quit leavittx (Remote host closed the connection)
23:31:28		Join niekie [0] (~niek@CAcert/Assurer/niekie)
23:31:42		Quit domonoky (Read error: Connection reset by peer)
23:34:32		Quit niekie (Read error: Connection reset by peer)
23:34:45		Join niekie [0] (~niek@2001:470:9326::3)
23:34:47		Quit niekie (Changing host)
23:34:47		Join niekie [0] (~niek@CAcert/Assurer/niekie)
23:34:53		Quit niekie (Remote host closed the connection)
23:36:34		Join niekie [0] (~niek@CAcert/Assurer/niekie)
23:41:03	saratoga	total probably refers to the sum of time spent in the codec and waiting on file IO
23:44:24		Join Horschti [0] (~Horscht@p5DD56C3D.dip.t-dialin.net)
23:44:24		Quit Horschti (Changing host)
23:44:24		Join Horschti [0] (~Horscht@xbmc/user/horscht)
23:46:44		Quit Horscht (Ping timeout: 252 seconds)
23:54:12		Join evilnick [0] (~evilnick@5e03124a.bb.sky.com)
23:54:12		Quit evilnick (Changing host)
23:54:12		Join evilnick [0] (~evilnick@rockbox/staff/evilnick)
23:55:02		Join MethoS- [0] (~clemens@134.102.106.250)

Previous day | Next day