--- Log for 17.08.111 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 14 hours ago 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.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.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.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.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.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.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.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 # 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.14.39 # 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.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 # GigaBrick: that one should be fixed 10.17.46 # :/ I just got it again with the latest svn 10.17.54 # 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 # GigaBrick: my commit should fix a panic on disconnect right 10.25.56 Quit antil33t () 10.25.58 # I'll give it another try 10.26.14 # But when I tired the SVN tonight and disconnected I got the same panic message gevaerts posted originally 10.26.22 # The "exclusive buffer owner" one 10.26.27 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 10.28.21 # GigaBrick: did you connect usb right after booting? 10.28.42 # Yeah, i was just going to mention that I waited until the disk activity icon stopped spinning 10.28.45 # And then plugged it in 10.29.01 # hm, might be a different one then 10.29.14 # 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 # 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 # 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 # Got it again... 10.36.00 Quit antil33t () 10.36.14 # 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 # Weirder, now I can't reproduce it at all 10.43.06 # 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.02.38 # 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 # gevaerts, does it happen to you on usb disconnect at all anymore? 11.15.45 # No idea. I haven't disconnected USB with current svn 11.16.36 # 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 # All right 11.23.04 # 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 # Oh, that makes sense why it stopped reproducing 11.23.50 # I turned the Last.fm log off anticipating a lot of crashes 11.23.58 # That's when the panics stopped too... 11.25.03 # GigaBrick: maybe a silly question, but is the panic text wrapped? 11.25.17 # Meaning it starts on a new line? 11.25.21 # Yes 11.25.53 # kugel: do you mind if I commit that patch so these panics get easier to trace? 11.26.07 # Or will it mess up your tree too much? 11.26.27 # gevaerts, it wraps at "...lusive buffer owner" if that's helpful to know 11.26.28 # gevaerts: yes 11.26.46 # it messes up my tree, and it will be obsolete 11.26.59 # because with buflib it doesn't panic anymore 11.27.05 # ah, ok 11.27.21 # * gevaerts isn't awake, clearly :) 11.27.33 # I forgot. That's what buflib is *for*... 11.27.56 # :) 11.28.15 # Well, I was right about disabling the last.fm log making the panic stop 11.28.47 # So I'm guessing there's a function called scrobbler_init that's to blame? 11.29.55 # Yes, or that area anyway 11.31.18 # 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 # I miss anything? 11.52.27 # gevaerts: scrobbler cache is re-allocated after usb extraction (and scrobbler is shut down on insertion) 11.52.54 # 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 # 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 # 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.19 # * kugel would propose this patch http://pastie.org/2385162 12.00.58 # GigaBrick: that should fix it 12.01.07 # Okay, I'll give it a try 12.01.44 Part Zagor 12.01.55 # 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 # like it doesn't do anything on flash 12.03.46 # As far as I know they should always work 12.04.36 # so the patch relies on that callback to flush last.fm log to disk on usb 12.04.44 # and stops the stupid re-allocation 12.06.03 # my mail to -dev didn't catch a lot of attention yet :( 12.09.04 # Well 12.09.08 # I don't get that panic 12.09.19 # But now after disconnecting the usb I get "Error accessing plyalist control file" 12.09.24 # Then "Invalid control file" 12.10.27 # Then when I try to build the playlist again it says it can't update the control file 12.11.05 # is that when you played music before usb? 12.11.33 # Yeah 12.11.49 # Well, I rebooted and can load playlists and stuff now 12.11.57 # Though looks like I ran into that database duplication thing 12.12.01 # Because now I have double of everything 12.12.31 # :'( 12.13.17 # Yeah, I've seen that "Error accessing playlist control file" before 12.13.25 # But it always loads after I try it again 12.13.36 # Haven't seen it say Invalid before 12.13.52 # is that also reproducable? 12.14.01 # Yeah 12.15.47 # I'm not sure that's caused by my recent changes 12.15.59 # I don't think so 12.16.09 # I think it's related to the issue gevaerts fixed 12.16.26 # Because I notice it only does it when it would panic ( well, now instead of panicing it pauses for a second) 12.16.59 # GigaBrick: try increasing that sleep time a bit more, maybe? 12.17.41 # Okay 12.17.43 # I'll give that a try 12.17.51 # I have to let my database re-initalize right now though 12.17.59 # PIty, I just rated a bunch of songs :( 12.20.37 # GigaBrick: Try exporting the DB data before regenerating it 12.20.45 # there's a good chance the data can be recovered 12.21.02 # Yeah, I considered that only after hitting "Initialize" 12.21.06 # So too late now heh 12.21.18 # Also, please log the steps that led to the duplication to FS#12129 12.21.19 # http://www.rockbox.org/tracker/task/12129 3Duplicate database entries (bugs, unconfirmed) 12.21.39 # Did you interrupt a DB update with a reboot? 12.22.09 # No, it was related to an error acessing the playlist control file 12.22.12 # is there a way to copy replaygain info from file to file without replacing the entire file? 12.22.51 # GigaBrick: interesting... 12.22.59 # Yeah, I'm not really sure what happened to be honest 12.23.14 # I don't really understand when that error can actually occur 12.23.33 # Perhaps it's related to a dircache shutdown 12.24.01 # 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 # (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 # 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 # When that happens next time, could you please check the database and dircache status pages in the debug menu? 12.25.57 # Okay 12.26.08 # The "Error accessing control file" is fairly reproducable though 12.26.13 # So I can probably check that right now 12.26.15 Join metaphys [0] (~5470130d@giant.haxx.se) 12.26.49 # Do you have DB auto-update enabled, BTW? 12.26.56 # 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 # 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 # Yeah, sideral 12.27.38 # Good idea, gevaerts 12.28.11 # sideral, I've got the dircache debug page open 12.28.19 # After getting the "Error accessing playlist control file" splash 12.28.29 # is the dircache still enabled? 12.28.53 # Says "Cache initialized: Yes" if that means yes 12.29.01 # yeah, that's what I meant 12.29.09 # k 12.30.10 # and what does the DB debug menu say? 12.30.21 # first three lines? 12.30.38 # "Intialized: yes, DB Ready: Yes, RAM Cache: Yes" 12.31.01 # Also, under progress it says 87% (9145 entries) 12.31.10 # Does that mean it duped again? 12.31.43 # No idea -- you'll have to check in the DB browser 12.31.44 # Or maybe that's all still loaded in RAM from before I re-initialized? 12.31.49 # Okay 12.32.07 # found entries does not correlate to the number of tracks 12.32.07 # Nah, doesn't seem like it duped again 12.32.27 # it includes every file and directory on the player 12.32.40 # Oh, okay 12.32.51 # 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 # Just coincidence it happened to be almost twice my collection 12.32.55 Join JacekNiesobski [0] (~1faedb6e@giant.haxx.se) 12.32.58 # (maybe a good idea to change it to include just tracks) 12.33.23 # Nope, sideral, just connected then disconnected 12.33.36 # hello everyone 12.34.00 # gevaerts, looks like you were right 12.34.12 # Just fsck'd and ./.rockbox/.playlist_control got flagged 12.34.22 # 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 # No, I definitely saw the dupes in the database 12.34.49 # But I think the playlist thing is unreleated since I just found the filesystem dirty 12.34.57 # alright 12.35.17 # can I ask to be added to the WikiUsersGroup? 12.36.33 # 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 # 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 # Haven't ran into anything like 12228 12.37.50 # Anything helpful I can do if I get the duplication again? 12.37.54 # LIke specifically what to note down? 12.38.01 # 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 # 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 # http://www.rockbox.org/tracker/task/12129 3Duplicate database entries (bugs, unconfirmed) 12.38.13 Quit JacekNiesobski (Quit: CGI:IRC) 12.38.36 # 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 # Okay, will do if it happens again 12.38.50 # that is, all /.rockbox/database*.* files 12.39.02 # cool, thanks! 12.39.20 # 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 # Or if I really could 12.39.52 # Slasheri: Have you seen the dircache-related "crazy idea" session I tortured everyone with two nights ago? 12.40.34 # I think I read through that 12.40.39 # Please don't nix the db, <3 the db 12.41.01 # Slasheri: Might be an entertaining read: http://www.rockbox.org/irc/log-20110816#00:01:31 12.41.37 # sideral: hehe, i read that =) 12.42.54 # sideral: in fact, i thought about block cache implementation before implementing the dircache :) 12.43.13 # GigaBrick: No one plans to remove it, no worries :) 12.43.45 # 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 # 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 # 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 # sideral, 12.47.34 # Just reproduced the db duplication I had earlier 12.48.39 # GigaBrick: dang, there goes my after-lunch nap ;) 12.48.48 # 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 # Would not retrun to main menu or even power down 12.48.56 # So I had to flip the battery 12.49.04 Quit Rob2222 (Ping timeout: 252 seconds) 12.49.06 # Loaded the device on usb and checked my filesystem to make sure that wasn't it again 12.49.23 # 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 # FBI_Guy: Whatever tool scanned them on your PC should also be able to scan them on your player. 12.49.30 # But then when I went to check the database, duplicates 12.49.45 # One thing I noticed that when it was hung, the disk was doing an awful lot 12.50.07 # Llorean: yeah but that takes forever :P (sorry if this is the wrong place ro be asking) 12.50.50 # GigaBrick: OK, please add a comment containing the steps and a copy of your DB to the tracker task 12.51.07 # Okay 12.51.10 # 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 # ah, before you shut down 12.51.35 # can you check in the FS browser whether everything looks OK? 12.51.36 # Yeah, I've got the .rockbox dir open 12.52.09 # Llorean: alright, thanks, I guess ill just scan again 12.53.11 # GigaBrick: enable "view all" in the file browser, and look out for strange file or dir names in the root directory 12.53.40 # Okay 12.53.41 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 12.53.44 # Everything looks right 12.54.04 # OK, that rules out the dircache corruption issue we've had a few revisions ago 12.54.26 # which could lead to loops in the dir hierarchy, which in turn lead to duplicates 12.54.42 # Hmm, interesting.... 12.54.49 # I copied my db before checking the files 12.54.57 # SO when I disconnected I got "Error accessing playlist control file" again 12.55.15 # 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 # 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 # -y 12.56.35 # that's probably an unrelated issue, but worth mentioning in the FS comment anyway 12.56.52 # Yeah 12.56.56 # Maybe you should report a separate bug for this behavior as well 12.57.06 # In fact I ran into the duplication while trying to figure out why the playlist control file was doing that 12.57.18 # I know it's related to a panic that gevaerts fixed 12.57.47 # 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 # 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 # So there's something else going on there 12.58.35 # sound like kind of a crude workaround 12.59.02 # Heh, can't comment, it stops it from panic'ing at least 12.59.27 # 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.01 # 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 # I'll check FS later 13.01.39 # thanks GigaBrick for helping to nail this one down! 13.01.57 # Np 13.02.04 # You still want me to add those steps I took to the FS right? 13.02.22 # yes, please 13.02.59 # Okay... Still have the link in your clipboard, having trouble finding it in the history 13.04.42 # Nvm, found it 13.07.20 Join HaimN_ [0] (~quassel@95.86.116.121) 13.08.26 # "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 # " <-- how is this different from now? 13.08.51 # sideral: ^ 13.09.24 # this is exactly how dircache currently works isn't it? 13.09.35 # pretty much :) 13.10.56 # 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 # Ugh, my forgetfulness is making a mockery of this FS page... 13.22.08 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 13.22.16 # 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 # no 13.23.38 # Weird 13.23.46 # I wonder why I keep getting the "Error accessing playlist control file" 13.24.14 # 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 # 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 # Hi 13.27.15 # can I please get some help on patching Rockbox? 13.27.34 # I installed GnuWin32... 13.27.35 # New commit by 03kugel (r30325): Fix panic after usb extraction if lastfm logging is enabled. ... 13.27.38 # but now what ^^ 13.27.58 # Okay, this is getting really weird now... I just picked up the gigabeat after hitting Initiali database to rebuild my database 13.28.09 # I have the "Error accessing playlist control file" splash 13.29.10 # 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 # GigaBrick: does this happen automatically or do you try tor esume playback? 13.29.29 # This appeared to happen automatically 13.29.37 # I was still in the settings menu for database 13.29.46 # very strange 13.29.59 # r30325 build result: All green 13.30.55 # 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 # Would the system automatically try to resume playback? 13.31.37 # 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 # 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 # somebody willing to help me out? Sorry for my lack of technical knowledge :s 13.35.22 # 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 # kugel, I just patched 30295 with your scrobbler patch and I'm not seeing the same behavior 13.39.28 # 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 # GigaBrick: what kind of playlist did you have? 13.50.11 # playing an m3u by chance? 13.50.25 # Yeah, this time around 13.50.34 # But most of the time I have a dynamic playlist 13.50.41 # I see a possible code path for your problem 13.51.00 # Does it still apply if I get this behavior when using dynamic playlists too? 13.51.05 # can you repro this with a dynamic playlist? 13.51.28 # gevaerts: I thought we had a define for player with no high speed usb 13.51.42 # kugel, yeah, happens with either type 13.52.24 # I found USB_NO_HIGH_SPEED but it seems to be unused 13.52.45 # GigaBrick: can you check if the playlist control thread is active (in view OS stacks debug menu)? 13.53.09 # After I repro or just right now? 13.53.17 # pamaury: yes, I don't think there's more. That was basically debug code 13.53.38 # so all players have high speed usb or hardware usb bridge ? 13.54.08 # As far as I know, yes 13.54.16 # Well, up to now anyway 13.54.31 # GigaBrick: after you repro 13.54.35 # Do we care actually, outside of the driver? 13.55.00 # Okay, I'll have to put the current revision back on 13.55.20 # gevaerts: in the core, for the descriptors 13.55.47 # we report as 1.1 usb when we don't have high speed 13.55.58 # but that's not mandatory iirc 13.56.09 # Ah, yes, the other speed config 13.56.57 *** Saving seen data "./dancer.seen" 13.57.28 # I'd say this is something to do when we actually have a target where it matters 13.58.19 # I have a FS only device 13.58.29 # Ah, you have some work to do then :) 13.59.05 # 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 # I'm not sure either. This is a *long* time ago... 14.00.31 # found: If a full-speed only device (with a device descriptor version number equal to 0200H) receives a 14.00.31 # GetDescriptor() request for a device_qualifier, it must respond with a request error. The host must not make 14.00.31 # a request for an other_speed_configuration descriptor unless it first successfully retrieves the 14.00.31 DBUG Enqueued KICK pamaury 14.00.31 # device_qualifier descriptor. 14.01.00 # right, I think we don't do that yet 14.01.21 # I suspect that's all there is to it 14.03.19 # 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 # Except for packet size: bulk is 64 at FS 14.07.19 # but that's already handled anyway 14.08.21 # kugel, I got the "Erorr accessing playlist control file" to reproduce 14.08.33 # Checked the playlistcachectrl thread and didn't see much of anything 14.08.41 # Changed from T to something, but went so fast I didn't see what it changed to 14.12.42 # Weird, now it's showing the splash while the playlist is actually playing on the WPS screen 14.12.51 # And now it's showing it in the debug menu when I went to check on that thread 14.13.19 # Except now it's doing something weird where it shows up briefly and disappears... :/ 14.14.02 # 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 # okay, I'll do that 14.17.16 Join Rob2222 [0] (~Miranda@p4FFF0504.dip.t-dialin.net) 14.17.33 # GigaBrick: I just wanted to know if it's there 14.17.43 # can you disable dircache and see if it persists? 14.18.02 # Yeah, I'll try that 14.20.14 # Where is that setting located again? 14.20.46 # Oh, under Disk, nvm 14.21.03 Quit Rob2223 (Ping timeout: 250 seconds) 14.23.33 # 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 # did you reboot? 14.24.20 # No, should I? 14.25.02 # you can try 14.25.29 # Okay, I'll reboot and give it a try too 14.26.20 # Yeah, seems to eliminate that splash when dir cache is off 14.26.45 # :\ 14.27.01 # thanks for your debugging, I'll have a look later 14.27.37 # Also, I thought I should mention 14.27.56 # I applied the sleep patch and the scrobbler patch to 30307 14.27.58 # the playlist control thread tries to fetch dircache ids in the background for the filenames, that seems to fail 14.28.05 # STill got the playlist splash 14.28.10 # But for some reason in 30295 I don't 14.28.17 # oh interesting 14.29.22 # 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 # not sure what commit can cause that then 14.30.07 # you did try bumping the sleep time higher in the sleep patch, didn't you? 14.30.22 # Yeah, I had it up to a full second and it didn't make a difference 14.30.27 # Didn't know if I should try any higher though 14.30.39 # Well, a full HZ (I'm assuming that's a second) 14.31.26 # that's a second yes 14.31.56 # Hertz is rolling in his grave at my unsuredness. :P 14.32.52 # Anyway, I suppose I can go up the revisions incrementally from 30295 until I find which one starts reproducing the behavior 14.33.06 # that would be fine :) 14.33.46 # Oh, one quesiton about svn updating 14.33.57 # How can I get it to actually replace a file that has custom modifications? 14.34.35 # not at all 14.34.40 # you need to undo the modifications 14.34.47 # Oh, all right 14.34.49 # e.g. svn revert 14.35.22 # Oh, come to think of it, is there a way to revert back to a specific revision? 14.35.32 # I should probably just man svn... 14.35.56 # svn up -rXXXX 14.37.31 # Oh, cool, it takes care of the changed files too 14.37.37 # All right, that will make this go a lot faster 14.38.29 # it doesn't touch modifications. it tries to merge and abort the update if it doesn't manage 14.38.56 # Hmm... It just replaced my patched ./firmware/usb.c with the one from the svn 14.39.50 # well, it would be news to me if it does that. but I haven't used svn in a long time 14.40.05 # Yeah, I have barely ever used it 15.18.36 # 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 # Do I really have to rebuild rockbox, just to apply a patch? 15.56.53 # 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 # mm, so the way to go is 15.58.00 # installing linux 15.58.08 # which I have already done, virtualbox) 15.58.42 # and rebuilding it there 15.58.54 # patching an already installed rockbox isn't possible? 15.59.02 # I 'm running it on a Cowon D2) 15.59.19 # patches are little changes to source code 15.59.39 # or sometimes big changes... 15.59.45 # heheh 16.00.23 # 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 # okay 16.01.03 # I'm a music lover 16.01.11 # but nowhere a programmer :) 16.01.30 # so it's kind of overwhelming 16.01.50 # 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.01.46 Quit petur (Quit: *plop*) 17.04.21 # Is buffer passed to sd_read_sectors() alligned? 17.08.56 # Not in general 17.09.35 # 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 # even word aligned on ARM? 17.12.59 # hm, I'm not sure actually now. It depends on what the FAT code does 17.18.31 # 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.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.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 # 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 # I get Data abort at the address of the plugin__start when loading plugin - what may cause this? 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.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 # 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 # argh, had some other output filter active. Doesn't work the way I thought :( 21.32.59 # \o/ - I was able to run test_codec on rk27xx :-) 21.36.54 # 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 # which is quite a lot to decode mp3... 21.46.01 # slow RAM? 21.46.34 # 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.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 # 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 # (the s3c2440 manual) 22.17.09 Part lixxus 22.22.19 # Buschel: test_mem says read ~100MB/s, write ~51MB/s, memset ~50MB/s, memcpy 48MB/s 22.23.02 # I don't have any target to compare this results 22.23.27 # is this for IRAM? 22.23.30 # dram 22.24.15 # iram is (almost) useless as it is 4kB or so 22.24.20 # S5L8701 DRAM = 59 read, 35 write, 35 set, 22 copy 22.24.43 # your numbers are similar to S5L8701 IRAM 22.25.42 # Buschel, maybe it's just misconfigured then? 22.25.54 # yep, maybe... 22.26.10 # hmm, so why mp3 decoding takes so much may it be (extremely) slow lcd updates? 22.27.08 # 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 # wodz, if the memory is that slow the filterbank will be slow as well. I think the codec measurement is fine 22.28.56 # wodz, I bet you'll see similar results if you do not update the screen during the test_codec run 22.29.36 # you said s5l8701 dram read 59 vs. rk27xx dram read 100 - I don't get 22.30.49 # most codecs use IRAM for the performance critical parts. IRAM S5L8701 = 107 read, 80 write/set, 45 copy 22.31.54 # so, a bit faster than rk27xx 22.36.18 Quit FBIGuy (Quit: I'm outta here) 22.39.40 # can you configure to use a higher bus clock for the DRAM? 22.40.44 # I can't remember the config 22.42.38 Quit benedikt93 (Quit: Bye ;)) 22.46.57 # sd reads aren't fast also 22.47.30 # what is the CPU clock? 22.47.36 # 200 MHz 22.47.52 # bus clock is 0.5 * CPU clock? 22.48.07 # I think so 22.48.21 # and APB is Fcpu/4 22.49.09 # 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 # 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 # you might for example run test_codec with CPU and AHB at 133 MHz 22.52.21 # dou you already have clock scaling? 22.53.13 # no 22.54.34 # 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 # 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 # the same as reset value stated in manual 23.05.21 # 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 # 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 # 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!")