00:00:07 | * | gevaerts hears some weird artefacts while playing mp3 on the clip |
00:00:46 | gevaerts | Like a short bit of audio repeating every now and then |
00:01:23 | Zagor | gevaerts: which build is that? |
00:02:09 | gevaerts | Zagor: clean svn, with tagcache, quickscreen and pitchscreen disabled |
00:03:02 | Zagor | interesting. my mp3 artefact is that it is skipping over small parts (perhaps 50-100ms) every second or so |
00:03:08 | Zagor | and of course that it crashes :) |
00:03:53 | funman | gevaerts: perhaps the pcmbuffer isnt updated correctly then |
00:04:59 | Zagor | I'm having trouble fitting a c200 build in 2MB... |
00:05:26 | gevaerts | It sounds like some sort of echo, so I'm pretty sure it's not skipping. This is a 24 kbps 16kHz mp3 |
00:05:48 | Zagor | I have only tested with 44kHz ones |
00:07:00 | funman | gevaerts: oh i have only tested 22 and 44kHz, perhaps we are not precise enough for 16kHz (that must be checked at least) |
00:08:33 | Llorean | PaulJam: In the end, only the Shuffle, Repeat, and Crossfade tags are redundant, as far as I can see. What to do with them has been discussed a little, but no final decision or anything. |
00:11:03 | | Join krazykit [0] (n=kkit@adsl-99-10-105-162.dsl.ipltin.sbcglobal.net) |
00:12:51 | | Join DerDome [0] (n=DerDome@dslb-082-083-235-187.pools.arcor-ip.net) |
00:14:13 | | Quit DerDome (Client Quit) |
00:15:56 | PaulJam | Llorean: wow, i somehow had the impression that it were much more tags. i guess those 3 (or 4 if you count %cf too) duplicates don't matter too much. |
00:20:12 | Zagor | hmm? with MEMORYSIZE=2 the DRAM section only becomes 512KB. no wonder it's hard to fit! |
00:22:48 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
00:22:58 | gevaerts | You need to optimize more! |
00:23:32 | Llorean | PaulJam: If you look carefully, there are one or two other tags that seem to be duplicates (for example, volume seems to be one) but there's pretty much always some special behaviour involved that you can't replace with the generic tag. |
00:24:03 | Zagor | ahh, it's my fault. ram.link does not depend on config.h |
00:24:31 | Zagor | when setting plugin and codec buffers to the same as on clip, it fits |
00:25:46 | | Join akur [0] (n=akur@bl5-224-46.dsl.telepac.pt) |
00:25:52 | funman | Zagor: for what is worth the clip use 64kb of IRAM for rockbox, 320-64 for codecs and the rest for rockbox plugins and audio |
00:27:15 | Zagor | it has a huge iram |
00:28:17 | Llorean | funman: Regarding the Clip, and how mine isn't playing back. |
00:28:26 | Llorean | It wasn't really "crashing" |
00:28:47 | Llorean | I could FF/RW to different times, change the play/pause state and see the icon change, playback just never actually started. I was sitting silently on the WPS screen. |
00:30:00 | Llorean | funman: As a clue, the "View buffering thread" says "alloc: 1832/ 29(something offscreen)" |
00:30:07 | Llorean | Could it still be trying to buffer 32mb for some reason? |
00:30:12 | | Quit BigBambi ("Please insert girder") |
00:32:03 | Zagor | Llorean: how much buffer do you have? |
00:32:06 | funman | I cant tell |
00:32:07 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
00:32:26 | | Join BigBambi [0] (n=alex@rockbox/staff/BigBambi) |
00:32:43 | Llorean | Zagor: Is there another screen to check, it's offscreen and won't scroll on this one |
00:32:48 | Llorean | There's a bunch of extra spacing. |
00:33:25 | Zagor | Llorean: "Rockbox info" show the buffer size |
00:33:32 | Llorean | Zagor: Buffer: 593kb |
00:33:40 | | Quit moos ("Rockbox rules the DAP world") |
00:33:42 | Llorean | So that 29 at the start of it is definitely indicating *something* wrong |
00:33:54 | Zagor | Llorean: right, that's too small. I got the same symptoms as you with that buffer size. |
00:34:11 | funman | Llorean: you got a point there .. |
00:34:20 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
00:35:01 | Zagor | and the same symtom on c200 compiled for 2MB! |
00:35:46 | Zagor | haha. "Buffer: 45KB" |
00:36:00 | Zagor | it needs a diet |
00:36:35 | Bagder | 45 feels a bit on the tiny side ;-) |
00:36:42 | *** | Saving seen data "./dancer.seen" |
00:36:46 | Zagor | just a bit |
00:38:09 | funman | Zagor: hum, what if you enable the check in playback.c for pcmbuf_init() return value ? |
00:38:27 | Llorean | Zagor: Out of curiosity, does yours show the right value in the debug->view buffering thread screen? |
00:41:47 | Zagor | refreshing database... |
00:42:05 | funman | thats not a right value I think |
00:42:09 | | Quit massiveH ("Leaving") |
00:43:03 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ff68d9d00fe67850) |
00:43:05 | Zagor | funman: yeah then I get panic. 578688 > 306720 |
00:44:14 | funman | try to enlarge the RAM by a few hundreds of kilobytes then |
00:44:28 | funman | I understand that 306720 is the audiobuffer size |
00:45:03 | Zagor | that's audiobufend - filebuf |
00:46:23 | | Quit akur (Read error: 110 (Connection timed out)) |
00:48:18 | funman | filebuf is defined by buffering.c ? |
00:49:54 | Zagor | no, it's a local variable in audio_reset_buffer. it's (malloc_buf + 15) & ~15) |
00:50:46 | | Quit shotofadds ("Leaving") |
00:51:55 | | Quit ender1 (" Why geeks like computers: look chat date touch grep make unzip strip view finger mount fsck more fsck yes spray umount slee") |
00:52:00 | Zagor | oh, malloc_buf is also local :-) |
00:52:48 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-5c9fe58426eed27f) |
00:54:28 | | Join akur [0] (n=akur@bl6-146-241.dsl.telepac.pt) |
00:55:52 | | Quit funman ("http://www.mibbit.com ajax IRC Client") |
00:58:30 | | Quit faemir ("Leaving") |
00:59:56 | | Quit jhulst (Remote closed the connection) |
01:00 |
01:01:06 | | Quit bluebrother ("leaving") |
01:04:25 | | Quit herrwaldo ("Konversation terminated!") |
01:04:59 | | Quit Nico_P (Remote closed the connection) |
01:05:12 | Zagor | alloc: and usefl: in the buffer thread display shows completely bonkers values when playback fails. |
01:05:29 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
01:05:34 | Zagor | usefl: stopped at -1684852 right now... |
01:07:42 | Zagor | and it does not always trigger an sd panic |
01:07:46 | | Quit tessarakt ("Client exiting") |
01:08:11 | | Quit akur ("Leaving.") |
01:10:33 | | Quit LambdaCalculus37 ("Ka-chunka") |
01:10:35 | | Quit MarcGuay ("http://www.mibbit.com ajax IRC Client") |
01:10:50 | Zagor | flash targets should save settings more often |
01:13:29 | | Join akur [0] (n=akur@bl6-146-241.dsl.telepac.pt) |
01:17:44 | pixelma | or more flash wear? |
01:17:51 | pixelma | s/or/for |
01:18:11 | Zagor | yeah, because that is a real problem with flash players... |
01:18:55 | Zagor | rather, they don't need to delay updating the config file. |
01:19:08 | pixelma | you never know |
01:19:19 | | Quit jhMikeS (Nick collision from services.) |
01:19:22 | Zagor | though of coure this is mostly a problem on targets that tend to crash a lot :-) |
01:19:25 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
01:19:43 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
01:19:45 | | Quit culture (Read error: 110 (Connection timed out)) |
01:20:08 | | Quit bmbl ("Woah!") |
01:21:54 | kugel | rasher, Llorean: I've looked at sorting tags a bit, and I don't think it's a good idea to implement this "show artist, but internally sort by sortartst" thing |
01:22:24 | Zagor | flash wear is only a problem when you write physical prom sectors yourself. all consumer flash media does wear leveling. |
01:22:38 | PaulJam | From the AlbumArt wiki: "%Cl|50|70|c100|b100| : displays the found bitmap at position x=50, y=70. Smaller bitmaps are centered horizontally at the bottom of this rectangle. Bigger bitmaps are cropped to 100x100." isn't this wrong? or does the resizing only support upscaling? |
01:23:10 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-690befe8b8979023) |
01:23:29 | kugel | PaulJam: probably just out-of-date. |
01:23:48 | kugel | I suppose you try it out (and update the page if you're at it) |
01:23:52 | | Quit Zagor ("Clint excited") |
01:24:19 | | Quit akur ("Leaving.") |
01:24:22 | | Join akur [0] (n=akur@bl6-146-241.dsl.telepac.pt) |
01:24:30 | pixelma | reminds me of a problem I have with the scaling and wanted to ask Unhelpful about... |
01:24:51 | PaulJam | well, i'm going to try it out, but i won't be able to update the wiki. |
01:24:54 | Unhelpful | you have great timing, i just got back ;) |
01:25:16 | kugel | PaulJam: no problem. I'll do it after you told me the result |
01:25:22 | PaulJam | ok |
01:25:28 | | Part akur |
01:26:31 | Unhelpful | PaulJam: the scaler is aspect-ratio-preserving, so if the the image is a different AR from the tag, the align tags may still come into play. there's not a very nice way to explain that that's as simple is explaining it without scaling. :/ |
01:27:12 | PaulJam | Unhelpful: i was mainly referring to the "Bigger bitmaps are cropped to 100x100." part |
01:27:31 | Unhelpful | no, that doesn't happen anymore, or shouldn't, anyway. |
01:28:21 | Unhelpful | the "smaller bitmaps are ..." is also not strictly true. the bitmap is scaled to the largest size that will fit the specified constraints |
01:29:45 | pixelma | Unhelpful: have a problem most likely related to the scaling on my M5 (also in the sim). I'm playing around with a new WPS which uses 100x100 AA, but since I used one with 50x50 AA before I already downscaled the pictures. Now with a build of last Monday, the picture was displayed smaller in the center of course, now displaying these pictures seem to fail completely in the WPS they would have to be upscaled (or just displayed as before) but in the |
01:29:45 | pixelma | other WPS where they fit they are displayed |
01:29:47 | Llorean | kugel: Why would it be a bad idea? |
01:30:08 | kugel | I've looked a bit into the code |
01:31:15 | pixelma | Unhelpful: the sim tells me that it finds the file and gives me the following error message: "read_part_line: error reading image, read returned 2 expected 24", rev 19389 |
01:31:18 | kugel | and going by that it'll be a) overly complex to implement (not only because tagcache code is already complex enough), b) be most likely considerable wasteful ram and/or performance wise |
01:31:21 | Unhelpful | pixelma: it sounds like something is wrong with the nearest-neighbor scaler, then. i'll play aound in the sim and see if i can duplicate & fix it. |
01:32:00 | kugel | tagcache loads the appropriate files (database*.idx) based on the format tagnavi passes to it |
01:32:16 | pixelma | Unhelpful: thanks :) |
01:32:20 | kugel | it takes the data and does both, display and sorting, out of it |
01:32:51 | Unhelpful | pixelma: it's somehow read past the end of the image. i've seen a few different ways that can happen... i'm not sure how it's doing it now, though. :/ |
01:32:54 | kugel | now if we want to sort and display different data, we need to load both files into ram. |
01:33:02 | Llorean | kugel: Why don't you populate the "SortArtist" idx file with both Artist AND SortArtist tags (put the Artist tag there if SortArtist doesn't exist) and ALWAYS use it for sorting, and then ALWAYS use the artist .idx file for displaying? |
01:33:24 | Llorean | You need to load both files, but you need to load multiple files for more complex filters too, don't you? |
01:34:01 | kugel | and, of course, introduce special cases for the sorting tags |
01:34:39 | Llorean | kugel: The alternative is having things not work if people don't have both sorting tags and artist tags on *all* their files, though? |
01:35:02 | kugel | well, I thought about that, but that means you need to load a file which contains twice as much data as you actually need |
01:35:43 | Llorean | kugel: If no file has sortartist tags, don't generate the sortartist .idx file, and use only the one? |
01:35:47 | kugel | Llorean: I implemented fall back for files which doesn't have the sorting tags filled, that's not my concern |
01:35:51 | | Quit Thundercloud (Remote closed the connection) |
01:36:05 | Llorean | The whole point of sorting tags is that they're not *supposed* to be displayed. |
01:36:33 | Llorean | If you're going to display them, you may as well just tell people "put what you want it sorted by in the Artist tag, because we're gonna display it anyway" |
01:36:42 | kugel | do you think generating a idx dependant on all your music files is a good idea? |
01:37:02 | Llorean | Displaying the sort tags basically makes the patch pointless, because it then has to display "Beatles, The" if it's to sort it as B, and removes the point of the patch entirely. |
01:37:04 | kugel | it's still displayed in the wps. It's only about the database browser |
01:37:14 | Llorean | kugel: Which is what people are complaining about... |
01:37:48 | Llorean | They want it to show "The Beetles" in the list, but have it listed in the B section. |
01:37:50 | kugel | the ram usage will baiscally double just for displaying "the"'s and "a"'s |
01:38:11 | Llorean | And the doubled RAM usage won't affect people who don't use the database. |
01:39:23 | Unhelpful | what if the sortartist index is only populated with files where it differs from the artist tag? |
01:40:31 | kugel | well, then you still need to check the sortartist idx file regulary. And that's even more complicated to implement |
01:41:10 | kugel | I mean, as long as you still need to read the separate file, then you can just put everything you need into it, imho |
01:41:19 | Llorean | Well, the sort artist patch doesn't actually solve the problem it's meant to solve unless the display issue is fixed. |
01:41:28 | Llorean | So it probably won't go in at all if some way isn't found, I suspect. |
01:41:42 | kugel | yea, I understand that |
01:42:02 | Llorean | And I don't think more RAM usage is a big deal for most people who use database. |
01:42:09 | Llorean | Since those people can save a lot of RAM just by not using it at all. |
01:42:33 | pixelma | well, you can discuss if that's a display issue. Thinking of a record shop... I often see "Beatles, The" there |
01:43:16 | kugel | pixelma: I wouldn't have a problem if it's displayed like that, especially since I made the tags like that, so it's at least not unexpected |
01:43:39 | | Quit MethoS- (Remote closed the connection) |
01:43:57 | Llorean | But the long historical tradition of feature requests it's meant to address are people who want to see "The Beatles" in the list, in the B section. |
01:45:17 | Unhelpful | ...what about offering separate displayas/sortby options? if you just set one, it sorts and displays from one index. if you set both, it has to load both files, and you get "The Beatles" in B |
01:45:55 | Llorean | Unhelpful: Most configuration of database behaviour is actually handled by the tagnavi.config file. |
01:46:47 | Llorean | I'm not sure complicating it with more options would simplify anything, since you'd still need to code for the most complex behaviour. |
01:47:06 | Llorean | So you still get "if they wish to use both tags, it takes more RAM" |
01:47:08 | pixelma | yeah, I know. My point was only that you can see it two ways. Btw. *I* would be surprised to see something starting with "T" between other "B"s, but then I'm not one who would use it - at least when it's about articles, maybe with names like "Elvis Presley" or so) |
01:47:13 | Llorean | And if they just wish to use one tag, there's no need for an option. |
01:47:42 | Unhelpful | and that's where the decision could be made. a generic displayas/sortby facility could also extend to the albumsort/albumartistsort tags just by putting those tags in the DB |
01:47:52 | PaulJam | Unhelpful: is it expected, that resizing doesn't seem to work when the filename of the bmp contains the dimensions (e.g. cover.75x75.bmp)? when i rename the bmp to cover.bmp it works like expected. |
01:48:19 | Llorean | Unhelpful: I think the decision could be 'made' by whether or not they included the tags in their files, rather than having them also have to adjust their tagnavi about it. |
01:48:19 | Unhelpful | PaulJam: are those dimensions the ones of the current WPS? |
01:48:31 | PaulJam | Unhelpful: no |
01:48:32 | Llorean | Unhelpful: I think it should be 'transparent', if they've included sort tags, they want to use them. |
01:48:46 | pixelma | ...then I'd expect it to be written Presley, Elvis"... ok, I'm not in that group at all |
01:48:56 | | Part toffe82 |
01:49:29 | Unhelpful | pixelma: just so it's not done how the karma did "library sort", and put "Die Happy!" under H |
01:49:33 | Llorean | PaulJam: How would it know to look for cover.75x75.bmp if the WPS doesn't specify 75x75 cover art? It still has the exact same old search pattern. |
01:50:23 | Unhelpful | exactly, the search is for <name>.<wpsAAdimensions>.bmp and then <name>.bmp |
01:50:31 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
01:50:46 | PaulJam | Llorean: true, maybe this should be mentioned on the wiki (if it isn't already) |
01:51:02 | Unhelpful | it can't reasonably search for each variation that might exist without loading the whole directory and pattern-matching the filenames |
01:51:04 | Llorean | PaulJam: Are we supposed to post somewhere "Yeah, the information already up is still correct" or what? |
01:51:16 | kugel | maybe Slasheri pops up sometime, I think he can estimate best how much rewrite and stuff tagcache needs to support such a feature |
01:52:04 | Unhelpful | pixelma: you wouldn't have a link to a 100x100 AA WPS for m5, would you? |
01:52:36 | kugel | I found the part where it sorts, and it sorts exactly the same variable which it displays, i.e. the result of the tagcache search |
01:53:27 | pixelma | Unhelpful: well in that case the file would have no sorting tag at all. What I mean is just the use of the sorting tag for displaying in the list. |
01:53:34 | kugel | and the sorting function cannot take more arguments (iiuc), so there's no way to tell it to sort artist or sortartist based on whatever condition |
01:53:52 | Unhelpful | ... it's horribly broken even w/ 50x50 file and cabbiev2 :/ |
01:54:33 | pixelma | cabbiev2 uses 64x64 as AA size on those displays, just looked |
01:54:39 | JdGordon | the sort comparer can use a global, or global_status to do it |
01:54:46 | JdGordon | like the comparer for the file tree |
01:55:01 | kugel | ah yea, those globals, right :) |
01:55:12 | Unhelpful | pixelma: right, it looks like upscaling 50x50->64x64 corrupts the image :/ |
01:55:52 | Unhelpful | 32x32 -> 64x64 gets the same load error as you had, with it reading past EOF :D |
01:56:05 | | Join XxJoshXx [0] (n=cf458923@gateway/web/cgi-irc/labb.contactor.se/x-a10461150afe06f0) |
01:56:43 | kugel | but it basically needs the search functions, the display functions, the sort functions, the parse functions and more to be (partly) rewritten |
01:56:45 | pixelma | ok, so I don't need to put my WPS up somewhere... good as it's still work in progress |
01:57:20 | kugel | sounds like fun |
01:57:32 | | Join darknessxsurroun [0] (n=04f4b7bd@gateway/web/cgi-irc/labb.contactor.se/x-351d3c64c0dd6c1b) |
01:57:34 | JdGordon | :D |
01:57:49 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
01:57:54 | darknessxsurroun | hello. |
01:57:56 | Llorean | kugel: Probably why there's not a patch for it that's under any discussion for commit yet. :) |
01:58:06 | Llorean | It's one of those 'big' projects. |
01:58:10 | Unhelpful | pixelma: no, you don't. there seems to be some goof it scale_nearest for at least 2^N exact multiples, and possibly for others - i'll look for an M5 WPS that's not a 2^N size and see if i can break that. |
01:58:12 | JdGordon | kugel: or rework database internally so it needs less work for this... |
01:59:12 | darknessxsurroun | i need some help with replacing the firmware on the Philips GoGear Audio MP3 Player (SA30XX) is there a program availble besides the one from the main website(Philips.com) |
01:59:48 | kugel | I fail to see where it needs rework (apart from this sorting tag thing), besides that the code is a bit complex, it performs fast and relatively reliable (at least for me, I've heard of some weird bugs) |
01:59:48 | Llorean | darknessxsurroun: This doesn't really sound like a Rockbox question. |
01:59:49 | Llorean | What are you trying to do, exactly? |
02:00 |
02:00:14 | darknessxsurroun | well i want to replace the firmware with a rockbox made one |
02:00:25 | darknessxsurroun | sorry if i'm not explaining right |
02:00:38 | * | kugel didn't know SA30XX is a supported target :o |
02:00:58 | darknessxsurroun | its not supported? |
02:01:02 | kugel | oh, it isn't |
02:01:07 | | Quit XxJoshXx ("CGI:IRC (Ping timeout)") |
02:01:09 | Llorean | darknessxsurroun: The list of supported players is on the front page. |
02:01:16 | kugel | darknessxsurroun: No, the front page clearly tells which targets are supported |
02:01:34 | Unhelpful | darknessxsurroun: if there's nothing on the website or forums about the player, chances are there is no rockbox for it. and if it's not on the front page, but you see it somewhere else, it's probably not very *well* supported. |
02:01:56 | Llorean | There has been some work on the SA31XX GoGears, I believe, but it's all fairly early development work, and mostly just sitting around for some time. |
02:02:16 | darknessxsurroun | oh, cause the default firmware for the mp3 player is dead slow, and i was looking for a replacement |
02:03:02 | darknessxsurroun | by means. the browsing is slow on the mp3> searching or scrolling for songs is slow.... |
02:03:18 | Unhelpful | you're going to need a different player if you want to use rockbox. the e200-series players are pretty cheap on froobi.com, most of the time. |
02:03:39 | darknessxsurroun | hm... alright thanks. |
02:06:07 | | Quit darknessxsurroun ("CGI:IRC (EOF)") |
02:07:35 | | Quit lasser (Read error: 110 (Connection timed out)) |
02:07:45 | PaulJam | Unhelpful: one last question: are there any restrictions on the size of the cover.bmp? |
02:11:02 | Unhelpful | PaulJam: can't scale up from smaller than 2x2, or down to smaller than 2x2. scaling up to, or down from, a size with more than 16843009 pixels (4104x4104, if square) will silently corrupt the scaled output. i'm adding tests to catch the limits at both ends, and fail the load, but i don't expect them to be hit too often |
02:11:39 | PaulJam | thanks |
02:12:04 | Unhelpful | a 24-bit bitmap file in the max size is about 50MB, i don't think many people will have one |
02:15:07 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
02:32:10 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
02:33:11 | | Quit massiveH ("Leaving") |
02:36:43 | *** | Saving seen data "./dancer.seen" |
02:46:09 | | Quit _lifeless (Remote closed the connection) |
02:54:02 | | Quit HellDragon (Remote closed the connection) |
02:55:38 | | Join HellDragon [0] (n=jd@modemcable100.136-203-24.mc.videotron.ca) |
02:55:58 | | Quit ajonat (Read error: 54 (Connection reset by peer)) |
02:56:41 | | Join ajonat [0] (n=ajonat@190.48.114.25) |
02:57:34 | | Join perrikwp|lab [0] (i=98214d2a@gateway/web/ajax/mibbit.com/x-2a3b55315427b43a) |
03:00 |
03:04:21 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
03:09:57 | | Quit jhulst (Read error: 110 (Connection timed out)) |
03:10:18 | | Quit avacore (Read error: 110 (Connection timed out)) |
03:10:48 | | Quit ajonat () |
03:15:14 | | Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
03:15:23 | | Join CaptainKewl [0] (n=jason@207-237-173-165.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
03:18:13 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
03:19:31 | | Quit martian67 ("gone") |
03:20:20 | | Quit XavierGr (Read error: 54 (Connection reset by peer)) |
03:21:24 | | Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) |
03:24:58 | Unhelpful | greyscale upscaling was broken, should i push the fix, or open an FS task first? also, should i push the other minor enhancements in my tree with it, or only the thing that actually fixes a bug? |
03:27:06 | JdGordon | one change at a time... |
03:27:09 | JdGordon | but yeah push the fix |
03:40:35 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
03:41:15 | | Join hillshum [0] (n=hillshum@75-165-241-220.slkc.qwest.net) |
03:44:35 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
03:46:24 | | Quit advcomp2019 (Nick collision from services.) |
03:46:25 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
04:00 |
04:12:15 | | Join blkhawk- [0] (n=blkhawk@f051070231.adsl.alicedsl.de) |
04:13:13 | | Quit Acky (Read error: 104 (Connection reset by peer)) |
04:17:47 | | Join Acksaw [0] (n=omgwtfbb@cpc2-stok5-0-0-cust754.bagu.cable.ntl.com) |
04:24:07 | | Quit parafin (niven.freenode.net irc.freenode.net) |
04:24:07 | NSplit | niven.freenode.net irc.freenode.net |
04:24:07 | | Quit tvelocity (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit shodanX (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit preglow (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit killan (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit DaCapn (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit Zambezi (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit FOAD (niven.freenode.net irc.freenode.net) |
04:24:07 | | Quit tim__b (niven.freenode.net irc.freenode.net) |
04:25:18 | | Nick Bensawsome is now known as NinJew (n=Bensawso@unaffiliated/bensawsome) |
04:25:46 | NHeal | niven.freenode.net irc.freenode.net |
04:25:46 | NJoin | killan [0] (n=nnscript@c-415472d5.06-397-67626721.cust.bredbandsbolaget.se) |
04:25:46 | NJoin | tvelocity [0] (n=tony@adsl4-37.her.forthnet.gr) |
04:25:46 | NJoin | parafin [0] (i=parafin@paraf.in) |
04:25:46 | NJoin | FOAD [0] (n=dok@dinah.blub.net) |
04:25:46 | NJoin | preglow [0] (i=thomj@tvilling2.pvv.ntnu.no) |
04:25:46 | NJoin | DaCapn [0] (i=dacapn@using.your.wireless-inter.net) |
04:25:46 | NJoin | shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
04:25:46 | NJoin | Zambezi [0] (i=stolgfor@bnc.fran.dotbnc.se) |
04:25:46 | NJoin | tim__b [0] (i=tim__b@the-ascii-scene.doesntexist.org) |
04:29:44 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
04:30:14 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@f051070231.adsl.alicedsl.de) |
04:30:41 | | Join Kakashi666 [0] (n=james@i60-47-33-111.s02.a013.ap.plala.or.jp) |
04:30:52 | Kakashi666 | hey all |
04:32:04 | Kakashi666 | I'm having an issue with my Flyspray account, but Zagor is not online? |
04:33:15 | Kakashi666 | I guess I'll try him by email, noone seems to be awake |
04:33:19 | | Quit jfc (Read error: 54 (Connection reset by peer)) |
04:34:01 | | Join jfc [0] (n=john@dpc691978010.direcpc.com) |
04:34:37 | | Part Kakashi666 |
04:36:13 | | Quit perrikwp|lab ("http://www.mibbit.com ajax IRC Client") |
04:36:45 | *** | Saving seen data "./dancer.seen" |
04:41:58 | | Quit jfc (Read error: 54 (Connection reset by peer)) |
04:45:44 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
04:46:05 | | Nick NinJew is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome) |
04:50:09 | | Quit hillshum ("Leaving") |
05:00 |
05:00:32 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-09078a43cdbbd768) |
05:08:24 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
05:11:05 | | Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) |
05:21:51 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
05:22:00 | Unhelpful | re: FS #7253, i am unable to "break" the dircache with the procedure steve describes, although shutting down while the disk is active just after startup seems to take much longer than if the disk has stopped - possibly any dircache updates are waited for on shutdown, now? it's also pretty old, filed 2007/06 and last updated 2008/03. |
05:23:29 | Llorean | Maybe leave a comment on it that you can't reproduce. |
05:24:42 | Unhelpful | seems sensible. i'm wondering if the bug has been "fixed" by some other random work since then... a lot changes in a year. |
05:26:51 | Unhelpful | maybe bug some H3x0 users to try to reproduce, but it seems unlikely this would be target-specific |
05:28:16 | Llorean | Well, pondlife is still around from time to time. I imagine a comment on that is likely to get a response, and I don't think it's too harmful to let it sit a bit longer. |
05:28:37 | Llorean | Not that there's likely any harm closing it either, with a reason "Seems to be fixed, file again if this is incorrect" or something |
05:34:16 | | Join Darksair [0] (n=user@58.192.35.250) |
05:36:16 | | Quit FOAD (Read error: 110 (Connection timed out)) |
05:36:16 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
05:37:12 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
05:39:52 | | Quit Horscht ("Snak 5.3.3 Unregistered copy. Evaluation period is over. Program will now quit. Thanks for using Snak.") |
05:52:49 | Unhelpful | how hard would it be to get a binary for a particular target and revision built on a particular buildserver? i'm kind of curious as to whether objdiff.py might help determine what causes the server-to-server binsize fluctuations that seem to have come in with resize-on-load. |
05:53:16 | Unhelpful | also, best place to put a possibly useful tool? ;) |
05:55:17 | | Join pixelma_ [0] (n=pixelma@rockbox/staff/pixelma) |
05:56:10 | | Quit amiconn (Read error: 110 (Connection timed out)) |
05:56:22 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
05:56:35 | | Quit massiveH ("Leaving") |
05:57:22 | | Quit pixelma (Read error: 110 (Connection timed out)) |
06:00 |
06:04:13 | | Quit Aurix_Lexico (Read error: 110 (Connection timed out)) |
06:04:52 | JdGordon | Unhelpful: you need to speak to Bagder about that... |
06:17:41 | | Quit HBK (Read error: 60 (Operation timed out)) |
06:19:32 | | Quit obo (Read error: 110 (Connection timed out)) |
06:20:56 | | Join Darksair` [0] (n=user@58.192.38.174) |
06:29:29 | | Join toffe82 [0] (n=chatzill@99.146.80.191) |
06:36:46 | *** | Saving seen data "./dancer.seen" |
06:37:01 | | Join HBK [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) |
06:40:19 | | Quit Darksair (Connection timed out) |
06:49:31 | | Quit daurnimator ("Cyas later...") |
06:49:56 | toffe82 | I still have a problem with the install on an ipod 5.5 80 gb with a samsung hd |
06:51:09 | toffe82 | it is 4k per sector, ipodpatche say it is a 2048 per sector, Lamdacalculus37 made me a version with the ata driver modified but it doesn't work |
06:51:50 | toffe82 | I still have the same error, panic error sector 4096 or something like this |
06:51:57 | toffe82 | anbody has an idea ? |
06:59:28 | | Join Darksair [0] (n=user@58.192.37.151) |
07:00 |
07:05:29 | | Join daurnimator [0] (n=daurn@ppp118-208-145-18.lns10.mel4.internode.on.net) |
07:06:46 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
07:08:03 | | Join Default_ [0] (n=chatzill@ool-457bfab5.dyn.optonline.net) |
07:08:11 | | Nick Default_ is now known as slact (n=chatzill@ool-457bfab5.dyn.optonline.net) |
07:08:14 | | Quit slact (Client Quit) |
07:08:27 | | Join slact [0] (n=chatzill@ool-457bfab5.dyn.optonline.net) |
07:08:44 | slact | hi Rockbox. I've an ipodish question. |
07:09:01 | slact | most of the time wheel response is kind of sluggish. |
07:09:24 | slact | ...except when music is currently playing. then it seems a lot more responsive |
07:09:29 | slact | (most of the time) |
07:10:06 | slact | this is for the latest svn build, but is the case for 3.0 as well several other builds that i've tried. i've got a 5.5G 80gb model |
07:10:29 | | Join daurn [0] (n=daurnima@unaffiliated/daurnimator) |
07:12:39 | Llorean | slact: This is normal behaviour. |
07:12:53 | slact | : ( |
07:13:03 | Llorean | The CPU is run pretty slow most of the time. When music is playing, it pops between the slow speed and the fast speed. When it's at the slow speed, the UI may be somewhat sluggish. |
07:13:14 | slact | ah |
07:13:25 | Llorean | This improves battery life quite a bit. |
07:13:52 | slact | i see. that explains why it unsluggishes during disk activity, too |
07:15:00 | slact | is the general screen refresh rate slow when the CPU is slowed down, or is it just because of the processing for the keypresses? |
07:15:29 | Llorean | Everything is slower, and the music has higher priority than the user interface. |
07:15:57 | | Quit Darksair` (Connection timed out) |
07:16:46 | slact | now you're making me want to go code-digging. |
07:17:19 | slact | ... 'cause now i naively think it might be a good idea to speed up the cpu when it detects keypresses |
07:17:36 | Llorean | There's a patch to do that in the tracker already, I think |
07:17:41 | Llorean | I couldn't tell you which task it is. |
07:17:49 | slact | i'll go have a look |
07:17:53 | | Quit reacocard ("AUGH") |
07:18:05 | | Join reacocard [0] (i=reacocar@saga.silenceisdefeat.org) |
07:18:34 | slact | http://www.rockbox.org/tracker/task/8142 |
07:18:41 | slact | is that it? 'cause that's nbot really what i'm talking about |
07:18:59 | Llorean | That's not a patch. |
07:19:19 | Unhelpful | this is the one: http://www.rockbox.org/tracker/task/8668 |
07:19:30 | Unhelpful | boost CPU for 1s after each button press |
07:19:46 | | Quit Darksair (Connection timed out) |
07:20:06 | slact | ah, http://www.rockbox.org/tracker/task/8668 |
07:20:19 | slact | thanks, unhelpful. |
07:20:44 | Unhelpful | it looks like it also reduces the "normal" speed that is used when not boosted |
07:21:13 | | Join Darksair [0] (n=user@58.192.41.143) |
07:21:52 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
07:22:02 | | Quit advcomp2019 (Nick collision from services.) |
07:22:06 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
07:23:01 | Unhelpful | it looks like there's some work to do on it, regarding limiting the boost to appropriate contexts - apparently many of the games and demos use cpu-speed-sensitive timing methods, or no timing at all, and are quite jerky with the popping in and out of boost every time a button is pressed. |
07:23:36 | slact | yep. |
07:24:12 | slact | guess i'll want to dig through the rockbox code after all |
07:25:04 | Unhelpful | i can't say how hard this job might be - it could very well be trivial. be sure to put up a new patch if you get anywhere with it. |
07:26:07 | slact | will do |
07:29:21 | | Join MethoS- [0] (n=clemens@host-091-097-243-027.ewe-ip-backbone.de) |
07:53:30 | | Quit BHSPitMonkey (Remote closed the connection) |
07:55:16 | | Join funman [0] (n=fun@rockbox/developer/funman) |
08:00 |
08:05:54 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
08:11:28 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
08:17:08 | | Join gromit`` [0] (n=gromit@ALagny-154-1-32-162.w83-112.abo.wanadoo.fr) |
08:19:27 | amiconn | gcc is weird |
08:20:23 | * | amiconn checked why ata.o pulls __ashrsi3 on SH1, even though there is no (obvious) variable right shift in ata.c |
08:21:59 | amiconn | It translates a check in set_features(): if (identify_info[features[i].id_word] & (1 << features[i].id_bit)) becomes if ((identify_info[features[i].id_word] >> features[i].id_bit) & 1) |
08:22:41 | amiconn | I don't understand why it uses an arithmetic shift though. identify_info is an array of unsigned short. |
08:23:50 | | Quit Seed ("cu, Andre") |
08:24:12 | Unhelpful | that's bizarre. you want to get that binsize gain on recorder down to ondio's size, eh? ;) |
08:24:15 | * | amiconn tries sth |
08:24:25 | amiconn | yep :) |
08:24:33 | * | funman gives a try at -Os |
08:24:36 | | Quit BigBambi (Read error: 113 (No route to host)) |
08:24:57 | Unhelpful | i saved my quick python hack into a file with prettified output. haven't decided where to put it yet, but it seemed possibly useful. |
08:24:58 | | Quit daurn (Read error: 113 (No route to host)) |
08:25:40 | | Join daurn [0] (n=daurnima@unaffiliated/daurnimator) |
08:27:21 | | Quit gromit` (Read error: 110 (Connection timed out)) |
08:28:04 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
08:30:46 | amiconn | Unhelpful: Using an unsigned '1' (1u) makes gcc switch to __lsrshi3 (logical right shift by n) |
08:31:10 | funman | ~30kB saved on binsize, same on RAM usage |
08:31:41 | Unhelpful | amiconn: but, bitwise operations are sign-agnostic? :/ |
08:31:50 | toffe82 | amiconn: it works with the first change |
08:32:52 | amiconn | toffe82: Try the other method anyway, if it works it's better (drive firmware will then handle partial sectors instead of rockbox) |
08:34:19 | amiconn | If it does work, we need to think about detecting this capability. Afaik the ata standard says nothing about it - we either need to probe, or check for specific disk models... |
08:34:44 | amiconn | Unhelpful: Shifts are not. |
08:34:45 | | Join Rob2222 [0] (n=Miranda@p4FDCD0D8.dip.t-dialin.net) |
08:36:02 | amiconn | Looks like gcc wants to play safe here. It wouldn't need to since for left shifts, logical == arithmetical, so it could just use a logical right shift even if the '1 |
08:36:09 | amiconn | ' for testing is signed. |
08:36:49 | *** | Saving seen data "./dancer.seen" |
08:37:00 | Unhelpful | that's very odd. but now we know :D |
08:37:35 | * | amiconn will try this build un his recorder just to make sure, then commit this tiny change |
08:37:46 | amiconn | It's just 1 ==> 1u |
08:39:33 | toffe82 | amiconn: it is working |
08:40:23 | amiconn | yay |
08:40:49 | Unhelpful | still best to test. now one of us just needs to figure out how to get the rest of it back, preferably without forking much of the bmp reader code. |
08:41:09 | amiconn | Should be a little faster for small sectors. If you have the time, run test_disk with both core variants |
08:42:04 | amiconn | (@ toffe82) |
08:42:49 | toffe82 | :) |
08:44:22 | Unhelpful | i got it down by 80B or so, to get it to where it is now, by making read_part_line on mono read whole lines, and bmp_read_fd call it unconditionally once per line. i'm guessing a good chunk of the change that's left is due to packing various bits of data into a struct, and calling the function that unpacks it? |
08:46:20 | toffe82 | amiconn: where is test_disk ? |
08:46:40 | GodEater | toffe82: it's another thing you'll have to enable in the build manually |
08:46:53 | toffe82 | :) |
08:47:01 | | Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-db5b0e910c71c4f0) |
08:47:13 | toffe82 | I will do it another day , time to sleep |
08:47:23 | toffe82 | thank you |
08:47:42 | * | GodEater must get round to looking at how that's done with the new makefile |
08:48:09 | | Part toffe82 |
08:48:18 | funman | edit apps/plugins/SOURCES (like old Makefile I think) |
08:48:44 | GodEater | so it is ;) |
08:49:45 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
08:50:15 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:50:31 | funman | hum with a -Os build some buttons seem to not respond .. |
08:52:06 | | Join Bagderr- [0] (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-178edeb9d183a42a) |
08:52:50 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
08:54:57 | amiconn | Hmm, the Player seems to use __ashrsi3 somewhere else as well |
08:56:23 | | Quit bertrik ("Leaving") |
08:57:20 | funman | I wonder why playback.c define target specific CODEC_IRAM_(ORIGIN,SIZE) and doesn't use them .. |
08:58:18 | funman | I see no include following the definition, so I think they should just go away, but I prefer to ask |
08:58:23 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
09:00 |
09:00:11 | Unhelpful | amiconn: odd, that's the only place outside of plugins i remember seeing it.. :/ |
09:01:35 | funman | just seem a leftover, amiconn could you check that i'm not misforgetting something here? |
09:03:37 | | Join pondlife [50] (n=Steve@rockbox/developer/pondlife) |
09:05:02 | Unhelpful | rechecked, i still only see it in firmware/drivers/ata.o :/ |
09:05:12 | pondlife | For the logs: Could amiconn's neat "1u << x" trick be used in elsewhere - dsp.c, eq.c and replaygain.c do a few "1 << x"s. |
09:05:23 | | Nick Bagderr- is now known as B4gder (n=daniel@gateway/web/cgi-irc/labb.contactor.se/x-178edeb9d183a42a) |
09:05:54 | pondlife | Or would that hit performance? |
09:05:57 | funman | pondlife: I understand that the right shift when using "& (1 << x)" |
09:06:25 | funman | i.e. it transforms to "( .. >> x) & 1" |
09:07:10 | pondlife | All aimconn did was specify that 1 was unsigned |
09:07:21 | pondlife | http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/ata.c?r1=19398;r2=19399;pathrev=19399 |
09:07:53 | pondlife | Saved quite some SH1 binsize |
09:07:59 | Unhelpful | which converts an arithmetic right shift to a logical on, in gcc's transformed version of the expression. |
09:08:03 | | Join petur [50] (n=petur@rockbox/developer/petur) |
09:08:26 | funman | because SH1 has no right shift so it uses a gcc function instead, i think other targets do have right shift? |
09:08:27 | pondlife | Of course it might (a) not help other architectures or (b) hurt performance in the general case... |
09:08:28 | amiconn | pondlife: On coldfire and arm it doesn't matter at all |
09:08:41 | pondlife | OK, that was the answer I was after |
09:09:01 | amiconn | SH1 has no variable shift instructions, only fixed ones, so variable shifts are subroutines on it |
09:09:44 | amiconn | But even with those subroutines, logical shifts are a little better, because the subroutines for variable logical shifts are faster |
09:10:35 | Unhelpful | i wasn't looking for common symbols of the same size - i'm assuming there's a logical shift right routine that's probably already used in many places? |
09:10:49 | amiconn | This is because logical shifts by 1, 2, 8 and 16 are available, while arithmetic right shift is only availabe by 1 (and you can do by-16 using 2 instructions, and by-24 using 3 insns) |
09:11:24 | amiconn | Yes there is - __lshrsi3 |
09:11:45 | | Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) |
09:12:01 | pixelma | Unhelpful: thanks for the fix, will have to try it out. And then find out if scrolling in conditional viewports is still broken and since when (must be something from last week too) |
09:12:33 | pixelma | well or already fixed |
09:13:08 | Unhelpful | pixelma: no problem, but i'm not really sure how i missed it before - i'm certain some of the test images i used in sliding_puzzle were smaller than display size |
09:13:19 | amiconn | Unhelpful: You probably didn't touch the Player, as it's charcell - no bmp scaler necessary :) |
09:13:46 | | Join Darksair` [0] (n=user@58.192.37.210) |
09:14:09 | Unhelpful | amiconn: it doesn't build the loader, or have album art, so i'm pretty sure anything i touched is ifdef'd out |
09:14:11 | amiconn | I'll check the .map and dig down the place(s) where it's used. It's a small optimisation, but still a good thing to do imho |
09:14:45 | Unhelpful | yay, macro-ized version of at least GET_FB_WIDTH works |
09:15:57 | | Quit Darksair (Connection timed out) |
09:17:03 | amiconn | funman: Btw, while I think this optimisation (using a right shift for preparing the test) is quite clever, gcc goof directly after that on SH1: |
09:18:56 | amiconn | It uses and #1, r0; tst r0, r0 instead of reducing that to tst #1, r0 |
09:19:06 | pixelma | Unhelpful: ah works... and scrolling works again too :) |
09:19:17 | Unhelpful | pixelma: i doubt i fixed *that* |
09:20:09 | amiconn | ('tst' is just an 'and' that sets the flag instead of storing the result. Normal alu instructions don't touch the flag on SH) |
09:22:19 | pixelma | Unhelpful: and doesn't look too bad. Well it was in the same WPS maybe something got "confused" when scaling didn't work as I noticed it falls back to displaying viewports for the non-AA case even when AA was present but couldn't be displayed) who knows |
09:24:22 | Unhelpful | i only tested with "extreme" upscaling, which makes it very obvious that it's working, because, HUGE GREY BLOCKS. :D |
09:25:11 | pixelma | rockblocks? |
09:25:19 | * | pixelma runs away |
09:27:22 | funman | Zagor: with SVN I see playback starts and hangs immediately on the Clip; by looking at the buffering thread debug screen. I'll try without tagcache since it let you play at least (sometimes) |
09:27:35 | Unhelpful | i also found out that i needed to special-case scaling up by exactly one pixel, and i believe we got a free binsize reduction on greyscale targets, as well. |
09:27:39 | funman | I noticed the audiobuffer is a bit below 1MB with tagcache enabled |
09:28:00 | Zagor | funman: are you still using the direct-from-flash patch? |
09:28:14 | Zagor | ah, "with SVN". |
09:28:36 | | Quit JdGordon (Remote closed the connection) |
09:28:44 | funman | no, I'm not using it because I want to reproduce problems, not avoid them ;o) |
09:29:04 | kugel | funman: that's exactly the issue I got on my fuze as well (using that startscreen+.playlist_control+nvram.bin trick), which has a planty more ram |
09:29:12 | Unhelpful | um, does the new build system even work on git that's not git-svn? i seem to recall that it calls git-svn info to get the svn revision... |
09:29:43 | funman | kugel: and did disabling tagcache help ? what's the size of audiobuffer ? (look in rockbox.map) |
09:30:11 | funman | Unhelpful: how can you get the svn revision on 'git that's not git-svn' ? |
09:31:12 | Unhelpful | funman: no clue how, since git doesn't do keyword subs, either... |
09:32:11 | funman | then it will work but report revision0 (like on a modified git tree) |
09:32:22 | kugel | funman: with svn (only my lcd fixes applied) audiobuf is 0x54DFCC (5 562316) |
09:32:41 | funman | perhaps the trick should be to use git log and grep magic as well to get the rev |
09:32:48 | funman | kugel: hm can you paste your map? |
09:33:13 | Unhelpful | hrm, the cloned git log *should* have the svn revs in the commits, right? |
09:33:37 | * | kugel thought funman doesn't read so hugh files |
09:33:49 | kugel | http://pastebin.ca/1283402 |
09:34:03 | kugel | huge* |
09:34:15 | funman | Unhelpful: yes it has, but it's just a bit harder to extract than using git svn info |
09:34:43 | funman | Zagor: disabling tagcache highers filebuflen from ~28k to ~256k and indeed there is working playback |
09:35:09 | Zagor | yup |
09:35:37 | funman | now I check the buffering thread stats and wait for a crash ! :) |
09:36:00 | Zagor | Unhelpful: git-svn-id: svn://svn.rockbox.org/rockbox/trunk@19399 |
09:36:39 | Llorean | funman: For me, I never had tagcache enabled in the first place, and didn't have working playback. |
09:36:41 | Zagor | that's what git log says on the server at least |
09:36:45 | Unhelpful | would git log + grep be faster or slow in general than using git-svn, i wonder? |
09:37:08 | funman | Unhelpful: also you (do you plan to fix it ?) should check if rev from git svn info and the rev from git log to see if the revision has been modified (and append a M to the revision) |
09:37:20 | funman | Llorean: did you check audiobuffer and filebuffer sizes? |
09:37:27 | funman | Unhelpful: not important ;) |
09:38:12 | Unhelpful | funman: that'll be tricky, if we don't import some form of .gitignore info into the actual svn repo... :/ |
09:38:21 | Unhelpful | also, i volunteered? ;) |
09:38:32 | Llorean | funman: What values do you refer to, on what screen? Do you mean the PCM and compressed buffers? |
09:39:21 | funman | Unhelpful: i can do that if you want |
09:39:58 | funman | Llorean: buffering thread debug screen to check filebuf, and rockbox.map to check audiobuffer (it seems that playback doesn't start if it's below 1MB) |
09:40:46 | Llorean | funman: There's not a value on that screen called "filebuff" |
09:41:07 | funman | Llorean: alloc and usefl |
09:41:30 | kugel | funman: well, what could be the reason the issue is also apparent on fuze? |
09:41:44 | funman | i had to edit debug_menu.c to make the values fit on screen |
09:41:46 | Llorean | funman: I can't see those values. They're off the right side of the screen. Remember, I mentioned they started with 29 earlier? |
09:41:48 | funman | kugel: no clue |
09:42:00 | Zagor | filebuflen is 284KB for me and playback works |
09:42:01 | Unhelpful | funman: i'll take a look, but i need get my current work commitable and switch to another branch first. |
09:42:06 | Zagor | well, starts |
09:42:14 | funman | Llorean: the important is how many digits they have :/ it could be 29k or 290k |
09:42:54 | Zagor | funman: well you see that from the left-side value. if that has six digits, so does the right-side |
09:42:57 | funman | Llorean: i removed the 08 from the format specifier, and used 4/5 chars for the description |
09:43:55 | funman | Zagor: do you have change directory enabled? |
09:44:09 | Zagor | when playback works, filebufused() and useful_data both hover around 240-280 KB. when it fails, it goes much much lower. 67KB now. |
09:44:45 | Zagor | funman: no |
09:44:47 | funman | like, instantly ? or does fail after having dropped until ~67k? |
09:45:10 | Zagor | "instantly". I can't tell which happens first. |
09:45:34 | Llorean | funman: Well, if Zagor's right, it's four digits. so 29XX |
09:45:36 | funman | I see arough 10kB per second decrease |
09:45:56 | funman | Llorean: definitely too low, I hadn't playback working with 29kb |
09:46:06 | Llorean | 2.9KB rather? |
09:46:11 | funman | no |
09:46:27 | Unhelpful | i think it might take an svnversion.pl... unless grep or sed has a first-match-only option that i'm not remember? |
09:46:41 | funman | Unhelpful: cut? |
09:46:51 | Llorean | funman: I'm confused. The value is not in Bytes? |
09:47:06 | Zagor | a strange thing is that usefl: varies with codec. the wav file shows values in a large range (50-280K) while mp3 is always >240KB |
09:47:14 | funman | Llorean: yes; i meant I had 29kb in my build and no playback, so your 2.9kb is definitely too low |
09:47:22 | | Quit jhulst (Remote closed the connection) |
09:47:32 | amiconn | Zagor: Different watermarks, I'd guess |
09:47:35 | Unhelpful | funman: no, no, i think head is the thing... and when it gets its one line and closes stdin, it should stop grep and git-log |
09:48:08 | Zagor | amiconn: could be. but why does mp3 use such a high watermark? |
09:48:18 | * | amiconn thinks that watermark handling in swcodec playback needs a thorough makeover |
09:48:29 | funman | grep -o only keeps the matching regex |
09:48:46 | amiconn | It's a thing I am complaining about almost since the beginning of swcodec playback... |
09:48:52 | Llorean | funman: Why would mine be so low with a clean SVN build and default settings? |
09:48:55 | Zagor | now mp3 changed, and decresed 16KB/sec as expected |
09:49:10 | Zagor | lots of funny symptoms... |
09:49:10 | Llorean | Or better yet, what file is that screen in, so I can fix formatting and get the values displayed, to be sure? |
09:49:10 | funman | Llorean: I have no clue, i only begin to read that code ^^ |
09:49:19 | funman | debug_menu.c |
09:49:27 | Llorean | Since it's not even filling completely |
09:49:39 | Llorean | Neither the PCM buffer nor the compressed buffers fill. |
09:49:53 | Llorean | funman: Also, for audiobuff, to I just subtract audiobuff_end from audiobuff in the map and give you that? |
09:50:15 | funman | hum playback stopped itself (but status remains on pause) and I see: pcm buffer empty, alloc/usefl buffer nearly full, track count 0, handle count 1 |
09:50:30 | kugel | Llorean: yes |
09:50:35 | funman | Llorean: yep, just to check if >1MB gives playback while <1 doesn't |
09:51:19 | funman | kugel: i don't read so huge files, just grep the minimal info i need from it ;) |
09:51:27 | | Join Darksair [0] (n=user@58.192.37.210) |
09:51:49 | kugel | funman: what info you need? I told you the audiobuf size before |
09:51:53 | Unhelpful | got it: git log | sed -nre '/git-svn-id/ s|.*@([0-9]+) .*|\1|p' | head -n 1 |
09:52:06 | Zagor | what is data_rem? it shows a bit over 6MB here! |
09:52:09 | funman | kugel: yeah; and I read 500kB, no 5.5MB .. so i wanted to check what was wrong |
09:52:10 | Llorean | funman: 990,352 in dec |
09:52:18 | funman | Zagor: data remaining to read in the file |
09:52:24 | Zagor | ah |
09:52:26 | kugel | funman: no, it's 5,5MB |
09:53:01 | funman | Llorean: what if you try to remove some code to get it over 1MB (reducing the plugin buffer for example, and ignoring plugins not building) ? |
09:53:06 | kugel | funman: 5 562316 (there's a space after the first 5, maybe the number got split at your screen) |
09:53:32 | funman | no it wasn't split but i overlooked the first 5, sorry for that |
09:53:35 | Unhelpful | it runs a tiny bit faster than git svn info here, too |
09:53:37 | | Quit kachna (Read error: 113 (No route to host)) |
09:54:06 | funman | Unhelpful: how does that work on osx (i mean without gnu sed) ? |
09:54:28 | Llorean | funman: Ah, it is 29k, not 2.9k on mine, btw. Just double checked |
09:54:35 | Unhelpful | that would be bsd sed? i don't know which options work with it... |
09:54:57 | funman | Llorean: and did you have disabled tagcache intentionally ? |
09:55:16 | funman | Unhelpful: mentioned in posix spec, i'll check that |
09:55:37 | funman | oops the spec is on the dead laptop, but there is freebsd manpages |
09:55:48 | | Quit Darksair (Client Quit) |
09:56:04 | | Quit Darksair` (Client Quit) |
09:56:18 | Llorean | funman: I never enabled it to begin with |
09:56:20 | Unhelpful | funman: found the mac os x sed man page online, it needs -E for the -r, otherwise we should be good. |
09:56:27 | funman | Unhelpful: uyup |
09:56:58 | funman | Llorean: it's enabled by default since r19382 |
09:57:34 | Unhelpful | i can't find this svnversion.sh, though, that the revlog says does the work |
09:57:34 | Zagor | pcm buffer seems a bit overkilled. it uses ~50 of its' 500 KB. |
09:57:45 | Unhelpful | nevermind, i was in my build dir :/ |
09:57:51 | funman | Unhelpful: in tools/ |
09:58:19 | Zagor | now I get a full mp3 playback, without skips |
09:58:31 | Zagor | how frustrating :-) |
09:58:41 | funman | Zagor: how ?! |
09:58:54 | Zagor | luck. I haven't changed anything. |
09:58:59 | funman | ah ;) |
09:59:05 | Llorean | funman: I thought you meant "enabled" as in "turned on", not "included" |
09:59:19 | Llorean | As I said before, an unmodified SVN build |
09:59:28 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
09:59:30 | funman | Llorean: sorry for the confusion |
09:59:42 | Llorean | I'm compiling one without a plugin buffer now. |
10:00 |
10:00:10 | Llorean | Or rather, a quite small one |
10:00:17 | Unhelpful | funman: if sed -r &>/dev/null ;, i guess? i don't have an osx around to test. |
10:00:21 | funman | not building tagcache is faster ;) |
10:01:00 | funman | Unhelpful: that's probably the right test (with a correct expression because gnu sed -r returns 4 here) |
10:01:11 | Unhelpful | echo | sed of course. |
10:01:38 | Llorean | funman: I'll do it that way then. |
10:01:52 | funman | just comment out HAVE_TAGCACHE in config-clip.h |
10:02:22 | Llorean | What is "audiobuff" then if it's not the PCM buffer and it's not the compressed audio buffer? |
10:02:26 | Unhelpful | does &> work in whatever shell osx uses? |
10:02:44 | Unhelpful | furthermore, is there a /dev/null? :/ |
10:02:50 | funman | Llorean: audiobuffer is used for voice, compressed audio, pcm, and probably more things |
10:03:10 | funman | it's just the RAM available which isn't used by rockbox, plugins, or codecs |
10:03:25 | amiconn | Ah, that reminds me |
10:03:29 | funman | Unhelpful: yes.. it's a bsd ;) |
10:03:42 | amiconn | On the lowmem swcodec targets, voice should probably be handled the same way as on archos |
10:04:19 | | Join mofux [0] (n=quassel@dslb-088-075-016-156.pools.arcor-ip.net) |
10:04:21 | Llorean | amiconn: Swap with playback rather than in parallel? |
10:04:29 | amiconn | I.e. instead of permanently reserving a chunk of audio buffer for voice, the voice file should use the main audio buffer, and be swapped out during playback |
10:04:59 | amiconn | This makes voice unavailable during playback, but might be the only way to make it work |
10:04:59 | funman | good idea |
10:05:36 | Llorean | funman: Alright, playback works (briefly) once I get enough memory free. |
10:05:52 | funman | Llorean: welcome in the club! |
10:06:09 | Llorean | Well, I'd already used it with the flash_buffering patch. |
10:06:33 | funman | i'd divided the pcm buffer size by 2, let's see what happens |
10:06:57 | Llorean | amiconn: Well, right now we could (presumably) just drop the largest few plugins and still have it do voice the old way, I think |
10:07:34 | funman | a quick crash, and I see the same values of filebuf_used and useful_data than when I had a 29kB filebuffer (alloc = 1832, usefl = 1224) |
10:07:39 | | Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) |
10:07:54 | funman | plugin buffer is 384kB I think |
10:08:02 | amiconn | Might work if you also switch to flash buffering, but then some nice-to-have plugins might be unable to run |
10:08:07 | Zagor | I get totally bogus data sometimes. looks like it gets overwritten. |
10:08:08 | Unhelpful | funman: works on linux, you want me to put it on FS? |
10:08:21 | amiconn | The jpeg viewer is rather smaller, but needs some buffer for the images |
10:08:25 | funman | Unhelpful: no, better let macosx people who do not want to use GNU fix it ;) |
10:08:26 | amiconn | *rather small |
10:08:52 | amiconn | So more free audio buffer is useful in many places |
10:08:54 | | Join lasser [0] (n=chatzill@Wbc14.w.pppool.de) |
10:09:16 | Llorean | I think I'd rather not have to stop playback for voice, than not having to stop it to view jpegs. |
10:09:22 | Zagor | where is the pcm buffer size defined? |
10:09:38 | funman | pcmbuf.c : pcmbuf_get_next_required_pcmbuf_size() |
10:09:39 | Llorean | Though actually, if it *always* just stopped playback for voice, that might be better all around. |
10:10:04 | Llorean | Save some memory on BigMem targets, resolve the complaint that "sometimes i can't hear the voice over the music" and fix the issue "I can't hear voice while music is paused" all in one go. |
10:10:12 | Unhelpful | i've got the test as described for the bsd-sed args, i just would want an actual OSX user to be sure it works... so FS might be the place |
10:11:02 | funman | Unhelpful: hum i think i have a shorter test |
10:11:29 | amiconn | Llorean: "fix" as in "make it the way it's intended to be"? |
10:11:36 | Unhelpful | ... we definitely want *something* like this, if you run git svn info on a non-svn git repo, it "fixes" it for you |
10:11:48 | funman | Unhelpful: oh |
10:11:51 | Unhelpful | mine's still not done fixing for a few minutes, now. :/ |
10:12:10 | funman | git log HEAD^..HEAD|tail -1|cut -d@ -f2|cut -d\ -f1 |
10:12:12 | Llorean | amiconn: You don't "fix" something that's working right. :) |
10:12:16 | funman | cross platform |
10:13:14 | amiconn | Llorean: Pausing != stopping. On archos, voice also doesn't work while paused (because the audio buffer is still occupied, it cannot laod voice) |
10:13:39 | Unhelpful | funman: erm, that only looks at the most-recent git rev, and if the most-recent git rev is not an svn rev, you get junk. |
10:13:54 | funman | Unhelpful: then origin^..origin ? |
10:13:55 | Llorean | amiconn: that seems odd. Why can't it flush, if it's going to have to rebuffer anyway? |
10:14:08 | amiconn | (and it actually pauses the MAS data transfer, allowing to continue from the exact same frame where it was paused) |
10:14:22 | funman | that assumes user use git pull −−rebase after svn rebase though |
10:14:24 | amiconn | It doesn't have to rebuffer after pause... |
10:14:35 | Llorean | It has to rebuffer after voice though, doesn't it? |
10:14:45 | amiconn | huh? |
10:14:51 | Llorean | I'm confused. |
10:14:57 | amiconn | It doesn't do voice when paused. Only when stopped. |
10:15:10 | funman | or using grep git-svn-id|head -1 : that solves the cross platform issue, perhaps at the cost of tiny cpu cycles (i don't think it's an issue) |
10:15:13 | Unhelpful | funman: that fails for my clone, at least. |
10:15:16 | Llorean | But when voice should be played, why does it "stop, voice, resume"? |
10:15:27 | Llorean | *doesn't it |
10:15:36 | amiconn | That'd be wasteful |
10:15:42 | funman | Unhelpful: git show origin doesn't show you a git-svn-id in the log? |
10:15:57 | amiconn | It would mean stop->load voice->talk->rebuffer->resume |
10:16:01 | Unhelpful | fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. |
10:16:13 | Llorean | amiconn: Which is necessary if you want to use voice anyway, you just have to do it by hand instead. |
10:16:29 | amiconn | Yes, hence it's better not to do it automatically |
10:16:39 | Unhelpful | i cloned this one from svn myself... maybe zagor's is not broken this way? :/ |
10:16:45 | Zagor | why are we using (NATIVE_FREQUENCY*4) in pcmbuf.c:434 ? last I checked we're not supporting 4-channel audio... |
10:17:06 | funman | hum .. what do you have in .git/refs/remotes ? |
10:17:07 | amiconn | Zagor: 2 channels * 2 bytes/sample ? |
10:17:16 | Zagor | also the "seconds += 2" ensures minimum 3 seconds, not 2 |
10:17:19 | Unhelpful | "git-svn" |
10:17:24 | LinusN | Zagor: could the 4 mean the 4 bytes per sample? |
10:17:35 | funman | Unhelpful: and after git pull −−rebase ? |
10:17:45 | amiconn | In fact I prefer the hwcodec behaviour of not doing voice during playback |
10:17:58 | Zagor | amiconn: that makes sense. but then why is it NATIVE_FREQUENCY*2 if MEM <= 1 ? |
10:18:21 | amiconn | I have no idea |
10:18:22 | Unhelpful | fatal: 'origin': unable to chdir or not a git archive |
10:18:23 | Unhelpful | fatal: The remote end hung up unexpectedly |
10:18:39 | Unhelpful | i pull from svn |
10:18:50 | funman | using the instructions on the wiki ? |
10:19:13 | funman | git update-ref refs/remotes/git-svn origin/master |
10:19:23 | Zagor | is sansa m200 working? it's the only target with MEM<2. |
10:19:38 | Zagor | (well, ifp too but I know that isn't working) |
10:19:59 | Unhelpful | that fails for me, too :D |
10:20:02 | | Quit axionix_ (Read error: 110 (Connection timed out)) |
10:20:19 | Unhelpful | at some point, i need to pull from the "official" git mirror, and see if things work any better. |
10:20:23 | * | Zagor regrets not bringing the usb cable to work today |
10:20:29 | funman | Unhelpful: i'm not sure but i think origin ref should be defined |
10:21:38 | funman | Unhelpful: could you paste your .git/config please? |
10:22:44 | funman | Zagor: see r12843 |
10:23:31 | Unhelpful | funman: lemme make a fresh clone really quick, of the last few revs, and see if something's not clearly broken... |
10:24:06 | Zagor | funman: yeah I saw that. doesn't really explain the strange code though. |
10:24:21 | funman | nope but at least points to its author ;) |
10:24:26 | Zagor | :) |
10:26:48 | funman | hum i just saw a drop into used buffer |
10:27:06 | funman | i mean very high drop at the moment of the crash, like you told me |
10:27:24 | funman | it displays BUF_USED in buffering.c |
10:27:35 | Zagor | changing pcm buffer to the specified 2 seconds instead of 3 would free up 172KB ram |
10:27:48 | funman | which uses scary macros |
10:27:48 | Zagor | and I question why we need 2 seconds pcm buffer on flash targets |
10:27:57 | funman | for effects? |
10:28:16 | Zagor | crossfade is added on top of those 3 seconds |
10:28:35 | funman | like fade on pause? |
10:28:52 | Zagor | that doesn't affect the pcm buffer |
10:28:54 | Llorean | With the flash_buffer patch at least, the PCM buffer almost never even drops below about 4/5 full from the look of it. |
10:29:15 | Unhelpful | still going :/ |
10:29:16 | | Quit Thundercloud (Read error: 54 (Connection reset by peer)) |
10:29:20 | Llorean | I don't know how it does with the normal buffering code, since I get a data abort after a few seconds. |
10:29:28 | Zagor | Llorean: exactly. I'm guessing the 2 seconds are to allow disks to spin up. |
10:29:33 | funman | Llorean: looks normal |
10:29:54 | Unhelpful | and my config has no origin ref in it |
10:29:55 | funman | i'm more interested by the file buffer |
10:30:05 | Llorean | Zagor: Even that *could* be handled in the compressed buffer instead of the PCM buffer. |
10:30:09 | funman | Unhelpful: does it have any remote ? |
10:30:16 | Llorean | It would make more sense since 2 seconds of compressed audio is a lot smaller, most of the time. |
10:30:17 | Zagor | Llorean: crossfade? |
10:30:23 | funman | excepting the svn-remote |
10:30:30 | Unhelpful | nope! :D |
10:30:32 | amiconn | The pcm buffer needs to be large enough to avoid too frequent boosting/unboosting |
10:30:40 | Llorean | Zagor: Possibly? Was just saying, disk spinup wouldn't need to depend on the PCM in my mind. :) |
10:31:02 | amiconn | On targets where we don't do that yet, it could very well be < 1 second |
10:31:09 | Zagor | Llorean: ah, you're right. pcm shouldn't have anything to do with spinup. |
10:31:16 | Unhelpful | it looks like you get none of that when you run git svn clone |
10:31:34 | Zagor | amiconn: is boost transition expensive? |
10:31:58 | amiconn | Yes, although it varies with SoC |
10:32:27 | amiconn | It's mainly the wait-for-pll-resync that costs time |
10:32:31 | Zagor | how expensive? bigger pcm also means smaller compressed buffer = more spinups/flash accesses |
10:32:39 | Unhelpful | a fresh git svn clone of the last few revs is exactly the same |
10:33:14 | amiconn | On coldfire, each transition also adds a bit of random timer uncertainty |
10:33:41 | Unhelpful | a git clone of the the git svn clone has a nice origin ref :/ |
10:33:42 | amiconn | (due to the timers being hooked to the core clock) |
10:33:45 | Unhelpful | remote rather |
10:34:04 | funman | Unhelpful: git remote add origin git://svn.rockbox.org/rockbox ? |
10:34:12 | Zagor | amiconn: yes, but what is a bit? are we talking microseconds or 100 milliseconds? |
10:34:33 | amiconn | Zagor: Up to 10 msec (typical 2 msec) on coldfire, and around 500 µsec on PP iirc |
10:34:39 | Zagor | ok. thanks. |
10:34:55 | funman | instant on as3525 :o) |
10:34:56 | | Quit Nibbler (Read error: 110 (Connection timed out)) |
10:35:02 | Zagor | funman: really? |
10:35:12 | Unhelpful | funman: that does 'er. :D |
10:35:12 | funman | the PLL setting doesn't change |
10:35:23 | Zagor | ah, only the divider? |
10:35:28 | funman | yep |
10:35:31 | Zagor | nice |
10:35:56 | Llorean | So we could do with a smaller PCM buffer there? |
10:36:13 | amiconn | We could do that too on PP (only changing a post divider), but not on coldfire |
10:36:15 | Zagor | we might want to do some stuff #if MEM < 8 or MEM==2 |
10:36:39 | Zagor | amiconn: why don't we already on pp? |
10:36:44 | funman | I was wondering if a global define LOWMEM would be useful |
10:36:50 | *** | Saving seen data "./dancer.seen" |
10:36:55 | amiconn | It would limit us to certain 'normal' frequencies, e.g. 1/3 of the max. |
10:37:02 | Zagor | right |
10:37:51 | Zagor | funman: nah, let's try not adding too many defines. |
10:37:56 | amiconn | Actually we could run the pll at a higher frequency, and divide even for the max. clock |
10:37:59 | Zagor | we already have a LOT |
10:38:39 | Zagor | amiconn: but coldfire must get pll change? |
10:38:43 | amiconn | On PP5022 the pll needs to be run at >=96 MHz anyway, so we wouldn't lose anything, but on PP5020 it doesn't, and if we run it higher, it might need more power |
10:39:31 | amiconn | Zagor: yes |
10:40:56 | amiconn | On PP we use 80 and 30MHz now. With simple post divider, normal clock could be either 40MHz, or 26.667MHz |
10:41:17 | Unhelpful | but it still doesn't make any of your suggested methods work for me... :/ |
10:41:30 | funman | Unhelpful: git show origin doesn't show anything? |
10:41:34 | Llorean | 40mhz would be nice for improved UI performance, though if the UI boost patch ever works, maybe 26.67 would work too. |
10:41:34 | amiconn | Starting from 160MHz (as we need to do anyway on 5022), we could also use e.g. 32MHz |
10:42:02 | Unhelpful | i think the only thing for it may be to clone from the official repo, and push −−mirror my work onto that |
10:42:04 | amiconn | Iirc the post divider is 1 <= divider <= 16 |
10:42:45 | Zagor | Llorean: surely the clip doesn't need a UI boost |
10:42:51 | funman | Unhelpful: if you name the svn remote "origin" does git svn still work ? |
10:43:06 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
10:43:11 | amiconn | Of course we can always use 24MHz, but then it makes sense to disable the pll in order to save power. Powering back up then implies resync again. |
10:43:13 | Llorean | Zagor: Yeah, but the 40 and 26.67 are for PP targets, which tend to sit on the edge of needing it, depending on screen size. |
10:43:32 | Zagor | yeah the pp targets are usually a bit more taxing |
10:43:42 | Llorean | Zagor: The Clip has probably got the best "amount of screen data" to "CPU speed" ratio we've got... |
10:43:49 | amiconn | Llorean: Actually I'd say it's just the Video. Color is fine afaics |
10:43:52 | Zagor | :-) |
10:44:15 | Llorean | amiconn: Yeah, but it's probably close enough that it'd need it if we dropped unboosted down a little further, right? |
10:44:29 | amiconn | perhaps |
10:44:45 | Llorean | Not that the patch is ready, anyway. |
10:45:00 | Zagor | anyway, since the ams targets use div boosting we have no reason to not shrink the pcm buffer |
10:45:50 | Zagor | not that it solves the immediate problems. but memory is rather scarce on these little critters. |
10:46:04 | Llorean | Zagor: Well, it might bring the audiobuffer back up to "large enough for playback" |
10:46:21 | Zagor | Llorean: yeah, without having to cut major features |
10:46:35 | funman | maybe even "resistant to crashes" |
10:46:38 | Llorean | Zagor: Where'd it defined, I'll test a build? |
10:46:54 | Zagor | going from 3 to 1 second pcm buffer will save 344 KB |
10:47:06 | Zagor | Llorean: apps/pcmbuf.c line 432 |
10:47:06 | funman | Unhelpful: how did you clone that tree, git svn clone ? I'll try to see what i can tweak |
10:47:22 | Zagor | simply remove "seconds += 2;" to get a 1-second buffer |
10:47:57 | funman | how a larger pcm buffer reduces the number of boosting needed, because boosting is needed by pcm playback? |
10:48:27 | Zagor | funman: boosting is needed by decoder. and decoder can only decode as much as can fit in the pcm buffer |
10:48:41 | Zagor | so small buffer = many small decodes. |
10:48:47 | Zagor | = many boosts |
10:49:26 | funman | ok |
10:49:46 | funman | -2.3MB of filebuffer used, that can't be right ! |
10:49:57 | Unhelpful | funman: yes, that's how the "broken" one got cloned... i'm still thinking maybe i should just mirror my branches onto a "proper" clone of the official git mirror. |
10:50:30 | Zagor | funman: yeah I get that sometimes too. I suspect overwriting. |
10:50:32 | funman | right, and we should remove the instructions to svn clone then |
10:50:52 | funman | Zagor: of buf_.idx , yes me too |
10:50:57 | Unhelpful | do we even have those? i just followed git-svn's instructions... :/ |
10:51:17 | funman | http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl |
10:51:33 | Unhelpful | i think there are more than a few things broken, anyway. pushing svn revs via git to a git-svn repo can very easily make git-svn too confused to be able to rebase :/ |
10:52:03 | | Part LinusN |
10:52:26 | funman | i would prefer a native git server too .. :o |
10:52:36 | Llorean | Zagor: Doesn't make playback work. My compressed buffers are much bigger now, but it still fails to play. I'll disable tagcache and see if it at least seems to work once the total audiobuff is big enough |
10:55:16 | | Join gregzx [0] (n=chatzill@dsg54.neoplus.adsl.tpnet.pl) |
10:55:24 | Unhelpful | well, it's good enough as a conduit to move revs out of svn and into git, and apparently if we all clone our git repos from a git-svn clone, ours will be fine |
10:56:43 | Llorean | Zagor: With the smaller PCM buffer playback seems to work well enough. It's unreliable, but I think it's just the usual unreliableness. |
10:57:27 | | Quit jhulst (Remote closed the connection) |
10:57:59 | Zagor | Llorean: did you ever try standard pcm buffer without tagcache? |
10:58:22 | Llorean | Zagor: Yeah, got data aborts after ~4 seconds of playback |
10:58:30 | Llorean | I'm not getting data aborts like this. |
10:58:35 | Zagor | yet :) |
10:58:38 | Llorean | Yet. |
10:58:43 | Llorean | I had a little difficulty getting playback to start |
10:58:55 | Llorean | I clicked on the file, got to the WPS, nothing happened, I paused then unpaused and it started. |
10:59:08 | funman | the reliable unreliableness |
10:59:13 | Llorean | It's been going for quite a bit so far, with me watching the audio buffer screen. It *might* make sense to change the low watermark for the PCM buffer now. |
10:59:30 | Zagor | I wonder if we have ever successfully ran swcodecs on a <8MB target |
11:00 |
11:00:05 | Llorean | Zagor: Someone declared an enormous plugin buffer on an iPod Nano once. |
11:00:16 | funman | with the in-progress buffering_flash.c i'd think yes |
11:00:17 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") |
11:00:20 | Llorean | So they, effectively, had a less than 8mb target I think |
11:00:33 | Zagor | there seems to be a lack of checks in the buffering/playback code |
11:00:34 | Llorean | funman: So far my music is still playing, and none of the audio glitches I get wit the buffer_flash patch. |
11:00:55 | funman | normal, because buffering.c use watermarks |
11:01:22 | Llorean | I do need to pause and unpause to start playback, which is strange. |
11:01:29 | Zagor | haha |
11:01:37 | Llorean | That's reproduceable like this, at least |
11:02:14 | Zagor | funman: how is the status of the sd driver? do we know why we get fifo full? |
11:02:21 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
11:02:28 | Zagor | or when |
11:02:44 | funman | Zagor: why, no, you might want to save the function params at each call and display them in the panic |
11:02:48 | Llorean | Hmm... |
11:02:50 | | Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) |
11:02:51 | funman | when, when buffering bugs |
11:02:56 | Llorean | The compressed audio buffer seems to refill *very* often |
11:03:00 | funman | the state : additional error handling wouldn't harm |
11:03:05 | Llorean | It seems to refill at about 512k |
11:03:13 | Llorean | Which is a bit early when it's only 630k large |
11:03:27 | Zagor | Llorean: yes, I noted that too. the watermarks are totally off. |
11:03:34 | Zagor | except for wav, for some reason |
11:03:37 | funman | #define BUFFERING_DEFAULT_WATERMARK (1024*512) |
11:03:45 | Zagor | funman: ah! :-) |
11:04:09 | funman | i think all the keys are in buffering.c since replacing this file gives completely different results |
11:04:18 | Zagor | new targets are good. it gives us reason to revisit and improve old code. |
11:05:09 | * | Llorean tries with a smaller watermark |
11:05:14 | Llorean | Flash doesn't need to wait for spinup |
11:05:49 | Zagor | yeah, seems the buffering code could use a number of #if HAVE_FLASH_STORAGE |
11:07:17 | Llorean | I imagine the watermark being higher than the total buffer size caused at least some problems |
11:07:20 | kugel | Zagor: Or use the flash buffering patch, maybe with a higher buffer? |
11:08:08 | Zagor | kugel: that's definitely an option. we need to determine which approach is the most power efficient. |
11:08:25 | Llorean | Hmm. |
11:08:25 | funman | Zagor: hum now i record : the corruption i had seen was in the linked lists struct memory_handle |
11:08:26 | Zagor | Llorean: indeed |
11:08:39 | Llorean | I tried changing the DEFAULT_WATERMARK to 1024*128 and it's still rebuffering at 512k |
11:08:43 | Llorean | Is there something else I need to look at? |
11:08:49 | funman | and the useful_data flag comes from the active struct |
11:09:04 | kugel | Zagor: I think a combination of both. As in use the available ram on as buffer for flash buffering too (although it potentially only needs very little) |
11:09:40 | Zagor | kugel: well we can't make it too special, since the audiobuffer is a core element that is used by a lot of other code too. |
11:10:55 | kugel | Zagor: That's what I meant: Full the very little flash buffer with the available ram to form the "classic" audiobuffer |
11:11:58 | | Join Darksair [0] (n=user@58.213.192.98) |
11:12:00 | funman | and the memory_handle s are stored in buffering.c's "buffer" (= playback.c's "filebuf") |
11:12:23 | * | Llorean assumes the problem is that he left high watermark alone |
11:12:34 | Zagor | do we have an SD guru? do SD cards normally have power management? i.e. is it more efficient to do few long reads, or is it just the same to do many frequent small reads? |
11:12:57 | funman | hum that reminds me the pl180 has a 'powersave' bit .. |
11:13:05 | Zagor | pl180? |
11:13:16 | funman | SD controller inside the as3525 SoC |
11:13:20 | Zagor | ah |
11:13:24 | kugel | Zagor: when I tried the flash buffer patch on my e200, it definitely had an impact on battery life |
11:13:32 | Zagor | kugel: negative? |
11:13:36 | kugel | yes |
11:13:40 | Zagor | ok |
11:13:50 | kugel | and that was before the "sd_enable()" commit |
11:14:00 | funman | that's what i was going to ask : what about now? |
11:14:11 | | Quit AndyI (Read error: 110 (Connection timed out)) |
11:14:32 | Unhelpful | funman: your short test w/ origin in place of HEAD seems to be the way to go |
11:14:47 | Unhelpful | git log origin^..origin|tail -1|cut -d@ -f2|cut -d\ -f1 |
11:14:51 | funman | as long as there is an origin ;) |
11:15:12 | Zagor | what exactly do we gain by reading directly from flash? it makes a lot of other things more difficult, such as MoB. |
11:15:13 | funman | and note that if you don't use git pull −−rebase, origin will not be updated |
11:15:46 | * | Llorean is apparently failing to convince it to use a different watermark. |
11:15:58 | Zagor | my feeling is that it's a last resort for very lowmem targets that simply cannot work otherwise |
11:16:18 | Llorean | That being said, as long as I sit in the buffer screen rather than the WPS, I currently have perfect playback, it seems. |
11:16:26 | Llorean | If I go to the WPS it eventually freezes up. |
11:16:43 | Unhelpful | funman: what about using git rebase? |
11:16:50 | Zagor | Llorean: try changing tracks in the buffer screen (press up & down) |
11:16:57 | funman | Unhelpful: yes that's probably better, i'm too used to git pull ;) |
11:17:04 | Llorean | Zagor: Works fine |
11:17:20 | Unhelpful | git rebase doesn't seem to work w/o arguments |
11:17:36 | Unhelpful | so it's either git rebase origin or git pull −−rebase :/ |
11:17:45 | funman | Llorean: if repeat again multiple times you'll get other (iconsistent) crashes i believe |
11:17:57 | Llorean | funman: Repeat what? |
11:18:07 | funman | any steps related to playback in fact |
11:18:18 | Llorean | No crashes |
11:18:27 | Llorean | I just skipped about 12 tracks. |
11:18:36 | funman | but you only did that for 1 or 2 hours |
11:18:56 | Llorean | If I skip many tracks, very fast, playback pauses, but if I go to the WPS and pause then unpause, it resumes. |
11:19:01 | | Quit kugel (Remote closed the connection) |
11:19:06 | funman | from my longer experience i think that the crashes happen randomly and not because of particular conditions |
11:19:42 | Llorean | Well, it was crashing _very_ easily before making the PCM buffer smaller. I currently have 1 second PCM buffer, and ~730K of compressed buffer. |
11:20:01 | Llorean | Unfortunately, I failed to set the watermark lower. |
11:20:11 | Llorean | So it's still rebuffering quite often. |
11:21:00 | Llorean | Hm, "backlight on hold" doesn't seem to work on the clip. |
11:21:19 | Zagor | Llorean: watermark is also set in each codec. ci->configure(CODEC_SET_FILEBUF_WATERMARK, 1024*512); |
11:22:05 | B4gder | haha, how... eh, weird |
11:22:10 | Llorean | That seems strange to me. |
11:22:17 | Llorean | it seems like the watermark should rather be a calculation. |
11:22:20 | Zagor | I won't argue with that... |
11:22:23 | Llorean | Average bitrate * X seconds, or something |
11:22:33 | Llorean | Basically "long enough to spinup, plus a bit" |
11:22:49 | B4gder | the hwcodec has it based on the hd spinup time iirc |
11:22:57 | Llorean | Though I guess it'd get quite complicated with mixed codecs. |
11:23:04 | Zagor | B4gder: at least it did, last I looked at it :-) |
11:23:16 | B4gder | I don't think that has moved much during recent times |
11:23:40 | Zagor | Llorean: well there are still much better ways to do it than this way |
11:24:08 | Llorean | Anyway, for whatever clue it's worth, if I'm in the WPS I seem much more likely to get a freeze or halt in playback. |
11:24:44 | | Join gregzx [0] (n=chatzill@dsg54.neoplus.adsl.tpnet.pl) |
11:25:59 | Zagor | Llorean: could simply be that wps touches a lot more memory areas than buffer screen, and so if things get overwritten wps will go wrong faster than buffer screen |
11:26:44 | Llorean | Could be. |
11:26:57 | Zagor | my theory remains buffering overruns, due to faulty assumptions about buffer size. |
11:27:52 | Llorean | I'm actually most curious why playback doesn't start until I pause and unpause. |
11:28:08 | Llorean | Since I can also get it "stuck" like that by skipping many tracks very quickly. |
11:29:22 | | Quit linuxstb (Read error: 110 (Connection timed out)) |
11:33:16 | | Join aliask [0] (n=chatzill@rockbox/developer/aliask) |
11:36:39 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
11:49:22 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
11:52:10 | | Quit kugel (Remote closed the connection) |
11:54:11 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
11:55:51 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
11:56:32 | | Join moos [0] (i=moos@81-66-158-133.rev.numericable.fr) |
12:00 |
12:08:54 | | Quit Darksair ("To Arch or Gentoo? That is the question...") |
12:13:53 | funman | i don't have playback anymore, perhaps it's due to too small pcm buffer? |
12:14:05 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
12:16:33 | funman | according to the debug menu, the pcm buffer fills and then everything just stops |
12:18:33 | n1s | hmm, this looks weird |
12:18:59 | * | n1s wants an iaudio [xm]5 tester |
12:21:01 | funman | and using an higher pcm buffer makes playback start again |
12:21:59 | Llorean | funman: I had playback with a ~176kb PCM buffer. |
12:22:15 | Llorean | Er, 192 perhaps |
12:22:34 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
12:22:35 | funman | if i use 1 second, i got nothing |
12:22:42 | Llorean | funman: Did you pause and unpause? |
12:22:48 | funman | yep |
12:23:03 | Llorean | How big are your compressed buffers? |
12:23:09 | funman | very big |
12:23:11 | Llorean | Er, is your compressed buffer. |
12:23:22 | Llorean | Mine was about 900k |
12:23:33 | funman | humm i think it was less |
12:23:43 | funman | where did you get this extra space i haven't? |
12:23:49 | Llorean | I disabled tagcache, and lowered my max playlist to 2000, and max files in folders to 100 |
12:23:55 | funman | right |
12:24:16 | Llorean | oh, sorry, 720 |
12:24:18 | Llorean | Not 900 |
12:24:23 | * | Llorean wonders where he got 900 from |
12:24:24 | funman | ah now pause/unpause starts playback |
12:24:58 | funman | 172kB pcm , 615kB filebuf |
12:25:45 | Llorean | Same PCM, slightly more compressed here. |
12:27:37 | n1s | hmm, not so weird after all, just a confusing keymap, still if someone could confirm FS #7572 on [mx]5 would be nice |
12:27:45 | pixelma | n1s: what for? |
12:28:49 | n1s | pixelma: No one has confirmed it, it's old and the code seems like everything should work the same as the irivers etc |
12:29:08 | pixelma | n1s: can't help you with this as the M5 doesn't have radio... |
12:29:20 | n1s | ah |
12:32:28 | funman | i'll stop reading that code else it'll give me headaches |
12:33:24 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
12:36:52 | *** | Saving seen data "./dancer.seen" |
12:39:20 | n1s | rasher: i'm pretty sure FS #8819 has not been fixed but the only way to test is to commit a broken amnual update :) |
12:39:32 | n1s | s/am/ma/ |
12:40:14 | Llorean | funman: So far with the small PCM buffer and large compressed buffer, the only crash I've gotten has been a Panic for the SD FIFO |
12:40:19 | | Join _lifeless [0] (n=lifeless@90.151.216.44) |
12:42:00 | funman | Llorean: i also get deadlocks, data abort (in buffering.c code messing with memory_handle linked lists, or memcpy, memset ..), stack overflows (less common) |
12:46:03 | | Join Aurix_Lexico [0] (n=comrade@68.56.205.239) |
12:56:05 | * | Zagor wants to see static symbols in the .map file |
12:56:50 | Zagor | I get a data abort in buffering.c, but it's not in one of the public symbols :-( |
12:57:12 | funman | Zagor: isn't it a struct access ? |
12:57:23 | funman | (or close to) |
12:57:29 | Zagor | pointer access, at least |
12:57:44 | Zagor | but there's quite many of those in that file... |
12:58:18 | funman | IDA makes it easy to read rockbox.elf , dunno about objdump |
12:58:34 | Zagor | good idea |
12:59:04 | Zagor | I forget, do we already have some support for assert()? methinks it would be useful in cases like this. |
13:00 |
13:00:35 | funman | #define assert(x) do { if(x) panicf(##x); } while(0) /* here it is */ |
13:00:55 | * | n1s wonders if jhMikeS has a different definition of 'freeze' than everyone else :P |
13:00:55 | funman | if(!x) even |
13:02:44 | Zagor | we have include/assert.h, but I can't find any implementation of __assert |
13:03:06 | * | jhMikeS missed the "freeze" announcement? Or is keeping things sane a bugfix? |
13:03:35 | Zagor | jhMikeS: what are you referring to? |
13:03:36 | Llorean | It's probably one of those gray areas anyway. |
13:04:01 | jhMikeS | n1s: wondering about my definition of "freeze" :) |
13:04:11 | funman | Zagor: i found also some other functions declared in headers but not defined |
13:04:13 | jhMikeS | s/n1s:/n1s/ |
13:05:34 | Zagor | the data abort is in fill_buffer() |
13:06:08 | funman | Zagor: m = m->next ? |
13:06:23 | funman | anyway that means corruption of the memory_handle |
13:06:46 | funman | or perhaps first_handle |
13:07:26 | Zagor | I'll disassebmle and see |
13:07:43 | Zagor | dismsmasllalbmle |
13:08:08 | funman | disassmatroskae, disbuttmatroskae, (ok i stop) |
13:08:24 | jhMikeS | beep (OT warning) |
13:09:24 | | Quit funman ("leaving") |
13:14:43 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
13:22:08 | | Join pvbcharon [0] (n=charon@62.225.173.228) |
13:22:18 | | Quit pvbcharon (Client Quit) |
13:32:44 | Zagor | I wonder if periodical list walking/checking would yield anything |
13:36:07 | * | Zagor feels a little guilty for playing with a new target instead of fixing bugs for the release... |
13:39:35 | Llorean | You're just getting a big head start on 3.2 |
13:39:39 | Llorean | Or maybe 3.3 |
13:42:07 | | Quit Nico_P (Remote closed the connection) |
13:44:03 | | Quit Aurix_Lexico ("Leaving.") |
13:45:21 | | Join kugel [0] (n=chatzill@e178073170.adsl.alicedsl.de) |
13:45:41 | | Join mc2739 [0] (n=mc2739@cpe-67-10-238-175.satx.res.rr.com) |
13:47:33 | | Part B4gder |
13:48:06 | mc2739 | can I get a dev to fix FS #9625, I hit add task too soon |
13:48:35 | mc2739 | it should be: tasktype=patch, category=music playback, and player=another |
13:49:35 | | Quit aliask ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") |
13:49:54 | kugel | mc2739: I assume you got sound? |
13:50:47 | Llorean | mc2739: Fixed.. |
13:50:59 | mc2739 | Llorean: thank you |
13:51:30 | mc2739 | kugel: yes, flac, wav, all play - mp3 has problems |
13:51:43 | kugel | I tried ogg and it didn't play |
13:52:06 | mc2739 | ogg worked for me also |
13:52:14 | kugel | I tried to ge to the wps using a playlist_control and nvram.bin in combination with start screen: wps |
13:52:41 | mc2739 | that is what I had to do to get it to play |
13:52:58 | Zagor | sounds like we should do what the comment above that #if says... |
13:54:04 | Zagor | "TODO : If this turns out to apply to all ams3525 targets, consider simplifying the precompiler condition to #if defined(AS3525)." |
13:54:12 | * | kugel highly assumes it also applies for fuze (and probably c200v2 too) |
13:54:25 | kugel | so, agree to Zagor |
13:54:54 | | Join stripwax__ [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
13:54:57 | | Quit stripwax__ (Client Quit) |
14:00 |
14:01:53 | | Quit mc2739 () |
14:04:06 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
14:04:12 | | Join DerDome [0] (n=DerDome@141.71.76.61) |
14:04:19 | | Join massiveH [0] (n=massiveH@pool-72-76-241-148.nwrknj.fios.verizon.net) |
14:10:02 | | Join LambdaCalculus37 [0] (i=44a04303@rockbox/staff/LambdaCalculus37) |
14:12:39 | | Join CaptainKewl [0] (n=jason@cpe-68-173-40-122.nyc.res.rr.com) |
14:15:17 | soap | linuxstb: congrats again on your polite and well spoken interaction with TBeck. I hope his offerings prove useful to you. |
14:15:29 | | Quit culture (Read error: 60 (Operation timed out)) |
14:16:50 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
14:17:58 | | Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) |
14:18:19 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
14:26:11 | | Join Schmogel [0] (n=Miranda@p3EE21885.dip0.t-ipconnect.de) |
14:28:40 | | Join Jaykay [0] (n=chatzill@p579E7B5F.dip.t-dialin.net) |
14:36:45 | | Quit CaptainKewl (Remote closed the connection) |
14:36:57 | *** | Saving seen data "./dancer.seen" |
14:38:35 | * | Jaykay breaks the silence |
14:38:53 | * | Jaykay hopes that the developers are not annoyed by those "i suggest closing of...."-messages... |
14:39:13 | Zagor | not if they are reasonable |
14:39:50 | Jaykay | i suggest closing of http://www.rockbox.org/tracker/task/6746?project=1 because when the player says 1020 min remaining you just think wtf...... |
14:41:29 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-6774dab534239b60) |
14:43:33 | Zagor | Jaykay: I disagree. I might not want it myself, but that is no reason to reject it. It's a valid feature and it doesn't add much code. |
14:44:09 | | Quit itcheg (Client Quit) |
14:44:18 | | Join itcheg [0] (i=41d59de2@gateway/web/ajax/mibbit.com/x-1c76697df886b4e6) |
14:45:39 | Jaykay | Zagor: du you really think somebody wants the battery lifetime given in minutes? you wont know how much hours 1000+ minutes are.... |
14:46:11 | Zagor | obviously the person who bothered to write the patch wants it |
14:47:39 | Zagor | the patch is adding a wps tag to be used by whoever chooses to. it's not changing anything, only adding. |
14:48:27 | Jaykay | ok so i am allowed to write a patch, say "i do want this" and hen the patch remains in the tracker for years? ;) |
14:48:52 | Llorean | It'll stay in the tracker until we make up our minds as to whether we want it or not. |
14:49:03 | Zagor | Jaykay: of course you are allowed to do that. |
14:49:12 | Jaykay | ok...... |
14:49:23 | Llorean | You need to be just as certain about rejecting it as you are about committing it. |
14:49:35 | Jaykay | know i know why there are 340+ patches^^ |
14:50:20 | Llorean | It's better than none, probably. |
14:51:36 | Jaykay | another patch: http://www.rockbox.org/tracker/task/9329?project=1 |
14:52:01 | Jaykay | it does something automatically.... without asking for anything. |
14:53:17 | Jaykay | and those total track/disk tags can be useful (nevertheless i dont use them) |
14:54:51 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
14:55:36 | Llorean | Jaykay: The patch opener is a dev, so it should probably wait for his response at least before closing. |
14:56:29 | Jaykay | ok |
14:56:31 | PaulJam | i think you can even acieve this without the patch, by just displaying this information in a vievport that just fits 2 numbers, so if the tracknumber is 08/12 then only 08 would be visible in the WPS. |
14:57:03 | Jaykay | yeah but as far as i see this patch is deleting the tags... |
14:57:17 | Jaykay | not only showing part of it |
14:57:26 | Llorean | It's ignoring part of it. |
14:57:46 | Llorean | Rockbox has no means of writing tags back to the files. |
14:58:36 | Jaykay | verdammt.... |
14:58:45 | Jaykay | ok im sorry.. |
14:59:20 | Zagor | on this one I agree with jaykay. rasher showed already aug27 that the patch goes againt the spec. |
14:59:40 | Llorean | Zagor: I stated I don't like the idea of the patch in the very first comment. |
14:59:49 | Zagor | yup |
15:00 |
15:00:10 | Llorean | I'd just think we should wait for lear to have a last response before closing, is all. Or at least, give him a day or two to respond, the last comment's only from yesterday. |
15:00:28 | Zagor | I'm ok with that |
15:09:10 | LambdaCalculus37 | I think that the patch doesn't really have any use at all, but yes, it's lear's patch, so let's have him speak about it. |
15:13:14 | | Quit PaulJam (".") |
15:31:08 | | Quit pondlife ("Leaving.") |
15:37:39 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
15:38:34 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
15:39:48 | | Join MethoS-- [0] (n=clemens@host-091-097-240-161.ewe-ip-backbone.de) |
15:40:46 | | Join Horschti [0] (n=Horscht@p4FD4C017.dip.t-dialin.net) |
15:41:32 | | Quit Horscht (Nick collision from services.) |
15:41:42 | | Quit MethoS- (Read error: 60 (Operation timed out)) |
15:43:22 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
15:45:34 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
15:45:35 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-069-229.nc.res.rr.com) |
15:53:00 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
15:53:08 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-50ac43ca7afe7622) |
16:00 |
16:08:42 | | Join massiveH_ [0] (n=massiveH@pool-72-76-241-148.nwrknj.fios.verizon.net) |
16:13:56 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
16:16:10 | | Quit DerDome ("Leaving.") |
16:25:48 | | Quit massiveH (Read error: 110 (Connection timed out)) |
16:37:00 | *** | Saving seen data "./dancer.seen" |
16:53:07 | Llorean | domonoky: Are you interested in accessibility in RBUtil or is it primarily Bluebrother who's worked on that? |
16:53:51 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
16:54:33 | domonoky | Llorean: i am interested in it, but i miss the time for it. I think we 8me and bluebrother) both worked on accessibility issues.. :-) |
16:54:58 | Llorean | domonoky: You may be interested in http://www.rockbox.org/mail/archive/rockbox-archive-2008-12/0104.shtml |
16:55:04 | Zagor | to build the database pc tool, we should probably just start with the uisim, put in the five-line database.c main() and then chip away what isn't needed. doing it the other way is ... frustrating |
16:55:10 | * | domonoky also already replied to brandon |
16:55:22 | Llorean | Okay, just making sure. |
16:55:43 | Llorean | Never do know who's subscribed to that list and who isn't. |
16:56:15 | domonoky | true, so thanks for noticing me. :-) |
16:56:49 | domonoky | did you find time to try out your m200v4 ? |
16:57:26 | Llorean | domonoky: Not yet. I keep getting distracted with my clip. |
16:57:38 | domonoky | :-) |
16:59:56 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
17:00 |
17:04:32 | LambdaCalculus37 | amiconn: Ping |
17:07:42 | | Quit Zagor ("Client exiting") |
17:10:20 | | Nick massiveH_ is now known as massiveH (n=massiveH@pool-72-76-241-148.nwrknj.fios.verizon.net) |
17:13:17 | | Join CaptainKwel [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-667e9cbb82d81a62) |
17:14:35 | | Quit petur ("connection reset by beer!") |
17:15:13 | | Nick Horschti is now known as Horscht (n=Horscht@xbmc/user/horscht) |
17:20:54 | | Join DrMoos [0] (i=moos@81-66-158-133.rev.numericable.fr) |
17:21:04 | | Quit DrMoos (Read error: 104 (Connection reset by peer)) |
17:29:17 | n1s | hmm, i wonder how we can have only 23 "known" bugs in the 3.1 release notes when there are 169 open bugreports... |
17:29:48 | kugel | marketing :) |
17:30:12 | | Quit kharo (Read error: 110 (Connection timed out)) |
17:30:13 | | Join kharo1 [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
17:30:31 | n1s | on a related note, i wonder why we list still open bugs in the release notes at all? |
17:31:58 | kugel | anti-marketing :) |
17:32:07 | * | kugel runs |
17:32:18 | Llorean | If we tell them it sucks, they'll be even happier when it's awesome. |
17:32:18 | * | LambdaCalculus37 chases kugel with a squeaky hammer |
17:32:27 | n1s | a question about FS #9427 can tracks in a file played with a cue sheet have individual meta data? |
17:38:58 | kugel | n1s: yes, I don't know if rockbox supports it though. The cue file can declare some fields individually for each track |
17:41:21 | linuxstb | n1s: Yes, Rockbox stores per-track metadata for a file with a cuesheet. |
17:41:25 | linuxstb | (assuming that info is in the cuesheet...) |
17:46:46 | n1s | so it _could_ be feasible to scrobble individual tracks from a cue sheet-file thingy? |
17:47:34 | linuxstb | Why only "could be" ? I would say it _is_ feasible. |
17:47:59 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
17:48:25 | linuxstb | I guess it could get complicated when determining % of tracks played... |
17:48:32 | kugel | the problem seems to be that scrobble thingy doesn't actually read the same thing as the wps (I seem to remember the wps shows the individual track info from the cue) |
17:48:46 | n1s | Doesn't the scrobbler require a bunch of fields? I guess i just don't know enough about cue sheet metadata stuff? |
17:49:24 | n1s | ah, well thanks for clarifying though :) |
17:49:32 | linuxstb | The cue contains artist name, track name and album name. I guess anything else would be from the whole-file metadata in the tags. |
17:49:39 | | Join perrikwp|lab [0] (i=982129cf@gateway/web/ajax/mibbit.com/x-5e49288843725070) |
17:50:02 | kugel | track number is probably too (at least indirectly) in the cue file |
17:50:38 | | Quit massiveH ("Leaving") |
17:51:27 | kugel | linuxstb: I wonder if you could commit http://www.rockbox.org/tracker/task/9623 , I tested it in the bootloader |
17:51:59 | * | kugel wonders if funman is going to show up again before he starts his travel tomorrow |
18:00 |
18:00:35 | | Join evilnick [0] (i=0c140464@gateway/web/ajax/mibbit.com/x-40034293988ac258) |
18:00:58 | | Join Rob2222 [0] (n=Miranda@p4FDCCD20.dip.t-dialin.net) |
18:03:16 | | Join Strife89 [0] (n=michael@204.116.245.152) |
18:09:20 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
18:11:33 | | Quit MethoS-- (Read error: 104 (Connection reset by peer)) |
18:11:41 | kugel | does anyone already have an idea what to do about the resizers in the pluginlib? smooth_resize and simple_resize |
18:12:07 | kugel | I think they're slightly obsolete with resize in the core |
18:16:05 | evilnick | Is there anyone with a Sansa E-series around? |
18:16:16 | kugel | here |
18:17:03 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
18:17:23 | evilnick | After the addition of the software fade-out, I've had a few instances when a button-press as the screen starts to fade-out will NOT reset the time-out (i.e. the screen still fades out) |
18:17:28 | | Join Llorean [0] (n=DarkkOne@adsl-65-68-72-166.dsl.hstntx.swbell.net) |
18:18:04 | evilnick | It's damn hard to reproduce though |
18:18:19 | | Quit TMM (Remote closed the connection) |
18:19:33 | kugel | evilnick: I made the patch. I have not experienced what you describe though |
18:19:42 | | Join TMM [0] (n=hp@5ED10264.cable.ziggo.nl) |
18:19:52 | kugel | you maybe didn't press hard enough? |
18:20:36 | evilnick | It's whilst I was in Solitaire, and pressed Rec to deal another three cards - the Rec button performs the correct function in Solitaire but the screen continues to fade-out |
18:21:01 | | Join MethoS- [0] (n=clemens@host-091-097-240-161.ewe-ip-backbone.de) |
18:21:23 | evilnick | This happened only 3 or 4 times in about half an hour, so it's usually working as expected. I just wanted to see if anyone else had experienced it. |
18:21:28 | | Join karashata [0] (n=karashat@69.41.192.215) |
18:22:58 | | Join miepchen^schlaf [0] (n=miepel@p579EC91E.dip.t-dialin.net) |
18:23:09 | kugel | evilnick: I have indeed a hard time trying to reproduce it |
18:24:13 | kugel | evilnick: have you only experienced it in solitaire so far? |
18:24:21 | evilnick | kugel: I'm guessing that it's such a small window of opportunity that it might not be worth looking into. |
18:24:40 | evilnick | kugel: yes, so far. Would the fact it's a plugin make a difference? |
18:25:05 | kugel | could be |
18:25:45 | evilnick | It seemed to happen if the fade-out had *just* started if that's any help |
18:27:20 | kugel | evilnick: sorry, I try hard, but I'm not able to reproduce |
18:28:09 | evilnick | Yeah, just tried on the wps screen using play/pause and can't reproduce it either, so perhaps it's a problem with the Solitaire plugin. |
18:28:34 | kugel | I'm trying solitaire |
18:29:14 | evilnick | kugel: try during a commute so that you can spend quite some time on it! |
18:29:14 | | Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
18:29:53 | kugel | evilnick: Ok, I got it now, with 1s backlight timeout |
18:30:32 | | Join Schmogel [0] (n=Miranda@p3EE21885.dip0.t-ipconnect.de) |
18:30:44 | evilnick | cool - it's very rare, but I'm glad I got to describe it to the correct dev! |
18:31:01 | | Part evilnick |
18:31:55 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
18:32:41 | kugel | I fail to reproduce it in other situations though |
18:37:03 | *** | Saving seen data "./dancer.seen" |
18:37:30 | slact | quick question: rockbox will accept dirty USB power, right? |
18:37:38 | | Quit Schmogel (Read error: 60 (Operation timed out)) |
18:37:48 | | Join jeffdameth [0] (n=jeff@dyndsl-095-033-111-197.ewe-ip-backbone.de) |
18:38:30 | slact | (that is, I wouldn't need to negotiate a "usb 2-capable, powered hub" on the data lines to get the battery to charge) |
18:38:36 | slact | (...on a 5.5G ipod) |
18:40:05 | rasher | slact: I actually don't think so.. gevaerts is the man you want to ask to get a real answer |
18:40:29 | slact | hmm |
18:40:35 | slact | well, it wouldn't kill it, right? |
18:40:48 | slact | i mean, 5 volts is 5 volts... |
18:41:26 | rasher | I've no idea, honestly.. I just remember hearing reports about not charging right |
18:41:31 | slact | hm |
18:41:37 | slact | eh, guess i'll just give it a try. |
18:42:57 | slact | seems to be charging okay... |
18:43:11 | slact | debug screen says so, voltage graph says so |
18:43:35 | slact | that makes my life easier, but i'm not sure that's great in general... |
18:53:14 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:55:19 | | Quit Strife89 ("Bye all.") |
18:56:30 | | Quit perrikwp|lab ("http://www.mibbit.com ajax IRC Client") |
18:56:34 | | Quit nplus (Read error: 110 (Connection timed out)) |
19:00 |
19:00:29 | | Join nplus [0] (n=nplus@141.25.Globcom.Net) |
19:03:32 | | Join massiveH [0] (n=massiveH@pool-72-76-241-148.nwrknj.fios.verizon.net) |
19:08:13 | | Join herrwaldo [0] (n=waldo@ip-81-11-216-3.dsl.scarlet.be) |
19:11:14 | | Quit linuxstb (Read error: 113 (No route to host)) |
19:21:24 | | Quit avacore (Read error: 110 (Connection timed out)) |
19:27:50 | * | kugel finally got a final version of his pictureflow patch out! |
19:27:56 | kugel | Nico_P: You might have a look at it |
19:31:13 | LambdaCalculus37 | kugel: What does your patch do? |
19:32:37 | | Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
19:32:39 | kugel | LambdaCalculus37: it adds configurability to the album title (at top, at bottom or not at all), introduces resizing (to lcd_height/2, configurable), and fixes 2 outstanding bugs |
19:33:01 | | Join eric [0] (n=eric@adsl-71-132-131-65.dsl.pltn13.pacbell.net) |
19:33:05 | kugel | parts of it have been committed already during the previous freeze ;) |
19:33:19 | | Nick eric is now known as Guest68088 (n=eric@adsl-71-132-131-65.dsl.pltn13.pacbell.net) |
19:33:32 | LambdaCalculus37 | kugel: Would one of those outstanding bugs happen to be PF not properly refreshing its database when told to do so via its option menu? |
19:34:02 | Guest68088 | I recently swapped out the HD in my Gigabeat F10 and I have tried all the recovery procedures to no avail....I was wondering if someone can help... |
19:34:08 | LambdaCalculus37 | Refreshing the database in that manner often cause PF to display certain album covers in place of blank covers. |
19:34:17 | kugel | LambdaCalculus37: No, not that one. I suppose you mean the one where covers of deleted files still show up? |
19:34:28 | kugel | or changed covers aren't refreshed |
19:35:12 | kugel | that's basically solved by really deleting the old cache. Yea, that should be doable (once I know how to batch delete files in plugins, I probably should look at disktidy) |
19:37:49 | Guest68088 | Broke rule #9 |
19:38:22 | | Quit slact (Read error: 60 (Operation timed out)) |
19:38:42 | LambdaCalculus37 | kugel: I've been doing that already (deleting the old cache and letting PF rebuild), but it sometimes tends to be a little tedious, not to mention a bit kludgey. |
19:38:43 | kugel | rb-remove(/absolute/path/to/file) ? |
19:39:01 | kugel | LambdaCalculus37: yea, pf should do that for you, I agree |
19:39:46 | | Quit MethoS- (Remote closed the connection) |
19:40:14 | LambdaCalculus37 | kugel: I think disktidy would be a good starting point to find out how to delete files from within plugins. Once you figure it out, adding an option to PF (say, "Rebuild art from scratch") would make the job much easier. |
19:40:22 | Guest68088 | Swapped out my Gigabeat F10 hard drive with a new HD from the list provided on the website. Everything is connected fine, used QT parted to create a partion and formated it with FAT32. Attempting to transfer the GBSytem folder to the drive, but the drive is not recognizable in Ubuntu, or XP. I can see it in Vista through Disk Management, but states not initialized. Need help getting HD recognized so I can reload System and |
19:40:22 | Guest68088 | RockBox |
19:40:27 | LambdaCalculus37 | s/art/cache |
19:40:41 | kugel | LambdaCalculus37: Why adding another item? Just let the existing rebuild cache do that |
19:40:57 | LambdaCalculus37 | kugel: True. |
19:44:05 | advcomp2019 | Guest68088, just wait for someone that knows it |
19:47:00 | | Nick Guest68088 is now known as J0hnnyBr (n=eric@adsl-71-132-131-65.dsl.pltn13.pacbell.net) |
19:47:03 | toffe82 | Guest68088: if the drive is no recognized, you have to do the recovery again |
19:48:33 | | Join fml [0] (n=4fd3c4a5@gateway/web/cgi-irc/labb.contactor.se/x-a1c965d48284ed09) |
19:49:23 | fml | Hello. Wouldn't it be good to have some last entries from the MajorChanges page on the start rockbox page? |
19:49:56 | J0hnnyBr | toffe82: I've done the recovery a few times already...I don't understand why the drive shows up until I add a partition and format...weird |
19:50:15 | LambdaCalculus37 | J0hnnyBr: Please stick with a nick. |
19:50:32 | toffe82 | after the format, if you don't disconnet, you don't see it ? |
19:51:49 | J0hnnyBr | toffee82: I took the drive and plugged it in to my Ubuntu box...it shows up but cannot mount. I then ran QT Parted and created a single FAT32 partition and formated with FAT32. When I go back into the file manager, the disk no longer shows up |
19:53:56 | J0hnnyBr | toffee82: When I follow the recovery procedure on my Vista box, I get a message that the Disk is not initialized and when I try to initialize it, it states there is an I/O error |
19:54:46 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
19:56:44 | | Join stoffel_ [0] (n=sfr@p57B4DFE3.dip.t-dialin.net) |
19:57:28 | kugel | LambdaCalculus37: fixed! |
19:59:48 | toffe82 | J0hnnyBr: did you try back your old drive ? |
20:00 |
20:01:18 | LambdaCalculus37 | kugel: Cool, what's the FS#? |
20:02:46 | kugel | LambdaCalculus37: Do you know which FS# that was? |
20:03:16 | kugel | I mean the bug report on that |
20:03:55 | kugel | hm, I think I have a better plan |
20:06:52 | LambdaCalculus37 | kugel: No, I don't remember. |
20:07:38 | | Join funman [0] (n=fun@rockbox/developer/funman) |
20:08:02 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
20:12:39 | | Quit fml ("CGI:IRC (EOF)") |
20:12:58 | | Quit stoffel_ ("leaving") |
20:18:27 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-12fc688be4f30200) |
20:21:31 | rasher | kugel: how about getting the artist / albumartist information before searching for albumart? (to fix FS #9606 and remove the need for FS #9622) |
20:22:03 | kugel | rasher: I'll have a look |
20:22:38 | kugel | if it fixes fs#9606, then yea, that's proper |
20:24:02 | rasher | Yeah, I mean actually getting the artist and albumartist value and putting that in id3.artist/id3.albumartist.. that would fix FS #9606, and FS #9622 wouldn't be necessary I guess |
20:26:40 | | Quit Bensawsome (Remote closed the connection) |
20:28:12 | | Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) |
20:28:50 | kugel | LambdaCalculus37: the fix is at FS #8335 |
20:29:16 | | Join petur [50] (n=petur@rockbox/developer/petur) |
20:30:16 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
20:30:16 | rasher | kugel: I'm going to commit FS #9622 (since it's currently buggy) and add a note that it should ideally be set to the actual artist/albumartist value instead |
20:31:08 | kugel | rasher: Ok. On a side note: It seems I somehow fixed that issue with the latest patch FS #8335 (No idea why though, but the sim doesn't crash anymore |
20:31:29 | rasher | kugel: you're probably just lucky concerning memory usage |
20:31:50 | kugel | fixed as in fix 9622, not as in fix#9606 probably |
20:32:11 | LambdaCalculus37 | J0hnnyBr: What's the drive model you're trying to use? |
20:32:30 | kugel | rasher: hm, you mean that my sim gets the same portion of ram again and happens to retrieve correct data by that? |
20:32:58 | rasher | kugel: or another portion where the memory happens to be null (or something else that doesn't cause trouble) |
20:33:11 | * | domonoky wonders why video.c in plugins/SOURCES is dependend on CONFIG_LCD == LCD_SSD1815 |
20:33:26 | kugel | rasher: yea, that's possible |
20:33:34 | * | kugel haven't thought of that |
20:34:44 | * | kugel fails to get segfaults. |
20:35:02 | kugel | can anyone else try to see if FS #8335 "fixes" the segfaults? |
20:37:06 | *** | Saving seen data "./dancer.seen" |
20:38:29 | pixelma | domonoky: that's the Archos video player |
20:39:19 | domonoky | pixelma: yes, and the m200v4 has a LCD_SSD1815, so i have to change the check. |
20:41:02 | * | domonoky finds chopper very hard to play on m200v4, the display is so small, you nearly always crash before you can even press select :-) |
20:41:23 | LambdaCalculus37 | domonoky: The tiny displays make it much harder to play. |
20:41:44 | J0hnnyBr | LambdaCalc: The drive is MK1231GAL |
20:42:01 | J0hnnyBr | LamdabCalc: Toshiba... |
20:42:12 | pixelma | domonoky: already using the half chopper size as Archos? |
20:42:36 | | Join Reizo [0] (n=4232bff8@gateway/web/cgi-irc/labb.contactor.se/x-12a599d11fc477fe) |
20:42:47 | LambdaCalculus37 | J0hnnyBr: Have you read http://www.rockbox.org/twiki/bin/view/Main/HardDriveReplacement before? |
20:42:53 | pixelma | btw... amiconn ;) |
20:43:03 | domonoky | pixelma: i only added keys, not more.. everything else can come later. Now i need a solution to the video.c and i can commit plugins for m200v4. |
20:43:22 | * | LambdaCalculus37 should look for an m200v4 and get in on the fun as well... ;) |
20:43:39 | J0hnnyBr | LambdaCalc: Yes...and the other docs on the site as well |
20:43:52 | pixelma | domonoky: maybe check for swcodec/hwcodec too? Though I don't know if that's the clean solution (TM) |
20:44:02 | Reizo | Hello. I wanna join TWiki. And I read, that I needed to introduce myself here. Or did I mis interpret? |
20:44:20 | LambdaCalculus37 | Reizo: Well, you do have to come here to ask for write permission. |
20:44:34 | LambdaCalculus37 | J0hnnyBr: Bad news: http://www.rockbox.org/twiki/bin/view/Main/HardDriveReplacement#Toshiba (read a little further down). |
20:44:38 | J0hnnyBr | LambdaCalc: OK...I see why you are telling me that.... |
20:45:05 | LambdaCalculus37 | Reizo: What's your wiki name? I can give you permission. |
20:45:27 | J0hnnyBr | LambdaCalc: I missed the *. Yep....kicking myself. Saw the drive was cheap and jumped at it... |
20:45:35 | Reizo | That's the thing. I'm kinda lost when it comes to joining. :o |
20:45:43 | gevaerts | LambdaCalculus37: maybe flashing the rockbox bootloader helps? |
20:46:02 | J0hnnyBr | LambdaCalc: Thanks for your help! ID10T error ;) |
20:46:38 | funman | domonoky: why not checking the defined model ? |
20:46:49 | linuxstb | domonoky: Adding && (CONFIG_CODEC != SWCODEC) would seem OK to me. |
20:46:52 | LambdaCalculus37 | gevaerts: I'm not sure if it'll help. The guy who was attempting the upgrade tried the recovery procedure as documented, and found that the drive wouldn't work whatsoever. |
20:46:58 | funman | there is only 1 with LCD1885 which is not m200v4 no? |
20:47:10 | gevaerts | LambdaCalculus37: yes, but that's using the OF |
20:47:25 | * | domonoky will use the CONFIG_CODEC check, video.c probably also depends on this. |
20:47:37 | linuxstb | funman: No, all the Archos devices have it |
20:47:42 | | Join mc2739 [0] (n=mc2739@rrcs-71-42-246-130.sw.biz.rr.com) |
20:47:42 | linuxstb | (apart from the Player) |
20:47:57 | | Part J0hnnyBr ("Leaving") |
20:48:25 | LambdaCalculus37 | gevaerts: I'm not sure if it'll work in Rockbox, either. If some brave soul is willing to step forward and try it, all the more power to them. |
20:48:42 | * | gevaerts would try, but he doesn't have a MK1231GAL :) |
20:49:35 | * | LambdaCalculus37 doesn't have one, either :) |
20:50:04 | LambdaCalculus37 | Anyone want to buy me a new iPod Classic so I can cannibalize it and take the drive? ;) |
20:50:16 | LambdaCalculus37 | Then we can try this out. |
20:52:41 | rasher | Can anyone give me a good reason why the background logic for the sim isn't reversed? New users are pretty much *always* mystified as to how to control the thing.. experienced user could run it with −−nobackground if it annoys them |
20:53:35 | funman | rasher: nobody did commit a change to this logic |
20:53:42 | kugel | rasher: pf only searches for the first song per album to search album art. Artist might differ though for the tracks, but pf isn't able to show AA on a per-track basis anyway, so I'd just set albumartist |
20:55:29 | Reizo | Question: You guys "specialize" in hacking/modding ipods? |
20:56:43 | | Quit Reizo ("CGI:IRC (EOF)") |
20:57:01 | | Join Reizo [0] (n=4232bff8@gateway/web/cgi-irc/labb.contactor.se/x-15184b3fd54308f2) |
20:57:37 | krazykit | Reizo, not really. rockbox runs on several devices, and ipods are simply one of them |
20:57:48 | | Quit Reizo (Client Quit) |
20:57:53 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
20:58:14 | rasher | kugel: You should check if there's an albumartist set though |
20:59:02 | linuxstb | rasher: Reversing the background logic would get my vote. |
20:59:09 | kugel | rasher: albumartist is always set (per fall back from artist) |
20:59:17 | | Join {phoenix} [0] (n=dirk@p54B450F2.dip.t-dialin.net) |
21:00 |
21:00:33 | rasher | kugel: Ah, alright. |
21:02:54 | funman | pixelma: indeed chopper is much more easy in archos mode ! |
21:03:19 | funman | i think the check should be made on height <= 64, not width |
21:04:10 | | Join Bensawsof [0] (n=Bensawso@5ED09C45.cable.ziggo.nl) |
21:06:11 | | Nick Bensawsof is now known as Bensawsome (n=Bensawso@5ED09C45.cable.ziggo.nl) |
21:08:03 | kugel | rasher: I got it |
21:08:18 | * | domonoky added a more detailed status table on http://www.rockbox.org/twiki/bin/view/Main/SansaV2, other sansa-ams devs should feel free to fill in more details :-) |
21:08:58 | rasher | kugel: the artist? |
21:08:58 | | Join einhirn [0] (i=Miranda@p5B0337AA.dip0.t-ipconnect.de) |
21:09:11 | kugel | rasher: all, I just do get_metadata actually :) |
21:09:35 | rasher | So id3 is fully populated? |
21:09:58 | kugel | rasher: yes |
21:10:09 | rasher | That should be more future-proof also |
21:10:35 | kugel | that doesn't harm though, and makes the fix relatively easy. and yes, it's surely future-proof (with respect to a possible database integration) |
21:10:37 | rasher | kugel: You sould probably open a separate task for that, since it's a bugfix that can go in now |
21:10:42 | | Join freddy__ [0] (n=freddy@p3E9E0D3E.dip0.t-ipconnect.de) |
21:10:48 | | Quit freddy_ (Read error: 110 (Connection timed out)) |
21:10:59 | LambdaCalculus37 | domonoky: Nice! I've got a couple of things to mention on the table. |
21:11:00 | kugel | rasher: uhm, my pf patch fixes 2 other bugs as well, they might be go in too |
21:11:09 | * | LambdaCalculus37 goes to add what he needs to add to the table |
21:11:20 | kugel | (not the features, of course) |
21:11:39 | LambdaCalculus37 | After funman gets done first. :) |
21:11:57 | rasher | kugel: Then you should at the least separate the bugfixes from the features and open a task for those |
21:11:58 | funman | o: |
21:12:15 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ff9ca8c453985daa) |
21:12:16 | rasher | A task for each would be preferable I guess, but if they're small fixes, a fix-em-all patch is fine |
21:12:27 | kugel | rasher: yup, that's exactly like in the last freeze, where the first load of my pictureflow bug fixes was committed :) |
21:13:43 | | Join mc2739_ [0] (n=mc2739@rrcs-71-42-246-130.sw.biz.rr.com) |
21:18:16 | kugel | rasher: "artist.bmp" in /,rockbox/albumart is valid, isn't it? |
21:18:21 | funman | the fuzev2 firmware seems to have the same format than clipv2 |
21:19:32 | rasher | kugel: Nope, that won't get picked up - check out apps/recorder/albumart.c line 154 |
21:19:36 | funman | and the same structure than other firmwares ("AS3525" string) |
21:23:01 | kugel | but artist-album.bmp it seems |
21:23:11 | rasher | Indeed |
21:23:18 | kugel | lets try that |
21:23:34 | rasher | How else would you get the right album art if you have more albums by one artist? |
21:24:05 | kugel | good point |
21:24:53 | funman | do you have a link to a list of the flags in the program status register on ARM ? |
21:25:20 | kugel | funman: http://www.peter-cockerell.net/aalp/html/frames.html |
21:25:39 | kugel | 2nd third of the right side page |
21:26:26 | kugel | uhm, that one should work better: http://www.peter-cockerell.net/aalp/html/ch-2.pdf |
21:26:29 | | Join Aurix_Lexico [0] (n=comrade@68.56.205.239) |
21:27:42 | funman | kugel: thanks! |
21:28:06 | | Quit jhulst (Read error: 113 (No route to host)) |
21:28:10 | kugel | you're welcome :) |
21:28:52 | * | kugel didn't expect a floating point exception in pictureflow |
21:29:29 | rasher | FS #9626 - Reverse simulator background logic - up for discussion |
21:29:51 | pixelma | I would be for reversing too |
21:30:24 | | Quit mc2739 (Read error: 110 (Connection timed out)) |
21:32:03 | * | bluebrother was thinking about adding WASD-style button mappings to the sim for those guys that don't have a num pad |
21:32:21 | rasher | The arrows work |
21:32:39 | rasher | Maybe the number row should just map to the numbers as well? |
21:32:48 | funman | http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0311d/ch02s04s02.html < more detailed |
21:33:18 | | Nick mc2739_ is now known as mc2739 (n=mc2739@rrcs-71-42-246-130.sw.biz.rr.com) |
21:33:41 | gevaerts | rasher: I think reversing the logic is a good idea |
21:34:37 | | Quit kharo1 (Read error: 110 (Connection timed out)) |
21:35:05 | funman | the fuzev2 also use the armv5 BLX instruction, so it suggests and upgrade to the as3525 |
21:35:33 | funman | because i can see what seems access to as3525 registers (same addresses) |
21:36:36 | | Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) |
21:39:45 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
21:40:24 | * | bertrik wonders if we could make the radio screen a little prettier |
21:41:38 | rasher | .wfms! |
21:43:03 | | Quit bmbl ("Woah!") |
21:43:17 | | Join akur [0] (n=akur@bl7-90-128.dsl.telepac.pt) |
21:45:41 | kugel | rasher: Ok, it works. It finds my artist-album in /.rockbox/albumart |
21:46:57 | LambdaCalculus37 | bertrik: It would be a nice idea. |
21:47:34 | rasher | kugel: smashing |
21:47:49 | gevaerts | I think FS #5744 should be rejected. Configuring buttons is a specific NODO, and reversing the behaviour sounds like a bad idea to me |
21:48:42 | bertrik | for example, we could quite easily give a visual indication of the "location on the dial" using a horizontal slider |
21:48:54 | kugel | http://www.rockbox.org/tracker/task/9627 |
21:49:25 | rasher | gevaerts: I agree |
21:50:08 | kugel | gevaerts: I think this one is a special case. And it doesn't really change the functionality of the button imho, rather "what happens when usb is inserted" |
21:51:47 | bluebrother | gevaerts: agreed |
21:52:32 | gevaerts | kugel: I'm not sure how you define "button funtionality" then |
21:52:58 | rasher | kugel: it configures how Rockbox interprets the buttonpress, I'd say that counts |
21:53:05 | * | gevaerts adds a c before anyone notices |
21:53:21 | kugel | well, it changes the behaviour if you don't press that button at all |
21:53:29 | bertrik | you put the fun in functionality |
21:54:47 | kugel | I think button configurability implies that that the you get different results when you press the button _only_. With this one, you don't press the button and still change behavior |
21:55:20 | kugel | and yea, it's annoying imho that you'll need to press select (which leads you to the context menu) in order to NOT reboot |
21:56:10 | rasher | kugel: It's the expected behavior in most cases, for most users though: Attaching cable enables USB connection. |
21:56:48 | rasher | I'd fight a reversal of this logic tooth and nail, since it'd "break" USB in the eyes of a lot of users |
21:57:41 | rasher | kugel: your patch is unclean |
21:57:58 | kugel | rasher: I tend to claim that most rockbox users aren't able to use rockbox usb (ipods and sansas have the biggest user base as per Bagder's statistics) |
21:58:35 | rasher | kugel: I'm not talking about rockbox usb, but about rebooting to the OF that has USB |
21:58:37 | gevaerts | kugel: are you going to do the support for all the people who complain that their ipod doesn't connect? |
21:59:05 | kugel | gevaerts: I didn't vote for reversing it, but I'd surely like to have the option |
21:59:21 | kugel | if the default is kept, no user will complain |
21:59:29 | | Quit LambdaCalculus37 ("mibbit.com: go home time is now") |
21:59:48 | kugel | anyway, if it goes under configurable buttons, then it should probably rejected |
21:59:58 | kugel | rasher: I answered |
22:00 |
22:00:35 | rasher | oh, yuck |
22:00:49 | | Quit funman ("leaving") |
22:02:25 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
22:05:43 | | Quit jhulst (Remote closed the connection) |
22:06:06 | kugel | rasher: Ok, I should've mentioned in the first post (I forgot about it), but don't you agree to what I answered? |
22:06:31 | rasher | Yup, the yuck was at the custom scrollwheel design |
22:06:38 | rasher | define* |
22:07:32 | | Join Zagor [242] (n=bjst@rockbox/developer/Zagor) |
22:09:50 | rasher | I'm unsure if the scrollwheel thing counts as a bugfix |
22:10:00 | rasher | Probably not, really |
22:10:35 | kugel | imho it does... |
22:10:51 | rasher | Where's the bug? Everything works as expected/intended |
22:10:59 | kugel | besides that it's totally safe |
22:12:13 | rasher | It does seem pretty obvious |
22:12:15 | rasher | :\ |
22:12:21 | | Quit Llorean (Read error: 131 (Connection reset by peer)) |
22:13:05 | kugel | rasher: visit the task to get a bugfix only version |
22:13:44 | * | rasher debates a bit back and forth |
22:14:10 | kugel | hehe |
22:14:58 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
22:15:04 | kugel | I don't mind either way. I'm sure that that FS #8335 will get committed some time after the release, and that can contain the scrollwheel stuff |
22:15:05 | gevaerts | bluebrother: is FS #5737 still relevant? |
22:17:10 | * | bluebrother spots an "okok" in the tracker ... |
22:17:33 | | Join jhulst [0] (n=jhulst@unaffiliated/jhulst) |
22:17:39 | bluebrother | gevaerts: yes. I still want to get it updated and committed. |
22:17:48 | gevaerts | ok. I won't touch it then |
22:17:54 | bluebrother | though I'm a bit unsure if the save format is the best idea |
22:18:09 | kugel | bluebrother: Anything against a "okok"? ;) |
22:18:14 | * | gevaerts now looks at rasher with FS #5519 |
22:18:18 | bluebrother | if you have a good idea about it let me know ;-) |
22:18:36 | bluebrother | kugel: shall I call you Casainho? :P |
22:18:53 | rasher | kugel: What about the MAX_PATH+1 change? Most uses of MAX_PATH don't do this.. Though some do. |
22:18:54 | gevaerts | I'm just going through the patch tracker to see if anything can be closed |
22:19:36 | rasher | gevaerts: People claim it takes ages.. I haven't tested it since I first wrote that patch though. |
22:20:08 | bluebrother | I'm planning to try to look into rbutil tasks during my holidays. And give the h100 remote a new shot. Maxim chips arrived :) |
22:21:06 | | Join akur1 [0] (n=akur@bl6-148-62.dsl.telepac.pt) |
22:21:18 | | Quit akur (Read error: 110 (Connection timed out)) |
22:22:00 | Zagor | rasher: I agree with you about simulator background. it should be enabled by default |
22:24:35 | kugel | rasher: it should be +1, for the \0 |
22:25:27 | kugel | else you dont have really max path available, but max path -1 |
22:26:04 | rasher | kugel: And you're sure that's not already included in the value of MAX_PATH? |
22:26:16 | bluebrother | well, does MAX_PATH include the terminating NULL? IIRC POSIX was unclear about that. |
22:27:11 | * | rasher is going to leave that in - won't do any harm |
22:27:16 | kugel | rasher: max path is max path, it's a convention to not include the \0 in that symbol, from what I've heard |
22:27:52 | Zagor | re #5744, how does car adapter mode work with usb-powered targets? |
22:27:57 | rasher | MAX_PATH doesn't consider multi-byte characters anyway, so it's already awfully broken |
22:29:16 | kugel | true |
22:30:08 | gevaerts | Zagor: no idea. As far as I know there is no car mode related code near the place where the button is checked in usb.c |
22:31:43 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
22:33:59 | kugel | bluebrother: don't! :) |
22:37:09 | *** | Saving seen data "./dancer.seen" |
22:40:52 | | Join Chronon [0] (n=chatzill@d23-217.uoregon.edu) |
22:43:23 | Chronon | I notice that there are a number of dead entries on the TWikiUsersGroup page. Are there any objections to me removing them? |
22:45:05 | bluebrother | ok ... http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266 -> a filename is up to MAX_PATH including the terminating NULL. The Filename entry instead says "1 to {NAME_MAX} bytes used to name a file" and doesn't mention the NULL at all |
22:45:29 | Zagor | Chronon: go ahead. I did a rather big cleanup a few weeks back and never got around to clean that page |
22:45:45 | Chronon | editing. .. |
22:47:14 | rasher | bluebrother: I'd say that MAX_PATH most likely *should* include the terminating NULL. If nothing else, then to avoid trouble. |
22:47:24 | | Quit massiveH ("Leaving") |
22:48:00 | bluebrother | rasher: yep. My point was just that the standard itself is unclear about it :) |
22:48:02 | * | amiconn returns, and sees LambdaCalculus pinged him... |
22:48:16 | | Quit bmbl ("Woah!") |
22:48:40 | gevaerts | What should we do with FS #8266? |
22:49:00 | rasher | bluebrother: It also seems more likely that the standard things the NULL should be included, since it specifically says that once, and just omits mention the other time |
22:49:14 | kugel | well, if you do sizeof(MAX_PATH) to know how much chars you can use for your filename, then you should get it (what you see is what you get, anyone?). And not that, effectively reduced by 1 imo |
22:49:56 | bluebrother | rasher: well, I bet there are other places where it explicitly tells it does not include NULL. |
22:49:57 | | Quit {phoenix} (Remote closed the connection) |
22:50:00 | kugel | Also, I've seen +1 more in the rockbox source, especially in the settings |
22:50:10 | bluebrother | MAX_PATH is a macro, so sizeof(MAX_PATH) doesn't make sense |
22:50:12 | gevaerts | kugel: sizeof(MAX_PATH) is going to be 4 or 8 ;) |
22:50:15 | Zagor | kugel: string variables always have room for a terminating null. that is not unexpected behaviour. |
22:51:02 | kugel | gevaerts, bluebrother: ok, "imagine you could do sizeof() on MAX_PATH" |
22:51:23 | bluebrother | kugel: you can do it ... it just doesn't yield what you want it to do ;) |
22:51:28 | | Join tessarakt [0] (n=jens@e180077210.adsl.alicedsl.de) |
22:51:56 | | Quit XavierGr (Read error: 110 (Connection timed out)) |
22:52:08 | | Quit mc2739 () |
22:52:09 | kugel | whatever |
22:52:30 | bluebrother | whenever |
22:52:31 | kugel | that makes me wonder how it's defined |
22:52:39 | bluebrother | whereever |
22:52:41 | rasher | #define MAX_PATH 260 |
22:52:46 | bluebrother | *la la la* |
22:53:09 | rasher | amiconn: Your take on the MAX_PATH thing? |
22:53:12 | kugel | bluebrother: singing shakira is strictly off-topic :) |
22:53:45 | Zagor | rasher: can I get a quick recap of the issue? are you wondering if variables should be declared with or without +1? |
22:53:46 | kugel | rasher: oh, thanks for that info |
22:54:16 | kugel | Zagor: yep, that's what we all wonder and discuss |
22:54:18 | rasher | Zagor: Pretty much. Also, how we handle multi-byte characters |
22:54:46 | CaptainKwel | Hi - so aside from the codec buffer, is there any substantial block of memory a codec can exploit to use for some internal memory stuff? |
22:55:25 | bluebrother | hmm, according to limits.h definitions it does include NULL. Oh my. |
22:55:41 | | Quit petur ("*plop*") |
22:55:44 | bluebrother | kugel: you sure it's Shakira? |
22:55:57 | Zagor | I definitely think MAX_PATH includes \0 |
22:55:58 | kugel | not anymore ;) |
22:56:02 | bluebrother | http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html |
22:56:56 | kugel | good that PATH_MAX != MAX_PATH, else I would've been proven wrong :D |
22:57:25 | * | kugel hides |
22:57:27 | * | bluebrother now listens to a track called "La La La" brought by last.fm player ... |
22:57:54 | Zagor | snprintf takes the size including 0, for example |
22:58:43 | kugel | I see, I see, I should renew my C references as soon as possible |
23:00 |
23:00:15 | rasher | I wonder how things would look if we did MAX_PATH = 780 (iirc, characters can be up to 3 bytes?) |
23:00:29 | kugel | Zagor: and how about MAX_FILENAME? It's been used with +1 in settings.h |
23:01:15 | | Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ad6d28c611411c11) |
23:01:24 | Zagor | same thing, in my opinion. declaring buffers string[MAX_SIZE+1] is ugly |
23:02:07 | | Join EspeonEefi [0] (i=eefi@STRATTON-SIX-FOURTY-SIX.MIT.EDU) |
23:02:44 | rasher | For this reason alone, I think the MAX_* defines should include the \0 |
23:04:02 | | Quit itcheg (Client Quit) |
23:08:42 | amiconn | rasher: Things would most probably crash very often |
23:09:01 | | Quit Zagor ("Leaving") |
23:09:20 | amiconn | And UTF-8 chars can be more than 3 bytes (but only for chars outside the unicode bmp) |
23:09:38 | rasher | amiconn: Why's that? |
23:10:05 | amiconn | Many buffers for that kind of stuff are allocated on teh stack |
23:10:38 | ender` | utf-8 characters are allowed to be up to 4 bytes (though originally 6 were allowed) |
23:11:46 | rasher | I think restricting to the BMP is acceptable. But I can see how allocating the better part of a KiB on the stack (often several times, I'll bet) would be problematic |
23:12:52 | amiconn | .bdf doesn't support extended unicode anyway |
23:13:00 | | Quit akur1 (Read error: 60 (Operation timed out)) |
23:15:17 | rasher | I think we can safely declare anything past the BMP "the boonies", and refuse to support it |
23:16:42 | rasher | Still, it seems a bit wrong that we potentially have a limit on MAX_PATH of less than 90 characters. |
23:17:48 | amiconn | Iirc the fat driver switches to using shortnames if the longname doesn't fit |
23:18:10 | rasher | Ah right, the shortname! A lucky escape for FAT32 there |
23:18:33 | | Quit freddy__ (Remote closed the connection) |
23:21:13 | amiconn | We might be better off using UTF-16 for pathnames internally. |
23:22:00 | * | rasher would think UCS-2 instead? |
23:22:40 | rasher | Avoid all the surrogate pair stuff, since we don't support that anyway |
23:23:43 | | Join MethoS- [0] (n=clemens@host-091-097-240-161.ewe-ip-backbone.de) |
23:27:01 | | Join BenCrinion [0] (n=5ec0f2a2@gateway/web/cgi-irc/labb.contactor.se/x-bc8cee4a6d55f1b5) |
23:27:29 | BenCrinion | hi |
23:27:42 | BenCrinion | hi, did that show? |
23:28:21 | gevaerts | BenCrinion: yes |
23:28:28 | | Quit karashata ("G'bye everyone!") |
23:29:57 | | Join akur [0] (n=akur@bl7-118-99.dsl.telepac.pt) |
23:30:04 | | Quit BenCrinion (Client Quit) |
23:30:27 | | Part akur |
23:39:36 | | Join BenCrinion [0] (n=BenCrini@94-192-242-162.zone6.bethere.co.uk) |
23:39:58 | | Join sajes [0] (n=sajes@66.82.244.88) |
23:40:06 | BenCrinion | hi, is there anybody out there |
23:40:13 | bluebrother | no, only bots in here |
23:40:23 | BenCrinion | nobots |
23:40:29 | bluebrother | and those are in, not out |
23:40:45 | bluebrother | hi, I'm Eliza. Please tell me your problem. |
23:40:53 | BenCrinion | so, is there any chance of getting rockbox help in here? |
23:40:58 | Bagder | BenCrinion: fire away your prob! |
23:40:59 | BenCrinion | i installed the latest version |
23:41:09 | BenCrinion | onto an olympus mrobe |
23:41:16 | BenCrinion | and it works, but i get no sound |
23:41:24 | bluebrother | Interesting. How do you feel about olympus mrobe? |
23:41:36 | * | gevaerts hits bluebrother over the head |
23:41:42 | gevaerts | BenCrinion: let me try on mine |
23:41:44 | BenCrinion | it looks like its playing, i can fast forward, upload |
23:41:52 | pixelma | mrobe100? |
23:41:55 | BenCrinion | yes |
23:42:09 | BenCrinion | i liked the mrobe until i broke it by deleting some files |
23:42:16 | bluebrother | Have you feeled upload before? |
23:42:18 | BenCrinion | and now i dont like it any more, cos its broke |
23:42:28 | BenCrinion | feeled upload? |
23:42:46 | gevaerts | BenCrinion: ignore bluebrother. He seems to be in a not very helpful mood today :) |
23:42:49 | pixelma | /ignore bluebrother ;) |
23:42:54 | bluebrother | BenCrinion: ignore me. I'm playing Eliza |
23:43:05 | BenCrinion | its fine |
23:43:58 | bluebrother | so, what kind of files did you delete? Have you chkdsk'ed the player? |
23:44:23 | BenCrinion | i reformated the player, then rehooked it up to the mtrip |
23:44:31 | BenCrinion | i havent chkdsked it |
23:44:38 | BenCrinion | im confident that its fine |
23:44:49 | BenCrinion | it was playing ok with mrobes firmware yesterday |
23:44:59 | bluebrother | hmm. Well, if you reformatted it there shouldn't be issues with crosslinked files |
23:45:06 | gevaerts | It's a bug |
23:45:15 | bluebrother | does the m:robe firmware play fine today? |
23:45:20 | gevaerts | I don't get any sound either with the latest build |
23:45:34 | gevaerts | BenCrinion: did you use Rockbox Utility to install? |
23:45:42 | BenCrinion | no, it didnt work |
23:45:48 | * | bluebrother hasn't tried the m:robe for a while |
23:45:50 | BenCrinion | something about cannot find firmware |
23:46:07 | * | jhMikeS did broke it? (somehow) |
23:46:09 | BenCrinion | maybe cos the original files were missing |
23:46:11 | gevaerts | OK, just checking what I should say next :) |
23:46:13 | bluebrother | let me guess ... the original firmware file wasn't present? |
23:46:21 | BenCrinion | probably |
23:46:25 | BenCrinion | cos i formatted it |
23:46:39 | gevaerts | BenCrinion: did you install the current build, or 3.0? |
23:46:54 | BenCrinion | 3.0 |
23:47:01 | BenCrinion | i think anyway |
23:47:06 | bluebrother | well, that file is required as otherwise it can't make booting the OF (and thus disk mode) work |
23:47:09 | BenCrinion | the link from the releases page |
23:47:39 | gevaerts | Just to check, can you go to the System menu and select Rockbox info? |
23:47:43 | BenCrinion | it boots fine |
23:47:59 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111319]") |
23:47:59 | * | gevaerts has sound now... |
23:48:08 | BenCrinion | 3.0-08923 |
23:48:15 | jhMikeS | gevaerts: what was the problem? |
23:48:15 | gevaerts | That's 3.0, yes |
23:48:17 | | Join kugel [0] (n=chatzill@unaffiliated/kugel) |
23:48:25 | gevaerts | I rebooted |
23:48:41 | | Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") |
23:48:44 | BenCrinion | rebooted the mrobe? |
23:48:48 | BenCrinion | with the rest button? |
23:48:53 | | Quit jgarvey ("Leaving") |
23:49:02 | bluebrother | that's not reboot, that's reset |
23:49:27 | gevaerts | Actually the current build froze on the USB screen, so I held power for a while to reset it |
23:50:32 | BenCrinion | got sound |
23:50:38 | BenCrinion | what the F? |
23:50:45 | gevaerts | Good question... |
23:50:45 | BenCrinion | im sure i turned it off already |
23:51:08 | gevaerts | There must be a bug that makes sound break now and then |
23:51:28 | * | jhMikeS sees something in wm8751.c that should be corrected anyhow |
23:51:32 | BenCrinion | if it makes any difference i just activated the database whatever that means |
23:52:18 | BenCrinion | this is really good guys, great job |
23:52:26 | gevaerts | can you try something? |
23:52:57 | gevaerts | If you connect it to USB, so it switches to the OF disk mode, and then disconnect and reboot to rockbox, do you have sound? |
23:53:38 | gevaerts | I seem to have sound on cold boot and on reboot from rockbox, but not on reboot from diskmode |
23:53:51 | BenCrinion | whats OF disk mode? |
23:54:06 | BenCrinion | i take it thats where it mounts as a hd? |
23:54:06 | gevaerts | Yes |
23:54:23 | gevaerts | OF stands for Original Firmware. Rockbox doesn't have its own USB code yet, so it uses that |
23:54:38 | * | gevaerts submits a bug report |
23:55:09 | BenCrinion | ive still got sound |
23:55:35 | bertrik | kugel, have you experimented yet with the i2c thing, maybe it could be some kind of I/O expander thingy that is involved in button reading |
23:56:10 | kugel | bertrik: I gave funmans patch a quick test, without success though |
23:56:27 | bertrik | what patch? |
23:56:28 | kugel | the read returns -4, and button passed to it doesn't change |
23:57:10 | kugel | bertrik: http://paste.ubuntu.com/83975/ |
23:57:45 | gevaerts | It seems to be a bit more complicated than that. Anyway, rebooting helps so it's not too bad |
23:57:47 | | Join helpo [0] (i=4b3a331d@gateway/web/ajax/mibbit.com/x-427ce2277bb8d95e) |
23:57:52 | helpo | hello |
23:58:09 | BenCrinion | right guys im off, thanks for your help |
23:58:09 | helpo | i have a sansa sandish e260R |
23:58:23 | helpo | i am not sure how to install it |
23:58:26 | | Part BenCrinion |
23:58:39 | helpo | it has wierd instructions, can anyone help? |