--- Log for 12.12.108 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 3 days and 15 hours ago 00.00.07 # * gevaerts hears some weird artefacts while playing mp3 on the clip 00.00.46 # Like a short bit of audio repeating every now and then 00.01.23 # gevaerts: which build is that? 00.02.09 # Zagor: clean svn, with tagcache, quickscreen and pitchscreen disabled 00.03.02 # interesting. my mp3 artefact is that it is skipping over small parts (perhaps 50-100ms) every second or so 00.03.08 # and of course that it crashes :) 00.03.53 # gevaerts: perhaps the pcmbuffer isnt updated correctly then 00.04.59 # I'm having trouble fitting a c200 build in 2MB... 00.05.26 # 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 # I have only tested with 44kHz ones 00.07.00 # 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 # 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 # 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 # 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 # You need to optimize more! 00.23.32 # 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 # ahh, it's my fault. ram.link does not depend on config.h 00.24.31 # 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 # 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 # it has a huge iram 00.28.17 # funman: Regarding the Clip, and how mine isn't playing back. 00.28.26 # It wasn't really "crashing" 00.28.47 # 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 # funman: As a clue, the "View buffering thread" says "alloc: 1832/ 29(something offscreen)" 00.30.07 # Could it still be trying to buffer 32mb for some reason? 00.30.12 Quit BigBambi ("Please insert girder") 00.32.03 # Llorean: how much buffer do you have? 00.32.06 # 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 # Zagor: Is there another screen to check, it's offscreen and won't scroll on this one 00.32.48 # There's a bunch of extra spacing. 00.33.25 # Llorean: "Rockbox info" show the buffer size 00.33.32 # Zagor: Buffer: 593kb 00.33.40 Quit moos ("Rockbox rules the DAP world") 00.33.42 # So that 29 at the start of it is definitely indicating *something* wrong 00.33.54 # Llorean: right, that's too small. I got the same symptoms as you with that buffer size. 00.34.11 # Llorean: you got a point there .. 00.34.20 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 00.35.01 # and the same symtom on c200 compiled for 2MB! 00.35.46 # haha. "Buffer: 45KB" 00.36.00 # it needs a diet 00.36.35 # 45 feels a bit on the tiny side ;-) 00.36.42 *** Saving seen data "./dancer.seen" 00.36.46 # just a bit 00.38.09 # Zagor: hum, what if you enable the check in playback.c for pcmbuf_init() return value ? 00.38.27 # Zagor: Out of curiosity, does yours show the right value in the debug->view buffering thread screen? 00.41.47 # refreshing database... 00.42.05 # 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 # funman: yeah then I get panic. 578688 > 306720 00.44.14 # try to enlarge the RAM by a few hundreds of kilobytes then 00.44.28 # I understand that 306720 is the audiobuffer size 00.45.03 # that's audiobufend - filebuf 00.46.23 Quit akur (Read error: 110 (Connection timed out)) 00.48.18 # filebuf is defined by buffering.c ? 00.49.54 # 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 # 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.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 # 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 # usefl: stopped at -1684852 right now... 01.07.42 # 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 # flash targets should save settings more often 01.13.29 Join akur [0] (n=akur@bl6-146-241.dsl.telepac.pt) 01.17.44 # or more flash wear? 01.17.51 # s/or/for 01.18.11 # yeah, because that is a real problem with flash players... 01.18.55 # rather, they don't need to delay updating the config file. 01.19.08 # you never know 01.19.19 Quit jhMikeS (Nick collision from services.) 01.19.22 # 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 # 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 # flash wear is only a problem when you write physical prom sectors yourself. all consumer flash media does wear leveling. 01.22.38 # 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 # PaulJam: probably just out-of-date. 01.23.48 # 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 # reminds me of a problem I have with the scaling and wanted to ask Unhelpful about... 01.24.51 # well, i'm going to try it out, but i won't be able to update the wiki. 01.24.54 # you have great timing, i just got back ;) 01.25.16 # PaulJam: no problem. I'll do it after you told me the result 01.25.22 # ok 01.25.28 Part akur 01.26.31 # 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 # Unhelpful: i was mainly referring to the "Bigger bitmaps are cropped to 100x100." part 01.27.31 # no, that doesn't happen anymore, or shouldn't, anyway. 01.28.21 # 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 # 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 # other WPS where they fit they are displayed 01.29.47 # kugel: Why would it be a bad idea? 01.30.08 # I've looked a bit into the code 01.31.15 # 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 # 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 # 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 # tagcache loads the appropriate files (database*.idx) based on the format tagnavi passes to it 01.32.16 # Unhelpful: thanks :) 01.32.20 # it takes the data and does both, display and sorting, out of it 01.32.51 # 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 # now if we want to sort and display different data, we need to load both files into ram. 01.33.02 # 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 # You need to load both files, but you need to load multiple files for more complex filters too, don't you? 01.34.01 # and, of course, introduce special cases for the sorting tags 01.34.39 # 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 # 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 # kugel: If no file has sortartist tags, don't generate the sortartist .idx file, and use only the one? 01.35.47 # 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 # The whole point of sorting tags is that they're not *supposed* to be displayed. 01.36.33 # 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 # do you think generating a idx dependant on all your music files is a good idea? 01.37.02 # 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 # it's still displayed in the wps. It's only about the database browser 01.37.14 # kugel: Which is what people are complaining about... 01.37.48 # They want it to show "The Beetles" in the list, but have it listed in the B section. 01.37.50 # the ram usage will baiscally double just for displaying "the"'s and "a"'s 01.38.11 # And the doubled RAM usage won't affect people who don't use the database. 01.39.23 # what if the sortartist index is only populated with files where it differs from the artist tag? 01.40.31 # well, then you still need to check the sortartist idx file regulary. And that's even more complicated to implement 01.41.10 # 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 # 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 # So it probably won't go in at all if some way isn't found, I suspect. 01.41.42 # yea, I understand that 01.42.02 # And I don't think more RAM usage is a big deal for most people who use database. 01.42.09 # Since those people can save a lot of RAM just by not using it at all. 01.42.33 # well, you can discuss if that's a display issue. Thinking of a record shop... I often see "Beatles, The" there 01.43.16 # 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 # 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 # ...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 # Unhelpful: Most configuration of database behaviour is actually handled by the tagnavi.config file. 01.46.47 # 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 # So you still get "if they wish to use both tags, it takes more RAM" 01.47.08 # 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 # And if they just wish to use one tag, there's no need for an option. 01.47.42 # 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 # 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 # 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 # PaulJam: are those dimensions the ones of the current WPS? 01.48.31 # Unhelpful: no 01.48.32 # Unhelpful: I think it should be 'transparent', if they've included sort tags, they want to use them. 01.48.46 # ...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 # pixelma: just so it's not done how the karma did "library sort", and put "Die Happy!" under H 01.49.33 # 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 # exactly, the search is for ..bmp and then .bmp 01.50.31 Quit robin0800 (Read error: 60 (Operation timed out)) 01.50.46 # Llorean: true, maybe this should be mentioned on the wiki (if it isn't already) 01.51.02 # it can't reasonably search for each variation that might exist without loading the whole directory and pattern-matching the filenames 01.51.04 # PaulJam: Are we supposed to post somewhere "Yeah, the information already up is still correct" or what? 01.51.16 # 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 # pixelma: you wouldn't have a link to a 100x100 AA WPS for m5, would you? 01.52.36 # 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 # 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 # 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 # ... it's horribly broken even w/ 50x50 file and cabbiev2 :/ 01.54.33 # cabbiev2 uses 64x64 as AA size on those displays, just looked 01.54.39 # the sort comparer can use a global, or global_status to do it 01.54.46 # like the comparer for the file tree 01.55.01 # ah yea, those globals, right :) 01.55.12 # pixelma: right, it looks like upscaling 50x50->64x64 corrupts the image :/ 01.55.52 # 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 # 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 # ok, so I don't need to put my WPS up somewhere... good as it's still work in progress 01.57.20 # sounds like fun 01.57.32 Join darknessxsurroun [0] (n=04f4b7bd@gateway/web/cgi-irc/labb.contactor.se/x-351d3c64c0dd6c1b) 01.57.34 # :D 01.57.49 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 01.57.54 # hello. 01.57.56 # kugel: Probably why there's not a patch for it that's under any discussion for commit yet. :) 01.58.06 # It's one of those 'big' projects. 01.58.10 # 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 # kugel: or rework database internally so it needs less work for this... 01.59.12 # 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 # 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 # darknessxsurroun: This doesn't really sound like a Rockbox question. 01.59.49 # What are you trying to do, exactly? 02.00.14 # well i want to replace the firmware with a rockbox made one 02.00.25 # sorry if i'm not explaining right 02.00.38 # * kugel didn't know SA30XX is a supported target :o 02.00.58 # its not supported? 02.01.02 # oh, it isn't 02.01.07 Quit XxJoshXx ("CGI:IRC (Ping timeout)") 02.01.09 # darknessxsurroun: The list of supported players is on the front page. 02.01.16 # darknessxsurroun: No, the front page clearly tells which targets are supported 02.01.34 # 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 # 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 # oh, cause the default firmware for the mp3 player is dead slow, and i was looking for a replacement 02.03.02 # by means. the browsing is slow on the mp3> searching or scrolling for songs is slow.... 02.03.18 # 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 # 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 # Unhelpful: one last question: are there any restrictions on the size of the cover.bmp? 02.11.02 # 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 # thanks 02.12.04 # 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.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 # 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 # one change at a time... 03.27.09 # 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.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 # hey all 04.32.04 # I'm having an issue with my Flyspray account, but Zagor is not online? 04.33.15 # 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.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 # 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 # Maybe leave a comment on it that you can't reproduce. 05.24.42 # 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 # maybe bug some H3x0 users to try to reproduce, but it seems unlikely this would be target-specific 05.28.16 # 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 # 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 # 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 # 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.04.13 Quit Aurix_Lexico (Read error: 110 (Connection timed out)) 06.04.52 # 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 # I still have a problem with the install on an ipod 5.5 80 gb with a samsung hd 06.51.09 # 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 # I still have the same error, panic error sector 4096 or something like this 06.51.57 # anbody has an idea ? 06.59.28 Join Darksair [0] (n=user@58.192.37.151) 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 # hi Rockbox. I've an ipodish question. 07.09.01 # most of the time wheel response is kind of sluggish. 07.09.24 # ...except when music is currently playing. then it seems a lot more responsive 07.09.29 # (most of the time) 07.10.06 # 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 # slact: This is normal behaviour. 07.12.53 # : ( 07.13.03 # 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 # ah 07.13.25 # This improves battery life quite a bit. 07.13.52 # i see. that explains why it unsluggishes during disk activity, too 07.15.00 # 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 # Everything is slower, and the music has higher priority than the user interface. 07.15.57 Quit Darksair` (Connection timed out) 07.16.46 # now you're making me want to go code-digging. 07.17.19 # ... 'cause now i naively think it might be a good idea to speed up the cpu when it detects keypresses 07.17.36 # There's a patch to do that in the tracker already, I think 07.17.41 # I couldn't tell you which task it is. 07.17.49 # 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 # http://www.rockbox.org/tracker/task/8142 07.18.41 # is that it? 'cause that's nbot really what i'm talking about 07.18.59 # That's not a patch. 07.19.19 # this is the one: http://www.rockbox.org/tracker/task/8668 07.19.30 # boost CPU for 1s after each button press 07.19.46 Quit Darksair (Connection timed out) 07.20.06 # ah, http://www.rockbox.org/tracker/task/8668 07.20.19 # thanks, unhelpful. 07.20.44 # 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 # 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 # yep. 07.24.12 # guess i'll want to dig through the rockbox code after all 07.25.04 # 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 # 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.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 # 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 # 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 # 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 # 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 # 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 # 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 # Unhelpful: Using an unsigned '1' (1u) makes gcc switch to __lsrshi3 (logical right shift by n) 08.31.10 # ~30kB saved on binsize, same on RAM usage 08.31.41 # amiconn: but, bitwise operations are sign-agnostic? :/ 08.31.50 # amiconn: it works with the first change 08.32.52 # 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 # 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 # Unhelpful: Shifts are not. 08.34.45 Join Rob2222 [0] (n=Miranda@p4FDCD0D8.dip.t-dialin.net) 08.36.02 # 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 # ' for testing is signed. 08.36.49 *** Saving seen data "./dancer.seen" 08.37.00 # 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 # It's just 1 ==> 1u 08.39.33 # amiconn: it is working 08.40.23 # yay 08.40.49 # 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 # Should be a little faster for small sectors. If you have the time, run test_disk with both core variants 08.42.04 # (@ toffe82) 08.42.49 # :) 08.44.22 # 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 # amiconn: where is test_disk ? 08.46.40 # toffe82: it's another thing you'll have to enable in the build manually 08.46.53 # :) 08.47.01 Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-db5b0e910c71c4f0) 08.47.13 # I will do it another day , time to sleep 08.47.23 # 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 # edit apps/plugins/SOURCES (like old Makefile I think) 08.48.44 # 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 # 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 # Hmm, the Player seems to use __ashrsi3 somewhere else as well 08.56.23 Quit bertrik ("Leaving") 08.57.20 # I wonder why playback.c define target specific CODEC_IRAM_(ORIGIN,SIZE) and doesn't use them .. 08.58.18 # 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.11 # amiconn: odd, that's the only place outside of plugins i remember seeing it.. :/ 09.01.35 # 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 # rechecked, i still only see it in firmware/drivers/ata.o :/ 09.05.12 # 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 # Or would that hit performance? 09.05.57 # pondlife: I understand that the right shift when using "& (1 << x)" 09.06.25 # i.e. it transforms to "( .. >> x) & 1" 09.07.10 # All aimconn did was specify that 1 was unsigned 09.07.21 # http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/ata.c?r1=19398;r2=19399;pathrev=19399 09.07.53 # Saved quite some SH1 binsize 09.07.59 # 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 # because SH1 has no right shift so it uses a gcc function instead, i think other targets do have right shift? 09.08.27 # Of course it might (a) not help other architectures or (b) hurt performance in the general case... 09.08.28 # pondlife: On coldfire and arm it doesn't matter at all 09.08.41 # OK, that was the answer I was after 09.09.01 # SH1 has no variable shift instructions, only fixed ones, so variable shifts are subroutines on it 09.09.44 # But even with those subroutines, logical shifts are a little better, because the subroutines for variable logical shifts are faster 09.10.35 # 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 # 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 # Yes there is - __lshrsi3 09.11.45 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.12.01 # 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 # well or already fixed 09.13.08 # 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 # 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 # 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 # 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 # yay, macro-ized version of at least GET_FB_WIDTH works 09.15.57 Quit Darksair (Connection timed out) 09.17.03 # 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 # It uses and #1, r0; tst r0, r0 instead of reducing that to tst #1, r0 09.19.06 # Unhelpful: ah works... and scrolling works again too :) 09.19.17 # pixelma: i doubt i fixed *that* 09.20.09 # ('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 # 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 # i only tested with "extreme" upscaling, which makes it very obvious that it's working, because, HUGE GREY BLOCKS. :D 09.25.11 # rockblocks? 09.25.19 # * pixelma runs away 09.27.22 # 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 # 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 # I noticed the audiobuffer is a bit below 1MB with tagcache enabled 09.28.00 # funman: are you still using the direct-from-flash patch? 09.28.14 # ah, "with SVN". 09.28.36 Quit JdGordon (Remote closed the connection) 09.28.44 # no, I'm not using it because I want to reproduce problems, not avoid them ;o) 09.29.04 # 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 # 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 # kugel: and did disabling tagcache help ? what's the size of audiobuffer ? (look in rockbox.map) 09.30.11 # Unhelpful: how can you get the svn revision on 'git that's not git-svn' ? 09.31.12 # funman: no clue how, since git doesn't do keyword subs, either... 09.32.11 # then it will work but report revision0 (like on a modified git tree) 09.32.22 # funman: with svn (only my lcd fixes applied) audiobuf is 0x54DFCC (5 562316) 09.32.41 # perhaps the trick should be to use git log and grep magic as well to get the rev 09.32.48 # kugel: hm can you paste your map? 09.33.13 # 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 # http://pastebin.ca/1283402 09.34.03 # huge* 09.34.15 # Unhelpful: yes it has, but it's just a bit harder to extract than using git svn info 09.34.43 # Zagor: disabling tagcache highers filebuflen from ~28k to ~256k and indeed there is working playback 09.35.09 # yup 09.35.37 # now I check the buffering thread stats and wait for a crash ! :) 09.36.00 # Unhelpful: git-svn-id: svn://svn.rockbox.org/rockbox/trunk@19399 09.36.39 # funman: For me, I never had tagcache enabled in the first place, and didn't have working playback. 09.36.41 # that's what git log says on the server at least 09.36.45 # would git log + grep be faster or slow in general than using git-svn, i wonder? 09.37.08 # 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 # Llorean: did you check audiobuffer and filebuffer sizes? 09.37.27 # Unhelpful: not important ;) 09.38.12 # funman: that'll be tricky, if we don't import some form of .gitignore info into the actual svn repo... :/ 09.38.21 # also, i volunteered? ;) 09.38.32 # funman: What values do you refer to, on what screen? Do you mean the PCM and compressed buffers? 09.39.21 # Unhelpful: i can do that if you want 09.39.58 # 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 # funman: There's not a value on that screen called "filebuff" 09.41.07 # Llorean: alloc and usefl 09.41.30 # funman: well, what could be the reason the issue is also apparent on fuze? 09.41.44 # i had to edit debug_menu.c to make the values fit on screen 09.41.46 # 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 # kugel: no clue 09.42.00 # filebuflen is 284KB for me and playback works 09.42.01 # funman: i'll take a look, but i need get my current work commitable and switch to another branch first. 09.42.06 # well, starts 09.42.14 # Llorean: the important is how many digits they have :/ it could be 29k or 290k 09.42.54 # funman: well you see that from the left-side value. if that has six digits, so does the right-side 09.42.57 # Llorean: i removed the 08 from the format specifier, and used 4/5 chars for the description 09.43.55 # Zagor: do you have change directory enabled? 09.44.09 # 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 # funman: no 09.44.47 # like, instantly ? or does fail after having dropped until ~67k? 09.45.10 # "instantly". I can't tell which happens first. 09.45.34 # funman: Well, if Zagor's right, it's four digits. so 29XX 09.45.36 # I see arough 10kB per second decrease 09.45.56 # Llorean: definitely too low, I hadn't playback working with 29kb 09.46.06 # 2.9KB rather? 09.46.11 # no 09.46.27 # 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 # Unhelpful: cut? 09.46.51 # funman: I'm confused. The value is not in Bytes? 09.47.06 # 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 # 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 # Zagor: Different watermarks, I'd guess 09.47.35 # 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 # 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 # grep -o only keeps the matching regex 09.48.46 # It's a thing I am complaining about almost since the beginning of swcodec playback... 09.48.52 # funman: Why would mine be so low with a clean SVN build and default settings? 09.48.55 # now mp3 changed, and decresed 16KB/sec as expected 09.49.10 # lots of funny symptoms... 09.49.10 # 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 # Llorean: I have no clue, i only begin to read that code ^^ 09.49.19 # debug_menu.c 09.49.27 # Since it's not even filling completely 09.49.39 # Neither the PCM buffer nor the compressed buffers fill. 09.49.53 # funman: Also, for audiobuff, to I just subtract audiobuff_end from audiobuff in the map and give you that? 09.50.15 # 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 # Llorean: yes 09.50.35 # Llorean: yep, just to check if >1MB gives playback while <1 doesn't 09.51.19 # 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 # funman: what info you need? I told you the audiobuf size before 09.51.53 # got it: git log | sed -nre '/git-svn-id/ s|.*@([0-9]+) .*|\1|p' | head -n 1 09.52.06 # what is data_rem? it shows a bit over 6MB here! 09.52.09 # kugel: yeah; and I read 500kB, no 5.5MB .. so i wanted to check what was wrong 09.52.10 # funman: 990,352 in dec 09.52.18 # Zagor: data remaining to read in the file 09.52.24 # ah 09.52.26 # funman: no, it's 5,5MB 09.53.01 # 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 # funman: 5 562316 (there's a space after the first 5, maybe the number got split at your screen) 09.53.32 # no it wasn't split but i overlooked the first 5, sorry for that 09.53.35 # 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 # Unhelpful: how does that work on osx (i mean without gnu sed) ? 09.54.28 # funman: Ah, it is 29k, not 2.9k on mine, btw. Just double checked 09.54.35 # that would be bsd sed? i don't know which options work with it... 09.54.57 # Llorean: and did you have disabled tagcache intentionally ? 09.55.16 # Unhelpful: mentioned in posix spec, i'll check that 09.55.37 # 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 # funman: I never enabled it to begin with 09.56.20 # funman: found the mac os x sed man page online, it needs -E for the -r, otherwise we should be good. 09.56.27 # Unhelpful: uyup 09.56.58 # Llorean: it's enabled by default since r19382 09.57.34 # i can't find this svnversion.sh, though, that the revlog says does the work 09.57.34 # pcm buffer seems a bit overkilled. it uses ~50 of its' 500 KB. 09.57.45 # nevermind, i was in my build dir :/ 09.57.51 # Unhelpful: in tools/ 09.58.19 # now I get a full mp3 playback, without skips 09.58.31 # how frustrating :-) 09.58.41 # Zagor: how ?! 09.58.54 # luck. I haven't changed anything. 09.58.59 # ah ;) 09.59.05 # funman: I thought you meant "enabled" as in "turned on", not "included" 09.59.19 # As I said before, an unmodified SVN build 09.59.28 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 09.59.30 # Llorean: sorry for the confusion 09.59.42 # I'm compiling one without a plugin buffer now. 10.00.10 # Or rather, a quite small one 10.00.17 # funman: if sed -r &>/dev/null ;, i guess? i don't have an osx around to test. 10.00.21 # not building tagcache is faster ;) 10.01.00 # Unhelpful: that's probably the right test (with a correct expression because gnu sed -r returns 4 here) 10.01.11 # echo | sed of course. 10.01.38 # funman: I'll do it that way then. 10.01.52 # just comment out HAVE_TAGCACHE in config-clip.h 10.02.22 # What is "audiobuff" then if it's not the PCM buffer and it's not the compressed audio buffer? 10.02.26 # does &> work in whatever shell osx uses? 10.02.44 # furthermore, is there a /dev/null? :/ 10.02.50 # Llorean: audiobuffer is used for voice, compressed audio, pcm, and probably more things 10.03.10 # it's just the RAM available which isn't used by rockbox, plugins, or codecs 10.03.25 # Ah, that reminds me 10.03.29 # Unhelpful: yes.. it's a bsd ;) 10.03.42 # 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 # amiconn: Swap with playback rather than in parallel? 10.04.29 # 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 # This makes voice unavailable during playback, but might be the only way to make it work 10.04.59 # good idea 10.05.36 # funman: Alright, playback works (briefly) once I get enough memory free. 10.05.52 # Llorean: welcome in the club! 10.06.09 # Well, I'd already used it with the flash_buffering patch. 10.06.33 # i'd divided the pcm buffer size by 2, let's see what happens 10.06.57 # 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 # 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 # plugin buffer is 384kB I think 10.08.02 # Might work if you also switch to flash buffering, but then some nice-to-have plugins might be unable to run 10.08.07 # I get totally bogus data sometimes. looks like it gets overwritten. 10.08.08 # funman: works on linux, you want me to put it on FS? 10.08.21 # The jpeg viewer is rather smaller, but needs some buffer for the images 10.08.25 # Unhelpful: no, better let macosx people who do not want to use GNU fix it ;) 10.08.26 # *rather small 10.08.52 # 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 # I think I'd rather not have to stop playback for voice, than not having to stop it to view jpegs. 10.09.22 # where is the pcm buffer size defined? 10.09.38 # pcmbuf.c : pcmbuf_get_next_required_pcmbuf_size() 10.09.39 # Though actually, if it *always* just stopped playback for voice, that might be better all around. 10.10.04 # 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 # 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 # Unhelpful: hum i think i have a shorter test 10.11.29 # Llorean: "fix" as in "make it the way it's intended to be"? 10.11.36 # ... 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 # Unhelpful: oh 10.11.51 # mine's still not done fixing for a few minutes, now. :/ 10.12.10 # git log HEAD^..HEAD|tail -1|cut -d@ -f2|cut -d\ -f1 10.12.12 # amiconn: You don't "fix" something that's working right. :) 10.12.16 # cross platform 10.13.14 # 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 # 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 # Unhelpful: then origin^..origin ? 10.13.55 # amiconn: that seems odd. Why can't it flush, if it's going to have to rebuffer anyway? 10.14.08 # (and it actually pauses the MAS data transfer, allowing to continue from the exact same frame where it was paused) 10.14.22 # that assumes user use git pull --rebase after svn rebase though 10.14.24 # It doesn't have to rebuffer after pause... 10.14.35 # It has to rebuffer after voice though, doesn't it? 10.14.45 # huh? 10.14.51 # I'm confused. 10.14.57 # It doesn't do voice when paused. Only when stopped. 10.15.10 # 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 # funman: that fails for my clone, at least. 10.15.16 # But when voice should be played, why does it "stop, voice, resume"? 10.15.27 # *doesn't it 10.15.36 # That'd be wasteful 10.15.42 # Unhelpful: git show origin doesn't show you a git-svn-id in the log? 10.15.57 # It would mean stop->load voice->talk->rebuffer->resume 10.16.01 # fatal: ambiguous argument 'origin': unknown revision or path not in the working tree. 10.16.13 # amiconn: Which is necessary if you want to use voice anyway, you just have to do it by hand instead. 10.16.29 # Yes, hence it's better not to do it automatically 10.16.39 # i cloned this one from svn myself... maybe zagor's is not broken this way? :/ 10.16.45 # why are we using (NATIVE_FREQUENCY*4) in pcmbuf.c:434 ? last I checked we're not supporting 4-channel audio... 10.17.06 # hum .. what do you have in .git/refs/remotes ? 10.17.07 # Zagor: 2 channels * 2 bytes/sample ? 10.17.16 # also the "seconds += 2" ensures minimum 3 seconds, not 2 10.17.19 # "git-svn" 10.17.24 # Zagor: could the 4 mean the 4 bytes per sample? 10.17.35 # Unhelpful: and after git pull --rebase ? 10.17.45 # In fact I prefer the hwcodec behaviour of not doing voice during playback 10.17.58 # amiconn: that makes sense. but then why is it NATIVE_FREQUENCY*2 if MEM <= 1 ? 10.18.21 # I have no idea 10.18.22 # fatal: 'origin': unable to chdir or not a git archive 10.18.23 # fatal: The remote end hung up unexpectedly 10.18.39 # i pull from svn 10.18.50 # using the instructions on the wiki ? 10.19.13 # git update-ref refs/remotes/git-svn origin/master 10.19.23 # is sansa m200 working? it's the only target with MEM<2. 10.19.38 # (well, ifp too but I know that isn't working) 10.19.59 # that fails for me, too :D 10.20.02 Quit axionix_ (Read error: 110 (Connection timed out)) 10.20.19 # 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 # Unhelpful: i'm not sure but i think origin ref should be defined 10.21.38 # Unhelpful: could you paste your .git/config please? 10.22.44 # Zagor: see r12843 10.23.31 # funman: lemme make a fresh clone really quick, of the last few revs, and see if something's not clearly broken... 10.24.06 # funman: yeah I saw that. doesn't really explain the strange code though. 10.24.21 # nope but at least points to its author ;) 10.24.26 # :) 10.26.48 # hum i just saw a drop into used buffer 10.27.06 # i mean very high drop at the moment of the crash, like you told me 10.27.24 # it displays BUF_USED in buffering.c 10.27.35 # changing pcm buffer to the specified 2 seconds instead of 3 would free up 172KB ram 10.27.48 # which uses scary macros 10.27.48 # and I question why we need 2 seconds pcm buffer on flash targets 10.27.57 # for effects? 10.28.16 # crossfade is added on top of those 3 seconds 10.28.35 # like fade on pause? 10.28.52 # that doesn't affect the pcm buffer 10.28.54 # 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 # still going :/ 10.29.16 Quit Thundercloud (Read error: 54 (Connection reset by peer)) 10.29.20 # 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 # Llorean: exactly. I'm guessing the 2 seconds are to allow disks to spin up. 10.29.33 # Llorean: looks normal 10.29.54 # and my config has no origin ref in it 10.29.55 # i'm more interested by the file buffer 10.30.05 # Zagor: Even that *could* be handled in the compressed buffer instead of the PCM buffer. 10.30.09 # Unhelpful: does it have any remote ? 10.30.16 # It would make more sense since 2 seconds of compressed audio is a lot smaller, most of the time. 10.30.17 # Llorean: crossfade? 10.30.23 # excepting the svn-remote 10.30.30 # nope! :D 10.30.32 # The pcm buffer needs to be large enough to avoid too frequent boosting/unboosting 10.30.40 # Zagor: Possibly? Was just saying, disk spinup wouldn't need to depend on the PCM in my mind. :) 10.31.02 # On targets where we don't do that yet, it could very well be < 1 second 10.31.09 # Llorean: ah, you're right. pcm shouldn't have anything to do with spinup. 10.31.16 # it looks like you get none of that when you run git svn clone 10.31.34 # amiconn: is boost transition expensive? 10.31.58 # Yes, although it varies with SoC 10.32.27 # It's mainly the wait-for-pll-resync that costs time 10.32.31 # how expensive? bigger pcm also means smaller compressed buffer = more spinups/flash accesses 10.32.39 # a fresh git svn clone of the last few revs is exactly the same 10.33.14 # On coldfire, each transition also adds a bit of random timer uncertainty 10.33.41 # a git clone of the the git svn clone has a nice origin ref :/ 10.33.42 # (due to the timers being hooked to the core clock) 10.33.45 # remote rather 10.34.04 # Unhelpful: git remote add origin git://svn.rockbox.org/rockbox ? 10.34.12 # amiconn: yes, but what is a bit? are we talking microseconds or 100 milliseconds? 10.34.33 # Zagor: Up to 10 msec (typical 2 msec) on coldfire, and around 500 µsec on PP iirc 10.34.39 # ok. thanks. 10.34.55 # instant on as3525 :o) 10.34.56 Quit Nibbler (Read error: 110 (Connection timed out)) 10.35.02 # funman: really? 10.35.12 # funman: that does 'er. :D 10.35.12 # the PLL setting doesn't change 10.35.23 # ah, only the divider? 10.35.28 # yep 10.35.31 # nice 10.35.56 # So we could do with a smaller PCM buffer there? 10.36.13 # We could do that too on PP (only changing a post divider), but not on coldfire 10.36.15 # we might want to do some stuff #if MEM < 8 or MEM==2 10.36.39 # amiconn: why don't we already on pp? 10.36.44 # I was wondering if a global define LOWMEM would be useful 10.36.50 *** Saving seen data "./dancer.seen" 10.36.55 # It would limit us to certain 'normal' frequencies, e.g. 1/3 of the max. 10.37.02 # right 10.37.51 # funman: nah, let's try not adding too many defines. 10.37.56 # Actually we could run the pll at a higher frequency, and divide even for the max. clock 10.37.59 # we already have a LOT 10.38.39 # amiconn: but coldfire must get pll change? 10.38.43 # 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 # Zagor: yes 10.40.56 # On PP we use 80 and 30MHz now. With simple post divider, normal clock could be either 40MHz, or 26.667MHz 10.41.17 # but it still doesn't make any of your suggested methods work for me... :/ 10.41.30 # Unhelpful: git show origin doesn't show anything? 10.41.34 # 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 # Starting from 160MHz (as we need to do anyway on 5022), we could also use e.g. 32MHz 10.42.02 # 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 # Iirc the post divider is 1 <= divider <= 16 10.42.45 # Llorean: surely the clip doesn't need a UI boost 10.42.51 # 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 # 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 # 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 # yeah the pp targets are usually a bit more taxing 10.43.42 # Zagor: The Clip has probably got the best "amount of screen data" to "CPU speed" ratio we've got... 10.43.49 # Llorean: Actually I'd say it's just the Video. Color is fine afaics 10.43.52 # :-) 10.44.15 # 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 # perhaps 10.44.45 # Not that the patch is ready, anyway. 10.45.00 # anyway, since the ams targets use div boosting we have no reason to not shrink the pcm buffer 10.45.50 # not that it solves the immediate problems. but memory is rather scarce on these little critters. 10.46.04 # Zagor: Well, it might bring the audiobuffer back up to "large enough for playback" 10.46.21 # Llorean: yeah, without having to cut major features 10.46.35 # maybe even "resistant to crashes" 10.46.38 # Zagor: Where'd it defined, I'll test a build? 10.46.54 # going from 3 to 1 second pcm buffer will save 344 KB 10.47.06 # Llorean: apps/pcmbuf.c line 432 10.47.06 # Unhelpful: how did you clone that tree, git svn clone ? I'll try to see what i can tweak 10.47.22 # simply remove "seconds += 2;" to get a 1-second buffer 10.47.57 # how a larger pcm buffer reduces the number of boosting needed, because boosting is needed by pcm playback? 10.48.27 # funman: boosting is needed by decoder. and decoder can only decode as much as can fit in the pcm buffer 10.48.41 # so small buffer = many small decodes. 10.48.47 # = many boosts 10.49.26 # ok 10.49.46 # -2.3MB of filebuffer used, that can't be right ! 10.49.57 # 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 # funman: yeah I get that sometimes too. I suspect overwriting. 10.50.32 # right, and we should remove the instructions to svn clone then 10.50.52 # Zagor: of buf_.idx , yes me too 10.50.57 # do we even have those? i just followed git-svn's instructions... :/ 10.51.17 # http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl 10.51.33 # 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 # i would prefer a native git server too .. :o 10.52.36 # 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 # 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 # 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 # Llorean: did you ever try standard pcm buffer without tagcache? 10.58.22 # Zagor: Yeah, got data aborts after ~4 seconds of playback 10.58.30 # I'm not getting data aborts like this. 10.58.35 # yet :) 10.58.38 # Yet. 10.58.43 # I had a little difficulty getting playback to start 10.58.55 # I clicked on the file, got to the WPS, nothing happened, I paused then unpaused and it started. 10.59.08 # the reliable unreliableness 10.59.13 # 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 # I wonder if we have ever successfully ran swcodecs on a <8MB target 11.00.05 # Zagor: Someone declared an enormous plugin buffer on an iPod Nano once. 11.00.16 # 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 # So they, effectively, had a less than 8mb target I think 11.00.33 # there seems to be a lack of checks in the buffering/playback code 11.00.34 # funman: So far my music is still playing, and none of the audio glitches I get wit the buffer_flash patch. 11.00.55 # normal, because buffering.c use watermarks 11.01.22 # I do need to pause and unpause to start playback, which is strange. 11.01.29 # haha 11.01.37 # That's reproduceable like this, at least 11.02.14 # 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 # or when 11.02.44 # Zagor: why, no, you might want to save the function params at each call and display them in the panic 11.02.48 # Hmm... 11.02.50 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 11.02.51 # when, when buffering bugs 11.02.56 # The compressed audio buffer seems to refill *very* often 11.03.00 # the state : additional error handling wouldn't harm 11.03.05 # It seems to refill at about 512k 11.03.13 # Which is a bit early when it's only 630k large 11.03.27 # Llorean: yes, I noted that too. the watermarks are totally off. 11.03.34 # except for wav, for some reason 11.03.37 # #define BUFFERING_DEFAULT_WATERMARK (1024*512) 11.03.45 # funman: ah! :-) 11.04.09 # i think all the keys are in buffering.c since replacing this file gives completely different results 11.04.18 # 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 # Flash doesn't need to wait for spinup 11.05.49 # yeah, seems the buffering code could use a number of #if HAVE_FLASH_STORAGE 11.07.17 # I imagine the watermark being higher than the total buffer size caused at least some problems 11.07.20 # Zagor: Or use the flash buffering patch, maybe with a higher buffer? 11.08.08 # kugel: that's definitely an option. we need to determine which approach is the most power efficient. 11.08.25 # Hmm. 11.08.25 # Zagor: hum now i record : the corruption i had seen was in the linked lists struct memory_handle 11.08.26 # Llorean: indeed 11.08.39 # I tried changing the DEFAULT_WATERMARK to 1024*128 and it's still rebuffering at 512k 11.08.43 # Is there something else I need to look at? 11.08.49 # and the useful_data flag comes from the active struct 11.09.04 # 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 # 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 # 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 # 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 # 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 # hum that reminds me the pl180 has a 'powersave' bit .. 11.13.05 # pl180? 11.13.16 # SD controller inside the as3525 SoC 11.13.20 # ah 11.13.24 # Zagor: when I tried the flash buffer patch on my e200, it definitely had an impact on battery life 11.13.32 # kugel: negative? 11.13.36 # yes 11.13.40 # ok 11.13.50 # and that was before the "sd_enable()" commit 11.14.00 # 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 # funman: your short test w/ origin in place of HEAD seems to be the way to go 11.14.47 # git log origin^..origin|tail -1|cut -d@ -f2|cut -d\ -f1 11.14.51 # as long as there is an origin ;) 11.15.12 # 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 # 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 # my feeling is that it's a last resort for very lowmem targets that simply cannot work otherwise 11.16.18 # 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 # If I go to the WPS it eventually freezes up. 11.16.43 # funman: what about using git rebase? 11.16.50 # Llorean: try changing tracks in the buffer screen (press up & down) 11.16.57 # Unhelpful: yes that's probably better, i'm too used to git pull ;) 11.17.04 # Zagor: Works fine 11.17.20 # git rebase doesn't seem to work w/o arguments 11.17.36 # so it's either git rebase origin or git pull --rebase :/ 11.17.45 # Llorean: if repeat again multiple times you'll get other (iconsistent) crashes i believe 11.17.57 # funman: Repeat what? 11.18.07 # any steps related to playback in fact 11.18.18 # No crashes 11.18.27 # I just skipped about 12 tracks. 11.18.36 # but you only did that for 1 or 2 hours 11.18.56 # 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 # from my longer experience i think that the crashes happen randomly and not because of particular conditions 11.19.42 # 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 # Unfortunately, I failed to set the watermark lower. 11.20.11 # So it's still rebuffering quite often. 11.21.00 # Hm, "backlight on hold" doesn't seem to work on the clip. 11.21.19 # Llorean: watermark is also set in each codec. ci->configure(CODEC_SET_FILEBUF_WATERMARK, 1024*512); 11.22.05 # haha, how... eh, weird 11.22.10 # That seems strange to me. 11.22.17 # it seems like the watermark should rather be a calculation. 11.22.20 # I won't argue with that... 11.22.23 # Average bitrate * X seconds, or something 11.22.33 # Basically "long enough to spinup, plus a bit" 11.22.49 # the hwcodec has it based on the hd spinup time iirc 11.22.57 # Though I guess it'd get quite complicated with mixed codecs. 11.23.04 # B4gder: at least it did, last I looked at it :-) 11.23.16 # I don't think that has moved much during recent times 11.23.40 # Llorean: well there are still much better ways to do it than this way 11.24.08 # 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 # 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 # Could be. 11.26.57 # my theory remains buffering overruns, due to faulty assumptions about buffer size. 11.27.52 # I'm actually most curious why playback doesn't start until I pause and unpause. 11.28.08 # 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.08.54 Quit Darksair ("To Arch or Gentoo? That is the question...") 12.13.53 # 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 # according to the debug menu, the pcm buffer fills and then everything just stops 12.18.33 # hmm, this looks weird 12.18.59 # * n1s wants an iaudio [xm]5 tester 12.21.01 # and using an higher pcm buffer makes playback start again 12.21.59 # funman: I had playback with a ~176kb PCM buffer. 12.22.15 # Er, 192 perhaps 12.22.34 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 12.22.35 # if i use 1 second, i got nothing 12.22.42 # funman: Did you pause and unpause? 12.22.48 # yep 12.23.03 # How big are your compressed buffers? 12.23.09 # very big 12.23.11 # Er, is your compressed buffer. 12.23.22 # Mine was about 900k 12.23.33 # humm i think it was less 12.23.43 # where did you get this extra space i haven't? 12.23.49 # I disabled tagcache, and lowered my max playlist to 2000, and max files in folders to 100 12.23.55 # right 12.24.16 # oh, sorry, 720 12.24.18 # Not 900 12.24.23 # * Llorean wonders where he got 900 from 12.24.24 # ah now pause/unpause starts playback 12.24.58 # 172kB pcm , 615kB filebuf 12.25.45 # Same PCM, slightly more compressed here. 12.27.37 # 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 # n1s: what for? 12.28.49 # 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 # n1s: can't help you with this as the M5 doesn't have radio... 12.29.20 # ah 12.32.28 # 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 # 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 # s/am/ma/ 12.40.14 # 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 # 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 # I get a data abort in buffering.c, but it's not in one of the public symbols :-( 12.57.12 # Zagor: isn't it a struct access ? 12.57.23 # (or close to) 12.57.29 # pointer access, at least 12.57.44 # but there's quite many of those in that file... 12.58.18 # IDA makes it easy to read rockbox.elf , dunno about objdump 12.58.34 # good idea 12.59.04 # I forget, do we already have some support for assert()? methinks it would be useful in cases like this. 13.00.35 # #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 # if(!x) even 13.02.44 # 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 # jhMikeS: what are you referring to? 13.03.36 # It's probably one of those gray areas anyway. 13.04.01 # n1s: wondering about my definition of "freeze" :) 13.04.11 # Zagor: i found also some other functions declared in headers but not defined 13.04.13 # s/n1s:/n1s/ 13.05.34 # the data abort is in fill_buffer() 13.06.08 # Zagor: m = m->next ? 13.06.23 # anyway that means corruption of the memory_handle 13.06.46 # or perhaps first_handle 13.07.26 # I'll disassebmle and see 13.07.43 # dismsmasllalbmle 13.08.08 # disassmatroskae, disbuttmatroskae, (ok i stop) 13.08.24 # 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 # 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 # You're just getting a big head start on 3.2 13.39.39 # 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 # can I get a dev to fix FS#9625, I hit add task too soon 13.48.35 # 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 # mc2739: I assume you got sound? 13.50.47 # mc2739: Fixed.. 13.50.59 # Llorean: thank you 13.51.30 # kugel: yes, flac, wav, all play - mp3 has problems 13.51.43 # I tried ogg and it didn't play 13.52.06 # ogg worked for me also 13.52.14 # I tried to ge to the wps using a playlist_control and nvram.bin in combination with start screen: wps 13.52.41 # that is what I had to do to get it to play 13.52.58 # sounds like we should do what the comment above that #if says... 13.54.04 # "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 # 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.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 # 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 # not if they are reasonable 14.39.50 # 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 # 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 # 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 # obviously the person who bothered to write the patch wants it 14.47.39 # the patch is adding a wps tag to be used by whoever chooses to. it's not changing anything, only adding. 14.48.27 # 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 # It'll stay in the tracker until we make up our minds as to whether we want it or not. 14.49.03 # Jaykay: of course you are allowed to do that. 14.49.12 # ok...... 14.49.23 # You need to be just as certain about rejecting it as you are about committing it. 14.49.35 # know i know why there are 340+ patches^^ 14.50.20 # It's better than none, probably. 14.51.36 # another patch: http://www.rockbox.org/tracker/task/9329?project=1 14.52.01 # it does something automatically.... without asking for anything. 14.53.17 # 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 # Jaykay: The patch opener is a dev, so it should probably wait for his response at least before closing. 14.56.29 # ok 14.56.31 # 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 # yeah but as far as i see this patch is deleting the tags... 14.57.17 # not only showing part of it 14.57.26 # It's ignoring part of it. 14.57.46 # Rockbox has no means of writing tags back to the files. 14.58.36 # verdammt.... 14.58.45 # ok im sorry.. 14.59.20 # on this one I agree with jaykay. rasher showed already aug27 that the patch goes againt the spec. 14.59.40 # Zagor: I stated I don't like the idea of the patch in the very first comment. 14.59.49 # yup 15.00.10 # 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 # I'm ok with that 15.09.10 # 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.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 # 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 # 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 # domonoky: You may be interested in http://www.rockbox.org/mail/archive/rockbox-archive-2008-12/0104.shtml 16.55.04 # 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 # Okay, just making sure. 16.55.43 # Never do know who's subscribed to that list and who isn't. 16.56.15 # true, so thanks for noticing me. :-) 16.56.49 # did you find time to try out your m200v4 ? 16.57.26 # domonoky: Not yet. I keep getting distracted with my clip. 16.57.38 # :-) 16.59.56 Join kachna [0] (n=kachna@r4ax178.net.upc.cz) 17.04.32 # 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 # 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 # 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 # on a related note, i wonder why we list still open bugs in the release notes at all? 17.31.58 # anti-marketing :) 17.32.07 # * kugel runs 17.32.18 # 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 # a question about FS#9427 can tracks in a file played with a cue sheet have individual meta data? 17.38.58 # 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 # n1s: Yes, Rockbox stores per-track metadata for a file with a cuesheet. 17.41.25 # (assuming that info is in the cuesheet...) 17.46.46 # so it _could_ be feasible to scrobble individual tracks from a cue sheet-file thingy? 17.47.34 # Why only "could be" ? I would say it _is_ feasible. 17.47.59 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 17.48.25 # I guess it could get complicated when determining % of tracks played... 17.48.32 # 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 # 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 # ah, well thanks for clarifying though :) 17.49.32 # 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 # track number is probably too (at least indirectly) in the cue file 17.50.38 Quit massiveH ("Leaving") 17.51.27 # 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.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 # does anyone already have an idea what to do about the resizers in the pluginlib? smooth_resize and simple_resize 18.12.07 # I think they're slightly obsolete with resize in the core 18.16.05 # Is there anyone with a Sansa E-series around? 18.16.16 # here 18.17.03 Quit Llorean (Read error: 104 (Connection reset by peer)) 18.17.23 # 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 # It's damn hard to reproduce though 18.18.19 Quit TMM (Remote closed the connection) 18.19.33 # 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 # you maybe didn't press hard enough? 18.20.36 # 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 # 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 # evilnick: I have indeed a hard time trying to reproduce it 18.24.13 # evilnick: have you only experienced it in solitaire so far? 18.24.21 # kugel: I'm guessing that it's such a small window of opportunity that it might not be worth looking into. 18.24.40 # kugel: yes, so far. Would the fact it's a plugin make a difference? 18.25.05 # could be 18.25.45 # It seemed to happen if the fade-out had *just* started if that's any help 18.27.20 # evilnick: sorry, I try hard, but I'm not able to reproduce 18.28.09 # 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 # I'm trying solitaire 18.29.14 # 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 # 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 # 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 # I fail to reproduce it in other situations though 18.37.03 *** Saving seen data "./dancer.seen" 18.37.30 # 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 # (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 # (...on a 5.5G ipod) 18.40.05 # slact: I actually don't think so.. gevaerts is the man you want to ask to get a real answer 18.40.29 # hmm 18.40.35 # well, it wouldn't kill it, right? 18.40.48 # i mean, 5 volts is 5 volts... 18.41.26 # I've no idea, honestly.. I just remember hearing reports about not charging right 18.41.31 # hm 18.41.37 # eh, guess i'll just give it a try. 18.42.57 # seems to be charging okay... 18.43.11 # debug screen says so, voltage graph says so 18.43.35 # 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.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 # Nico_P: You might have a look at it 19.31.13 # kugel: What does your patch do? 19.32.37 Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) 19.32.39 # 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 # 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 # 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 # 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 # Refreshing the database in that manner often cause PF to display certain album covers in place of blank covers. 19.34.17 # LambdaCalculus37: No, not that one. I suppose you mean the one where covers of deleted files still show up? 19.34.28 # or changed covers aren't refreshed 19.35.12 # 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 # Broke rule #9 19.38.22 Quit slact (Read error: 60 (Operation timed out)) 19.38.42 # 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 # rb-remove(/absolute/path/to/file) ? 19.39.01 # LambdaCalculus37: yea, pf should do that for you, I agree 19.39.46 Quit MethoS- (Remote closed the connection) 19.40.14 # 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 # 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 # RockBox 19.40.27 # s/art/cache 19.40.41 # LambdaCalculus37: Why adding another item? Just let the existing rebuild cache do that 19.40.57 # kugel: True. 19.44.05 # 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 # 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 # Hello. Wouldn't it be good to have some last entries from the MajorChanges page on the start rockbox page? 19.49.56 # 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 # J0hnnyBr: Please stick with a nick. 19.50.32 # after the format, if you don't disconnet, you don't see it ? 19.51.49 # 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 # 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 # LambdaCalculus37: fixed! 19.59.48 # J0hnnyBr: did you try back your old drive ? 20.01.18 # kugel: Cool, what's the FS#? 20.02.46 # LambdaCalculus37: Do you know which FS# that was? 20.03.16 # I mean the bug report on that 20.03.55 # hm, I think I have a better plan 20.06.52 # 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 # 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 # rasher: I'll have a look 20.22.38 # if it fixes fs#9606, then yea, that's proper 20.24.02 # 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 # 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 # 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 # 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 # kugel: you're probably just lucky concerning memory usage 20.31.50 # fixed as in fix 9622, not as in fix#9606 probably 20.32.11 # J0hnnyBr: What's the drive model you're trying to use? 20.32.30 # 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 # 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 # 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 # can anyone else try to see if FS#8335 "fixes" the segfaults? 20.37.06 *** Saving seen data "./dancer.seen" 20.38.29 # domonoky: that's the Archos video player 20.39.19 # 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 # domonoky: The tiny displays make it much harder to play. 20.41.44 # LambdaCalc: The drive is MK1231GAL 20.42.01 # LamdabCalc: Toshiba... 20.42.12 # 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 # J0hnnyBr: Have you read http://www.rockbox.org/twiki/bin/view/Main/HardDriveReplacement before? 20.42.53 # btw... amiconn ;) 20.43.03 # 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 # LambdaCalc: Yes...and the other docs on the site as well 20.43.52 # domonoky: maybe check for swcodec/hwcodec too? Though I don't know if that's the clean solution (TM) 20.44.02 # Hello. I wanna join TWiki. And I read, that I needed to introduce myself here. Or did I mis interpret? 20.44.20 # Reizo: Well, you do have to come here to ask for write permission. 20.44.34 # J0hnnyBr: Bad news: http://www.rockbox.org/twiki/bin/view/Main/HardDriveReplacement#Toshiba (read a little further down). 20.44.38 # LambdaCalc: OK...I see why you are telling me that.... 20.45.05 # Reizo: What's your wiki name? I can give you permission. 20.45.27 # LambdaCalc: I missed the *. Yep....kicking myself. Saw the drive was cheap and jumped at it... 20.45.35 # That's the thing. I'm kinda lost when it comes to joining. :o 20.45.43 # LambdaCalculus37: maybe flashing the rockbox bootloader helps? 20.46.02 # LambdaCalc: Thanks for your help! ID10T error ;) 20.46.38 # domonoky: why not checking the defined model ? 20.46.49 # domonoky: Adding && (CONFIG_CODEC != SWCODEC) would seem OK to me. 20.46.52 # 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 # there is only 1 with LCD1885 which is not m200v4 no? 20.47.10 # 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 # 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 # (apart from the Player) 20.47.57 Part J0hnnyBr ("Leaving") 20.48.25 # 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 # Anyone want to buy me a new iPod Classic so I can cannibalize it and take the drive? ;) 20.50.16 # Then we can try this out. 20.52.41 # 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 # rasher: nobody did commit a change to this logic 20.53.42 # 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 # 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 # 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 # kugel: You should check if there's an albumartist set though 20.59.02 # rasher: Reversing the background logic would get my vote. 20.59.09 # 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.33 # kugel: Ah, alright. 21.02.54 # pixelma: indeed chopper is much more easy in archos mode ! 21.03.19 # 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 # 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 # kugel: the artist? 21.08.58 Join einhirn [0] (i=Miranda@p5B0337AA.dip0.t-ipconnect.de) 21.09.11 # rasher: all, I just do get_metadata actually :) 21.09.35 # So id3 is fully populated? 21.09.58 # rasher: yes 21.10.09 # That should be more future-proof also 21.10.35 # 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 # 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 # domonoky: Nice! I've got a couple of things to mention on the table. 21.11.00 # 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 # (not the features, of course) 21.11.39 # After funman gets done first. :) 21.11.57 # kugel: Then you should at the least separate the bugfixes from the features and open a task for those 21.11.58 # o: 21.12.15 Join itcheg [0] (i=62db4767@gateway/web/ajax/mibbit.com/x-ff9ca8c453985daa) 21.12.16 # 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 # 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 # rasher: "artist.bmp" in /,rockbox/albumart is valid, isn't it? 21.18.21 # the fuzev2 firmware seems to have the same format than clipv2 21.19.32 # kugel: Nope, that won't get picked up - check out apps/recorder/albumart.c line 154 21.19.36 # and the same structure than other firmwares ("AS3525" string) 21.23.01 # but artist-album.bmp it seems 21.23.11 # Indeed 21.23.18 # lets try that 21.23.34 # How else would you get the right album art if you have more albums by one artist? 21.24.05 # good point 21.24.53 # do you have a link to a list of the flags in the program status register on ARM ? 21.25.20 # funman: http://www.peter-cockerell.net/aalp/html/frames.html 21.25.39 # 2nd third of the right side page 21.26.26 # 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 # kugel: thanks! 21.28.06 Quit jhulst (Read error: 113 (No route to host)) 21.28.10 # you're welcome :) 21.28.52 # * kugel didn't expect a floating point exception in pictureflow 21.29.29 # FS#9626 - Reverse simulator background logic - up for discussion 21.29.51 # 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 # The arrows work 21.32.39 # Maybe the number row should just map to the numbers as well? 21.32.48 # 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 # rasher: I think reversing the logic is a good idea 21.34.37 Quit kharo1 (Read error: 110 (Connection timed out)) 21.35.05 # the fuzev2 also use the armv5 BLX instruction, so it suggests and upgrade to the as3525 21.35.33 # 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 # .wfms! 21.43.03 Quit bmbl ("Woah!") 21.43.17 Join akur [0] (n=akur@bl7-90-128.dsl.telepac.pt) 21.45.41 # rasher: Ok, it works. It finds my artist-album in /.rockbox/albumart 21.46.57 # bertrik: It would be a nice idea. 21.47.34 # kugel: smashing 21.47.49 # 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 # for example, we could quite easily give a visual indication of the "location on the dial" using a horizontal slider 21.48.54 # http://www.rockbox.org/tracker/task/9627 21.49.25 # gevaerts: I agree 21.50.08 # 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 # gevaerts: agreed 21.52.32 # kugel: I'm not sure how you define "button funtionality" then 21.52.58 # 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 # well, it changes the behaviour if you don't press that button at all 21.53.29 # you put the fun in functionality 21.54.47 # 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 # 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 # kugel: It's the expected behavior in most cases, for most users though: Attaching cable enables USB connection. 21.56.48 # 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 # kugel: your patch is unclean 21.57.58 # 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 # kugel: I'm not talking about rockbox usb, but about rebooting to the OF that has USB 21.58.37 # kugel: are you going to do the support for all the people who complain that their ipod doesn't connect? 21.59.05 # gevaerts: I didn't vote for reversing it, but I'd surely like to have the option 21.59.21 # if the default is kept, no user will complain 21.59.29 Quit LambdaCalculus37 ("mibbit.com: go home time is now") 21.59.48 # anyway, if it goes under configurable buttons, then it should probably rejected 21.59.58 # rasher: I answered 22.00.35 # 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 # 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 # Yup, the yuck was at the custom scrollwheel design 22.06.38 # define* 22.07.32 Join Zagor [242] (n=bjst@rockbox/developer/Zagor) 22.09.50 # I'm unsure if the scrollwheel thing counts as a bugfix 22.10.00 # Probably not, really 22.10.35 # imho it does... 22.10.51 # Where's the bug? Everything works as expected/intended 22.10.59 # besides that it's totally safe 22.12.13 # It does seem pretty obvious 22.12.15 # :\ 22.12.21 Quit Llorean (Read error: 131 (Connection reset by peer)) 22.13.05 # rasher: visit the task to get a bugfix only version 22.13.44 # * rasher debates a bit back and forth 22.14.10 # hehe 22.14.58 Quit itcheg ("http://www.mibbit.com ajax IRC Client") 22.15.04 # 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 # 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 # gevaerts: yes. I still want to get it updated and committed. 22.17.48 # ok. I won't touch it then 22.17.54 # though I'm a bit unsure if the save format is the best idea 22.18.09 # bluebrother: Anything against a "okok"? ;) 22.18.14 # * gevaerts now looks at rasher with FS#5519 22.18.18 # if you have a good idea about it let me know ;-) 22.18.36 # kugel: shall I call you Casainho? :P 22.18.53 # kugel: What about the MAX_PATH+1 change? Most uses of MAX_PATH don't do this.. Though some do. 22.18.54 # I'm just going through the patch tracker to see if anything can be closed 22.19.36 # gevaerts: People claim it takes ages.. I haven't tested it since I first wrote that patch though. 22.20.08 # 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 # rasher: I agree with you about simulator background. it should be enabled by default 22.24.35 # rasher: it should be +1, for the \0 22.25.27 # else you dont have really max path available, but max path -1 22.26.04 # kugel: And you're sure that's not already included in the value of MAX_PATH? 22.26.16 # 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 # 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 # re #5744, how does car adapter mode work with usb-powered targets? 22.27.57 # MAX_PATH doesn't consider multi-byte characters anyway, so it's already awfully broken 22.29.16 # true 22.30.08 # 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 # 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 # 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 # 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 # Chronon: go ahead. I did a rather big cleanup a few weeks back and never got around to clean that page 22.45.45 # editing. .. 22.47.14 # 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 # 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 # What should we do with FS#8266? 22.49.00 # 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 # 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 # 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 # Also, I've seen +1 more in the rockbox source, especially in the settings 22.50.10 # MAX_PATH is a macro, so sizeof(MAX_PATH) doesn't make sense 22.50.12 # kugel: sizeof(MAX_PATH) is going to be 4 or 8 ;) 22.50.15 # kugel: string variables always have room for a terminating null. that is not unexpected behaviour. 22.51.02 # gevaerts, bluebrother: ok, "imagine you could do sizeof() on MAX_PATH" 22.51.23 # 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 # whatever 22.52.30 # whenever 22.52.31 # that makes me wonder how it's defined 22.52.39 # whereever 22.52.41 # #define MAX_PATH 260 22.52.46 # *la la la* 22.53.09 # amiconn: Your take on the MAX_PATH thing? 22.53.12 # bluebrother: singing shakira is strictly off-topic :) 22.53.45 # 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 # rasher: oh, thanks for that info 22.54.16 # Zagor: yep, that's what we all wonder and discuss 22.54.18 # Zagor: Pretty much. Also, how we handle multi-byte characters 22.54.46 # 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 # hmm, according to limits.h definitions it does include NULL. Oh my. 22.55.41 Quit petur ("*plop*") 22.55.44 # kugel: you sure it's Shakira? 22.55.57 # I definitely think MAX_PATH includes \0 22.55.58 # not anymore ;) 22.56.02 # http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html 22.56.56 # 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 # snprintf takes the size including 0, for example 22.58.43 # I see, I see, I should renew my C references as soon as possible 23.00.15 # I wonder how things would look if we did MAX_PATH = 780 (iirc, characters can be up to 3 bytes?) 23.00.29 # 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 # 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 # For this reason alone, I think the MAX_* defines should include the \0 23.04.02 Quit itcheg (Client Quit) 23.08.42 # rasher: Things would most probably crash very often 23.09.01 Quit Zagor ("Leaving") 23.09.20 # And UTF-8 chars can be more than 3 bytes (but only for chars outside the unicode bmp) 23.09.38 # amiconn: Why's that? 23.10.05 # Many buffers for that kind of stuff are allocated on teh stack 23.10.38 # utf-8 characters are allowed to be up to 4 bytes (though originally 6 were allowed) 23.11.46 # 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 # .bdf doesn't support extended unicode anyway 23.13.00 Quit akur1 (Read error: 60 (Operation timed out)) 23.15.17 # I think we can safely declare anything past the BMP "the boonies", and refuse to support it 23.16.42 # Still, it seems a bit wrong that we potentially have a limit on MAX_PATH of less than 90 characters. 23.17.48 # Iirc the fat driver switches to using shortnames if the longname doesn't fit 23.18.10 # Ah right, the shortname! A lucky escape for FAT32 there 23.18.33 Quit freddy__ (Remote closed the connection) 23.21.13 # We might be better off using UTF-16 for pathnames internally. 23.22.00 # * rasher would think UCS-2 instead? 23.22.40 # 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 # hi 23.27.42 # hi, did that show? 23.28.21 # 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 # hi, is there anybody out there 23.40.13 # no, only bots in here 23.40.23 # nobots 23.40.29 # and those are in, not out 23.40.45 # hi, I'm Eliza. Please tell me your problem. 23.40.53 # so, is there any chance of getting rockbox help in here? 23.40.58 # BenCrinion: fire away your prob! 23.40.59 # i installed the latest version 23.41.09 # onto an olympus mrobe 23.41.16 # and it works, but i get no sound 23.41.24 # Interesting. How do you feel about olympus mrobe? 23.41.36 # * gevaerts hits bluebrother over the head 23.41.42 # BenCrinion: let me try on mine 23.41.44 # it looks like its playing, i can fast forward, upload 23.41.52 # mrobe100? 23.41.55 # yes 23.42.09 # i liked the mrobe until i broke it by deleting some files 23.42.16 # Have you feeled upload before? 23.42.18 # and now i dont like it any more, cos its broke 23.42.28 # feeled upload? 23.42.46 # BenCrinion: ignore bluebrother. He seems to be in a not very helpful mood today :) 23.42.49 # /ignore bluebrother ;) 23.42.54 # BenCrinion: ignore me. I'm playing Eliza 23.43.05 # its fine 23.43.58 # so, what kind of files did you delete? Have you chkdsk'ed the player? 23.44.23 # i reformated the player, then rehooked it up to the mtrip 23.44.31 # i havent chkdsked it 23.44.38 # im confident that its fine 23.44.49 # it was playing ok with mrobes firmware yesterday 23.44.59 # hmm. Well, if you reformatted it there shouldn't be issues with crosslinked files 23.45.06 # It's a bug 23.45.15 # does the m:robe firmware play fine today? 23.45.20 # I don't get any sound either with the latest build 23.45.34 # BenCrinion: did you use Rockbox Utility to install? 23.45.42 # no, it didnt work 23.45.48 # * bluebrother hasn't tried the m:robe for a while 23.45.50 # something about cannot find firmware 23.46.07 # * jhMikeS did broke it? (somehow) 23.46.09 # maybe cos the original files were missing 23.46.11 # OK, just checking what I should say next :) 23.46.13 # let me guess ... the original firmware file wasn't present? 23.46.21 # probably 23.46.25 # cos i formatted it 23.46.39 # BenCrinion: did you install the current build, or 3.0? 23.46.54 # 3.0 23.47.01 # i think anyway 23.47.06 # well, that file is required as otherwise it can't make booting the OF (and thus disk mode) work 23.47.09 # the link from the releases page 23.47.39 # Just to check, can you go to the System menu and select Rockbox info? 23.47.43 # 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 # 3.0-08923 23.48.15 # gevaerts: what was the problem? 23.48.15 # That's 3.0, yes 23.48.17 Join kugel [0] (n=chatzill@unaffiliated/kugel) 23.48.25 # I rebooted 23.48.41 Quit CaptainKwel ("http://www.mibbit.com ajax IRC Client") 23.48.44 # rebooted the mrobe? 23.48.48 # with the rest button? 23.48.53 Quit jgarvey ("Leaving") 23.49.02 # that's not reboot, that's reset 23.49.27 # Actually the current build froze on the USB screen, so I held power for a while to reset it 23.50.32 # got sound 23.50.38 # what the F? 23.50.45 # Good question... 23.50.45 # im sure i turned it off already 23.51.08 # 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 # if it makes any difference i just activated the database whatever that means 23.52.18 # this is really good guys, great job 23.52.26 # can you try something? 23.52.57 # 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 # I seem to have sound on cold boot and on reboot from rockbox, but not on reboot from diskmode 23.53.51 # whats OF disk mode? 23.54.06 # i take it thats where it mounts as a hd? 23.54.06 # Yes 23.54.23 # 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 # ive still got sound 23.55.35 # 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 # bertrik: I gave funmans patch a quick test, without success though 23.56.27 # what patch? 23.56.28 # the read returns -4, and button passed to it doesn't change 23.57.10 # bertrik: http://paste.ubuntu.com/83975/ 23.57.45 # 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 # hello 23.58.09 # right guys im off, thanks for your help 23.58.09 # i have a sansa sandish e260R 23.58.23 # i am not sure how to install it 23.58.26 Part BenCrinion 23.58.39 # it has wierd instructions, can anyone help?