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 Duplicate 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 Database 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 Duplicate 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 kugel (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 buschel (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!") |