00:00:21 | kugelp | I'm just not at the laptop but chatting from ny phone |
00:01:31 | sideral | ah OK. so are you ready for my mind-boggling idea? |
00:05:17 | kugelp | yes :-) |
00:06:08 | sideral | so here it comes: Let's reduce the complexity of the dircache by... |
00:06:13 | sideral | ...abolishing it! |
00:06:30 | sideral | Let's use the plenty of space we get for an LRU block cache |
00:06:59 | Llorean | With dircache off, playlist generation can take orders of magnitude more time on some disk targets. |
00:07:19 | sideral | Lots of dircache-related code will just vanish in exchange for some small hashing complexity in the block cache |
00:08:02 | sideral | The bet is that going through the filesystem into the block cache wouldn't be much slower |
00:08:20 | AlexP_ | 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 | sideral | Well no, the idea is to have the relevant data cached in the block cache |
00:08:55 | AlexP_ | OK |
00:09:03 | Llorean | 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 | AlexP_ | I don't care how you do it as long as the effect is the same :) |
00:09:10 | kugelp | sideral: not sure |
00:09:11 | Torne | presumably you wouldn't read data blocks into the cache? |
00:09:23 | Llorean | AlexP_: But waiting 10s or 100s of seconds for a large playlist to populate sucked. |
00:09:24 | sideral | Torne: definitely not the audio data. |
00:09:36 | AlexP_ | Llorean: It makes a pause of 3 or 4 seconds on some targets. Every time you start browsing |
00:09:41 | sideral | The filesystem would have to hint the caching scheme to the block layer |
00:09:46 | Torne | sideral: well, very little gets read repeatedly except via buffering |
00:09:55 | Llorean | AlexP_: Yeah, I remember. :) But 3 or 4 seconds isn't that long unless you stop and start browsing very frequently. |
00:10:02 | sideral | it would be LRU for directory entries / FAT, and don't care for most of everything else |
00:10:07 | AlexP_ | I tend to |
00:10:09 | Llorean | Or if your spindown time is too low for your habits. |
00:10:20 | AlexP_ | And 3 - 4 seconds was a huge time then |
00:10:20 | kugelp | the dircache works well for our not-general purpose file systems no? |
00:10:38 | Torne | sideral: i can't help but think this will use more ram for less benefit |
00:10:44 | Llorean | 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 | Torne | wel, or the same amount of ram for less benefit. |
00:11:04 | AlexP_ | 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 | kugelp | and maintaining the lru is probably more complete than the dircache |
00:11:17 | sideral | That's something that needs to be substantiated for sure |
00:11:27 | Torne | the dircache is more dense than a block cache of the directory data ont he disk |
00:11:30 | Torne | let alone the FAT |
00:11:31 | AlexP_ | Llorean: Having to wait a few seconds even every half an hour or so is very annoying |
00:11:39 | sideral | kugel: No, maintaining LRU is easy and fast, as is hashing |
00:11:52 | Llorean | 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 | AlexP_ | I do |
00:12:06 | AlexP_ | Well, depends on the improvements |
00:12:20 | Llorean | Yes, it depends on the improvements. |
00:12:21 | AlexP_ | But they'd have to be enormous |
00:12:28 | Llorean | I don't think they'd have to be enormouse. |
00:12:32 | AlexP_ | I do :) |
00:12:38 | Llorean | They'd just have to be one less annoyance ever 30 minutes |
00:12:47 | AlexP_ | Especially as we have dircache now |
00:12:49 | Llorean | Or, less bugs due to dircache complexity. |
00:13:03 | kugelp | sideral: not if I look at our font code :-) |
00:13:14 | AlexP_ | It'd be a major step back |
00:13:16 | Llorean | But it'd be unacceptable to go back to the time of counting dynamic playlist generation time in minutes. |
00:13:28 | AlexP_ | 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 | sideral | 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 | AlexP_ | See, it all depends what matters to you |
00:13:59 | AlexP_ | I just don't want to have to go back to waiting for spin up on browsing |
00:14:00 | Llorean | In an objective sense, waiting 3 seconds for an operation vs waiting 3 minutes is pretty significantly differenct. |
00:14:06 | kugelp | the "dircache clients"? |
00:14:06 | sideral | and we'd have fewer bugs for sure :) |
00:14:13 | AlexP_ | In fact, that would just lead me to not updating Rockbox anymore |
00:14:17 | Torne | the dircache guarantees that browsing doesn't need to touch the disk (under normal circumstances) |
00:14:28 | sideral | kugel: everything that does special stuff with the dircache, especially the database |
00:14:36 | pamaury | 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 | Torne | a block cache would not, even if it did improve other things somewhat |
00:14:40 | kugelp | 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 | Llorean | 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 | sideral | Llorean: sure. This is only a thought experiment so far :) |
00:15:20 | sideral | There's one major problem with my idea that I see: |
00:15:23 | Llorean | 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 | Llorean | That doesn't seem a win. |
00:15:30 | AlexP_ | exactly |
00:15:45 | kugelp | the block cache is what Linux does isn't it? |
00:15:50 | sideral | well, bugs and crashes are user visible :) |
00:15:55 | Llorean | sideral: But fixable. |
00:16:05 | Torne | currently virtually all of our disk accesses come down to two categories: directory accesses and buffering |
00:16:13 | Torne | the former is more efficiently served by the dircache |
00:16:14 | Llorean | 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 | Torne | the latter is not really served by caching at all |
00:16:37 | pamaury | dircache works rather well; it's a bit unstable recently due to kugel fiddling with it but appart from that... :) |
00:16:41 | kugelp | I agree with Torne |
00:16:53 | sideral | 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 | Torne | arguments about complexity/etc seem uninteresting |
00:17:12 | Torne | I don't think we should implement something worse because we think we can implement it more reliably |
00:17:19 | Torne | we should just try harder to implement the best thing *right* :) |
00:17:26 | * | Llorean agrees with Torne |
00:17:29 | AlexP_ | me too |
00:17:50 | Torne | our storage usage is very unlike a normal OS :) |
00:18:00 | sideral | No disagreement there :) |
00:18:13 | AlexP_ | and not forget HD and non-db users :) |
00:18:21 | AlexP_ | Or, at the same time remove db load to RAM :) |
00:18:25 | Torne | 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 | pamaury | 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 | Llorean | 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 | sideral | pamaury: The dircache itself isn't, but the dircache clients suffer enormous complexity |
00:19:24 | pamaury | which "enormous complexity" ? |
00:19:58 | sideral | pamaury: For example, the DB has a combination of #ifdef hell and if-the-else disease because of the dircache |
00:20:11 | sideral | and I've found a few bugs in there recently |
00:20:17 | sideral | I'm sure there are more lurking :) |
00:20:31 | Torne | right, but the database is 1) complicated anyway and 2) not used by as many people :) |
00:20:44 | pamaury | the database is one of the worst pieces of code |
00:20:45 | Torne | 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 | sideral | I thought it would be cool if that could be hidden below the POSIX layer :) |
00:21:06 | Torne | Right, but it can't be, without costing more ram |
00:21:12 | sideral | I wouldn't want anyone to take a hit Torne :) |
00:21:29 | AlexP_ | Then don't make me suffer spin up times etc. :) |
00:21:32 | Llorean | And RAM is most important on targets where Dircache is most beneficial. |
00:21:33 | Torne | 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 | pamaury | 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 | sideral | 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 | pamaury | *can't |
00:22:20 | sideral | (or maybe in the FS layer rather than in the block cache) |
00:22:33 | Torne | The directory blocks will *always* use more space, though |
00:22:34 | pamaury | but memory blocks use a horribly complicated structure due to FAT |
00:22:48 | Torne | as pamaury says |
00:22:49 | Torne | also fragmentation |
00:23:51 | pamaury | 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 | sideral | re the DB using dircache IDs as filename references: This service could be offered by the FAT FS as well |
00:24:17 | Torne | sideral: How? |
00:24:25 | Torne | How do you have stable identifiers for things in a LRU cache? |
00:24:28 | pamaury | you would end up with dircache ! |
00:24:41 | Torne | You can't evict things and still know what those identifiers mean |
00:24:45 | sideral | Torne: It'd have to be partition-relative |
00:24:59 | Torne | huh? |
00:25:05 | Torne | you mean have the identifier refer to the physical location on the disk? |
00:25:10 | Torne | that doesn't work if you, er, ever write to the disk :) |
00:25:17 | sideral | pamaury: Don't think so, as the blocks could be reread if they were evicted |
00:25:37 | pamaury | but how do you assign identifiers ? |
00:25:46 | sideral | directory entries basically never change their disk offset in FAT |
00:25:52 | Torne | Er |
00:25:54 | Torne | Sure they do |
00:25:55 | Torne | Delete file. |
00:25:58 | pamaury | rename |
00:25:58 | Torne | Et voila :) |
00:26:04 | Torne | Or, yeah, rename it |
00:26:06 | Torne | to somethign longer |
00:26:11 | pamaury | not even |
00:26:28 | Torne | anyway, yeah, simplest case: delete file |
00:26:31 | pamaury | the fat code is stupid, it doesn't reuse entries iirc |
00:26:42 | pamaury | (not all the time) |
00:27:12 | sideral | delete file is unimportant I think, the DB doesn't need IDs for deleted files (doesn't work with dircache either) |
00:27:21 | sideral | pamaury: OK |
00:27:31 | sideral | it was just an idea :) |
00:27:51 | pamaury | 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 | sideral | I'm not so pessimistic that we could synthesize something like an inode number for FAT files |
00:28:49 | Torne | er |
00:28:52 | Torne | People have tried this before |
00:28:54 | Torne | it hasn't worked |
00:28:54 | sideral | it doesn't have to be perfect, just enough for our used cases |
00:29:10 | sideral | s/used/use/ |
00:29:16 | Torne | inodes work because they never have to move :) |
00:29:16 | AlexP_ | sideral: Would it let you browse, build playlists etc. without spinning up the disk? |
00:29:22 | Torne | FAT direntries move all the time |
00:29:26 | kugelp | the dircache is just enough for our use cases :-) |
00:29:42 | sideral | AlexP: the idea would be that everything you need frequently is already in the cache. :) |
00:30:04 | pamaury | 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 | AlexP_ | I need to be able to browse potentially any of the files/directories on disk frequently |
00:30:34 | sideral | AlexP: then you need to prime your cache well :) |
00:30:42 | AlexP_ | This sounds much worse |
00:30:50 | kugelp | pamaury: not sure you can sensibly abstract exploiting the dircache |
00:30:51 | AlexP_ | Not everything is about the DB |
00:31:06 | kugelp | you have dircache ids or... nothing |
00:31:09 | sideral | Yeah, I'm aware of that AlexP |
00:31:12 | AlexP_ | File browsing is a primary function, and there are many HD targets |
00:31:26 | AlexP_ | So we should not make other things worse for the sake of the DB |
00:31:57 | Torne | sideral: look at this from my ipodvideo64mb's POV |
00:32:01 | Torne | I don't use the db |
00:32:04 | sideral | I suppose we could prime it by just going reading the dir hierarchy once |
00:32:06 | pamaury | The DB uses optimization for names (basically) so you can abstract from the method used to store a name |
00:32:09 | Torne | I can browse the entire fs without a slow expensive spinup, guaranteed |
00:32:15 | Torne | at a cost of a tiny, tiny fraction of the available RAM |
00:32:35 | Llorean | sideral: If you're just going to read the directory hierarchy, why even have it be LRU? |
00:32:35 | Torne | 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 | Torne | since subdirectories are bloated and you also need to cache the FAT |
00:33:02 | Torne | otherwise you can't read any subdirectories that are longer than a cluster |
00:33:06 | Torne | (well, parts of the FAT) |
00:33:19 | * | sideral goes on record saying the DB code is not crappy!!1!oneeleven! |
00:34:04 | Llorean | 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 | Torne | Llorean: Well the amoutn of ram is not really the thing even |
00:34:37 | sideral | Before kugel implemented dircache compaction, the dircache was quite hugr |
00:34:40 | sideral | huge |
00:34:40 | Torne | You don't know how much ram you *need* |
00:34:48 | pamaury | the DB code has been buggy for years because of this horrible mess of tricky details everywhere with a poor abstraction |
00:34:49 | Torne | so any limit is too low, potentially |
00:34:50 | sideral | and nobody objected :) |
00:35:12 | Llorean | 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 | Torne | sideral: it wasn't huge for me |
00:35:15 | kugelp | 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 | Torne | it was, like, 100kb |
00:35:22 | Torne | still is afaik |
00:35:29 | pamaury | 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 | Torne | 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 | Torne | 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 | kugelp | the struct member removal reduced its size |
00:36:13 | sideral | kugel: Ah, maybe I misunderstood the point of compaction then? |
00:36:24 | pamaury | it's wasn't *huge* |
00:36:30 | AlexP_ | Torne: I think mine is quite a bit bigger, but that is well worth it too to guarantee no spin up |
00:36:35 | pamaury | the reduction came from something unrelated to compaction |
00:36:51 | sideral | OK, point taken |
00:36:56 | kugelp | sideral: I changed the layout, so that names are allocated from the end |
00:37:39 | kugelp | and since the the non-transparent build doesn't know the size in advance it needs to compact when it dies |
00:37:43 | kugelp | does |
00:38:34 | sideral | pamaury: I don't think the DB is so bad, but I agree that it could use more abstraction |
00:39:08 | sideral | but that's perhaps a different discussion. :) |
00:39:49 | | Quit pamaury (Remote host closed the connection) |
00:40:01 | sideral | The playlist code and the file-browser also have lots of #ifdef HAVE_DIRCACHE and would be simplified |
00:40:30 | Llorean | 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 | sideral | bah, features ;) |
00:42:08 | sideral | How fast is flash memory in comparison to hard drives? |
00:43:11 | sideral | Llorean: In principle I agree with your list, but personally I wouldn't draw the line so rigidly |
00:45:12 | Llorean | What's the point of a dircache if it no longer does what dircache was put in explicitly to do? |
00:45:51 | Llorean | 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 | Llorean | Do you see any feature of the dircache as "essential"? |
00:47:13 | sideral | As I said, I mostly agree with your list. I'd hate any change to slow down FS or DB browsing |
00:47:20 | sideral | or playlist generation |
00:47:33 | sideral | but I'd tolerate it as an exception |
00:47:47 | AlexP_ | I would if it were once a year |
00:47:56 | AlexP_ | But not if it were at all common |
00:48:01 | sideral | because I value functionality, including robustness, higher than overall speed |
00:48:15 | AlexP_ | But that is removing functionality |
00:48:38 | sideral | crashing more often also removes functionality |
00:48:44 | Llorean | sideral: Dircache was very, very stable for filetree users for quite a long time. |
00:48:46 | Espreon | kugelp: I replied to your comment. |
00:48:53 | AlexP_ | dircache has been hugely stable |
00:48:55 | Llorean | 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 | AlexP_ | I haven't had a crash in years |
00:49:22 | kugelp | then you haven't updated recently :-) |
00:49:35 | AlexP_ | kugelp: Not in the last couple of weeks, no :) |
00:49:49 | sideral | 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 | sideral | this (until two weeks ago) made the DB crasg |
00:50:05 | sideral | crash |
00:50:36 | Llorean | And now it's fixed. |
00:50:43 | Llorean | So it seems like it's a non-issue any more for this discussion. |
00:50:49 | sideral | Llorean: But I'd rather not have to program around sudden service disruptions in the DB |
00:51:23 | sideral | it's fixed only in that the DB doesn't crash any more |
00:51:26 | Llorean | 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 | sideral | the dircache still shuts down in this case |
00:51:56 | Llorean | And it's 100% impossible to have dircache not shut down in that case? |
00:52:36 | kugelp | the lru thing won't work as well as dircache, very sure about that |
00:52:44 | sideral | Llorean: It's not simple. If you have a good idea, chime in to FS #12216 :) |
00:52:44 | fs-bluebot | http://www.rockbox.org/tracker/task/12216 Dircache shuts down when closing a file that was opened prior to reloading the dircache (bugs, new) |
00:53:02 | Llorean | 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 | sideral | I do understand you concern, Llorean |
00:54:36 | | Quit simabeis (Ping timeout: 240 seconds) |
00:54:41 | sideral | 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 | sideral | 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 | Torne | if we wanted it to be really fault robust we wound't cache the disk at all :) |
00:55:53 | Torne | because that's way simpler to implement reliably |
00:55:53 | Llorean | 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 | sideral | 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 | Llorean | By that standard we could remove any feature in the name of "less complexity" |
00:58:20 | Llorean | My first vote is the database. It's *always* been somewhat buggy. |
00:59:01 | Llorean | 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 | sideral | hehe. I wasn't proposing to remove any function −− but to relax one of the nonfunctional requirements :) |
00:59:45 | AlexP_ | A dircache which no longer guarantees no spin up is removing functions |
01:00 |
01:00:02 | Llorean | 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 | Llorean | *The* function of the dircache was "file browsing no longer requires a disk spinup" |
01:01:15 | Llorean | 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 | sideral | this is getting into dangerous specification geek territory −− let's not go there :) |
01:01:43 | Llorean | 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 | sideral | let's agree that not having disk spinups is a requirement |
01:01:51 | Llorean | Because that's "specification geek territory"? |
01:02:01 | Torne | it *never* spinning up *is* a functional requirement |
01:02:12 | Llorean | Okay. No disk spinups during file browsing when the feature is turned on. |
01:02:14 | Torne | "never" is something a user can trivially observe :) |
01:03:05 | sideral | I'll rather pass than starting a discussion of functional vs nonfunctional requirement at this time of day −− so you win :) |
01:03:28 | AlexP_ | The point of a feature doesn't need discussion - it is the point |
01:03:50 | bertrik | Do we have any functional requirement written somewhere at all? |
01:04:06 | | Quit GeekShadow (Ping timeout: 240 seconds) |
01:04:31 | sideral | bertrik: there are tons of *unwritten* requirements all over Rockbox |
01:04:53 | sideral | 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 | sideral | 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 | Llorean | 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 | sam_t | has anyone seen floatsaka |
01:48:33 | sideral | Llorean: No, I have not. Has it been that obvious? ;) |
01:49:50 | sideral | 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 | sam_t | Llorean, do you remember a dude named floatsaka? |
01:56:10 | *** | Saving seen data "./dancer.seen" |
02:00 |
02:15:26 | AlexP_ | 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 | Llorean | 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 | Llorean | 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:00 |
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 | mc2739 | 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 |
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 | JdGordon | 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:00 |
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:00 |
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:00 |
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 |
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 | amiconn | 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 | amiconn | 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:00 |
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:00 |
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 | kugelp | amiconn: I noticed that behavior in the code. and I don't understand it |
10:46:01 | kugelp | 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 | kugelp | can any of the lang or AE vs BE guys look at fs#12232? |
10:57:25 | fs-bluebot | http://www.rockbox.org/tracker/task/12232 American English translation update (patches, unconfirmed) |
11:00 |
11:02:30 | Llorean | 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 | Llorean | It may be acceptable, but I'd go with it being the less common. |
11:03:07 | kugelp | that was my guess too |
11:03:09 | Llorean | 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 | kugelp | I agree |
11:03:58 | God_Eater | If you prefer BE - don't use AE.lang ;) |
11:05:48 | Llorean | 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:00 |
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:00 |
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:00 |
14:15:38 | | Quit dunkaist (Quit: leaving) |
14:17:20 | CIA-14 | New commit by mc2739 (r30320): Update American English language |
14:19:58 | CIA-14 | 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 | kugel | 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:00 |
15:01:11 | CIA-14 | New commit by kugel (r30321): Dircache: Fix memory leak (and recently panic). ... |
15:03:49 | CIA-14 | 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 | Espreon | Ugh, why must my translation be mutilated? |
15:24:38 | kugel | Espreon: http://www.rockbox.org/irc/log-20110816#10:57:24 |
15:25:05 | kugel | we don't agree that BE is suitable for english-us.lang |
15:25:12 | kugel | 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 | Espreon | It's not BE. |
15:27:37 | Espreon | It's merely the formal spelling. |
15:28:51 | Torne | common usage is overwhelmingly catalog |
15:29:07 | Espreon | And? |
15:29:09 | Espreon | 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 | Espreon | What is that supposed to mean?> |
15:29:35 | Torne | 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 | kugel | 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 | Torne | 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 | Torne | 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 | Espreon | 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 | Espreon | The use of "favour" and "realise", however, would be questioned. |
15:36:22 | Espreon | And they're unacceptable. |
15:37:29 | kugel | it's not only about what's acceptable, but about what's common |
15:38:01 | Zagor | wikipedia's manual of style says "catalog is the preferred spelling in American English." |
15:38:19 | Zagor | not that it's our reference, just a data point |
15:38:28 | Zagor | http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(spelling) |
15:38:58 | Espreon | kugel: Just because something's commonly done doesn't mean it should be done. |
15:39:10 | Espreon | Seriously, do any of you even use english-us.lang? |
15:39:34 | mc2739 | yes |
15:40:21 | Zagor | http://en.wiktionary.org/wiki/catalog |
15:41:03 | Zagor | http://wiki.answers.com/Q/What_is_the_difference_between_'catalog'_and_'catalogue' same thing |
15:42:26 | Zagor | http://eprints.rclis.org/bitstream/10760/6859/1/Beall_Catalog.pdf |
15:43:23 | | Quit simonlnu (Ping timeout: 258 seconds) |
15:44:01 | Espreon | I guess that I don't control my own translation. Is this correct? |
15:44:47 | gevaerts | Espreon: it's not your translation. It's the rockbox US English translation to which you are a (possibly major) contributor |
15:45:31 | gevaerts | 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 | Zagor | 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 | Zagor | 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 | Espreon | 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 | Espreon | At this point, I really wish to not be affiliated with that translation, but IDK. |
15:49:45 | AlexP | Surely catalogue is far too frenchified for you? |
15:51:27 | Zagor | Espreon: well has there been any discussion about dialogue, or has simply nobody considered it? |
15:52:20 | AlexP | 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 | Espreon | 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 | Zagor | oh, there is no "dialogue" in the lang files :-) |
15:54:52 | | Quit bluefoxx (Ping timeout: 258 seconds) |
15:55:08 | Zagor | how about "queue" ;-) |
15:55:51 | Espreon | 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 | Espreon | 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 | Torne | Arguing that the translation is inconsistent is missing the point somewhat :) |
15:56:39 | Torne | The *language* is inconsistent |
15:56:43 | * | gevaerts proposes to drop *all* English text from rockbox |
15:56:44 | Torne | that's just how it works :) |
15:57:03 | God_Eater | if you want consistency, learn lojban ;) |
15:57:07 | JdGordon | gevaerts: why stop there? |
15:57:30 | gevaerts | JdGordon: I think numeric IDs for strings are all we need |
15:57:38 | Zagor | Espreon: I think the lang files should reflect the language commonly used (and thus, expected) |
15:57:50 | JdGordon | you prude! |
15:58:22 | | Quit bluefoxx (Client Quit) |
15:59:17 | Espreon | Torne: That may be, but that's no reason to continue the madness. |
15:59:34 | Torne | yes there is! |
15:59:39 | Torne | Language is what people use. |
15:59:40 | Zagor | what madness? |
15:59:44 | Torne | Any other approach is mad |
16:00 |
16:00:00 | Zagor | spelling words as most people expect them is madness? |
16:01:04 | | Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) |
16:01:25 | Espreon | God_Eater: ... No. Just... no. |
16:01:51 | Espreon | 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 | Espreon | 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 | Torne | you already don't own it, so that's a no-op |
16:04:08 | Espreon | Whatever. Remove the line in the file affiliating me with it. |
16:05:21 | Espreon | 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 | CoLdAsSauLt | Hi |
16:08:52 | CoLdAsSauLt | I was looking for some help |
16:09:09 | CoLdAsSauLt | I would like to install a patch, i.e. the Meier crossfeed emulation |
16:09:21 | CoLdAsSauLt | but I'm not sure how and where to start with the patching thing... |
16:09:33 | CoLdAsSauLt | any clues or help would be greatly appreciated :) |
16:10:17 | Zagor | CoLdAsSauLt: http://www.rockbox.org/wiki/WorkingWithPatches |
16:12:33 | CoLdAsSauLt | http://gnuwin32.sourceforge.net/packages/patch.htm |
16:12:43 | Espreon | Would somone just please unaffiliate me from that translation? That is all I shall ever ask of you. |
16:12:47 | CoLdAsSauLt | 2007... is this the latest version? |
16:12:56 | CoLdAsSauLt | or doesn't that matter? |
16:13:30 | Zagor | CoLdAsSauLt: doesn't matter |
16:13:37 | CoLdAsSauLt | k thx |
16:14:13 | Zagor | Espreon: sure |
16:14:31 | Espreon | 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 | CIA-14 | New commit by zagor (r30322): Removed attribution, at author's request. |
16:25:27 | CIA-14 | r30322 build result: All green |
16:25:55 | Espreon | 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 | n1s | Zagor: any comments on fs#12231 |
16:47:51 | fs-bluebot | http://www.rockbox.org/tracker/task/12231 Centralize codec compilation flag setting (patches, new) |
16:49:15 | Zagor | it looks terrific |
16:50:05 | n1s | great |
16:50:18 | kugel | 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 | kugel | $ LANG=C make zip |
16:51:32 | kugel | make: Nothing to be done for `zip'. |
16:51:42 | kugel | that's buggered |
16:51:48 | Zagor | hmm |
16:57:02 | | Quit HaimN (Quit: No Ping reply in 180 seconds.) |
16:57:04 | Zagor | I'll have to look at that later |
16:57:39 | | Join HaimN [0] (~quassel@31.44.142.168) |
17:00 |
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 |
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 | Guest21717 | 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 | bluebroth3r | 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 | Guest21717 | Haha, it is, which is the thing. |
18:49:55 | bluebroth3r | I almost never use the database so not much experience on my side. |
18:50:00 | Guest21717 | the size of the folder[s] shouldn't matter right? |
18:50:24 | bluebroth3r | no |
18:51:49 | Guest21717 | Well, I've rechecked the files, and the folders come up empty... |
18:52:10 | Guest21717 | But that's normal, right? |
18:54:11 | Guest21717 | bluebroth3r, if you don't use the database, what do you use? |
18:55:23 | bluebroth3r | the file browser. It's much nicer if you have the appropriate folder structure ;-) |
18:55:46 | Guest21717 | Ah there we go, I've got it fixed. I guess it just took a while for it to read. |
18:55:57 | Guest21717 | Thanks for the help! |
18:55:59 | | Quit Guest21717 (Quit: CGI:IRC) |
18:56:04 | bluebroth3r | 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 | bluebroth3r | wow. Kinda impatient :/ |
18:57:12 | | Quit froggyman (Quit: Ex-Chat) |
18:59:00 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
19:00 |
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:00 |
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:00 |
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 | CIA-14 | New commit by thomasjfox (r30323): perl magic: Use if/elsif/else instead of given/when (FS #12188) ... |
21:29:01 | CIA-14 | r30323 build result: All green |
21:29:30 | | Join TheLemonMan [0] (~lem0n@ppp-66-44.26-151.libero.it) |
21:30:25 | CIA-14 | New commit by thomasjfox (r30324): Add Nick Peskett to CREDITS |
21:31:22 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
21:32:44 | CIA-14 | 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 | thomasjfox | 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 |
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 | stephen__ | 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 | user890104 | 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:00 |
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 | glued | 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 | glued | 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 | AlexP | glued: You can try to catch him here, but if not you should probably file a bug report |
23:41:13 | glued | Maybe if someone else could confirm it, I don't trust myself at nights. |
23:44:19 | AlexP | That sounds worrying :) |
23:54:15 | glued | 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 | glued | 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" |