Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2011-08-16

00:00:21kugelpI'm just not at the laptop but chatting from ny phone
00:01:31sideralah OK. so are you ready for my mind-boggling idea?
00:05:17kugelpyes :-)
00:06:08sideralso here it comes: Let's reduce the complexity of the dircache by...
00:06:13sideral...abolishing it!
00:06:30sideralLet's use the plenty of space we get for an LRU block cache
00:06:59LloreanWith dircache off, playlist generation can take orders of magnitude more time on some disk targets.
00:07:19sideralLots of dircache-related code will just vanish in exchange for some small hashing complexity in the block cache
00:08:02sideralThe bet is that going through the filesystem into the block cache wouldn't be much slower
00:08:20AlexP_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:48sideralWell no, the idea is to have the relevant data cached in the block cache
00:08:55AlexP_OK
00:09:03LloreanAlexP_: 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:08AlexP_I don't care how you do it as long as the effect is the same :)
00:09:10kugelpsideral: not sure
00:09:11Tornepresumably you wouldn't read data blocks into the cache?
00:09:23LloreanAlexP_: But waiting 10s or 100s of seconds for a large playlist to populate sucked.
00:09:24sideralTorne: definitely not the audio data.
00:09:36AlexP_Llorean: It makes a pause of 3 or 4 seconds on some targets. Every time you start browsing
00:09:41sideralThe filesystem would have to hint the caching scheme to the block layer
00:09:46Tornesideral: well, very little gets read repeatedly except via buffering
00:09:55LloreanAlexP_: Yeah, I remember. :) But 3 or 4 seconds isn't that long unless you stop and start browsing very frequently.
00:10:02sideralit would be LRU for directory entries / FAT, and don't care for most of everything else
00:10:07AlexP_I tend to
00:10:09LloreanOr if your spindown time is too low for your habits.
00:10:20AlexP_And 3 - 4 seconds was a huge time then
00:10:20kugelpthe dircache works well for our not-general purpose file systems no?
00:10:38Tornesideral: i can't help but think this will use more ram for less benefit
00:10:44LloreanAlexP_: 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:45Tornewel, or the same amount of ram for less benefit.
00:11:04AlexP_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:08kugelpand maintaining the lru is probably more complete than the dircache
00:11:17sideralThat's something that needs to be substantiated for sure
00:11:27Tornethe dircache is more dense than a block cache of the directory data ont he disk
00:11:30Tornelet alone the FAT
00:11:31AlexP_Llorean: Having to wait a few seconds even every half an hour or so is very annoying
00:11:39sideralkugel: No, maintaining LRU is easy and fast, as is hashing
00:11:52LloreanAlexP_: 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:57AlexP_I do
00:12:06AlexP_Well, depends on the improvements
00:12:20LloreanYes, it depends on the improvements.
00:12:21AlexP_But they'd have to be enormous
00:12:28LloreanI don't think they'd have to be enormouse.
00:12:32AlexP_I do :)
00:12:38LloreanThey'd just have to be one less annoyance ever 30 minutes
00:12:47AlexP_Especially as we have dircache now
00:12:49LloreanOr, less bugs due to dircache complexity.
00:13:03kugelpsideral: not if I look at our font code :-)
00:13:14AlexP_It'd be a major step back
00:13:16LloreanBut it'd be unacceptable to go back to the time of counting dynamic playlist generation time in minutes.
00:13:28AlexP_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:36sideralThe 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:39AlexP_See, it all depends what matters to you
00:13:59AlexP_I just don't want to have to go back to waiting for spin up on browsing
00:14:00LloreanIn an objective sense, waiting 3 seconds for an operation vs waiting 3 minutes is pretty significantly differenct.
00:14:06kugelpthe "dircache clients"?
00:14:06sideraland we'd have fewer bugs for sure :)
00:14:13AlexP_In fact, that would just lead me to not updating Rockbox anymore
00:14:17Tornethe dircache guarantees that browsing doesn't need to touch the disk (under normal circumstances)
00:14:28sideralkugel: everything that does special stuff with the dircache, especially the database
00:14:36pamauryI 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:37Tornea block cache would not, even if it did improve other things somewhat
00:14:40kugelpI really doubt it would reduce complexity
00:14:47 Join drezon [0] (~drezon@2001:6f8:1029:2:1a3d:a2ff:fe60:4ae0)
00:14:48Lloreansideral: 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:05sideralLlorean: sure. This is only a thought experiment so far :)
00:15:20sideralThere's one major problem with my idea that I see:
00:15:23LloreanIt certainly sounds like the idea would sacrifice some of the benefits of dircache for gaining improvements on the non-user-visible side.
00:15:26LloreanThat doesn't seem a win.
00:15:30AlexP_exactly
00:15:45kugelpthe block cache is what Linux does isn't it?
00:15:50sideralwell, bugs and crashes are user visible :)
00:15:55Lloreansideral: But fixable.
00:16:05Tornecurrently virtually all of our disk accesses come down to two categories: directory accesses and buffering
00:16:13Tornethe former is more efficiently served by the dircache
00:16:14LloreanWhereas 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:19Tornethe latter is not really served by caching at all
00:16:37pamaurydircache works rather well; it's a bit unstable recently due to kugel fiddling with it but appart from that... :)
00:16:41kugelpI agree with Torne
00:16:53sideralSo 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:59Tornearguments about complexity/etc seem uninteresting
00:17:12TorneI don't think we should implement something worse because we think we can implement it more reliably
00:17:19Tornewe should just try harder to implement the best thing *right* :)
00:17:26*Llorean agrees with Torne
00:17:29AlexP_me too
00:17:50Torneour storage usage is very unlike a normal OS :)
00:18:00sideralNo disagreement there :)
00:18:13AlexP_and not forget HD and non-db users :)
00:18:21AlexP_Or, at the same time remove db load to RAM :)
00:18:25Tornewe're not general purpose; so my usual assumption is we can do better than a general purpose solution to virtually *every* problem
00:18:37pamauryAnd 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:50LloreanI 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:06sideralpamaury: The dircache itself isn't, but the dircache clients suffer enormous complexity
00:19:24pamaurywhich "enormous complexity" ?
00:19:58sideralpamaury: For example, the DB has a combination of #ifdef hell and if-the-else disease because of the dircache
00:20:11sideraland I've found a few bugs in there recently
00:20:17sideralI'm sure there are more lurking :)
00:20:31Torneright, but the database is 1) complicated anyway and 2) not used by as many people :)
00:20:44pamaurythe database is one of the worst pieces of code
00:20:45Tornei realise you care about it, but if that's your only example then i suspect we are willing to take that hit :)
00:20:51sideralI thought it would be cool if that could be hidden below the POSIX layer :)
00:21:06TorneRight, but it can't be, without costing more ram
00:21:12sideralI wouldn't want anyone to take a hit Torne :)
00:21:29AlexP_Then don't make me suffer spin up times etc. :)
00:21:32LloreanAnd RAM is most important on targets where Dircache is most beneficial.
00:21:33Tornethe 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:50pamaurywe 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:58sideralTorne: 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:02pamaury*can't
00:22:20sideral(or maybe in the FS layer rather than in the block cache)
00:22:33TorneThe directory blocks will *always* use more space, though
00:22:34pamaurybut memory blocks use a horribly complicated structure due to FAT
00:22:48Torneas pamaury says
00:22:49Tornealso fragmentation
00:23:51pamauryjust 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:05sideralre the DB using dircache IDs as filename references: This service could be offered by the FAT FS as well
00:24:17Tornesideral: How?
00:24:25TorneHow do you have stable identifiers for things in a LRU cache?
00:24:28pamauryyou would end up with dircache !
00:24:41TorneYou can't evict things and still know what those identifiers mean
00:24:45sideralTorne: It'd have to be partition-relative
00:24:59Tornehuh?
00:25:05Torneyou mean have the identifier refer to the physical location on the disk?
00:25:10Tornethat doesn't work if you, er, ever write to the disk :)
00:25:17sideralpamaury: Don't think so, as the blocks could be reread if they were evicted
00:25:37pamaurybut how do you assign identifiers ?
00:25:46sideraldirectory entries basically never change their disk offset in FAT
00:25:52TorneEr
00:25:54TorneSure they do
00:25:55TorneDelete file.
00:25:58pamauryrename
00:25:58TorneEt voila :)
00:26:04TorneOr, yeah, rename it
00:26:06Torneto somethign longer
00:26:11pamaurynot even
00:26:28Torneanyway, yeah, simplest case: delete file
00:26:31pamaurythe fat code is stupid, it doesn't reuse entries iirc
00:26:42pamaury(not all the time)
00:27:12sideraldelete file is unimportant I think, the DB doesn't need IDs for deleted files (doesn't work with dircache either)
00:27:21sideralpamaury: OK
00:27:31sideralit was just an idea :)
00:27:51pamauryTo 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:34sideralI'm not so pessimistic that we could synthesize something like an inode number for FAT files
00:28:49Torneer
00:28:52TornePeople have tried this before
00:28:54Torneit hasn't worked
00:28:54sideralit doesn't have to be perfect, just enough for our used cases
00:29:10siderals/used/use/
00:29:16Torneinodes work because they never have to move :)
00:29:16AlexP_sideral: Would it let you browse, build playlists etc. without spinning up the disk?
00:29:22TorneFAT direntries move all the time
00:29:26kugelpthe dircache is just enough for our use cases :-)
00:29:42sideralAlexP: the idea would be that everything you need frequently is already in the cache. :)
00:30:04pamauryI believe the problem lies in the DB code, it should be written in a way which abstract from these tricky details
00:30:04AlexP_I need to be able to browse potentially any of the files/directories on disk frequently
00:30:34sideralAlexP: then you need to prime your cache well :)
00:30:42AlexP_This sounds much worse
00:30:50kugelppamaury: not sure you can sensibly abstract exploiting the dircache
00:30:51AlexP_Not everything is about the DB
00:31:06kugelpyou have dircache ids or... nothing
00:31:09sideralYeah, I'm aware of that AlexP
00:31:12AlexP_File browsing is a primary function, and there are many HD targets
00:31:26AlexP_So we should not make other things worse for the sake of the DB
00:31:57Tornesideral: look at this from my ipodvideo64mb's POV
00:32:01TorneI don't use the db
00:32:04sideralI suppose we could prime it by just going reading the dir hierarchy once
00:32:06pamauryThe DB uses optimization for names (basically) so you can abstract from the method used to store a name
00:32:09TorneI can browse the entire fs without a slow expensive spinup, guaranteed
00:32:15Torneat a cost of a tiny, tiny fraction of the available RAM
00:32:35Lloreansideral: If you're just going to read the directory hierarchy, why even have it be LRU?
00:32:35Torneoff 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:53Tornesince subdirectories are bloated and you also need to cache the FAT
00:33:02Torneotherwise you can't read any subdirectories that are longer than a cluster
00:33:06Torne(well, parts of the FAT)
00:33:19*sideral goes on record saying the DB code is not crappy!!1!oneeleven!
00:34:04LloreanTorne: 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:33TorneLlorean: Well the amoutn of ram is not really the thing even
00:34:37sideralBefore kugel implemented dircache compaction, the dircache was quite hugr
00:34:40sideralhuge
00:34:40TorneYou don't know how much ram you *need*
00:34:48pamaurythe DB code has been buggy for years because of this horrible mess of tricky details everywhere with a poor abstraction
00:34:49Torneso any limit is too low, potentially
00:34:50sideraland nobody objected :)
00:35:12Lloreansideral: We didn't like it, but it was necessary. now it's not necessary, but someone's proposing we do it anyway...
00:35:13Tornesideral: it wasn't huge for me
00:35:15kugelpsideral: 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:17Torneit was, like, 100kb
00:35:22Tornestill is afaik
00:35:29pamaurythe dircache wasn't buggy before compaction !
00:35:35*Llorean would love if dircache were 1/3 the size it is now.
00:35:44Torne100kb 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:03TorneHaving a block cache which is multiple times larger is multiple times more expensive, and *still* may not succeed all the time
00:36:04kugelpthe struct member removal reduced its size
00:36:13sideralkugel: Ah, maybe I misunderstood the point of compaction then?
00:36:24pamauryit's wasn't *huge*
00:36:30AlexP_Torne: I think mine is quite a bit bigger, but that is well worth it too to guarantee no spin up
00:36:35pamaurythe reduction came from something unrelated to compaction
00:36:51sideralOK, point taken
00:36:56kugelpsideral: I changed the layout, so that names are allocated from the end
00:37:39kugelpand since the the non-transparent build doesn't know the size in advance it needs to compact when it dies
00:37:43kugelpdoes
00:38:34sideralpamaury: I don't think the DB is so bad, but I agree that it could use more abstraction
00:39:08sideralbut that's perhaps a different discussion. :)
00:39:49 Quit pamaury (Remote host closed the connection)
00:40:01sideralThe playlist code and the file-browser also have lots of #ifdef HAVE_DIRCACHE and would be simplified
00:40:30LloreanSo 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:25sideralbah, features ;)
00:42:08sideralHow fast is flash memory in comparison to hard drives?
00:43:11sideralLlorean: In principle I agree with your list, but personally I wouldn't draw the line so rigidly
00:45:12LloreanWhat's the point of a dircache if it no longer does what dircache was put in explicitly to do?
00:45:51LloreanIt 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:25LloreanDo you see any feature of the dircache as "essential"?
00:47:13sideralAs I said, I mostly agree with your list. I'd hate any change to slow down FS or DB browsing
00:47:20sideralor playlist generation
00:47:33sideralbut I'd tolerate it as an exception
00:47:47AlexP_I would if it were once a year
00:47:56AlexP_But not if it were at all common
00:48:01sideralbecause I value functionality, including robustness, higher than overall speed
00:48:15AlexP_But that is removing functionality
00:48:38sideralcrashing more often also removes functionality
00:48:44Lloreansideral: Dircache was very, very stable for filetree users for quite a long time.
00:48:46Espreonkugelp: I replied to your comment.
00:48:53AlexP_dircache has been hugely stable
00:48:55LloreanIf someone's added things that make it crash now, isn't the solution "fix those things" rather htan "throw it out"?
00:49:00AlexP_I haven't had a crash in years
00:49:22kugelpthen you haven't updated recently :-)
00:49:35AlexP_kugelp: Not in the last couple of weeks, no :)
00:49:49sideralone 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:02sideralthis (until two weeks ago) made the DB crasg
00:50:05sideralcrash
00:50:36LloreanAnd now it's fixed.
00:50:43LloreanSo it seems like it's a non-issue any more for this discussion.
00:50:49sideralLlorean: But I'd rather not have to program around sudden service disruptions in the DB
00:51:23sideralit's fixed only in that the DB doesn't crash any more
00:51:26Lloreansideral: 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:32sideralthe dircache still shuts down in this case
00:51:56LloreanAnd it's 100% impossible to have dircache not shut down in that case?
00:52:36kugelpthe lru thing won't work as well as dircache, very sure about that
00:52:44sideralLlorean: It's not simple. If you have a good idea, chime in to FS #12216 :)
00:52:44fs-bluebothttp://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:02LloreanEven 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:49sideralI do understand you concern, Llorean
00:54:36 Quit simabeis (Ping timeout: 240 seconds)
00:54:41sideralI 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:21sideralAnd 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:51Torneif we wanted it to be really fault robust we wound't cache the disk at all :)
00:55:53Tornebecause that's way simpler to implement reliably
00:55:53LloreanI'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:31sideralyeah. 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:14LloreanBy that standard we could remove any feature in the name of "less complexity"
00:58:20LloreanMy first vote is the database. It's *always* been somewhat buggy.
00:59:01LloreanIn 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:04sideralhehe. I wasn't proposing to remove any function −− but to relax one of the nonfunctional requirements :)
00:59:45AlexP_A dircache which no longer guarantees no spin up is removing functions
01:00
01:00:02LloreanWould 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:24Llorean*The* function of the dircache was "file browsing no longer requires a disk spinup"
01:01:15LloreanYou'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:16sideralthis is getting into dangerous specification geek territory −− let's not go there :)
01:01:43Lloreansideral: So you're allowed to call part of the feature "not a requirement" but we're not allowed to contradict it?
01:01:51siderallet's agree that not having disk spinups is a requirement
01:01:51LloreanBecause that's "specification geek territory"?
01:02:01Torneit *never* spinning up *is* a functional requirement
01:02:12LloreanOkay. No disk spinups during file browsing when the feature is turned on.
01:02:14Torne"never" is something a user can trivially observe :)
01:03:05sideralI'll rather pass than starting a discussion of functional vs nonfunctional requirement at this time of day −− so you win :)
01:03:28AlexP_The point of a feature doesn't need discussion - it is the point
01:03:50bertrikDo we have any functional requirement written somewhere at all?
01:04:06 Quit GeekShadow (Ping timeout: 240 seconds)
01:04:31sideralbertrik: there are tons of *unwritten* requirements all over Rockbox
01:04:53sideralI 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:08sideralAlexP: 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:23Lloreansideral: 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:47sam_thas anyone seen floatsaka
01:48:33sideralLlorean: No, I have not. Has it been that obvious? ;)
01:49:50sideralWell, 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:43sam_tLlorean, do you remember a dude named floatsaka?
01:56:10***Saving seen data "./dancer.seen"
02:00
02:15:26AlexP_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:32Lloreansideral: 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:09LloreanA 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:48mc2739any 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:54JdGordonAlexP: 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:19amiconnTorne: (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:16amiconnThis 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:07kugelpamiconn: I noticed that behavior in the code. and I don't understand it
10:46:01kugelpwait, 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:24kugelpcan any of the lang or AE vs BE guys look at fs#12232?
10:57:25fs-bluebothttp://www.rockbox.org/tracker/task/12232 American English translation update (patches, unconfirmed)
11:00
11:02:30Lloreankugelp: 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:38LloreanIt may be acceptable, but I'd go with it being the less common.
11:03:07kugelpthat was my guess too
11:03:09LloreanThere'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:26kugelpI agree
11:03:58God_EaterIf you prefer BE - don't use AE.lang ;)
11:05:48LloreanExactly
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:20CIA-14New commit by mc2739 (r30320): Update American English language
14:19:58CIA-14r30320 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:50kugelbtw. 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:11CIA-14New commit by kugel (r30321): Dircache: Fix memory leak (and recently panic). ...
15:03:49CIA-14r30321 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:18EspreonUgh, why must my translation be mutilated?
15:24:38kugelEspreon: http://www.rockbox.org/irc/log-20110816#10:57:24
15:25:05kugelwe don't agree that BE is suitable for english-us.lang
15:25:12kugelwhether or not it's acceptable
15:27:18 Join wtachi [0] (~wtachi@cpe-069-134-168-033.nc.res.rr.com)
15:27:29EspreonIt's not BE.
15:27:37EspreonIt's merely the formal spelling.
15:28:51Tornecommon usage is overwhelmingly catalog
15:29:07EspreonAnd?
15:29:09Espreon14: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:13EspreonWhat is that supposed to mean?>
15:29:35Torneand 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:45kugelthe whole point of english-us.lang is that english.lang includes lots of uncommon (or even wrong) translations for US people
15:31:04Tornethere seems little point if you aren't going to make the most effort to use what's common in the US
15:31:33Tornethe 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:38EspreonAnd 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:03EspreonThe use of "favour" and "realise", however, would be questioned.
15:36:22EspreonAnd they're unacceptable.
15:37:29kugelit's not only about what's acceptable, but about what's common
15:38:01Zagorwikipedia's manual of style says "catalog is the preferred spelling in American English."
15:38:19Zagornot that it's our reference, just a data point
15:38:28Zagorhttp://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(spelling)
15:38:58Espreonkugel: Just because something's commonly done doesn't mean it should be done.
15:39:10EspreonSeriously, do any of you even use english-us.lang?
15:39:34mc2739yes
15:40:21Zagorhttp://en.wiktionary.org/wiki/catalog
15:41:03Zagorhttp://wiki.answers.com/Q/What_is_the_difference_between_'catalog'_and_'catalogue' same thing
15:42:26Zagorhttp://eprints.rclis.org/bitstream/10760/6859/1/Beall_Catalog.pdf
15:43:23 Quit simonlnu (Ping timeout: 258 seconds)
15:44:01EspreonI guess that I don't control my own translation. Is this correct?
15:44:47gevaertsEspreon: it's not your translation. It's the rockbox US English translation to which you are a (possibly major) contributor
15:45:31gevaertsIf 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:44Zagorfwiw, 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:35Zagorall 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:31EspreonWell, 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:00EspreonAt this point, I really wish to not be affiliated with that translation, but IDK.
15:49:45AlexPSurely catalogue is far too frenchified for you?
15:51:27ZagorEspreon: well has there been any discussion about dialogue, or has simply nobody considered it?
15:52:20AlexPWhen 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:44EspreonAlexP: 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:46Zagoroh, there is no "dialogue" in the lang files :-)
15:54:52 Quit bluefoxx (Ping timeout: 258 seconds)
15:55:08Zagorhow about "queue" ;-)
15:55:51EspreonThat 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:55EspreonThat's different.
15:56:07 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
15:56:29***Saving seen data "./dancer.seen"
15:56:35TorneArguing that the translation is inconsistent is missing the point somewhat :)
15:56:39TorneThe *language* is inconsistent
15:56:43*gevaerts proposes to drop *all* English text from rockbox
15:56:44Tornethat's just how it works :)
15:57:03God_Eaterif you want consistency, learn lojban ;)
15:57:07JdGordongevaerts: why stop there?
15:57:30gevaertsJdGordon: I think numeric IDs for strings are all we need
15:57:38ZagorEspreon: I think the lang files should reflect the language commonly used (and thus, expected)
15:57:50JdGordonyou prude!
15:58:22 Quit bluefoxx (Client Quit)
15:59:17EspreonTorne: That may be, but that's no reason to continue the madness.
15:59:34Torneyes there is!
15:59:39TorneLanguage is what people use.
15:59:40Zagorwhat madness?
15:59:44TorneAny other approach is mad
16:00
16:00:00Zagorspelling words as most people expect them is madness?
16:01:04 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net)
16:01:25EspreonGod_Eater: ... No. Just... no.
16:01:51EspreonI 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:37EspreonAs for this, it's not going to do anything or get anyone anywhere. Fine. Do what you wish. I disown that... thing.
16:03:55Torneyou already don't own it, so that's a no-op
16:04:08EspreonWhatever. Remove the line in the file affiliating me with it.
16:05:21EspreonYou 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:26CoLdAsSauLtHi
16:08:52CoLdAsSauLtI was looking for some help
16:09:09CoLdAsSauLtI would like to install a patch, i.e. the Meier crossfeed emulation
16:09:21CoLdAsSauLtbut I'm not sure how and where to start with the patching thing...
16:09:33CoLdAsSauLtany clues or help would be greatly appreciated :)
16:10:17ZagorCoLdAsSauLt: http://www.rockbox.org/wiki/WorkingWithPatches
16:12:33CoLdAsSauLthttp://gnuwin32.sourceforge.net/packages/patch.htm
16:12:43EspreonWould somone just please unaffiliate me from that translation? That is all I shall ever ask of you.
16:12:47CoLdAsSauLt2007... is this the latest version?
16:12:56CoLdAsSauLtor doesn't that matter?
16:13:30ZagorCoLdAsSauLt: doesn't matter
16:13:37CoLdAsSauLtk thx
16:14:13ZagorEspreon: sure
16:14:31EspreonThank 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:00CIA-14New commit by zagor (r30322): Removed attribution, at author's request.
16:25:27CIA-14r30322 build result: All green
16:25:55EspreonThanks 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:51n1sZagor: any comments on fs#12231
16:47:51fs-bluebothttp://www.rockbox.org/tracker/task/12231 Centralize codec compilation flag setting (patches, new)
16:49:15Zagorit looks terrific
16:50:05n1sgreat
16:50:18kugelZagor: 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:32kugel$ LANG=C make zip
16:51:32kugelmake: Nothing to be done for `zip'.
16:51:42kugelthat's buggered
16:51:48Zagorhmm
16:57:02 Quit HaimN (Quit: No Ping reply in 180 seconds.)
16:57:04ZagorI'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:44Guest21717Hey 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:43bluebroth3rGuest21717: 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:44Guest21717Haha, it is, which is the thing.
18:49:55bluebroth3rI almost never use the database so not much experience on my side.
18:50:00Guest21717the size of the folder[s] shouldn't matter right?
18:50:24bluebroth3rno
18:51:49Guest21717Well, I've rechecked the files, and the folders come up empty...
18:52:10Guest21717But that's normal, right?
18:54:11Guest21717bluebroth3r, if you don't use the database, what do you use?
18:55:23bluebroth3rthe file browser. It's much nicer if you have the appropriate folder structure ;-)
18:55:46Guest21717Ah there we go, I've got it fixed. I guess it just took a while for it to read.
18:55:57Guest21717Thanks for the help!
18:55:59 Quit Guest21717 (Quit: CGI:IRC)
18:56:04bluebroth3rcheck 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:17bluebroth3rwow. 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:26CIA-14New commit by thomasjfox (r30323): perl magic: Use if/elsif/else instead of given/when (FS #12188) ...
21:29:01CIA-14r30323 build result: All green
21:29:30 Join TheLemonMan [0] (~lem0n@ppp-66-44.26-151.libero.it)
21:30:25CIA-14New 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:44CIA-14r30324 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:36thomasjfoxkugel: 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:44stephen__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:34user890104oh 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:40gluedHi, 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:49gluedIt'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:07AlexPglued: You can try to catch him here, but if not you should probably file a bug report
23:41:13gluedMaybe if someone else could confirm it, I don't trust myself at nights.
23:44:19AlexPThat sounds worrying :)
23:54:15gluedNo 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:13gluedJust 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"

Previous day | Next day