#rockbox 2011-08-17

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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2011-08-17

00:03:13		Quit funman (Quit: Lost terminal)
00:05:18		Quit domonoky (Read error: Connection reset by peer)
00:09:18		Join GigaBrick [0] (~sagacious@67-5-105-134.spok.qwest.net)
00:11:05		Quit kadoban (Ping timeout: 240 seconds)
00:18:31		Part toffe82
00:24:40		Quit pamaury (Remote host closed the connection)
00:30:03		Part Zagor
00:32:32		Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
00:33:05		Quit TheLemonMan (Ping timeout: 240 seconds)
00:34:15		Join advcomp2019 [0] (~advcomp20@97-114-233-50.sxcy.qwest.net)
00:34:15		Quit advcomp2019 (Changing host)
00:34:15		Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
00:37:05		Quit advcomp2019_ (Ping timeout: 240 seconds)
00:37:49		Join FoH [0] (~foh@adsl-98-83-162-86.bhm.bellsouth.net)
00:38:52		Quit FoH_Phobos (Quit: And so, the universe ended.)
00:39:54		Quit ender` (Quit: /* Return code=1: generic error condition, Return code=2: all other error conditions */)
00:48:18		Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603])
00:51:18		Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se)
01:00
01:12:07		Join HaimN [0] (~quassel@95.86.116.121)
01:12:15		Quit wtachi (Quit: &)
01:15:05		Quit FoH (Quit: ¡ooʇ ‘ǝןdoǝd ǝɹɐ sʇɐq)
01:15:09		Quit MethoS- (Remote host closed the connection)
01:18:45		Quit bertrik (Ping timeout: 260 seconds)
01:19:15		Quit glued (Quit: CGI:IRC)
01:20:53		Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.)
01:22:16		Quit HaimN (Ping timeout: 264 seconds)
01:22:37		Quit sideral (Ping timeout: 258 seconds)
01:31:22		Quit drezon (Quit: So long and thanks for all the fish)
01:33:03		Quit Poodlemastah (Quit: ChatZilla 0.9.87 [Firefox 7.0a2/20110729175641])
01:42:25		Quit mudd1 (Ping timeout: 240 seconds)
01:53:00		Quit stripwax (Quit: http://miranda-im.org)
01:56:41	***	Saving seen data "./dancer.seen"
01:58:39		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
02:00
02:14:24		Quit Xerion (Read error: Connection reset by peer)
02:46:35		Quit GigaBrick (Ping timeout: 252 seconds)
02:59:20		Join GigaBrick [0] (~sagacious@67-5-126-32.spok.qwest.net)
03:00
03:04:22		Quit kadoban (Read error: Operation timed out)
03:13:03		Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au)
03:15:32		Quit Scromple (Ping timeout: 252 seconds)
03:22:07		Join Horschti [0] (~Horscht@xbmc/user/horscht)
03:23:44		Quit mgue (Ping timeout: 240 seconds)
03:25:32		Join mgue [0] (~mgue@p579826A3.dip.t-dialin.net)
03:25:57		Quit Horscht (Ping timeout: 276 seconds)
03:30:12		Quit liar (Quit: hallowed are the ori!)
03:42:39		Quit mgue (Ping timeout: 264 seconds)
03:43:17		Join mgue [0] (~mgue@p579826A3.dip.t-dialin.net)
03:54:35		Quit efyx (Ping timeout: 240 seconds)
03:54:52		Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
03:56:43	***	Saving seen data "./dancer.seen"
04:00
04:17:29		Quit amiconn (Disconnected by services)
04:17:30		Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:17:50		Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:18:47		Quit pixelma (Disconnected by services)
04:18:49		Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:18:51		Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
05:00
05:32:07		Join Rob2223 [0] (~Miranda@p5DE4BF02.dip.t-dialin.net)
05:35:19		Quit Rob2222 (Ping timeout: 252 seconds)
05:42:25		Quit Horschti (Quit: Verlassend)
05:56:47	***	Saving seen data "./dancer.seen"
07:00
07:08:59		Quit froggyman (Ping timeout: 240 seconds)
07:18:49		Join froggyman [0] (~seth@unaffiliated/froggyman)
07:19:11		Join froggyman_ [0] (~seth@50.105.151.180)
07:23:29		Quit froggyman_ (Client Quit)
07:42:38		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
07:56:49	***	Saving seen data "./dancer.seen"
07:56:52		Join sideral [0] (~sideral@rockbox/developer/sideral)
08:00
08:07:10		Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
08:09:58		Quit powell14ski (Quit: powell14ski)
08:14:14		Quit shai_ (Read error: Connection reset by peer)
08:14:43		Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
08:16:15		Join Rob2222 [0] (~Miranda@p5DE4BF02.dip.t-dialin.net)
08:17:49		Quit Rob2223 (Read error: Connection reset by peer)
08:18:37		Join Guest_13323 [0] (~antil33t@124-197-33-15.callplus.net.nz)
08:19:41		Join Zagor [242] (~bjst@rockbox/developer/Zagor)
08:22:11		Nick Guest_13323 is now known as antil33t (~antil33t@124-197-33-15.callplus.net.nz)
08:26:06		Quit kadoban (Remote host closed the connection)
08:28:07		Quit Keripo (Read error: Connection reset by peer)
08:31:38		Join Bagder [0] (~daniel@www.haxx.se)
08:31:38		Quit Bagder (Changing host)
08:31:38		Join Bagder [241] (~daniel@rockbox/developer/bagder)
08:39:37		Join ender` [0] (~ender@foo.eternallybored.org)
08:44:41		Quit GigaBrick (Remote host closed the connection)
08:45:28		Join GigaBrick [0] (~kenneth@67-5-126-32.spok.qwest.net)
08:58:30	GigaBrick	kugelp, was the "buffer_alloc(): exclusive buffer owner" panic gevaerts found with USB disconnect fixed already? Just happened for me in the current revision
08:59:45		Quit factor (Ping timeout: 240 seconds)
09:00
09:14:39	GigaBrick	http://www.rockbox.org/irc/log-20110815 at 15:03 is what I got... Is r30321 supposed to address that too or just on usb insert?
09:22:16		Join HaimN [0] (~quassel@95.86.116.121)
09:24:22		Join dfkt [0] (dfkt@unaffiliated/dfkt)
09:27:28		Join factor [0] (~factor@74.197.205.204)
09:28:17		Quit Scr0mple (Quit: Leaving)
09:29:22		Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09:41:02		Quit GeekShadow (Read error: Operation timed out)
09:41:16		Join n1s [0] (~quassel@rockbox/developer/n1s)
09:41:39		Join petur [0] (~petur@rockbox/developer/petur)
09:45:39		Join GeekShadow [0] (~antoine@101.158.21.93.rev.sfr.net)
09:50:06		Quit God_Eater (Ping timeout: 252 seconds)
09:52:32		Quit iq_ (Read error: Operation timed out)
09:56:50	***	Saving seen data "./dancer.seen"
09:59:23		Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
09:59:24		Quit bertrik (Changing host)
09:59:24		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
10:00
10:05:14		Join TheLemonMan [0] (~lem0n@ppp-139-57.26-151.libero.it)
10:10:41		Quit HaimN (Ping timeout: 252 seconds)
10:13:48		Quit GeekShadow (Ping timeout: 240 seconds)
10:16:07		Join GeekShadow [0] (~antoine@38.204.120.78.rev.sfr.net)
10:16:10		Quit factor (Read error: Connection reset by peer)
10:16:40	kugelp	GigaBrick: that one should be fixed
10:17:46	GigaBrick	:/ I just got it again with the latest svn
10:17:54	GigaBrick	This was the USB disconnect one though
10:22:11		Join God_Eater [0] (93722cc9@rockbox/staff/GodEater)
10:23:08		Quit GeekShadow (Ping timeout: 252 seconds)
10:25:17		Join GeekShadow [0] (~antoine@156.203.120.78.rev.sfr.net)
10:25:40	kugelp	GigaBrick: my commit should fix a panic on disconnect right
10:25:56		Quit antil33t ()
10:25:58	GigaBrick	I'll give it another try
10:26:14	GigaBrick	But when I tired the SVN tonight and disconnected I got the same panic message gevaerts posted originally
10:26:22	GigaBrick	The "exclusive buffer owner" one
10:26:27		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
10:28:21	gevaerts	GigaBrick: did you connect usb right after booting?
10:28:42	GigaBrick	Yeah, i was just going to mention that I waited until the disk activity icon stopped spinning
10:28:45	GigaBrick	And then plugged it in
10:29:01	gevaerts	hm, might be a different one then
10:29:14	GigaBrick	Well, I know it was right after I turned it on, but I know I also waited for the disk to settle
10:29:23	GigaBrick	I'll give it another shot to see if I can reproduce it
10:29:38		Quit antil33t (Client Quit)
10:30:03		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
10:30:55		Quit user890104 (Ping timeout: 240 seconds)
10:30:57	GigaBrick	Okay, got it again... Rebooted after upgrading it, waited for disk to settle, put USB back in, then took it out with the backlight still on
10:33:16		Join factor [0] (~factor@74.197.205.204)
10:33:38	GigaBrick	Got it again...
10:36:00		Quit antil33t ()
10:36:14	GigaBrick	gevaerts, after I played some music it won't do it again
10:36:21		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
10:37:12		Quit antil33t (Client Quit)
10:37:35		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
10:41:46		Join user890104 [0] (~Venci@6bez10.info)
10:42:47	GigaBrick	Weirder, now I can't reproduce it at all
10:43:06	GigaBrick	Not sure if that's good or bad. lol
10:54:07		Join iq [0] (~iq@unaffiliated/iq)
10:54:48		Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
11:00
11:02:38	GigaBrick	Well, I got it again, so, whatever is happening doesn't seem very consistent
11:04:55		Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net)
11:04:55		Quit pamaury (Changing host)
11:04:55		Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:07:54		Join swilde [0] (~wilde@aktaia.intevation.org)
11:11:22		Quit shai_ (Read error: Connection reset by peer)
11:11:48		Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il)
11:15:20	GigaBrick	gevaerts, does it happen to you on usb disconnect at all anymore?
11:15:45	gevaerts	No idea. I haven't disconnected USB with current svn
11:16:36	gevaerts	Can you add the patch at http://paste.debian.net/126486/ ? That should provide a bit more information in the panic message
11:17:19	GigaBrick	All right
11:23:04	GigaBrick	gevaerts, I got "buffer_alloc() : scrobbler_init:251 exclusive buffer owner"
11:23:11		Join dunkaist [0] (~dunkaist@bp-203-179.dialup.vitebsk.by)
11:23:37	GigaBrick	Oh, that makes sense why it stopped reproducing
11:23:50	GigaBrick	I turned the Last.fm log off anticipating a lot of crashes
11:23:58	GigaBrick	That's when the panics stopped too...
11:25:03	gevaerts	GigaBrick: maybe a silly question, but is the panic text wrapped?
11:25:17	GigaBrick	Meaning it starts on a new line?
11:25:21	GigaBrick	Yes
11:25:53	gevaerts	kugel: do you mind if I commit that patch so these panics get easier to trace?
11:26:07	gevaerts	Or will it mess up your tree too much?
11:26:27	GigaBrick	gevaerts, it wraps at "...lusive buffer owner" if that's helpful to know
11:26:28	kugel	gevaerts: yes
11:26:46	kugel	it messes up my tree, and it will be obsolete
11:26:59	kugel	because with buflib it doesn't panic anymore
11:27:05	gevaerts	ah, ok
11:27:21	*	gevaerts isn't awake, clearly :)
11:27:33	gevaerts	I forgot. That's what buflib is for...
11:27:56	kugel	:)
11:28:15	GigaBrick	Well, I was right about disabling the last.fm log making the panic stop
11:28:47	GigaBrick	So I'm guessing there's a function called scrobbler_init that's to blame?
11:29:55	gevaerts	Yes, or that area anyway
11:31:18	kugel	I'll have a look in a few minutes
11:32:26		Quit mudd1 (Ping timeout: 252 seconds)
11:38:02		Quit dunkaist (Quit: leaving)
11:38:40		Quit GigaBrick (Remote host closed the connection)
11:42:15		Join GigaBrick [0] (~sagacious@67-5-126-32.spok.qwest.net)
11:43:27	GigaBrick	I miss anything?
11:52:27	kugel	gevaerts: scrobbler cache is re-allocated after usb extraction (and scrobbler is shut down on insertion)
11:52:54	kugel	I assume it's to free memory for usb but it doesn't make a lot of sense
11:53:10		Join FBI_Guy [0] (~fbiguy@pool-96-233-107-20.bstnma.fios.verizon.net)
11:55:22	kugel	because audiobuf isn't reset back, it still points to whatever audio it was set to. e.g. right after the scrobbler buffer if scrobbler was the last allocation
11:56:31	kugel	hm, I suspect the shutdown is rather to force flushing of the last.fm logs, but that's also handled already by the ata idle callbacks
11:56:53	***	Saving seen data "./dancer.seen"
11:59:48		Quit ruskie (Ping timeout: 240 seconds)
12:00
12:00:19	*	kugel would propose this patch http://pastie.org/2385162
12:00:58	kugel	GigaBrick: that should fix it
12:01:07	GigaBrick	Okay, I'll give it a try
12:01:44		Part Zagor
12:01:55	kugel	gevaerts: the ata notify callbacks always work, no? or is there some trick?
12:02:00		Join Zagor [242] (~bjst@rockbox/developer/Zagor)
12:02:03	kugel	like it doesn't do anything on flash
12:03:46	gevaerts	As far as I know they should always work
12:04:36	kugel	so the patch relies on that callback to flush last.fm log to disk on usb
12:04:44	kugel	and stops the stupid re-allocation
12:06:03	kugel	my mail to -dev didn't catch a lot of attention yet :(
12:09:04	GigaBrick	Well
12:09:08	GigaBrick	I don't get that panic
12:09:19	GigaBrick	But now after disconnecting the usb I get "Error accessing plyalist control file"
12:09:24	GigaBrick	Then "Invalid control file"
12:10:27	GigaBrick	Then when I try to build the playlist again it says it can't update the control file
12:11:05	kugel	is that when you played music before usb?
12:11:33	GigaBrick	Yeah
12:11:49	GigaBrick	Well, I rebooted and can load playlists and stuff now
12:11:57	GigaBrick	Though looks like I ran into that database duplication thing
12:12:01	GigaBrick	Because now I have double of everything
12:12:31	kugel	:'(
12:13:17	GigaBrick	Yeah, I've seen that "Error accessing playlist control file" before
12:13:25	GigaBrick	But it always loads after I try it again
12:13:36	GigaBrick	Haven't seen it say Invalid before
12:13:52	kugel	is that also reproducable?
12:14:01	GigaBrick	Yeah
12:15:47	kugel	I'm not sure that's caused by my recent changes
12:15:59	GigaBrick	I don't think so
12:16:09	GigaBrick	I think it's related to the issue gevaerts fixed
12:16:26	GigaBrick	Because I notice it only does it when it would panic ( well, now instead of panicing it pauses for a second)
12:16:59	gevaerts	GigaBrick: try increasing that sleep time a bit more, maybe?
12:17:41	GigaBrick	Okay
12:17:43	GigaBrick	I'll give that a try
12:17:51	GigaBrick	I have to let my database re-initalize right now though
12:17:59	GigaBrick	PIty, I just rated a bunch of songs :(
12:20:37	sideral	GigaBrick: Try exporting the DB data before regenerating it
12:20:45	sideral	there's a good chance the data can be recovered
12:21:02	GigaBrick	Yeah, I considered that only after hitting "Initialize"
12:21:06	GigaBrick	So too late now heh
12:21:18	sideral	Also, please log the steps that led to the duplication to FS #12129
12:21:19	fs-bluebot	http://www.rockbox.org/tracker/task/12129 3Duplicate database entries (bugs, unconfirmed)
12:21:39	sideral	Did you interrupt a DB update with a reboot?
12:22:09	GigaBrick	No, it was related to an error acessing the playlist control file
12:22:12	FBI_Guy	is there a way to copy replaygain info from file to file without replacing the entire file?
12:22:51	sideral	GigaBrick: interesting...
12:22:59	GigaBrick	Yeah, I'm not really sure what happened to be honest
12:23:14	sideral	I don't really understand when that error can actually occur
12:23:33	sideral	Perhaps it's related to a dircache shutdown
12:24:01	GigaBrick	We were working through an unrelated panic from scrobbler.c I got when disocnnecting from USB... When it tried to resume I got "Error accessing playlist control file", which I've seen before, but usually can just resume... THis time it said "Invalid control file" and then wiped the playlist, so then when I tried it said "Nothing to resume"
12:24:34	sideral	(Just a guess because Slasheri and I recently fixed two bugs related to that in the playlist and DB code; there may be more lurking around)
12:24:35	GigaBrick	So then once that happened I went to my database to reload the playlist, and when I clicked I got the message "~9000 found" and knew it was dup'ing because my collection is only about 5000 tracks
12:25:49	sideral	When that happens next time, could you please check the database and dircache status pages in the debug menu?
12:25:57	GigaBrick	Okay
12:26:08	GigaBrick	The "Error accessing control file" is fairly reproducable though
12:26:13	GigaBrick	So I can probably check that right now
12:26:15		Join metaphys [0] (~5470130d@giant.haxx.se)
12:26:49	sideral	Do you have DB auto-update enabled, BTW?
12:26:56	Llorean	FBI_Guy: I'm not even sure what you think you're asking, honestly. Replaygain info is unique to either the track or album anyway, and it's just metadata. I can't even imagine why you'd need to "replace" a file anywhere in the replaygain process.
12:27:01	gevaerts	GigaBrick: try checking the filesystem. You've had so many panics recently that I'm not entirely convinced that that's still going to be clean
12:27:12	GigaBrick	Yeah, sideral
12:27:38	GigaBrick	Good idea, gevaerts
12:28:11	GigaBrick	sideral, I've got the dircache debug page open
12:28:19	GigaBrick	After getting the "Error accessing playlist control file" splash
12:28:29	sideral	is the dircache still enabled?
12:28:53	GigaBrick	Says "Cache initialized: Yes" if that means yes
12:29:01	sideral	yeah, that's what I meant
12:29:09	GigaBrick	k
12:30:10	sideral	and what does the DB debug menu say?
12:30:21	sideral	first three lines?
12:30:38	GigaBrick	"Intialized: yes, DB Ready: Yes, RAM Cache: Yes"
12:31:01	GigaBrick	Also, under progress it says 87% (9145 entries)
12:31:10	GigaBrick	Does that mean it duped again?
12:31:43	sideral	No idea −− you'll have to check in the DB browser
12:31:44	GigaBrick	Or maybe that's all still loaded in RAM from before I re-initialized?
12:31:49	GigaBrick	Okay
12:32:07	Slasheri	found entries does not correlate to the number of tracks
12:32:07	GigaBrick	Nah, doesn't seem like it duped again
12:32:27	Slasheri	it includes every file and directory on the player
12:32:40	GigaBrick	Oh, okay
12:32:51	sideral	Looks like everything is fine and dandy this time. But you didn't add/remove files over USB this time around, right?
12:32:55	GigaBrick	Just coincidence it happened to be almost twice my collection
12:32:55		Join JacekNiesobski [0] (~1faedb6e@giant.haxx.se)
12:32:58	Slasheri	(maybe a good idea to change it to include just tracks)
12:33:23	GigaBrick	Nope, sideral, just connected then disconnected
12:33:36	JacekNiesobski	hello everyone
12:34:00	GigaBrick	gevaerts, looks like you were right
12:34:12	GigaBrick	Just fsck'd and ./.rockbox/.playlist_control got flagged
12:34:22	sideral	GigaBrick: So the playlist error is probably unrelated to the DB problem −− if there ever was any (you did observe dupes in the DB browser, right? or was it just the 9000 that confused you?)
12:34:37	GigaBrick	No, I definitely saw the dupes in the database
12:34:49	GigaBrick	But I think the playlist thing is unreleated since I just found the filesystem dirty
12:34:57	sideral	alright
12:35:17	JacekNiesobski	can I ask to be added to the WikiUsersGroup?
12:36:33	sideral	GigaBrick: Slasheri and I have a theory about the dupe issue (double commit into a dirty database). I now have a filesystem copy from someone who ran into it (and also FS #12228, which may be related), and hope to be able to reproduce the issue now.
12:36:34	fs-bluebot	http://www.rockbox.org/tracker/task/12228 3Database fails to commit on Fuze v2 fresh SVN build (bugs, unconfirmed)
12:37:36		Join MethoS- [0] (~clemens@134.102.106.250)
12:37:37	GigaBrick	Haven't ran into anything like 12228
12:37:50	GigaBrick	Anything helpful I can do if I get the duplication again?
12:37:54	GigaBrick	LIke specifically what to note down?
12:38:01	FBI_Guy	Llorean: sorry for late response :P, but i mean is there a way to copy the replaygain metadata so i dont have to replace the songs i already have on my player which dont have replaygain info with the ones from my computer which now do
12:38:08	sideral	GigaBrick: But if you have a recipe for reproducing it, I'd still be grateful if you posted it to FS #12129
12:38:09	fs-bluebot	http://www.rockbox.org/tracker/task/12129 3Duplicate database entries (bugs, unconfirmed)
12:38:13		Quit JacekNiesobski (Quit: CGI:IRC)
12:38:36	sideral	GigaBrick: Yeah, try to remember the exact steps that lead to it, and attach a copy of your DB to the tracker item
12:38:47	GigaBrick	Okay, will do if it happens again
12:38:50	sideral	that is, all /.rockbox/database. files
12:39:02	sideral	cool, thanks!
12:39:20	GigaBrick	Yeah, this time was so mixed with other things I'm not really sure it'd be any help to recall exactly what happened
12:39:42	GigaBrick	Or if I really could
12:39:52	sideral	Slasheri: Have you seen the dircache-related "crazy idea" session I tortured everyone with two nights ago?
12:40:34	GigaBrick	I think I read through that
12:40:39	GigaBrick	Please don't nix the db, <3 the db
12:41:01	sideral	Slasheri: Might be an entertaining read: http://www.rockbox.org/irc/log-20110816#00:01:31
12:41:37	Slasheri	sideral: hehe, i read that =)
12:42:54	Slasheri	sideral: in fact, i thought about block cache implementation before implementing the dircache :)
12:43:13	sideral	GigaBrick: No one plans to remove it, no worries :)
12:43:45	GigaBrick	Heh, okay, just had to get that out there since there doesn't seem to be a lot of love for it
12:44:15	sideral	Yeah, it's probably the best solution. I do worry about the complexity of its interface for clients, though, especially when the dircache shuts down
12:45:14	sideral	Perhaps an alternative idea would be to hide the dircache behind the filesystem interface and just offer an interface for retrieving the filename of an "inode" (aka dircache ID)
12:45:31		Join ruskie [0] (ruskie@sourcemage/mage/ruskie)
12:45:34		Join Rob2223 [0] (~Miranda@p5DE4BA36.dip.t-dialin.net)
12:47:28	GigaBrick	sideral,
12:47:34	GigaBrick	Just reproduced the db duplication I had earlier
12:48:39	sideral	GigaBrick: dang, there goes my after-lunch nap ;)
12:48:48	GigaBrick	Disconnected USB, had the "Error accessing playlist control file" splash, tried to resume again anyway, got "Invalid control file" splash so then I went to load a new playlist and got "Error updating control playlist" and the player hung up hard
12:48:53	GigaBrick	Would not retrun to main menu or even power down
12:48:56	GigaBrick	So I had to flip the battery
12:49:04		Quit Rob2222 (Ping timeout: 252 seconds)
12:49:06	GigaBrick	Loaded the device on usb and checked my filesystem to make sure that wasn't it again
12:49:23	GigaBrick	Filsystem was clean, so I started it again, the playlist contro file loaded the playlist I had just tried and started playing
12:49:26	Llorean	FBI_Guy: Whatever tool scanned them on your PC should also be able to scan them on your player.
12:49:30	GigaBrick	But then when I went to check the database, duplicates
12:49:45	GigaBrick	One thing I noticed that when it was hung, the disk was doing an awful lot
12:50:07	FBI_Guy	Llorean: yeah but that takes forever :P (sorry if this is the wrong place ro be asking)
12:50:50	sideral	GigaBrick: OK, please add a comment containing the steps and a copy of your DB to the tracker task
12:51:07	GigaBrick	Okay
12:51:10	Llorean	FBI_Guy: Typically tagging tools are not designed to identify duplicate songs and match the tags between them. So you'll either need to copy them over, or re-scan
12:51:13	sideral	ah, before you shut down
12:51:35	sideral	can you check in the FS browser whether everything looks OK?
12:51:36	GigaBrick	Yeah, I've got the .rockbox dir open
12:52:09	FBI_Guy	Llorean: alright, thanks, I guess ill just scan again
12:53:11	sideral	GigaBrick: enable "view all" in the file browser, and look out for strange file or dir names in the root directory
12:53:40	GigaBrick	Okay
12:53:41		Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
12:53:44	GigaBrick	Everything looks right
12:54:04	sideral	OK, that rules out the dircache corruption issue we've had a few revisions ago
12:54:26	sideral	which could lead to loops in the dir hierarchy, which in turn lead to duplicates
12:54:42	GigaBrick	Hmm, interesting....
12:54:49	GigaBrick	I copied my db before checking the files
12:54:57	GigaBrick	SO when I disconnected I got "Error accessing playlist control file" again
12:55:15	GigaBrick	I thought I'd try to reproduce the whole thing again just for kicks and loaded a playlist, but it worked fine this time
12:55:32	GigaBrick	Only difference I can see is that before I inserted the USB while music was playing, this time it was inserted from the main menuy
12:55:34		Quit metaphys (Quit: CGI:IRC (Ping timeout))
12:55:36	GigaBrick	-y
12:56:35	sideral	that's probably an unrelated issue, but worth mentioning in the FS comment anyway
12:56:52	GigaBrick	Yeah
12:56:56	sideral	Maybe you should report a separate bug for this behavior as well
12:57:06	GigaBrick	In fact I ran into the duplication while trying to figure out why the playlist control file was doing that
12:57:18	GigaBrick	I know it's related to a panic that gevaerts fixed
12:57:47	GigaBrick	Had to add a 100 ms delay before the disk mounted again after leaving usb mode, or else it would panic because nothing was mounted
12:58:02	GigaBrick	Well, the only times I get the "Error accessing control playlist file" are times that it would otherwise panic without that sleep
12:58:08	GigaBrick	So there's something else going on there
12:58:35	sideral	sound like kind of a crude workaround
12:59:02	GigaBrick	Heh, can't comment, it stops it from panic'ing at least
12:59:27	GigaBrick	But I think a similar thing is happening where the playlist is trying to be resumed but there's problems acessing the disk
13:00
13:00:01	GigaBrick	Mainly basing that off the fact that I only get the playlist control access error on disconnects that would have caused the panic, so it seems fairly related
13:01:19	*	sideral need to go offline now
13:01:27	sideral	I'll check FS later
13:01:39	sideral	thanks GigaBrick for helping to nail this one down!
13:01:57	GigaBrick	Np
13:02:04	GigaBrick	You still want me to add those steps I took to the FS right?
13:02:22	sideral	yes, please
13:02:59	GigaBrick	Okay... Still have the link in your clipboard, having trouble finding it in the history
13:04:42	GigaBrick	Nvm, found it
13:07:20		Join HaimN_ [0] (~quassel@95.86.116.121)
13:08:26	kugel	"Perhaps an alternative idea would be to hide the dircache behind the filesystem interface and just offer an interface for retrieving the filename of an "inode" (aka dircache ID)
13:08:46	kugel	" <−− how is this different from now?
13:08:51	kugel	sideral: ^
13:09:24	kugel	this is exactly how dircache currently works isn't it?
13:09:35	Torne	pretty much :)
13:10:56	kugel	dircache is completely transparent behind opendir and friends, additionally one can exploit the cache by getting dircache IDs and from that the filename
13:11:16	*	kugel must be missing something
13:16:18	GigaBrick	Ugh, my forgetfulness is making a mockery of this FS page...
13:22:08		Join XavierGr [0] (~xavier@rockbox/staff/XavierGr)
13:22:16	GigaBrick	kugel, is there anything you can think of in the scrobbler patch you made that would cause the database to rebuild itself like this?
13:22:31	kugel	no
13:23:38	GigaBrick	Weird
13:23:46	GigaBrick	I wonder why I keep getting the "Error accessing playlist control file"
13:24:14	GigaBrick	Because it seems to all happen after that. Once I click that flash away I get "Invalid control file" and then the splash that pops up when you update the database saying 9000 something found...
13:24:39	GigaBrick	Weird difference this time though... When I powered down and checked the database for duplicates, instead of finding duplicates it asked to initialize it
13:27:01		Join CoLdAsSauLt [0] (~c1befd92@giant.haxx.se)
13:27:04	CoLdAsSauLt	Hi
13:27:15	CoLdAsSauLt	can I please get some help on patching Rockbox?
13:27:34	CoLdAsSauLt	I installed GnuWin32...
13:27:35	CIA-14	New commit by 03kugel (r30325): Fix panic after usb extraction if lastfm logging is enabled. ...
13:27:38	CoLdAsSauLt	but now what ^^
13:27:58	GigaBrick	Okay, this is getting really weird now... I just picked up the gigabeat after hitting Initiali database to rebuild my database
13:28:09	GigaBrick	I have the "Error accessing playlist control file" splash
13:29:10	GigaBrick	kugel, I'm going to try reverting to my 30295 build and apply the scrobble patch and see if I still get this behavior, does that sound like it will be helpful at all in determining what might be causing it?
13:29:20	kugel	GigaBrick: does this happen automatically or do you try tor esume playback?
13:29:29	GigaBrick	This appeared to happen automatically
13:29:37	GigaBrick	I was still in the settings menu for database
13:29:46	kugel	very strange
13:29:59	CIA-14	r30325 build result: All green
13:30:55	kugel	normally the playlist control file is only accessed when you stop or resume playback, or when you edit the playlist in the playlist viewer
13:30:56		Quit merbanan (Ping timeout: 258 seconds)
13:31:21	GigaBrick	Would the system automatically try to resume playback?
13:31:37	GigaBrick	I mean, that's the first thing I thought of but it seems strange it would do that from the settings menu
13:32:34	kugel	no it shouldn't do that AFAIK
13:33:58		Join merbanan [0] (~banan@c-62-220-165-114.cust.bredband2.com)
13:34:10	CoLdAsSauLt	somebody willing to help me out? Sorry for my lack of technical knowledge :s
13:35:22	Bagder	CoLdAsSauLt: you probably want to build rockbox after you've pathed it, so follow the docs to setup a dev environment
13:36:11		Quit HaimN_ (Remote host closed the connection)
13:38:54	GigaBrick	kugel, I just patched 30295 with your scrobbler patch and I'm not seeing the same behavior
13:39:28	GigaBrick	No error on playlist control file access or duplication or anything
13:43:30		Quit merbanan (Ping timeout: 276 seconds)
13:47:06		Join merbanan [0] (~banan@c-62-220-165-114.cust.bredband2.com)
13:50:05	kugel	GigaBrick: what kind of playlist did you have?
13:50:11	kugel	playing an m3u by chance?
13:50:25	GigaBrick	Yeah, this time around
13:50:34	GigaBrick	But most of the time I have a dynamic playlist
13:50:41	kugel	I see a possible code path for your problem
13:51:00	GigaBrick	Does it still apply if I get this behavior when using dynamic playlists too?
13:51:05	kugel	can you repro this with a dynamic playlist?
13:51:28	pamaury	gevaerts: I thought we had a define for player with no high speed usb
13:51:42	GigaBrick	kugel, yeah, happens with either type
13:52:24	pamaury	I found USB_NO_HIGH_SPEED but it seems to be unused
13:52:45	kugel	GigaBrick: can you check if the playlist control thread is active (in view OS stacks debug menu)?
13:53:09	GigaBrick	After I repro or just right now?
13:53:17	gevaerts	pamaury: yes, I don't think there's more. That was basically debug code
13:53:38	pamaury	so all players have high speed usb or hardware usb bridge ?
13:54:08	gevaerts	As far as I know, yes
13:54:16	gevaerts	Well, up to now anyway
13:54:31	kugel	GigaBrick: after you repro
13:54:35	gevaerts	Do we care actually, outside of the driver?
13:55:00	GigaBrick	Okay, I'll have to put the current revision back on
13:55:20	pamaury	gevaerts: in the core, for the descriptors
13:55:47	pamaury	we report as 1.1 usb when we don't have high speed
13:55:58	pamaury	but that's not mandatory iirc
13:56:09	gevaerts	Ah, yes, the other speed config
13:56:57	***	Saving seen data "./dancer.seen"
13:57:28	gevaerts	I'd say this is something to do when we actually have a target where it matters
13:58:19	pamaury	I have a FS only device
13:58:29	gevaerts	Ah, you have some work to do then :)
13:59:05	pamaury	I'm not sure what needs to change,the only use of USB_NO_HIGH_SPEED us the bcdUSB field andI think you can report 2.00 for a FS device
13:59:55	gevaerts	I'm not sure either. This is a long time ago...
14:00
14:00:31	pamaury	found: If a full-speed only device (with a device descriptor version number equal to 0200H) receives a
14:00:31	pamaury	GetDescriptor() request for a device_qualifier, it must respond with a request error. The host must not make
14:00:31	pamaury	a request for an other_speed_configuration descriptor unless it first successfully retrieves the
14:00:31	DBUG	Enqueued KICK pamaury
14:00:31	pamaury	device_qualifier descriptor.
14:01:00	gevaerts	right, I think we don't do that yet
14:01:21	gevaerts	I suspect that's all there is to it
14:03:19	pamaury	so in fact we could probably keep the current code, assume the host don't request device_qualifier and always use 2.00 version. In fact there is not need to disctinction
14:07:00	pamaury	Except for packet size: bulk is 64 at FS
14:07:19	pamaury	but that's already handled anyway
14:08:21	GigaBrick	kugel, I got the "Erorr accessing playlist control file" to reproduce
14:08:33	GigaBrick	Checked the playlistcachectrl thread and didn't see much of anything
14:08:41	GigaBrick	Changed from T to something, but went so fast I didn't see what it changed to
14:12:42	GigaBrick	Weird, now it's showing the splash while the playlist is actually playing on the WPS screen
14:12:51	GigaBrick	And now it's showing it in the debug menu when I went to check on that thread
14:13:19	GigaBrick	Except now it's doing something weird where it shows up briefly and disappears... :/
14:14:02	gevaerts	pamaury: the host will ask for the device_qualifier. If it does, though, the worst that happens is that windows tells you that a different port might be faster. Returning an error there (for FS-only devices) is probably a good idea in the long term
14:16:23	pamaury	okay, I'll do that
14:17:16		Join Rob2222 [0] (~Miranda@p4FFF0504.dip.t-dialin.net)
14:17:33	kugel	GigaBrick: I just wanted to know if it's there
14:17:43	kugel	can you disable dircache and see if it persists?
14:18:02	GigaBrick	Yeah, I'll try that
14:20:14	GigaBrick	Where is that setting located again?
14:20:46	GigaBrick	Oh, under Disk, nvm
14:21:03		Quit Rob2223 (Ping timeout: 250 seconds)
14:23:33	GigaBrick	kugel, only got it to reproduce once with dir cache off, just disconnected 5 times in a row now without the playlist control splash
14:23:56	kugel	did you reboot?
14:24:20	GigaBrick	No, should I?
14:25:02	kugel	you can try
14:25:29	GigaBrick	Okay, I'll reboot and give it a try too
14:26:20	GigaBrick	Yeah, seems to eliminate that splash when dir cache is off
14:26:45	kugel	:\
14:27:01	kugel	thanks for your debugging, I'll have a look later
14:27:37	GigaBrick	Also, I thought I should mention
14:27:56	GigaBrick	I applied the sleep patch and the scrobbler patch to 30307
14:27:58	kugel	the playlist control thread tries to fetch dircache ids in the background for the filenames, that seems to fail
14:28:05	GigaBrick	STill got the playlist splash
14:28:10	GigaBrick	But for some reason in 30295 I don't
14:28:17	kugel	oh interesting
14:29:22	GigaBrick	Yeah, I haven't seen what's the highest revision I can go to yet without reproducing, but I figured I'd try that and that might answer something
14:29:27	kugel	not sure what commit can cause that then
14:30:07	kugel	you did try bumping the sleep time higher in the sleep patch, didn't you?
14:30:22	GigaBrick	Yeah, I had it up to a full second and it didn't make a difference
14:30:27	GigaBrick	Didn't know if I should try any higher though
14:30:39	GigaBrick	Well, a full HZ (I'm assuming that's a second)
14:31:26	kugel	that's a second yes
14:31:56	GigaBrick	Hertz is rolling in his grave at my unsuredness. :P
14:32:52	GigaBrick	Anyway, I suppose I can go up the revisions incrementally from 30295 until I find which one starts reproducing the behavior
14:33:06	kugel	that would be fine :)
14:33:46	GigaBrick	Oh, one quesiton about svn updating
14:33:57	GigaBrick	How can I get it to actually replace a file that has custom modifications?
14:34:35	kugel	not at all
14:34:40	kugel	you need to undo the modifications
14:34:47	GigaBrick	Oh, all right
14:34:49	kugel	e.g. svn revert
14:35:22	GigaBrick	Oh, come to think of it, is there a way to revert back to a specific revision?
14:35:32	GigaBrick	I should probably just man svn...
14:35:56	kugel	svn up -rXXXX
14:37:31	GigaBrick	Oh, cool, it takes care of the changed files too
14:37:37	GigaBrick	All right, that will make this go a lot faster
14:38:29	kugel	it doesn't touch modifications. it tries to merge and abort the update if it doesn't manage
14:38:56	GigaBrick	Hmm... It just replaced my patched ./firmware/usb.c with the one from the svn
14:39:50	kugel	well, it would be news to me if it does that. but I haven't used svn in a long time
14:40:05	GigaBrick	Yeah, I have barely ever used it
15:00
15:18:36	GigaBrick	kugel, I must have done something wrong before, I just tried 30307 and I didn't get the playlist splash
15:21:41		Quit CoLdAsSauLt (Quit: CGI:IRC (Ping timeout))
15:46:01		Join FBIGuy [0] (~fbiguy@pool-96-233-107-20.bstnma.fios.verizon.net)
15:46:01		Quit FBI_Guy (Read error: Connection reset by peer)
15:49:31		Join ntkm [0] (~taku@bmdk6141.bmobile.ne.jp)
15:50:44		Quit ntkm (Client Quit)
15:56:21		Join CoLdAsSauLt [0] (~c1befd92@giant.haxx.se)
15:56:34	CoLdAsSauLt	Do I really have to rebuild rockbox, just to apply a patch?
15:56:53	Bagder	no, but you won't get a rockbox to install unless you build it...
15:56:58	***	Saving seen data "./dancer.seen"
15:57:50	CoLdAsSauLt	mm, so the way to go is
15:58:00	CoLdAsSauLt	installing linux
15:58:08	CoLdAsSauLt	which I have already done, virtualbox)
15:58:42	CoLdAsSauLt	and rebuilding it there
15:58:54	CoLdAsSauLt	patching an already installed rockbox isn't possible?
15:59:02	CoLdAsSauLt	I 'm running it on a Cowon D2)
15:59:19	Bagder	patches are little changes to source code
15:59:39	Bagder	or sometimes big changes...
15:59:45	CoLdAsSauLt	heheh
16:00
16:00:23	Bagder	but still source code, and once you have applied a patch, you have modified the source code, and then you want that modified source code to get turned into a rockbox install for you
16:00:39	CoLdAsSauLt	okay
16:01:03	CoLdAsSauLt	I'm a music lover
16:01:11	CoLdAsSauLt	but nowhere a programmer :)
16:01:30	CoLdAsSauLt	so it's kind of overwhelming
16:01:50	CoLdAsSauLt	when reading through the patch pages
16:02:22		Quit antil33t (Read error: Connection reset by peer)
16:02:42		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
16:03:47		Quit shai_ (Ping timeout: 240 seconds)
16:22:22		Join mshathlonxp [0] (~amdk7powe@027d5fc9.bb.sky.com)
16:38:16		Quit XavierGr (Read error: Connection reset by peer)
16:38:40		Join XavierGr [0] (~xavier@rockbox/staff/XavierGr)
16:39:26		Quit Rob2222 (Quit: Rob2222)
16:41:37		Quit GigaBrick (Ping timeout: 240 seconds)
16:56:00		Join GigaBrick [0] (~sagacious@67-5-101-98.spok.qwest.net)
17:00
17:01:46		Quit petur (Quit: plop)
17:04:21	wodz	Is buffer passed to sd_read_sectors() alligned?
17:08:56	gevaerts	Not in general
17:09:35	gevaerts	Performance-critical code does align it, but that's not what you mean I guess
17:09:59		Quit Bagder (Quit: Konversation terminated!)
17:11:41	wodz	even word aligned on ARM?
17:12:59	gevaerts	hm, I'm not sure actually now. It depends on what the FAT code does
17:18:31	wodz	How to build single plugin (or only test plugins)?
17:19:32		Quit antil33t (Read error: Connection reset by peer)
17:19:52		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
17:19:57		Join petur [0] (~petur@rockbox/developer/petur)
17:20:50		Part Zagor
17:49:32		Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
17:56:59	***	Saving seen data "./dancer.seen"
17:57:29		Join y4n [0] (y4n@unaffiliated/y4ndexx)
18:00
18:00:15		Join saratoga [0] (9803ec71@rockbox/developer/saratoga)
18:07:04		Quit wodz (Quit: Leaving)
18:10:56		Quit Stummi (Quit: Bye!)
18:11:09		Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
18:11:18		Quit petur (Quit: plop)
18:12:40		Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
18:13:17		Quit user890104 (Read error: Connection reset by peer)
18:14:31		Join user890104 [0] (~Venci@6bez10.info)
18:18:06		Join mystica555 [0] (~mike@173-108-203-0.pools.spcsdns.net)
18:23:37		Quit mystica555 (Ping timeout: 276 seconds)
18:28:09		Join mystica555 [0] (~mike@173-108-203-0.pools.spcsdns.net)
18:32:46		Join T44 [0] (~Topy44@f048235017.adsl.alicedsl.de)
18:36:28		Quit Topy (Ping timeout: 250 seconds)
18:41:30		Quit mystica555 (Ping timeout: 264 seconds)
18:43:56		Join dunkaist [0] (~dunkaist@bp-203-171.dialup.vitebsk.by)
18:45:53		Quit dunkaist (Client Quit)
18:51:26		Join Amadiro [0] (~Amadiro@ti0021a380-dhcp3462.bb.online.no)
18:51:39		Join lorenzo92 [0] (~chatzilla@host152-110-dynamic.30-79-r.retail.telecomitalia.it)
18:51:41		Join Rob2222 [0] (~Miranda@p4FFF299C.dip.t-dialin.net)
18:51:54		Quit lorenzo92 (Client Quit)
18:52:48		Quit swilde (Remote host closed the connection)
19:00
19:01:33		Quit TheLemonMan (Quit: .)
19:06:15		Quit XavierGr (Read error: Connection reset by peer)
19:06:24		Join XavierGr [0] (~xavier@rockbox/staff/XavierGr)
19:10:42		Quit XavierGr (Ping timeout: 250 seconds)
19:10:50		Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
19:12:50		Join dunkaist [0] (~dunkaist@86.57.183.39)
19:37:18		Quit bluebrother (Disconnected by services)
19:37:20		Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
19:39:05		Join Horscht [0] (~Horscht@p57B57352.dip.t-dialin.net)
19:39:05		Quit Horscht (Changing host)
19:39:05		Join Horscht [0] (~Horscht@xbmc/user/horscht)
19:40:36		Quit fs-bluebot (Ping timeout: 250 seconds)
19:41:43		Join fs-bluebot [0] (~fs-bluebo@g225252014.adsl.alicedsl.de)
19:41:54		Join lixxus [0] (~Mehdi@94-193-41-177.zone7.bethere.co.uk)
19:42:14	lixxus	anyone interested in buying a toshiba gigbeat s 30gb ?
19:42:49		Join stoffel [0] (~quassel@p57B4C0C7.dip.t-dialin.net)
19:50:39		Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
19:51:49		Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
19:57:01	***	Saving seen data "./dancer.seen"
19:59:40	wodz	I get Data abort at the address of the plugin__start when loading plugin - what may cause this?
20:00
20:02:25		Quit Horscht (Ping timeout: 276 seconds)
20:04:49		Join Horscht [0] (~Horscht@p57B57C4F.dip.t-dialin.net)
20:04:49		Quit Horscht (Changing host)
20:04:49		Join Horscht [0] (~Horscht@xbmc/user/horscht)
20:06:49		Join XavierGr [0] (~xavier@rockbox/staff/XavierGr)
20:07:00		Join ChickeNES [0] (~ChickeNES@rouxbicon.rh.uchicago.edu)
20:09:48		Join ibhan [0] (~yaaic@79.138.168.113.bredband.oister.dk)
20:10:04		Quit ibhan (Remote host closed the connection)
20:10:43		Join ibhan [0] (~yaaic@79.138.168.113.bredband.oister.dk)
20:10:43		Quit antil33t (Read error: No route to host)
20:11:26		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
20:11:32		Quit ibhan (Remote host closed the connection)
20:19:06		Quit user890104 (Read error: Connection reset by peer)
20:20:14		Join user890104 [0] (~Venci@6bez10.info)
20:37:47		Join [fred] [0] (fred@ircop.efnet.at)
20:54:13		Quit wodz (Quit: Leaving)
20:54:35		Quit knittl (Ping timeout: 260 seconds)
20:54:35		Quit Staphylo (Ping timeout: 260 seconds)
20:54:36		Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net)
20:55:07		Join knittl [0] (~knittl@unaffiliated/knittl)
20:56:33		Quit stoffel (Remote host closed the connection)
21:00
21:03:34		Quit kadoban (Remote host closed the connection)
21:07:17		Join Staphylo [0] (staphylo@hyperion.epimeros.org)
21:09:01		Quit sideral (Remote host closed the connection)
21:10:22		Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
21:12:39		Join sideral [0] (~sideral@rockbox/developer/sideral)
21:16:48		Join stoffel [0] (~quassel@p57B4C0C7.dip.t-dialin.net)
21:20:37		Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
21:23:11	bluebroth3r	niiiice :)
21:23:26	Ctcp	Ignored 1 channel CTCP requests in 0 seconds at the last flood
21:23:26	*	bluebroth3r stumbled across the LaTeX silence package: http://www.ctan.org/tex-archive/macros/latex/contrib/silence
21:29:57	bluebroth3r	argh, had some other output filter active. Doesn't work the way I thought :(
21:32:59	wodz	\o/ - I was able to run test_codec on rk27xx :-)
21:36:54	wodz	so, arm7ej-s gives 51.29MHz for realtime to decode mp3 cbr 128
21:38:36		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
21:43:34		Quit stoffel (Remote host closed the connection)
21:44:30		Join Buschel [0] (~chatzilla@p54A3BF0D.dip.t-dialin.net)
21:45:57	Buschel	which is quite a lot to decode mp3...
21:46:01	Buschel	slow RAM?
21:46:34	Buschel	S5L8701 (ARM940T) shows similar results formp3
21:49:38		Join Strife89 [0] (~Strife89@207.144.201.128)
21:54:27		Quit factor (Read error: Connection reset by peer)
21:57:04	***	Saving seen data "./dancer.seen"
22:00
22:10:42		Join factor [0] (~factor@74.197.205.204)
22:12:05		Quit antil33t (Ping timeout: 240 seconds)
22:12:31		Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz)
22:12:45		Quit XavierGr ()
22:13:21	*	pamaury curses the usb controller of the s3c2440
22:13:47		Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!)
22:15:44	pamaury	the fucking manual sounds like it was written by someone who doesn't know how does it work and which features is has !
22:16:02	pamaury	(the s3c2440 manual)
22:17:09		Part lixxus
22:22:19	wodz	Buschel: test_mem says read ~100MB/s, write ~51MB/s, memset ~50MB/s, memcpy 48MB/s
22:23:02	wodz	I don't have any target to compare this results
22:23:27	Buschel	is this for IRAM?
22:23:30	wodz	dram
22:24:15	wodz	iram is (almost) useless as it is 4kB or so
22:24:20	Buschel	S5L8701 DRAM = 59 read, 35 write, 35 set, 22 copy
22:24:43	Buschel	your numbers are similar to S5L8701 IRAM
22:25:42	bertrik	Buschel, maybe it's just misconfigured then?
22:25:54	Buschel	yep, maybe...
22:26:10	wodz	hmm, so why mp3 decoding takes so much may it be (extremely) slow lcd updates?
22:27:08	Buschel	on S5L8701 I can sqeeze a bit more performance from my nano 2G. but this might most likely impact other nano's... for the rk27xx it might be interesting to check the RAM timings
22:28:05	Buschel	wodz, if the memory is that slow the filterbank will be slow as well. I think the codec measurement is fine
22:28:56	Buschel	wodz, I bet you'll see similar results if you do not update the screen during the test_codec run
22:29:36	wodz	you said s5l8701 dram read 59 vs. rk27xx dram read 100 - I don't get
22:30:49	Buschel	most codecs use IRAM for the performance critical parts. IRAM S5L8701 = 107 read, 80 write/set, 45 copy
22:31:54	Buschel	so, a bit faster than rk27xx
22:36:18		Quit FBIGuy (Quit: I'm outta here)
22:39:40	Buschel	can you configure to use a higher bus clock for the DRAM?
22:40:44	wodz	I can't remember the config
22:42:38		Quit benedikt93 (Quit: Bye ;))
22:46:57	wodz	sd reads aren't fast also
22:47:30	Buschel	what is the CPU clock?
22:47:36	wodz	200 MHz
22:47:52	Buschel	bus clock is 0.5 * CPU clock?
22:48:07	wodz	I think so
22:48:21	wodz	and APB is Fcpu/4
22:49:09	wodz	this particular version of the SoC can run at 240MHz
22:49:44		Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com)
22:50:56	Buschel	if you do not change the ration fcpu : ahb you should not be able to reach higher codec efficiency (like 53 MHz) but only a higher realtime factor
22:51:29		Quit dunkaist (Quit: leaving)
22:51:52	Buschel	you might for example run test_codec with CPU and AHB at 133 MHz
22:52:21	Buschel	dou you already have clock scaling?
22:53:13	wodz	no
22:54:34	Buschel	you will most likely see that test_codec will result in higher efficiency when CPU:AHB = 1:1. this way the CPU could be clocked to lets say 50 MHZ and be able to play mp3 in realtime.
22:57:27	Buschel	what is SCU_DIVCON1 set to?
22:57:49		Join FBI_Guy [0] (~fbiguy@pool-96-233-107-20.bstnma.fios.verizon.net)
22:58:12	wodz	the same as reset value stated in manual
23:00
23:05:21	wodz	eh, I fucked up filesystem on SD playing with sd_write_sectors(). Time to sleep() apparently.
23:05:57		Quit wodz (Quit: Leaving)
23:06:42		Quit FBI_Guy (Quit: I'm outta here)
23:07:01		Join FBI_Guy [0] (~fbiguy@pool-96-233-107-20.bstnma.fios.verizon.net)
23:37:43		Join TheLemonMan [0] (~lem0n@ppp-171-63.26-151.libero.it)
23:40:36		Quit n1s (Remote host closed the connection)
23:48:31	CIA-14	New commit by 03buschel (r30326): Reduce memory consumption of VGM codec for low memry targets at the costs of some performance for tracks using the 2616 emulator.
23:51:28	CIA-14	r30326 build result: All green
23:57:05	***	Saving seen data "./dancer.seen"
23:57:16		Quit ender` (Quit: You don't have to think too hard when you talk to teachers.-- J. D. Salinger)
23:57:54		Part Strife89 ("Vamoose!")

Previous day | Next day