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-15

00:08:16 Quit niekie (Ping timeout: 260 seconds)
00:10:50 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603])
00:13:35 Nick powell14ski__ is now known as powell14ski_ (
00:13:41 Nick powell14ski_ is now known as powell14ski (
00:34:43 Quit dunkaist (Quit: leaving)
00:36:33 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723])
00:47:48 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
00:51:15 Quit mudd1 (Ping timeout: 260 seconds)
01:05:24 Quit skx` (Ping timeout: 276 seconds)
01:05:44 Join skx` [0] (
01:06:33 Join Scromple [0] (
01:27:00 Quit sideral (Ping timeout: 260 seconds)
01:29:43 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
01:35:00 Quit ender` (Quit: Calling atheism a religion is like calling bald a hair color. -- Don Hirschberg)
01:41:03 Join kadoban [0] (
01:55:36***Saving seen data "./dancer.seen"
02:04:02 Join hskf [0] (
02:16:54 Quit bertrik (Read error: Operation timed out)
02:27:44 Join Thra11 [0] (~thrall@
02:28:46 Quit God_Eater (Ping timeout: 252 seconds)
02:30:20 Quit Thra11_ (Ping timeout: 246 seconds)
02:32:01 Join Keripo [0] (
02:40:35 Quit Thra11 (Ping timeout: 240 seconds)
02:49:58 Quit hskf (Quit: Computer has gone to sleep.)
02:52:09 Join hskf [0] (
02:57:28 Quit kadoban (Ping timeout: 250 seconds)
03:05:58 Quit hskf (Quit: Computer has gone to sleep.)
03:23:24 Quit shai (Ping timeout: 276 seconds)
03:23:51 Quit mgue (Ping timeout: 276 seconds)
03:25:19 Join mgue [0] (
03:30:06 Join Stevens111 [0] (
03:30:15 Quit Stevens111 (Client Quit)
03:32:49 Join kadoban [0] (
03:36:44 Quit liar (Ping timeout: 258 seconds)
03:41:24 Quit MethoS- (Remote host closed the connection)
03:55:39***Saving seen data "./dancer.seen"
03:57:57 Join JesusFreak316 [0] (
04:22:30 Join fyre^OS [0] (
04:23:12 Quit wtachi (Ping timeout: 258 seconds)
04:23:41 Quit fyrestorm (Ping timeout: 240 seconds)
04:29:42 Quit funman (Quit: leaving)
04:34:13 Quit fyre^OS (Ping timeout: 258 seconds)
04:36:08 Join shai [0] (
04:46:57 Quit JesusFreak316 (Ping timeout: 264 seconds)
04:57:08 Join Guest_25614 [0] (
05:00:17 Quit pixelma (Disconnected by services)
05:00:19 Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
05:00:21 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
05:00:31 Quit amiconn (Disconnected by services)
05:00:32 Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
05:00:52 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
05:28:04 Quit FoH (Quit: ¡ooʇ ‘ǝןdoǝd ǝɹɐ sʇɐq)
05:33:50 Join Rob2223 [0] (
05:37:54 Quit Rob2222 (Ping timeout: 250 seconds)
05:39:25 Quit Horschti (Quit: Verlassend)
05:41:41 Quit kadoban (Ping timeout: 240 seconds)
05:44:43 Quit shai (Quit: Leaving)
05:45:56 Join shai [0] (
05:46:46 Quit markun (Ping timeout: 246 seconds)
05:53:25 Quit ruler501 (Remote host closed the connection)
05:55:44***Saving seen data "./dancer.seen"
06:26:07 Quit Keripo (Quit: Leaving.)
06:27:30 Join upul` [0] (cb5e5562@gateway/web/freenode/ip.
06:49:30 Join ChickeNES [0] (
06:55:29 Join kadoban [0] (
07:17:06 Quit kadoban (Ping timeout: 252 seconds)
07:36:08 Join stoffel [0] (
07:37:32 Join bug2000 [0] (~bug@unaffiliated/bug2000)
07:48:29 Join Topy [0] (
07:51:34 Join sideral [0] (~sideral@rockbox/developer/sideral)
07:52:13 Quit T44 (Ping timeout: 250 seconds)
07:55:34 Quit stoffel (Remote host closed the connection)
07:55:48***Saving seen data "./dancer.seen"
07:59:19 Join Scr0mple [0] (
08:01:45 Quit Scromple (Ping timeout: 250 seconds)
08:03:52 Quit HaimN (Remote host closed the connection)
08:09:57 Quit powell14ski (Quit: powell14ski)
08:19:08 Join Bagd3r [0] (
08:27:22 Join Zagor [242] (~bjst@rockbox/developer/Zagor)
08:53:25 Join einhirn [0] (
09:03:51 Quit Scr0mple (Quit: Leaving)
09:24:07 Join God_Eater [0] (93722cc8@rockbox/staff/GodEater)
09:26:34 Join T44 [0] (
09:30:09 Quit Topy (Ping timeout: 250 seconds)
09:47:06 Join kadoban [0] (
09:55:49***Saving seen data "./dancer.seen"
10:13:44 Join bertrik [0] (
10:13:44 Quit bertrik (Changing host)
10:13:44 Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
10:14:19 Join Topy [0] (
10:17:31 Nick Bagd3r is now known as Bagder (
10:17:39 Quit Bagder (Changing host)
10:17:39 Join Bagder [241] (~daniel@rockbox/developer/bagder)
10:17:49 Quit T44 (Ping timeout: 250 seconds)
10:20:57 Join Topy44 [0] (
10:23:53 Quit Topy (Ping timeout: 250 seconds)
10:28:00 Join bertrik_ [0] (~bertrik@rockbox/developer/bertrik)
10:37:48 Quit sideral (Disconnected by services)
10:37:50 Join sideral [0] (~sideral@rockbox/developer/sideral)
10:38:12 Quit bertrik_ (Quit: :tiuQ)
11:01:00 Join ender` [0] (
11:02:02 Join lorenzo92 [0] (~chatzilla@
11:05:03 Quit Guest_25614 ()
11:08:46 Quit ender` (Read error: Connection reset by peer)
11:08:52 Join ender` [0] (
11:17:16 Quit sideral (Disconnected by services)
11:17:16 Join sideral1 [0] (~sideral@rockbox/developer/sideral)
11:17:39 Quit God_Eater (Quit: Page closed)
11:24:02 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440])
11:40:36 Quit ChickeNES (Quit: Computer has gone to sleep.)
11:46:04 Join pamaury [0] (
11:46:04 Quit pamaury (Changing host)
11:46:04 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:55:53***Saving seen data "./dancer.seen"
11:58:38 Join GigaBrick [0] (
11:59:01GigaBrickIs there a place to upload your battery-bench runtimes?
11:59:29AlexPThere is a wiki page
11:59:36AlexPOr maybe multiple pages, per device
12:00:03GigaBrickOh, I guess I don't really know how to work it
12:00:09AlexPI can't remember what they are called, but something like e.g. SansaRuntime IIRC
12:00:12GigaBrickDo you have to actually edit it like a wiki page or something?
12:00:20AlexPwell yes, it is a wiki
12:00:22GigaBrickI found the one for the gigabeat ( my device)
12:00:38 Join dunkaist [0] (~dunkaist@
12:00:45GigaBrickHeh, okay, I guess I was just thinking it would be like a little file form and an upload button or something
12:02:57 Join niekie [0] (~niek@CAcert/Assurer/niekie)
12:11:12 Join fyrestorm [0] (
12:11:45GigaBrickWell, I don't know if the gigabeat really needs another uptime entry that bad
12:14:55 Quit GeekShadow (Ping timeout: 258 seconds)
12:16:42 Join GeekShadow [0] (
12:20:32 Join liar [0] (
12:41:04sideral1Hi bug2000, you rang?
12:41:18bug2000sideral1, Just wanted to know if there are any news of the duplication bug.
12:41:32 Quit dunkaist (Quit: leaving)
12:42:51sideral1yeah, another user managed to replicate it and uploaded his DB to FS #12129; and we have a theory that it happens when a DB commit fails in mid-process, and later restarts and succeeds.
12:42:52fs-bluebot Duplicate database entries (bugs, unconfirmed)
12:43:50 Join lorenzo92 [0] (
12:43:52sideral1and it seems to be related to FS #12228: DB duplication was another failure mode of the error described in that task
12:43:53fs-bluebot Database fails to commit on Fuze v2 fresh SVN build (bugs, unconfirmed)
12:43:59 Quit lorenzo92 (Client Quit)
12:44:20Slasherisideral1: great work with hunting those db bugs :)
12:44:49sideral1I'm positive I can reproduce the latter problem; I'm in the process of duplicating that user's data set, and I have the same player available
12:45:14 Nick sideral1 is now known as sideral (~sideral@rockbox/developer/sideral)
12:45:47sideralSlasheri: thanks :) the dircache buffer shrinking uncovered quite a number of them :)
12:45:51Slasherisideral1: i think the commit should be prevented to start if db is marked dirty.. that was the original intention, but due to a bug that flag is no checked at beginning of commit
12:46:22Slasherisideral: yeah, that's a good thing we made such a change to the dircache :)
12:46:37sideralyeah, I'll eventually get to that (unless you beat me to it ;) ). But first I'd love to verify that this is causing the bugs
12:47:30Slasheriand second thing to find out would be that why db commit has failed
12:49:21 Join ptrkmj [0] (
12:49:57sideralSlasheri: Do you have any idea re FS #12216?
12:49:58fs-bluebot Dircache shuts down when closing a file that was opened prior to reloading the dircache (bugs, new)
12:52:41Slasherisideral: ah, that's interesting..
12:53:40sideralI fixed the DB cras
12:53:56sideralI fixed the DB crash triggered by this bug already in current SVN
12:54:13Slasherisideral: dircache definately needs recover those already open handles somehow, inconsistency between fs layer and dircache is not acceptable (causing dircache to shutdown)
12:55:48sideralSlasheri: which of my three proposed solutions do you like best; or do you have something else in mind?
12:56:37sideralAlso, we should consider that keeping the status quo (shutting down the dircache in this case) might be the best solution
12:56:46Slasherisideral: another bug that needs to fixed is to record updates to file size etc. while dircache is being initialized. I already semi-fixed that locally some time ago
12:57:28Slasherisideral: i think saving those open handles would work for sure, but better solutions could exist as well :)
13:00:14sideralSlasheri: You mean updates to dircache entries in a partially initialized dircache?
13:00:54sideral(^ re "another bug")
13:03:07*sideral needs to go offline for some time; I'll check back later
13:04:25JdGordonAlexP: hey, did you notice FS #12230 :)
13:04:26fs-bluebot text stlye skin changes need adding to the manual (bugs, new)
13:04:45JdGordonI dont like adding new tags because i have no idea how TeX works, but its enough enough modifying existing ones
13:04:59AlexPJdGordon: Yeah, I saw it thanks :)
13:07:17JdGordoncan anyone confirm fs#12047 ?
13:07:18fs-bluebot WPS on startup doesn't work on iPod Video (bugs, unconfirmed)
13:12:01Slasherisideral: yes
13:19:03AlexPJdGordon: Is %Vg only for colour targets, or does it work for greyscale?
13:19:10 Join MethoS- [0] (~clemens@
13:20:15 Join HaimN [0] (~quassel@
13:27:46AlexPYou can't answer yes to an either or question! :)
13:28:13JdGordonVg only works for colour
13:28:17AlexPOK :)
13:28:23JdGordonditto the gradiuent mode in Vs
13:38:48 Quit upul` (Quit: Page closed)
13:41:16AlexPJdGordon: %Vg applies the whole viewport and comes in the line with %Vf and %Vb i.e. %V(...) %Vf(...) %Vb(...) %Vg(...) ?
13:49:58AlexPJdGordon: If so, to what does the "text" param mean?
13:50:22AlexPAnd if not and you put it before individual lines, when the wiki says "These need to be before any other tags after a %V() line or scrolling lines will not work as expected. " is it then wrong?
13:55:57***Saving seen data "./dancer.seen"
13:58:28 Quit simonlnu (Ping timeout: 246 seconds)
13:58:30 Join Thra11 [0] (~thrall@
14:01:25 Join simonlnu [0] (K799LvyJE1@unaffiliated/simonrvn)
14:01:26 Join ptrkmj_ [0] (~chatzilla@
14:03:15 Quit ptrkmj (Ping timeout: 240 seconds)
14:03:20 Nick ptrkmj_ is now known as ptrkmj (~chatzilla@
14:05:12 Quit Thra11 (Ping timeout: 260 seconds)
14:11:47 Join lorenzo92 [0] (
14:14:33 Join nick-p [0] (
14:17:09 Join Thra11 [0] (
14:17:30nick-psideral: Though I'm not subscribed, I just saw your comments on rockbox-dev FS #10849 via the website. I agree Thomas Jarosch's suggestion is a good compromise. Would you like me to implement it, wait a bit, or would you rather do it?
14:23:20user890104can someone have a look at FS #12233 please?
14:23:21fs-bluebot iPod 6G/Classic: LCD not displaying rockbox correctly if using emCORE >= r746 (patches, unconfirmed)
14:26:49 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
14:28:37 Quit mystica555 (Ping timeout: 252 seconds)
14:30:52 Join mystica555 [0] (
14:30:55 Quit mystica555 (Max SendQ exceeded)
14:31:12 Join mystica555 [0] (
14:31:15 Quit mystica555 (Max SendQ exceeded)
14:31:34 Join mystica555 [0] (
14:31:36 Quit mystica555 (Max SendQ exceeded)
14:31:53 Join mystica555 [0] (
14:31:55 Quit mystica555 (Max SendQ exceeded)
14:32:11 Join mystica555 [0] (
14:32:12 Quit mystica555 (Max SendQ exceeded)
14:32:40 Join mystica555 [0] (
14:35:49gevaertskugel: shouldn't FS #12159 be closed now?
14:35:50fs-bluebot GSoC/Buflib: Remove direct audiobuf accesses (patches, new)
14:36:56kugelwill do shortly
14:37:45 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440])
14:39:49sideralnick-p: I think it'd be wise to wait a couple more days for more comments before getting back to coding
14:40:14gevaertssideral: you think there will be a consensus?
14:41:12sideralgevaerts: I'm always optimistic :) BTW, thanks for commenting in the thread!
14:41:47GigaBrickHey, gavaerts, if you've got time someone told me I should mention a problem I'm having with usb.c with you
14:42:01AlexPI don't see an email from gevaerts
14:42:45sideralAlexP: he was the first one to comment
14:42:51siderala few days ago
14:42:59AlexPoh, I thought you meant recently
14:43:06nick-psideral: will do, thanks
14:43:35AlexPGigaBrick: If you want him to be alerted, you probably want to get his nick right :)
14:44:47GigaBrickOh, whoops, looked like an 'a'
14:45:22GigaBrickHey, gevaerts, if you've got time someone told me I should mention a problem I'm having with usb.c with you
14:45:55gevaertsGigaBrick: sure, go ahead
14:46:17gevaertsAlthough I'm not sure if I'm really as knowledgeable about those parts as some people claim
14:47:08GigaBrickWell, me either, but I've been having an issue where I get "*PANIC* mount: 0" across the screen if I disconnect the USB while the backlight is off ( outside of bootloader usb mode )
14:47:58gevaertsWhich device?
14:48:36gevaertsIs this recent and reproducible?
14:48:55GigaBrickI'm not really sure on either case
14:49:06GigaBrickI only found one other person on the forums that seems to have a similar problem and that was way back from 2007
14:49:24GigaBrickIt only started happening to me after updating from 3.0 ( one of the svn releases ) to 3.9
14:49:37gevaertsI mean, does it happen every time?
14:49:51GigaBrickOh, okay, in that case yes
14:50:11GigaBrickI even changed the panic message from "mount: %d" to include the line number from usb.c to make sure which one it was
14:50:14*gevaerts goes to get a gigabeat
14:50:32GigaBrickIt's the one on line 336, if that helps
14:51:01GigaBrickAll I can tell from the source is that it's because disk_mount_all() returned 0 ( no partitions) but I'm not sure why that's happening now
14:51:33gevaertsIs that with 3.9 or current svn?
14:51:57GigaBrickCurrent svn
14:52:34AlexPjust to be sure, which version?
14:53:06gevaertsI doubt the exact revision matters much. I just want to be reasonably close when trying myself :)
14:53:14GigaBrickr30295M-110815 ( not sure which one of those numbers matters )
14:53:45AlexPThe first is the version number (which is a bout 20 revisions old)
14:53:51AlexPThe second is the date
14:54:50gevaertsAh, interesting
14:54:58*gevaerts can apparently reproduce this
14:55:54GigaBrickHeh, not sure if it's appropriate, but I"ll say, "Yay, it's not just mine"
14:57:05gevaertsTime for some splashf() debugging
14:59:32GigaBrickThe only caveat to reproducing it is that sometimes it will still panic even after hititng the touchpad to turn the backlight back on
14:59:41GigaBrickBut it will always do it to me if I disconnect while the backlight is off
15:02:01gevaertsOh, more fun
15:02:12gevaertsThis time it's buffer_alloc() that panics :)
15:02:17*gevaerts summons kugel
15:02:25*kugel is here
15:03:36gevaertskugel: "buffer_alloc(): exclusive buffer owner". Any ideas?
15:03:46gevaertsHappens after unplugging usb
15:04:09kugelthat means that someone calls buffer_alloc() while someone else has the lock from buffer_get_buffer()
15:04:18kugelit didn't happen for me though
15:04:21gevaertsHow dare they? :)
15:06:03 Quit HaimN (Ping timeout: 260 seconds)
15:06:29 Join HaimN [0] (~quassel@
15:07:18gevaertshm, this is too random to be useful!
15:12:28kugelhm, how can I debug this win32 crash
15:13:26 Join ptrkmj_ [0] (
15:13:36 Quit ptrkmj_ (Client Quit)
15:13:52gevaertsGigaBrick: can you try the patch at ? I'd recommend staying on r30295 for now, since current svn seems to have another possible panic, and you don't want two different issues interfering :)
15:14:37 Quit ptrkmj (Ping timeout: 250 seconds)
15:15:12GigaBrickOkay, but I think I might need to double-check which version I have
15:15:24GigaBrickI thought this was current svn... Checked out via svn and compiled myself
15:15:30gevaertsYes, but when?
15:15:40GigaBrickJust yesterday
15:16:02gevaertsThat's *ages* ago :)
15:16:22GigaBrickOh, heh, okay... Well, when someone mentioned I was 20 revisions behind
15:16:31GigaBrickI was worried I may have checked out an old build somehow
15:16:38gevaertsMore or less, yes. Keep it that way for now
15:16:55GigaBrickAll right, thanks for the heads up on that
15:17:21GigaBrickAs for that patch, I'm afraid it's been awhile since I've patched anything... Have to go look at the wiki real quick
15:17:48gevaertsI only saw your panic once, and then never again. This other panic is later on, so it can't be suppressing it
15:17:57gevaertspatch -p0 < patchfile
15:18:50GigaBrickAhh, yeah, that seems familiar :)
15:18:58gevaertsGigaBrick: in bootloader USB, do you ever see "ATA error -11"?
15:19:12GigaBrickEvery time I disconnect the USB
15:19:24gevaertsI suspect that's the same issue
15:20:03GigaBrickYeah, I've always wondered what that meant
15:20:20GigaBrickI remember searching for it on the forums quite a long time ago, but the only people that had it happened to didn't report any problems so I never worried about it
15:20:42GigaBrickThe panics are new to me though... I assume it's probably just a difference in the way 3.0 handled it versus where it's at now
15:21:44 Quit GeekShadow (Ping timeout: 258 seconds)
15:21:44 Join GeekShad1w [0] (
15:21:58gevaertsI don't know what -11 means exactly, but there's a problem accessing the disk after disconnecting usb.
15:23:45GigaBrickI wonder if maybe the disk powers down when in USB mode, but doesn't power up in time after disconnecting?
15:27:46gevaertshm, maybe
15:28:22 Quit nick-p (Quit: CGI:IRC)
15:30:11GigaBrickgevaerts, I tried the patch out, but I still get the same panic
15:31:47gevaertsGigaBrick: it doesn't say anything before panicking?
15:32:26GigaBrickI didn't see anything
15:32:29GigaBrickI'll try it again
15:33:31gevaertskugel: it's the buffer_alloc() in dircache_build()
15:34:27 Nick GeekShad1w is now known as GeekShadow (
15:34:43 Quit GeekShadow (Changing host)
15:34:43 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
15:35:30gevaertsGigaBrick: I don't see anything that touches the disk before the first splash I added
15:35:41gevaertsSo it should at least get there
15:36:48GigaBrickWell, I'm only seeing the "*PANIC* mount: 0" message
15:36:54GigaBrickIt's still the one from line 336 though
15:37:03gevaertsDo you see the splashes when booting?
15:37:22 Quit mystica555 (Ping timeout: 260 seconds)
15:37:46GigaBrickAll I see is the standard rockbox splash when booting
15:37:49 Join Thra11_ [0] (~thrall@
15:38:04gevaertsThen I suspect you didn't apply the patch correctly or something like that
15:38:05kugelgevaerts: interesting
15:38:08 Join God_Eater [0] (93722cd0@rockbox/staff/GodEater)
15:38:15GigaBrickYeah, I was about to say maybe I did something wrong
15:38:24GigaBrickOh, yeah, that would explain it
15:38:30GigaBrickDidn't actually copy the new to the player
15:40:54 Quit Thra11 (Ping timeout: 258 seconds)
15:43:15gevaertskugel: I seem to get it more often (or only) if I plug in USB immediately after boot, so possibly it's when dircache wasn't fully initialised?
15:43:29gevaerts(I get it after unplugging)
15:45:20kugelthat's possible
15:46:00kugelthat code path is supposed to be only taken at boot
15:46:28kugelwhen the dircache size is known from the previous boot
15:46:46kugelruntime dircache generation should take the path where the dircache buffer is already allocated
15:47:41kugelgevaerts: it's possible that your usb insertion interrupts the dircache generation. then in the next dircache generation it doesn't see the already allocated buffer
15:48:32kugelperhaps I accidentally changed the semantics of the dircache_size variable
15:49:02kugelor (what I find more likely) that the panic uncovered an old bug :)
15:49:16gevaertsMaybe. Or maybe it's a long-standing problem that's now visible with the new checking
15:50:03gevaertsIt goes on sideral's pile then :)
15:51:40kugeldircache generation needs to be restarted, but not in a code path which does buffer_alloc
15:53:23 Quit simonlnu (Ping timeout: 258 seconds)
15:54:58 Join T44 [0] (
15:56:01***Saving seen data "./dancer.seen"
15:58:11kugelgevaerts: that could fix it
15:58:21 Quit Bagder (Quit: Konversation terminated!)
15:58:25 Quit Topy44 (Ping timeout: 240 seconds)
15:58:52kugeldircache_size is (and always has been) reset to 0 when the generation is cancalled
15:59:00 Quit kadoban (Ping timeout: 250 seconds)
15:59:33*gevaerts tries
15:59:56kugelthe cancellation doesn't distringuish between failure due to error or failure due to interruption
16:00:33kugelsideral: can you comment on that?
16:01:14GigaBrickgevaerts, finally got that patch applied
16:01:23 Join simonlnu [0] (L8SlmflMgG@unaffiliated/simonrvn)
16:01:53kugelor Slasheri
16:03:26gevaertskugel: I can't comment on the explanation, but it seems to fix the problem
16:03:50GigaBrickOkay, gevaerts it says "volume 0! trying volume 0! mounted volume 0!" and then returns to the main menu screen
16:04:08gevaertsGigaBrick: consistently? If so, that would point to a timing problem
16:04:12kugelgevaerts: I'm fairly confident, but lets wait for the experts :)
16:04:40kugelnot sure if the initialization to DIRCACHE_LIMIT has any special meaning
16:04:48GigaBrickYep, seems pretty consistent, the only times it doesn't do that it just flashes traight from the usb flash to the main menu, it seems that whenever it shows "volume 0! trying volume 0! etc" would be when it was going to panic
16:06:57GigaBrickYep, can't get it to panic at all anymore
16:07:52gevaertsGigaBrick: ok. Can you try reverting all those changes and applying *just* ? That just adds a half second sleep
16:08:25GigaBrickOkay, will do
16:12:56GigaBrickI have to recompile the whole thing over again though... For some reason doing "make reconf" and then "make" in the build dir didn't apply the patch
16:13:02GigaBrickSO yeah, just waiting for that
16:13:36GigaBrickI'm not really sure if that's the proper way to do things either, but it's been working for my other changes, but anyway, shouldn't be too long
16:13:49gevaertsYou shouldn't need make reconf for these patches
16:14:54gevaertsAnyway, if you could play with that number a bit (e.g. try HZ/10 which would be a tenth of a second) to try to figure out how long the sleep should really be, that would be ideal.
16:15:27GigaBrickAll right
16:15:38gevaertsIf you only change that file, make will only rebuild the main binary, so you don't need to go through the full make zip sequence. Just make, and then copy rockbox.gigabeat to .rockbox on the player is enough
16:15:39GigaBrickI'll let you know what the golden figure is when I find it
16:16:03GigaBrickOh, okay, that should save some time
16:16:18GigaBrickI changed someone else the other day and tried to run make and it told me to do "make reconf" so I figured I had to do that again
16:17:01gevaertsNo need to try 1000 different values of course. We want it reasonably short to avoid annoying users, but there's no point in trying to figure out if it should be 150ms or 125ms. Trying HZ/2 (the current value), and going down to HZ/5 or HZ/10 if it works, or up to HZ if it doesn't work would be plenty
16:17:53GigaBrickOkay, makes sense
16:18:09 Quit benedikt93 (Quit: Bye ;))
16:19:39GigaBrickYou wanted me to revert disk.c back to original too, right?
16:23:05kugelhow can I possibly debug the crash in the mingw build?
16:23:23 Quit HaimN (Remote host closed the connection)
16:23:42kugelI can lots of unrelated segfaults when I load it in winedbg
16:27:03kugelah I can continue them away
16:29:38GigaBrickHey, real quck question about themes if you guys know... If I change a theme to "%bt" where it once had a bitmap of the battery level, will it just display the runtime in text or nothing at all? Because I'm getting nothing at all...
16:30:54 Quit Rob2223 (Read error: Connection reset by peer)
16:31:09 Join Rob2222 [0] (
16:33:38GigaBrickgevaerts, HZ/10 seems to be working fine
16:35:16gevaertsOK. I'll commit that then. It's a bit of guesswork anyway. If people still have problems we can always increase it a bit
16:36:25CIA-14New commit by gevaerts (r30316): Add a 100ms delay before calling disk_mount_all(). Some players (especially some gigabeat Fs) seem to need a delay after disabling USB if we want disk ...
16:37:28GigaBrickYeah, HZ/5 didn't seem like that much of a wait at all
16:37:35GigaBrickSo maybe just use that instead
16:38:14gevaertsI wouldn't be surprised if even shorter would also be fine
16:38:45CIA-14New commit by gevaerts (r30317): Add a 100ms delay before calling disk_mount_all(). Some players (especially some gigabeat Fs) seem to need a delay after disabling USB if we want disk ...
16:38:52GigaBrickHeh, seems good then
16:38:58gevaertsAlexP: I guess that one wasn't controversial for 3.9?
16:39:10CIA-14r30316 build result: All green
16:39:38GigaBrickWell, neat, thanks for taking a look at that for me
16:41:22bertrikgevaerts, commit first, ask questions later :D
16:41:35 Join Topy [0] (
16:44:19 Quit T44 (Ping timeout: 250 seconds)
16:45:19gevaertsbertrik: I'm starting to understand how rockbox works :)
16:47:07 Join krnlyng [0] (
16:47:35 Quit liar (Ping timeout: 258 seconds)
16:48:08 Join powell14ski [0] (
16:49:09 Quit Thra11_ (Read error: Operation timed out)
16:50:43GigaBrickDarn, was hoping you guys would have one of those
16:50:57 Join liar__ [0] (
16:51:48 Quit krnlyng (Ping timeout: 258 seconds)
16:52:20ZagorGigaBrick: /msg logbot seen <nick>
16:52:34GigaBrickAhh, thank you
16:53:36GigaBrickYikes, it appears I'm looking for help on a theme that was last updated in 2008
16:53:40*GigaBrick crosses fingers
16:56:22 Join Thra11_ [0] (~thrall@
16:58:55 Join Keripo [0] (
17:03:01kugeluh, I left some pretty hefty bugs in dircache.c
17:03:29 Join T44 [0] (
17:04:24*kugel impatiently waits for sideral or Slasheri
17:07:17 Quit Topy (Ping timeout: 250 seconds)
17:09:13AlexPgevaerts: No, seems fine to me
17:09:26 Join Jerom [0] (~jerome@
17:10:29kugelheh, nice that ".", ".." and ".rockbox" are at the end of the dircache, that uncovers bugs quite easily
17:10:51 Join HaimN [0] (~quassel@
17:12:31 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
17:13:18CIA-14New commit by kugel (r30318): Dircache: Fix bug introduced in r30308. ...
17:16:01CIA-14r30318 build result: All green
17:17:52 Quit Thra11_ (Read error: Operation timed out)
17:24:11 Quit jhMikeS (Ping timeout: 250 seconds)
17:24:27 Part Zagor
17:27:46 Join GeekShad1w [0] (
17:28:14 Quit GeekShadow (Ping timeout: 276 seconds)
17:28:28 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier.
17:35:36 Join user829385 [0] (~aoeu@
17:39:07 Join Topy [0] (
17:40:39 Quit T44 (Ping timeout: 250 seconds)
17:41:20 Join ruler5 [0] (
17:44:25 Quit Keripo (Read error: Connection reset by peer)
17:46:11 Join wtachi [0] (
17:47:28 Join drezon [0] (~drezon@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584)
17:47:37 Join Keripo [0] (
17:51:42 Quit Keripo (Read error: Connection reset by peer)
17:52:07 Join Thra11 [0] (~thrall@
17:53:40 Nick GeekShad1w is now known as GeekShadow (
17:53:55 Quit GeekShadow (Changing host)
17:53:55 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
17:54:44 Join Keripo [0] (
17:56:02***Saving seen data "./dancer.seen"
18:03:23 Join Thra11_ [0] (~thrall@
18:06:35 Quit Thra11 (Ping timeout: 276 seconds)
18:12:28sideralkugel: I won't have time to look at the dircache patch for another two hours −− but anyway it's you who maintains dircache, not me ;)
18:20:43 Join Thra11 [0] (~thrall@
18:20:54kugelsideral: I hope for Slasheri then :)
18:22:23 Quit bug2000 (Ping timeout: 276 seconds)
18:23:48 Quit Thra11_ (Ping timeout: 258 seconds)
18:25:59 Join mystica555 [0] (~mike@
18:30:51 Join jhMikeS [0] (
18:30:51 Quit jhMikeS (Changing host)
18:30:51 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
18:32:48 Join T44 [0] (
18:36:33 Quit Topy (Ping timeout: 250 seconds)
18:39:10 Join y4n [0] (y4n@unaffiliated/y4ndexx)
18:44:20 Quit mystica555 (Ping timeout: 258 seconds)
18:45:39 Quit neferty (Quit: ohshi-)
18:47:36 Join neferty [0] (~andor@
18:48:28 Quit God_Eater (Quit: Page closed)
18:52:27 Quit Keripo (Read error: Connection reset by peer)
18:54:46 Join Keripo [0] (
19:12:28 Join nomada [0] (
19:13:00 Join kadoban [0] (
19:20:32 Quit MethoS- (Remote host closed the connection)
19:21:14 Join MethoS- [0] (~clemens@
19:24:44 Quit Keripo (Quit: Leaving.)
19:31:04 Join Strife89 [0] (~Strife89@
19:34:36 Join dunkaist [0] (~dunkaist@
19:36:50 Quit bluebrother (Disconnected by services)
19:36:51 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
19:39:05 Quit GigaBrick (Ping timeout: 276 seconds)
19:39:22 Quit fs-bluebot (Ping timeout: 250 seconds)
19:40:31 Join fs-bluebot [0] (
19:42:23 Quit dunkaist (Quit: leaving)
19:45:38 Quit HaimN (Ping timeout: 246 seconds)
19:46:04 Join HaimN [0] (~quassel@
19:46:24 Join Keripo [0] (
19:47:45 Join stoffel [0] (
19:52:31 Join GigaBrick [0] (
19:52:43 Quit Keripo (Read error: Connection reset by peer)
19:54:41 Join Keripo [0] (
19:55:02 Join Thra11_ [0] (
19:55:21 Quit Thra11 (Read error: Operation timed out)
19:56:04***Saving seen data "./dancer.seen"
19:56:22 Join Horscht [0] (
19:56:22 Quit Horscht (Changing host)
19:56:22 Join Horscht [0] (~Horscht@xbmc/user/horscht)
20:04:55 Quit drezon (Ping timeout: 255 seconds)
20:12:17 Join Buschel [0] (
20:13:48Buschelkugel: r30318 fixes my nano2g-sim issue. thanks
20:15:32 Quit HaimN (Quit: No Ping reply in 180 seconds.)
20:16:16 Join HaimN [0] (~quassel@
20:18:39 Quit user890104 (Read error: Connection reset by peer)
20:19:47 Join user890104 [0] (
20:24:52CIA-14New commit by buschel (r30319): Save some RAM in a libgme emulator used for VGM codec. LFO_ENV_TAB[] and LFO_FREQ_TAB[] are obselete.
20:27:11CIA-14r30319 build result: All green
20:30:47 Quit Buschel (Ping timeout: 246 seconds)
20:32:09 Join germanmushroom [0] (
20:34:17 Quit GeekShadow (Ping timeout: 264 seconds)
20:34:56 Join GeekShadow [0] (
20:44:02 Quit stoffel (Remote host closed the connection)
20:45:10 Join Buschel [0] (
20:53:00 Nick Horscht is now known as Cmptr (~Horscht@xbmc/user/horscht)
20:53:01 Quit Keripo (Read error: Connection reset by peer)
20:53:13 Nick Cmptr is now known as Horscht (~Horscht@xbmc/user/horscht)
20:55:27 Join Keripo [0] (
20:58:36 Join mystica555 [0] (~mike@
20:58:55 Quit mystica555 (Read error: Connection reset by peer)
21:11:41 Quit Jerom (Ping timeout: 258 seconds)
21:12:43 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky)
21:22:56 Quit HaimN (Ping timeout: 246 seconds)
21:25:35 Join HaimN [0] (~quassel@
21:33:44 Quit HaimN (Quit: No Ping reply in 180 seconds.)
21:34:11 Join HaimN [0] (~quassel@
21:36:12 Quit HaimN (Read error: Operation timed out)
21:37:56 Join HaimN [0] (~quassel@
21:43:22*sideral is frustrated with the time-killing aspect of the FS #10849 discussion on the dev mailing list
21:43:24fs-bluebot Sleep timer options: persistent duration and start on boot. (patches, unconfirmed)
21:43:54 Quit HaimN (Quit: No Ping reply in 180 seconds.)
21:44:29 Join HaimN [0] (~quassel@
21:53:11 Quit Keripo (Read error: Connection reset by peer)
21:53:31 Quit y4n (Quit: The world around me drops away, replaced by worlds being created and destroyed by my imagination.)
21:55:33 Join Keripo [0] (
21:56:08***Saving seen data "./dancer.seen"
22:00:12 Quit jhMikeS (Ping timeout: 250 seconds)
22:16:09 Join Huls [0] (
22:21:04HulsI've installed Rockbox on a iaudio X5L but now my pc doesn't recognize it anymore so I can't do anything.
22:21:48 Quit Huls (Quit: CGI:IRC)
22:26:32 Join fml [0] (
22:27:10 Join AlexP_ [0] (~alex@rockbox/staff/AlexP)
22:27:26 Quit AlexP (Ping timeout: 260 seconds)
22:28:24fmlsideral: he-he, with the time rockbox has gained great inertion which makes introducing a new feature not so easy (good in many cases) especially when there are comments from people who only theoretize and (would) not really use the feature
22:28:56 Quit fml (Client Quit)
22:29:41 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 3.6.18/20110614230723])
22:34:26 Quit simonlnu (Ping timeout: 260 seconds)
22:37:09 Join simonlnu [0] (cthxevBBPH@unaffiliated/simonrvn)
22:39:26 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
22:40:38 Join petur [0] (~petur@rockbox/developer/petur)
22:52:08 Quit simonlnu (Ping timeout: 240 seconds)
22:53:21 Join ptrkmj [0] (~chatzilla@
22:55:36 Join lorenzo92 [0] (
22:55:48 Quit lorenzo92 (Client Quit)
22:56:32 Join simonlnu [0] (clq5j3W37G@unaffiliated/simonrvn)
22:58:32 Quit HaimN (Ping timeout: 276 seconds)
22:58:32 Join HaimN [0] (~quassel@
23:00:35*AlexP_ doesn't see the point of posting something to -dev for discussion then saying don't have the discussion
23:00:35 Quit HaimN (Remote host closed the connection)
23:00:35sideralkugel: What was that dircache change you wanted me to look at, and what was it about?
23:00:35 Join JeanLouisBiasini [0] (
23:00:35 Join HaimN [0] (~quassel@
23:00:35sideralAlexP: Thanks for your kind words ;) I've posted something for discussion to -dev to discuss this particular something, and not something else
23:00:35AlexP_To me it seems fairly integral
23:00:40AlexP_It affects how the patch is implemented and works
23:01:24sideralAnd I feel the UI discussion is fairly orthogonal and should be sorted out separately / later
23:01:43AlexP_I don't see how it is orthogonal
23:01:45sideralBut I'll be happy if it is sorted out sooner rather than later
23:01:50AlexP_But whatever
23:01:55AlexP_Frankly I can't be bothered
23:03:36*sideral doesn't see the point of posting something in IRC for discussion then saying I can't be bothered :P
23:03:44sideralI suggested to consider integrating the feature into the current UI paradigm first, and thinking separately about changing that paradigm
23:04:18AlexP_I didn't post here for discussion, I made an observation
23:04:35AlexP_Also, I hate the word paradigm :)
23:05:11AlexP_I don't care enough to argue though
23:05:28sideralRe "paradigm": So do I, but this is not an email that took 2 hours to get right and politically correct ;)
23:05:30AlexP_As long as I don't have to go to two different places to set my time then start it I don't mind
23:06:31sideralMore people should think like you :)
23:06:36 Part Thra11_ ("kthxbai")
23:06:38AlexP_heh :)
23:07:20 Quit simonlnu (Read error: Connection reset by peer)
23:07:26 Quit HaimN (Quit: No Ping reply in 180 seconds.)
23:07:38 Join simonlnu [0] (V3i8gzPgYt@unaffiliated/simonrvn)
23:08:02 Join HaimN [0] (~quassel@
23:09:07sideralAnyway, I'd rather have liked to spend those 2 hours hacking.
23:12:42 Quit JeanLouisBiasini (Quit: CGI:IRC)
23:26:46kugelpsideral: should be in the logs
23:27:25sideralkugel: I'd hoped you could summarize that long discussion in one or two sentences?
23:27:57kugelpwhat discussion?
23:28:38sideralsee? looks like I don't know what to look at :)
23:28:55kugelpI'm on the phone so I rather not repeat what's in the logs for your convenience :-)
23:30:28sideralOK, maybe later then :)
23:30:41kugelpit starts at 15pm
23:30:44sideral I just don't know where that discussion starts and whether this has anything to do with USB at all
23:32:00kugelpgevaerts spotted another panic while repro-ing the mount problem
23:32:29 Quit Keripo (Quit: Leaving.)
23:33:02kugelpa buffer_alloc() while the audio buffer is locked by a buffer_get_buffer()
23:33:26kugelpI introduced that panic with r30308
23:34:28sideralkugel: Looks like I've had my share of long discussions today; I won't read through another one right now. Maybe tomorrow.
23:35:19kugelpit looks like it uncovered a bug in that the dircache takes a code path on usb unplug which it is supposed to take at boot
23:35:47kugelpbecause usb insertion cancels the cache generation
23:35:52 Part domonoky
23:36:24sideralis taking dircache generation so long on that player that it can be interrupted by an USB insertion?
23:37:20kugelpmore details at 15:46 and the next few minutes. my proposed patch is at 15:58
23:37:52kugelpI suspect the background build takes a lot longer
23:38:30*sideral is looking at the patch
23:39:48kugelpit cancels when dircache_size is still 0, so the rebuild doesn't see the buffer is already allocated and thus.does another buffer_alloc()
23:40:27kugelpI assume anyway, I didn't actually repro this. I made the patch blindly :-)
23:44:05sideralI think the patch makes sense. I seem to remember thinking that initializing allocated_size as nonzero was needed somewhere, but I cannot remember why anymore :)
23:45:19sideralcan we assume that unititialized static variables are zero-initialized?
23:45:31sideralprobably better to init allocated_size with 0
23:46:42sideralwhat makes sure BSS is 0-initialized in Rockbox?
23:47:54kugelpsideral: the c runtime does that
23:48:31Tornesideral: the entry point, and plugin_load, and codec_load
23:48:48sideralOK, thanks
23:49:02TorneThe C spec guarantees it, so we would be somewhat silly to not provide it :)
23:49:25Torneit would break a lot of code :p
23:49:31kugelpsideral: that it is initialized to DIRCACHE_LIMIT confuses me as well, I'm not sire I didn't overlook something
23:49:36sideralYeah, maybe even the compiler relies on it; AFAIK it's free to allocate 0-initialized globals in BSS
23:50:00Torneyes, it will.
23:51:28kugelpit does? I read somewhere about kernel development that they rather see not initialized because 0-initialized ends up in the data segment and increases the binsize
23:51:53kugelpI never checked that, though
23:51:55Tornekugelp: always has for me
23:52:06Torneit's free to do it; .bss being initialised to zero is guaranteed by the platform ABI
23:52:16Torne(not by the C spec, whcih doesn't know about sections)
23:52:33Torne(but the C spec guarantees arithmetic types are initialized to 0 if not explicitly set to something else, and pointers to NULL)
23:52:58 Quit HaimN (Quit: No Ping reply in 180 seconds.)
23:53:34 Join HaimN [0] (~quassel@
23:53:46sideralkugel: Maybe this was important before you introduced buffer_alloc? It probably was used as the default allocation size, starting at the beginning of audiobuf
23:55:38sideralI seem to remember that the dircache stopped initializing if that allocation limit was stepped over by allocating another entry
23:56:09***Saving seen data "./dancer.seen"
23:56:21sideraland if it wasn't, the allocated_size was corrected downwards (end of dircache + reserve) after the init
23:56:33sideralso it shouldn't be needed anymore
23:57:23sideralSo I suggest to commit the patch after testing it for a few days yourself
23:58:02sideralkugel: Let me know when you've finished your call, I have a fun dircache-related proposal / thought experiment :)

Previous day | Next day