--- Log for 16.08.111 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 14 hours ago 00.00.21 # I'm just not at the laptop but chatting from ny phone 00.01.31 # ah OK. so are you ready for my mind-boggling idea? 00.05.17 # yes :-) 00.06.08 # so here it comes: Let's reduce the complexity of the dircache by... 00.06.13 # ...abolishing it! 00.06.30 # Let's use the plenty of space we get for an LRU block cache 00.06.59 # With dircache off, playlist generation can take orders of magnitude more time on some disk targets. 00.07.19 # Lots of dircache-related code will just vanish in exchange for some small hashing complexity in the block cache 00.08.02 # The bet is that going through the filesystem into the block cache wouldn't be much slower 00.08.20 # And you have to wait a number of seconds for the disk to spin up before browsing 00.08.27 Quit petur (Quit: Leaving) 00.08.48 # Well no, the idea is to have the relevant data cached in the block cache 00.08.55 # OK 00.09.03 # AlexP_: I don't see initial spinup as a huge deal, though I will admit it saves a small amount of battery that the disk doesn't have to spin at all if you accidentally browse, and didn't mean to, or whatnot. 00.09.08 # I don't care how you do it as long as the effect is the same :) 00.09.10 # sideral: not sure 00.09.11 # presumably you wouldn't read data blocks into the cache? 00.09.23 # AlexP_: But waiting 10s or 100s of seconds for a large playlist to populate sucked. 00.09.24 # Torne: definitely not the audio data. 00.09.36 # Llorean: It makes a pause of 3 or 4 seconds on some targets. Every time you start browsing 00.09.41 # The filesystem would have to hint the caching scheme to the block layer 00.09.46 # sideral: well, very little gets read repeatedly except via buffering 00.09.55 # AlexP_: Yeah, I remember. :) But 3 or 4 seconds isn't that long unless you stop and start browsing very frequently. 00.10.02 # it would be LRU for directory entries / FAT, and don't care for most of everything else 00.10.07 # I tend to 00.10.09 # Or if your spindown time is too low for your habits. 00.10.20 # And 3 - 4 seconds was a huge time then 00.10.20 # the dircache works well for our not-general purpose file systems no? 00.10.38 # sideral: i can't help but think this will use more ram for less benefit 00.10.44 # AlexP_: We already optimize some things (buffering whole songs, rather than just the starts of several) based on the idea people typically listen to stretches of music, rather than constantly changing. 00.10.45 # wel, or the same amount of ram for less benefit. 00.11.04 # And the problem with spin down time is that if you turn it up for the few occasions when it would be needed, you waste battery all the time 00.11.08 # and maintaining the lru is probably more complete than the dircache 00.11.17 # That's something that needs to be substantiated for sure 00.11.27 # the dircache is more dense than a block cache of the directory data ont he disk 00.11.30 # let alone the FAT 00.11.31 # Llorean: Having to wait a few seconds even every half an hour or so is very annoying 00.11.39 # kugel: No, maintaining LRU is easy and fast, as is hashing 00.11.52 # AlexP_: Yes, it's annoying. But I don't think it's a big deal if that's the *only* cost to improve other areas. 00.11.57 # I do 00.12.06 # Well, depends on the improvements 00.12.20 # Yes, it depends on the improvements. 00.12.21 # But they'd have to be enormous 00.12.28 # I don't think they'd have to be enormouse. 00.12.32 # I do :) 00.12.38 # They'd just have to be one less annoyance ever 30 minutes 00.12.47 # Especially as we have dircache now 00.12.49 # Or, less bugs due to dircache complexity. 00.13.03 # sideral: not if I look at our font code :-) 00.13.14 # It'd be a major step back 00.13.16 # But it'd be unacceptable to go back to the time of counting dynamic playlist generation time in minutes. 00.13.28 # I don't care about that, I don't use them 00.13.32 # * Llorean really doesn't see 3 seconds once or twice an hour "major" at all. 00.13.36 # The block cache likely wouldn't be as effective as the dircache is today out of the box. But the gain is vastly less complex code in all the dircache clients 00.13.39 # See, it all depends what matters to you 00.13.59 # I just don't want to have to go back to waiting for spin up on browsing 00.14.00 # In an objective sense, waiting 3 seconds for an operation vs waiting 3 minutes is pretty significantly differenct. 00.14.06 # the "dircache clients"? 00.14.06 # and we'd have fewer bugs for sure :) 00.14.13 # In fact, that would just lead me to not updating Rockbox anymore 00.14.17 # the dircache guarantees that browsing doesn't need to touch the disk (under normal circumstances) 00.14.28 # kugel: everything that does special stuff with the dircache, especially the database 00.14.36 # I can't see how a block cache can be effective, you would need to re-read the disk on many occasion contrary to dircache 00.14.37 # a block cache would not, even if it did improve other things somewhat 00.14.40 # I really doubt it would reduce complexity 00.14.47 Join drezon [0] (~drezon@2001:6f8:1029:2:1a3d:a2ff:fe60:4ae0) 00.14.48 # sideral: I'd imagine the best idea would be to show a proof of concept that it actually improves things, rather than making them worse. 00.15.05 # Llorean: sure. This is only a thought experiment so far :) 00.15.20 # There's one major problem with my idea that I see: 00.15.23 # It certainly sounds like the idea would sacrifice some of the benefits of dircache for gaining improvements on the non-user-visible side. 00.15.26 # That doesn't seem a win. 00.15.30 # exactly 00.15.45 # the block cache is what Linux does isn't it? 00.15.50 # well, bugs and crashes are user visible :) 00.15.55 # sideral: But fixable. 00.16.05 # currently virtually all of our disk accesses come down to two categories: directory accesses and buffering 00.16.13 # the former is more efficiently served by the dircache 00.16.14 # Whereas the flaws in using a different sort of cache that doesn't handle the same things aren't really, without probably bringing in another set of complexities and bugs anyway 00.16.19 # the latter is not really served by caching at all 00.16.37 # dircache works rather well; it's a bit unstable recently due to kugel fiddling with it but appart from that... :) 00.16.41 # I agree with Torne 00.16.53 # So the major downside I see is that the database would have to keep the file names itself rather than just storing dircache IDs, which would eat a large part of the memory benefit 00.16.59 # arguments about complexity/etc seem uninteresting 00.17.12 # I don't think we should implement something worse because we think we can implement it more reliably 00.17.19 # we should just try harder to implement the best thing *right* :) 00.17.26 # * Llorean agrees with Torne 00.17.29 # me too 00.17.50 # our storage usage is very unlike a normal OS :) 00.18.00 # No disagreement there :) 00.18.13 # and not forget HD and non-db users :) 00.18.21 # Or, at the same time remove db load to RAM :) 00.18.25 # we're not general purpose; so my usual assumption is we can do better than a general purpose solution to virtually *every* problem 00.18.37 # And imho the dircache code is not *that* complicated, compared to other pieces of code we have 00.18.40 Quit ptrkmj (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110615151330]) 00.18.50 # I wouldn't mind a way to rule out folders from the dircache, if we need to recover some RAM. A way to mark no-media files folders. 00.19.06 Join Scromple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 00.19.06 # pamaury: The dircache itself isn't, but the dircache clients suffer enormous complexity 00.19.24 # which "enormous complexity" ? 00.19.58 # pamaury: For example, the DB has a combination of #ifdef hell and if-the-else disease because of the dircache 00.20.11 # and I've found a few bugs in there recently 00.20.17 # I'm sure there are more lurking :) 00.20.31 # right, but the database is 1) complicated anyway and 2) not used by as many people :) 00.20.44 # the database is one of the worst pieces of code 00.20.45 # i realise you care about it, but if that's your only example then i suspect we are willing to take that hit :) 00.20.51 # I thought it would be cool if that could be hidden below the POSIX layer :) 00.21.06 # Right, but it can't be, without costing more ram 00.21.12 # I wouldn't want anyone to take a hit Torne :) 00.21.29 # Then don't make me suffer spin up times etc. :) 00.21.32 # And RAM is most important on targets where Dircache is most beneficial. 00.21.33 # the tagcache sharing filenames with the dircache is a memory win that i can't see how ou can achieve without having the one fiddle with the innards of the other 00.21.50 # we already have a POSIX interface, the problem is that you can have the full benefit of dircache without being dircache-aware; that's a kind of obvious statement no ? 00.21.58 # Torne: The RAM use could be optimized as well by storing a compressed version of the directory blocks in the block cache, much in the vein of dircache 00.22.02 # *can't 00.22.20 # (or maybe in the FS layer rather than in the block cache) 00.22.33 # The directory blocks will *always* use more space, though 00.22.34 # but memory blocks use a horribly complicated structure due to FAT 00.22.48 # as pamaury says 00.22.49 # also fragmentation 00.23.51 # just have a look at the FAT code which reads directory, that's a disaster, you basically have a rebuild every string so even if you don't loose space, you loose time 00.24.05 # re the DB using dircache IDs as filename references: This service could be offered by the FAT FS as well 00.24.17 # sideral: How? 00.24.25 # How do you have stable identifiers for things in a LRU cache? 00.24.28 # you would end up with dircache ! 00.24.41 # You can't evict things and still know what those identifiers mean 00.24.45 # Torne: It'd have to be partition-relative 00.24.59 # huh? 00.25.05 # you mean have the identifier refer to the physical location on the disk? 00.25.10 # that doesn't work if you, er, ever write to the disk :) 00.25.17 # pamaury: Don't think so, as the blocks could be reread if they were evicted 00.25.37 # but how do you assign identifiers ? 00.25.46 # directory entries basically never change their disk offset in FAT 00.25.52 # Er 00.25.54 # Sure they do 00.25.55 # Delete file. 00.25.58 # rename 00.25.58 # Et voila :) 00.26.04 # Or, yeah, rename it 00.26.06 # to somethign longer 00.26.11 # not even 00.26.28 # anyway, yeah, simplest case: delete file 00.26.31 # the fat code is stupid, it doesn't reuse entries iirc 00.26.42 # (not all the time) 00.27.12 # delete file is unimportant I think, the DB doesn't need IDs for deleted files (doesn't work with dircache either) 00.27.21 # pamaury: OK 00.27.31 # it was just an idea :) 00.27.51 # To be honest I've thought about this problem a long time ago for MTP and concluded that dircache (or similar) was the only real solution 00.28.34 # I'm not so pessimistic that we could synthesize something like an inode number for FAT files 00.28.49 # er 00.28.52 # People have tried this before 00.28.54 # it hasn't worked 00.28.54 # it doesn't have to be perfect, just enough for our used cases 00.29.10 # s/used/use/ 00.29.16 # inodes work because they never have to move :) 00.29.16 # sideral: Would it let you browse, build playlists etc. without spinning up the disk? 00.29.22 # FAT direntries move all the time 00.29.26 # the dircache is just enough for our use cases :-) 00.29.42 # AlexP: the idea would be that everything you need frequently is already in the cache. :) 00.30.04 # I believe the problem lies in the DB code, it should be written in a way which abstract from these tricky details 00.30.04 # I need to be able to browse potentially any of the files/directories on disk frequently 00.30.34 # AlexP: then you need to prime your cache well :) 00.30.42 # This sounds much worse 00.30.50 # pamaury: not sure you can sensibly abstract exploiting the dircache 00.30.51 # Not everything is about the DB 00.31.06 # you have dircache ids or... nothing 00.31.09 # Yeah, I'm aware of that AlexP 00.31.12 # File browsing is a primary function, and there are many HD targets 00.31.26 # So we should not make other things worse for the sake of the DB 00.31.57 # sideral: look at this from my ipodvideo64mb's POV 00.32.01 # I don't use the db 00.32.04 # I suppose we could prime it by just going reading the dir hierarchy once 00.32.06 # The DB uses optimization for names (basically) so you can abstract from the method used to store a name 00.32.09 # I can browse the entire fs without a slow expensive spinup, guaranteed 00.32.15 # at a cost of a tiny, tiny fraction of the available RAM 00.32.35 # sideral: If you're just going to read the directory hierarchy, why even have it be LRU? 00.32.35 # off the top of my head i would expect to use at *least* twice as much ram to keep a full copy of the filesytem metadata blocks cached 00.32.49 # * pamaury thinks the DB code is crappy and stop the discussion here :) 00.32.53 # since subdirectories are bloated and you also need to cache the FAT 00.33.02 # otherwise you can't read any subdirectories that are longer than a cluster 00.33.06 # (well, parts of the FAT) 00.33.19 # * sideral goes on record saying the DB code is not crappy!!1!oneeleven! 00.34.04 # Torne: Don't forget that some of the HD targets where dircache is frequently in use can have 16 or even 8mb of RAM, in which case using twice as much RAM for the cache becomes more painful. 00.34.33 # Llorean: Well the amoutn of ram is not really the thing even 00.34.37 # Before kugel implemented dircache compaction, the dircache was quite hugr 00.34.40 # huge 00.34.40 # You don't know how much ram you *need* 00.34.48 # the DB code has been buggy for years because of this horrible mess of tricky details everywhere with a poor abstraction 00.34.49 # so any limit is too low, potentially 00.34.50 # and nobody objected :) 00.35.12 # sideral: We didn't like it, but it was necessary. now it's not necessary, but someone's proposing we do it anyway... 00.35.13 # sideral: it wasn't huge for me 00.35.15 # sideral: no, the compaction didn't change the dircache size one bit 00.35.17 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 00.35.17 # it was, like, 100kb 00.35.22 # still is afaik 00.35.29 # the dircache wasn't buggy before compaction ! 00.35.35 # * Llorean would love if dircache were 1/3 the size it is now. 00.35.44 # 100kb to guarantee i don't need to spin up when not buffering is very cheap :) 00.35.51 Quit ender` (Quit: We must respect the other fellow's religion, but only in the sense and to the extent that we respect his theory that his wife is beautiful and his children smart. -- H.L. Mencken) 00.36.03 Quit lebellium (Client Quit) 00.36.03 # Having a block cache which is multiple times larger is multiple times more expensive, and *still* may not succeed all the time 00.36.04 # the struct member removal reduced its size 00.36.13 # kugel: Ah, maybe I misunderstood the point of compaction then? 00.36.24 # it's wasn't *huge* 00.36.30 # Torne: I think mine is quite a bit bigger, but that is well worth it too to guarantee no spin up 00.36.35 # the reduction came from something unrelated to compaction 00.36.51 # OK, point taken 00.36.56 # sideral: I changed the layout, so that names are allocated from the end 00.37.39 # and since the the non-transparent build doesn't know the size in advance it needs to compact when it dies 00.37.43 # does 00.38.34 # pamaury: I don't think the DB is so bad, but I agree that it could use more abstraction 00.39.08 # but that's perhaps a different discussion. :) 00.39.49 Quit pamaury (Remote host closed the connection) 00.40.01 # The playlist code and the file-browser also have lots of #ifdef HAVE_DIRCACHE and would be simplified 00.40.30 # So why don't we decide what features of dircache can't be sacrificed? For example, I'd say a dircache replacement has failed if it needs to hit the disk during browsing, or during playlist generation. Ideally (but not necessarily) it wouldn't use more RAM (and too much more would definitely be a failure) 00.41.25 # bah, features ;) 00.42.08 # How fast is flash memory in comparison to hard drives? 00.43.11 # Llorean: In principle I agree with your list, but personally I wouldn't draw the line so rigidly 00.45.12 # What's the point of a dircache if it no longer does what dircache was put in explicitly to do? 00.45.51 # It seems like a regression to me if you're saying "it'll no longer reliably do either of the things it was put in to do, and we're also using more RAM, but hey, at least it makes the job for the programmers a bit easier" 00.46.04 Quit Strife89 (Quit: Vamoose.) 00.46.25 # Do you see any feature of the dircache as "essential"? 00.47.13 # As I said, I mostly agree with your list. I'd hate any change to slow down FS or DB browsing 00.47.20 # or playlist generation 00.47.33 # but I'd tolerate it as an exception 00.47.47 # I would if it were once a year 00.47.56 # But not if it were at all common 00.48.01 # because I value functionality, including robustness, higher than overall speed 00.48.15 # But that is removing functionality 00.48.38 # crashing more often also removes functionality 00.48.44 # sideral: Dircache was very, very stable for filetree users for quite a long time. 00.48.46 # kugelp: I replied to your comment. 00.48.53 # dircache has been hugely stable 00.48.55 # If someone's added things that make it crash now, isn't the solution "fix those things" rather htan "throw it out"? 00.49.00 # I haven't had a crash in years 00.49.22 # then you haven't updated recently :-) 00.49.35 # kugelp: Not in the last couple of weeks, no :) 00.49.49 # one thing I've persistently run into, and which kugel did not introduce, is that the dircache shuts down when WPS is the startup screen and another playlist is started 00.50.02 # this (until two weeks ago) made the DB crasg 00.50.05 # crash 00.50.36 # And now it's fixed. 00.50.43 # So it seems like it's a non-issue any more for this discussion. 00.50.49 # Llorean: But I'd rather not have to program around sudden service disruptions in the DB 00.51.23 # it's fixed only in that the DB doesn't crash any more 00.51.26 # sideral: And I'd rather not have to wait longer than I currently do for playlist generation. And there are thousands of users who have to deal with playlist generation, and a few dozen (at most) programmers who have to program around that. 00.51.32 # the dircache still shuts down in this case 00.51.56 # And it's 100% impossible to have dircache not shut down in that case? 00.52.36 # the lru thing won't work as well as dircache, very sure about that 00.52.44 # Llorean: It's not simple. If you have a good idea, chime in to FS#12216 :) 00.52.44 # http://www.rockbox.org/tracker/task/12216 3Dircache shuts down when closing a file that was opened prior to reloading the dircache (bugs, new) 00.53.02 # Even then, it's a single *predictable* use case where dircache will fail, rather than the dircache replacement randomly failing users at unknown times and unknown places. 00.53.49 # I do understand you concern, Llorean 00.54.36 Quit simabeis (Ping timeout: 240 seconds) 00.54.41 # I was just testing the waters with this discussion for how fault robust we'd like Rockbox to be, in relation to some of the features. 00.55.06 Quit nomada (Ping timeout: 240 seconds) 00.55.06 Quit knittl (Ping timeout: 240 seconds) 00.55.12 Join knittl [0] (~knittl@unaffiliated/knittl) 00.55.21 # And this discussion was of immense fun to me -- thanks to all involved! 00.55.28 Join simabeis [0] (~simabeis@lobmenschen.de) 00.55.46 Join nomada [0] (~nomada@irc.consciente.de) 00.55.49 Quit liar__ (Quit: hallowed are the ori!) 00.55.51 # if we wanted it to be really fault robust we wound't cache the disk at all :) 00.55.53 # because that's way simpler to implement reliably 00.55.53 # I'd define a 'fault' as any time something doesn't work the way a user expects it to. Dircache suddenly failing, either due to that bug, or because it's been replaced with a cache that no longer contains everything consistently, is a fault. 00.57.31 # yeah. I think it has to be weighted against each other, and I personally think that sometimes, less complexity is a goal in its own right because it implies fewer bugs 00.58.14 # By that standard we could remove any feature in the name of "less complexity" 00.58.20 # My first vote is the database. It's *always* been somewhat buggy. 00.59.01 # In case it's not clear, I'm not 100% serious there. The point is, though, that "less complexity at the cost of existing features" isn't an argument we should have. 00.59.04 # hehe. I wasn't proposing to remove any function -- but to relax one of the nonfunctional requirements :) 00.59.45 # A dircache which no longer guarantees no spin up is removing functions 01.00.02 # Would it be okay if the database occasionally "forgot" tags? Songs randomly not showing up in searches that had in the past, if it made the database code less complex? 01.00.24 # *The* function of the dircache was "file browsing no longer requires a disk spinup" 01.01.15 # You'd be changing it to "file browsing only occasionally requires a disk spinup" and depending on the cache size and circumstances, might make disk spinups *more* likely because if other files are cached, the disk is more likely to spin down during browsing before the next cache miss. 01.01.16 # this is getting into dangerous specification geek territory -- let's not go there :) 01.01.43 # sideral: So you're allowed to call part of the feature "not a requirement" but we're not allowed to contradict it? 01.01.51 # let's agree that not having disk spinups is a requirement 01.01.51 # Because that's "specification geek territory"? 01.02.01 # it *never* spinning up *is* a functional requirement 01.02.12 # Okay. No disk spinups during file browsing when the feature is turned on. 01.02.14 # "never" is something a user can trivially observe :) 01.03.05 # I'll rather pass than starting a discussion of functional vs nonfunctional requirement at this time of day -- so you win :) 01.03.28 # The point of a feature doesn't need discussion - it is the point 01.03.50 # Do we have any functional requirement written somewhere at all? 01.04.06 Quit GeekShadow (Ping timeout: 240 seconds) 01.04.31 # bertrik: there are tons of *unwritten* requirements all over Rockbox 01.04.53 # I don't think anyone cares to write any of them down :) 01.05.57 Join GeekShadow [0] (~antoine@242.160.21.93.rev.sfr.net) 01.14.35 Quit MethoS- (Remote host closed the connection) 01.15.49 Quit HaimN (Ping timeout: 250 seconds) 01.32.30 Quit drezon (Ping timeout: 260 seconds) 01.38.11 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 01.41.08 # AlexP: On rereading the chat log, I noticed I'd missed your proposal to remove DB RAM caching along with the dircache. Hey, that may be totally worth it with a block cache! :) 01.42.05 Quit germanmushroom (Ping timeout: 240 seconds) 01.44.23 # sideral: Do you have a hard disk based target? 01.46.26 Join sam_t [0] (~Sam@c-71-239-15-70.hsd1.in.comcast.net) 01.46.47 # has anyone seen floatsaka 01.48.33 # Llorean: No, I have not. Has it been that obvious? ;) 01.49.50 # Well, except for the simulators, that is. I noticed how long startup takes with them with a comparable file set due to the dircache initialization 01.53.43 # Llorean, do you remember a dude named floatsaka? 01.56.10 *** Saving seen data "./dancer.seen" 02.15.26 # sideral: It is pretty obvious, yes :) I'd strongly recommend trying one with and without dircache then see if you want to remove it :) 02.21.00 Nick AlexP_ is now known as AlexP (~alex@rockbox/staff/AlexP) 02.27.37 Join robin0800 [0] (~robin0800@149.254.217.248) 02.42.32 # sideral: AlexP suggested what I was going to. See if you can borrow or get access to one, and use it without dircache and database for a few days. It's remarkably different, and having dircache only *sometimes* improve the situation, rather than constantly, would feel like a significant downgrade 02.43.09 # A 3-4 second delay every time you enter a folder if you spend too long looking at the current folder's contents is somewhat painful. 02.44.02 Quit Keripo (Read error: Connection reset by peer) 02.46.49 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 02.53.18 Quit Xerion (*.net *.split) 02.53.18 Quit ruskie (*.net *.split) 02.53.21 Quit [fred] (*.net *.split) 02.53.22 Quit alexbobp (*.net *.split) 02.53.23 Quit iq_ (*.net *.split) 02.53.23 Quit balintx (*.net *.split) 02.53.24 Quit bertrik (Quit: :tiuQ) 02.53.27 Join alexbobp [0] (~alex@108.60.198.57) 02.53.44 Join iq_ [0] (~iq@ip24-252-19-172.om.om.cox.net) 02.53.50 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 02.54.34 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 02.57.59 Nick tmzt_ is now known as tmzt (~tmzt@adsl-99-164-121-105.dsl.akrnoh.sbcglobal.net) 02.58.04 Quit robin0800 (Ping timeout: 260 seconds) 03.22.59 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 03.23.14 Quit mgue (Read error: Operation timed out) 03.25.30 Join mgue [0] (~mgue@p5DDA0E72.dip.t-dialin.net) 03.36.48 # any forum admins? seniyajw wants to be banned 03.56.14 *** Saving seen data "./dancer.seen" 03.59.28 Quit Keripo (Read error: Connection reset by peer) 04.00.36 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 04.00.45 Quit ReimuHakurei_ (Read error: Connection reset by peer) 04.01.15 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 04.11.53 Quit FOAD (Read error: Operation timed out) 04.19.27 Join FOAD [0] (~foad@83.161.135.61) 04.19.27 Quit FOAD (Changing host) 04.19.27 Join FOAD [0] (~foad@unaffiliated/foad) 04.30.02 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 04.52.54 # AlexP: sorry for disapeareing last night. %Vg() can be on the same line as %V() but doesnt have to. the 'text' param is the colour to use for the text. it is optional and IIRC it uses the foreground colour if it isnt specified 04.59.00 Quit amiconn (Disconnected by services) 04.59.00 Quit pixelma (Disconnected by services) 04.59.01 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.59.02 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.59.05 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.59.21 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.32.34 Join Rob2223 [0] (~Miranda@p4FFF16A5.dip.t-dialin.net) 05.35.08 Quit ReimuHakurei (Read error: Connection reset by peer) 05.35.18 Join ReimuHakurei [0] (~kudo@wireless.sit-co.net) 05.36.34 Quit Rob2222 (Ping timeout: 250 seconds) 05.42.43 Join Scr0mple [0] (~Simon@115-64-195-104.static.tpgi.com.au) 05.43.26 Quit nomada (Ping timeout: 276 seconds) 05.44.32 Quit Keripo (Read error: Connection reset by peer) 05.44.41 Quit Horscht (Quit: Verlassend) 05.45.14 Quit Scromple (Ping timeout: 250 seconds) 05.46.20 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 05.49.21 Join nomada [0] (~nomada@irc.consciente.de) 05.56.17 *** Saving seen data "./dancer.seen" 05.59.17 Quit sam_t (Quit: Leaving) 06.29.28 Quit Keripo (Read error: Connection reset by peer) 06.30.40 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 07.06.33 Join advcomp2019_ [0] (~advcomp20@97-114-233-50.sxcy.qwest.net) 07.06.33 Quit advcomp2019_ (Changing host) 07.06.33 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 07.09.40 Quit advcomp2019 (Ping timeout: 252 seconds) 07.43.24 Quit froggyman (Ping timeout: 260 seconds) 07.44.33 Quit Keripo (Read error: Connection reset by peer) 07.48.31 Join froggyman [0] (~seth@50.105.151.180) 07.48.31 Quit froggyman (Changing host) 07.48.31 Join froggyman [0] (~seth@unaffiliated/froggyman) 07.54.31 Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) 07.54.31 Quit pamaury (Changing host) 07.54.31 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 07.55.48 Join Xerion_ [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 07.56.21 *** Saving seen data "./dancer.seen" 07.56.42 Quit Xerion (Read error: Connection reset by peer) 07.56.42 Nick Xerion_ is now known as Xerion (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 07.57.55 Join HaimN [0] (~quassel@31.44.142.168) 08.00.42 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 08.00.42 Quit Zagor (Changing host) 08.00.42 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.09.59 Quit powell14ski (Quit: powell14ski) 08.13.23 Join Bagder [0] (~daniel@www.haxx.se) 08.13.23 Quit Bagder (Changing host) 08.13.23 Join Bagder [241] (~daniel@rockbox/developer/bagder) 08.18.36 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 08.21.26 Join mystica555 [0] (~mike@c-71-205-210-44.hsd1.mi.comcast.net) 08.25.19 # Torne: (re last night's discussion) Not having to hit the disk when browsing with dircache enabled is not completely true. It is only true if you're not using .talk clips 08.26.16 # This can be quite irritating if you can't (shouldn't) look at the display, e.g. while driving 08.27.20 Quit user890104 (Read error: Connection reset by peer) 08.29.33 Join user890104 [0] (~Venci@6bez10.info) 08.31.20 Quit user890104 (Read error: Connection reset by peer) 08.33.21 Join user890104 [0] (~Venci@6bez10.info) 08.45.29 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.47.19 Quit HaimN (Ping timeout: 240 seconds) 08.55.05 Join ender` [0] (~ender@foo.eternallybored.org) 09.06.09 Quit Scr0mple (Quit: Leaving) 09.10.05 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 09.13.26 Quit wtachi (Quit: &) 09.21.07 Join God_Eater [0] (93722cd0@rockbox/staff/GodEater) 09.37.57 Quit otih (Remote host closed the connection) 09.38.32 Quit froggyman (Ping timeout: 264 seconds) 09.40.33 Join n1s [0] (~quassel@rockbox/developer/n1s) 09.41.16 Join otih [0] (~otih@2a01:4f8:100:9ff6:1::2) 09.41.16 Quit otih (Changing host) 09.41.16 Join otih [0] (~otih@CAcert/Assurer/otih) 09.41.28 Join HaimN [0] (~quassel@31.44.142.168) 09.56.23 *** Saving seen data "./dancer.seen" 10.01.49 Quit n1s (Remote host closed the connection) 10.13.49 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 10.20.44 Join lorenzo92 [0] (~chatzilla@host105-111-dynamic.20-79-r.retail.telecomitalia.it) 10.45.07 # amiconn: I noticed that behavior in the code. and I don't understand it 10.46.01 # wait, you probably meant something else 10.52.27 Quit HaimN (Ping timeout: 240 seconds) 10.52.53 Join HaimN [0] (~quassel@31.44.142.168) 10.57.24 # can any of the lang or AE vs BE guys look at fs#12232? 10.57.25 # http://www.rockbox.org/tracker/task/12232 3American English translation update (patches, unconfirmed) 11.02.30 # kugelp: I've never seen catalogue used as an American English spelling, and the current AE dictionary my spellchecker's using gives it a red underline. 11.02.38 # It may be acceptable, but I'd go with it being the less common. 11.03.07 # that was my guess too 11.03.09 # There's not much point in having an AE lang if we're going to put in BE spellings where someone 'prefers' it. 11.03.10 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.03.26 # I agree 11.03.58 # If you prefer BE - don't use AE.lang ;) 11.05.48 # Exactly 11.08.16 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 11.42.08 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440]) 11.46.59 Join stoffel [0] (~quassel@p57B4C5A4.dip.t-dialin.net) 11.56.24 *** Saving seen data "./dancer.seen" 11.58.18 Quit stoffel (Ping timeout: 260 seconds) 11.59.57 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 12.04.39 Join drezon [0] (~drezon@2a01:238:4200:7e03:f2de:f1ff:fe4f:3584) 12.12.57 Join lorenzo92 [0] (~chatzilla@host105-111-dynamic.20-79-r.retail.telecomitalia.it) 12.14.02 Quit antil33t () 12.24.49 Quit HaimN (Ping timeout: 258 seconds) 12.25.15 Join HaimN [0] (~quassel@31.44.142.168) 12.25.58 Quit kadoban (Ping timeout: 258 seconds) 12.26.28 Quit lorenzo92 (Remote host closed the connection) 12.30.32 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 6.0/20110811165603]) 12.35.12 Quit dfkt (Read error: Connection reset by peer) 12.35.12 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 12.38.59 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 12.41.22 Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) 12.59.27 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 13.14.08 Quit HaimN (Remote host closed the connection) 13.14.13 Join HaimN [0] (~quassel@31.44.142.168) 13.25.45 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 13.52.45 Join dunkaist [0] (~dunkaist@82.209.203.239) 13.55.15 Join HaimN_ [0] (~quassel@31.44.142.168) 13.55.32 Quit HaimN (Ping timeout: 252 seconds) 13.56.26 *** Saving seen data "./dancer.seen" 14.15.38 Quit dunkaist (Quit: leaving) 14.17.20 # New commit by 03mc2739 (r30320): Update American English language 14.19.58 # r30320 build result: All green 14.24.22 Quit niekie (Quit: No Ping reply in 180 seconds.) 14.25.01 Join niekie [0] (~niek@CAcert/Assurer/niekie) 14.36.50 # btw. isn't the new english-us.lang a good opportunity to discuss the title case vs sentence case topic again? :) 14.44.02 Join MethoS- [0] (~clemens@134.102.106.250) 14.58.08 Quit Bagder (Quit: Konversation terminated!) 15.01.11 # New commit by 03kugel (r30321): Dircache: Fix memory leak (and recently panic). ... 15.03.49 # r30321 build result: All green 15.06.31 Join dunkaist [0] (~dunkaist@82.209.203.41) 15.12.11 Quit bluefoxx (Ping timeout: 246 seconds) 15.21.00 Quit dunkaist (Quit: leaving) 15.22.18 # Ugh, why must my translation be mutilated? 15.24.38 # Espreon: http://www.rockbox.org/irc/log-20110816#10:57:24 15.25.05 # we don't agree that BE is suitable for english-us.lang 15.25.12 # whether or not it's acceptable 15.27.18 Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com) 15.27.29 # It's not BE. 15.27.37 # It's merely the formal spelling. 15.28.51 # common usage is overwhelmingly catalog 15.29.07 # And? 15.29.09 # 14:36 < kugel> btw. isn't the new english-us.lang a good opportunity to discuss the title case vs sentence case topic again? :) 15.29.13 # What is that supposed to mean?> 15.29.35 # and we expect that our translated strings reflect common usage in the language in question? 15.29.58 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 15.30.30 Quit Poodlemastah (Ping timeout: 252 seconds) 15.30.45 # the whole point of english-us.lang is that english.lang includes lots of uncommon (or even wrong) translations for US people 15.31.04 # there seems little point if you aren't going to make the most effort to use what's common in the US 15.31.33 # the point of a translation is not to appease the translator's aesthetic sensibilities, it's to serve people who use that language 15.31.38 Join Poodlemastah [0] (~chatzilla@h-241-205.a218.priv.bahnhof.se) 15.35.38 # And who are you to make these decisions? Well, since you wish to do such things, please do research on every other language you have translations for and enforce your beliefs on everyone else. "catalogue" is perfectly acceptable and no one from here would question it. 15.36.03 # The use of "favour" and "realise", however, would be questioned. 15.36.22 # And they're unacceptable. 15.37.29 # it's not only about what's acceptable, but about what's common 15.38.01 # wikipedia's manual of style says "catalog is the preferred spelling in American English." 15.38.19 # not that it's our reference, just a data point 15.38.28 # http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(spelling) 15.38.58 # kugel: Just because something's commonly done doesn't mean it should be done. 15.39.10 # Seriously, do any of you even use english-us.lang? 15.39.34 # yes 15.40.21 # http://en.wiktionary.org/wiki/catalog 15.41.03 # http://wiki.answers.com/Q/What_is_the_difference_between_'catalog'_and_'catalogue' same thing 15.42.26 # http://eprints.rclis.org/bitstream/10760/6859/1/Beall_Catalog.pdf 15.43.23 Quit simonlnu (Ping timeout: 258 seconds) 15.44.01 # I guess that I don't control my own translation. Is this correct? 15.44.47 # Espreon: it's not your translation. It's the rockbox US English translation to which you are a (possibly major) contributor 15.45.31 # If you want your own translation which you control 100%, we won't stop you, but that won't be the translation in svn 15.45.37 Join simonlnu [0] (cFsIj0qI52@unaffiliated/simonrvn) 15.45.44 # fwiw, I think you questioning the change is fine. but you need to be prepared to back up your opinion with more than "it's my translation" 15.47.35 # all the data points I can find concur with the opinon that 'catalog' is the predominant US spelling, especially outside formal or government text 15.48.07 Quit HaimN_ (Ping timeout: 264 seconds) 15.48.31 # Well, I just think it's silly that everything's inconsistent. "dialogue" in common use; "catalog" in common use, and so forth. There that's my opinion. I probably won't get anywhere with it, but whatever. 15.48.34 Join HaimN [0] (~quassel@31.44.142.168) 15.49.00 # At this point, I really wish to not be affiliated with that translation, but IDK. 15.49.45 # Surely catalogue is far too frenchified for you? 15.51.27 # Espreon: well has there been any discussion about dialogue, or has simply nobody considered it? 15.52.20 # When I changed the spelling to catalogue in the BE translation, there was a bug report from someone who (in error) thought I'd changed the AE to catalogue too 15.52.44 # AlexP: There's a difference between Frenchification and mutilation. I simply see the remaining "-ue"s as representations of "-os". 15.53.15 Join froggyman [0] (~seth@unaffiliated/froggyman) 15.54.46 # oh, there is no "dialogue" in the lang files :-) 15.54.52 Quit bluefoxx (Ping timeout: 258 seconds) 15.55.08 # how about "queue" ;-) 15.55.51 # That may be, but what if we had another common "-gue" spelling coexisting with a common "-g" spelling? Oh noez. I think it should just be kept "-gue". 15.55.55 # That's different. 15.56.07 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 15.56.29 *** Saving seen data "./dancer.seen" 15.56.35 # Arguing that the translation is inconsistent is missing the point somewhat :) 15.56.39 # The *language* is inconsistent 15.56.43 # * gevaerts proposes to drop *all* English text from rockbox 15.56.44 # that's just how it works :) 15.57.03 # if you want consistency, learn lojban ;) 15.57.07 # gevaerts: why stop there? 15.57.30 # JdGordon: I think numeric IDs for strings are all we need 15.57.38 # Espreon: I think the lang files should reflect the language commonly used (and thus, expected) 15.57.50 # you prude! 15.58.22 Quit bluefoxx (Client Quit) 15.59.17 # Torne: That may be, but that's no reason to continue the madness. 15.59.34 # yes there is! 15.59.39 # Language is what people use. 15.59.40 # what madness? 15.59.44 # Any other approach is mad 16.00.00 # spelling words as most people expect them is madness? 16.01.04 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 16.01.25 # God_Eater: ... No. Just... no. 16.01.51 # I have a list of things I'd rather do before doing that. 16.02.24 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 16.02.37 # As for this, it's not going to do anything or get anyone anywhere. Fine. Do what you wish. I disown that... thing. 16.03.55 # you already don't own it, so that's a no-op 16.04.08 # Whatever. Remove the line in the file affiliating me with it. 16.05.21 # You are right... it is indeed not mine. 16.07.40 Join webguest371 [0] (~c1befd92@giant.haxx.se) 16.07.49 Quit webguest371 (Client Quit) 16.07.57 Join CoLdAsSauLt [0] (~c1befd92@giant.haxx.se) 16.08.26 # Hi 16.08.52 # I was looking for some help 16.09.09 # I would like to install a patch, i.e. the Meier crossfeed emulation 16.09.21 # but I'm not sure how and where to start with the patching thing... 16.09.33 # any clues or help would be greatly appreciated :) 16.10.17 # CoLdAsSauLt: http://www.rockbox.org/wiki/WorkingWithPatches 16.12.33 # http://gnuwin32.sourceforge.net/packages/patch.htm 16.12.43 # Would somone just please unaffiliate me from that translation? That is all I shall ever ask of you. 16.12.47 # 2007... is this the latest version? 16.12.56 # or doesn't that matter? 16.13.30 # CoLdAsSauLt: doesn't matter 16.13.37 # k thx 16.14.13 # Espreon: sure 16.14.31 # Thank you. 16.17.52 Quit simonlnu (Ping timeout: 258 seconds) 16.20.03 Join simonlnu [0] (uc14uIPduy@unaffiliated/simonrvn) 16.20.32 Quit niekie (Quit: No Ping reply in 180 seconds.) 16.21.18 Join niekie [0] (~niek@CAcert/Assurer/niekie) 16.22.37 Join n1s [0] (~quassel@rockbox/developer/n1s) 16.23.00 # New commit by 03zagor (r30322): Removed attribution, at author's request. 16.25.27 # r30322 build result: All green 16.25.55 # Thanks again; farewell. 16.26.02 Part Espreon 16.29.36 Quit robin0800 (Quit: Leaving) 16.30.37 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 16.47.51 # Zagor: any comments on fs#12231 16.47.51 # http://www.rockbox.org/tracker/task/12231 3Centralize codec compilation flag setting (patches, new) 16.49.15 # it looks terrific 16.50.05 # great 16.50.18 # Zagor: I noticed the zip dependency doesn't quite work 16.50.56 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 16.51.32 # $ LANG=C make zip 16.51.32 # make: Nothing to be done for `zip'. 16.51.42 # that's buggered 16.51.48 # hmm 16.57.02 Quit HaimN (Quit: No Ping reply in 180 seconds.) 16.57.04 # I'll have to look at that later 16.57.39 Join HaimN [0] (~quassel@31.44.142.168) 17.08.39 Part Zagor 17.19.51 Join dunkaist [0] (~dunkaist@bp-203-135.dialup.vitebsk.by) 17.20.07 Quit n1s (Remote host closed the connection) 17.34.38 Quit ThomasAH (Quit: leaving) 17.39.57 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.44.28 Join stoffel [0] (~quassel@p57B4C5A4.dip.t-dialin.net) 17.45.00 Join powell14ski [0] (~powell14s@c-174-51-194-6.hsd1.co.comcast.net) 17.56.33 *** Saving seen data "./dancer.seen" 18.00.25 Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) 18.05.21 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.06.47 Quit HaimN (Ping timeout: 240 seconds) 18.06.52 Join HaimN [0] (~quassel@31.44.142.168) 18.17.21 Quit niekie (Quit: No Ping reply in 180 seconds.) 18.17.32 Join niekie [0] (~niek@CAcert/Assurer/niekie) 18.21.50 Quit dunkaist (Quit: leaving) 18.22.31 Quit HaimN (Remote host closed the connection) 18.22.56 Join HaimN [0] (~quassel@31.44.142.168) 18.23.27 Quit niekie (Ping timeout: 260 seconds) 18.23.41 Join niekie [0] (quasselcor@CAcert/Assurer/niekie) 18.28.01 Join Keripo [0] (~Keripo@CPE0022b0d4bdb7-CM001a6680d4fe.cpe.net.cable.rogers.com) 18.32.41 Join Topy [0] (~Topy44@g228199140.adsl.alicedsl.de) 18.36.03 Quit Stummi (Quit: Leaving...) 18.36.30 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.36.31 Quit T44 (Ping timeout: 250 seconds) 18.39.09 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.41.57 Join Graham [0] (~47b69583@giant.haxx.se) 18.42.24 Nick Graham is now known as Guest21717 (~47b69583@giant.haxx.se) 18.44.44 # Hey there guys I have a quick question: When I add a folder of music, it shows up in my files, but not in my database. Shouldn't it automatically show up after rebooting? 18.46.43 # Guest21717: only if you set the database to auto update 18.47.00 # * bluebroth3r wonders when we started to not attribute contributions on request 18.48.44 # Haha, it is, which is the thing. 18.49.55 # I almost never use the database so not much experience on my side. 18.50.00 # the size of the folder[s] shouldn't matter right? 18.50.24 # no 18.51.49 # Well, I've rechecked the files, and the folders come up empty... 18.52.10 # But that's normal, right? 18.54.11 # bluebroth3r, if you don't use the database, what do you use? 18.55.23 # the file browser. It's much nicer if you have the appropriate folder structure ;-) 18.55.46 # Ah there we go, I've got it fixed. I guess it just took a while for it to read. 18.55.57 # Thanks for the help! 18.55.59 Quit Guest21717 (Quit: CGI:IRC) 18.56.04 # check the "show files" setting. If it's set to "Playlists" it's normal the folders are empty. If not I guess the folders are actually empty :) 18.56.17 # wow. Kinda impatient :/ 18.57.12 Quit froggyman (Quit: Ex-Chat) 18.59.00 Join froggyman [0] (~seth@unaffiliated/froggyman) 19.01.35 Quit stoffel (Ping timeout: 276 seconds) 19.23.56 Join pacovila [0] (~pacovila@84.79.151.4) 19.25.10 Part pacovila 19.27.06 Join stoffel [0] (~quassel@p57B4C5A4.dip.t-dialin.net) 19.30.00 Quit HaimN (Ping timeout: 258 seconds) 19.30.26 Join HaimN [0] (~quassel@31.44.142.168) 19.30.43 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.33.08 Join lorenzo92 [0] (~chatzilla@host4-251-dynamic.50-79-r.retail.telecomitalia.it) 19.38.54 Quit fs-bluebot (Ping timeout: 250 seconds) 19.40.04 Join fs-bluebot [0] (~fs-bluebo@g225252076.adsl.alicedsl.de) 19.40.16 Quit bluebroth3r (Ping timeout: 260 seconds) 19.41.32 Join bluebrother [0] (~dom@g225252076.adsl.alicedsl.de) 19.41.32 Quit bluebrother (Changing host) 19.41.32 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.44.29 Quit mudd1 (Ping timeout: 276 seconds) 19.48.45 Quit Poodlemastah (Remote host closed the connection) 19.53.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.56.18 Quit Rob2223 (Quit: Rob2223) 19.56.34 *** Saving seen data "./dancer.seen" 19.56.43 Join Rob2222 [0] (~Miranda@p4FFF16A5.dip.t-dialin.net) 20.02.38 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 20.05.36 Quit stripwax (Quit: http://miranda-im.org) 20.08.05 Quit drezon (Ping timeout: 255 seconds) 20.19.16 Quit user890104 (Read error: Connection reset by peer) 20.27.44 Join user890104 [0] (~Venci@6bez10.info) 20.35.19 Quit HaimN (Remote host closed the connection) 20.35.44 Join HaimN [0] (~quassel@31.44.142.168) 20.39.21 Quit stoffel (Remote host closed the connection) 20.50.52 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 20.54.41 Quit HaimN (Quit: No Ping reply in 180 seconds.) 20.55.22 Join HaimN [0] (~quassel@31.44.142.168) 20.55.41 Join dunkaist [0] (~dunkaist@86.57.183.168) 21.01.34 Quit user890104 (Ping timeout: 252 seconds) 21.01.42 Join user890104 [0] (~Venci@6bez10.info) 21.03.01 Quit dunkaist (Quit: leaving) 21.09.11 Quit pixelma (Disconnected by services) 21.09.13 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.09.15 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.09.20 Quit factor (Read error: Connection reset by peer) 21.09.36 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.09.43 Quit amiconn (Disconnected by services) 21.09.56 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.10.14 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 21.12.50 Part mystica555 ("Leaving") 21.14.22 Quit pixelma (Disconnected by services) 21.14.24 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.14.26 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.14.56 Quit amiconn (Ping timeout: 258 seconds) 21.14.58 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.15.18 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.26.11 Join factor [0] (~factor@74.197.205.204) 21.26.26 # New commit by 03thomasjfox (r30323): perl magic: Use if/elsif/else instead of given/when (FS #12188) ... 21.29.01 # r30323 build result: All green 21.29.30 Join TheLemonMan [0] (~lem0n@ppp-66-44.26-151.libero.it) 21.30.25 # New commit by 03thomasjfox (r30324): Add Nick Peskett to CREDITS 21.31.22 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.32.44 # r30324 build result: All green 21.36.05 Quit amiconn (Disconnected by services) 21.36.06 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.36.26 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.36.27 Quit pixelma (Disconnected by services) 21.36.29 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 21.36.31 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 21.38.36 # * thomasjfox hopes kugel's latest fixes unbreak the database feature. It did my last build around two or three days ago 21.39.33 Quit Stummi (Quit: Bye!) 21.43.09 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 5.0/20110622232440]) 21.51.36 # kugel: Dunno if it's related to the latest buffering changes: Going to "Database -> History... -> Most played" gives me a "Dir Buffer is Full!". This is with r30324 21.56.12 Quit simonlnu (Ping timeout: 252 seconds) 21.56.38 *** Saving seen data "./dancer.seen" 21.57.11 Quit stripwax (Quit: http://miranda-im.org) 21.58.24 Join stephen__ [0] (~stephen@86.41.2.34) 22.00.52 Join simonlnu [0] (c6uuRozapo@unaffiliated/simonrvn) 22.07.28 Quit HaimN (Ping timeout: 276 seconds) 22.07.31 Part Zagor 22.07.41 Join HaimN [0] (~quassel@31.44.142.168) 22.08.18 Quit thomasjfox (Remote host closed the connection) 22.18.43 Join drezon [0] (~drezon@2001:6f8:1029:2:1a3d:a2ff:fe60:4ae0) 22.20.45 # * AlexP assumes there are no 3.9.1 objections? 22.21.41 Quit HaimN (Quit: No Ping reply in 180 seconds.) 22.21.57 # * gevaerts has none 22.22.17 Join HaimN [0] (~quassel@31.44.142.168) 22.23.03 # * user890104 has a patch that would be a good idea to be included, even if the target's status is still unusable 22.23.44 # 3.9.1 won't be built for that target if it's not stable. 22.24.11 Quit factor (Read error: Connection reset by peer) 22.24.34 # oh yeah, right 22.24.48 Quit HaimN (Remote host closed the connection) 22.25.10 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.33.48 Join lorenzo92 [0] (~chatzilla@host4-251-dynamic.50-79-r.retail.telecomitalia.it) 22.34.08 Quit lorenzo92 (Client Quit) 22.39.38 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 22.41.36 Join factor [0] (~factor@74.197.205.204) 22.42.10 Quit stephen__ (Quit: Leaving) 22.42.38 Quit shai (Ping timeout: 250 seconds) 22.57.46 Join dunkaist [0] (~dunkaist@bp-203-108.dialup.vitebsk.by) 23.10.26 Quit dunkaist (Quit: leaving) 23.12.09 Quit CoLdAsSauLt (Quit: CGI:IRC (Ping timeout)) 23.14.03 Join FoH_Phobos [0] (~foh@adsl-98-83-162-86.bhm.bellsouth.net) 23.22.44 Join glued [0] (~536386b3@giant.haxx.se) 23.30.08 Join funman [0] (~fun@rockbox/developer/funman) 23.30.08 Quit glued (Quit: CGI:IRC (EOF)) 23.30.16 Join glued [0] (~536386b3@giant.haxx.se) 23.30.40 # Hi, there's a small bug, probably introduced by r30302 (JdGordon). The %a{l,c,r}format tags seem to add a space at the end. 23.30.49 # It's not very noticable with small font, but is very apparent with bigger ones. Test %ac 35-Nimbus.fnt — the text is not centered at all. 23.32.59 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 23.33.07 # glued: You can try to catch him here, but if not you should probably file a bug report 23.41.13 # Maybe if someone else could confirm it, I don't trust myself at nights. 23.44.19 # That sounds worrying :) 23.54.15 # No svn access atm, but I checked my old r30245 bins, text is centered ok. And JdGordon's r30302 is the only related change. 23.55.05 Quit GigaBrick (Ping timeout: 240 seconds) 23.55.13 # Just can't see what's wrong there... 23.55.52 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 23.56.40 *** Saving seen data "./dancer.seen"