--- Log for 09.06.114 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 27 days and 19 hours ago 00.00.07 # <[Saint]> (context: soap's proposal was to add a plain text file to govern the desired weighting of random folder advance) 00.00.14 # [Saint]: well, those weighting files either are files, in which case dircache will know about them, or they're not, in which case dircache won't. In the latter case I'll need more details about what they are though 00.01.22 # <[Saint]> Errr...well, yes, it will know the files *exist*, but, not what to do with them, nor, IMO, should it. 00.02.06 # weighing of folders. 00.02.43 # it's random _folder_ advance. Proposal is for a tack-on to the existing system, not a whole cloth deal. 00.02.56 # [Saint]: of course dircache doesn't know what to do with files... 00.03.37 # The plugin which makes the directory list could do the weighing through simple multiplication of entries in the list, then. 00.03.48 # Then the weights would all be > 1 instead of less than 1. 00.03.56 # Yes. That would be the trivial solution 00.04.18 # so you'd set a "default weight", let's call it 10, and then weigh a folder you want to be 20% to a weight of 2 00.04.21 # Well, the plugin could look at what the weights are and rebalance them to what it likes 00.04.42 # But not doing that is easier :) 00.05.32 # if the plugin did it there's no change to the core and no need to worry about where the weight file gets cached if it gets cached. 00.05.59 # <[Saint]> The problem arises when someone pipes up and says "I want this in regular, random playback too!" 00.06.10 # [Saint]: then they get to implement it there 00.06.25 # Random folder advance has *nothing* at all to do with shuffle or things like that 00.07.37 # <[Saint]> Oh, sure. But to the casual observer, having weighting only in RFA would seem like a bloody odd descision. 00.07.43 # Well 00.08.06 # RFA has always been the stepchild, so this would rebalance things a bit :) 00.08.41 # <[Saint]> And, there's the *other* other obvious extension... 00.08.49 # <[Saint]> I'm sure you know which, or can guess. 00.08.56 # <[Saint]> "weighting by rating" 00.09.16 # Sure. The RFA plugin can look at rating tags if you want :) 00.10.06 # <[Saint]> I do have a slight suspicion that very few people care a flying fudge about Rb's rating system - but some may. 00.10.58 # soap: the way RFA works, I think the "have the popular directories more often in the .dat file" is the only reasonable way to do this without reimplementing all of RFA 00.11.38 # [Saint]: anyway, the obvious thing to do is what we've always done. Explain to people that "shuffle" and "random play" are not the same thing :) 00.12.20 # <[Saint]> *pseudorandom play ;) 00.12.44 # That's a third thing! 00.12.54 # <[Saint]> If we're explaining potentially confusing things, we may as well pull out all the cards. 00.13.01 # Exactly 00.13.11 # Card analogies work well to explain shuffling 00.13.59 # <[Saint]> And, technically, pseudorandom playback, I suppose. 00.14.43 # <[Saint]> (in the "each card can be drawn exactly once, and then discarded" vein.) 00.15.58 # <[Saint]> Unless its blackjack, or poker, or the many other games that use multiple decks. 00.16.10 # * [Saint] analogied too hard 00.16.58 *** Saving seen data "./dancer.seen" 00.21.07 # soap: for your particular case, do you usually want to make just a few albums less common, just a few more common, or quite a lot in all directions? 00.21.32 # Also, is having to edit a text file (on a computer, this isn't something to do in rockbox...) acceptable? 00.22.01 # <[Saint]> One could do it with the filename, rather than content, no? 00.22.14 # <[Saint]> .weight_50 etc. 00.22.16 # * gevaerts isn't talking about those 00.22.28 # <[Saint]> Ahhh - then, whoops. 00.22.59 # It's just that right now, you can have the plugin look for directories, save the list to a text file, and import that list again 00.23.21 # If I read the code right, if in between those you duplicate some entries, you've "won" 00.23.38 # That's not a general solution by any means of course :) 00.24.19 Quit ZincAlloy (Quit: Leaving.) 00.24.30 Quit Misanthropos (Quit: Ex-Chat) 00.24.42 Quit pamaury (Ping timeout: 260 seconds) 00.25.04 # <[Saint]> I had a cursory look and I wasn't sure that if you added duplicate entries atthat stage if they would be discarded or not. 00.25.32 # <[Saint]> (browsing git on mobile sucks ass) 00.26.06 # That would be an "advanced" feature. RFA doesn't do advanced :) 00.26.22 # Also, it wouldn't actually *help* any use case, only hinder some 00.30.37 Quit [Saint] (Quit: Page closed) 00.38.09 Quit ender` (Quit: I'm a complex person. I have a real and an imaginary part.) 00.38.57 Part rainbyte ("Leaving") 00.49.12 Quit bluebrother (Disconnected by services) 00.49.17 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 00.52.07 Quit fs-bluebot (Ping timeout: 252 seconds) 00.54.53 Join fs-bluebot [0] (~fs-bluebo@g224239144.adsl.alicedsl.de) 01.12.04 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 01.15.46 Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) 01.15.56 Part zaphee 01.16.14 Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) 01.17.08 Join tertu [0] (~quassel@143.44.65.14) 01.42.27 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) 01.45.08 # sorry I had to step away so abruptly 01.59.20 Join swimllamaswim [0] (185d1dc9@gateway/web/freenode/ip.24.93.29.201) 01.59.28 # Hello, everyone 01.59.59 # I need some help with my iPod classic 6g. 02.03.22 # gevaerts, In _MY_ case I think making about 25% of my collection less common is the end goal. 02.03.43 # editing a text file is quite acceptable, and I think I see where you're going. 02.04.14 # Hello 02.07.19 # swimllamaswim: please just ask whatever question you have 02.08.39 # When I open rockbox, I have to disconnect my ipod to do anything. It says (Not Responding). When I open the dialogue box to select my mountpoint and device, no mountpoints are shown. Not even C:\ 02.09.48 # you mean that explorer doesn't show any drives as long as your ipod is connected and running rockbox? 02.10.05 # try manually starting the rockbox fallback image from emcore's "tools" menu (the last icon) 02.10.29 # that will usually behave better on windows systems. this is a known issue that we're currently looking into. 02.10.38 # Explorer shows it, but I'll try that 02.10.53 # (when running the fallback image, you won't be able to play music until you boot back into normal rockbox) 02.11.33 # should I restart the rockbox utility? 02.12.30 # oh wait, I think we might be talking about different things 02.12.37 # can you describe in more detail what you were trying to do? 02.12.57 # are you still doing the initial installation, or trying to do an update, or what? 02.13.26 Join teythoon_ [0] (~teythoon@mail.jade-hamburg.de) 02.14.09 # I'm trying to install rockbox. I have emCore installed, and the fallback image RUNS, but when I connect it to install, the utility freezes, then I have to reconnect the ipod to do anything. It shows the device in explorer, but not as a mountpoint in the utility 02.14.40 # so you can successfully access it using explorer? 02.15.05 # it says I need to format it, but it shows up (and it has the ipod as the icon) 02.15.18 # that doesn't sound good at all 02.15.34 # try reformatting the data partition using emcore's tools menu, and check if it still says that 02.15.43 # I've tried it on two computers, same thing 02.15.48 # I already did that, twice 02.16.00 # and reinstalled emcore twice as well 02.16.18 # very weird... what happens if you let windows attempt to format it? (as FAT32, not NTFS or exFAT) 02.16.27 Quit teythoon (Ping timeout: 276 seconds) 02.17.01 *** Saving seen data "./dancer.seen" 02.17.11 # I havent tried that yet (that I can remember. I've been trying this for a few weeks.) 02.19.17 # It froze the file explorer 02.19.45 # which exact model of ipod is this? which capacity and year of manufacturing? 02.20.07 # how long does formatting it through emcore take? 02.20.14 # 80gb 6g (I think it is a 2009, could be 2008) 02.20.29 # emcore usually takes 5-10 minutes, somewhere in there 02.20.51 # ouch 02.20.59 # this should be more like 20 seconds or so 02.21.11 # hmm 02.21.24 # do you hear a lot of clicking noise from the drive during that? 02.21.50 # Let me run it again, ill tell you 02.22.36 # the behavior that you're reporting fits a damaged HDD quite well... 02.22.48 # and it's quite common for these old 80gb drives to fail these days 02.23.02 # they seem to somehow degrade over time 02.23.29 # there isnt a lot of clicking, a little, but not a ton 02.23.41 # about as much as normal usage 02.23.49 # repeated clicking patterns, about one click per second? 02.24.14 # (or sometimes a pair of them) 02.24.19 # no, a few quick ones every few seconds 02.24.38 # ok, now it sounds like its turning off 02.24.59 # the formatting code accesses the disk in a very linear fashion. there shouldn't be any audible head movement at all during that 02.25.13 # were there any issues at all with this ipod before installing emcore? such as taking unusually long to start playback of a track sometimes? 02.25.15 # it comes back on, for about 2 min, and does it again 02.25.31 # as in completely spinning down for a few seconds? 02.25.49 # no, the reason I'm doing this is I accedentally disconected it while tranfering music 02.25.50 # does it make a violent click and "whining" spindown noise before that? 02.26.01 # yeah 02.26.26 # thats it 02.26.38 # not a good sign at all, this means that it had to recover from a state where the drive completely locked up and refused to accept any further commands 02.26.57 # i.e. the ipod had to forcibly cycle the drive's power without being able to properly stop the drive first 02.26.57 # hmm... so its probably broken? 02.27.03 # sounds like it, yes 02.27.12 # EHHH 02.27.21 # stupid apple products 02.27.21 # what do you mean with " no, the reason I'm doing this is I accedentally disconected it while tranfering music"? 02.28.08 # in this case you should probably blame toshiba for manufacturing HDDs that, from what it looks like, degrade their servo information over time 02.28.15 # the reason I'm installing rockbox was that I accedentally disconnected it while transfering music, it erased everything, and itunes quit while restoring it 02.28.32 # I've been observing the behavior of one of those affected disks for a few years now, and it is getting continually worse 02.28.33 # well, I just dont like apple in general 02.28.39 # * TheSeven neither 02.28.48 # better warn my dad, he has the same one 02.29.12 # "itunes quit while restoring it" is also already a sign of this drive problem 02.29.35 # yet, my old 3g ipod works great (except for the battery, it needs a new one) 02.29.47 # it has rockbox 02.30.07 # depending on how bad the damage already is, you might have luck working around it for a while using some special tools which try to identify the bad blocks and avoid using them 02.30.23 # however this will usually work for a while, until even more damage crops up 02.30.50 # the one that I'm observing is still alive and usable, but during a recent re-scan of the damage it became clear that it is now spreading out all over the disk surface 02.31.10 # well, I think I have a warrenty on it (I bought it used a few months ago) 02.31.44 # try returning it then. if you don't have success with that, feel free to contact me about that workaround 02.32.36 # In case you're not on, can you give me your email? I'm on vacation right now, it'll be a while before I can return it 02.33.05 # I'm usually connected 24/7, although I might not respond immediately 02.33.35 # ok, I'm going to be back home next tuesday 02.34.23 # I'm in the UTC+2 time zone, typically available in the late evening 02.36.47 # so eastern european time then? 02.40.41 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 02.41.07 # central european + daylight savings 02.41.31 # (CEST) 02.44.16 Quit bertrik (Remote host closed the connection) 02.48.36 Join sakax [0] (~sakax@unaffiliated/sakax) 02.49.57 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 02.51.26 Quit swimllamaswim (Ping timeout: 246 seconds) 03.00.00 Quit AlexP (Remote host closed the connection) 03.29.09 Join [Saint] [0] (7cc51487@rockbox/staff/saint) 03.31.23 Quit cmhobbs (Quit: Leaving) 03.31.36 Join cmhobbs [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 03.31.36 Quit cmhobbs (Changing host) 03.31.36 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 03.47.22 Quit cmhobbs (Remote host closed the connection) 04.01.00 Join Cinos [0] (Cinos@cinos.biz) 04.04.12 # I have a Sansa Clip Zip with Rockbox 3.13 (updated yesterday) and I notice that my screen is turning itself on about 5 seconds before the end of a song without me pressing any buttons. I want to disable this because it will only end up draining my battery when I don't press any buttons for a long period of time, but I can't seem to find any information on this functionality even existing, and 04.04.12 # I can't find any setting for it in the menus. 04.07.47 # <[Saint]> One minute. 04.07.52 # <[Saint]> I'll be with you shortly. 04.10.30 # <[Saint]> Cinos: you have enabled "Caption Backlight" 04.10.44 # <[Saint]> Settings - General; Settings - Display - Caption Backlight 04.10.53 # <[Saint]> Disable it. 04.10.57 # One moment 04.11.07 # <[Saint]> It might be worth reading out fine manual. 04.11.12 # <[Saint]> *our 04.11.43 # I dont' see "caption backlight" 04.11.45 # don't* 04.11.55 # oh, never mind 04.11.58 # It's under LCD settings 04.12.06 # <[Saint]> Ah, sorry. 04.12.07 # Thank you 04.12.10 # <[Saint]> I was working from memory. 04.12.23 # for at least pointing me in the right direction because I honestly had no idea what to call that feature 04.12.32 # <[Saint]> I highly advise updating the Rockbox binary to the development version. 04.13.06 # <[Saint]> The stable release is over a year old, and the "stable" classification is rather misleading. 04.13.44 # <[Saint]> By using the release build, you're essentially disregarding over a years worth of bugfixes, additional features, and general improvements. 04.13.44 # Well I do have to say it was an upgrade over whatever the MP3 player had on it previously, then again this was probably over a year ago (it was back when the Clip Zip port was still classified as being 'unstable') 04.14.38 # Maybe that will help with the issues I'm having just connecting the mp3 player to my computer (tons of crashes) 04.14.50 # <[Saint]> stable/unstable/unusable are pretty much meaningless to users - unless the read the detailed explanation of the classification requirements, which very little people seem to so. 04.15.43 # <[Saint]> "stable", doesn't necessarily mean it will be stable, or bug free. "unstable" doesn't necessarily imply theere will be bugs, or the system will be unstable at all, and nor does "unusable" imply it cannot be used. 04.15.51 Join ygrek [0] (~user@108.59.6.97) 04.15.54 # <[Saint]> I do admit this is highly confusing. 04.17.02 *** Saving seen data "./dancer.seen" 04.18.21 # <[Saint]> A port can be "unstable" simply because it has no documentation, for instance. 04.25.46 # Okay, upgraded to the dev build. Thanks again for the help and suggestions 04.27.04 # <[Saint]> Your USB issues _should_ be resolved. 04.27.36 # <[Saint]> If not, it is important to nate that one can easily boot the OF and use it to handle USB transfer. 04.27.52 # I know that. That's how I upgraded initially 04.28.08 # <[Saint]> (it is also important to note that this is only a Windows thing - Linux/Mac "Just Works") 04.28.35 # Because Windows 7 x64 was initially not recognizing the device at all when it was booted into RockBox, but worked fine on the original firmware. 04.28.42 # <[Saint]> What Windows is or isn't doing sifferently, or how exactly we're pissing it off, is still an unknown to my knowledge. 04.28.53 # <[Saint]> *differently 04.29.36 # The problem I had more recently was that the device was showing up but not accessible (trying to access it would result in Explorer loading it indefinitely). Also, Rockbox would crash a lot of the time when plugged into a computer 04.29.57 # <[Saint]> FOr lack of a better explanation - USB is essentially voodoo 04.30.15 # <[Saint]> There are so many opportunities for the clinet, or host, or both, to fuck something up. 04.30.25 # <[Saint]> *client 04.30.54 Quit amiconn (Disconnected by services) 04.30.54 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.30.56 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.31.19 Quit pixelma (Ping timeout: 240 seconds) 04.31.20 # <[Saint]> Linux seems to be a lot more permissive/tolerant (or, sane?) in this regard when compared to Windows. 04.31.27 # <[Saint]> For our purposes at least. 04.31.28 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.31.34 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.31.53 # <[Saint]> I think the issue is somewhat compounded by the fact that very few developers use Windows unless the absolutely have to. 04.32.35 # <[Saint]> And also that it is problematic to reliably trigger a fault. 04.32.36 # Yeah, it seems completely random what will work and what won't work. If I plug my MP3 player into my desktop's front USB port, it says that it can perform faster if plugged into a USB 2.0 port (even though both the device and port are 2.0), but plugging it into a hub that then plugs into a rear port works fine. 04.33.46 # <[Saint]> Front case USb ports are usually *very* shitty quality, and it isn't uncommon to see USB 1.1 ports in the front, even in reasonably modern machines (of lesser quality). 04.34.19 # I thought of that possibility, but Windows itself didn't show any USB ports that didn't support 2.0 04.34.26 # And no other devices give me this issue 04.35.35 # But yeah, in a case like that, I can just boot into the OF and transfer files/perform upgrades that way, so it's not really that big an issue. 04.35.40 # * [Saint] puts on his speculating hat 04.35.46 # <[Saint]> It may be a power issue 04.36.15 # <[Saint]> I have seen many times front panel USB ports that are unable to provide 500mA to a single port, let alone several. 04.36.33 # <[Saint]> Spec compliance in USb hardware is a very rare thing. 04.36.48 # That could be, since I had the same issue on a laptop, and laptops are known for not pushing the typical power of a USB port 04.37.30 # <[Saint]> It is incredibly rare to find a machine that doesn't mess up on *some* aspect of USb spec. 04.37.57 # I have another device that runs RockBox that has similar problems. The device tends to crash when transferring files for an extended period of time (i.e. transferring many songs at once) 04.38.15 # And the transfers run incredibly slow, usually lower than that of USB 1.0 04.38.26 # <[Saint]> Is it a HDD based device, or flash based? 04.38.27 # *than the maximum transfer speed of 1.0 04.39.40 # Flash, I'm pretty sure. Also, most of the time I would be transferring to a MicroSD card 04.40.34 # <[Saint]> Ah, Hmmm. The reason I ask is that with some HDD based devices, with the LCD on and the HDD spun up, even if connected via USb the device will actually be discharging. 04.41.05 # <[Saint]> In your case, it seems to point a finger towards filesystem corruption. 04.41.26 # <[Saint]> It may be worthwhile checking the volume for errors. 04.41.45 # I should at least try to recreate the issue on my other device (same MicroSD card) 04.42.40 # Well, it crashed before I even did anything. That's a nice start 04.42.58 # <[Saint]> The symptoms you describe sound very much like indicators that all is not well in filesystem land. 04.43.51 # <[Saint]> Do you safely eject the device, or opt for the usual "yank the cord and hope" method? 04.44.10 # <[Saint]> (hint: don't do the latter - always safely eject removable storage volumes) 04.44.23 # Usually do the latter, so that might be the issue 04.45.07 # <[Saint]> Without safely ejecting, there's no way to actually guarantee that the files beinf transferred were sucessfully written out to the device. 04.45.30 # <[Saint]> Some or all of the transferred files may still be sitting in the write cache. 04.45.45 # Yeah, I have noticed a lot of corrupted music files 04.46.04 # <[Saint]> Well, at least now you know why. :) 04.46.20 # <[Saint]> This has been a reasonably productive conversation. 04.46.23 # <[Saint]> I like these. 04.47.02 # Okay, I scanned and repaired both using Windows' internal disk check function (I'm not really sure how well that works, though) 04.48.31 # Er, both being the MicroSD card and the device's internal memory. 04.54.17 # <[Saint]> Indeed. Using the Windows-native chksdk function is entirely adequate. 04.54.48 # <[Saint]> Not terribly verbose, but perfectly adequate. 04.57.04 Quit tertu (Ping timeout: 260 seconds) 05.02.49 Join cmhobbs [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 05.02.49 Quit cmhobbs (Changing host) 05.02.49 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 05.02.50 Join cmhobbs_ [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 05.03.26 Quit cmhobbs_ (Client Quit) 05.03.29 Quit cmhobbs (Client Quit) 05.03.41 Join cmhobbs [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 05.03.41 Quit cmhobbs (Changing host) 05.03.41 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 05.05.03 Quit steffengy (Disconnected by services) 05.05.04 Join steffengy1 [0] (~quassel@p5088F69B.dip0.t-ipconnect.de) 05.17.54 Join tertu [0] (~quassel@143.44.65.14) 05.19.27 Quit Provel (Ping timeout: 260 seconds) 05.20.10 Join Provel [0] (~Provel@75-132-32-77.dhcp.stls.mo.charter.com) 05.36.16 Quit TheSeven (Ping timeout: 260 seconds) 05.37.43 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.40.51 Quit tertu (Ping timeout: 265 seconds) 05.56.07 Quit Strife89 (Ping timeout: 240 seconds) 06.17.05 *** Saving seen data "./dancer.seen" 06.25.19 Quit tchan (Ping timeout: 240 seconds) 06.40.30 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 07.16.39 Quit [Saint] (Quit: Page closed) 07.19.49 Join tertu [0] (~quassel@143.44.65.14) 07.27.52 Quit ygrek (Remote host closed the connection) 08.11.55 Join [Saint] [0] (7cc51487@rockbox/staff/saint) 08.17.09 *** Saving seen data "./dancer.seen" 08.19.11 Join mortalis [0] (~kvirc@213.33.220.118) 08.22.47 Join ygrek [0] (~user@108.59.6.97) 08.25.31 Quit tertu (Ping timeout: 240 seconds) 08.25.47 Join ender` [0] (krneki@foo.eternallybored.org) 08.37.20 Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 08.59.40 Quit [Saint] (Ping timeout: 246 seconds) 09.15.09 Join [Saint] [0] (7cc51487@rockbox/staff/saint) 09.51.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.58.32 Quit kiwicam (Ping timeout: 240 seconds) 10.00.24 Join kiwicam [0] (~quassel@121-99-189-240.bng1.nct.orcon.net.nz) 10.01.02 Quit Topy44 (Ping timeout: 240 seconds) 10.01.19 Join model|gone [0] (~model@cscluster.minotstateu.edu) 10.01.40 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 10.02.41 Quit kugel (Remote host closed the connection) 10.02.49 Join Topy44 [0] (~Topy44@93.190.93.215) 10.04.54 Quit model|afk (Ping timeout: 240 seconds) 10.06.17 Quit copper (Ping timeout: 240 seconds) 10.07.05 Quit tchan (Ping timeout: 240 seconds) 10.11.01 Quit Cinos (Ping timeout: 240 seconds) 10.13.36 Join Cinos [0] (Cinos@cinos.biz) 10.13.54 Quit ygrek (Remote host closed the connection) 10.15.04 Quit Bluefoxicy (Ping timeout: 240 seconds) 10.15.16 Join Bluefoxicy [0] (~Bluefoxic@c-76-21-157-203.hsd1.md.comcast.net) 10.17.11 *** Saving seen data "./dancer.seen" 10.19.57 Join copper [0] (~copper@unaffiliated/copper) 10.20.51 Quit Galois (Ping timeout: 240 seconds) 10.22.13 Join rela [0] (~x@pdpc/supporter/active/rela) 10.22.19 Quit kugel_ (Remote host closed the connection) 10.22.20 Quit copper (Client Quit) 10.23.40 Join copper [0] (~copper@unaffiliated/copper) 10.29.53 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 10.34.13 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 10.34.31 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 10.41.01 Quit rela (Read error: Connection reset by peer) 10.53.13 Quit jhMikeS (Ping timeout: 276 seconds) 11.01.38 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 11.01.38 Quit bertrik (Changing host) 11.01.38 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 11.07.20 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.11.47 Join rela [0] (~x@pdpc/supporter/active/rela) 11.14.38 Quit Cultist (Ping timeout: 240 seconds) 11.17.02 Join Cultist [0] (~CultOfThe@c-98-223-211-32.hsd1.il.comcast.net) 11.23.56 Quit kugel_ (Ping timeout: 245 seconds) 11.29.19 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.33.15 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.37.04 Quit rela (Read error: Connection reset by peer) 11.37.07 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 11.38.17 Quit copper (Ping timeout: 240 seconds) 11.43.48 Quit [Saint] (Ping timeout: 246 seconds) 11.53.53 Join copper [0] (~copper@unaffiliated/copper) 12.10.50 Quit kugel (Ping timeout: 252 seconds) 12.16.49 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 12.17.15 *** Saving seen data "./dancer.seen" 12.17.54 Join ygrek [0] (~user@108.59.6.97) 12.24.17 Join rela [0] (~x@pdpc/supporter/active/rela) 12.24.37 Part zaphee 12.31.48 Join kugel [0] (~kugel@p5DC528D7.dip0.t-ipconnect.de) 12.31.48 Quit kugel (Changing host) 12.31.48 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.50.10 Quit ygrek (Remote host closed the connection) 12.53.10 Quit rela (Quit: Leaving) 12.59.57 Join rela [0] (~x@pdpc/supporter/active/rela) 13.05.38 Quit kugel (Quit: leaving) 13.27.41 Quit igitoor (Ping timeout: 245 seconds) 13.29.46 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 13.33.48 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) 13.34.13 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 13.34.56 Quit dfkt (Read error: Connection reset by peer) 13.36.52 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.45.03 Quit igitoor (Changing host) 13.45.03 Join igitoor [0] (igitur@unaffiliated/contempt) 13.50.53 Quit dfkt (Read error: Connection reset by peer) 13.52.48 Join dfkt [0] (OxO29A@unaffiliated/dfkt) 13.59.38 Quit dfkt (Ping timeout: 265 seconds) 13.59.51 Join tertu [0] (~quassel@143.44.65.14) 14.17.18 *** Saving seen data "./dancer.seen" 14.30.10 Quit TheSeven (Ping timeout: 252 seconds) 14.31.26 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 14.35.35 Quit yosafbridge (Quit: ERC Version 5.3 (IRC client for Emacs)) 14.39.40 Quit rela (Quit: Leaving) 14.40.43 Quit cmhobbs (Ping timeout: 276 seconds) 14.40.47 Join yosafbridge [0] (~yosafbrid@192.241.198.49) 14.41.53 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.58.35 Join Geoff_ [0] (~qua@192.3.27.126) 14.59.26 Join einhirn [0] (~Miranda@p3E9E7128.dip0.t-ipconnect.de) 15.00.22 Quit einhirn (Client Quit) 15.09.20 Quit wodz (Remote host closed the connection) 15.14.49 Quit sulky (Read error: Connection reset by peer) 15.16.11 Join sulky [0] (sulky@gateway/shell/cadoth.net/x-jcgdzgeqmxafqkgd) 15.21.29 Join ZincAlloy [0] (~Adium@pD9EEA12D.dip0.t-ipconnect.de) 15.26.42 Join Scr0mple [0] (~Simon@161.43.73.67) 15.26.43 Quit Scromple_ (Read error: Connection reset by peer) 15.38.43 Quit TheSeven (Ping timeout: 260 seconds) 15.40.07 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 15.48.28 Join Strife89 [0] (~Strife89@adsl-98-80-200-103.mcn.bellsouth.net) 16.17.19 *** Saving seen data "./dancer.seen" 16.33.44 Quit Strife89 (Ping timeout: 252 seconds) 16.59.38 Quit Zagor (Quit: Clint excited) 17.37.15 Quit Mir (Quit: OH MAI GOD! Death wants to go to the park and he has cookies! what a nice death!) 17.46.02 Join AlexP [0] (~alex@rockbox/staff/AlexP) 18.05.23 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 18.17.22 *** Saving seen data "./dancer.seen" 18.19.05 Join rela [0] (~x@pdpc/supporter/active/rela) 18.19.53 Quit sakax (Read error: Connection reset by peer) 18.20.48 Join sakax [0] (~sakax@unaffiliated/sakax) 18.39.57 Join einhirn [0] (~Miranda@p3E9E7128.dip0.t-ipconnect.de) 18.44.17 Quit einhirn (Ping timeout: 240 seconds) 18.52.40 Quit mc2739 (Ping timeout: 245 seconds) 18.53.12 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 19.14.45 Join b0hoon [0] (~quassel@public-gprs480221.centertel.pl) 19.36.20 Quit y4n (Quit: We're fucking 3LN!) 19.40.10 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 20.17.26 *** Saving seen data "./dancer.seen" 20.27.43 Join RiD [0] (RiD@2.83.226.139) 20.52.42 Quit TheSeven (Disconnected by services) 20.52.58 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 21.14.42 Quit the-kyle (Ping timeout: 260 seconds) 21.19.21 Quit y4n (Ping timeout: 245 seconds) 21.29.46 Quit rela (Quit: Leaving) 21.30.33 Quit [7] (Disconnected by services) 21.30.49 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 21.39.05 Join the-kyle [0] (~kyle@kyle.tk) 21.50.11 Quit igitoor (Ping timeout: 260 seconds) 21.58.11 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 22.04.19 Join Jinx [0] (Dojo@unaffiliated/jinx) 22.08.28 Join Strife89 [0] (~Strife89@adsl-98-80-200-103.mcn.bellsouth.net) 22.15.27 Quit igitoor (Changing host) 22.15.27 Join igitoor [0] (igitur@unaffiliated/contempt) 22.17.29 *** Saving seen data "./dancer.seen" 22.18.26 Quit pamaury (Ping timeout: 265 seconds) 22.19.45 Quit guymann (Remote host closed the connection) 22.20.11 Join guymann [0] (~c@unaffiliated/guymann) 22.21.16 Quit TheSeven (Ping timeout: 264 seconds) 22.22.32 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 22.27.46 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 23.02.30 Quit TheSeven (Ping timeout: 260 seconds) 23.04.14 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 23.06.57 Quit amayer (Quit: Leaving) 23.19.10 # Build Server message: 3New build round started. Revision 43f10db, 253 builds, 33 clients. 23.22.56 Quit Strife89 (Ping timeout: 252 seconds) 23.23.15 # Build Server message: 3Build round completed after 247 seconds. 23.24.40 Join sakax_ [0] (~sakax@78-23-252-57.access.telenet.be) 23.24.40 Quit sakax_ (Client Quit) 23.25.50 Part b0hoon ("GTG... Bye.") 23.53.06 Join einhirn [0] (~Miranda@p3E9E7128.dip0.t-ipconnect.de) 23.57.46 Quit einhirn (Ping timeout: 252 seconds)