--- Log for 06.04.104 Server: truong.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16p1 Started: 1 month and 23 days ago 00.01.13 # On Saturday I discovered a rockbox bug :(, for which I filed both the bug report and the fixing patch today :) 00.01.52 # I did also complete my recording loop optimization and filed another patch for that :)) 00.02.50 # i just committed your patch 00.03.17 # Which one? 00.03.30 # the postpone bug 00.04.24 # i don't see a recording path in the tracker 00.04.27 # patch 00.04.58 # Hmm, may that have any ill side effect? I didn't observe one, but I do not have such nice equipment available as you (logic analyzer) 00.05.11 # hehe, i'll examin ethat 00.05.19 # examine that later this week i hope 00.05.32 # Recording: patch #929702 00.05.33 # i am on vacation (with my laptop) 00.05.40 # oo coder people are here 00.05.49 # there is an uber bug in the current cvs version 00.06.03 # stevenm: oh? 00.06.11 # filed bug report, but still. look at the last menu item in General Settings, as well as the DEbug menu 00.06.24 # you will be very unpleasantly surprised 00.06.37 # and the credits are gone- replaced by a counter and fragments of the speech menu. 00.06.43 # cool 00.07.10 # I'm guessing something went askew with the string table, if there is one.. these all seem related bugs 00.08.15 # Hmm, I did build my personal Rockbox from current cvs and did observe no such problems (although my personal build incorporates various optimizaions that are not (yet) in the official build, but none of them have to do with menus & strings) 00.08.45 # is it just me, or is the whole debug menu shifted down 4 lines, and the speech menu gone, and the last option in general settings is blank ? 00.09.08 # this is version 04052004-CVS I'm talking about 00.09.30 # woo, cpuadrerr at 090120c0 :-) 00.09.54 # I downloaded file several times, reased from memory entirely, and reflashed, and the unit is behaving, well, erratically 00.10.05 # LinusN, hmm ?? 00.10.12 # LinusN: ??? 00.10.26 # built from cvs and boom! 00.10.39 # i guess i'll have to rename the (old) voice file 00.11.02 # nope, already did that... 00.11.12 # time to fire up gdb 00.11.29 # so I aint the only one seeing weirdness ? 00.11.40 # nope 00.11.51 # all right.. I figured this whole unit was dead. 00.12.04 # and theres a battery issue also, but I submitted that, and its far less important right now 00.12.21 # the percentage while charging? 00.12.35 # no, not that 00.12.41 # stevenm, LinusN: on which Archos model(s)? I have recorder v1, no probs with current cvs?!? 00.12.57 # amiconn, Recorder V1. I used daily build. 00.13.10 # stevenm: 100% does not mean that it's fully charged 00.13.20 # LinusN, I mean, it switches to top-off charge 00.13.27 # really? 00.13.34 # Hmm, will try the daily (although not flashing it) 00.13.44 # It goes into top-off charge, but then runs for like 2 minutes on those cells, and dies 00.13.51 # wow 00.14.18 # are you using the original charger? 00.14.24 # LinusN, I am charging with archos firmware right now (yea yea, shame on me, but) and its STILl charging 00.14.33 # are you using the original charger? 00.14.48 # LinusN, I am using my own- never had the original. feeding it 9V, max charger output is 800mA 00.14.59 # ok 00.15.12 # it's worked before, with this same charger, worked for a while.. no problems. this started happening suddenl;y 00.15.18 # i'm wondering if it sees a negative delta prematurely 00.15.58 # and I am now charging by the method of holding F1 and then plugging it in, and it's still going. been charging for 3.5 hrs 00.16.38 # well forget the deltas for now, what's up with the menu options? it's as if they had a mind of their own.. 00.16.55 # the original firmware doesn't use the negative delta method as far as i know 00.17.11 # I downloaded CVS-040405, put it on my box, rolo'ed - no problems at all! I'm puzzled. 00.18.09 # stevenm: Did you update your .lng file along with the firmware? 00.18.27 # amiconn, I unzipped the whole zip file 00.18.53 # Which language do you use? (So I can try that as well) 00.19.01 # I use English 00.19.43 # I flashed, though, if that makes that big a difference 00.21.04 # i think i have a stack overflow 00.22.08 # Bingo! The english.lng file somehow produces an overflow. I usually use german and have no probs like described. If I switch to english, I get them as well. They stay even if I switch back to german until re-rolo. 00.24.07 # It also occurs with my personal build if I switch to english. 00.25.44 # Btw: There is still the bug that if you switch languages from the menu, the menu texts are garbled completely until you leave and re-enter the menu. 00.27.32 # still? i don't even know about it 00.27.34 # amiconn, I confirm. Selected French, roloed, works fine. Selected English, and it died. 00.28.07 Quit matsl (Remote closed the connection) 00.28.10 # LinusN: bug report #918063 of 2004-03-17 00.31.24 # ah 00.31.43 Join matsl [0] (~matsl@1-1-4-2a.mal.sth.bostream.se) 00.37.18 Quit matsl (Remote closed the connection) 00.39.18 # i did "make clean", and the problem went away 00.41.36 # ah, now i see it 00.42.54 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 00.45.42 # stevenm: a workaround is to reset the settings, making it use the internal string table instead of english.lng 00.45.53 # or delete english.lng 00.46.21 # binlang hasn't been updated for the new string lable format 00.46.24 # table 00.46.27 # thanks, I'll do that right now.. do you suppose there's gonna be a fix within the next few days? 00.46.39 # sure, give me a few more minutes 00.46.59 Join scott666_ [0] (scott666@c-24-245-58-245.mn.client2.attbi.com) 00.47.13 # oh and also, for some reason, if charging from the original firmware charge screen, pressing On will start Rockbox, then give ATA error -31 00.47.41 # oh 00.47.48 # you have to disconect charger, hold Off, then press On for it to work properly 00.47.52 Quit scott666 (Read error: 104 (Connection reset by peer)) 00.50.38 # and theres htis other annoying thing I've been meaning to bring up 00.51.20 # the buttons aren't always read right. I press one button, and it reads it as another. I assume this has something to do with the ADC it uses for the buttons.. I spotted a bunch of resistors there 00.53.12 # go to debug->view i/o ports 00.53.31 # yes? 00.54.02 # press F1, F2, F3 and Up and tell me the AN4 readings 00.54.20 # then press Left, Play, Right and Down and tell me the AN5 readings 00.54.43 # F1 - bouncing from 18F to 191 00.55.06 # F2 - 262 - 264 00.55.22 # F3 - 3Fe - 3FF 00.55.38 # Up - 331 - 335 00.55.52 # Left - 262-265 00.56.13 # Play - 32F - 332 00.56.26 # Right- 18F - 192 00.56.41 # Down- 3FE - 3FF 00.56.45 # excellent 00.56.50 # no problem there 00.57.25 # now try to jiggle the buttons a little, or apply some force, and see if you can make it produce a different value for a button 00.57.25 # so.. what do you think is causing it? 00.57.55 # i think you have a hardware problem 00.58.27 Join diddystar5 [0] (Lee@ACC7D0A6.ipt.aol.com) 00.58.33 # I tried, Down is always 3FF 00.58.43 # and it most ofen mistakes Down for Right 00.59.10 # I guess maybe my pads are worn- I need to apply more force, or something 00.59.11 # i have that problem too 00.59.16 Nick scott666_ is now known as scott666 (scott666@c-24-245-58-245.mn.client2.attbi.com) 00.59.42 # try to press it very lightly, or very fast 01.00.05 # LinusN, does the button driver look for one nonzero value, or does it sample several times and pick the most commonly occuring value, or what? 01.00.47 # it takes several samples 01.01.18 # my debug values are completely different though 01.01.29 # or rather, it accepts the button if it reads the same value twice in a row 01.01.38 # scott666: gimme those 01.02.03 # F1: 133-135 01.02.29 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 01.02.36 # F2 1DF-1CF 01.02.59 # F3: 309-30D 01.03.15 # up: 26D-26F 01.03.52 # play: 132-12F 01.04.09 # right: 26B-26E 01.04.12 # scott666: do you have an fm recorder? 01.04.17 # yes 01.04.29 # that explains the different levels 01.04.35 # down:30A-30D 01.04.36 # ahh 01.04.38 # ok then 01.04.38 # heh 01.05.19 # you have problems with f2? 01.05.43 # down and right and up and f2 i think 01.06.05 # i dont actually _use_ my fmr much lately as the headphone jack is broken 01.06.11 # but i remember having those problems 01.06.41 # i did a survey long ago to find the best thresholds for the plain recorder, but we never did that for the fm 01.07.19 # that could explain it 01.07.43 # your readings look good, though 01.07.57 # i dunno, its a strage bug 01.08.22 # you press down and it is interpreted as right? 01.08.32 # some of the time 01.08.36 # its fairly rare 01.08.47 # like when you scroll fast? 01.08.50 # but its happened enough for me to know im not insane 01.08.58 # yeah 01.09.30 # i think i know what might be the problem 01.09.46 # but i'm not sure how to fix it in the firmware 01.10.06 # i think a very brief press gives a lower reading 01.10.13 # LinusN: my grayscale framework for plugins takes shape... 01.10.31 # grayscale framework? 01.10.44 # for generic grayscale graphics? 01.10.52 # amiconn: yay 01.10.57 # Yup, for use e.g. in games etc. 01.11.26 # i have no dev enviroment atm :( 01.11.32 # (or linux) 01.11.32 # LinusN, the way to fix the buttons would have been to put a TRANSISTOR on every button 01.11.57 # but oh well 01.12.18 # Basically this will provide an additional framebuffer for grayscale (within the plugin buffer limits) that can be displayed as overlay. 01.13.07 # amiconn, can we get a nice grayscale breakout game? 01.13.14 # a la ipod 01.13.35 # It can even be used while the music is playing. The drawback is that it provides a fixed number of grayscales, no continuous rendering like in the video plugin by Jörg. 01.15.11 # The number of available grayscales will be dynamic, the smaller the overlay gets, the more grayscales will be possible. If there are too many grayscales, it will probably flicker a lot. I'm just testing that. 01.20.01 # i have now committed a fix for the language file corruption 01.21.11 # LinusN, how do i get raw mp3 data to use the mp3_xx functions with? 01.21.25 # (i'm updating my battery low bepp patch with that) 01.22.00 # first of all you need an mp3-encoded beep, do you have that? 01.22.27 # LinusN, no, but i will make on just a minute 01.23.41 # then you will want to bitswap it and produce a nice C-array with the data 01.23.53 # and there are no published tools for that 01.23.57 # how do i bitswap it? 01.24.33 # how did you do it? 01.24.39 # did you write a prog? 01.24.59 # i haven't, but if i did, i would write a prog to do it 01.25.25 # ok, then how do it anyway possible? 01.25.41 # please rephrase that 01.25.52 # diddystar5: If you're looking for a bitswap in C, look at the source of Jörg's rvf_mux 01.26.13 # amiconn, thanks 01.27.02 # i didnt have goldwave installed to make the sound.... will take me a few mintes to download 01.31.33 # its a cpp, guess ill have to go to the library and get g++ along with my cygwin 01.31.42 # or i could install linux.... 01.33.38 # rename it to .c and you'll be fine 01.34.41 # yeah, the only c++ ism's ther are i wont need 01.35.27 Quit diddystar5 (Read error: 54 (Connection reset by peer)) 01.39.01 # Ahh, my grayscales look really good now. I was able to get rid of that dreaded moire pattern. 01.41.00 # LinusN: Did you find my recording patch in the meantime? 01.42.51 # yup 01.43.40 # will try it soon, just not today 01.43.46 # I would be _very_ interested if you could manage to do some logic analyzing with my new loop. 01.43.52 # will do 01.45.02 # amiconn: do you care a lot about the contents of your jukebox? 01.45.23 # How do you mean that? 01.45.26 # i mean, are you willing to reformat it? 01.45.35 *** Saving seen data "./dancer.seen" 01.46.12 # Could do that, since it has USB2, so transfer of the data should not take that long. But why should I reformat? 01.47.02 # i'd like you to reformat with a very small cluster size, to see how the seek times affect the recording 01.47.31 # (Most of the data is already backed up on my PC, since I tested my writing with it and did'nt want to put all data at risk) 01.48.01 # i always have a complete mirror of my jukebox on my pc 01.49.22 # Wth has the seek time to do with cluster size? Seek time only depends on the disk model, or do I miss a point here? 01.51.00 Join joshn [0] (~joshn@204.251.225.17) 01.51.51 Quit joshn (Remote closed the connection) 01.53.41 # the file seek needs to wade through the FAT chain to find the position in the file 01.54.03 # small clusters == more FAT entries to search 01.54.47 # Grr, I think I'm silly. Of course you spoke about the file seek and not the disk seek. 01.54.53 # :-) 01.54.55 # tired? 01.55.07 # have a Red Bull 01.55.42 # Hmm, not really. I happen to be on vacation also. 01.56.43 # Why should the file seek affect recording? Is there a seek operation executed _while_ recording? 01.57.30 # it appends to the file, and i think we still do append by seeking to the end 01.57.39 Join joshn [0] (~joshn@204.251.225.17) 02.01.03 # As far as I call tell from the source, the file is held open between consecutive writes, so no seek here. 02.01.35 # the recording code does fsync(), which calls flush_cache(), which performs a seek() 02.02.21 # this is done to make sure that the file is updated on disk in case of a crash 02.02.53 # Ahh, I get your point. 02.03.26 # i suspect that the seek takes too long when the file grows, and the recording buffer overflows 02.03.39 # (nice rhyme) 02.04.31 # Did you get overflows? I didn't manage to get incomplete frames (except the last one) even in my 2:09 h test recording. 02.05.31 # i have never had any overflows, or corrupt files 02.05.49 # but other people have, that's why i want you to test my theory 02.06.19 # Still I have to figure out how to format with a different cluster size (on Windows). 02.06.46 # i think you can select that in the formatting dialog box... 02.07.43 # True for NTFS, but for FAT i only get "default size" which is not very helpful. 02.08.07 # silly windows 02.08.17 # :) 02.08.58 # i think win98 lets you choose 02.15.05 # I _can_ choose the cluster size _if_ I do the formatting from the device manager in WinXP :) 02.18.01 # But.. Windows complains that it cannot format a 4 GB test volume with 512 byte/cluster. 1024 byte/cluster works. So I will have to choose 8192 bytes/cluster or higher for my 20 GB box. 02.19.05 # This is strange, shouldn't FAT32 allow for 2^32 clusters equalling 2 TB with 512 bytes/cluster? 02.21.23 # 2^28 02.21.36 # 4 bits are used for other stuff 02.22.09 # This would still be good for 128 GB with 512 bytes/cluster... 02.23.03 # there may be more limits 02.23.48 # like a maximum fat size for example 02.25.48 # Some days ago I did take a look at the beginning of my jukebox hd with a hex editor and found my fat being ~10 MB large. This implies that I'm currently using 16 KB clusters. 02.27.06 # (I tried to find a way of getting only the root dir extracted, to put together a small program that does this. This could help in getting the cause for the file system corruption, since apparently the root directory is affected) 02.31.44 # not necessarily, some people report that .rockbox is affected 02.53.34 # I guess I should try to get some sleep now. Can do more tomorrow. 02.53.34 Quit Nibbler (Read error: 54 (Connection reset by peer)) 02.54.45 # Linus, please tell me if you think it's worth going from 16K to 8K clusters and test recording. Or would a _very_ long recording also help tracking down the seek problem? 02.55.06 # In this case I would leave my Archos recording overnight. 02.56.26 # Btw: I have write optimization compiled in (of course). 02.57.34 --> "*** addictirc!logbot_: sYk0_frEak kicked #guitar sYk0_frEak" received from Rhino (zachary@66.207.165.66) 02.58.03 # i have 4k clusters and have no problems 02.59.16 # haven't done any _huge_ recordings lately, though 02.59.22 # What disk size do you have? 02.59.55 # 40gb 03.00.58 # Why would that &§%$ Windows not let me format 20 GB with less than 8 K/cluster then? 03.01.42 # b/c it is silly? 03.01.44 # I think I will have to download knoppix and give it a try on my laptop. 03.02.44 # iirc if you used 512 byte sectors, you would quickly run out of entries in the FAT table (i could be very wrong) 03.03.16 # (This will have to wait till tomorrow, though. Will do a "overnight-recording" with my current cluster size a a first test). 03.03.30 # i tend to sleep through too many of my lectures :/ 03.04.53 # Nite all. 03.06.32 Part amiconn 03.12.17 Quit AciD (Read error: 54 (Connection reset by peer)) 03.42.26 # hi guys 03.42.50 # Anyone notice when you go from the fm radio to play a mp3 the Peak Meter is still tracking the fm radio, and if you stop the radio then go to play a mp3 file the Peak Meter doesn't work ?… you got to reboot first 03.45.37 *** Saving seen data "./dancer.seen" 03.50.25 Quit joshn (Remote closed the connection) 03.50.59 Join joshn [0] (~joshn@204.251.225.17) 03.51.14 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 03.51.34 Quit joshn (Remote closed the connection) 03.51.54 Join joshn [0] (~joshn@204.251.225.17) 04.01.49 # ILuvit: oops, i'll have a look. please file a report 04.02.45 Join diddystar5 [0] (Lee@ACC5DF77.ipt.aol.com) 04.07.47 Join elinenbe [0] (trilluser@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 04.07.59 # let's port rockbox to the ipod! http://ipodlinux.sourceforge.net/ 04.08.46 # heh 04.09.16 # go4it :) 04.11.23 Quit joshn (Remote closed the connection) 04.15.10 # i would never get a ipod 04.15.23 # infact i dont even look for just mp3 players anymore 04.15.36 # i look for ones with video etc, like the av320 04.15.57 Join joshn [0] (~joshn@204.251.225.17) 04.16.28 Join [1]c0utta [0] (~c0utta@146.cust46.nsw.dsl.ozemail.com.au) 04.20.06 # ILuvit: fixed in cvs 04.20.25 # time to sleep, nite guys 04.20.29 Part LinusN 04.20.41 # LinusN, what do you think about my simplified vu meter patch? 04.20.45 # n/m 04.20.46 # lol 04.31.50 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 04.34.01 Quit c0utta (Read error: 110 (Connection timed out)) 04.34.05 Nick [1]c0utta is now known as c0utta (~c0utta@146.cust46.nsw.dsl.ozemail.com.au) 04.45.29 Quit AciD (Read error: 104 (Connection reset by peer)) 04.46.45 Join sagegoku [0] (~asdfa@CPE-24-163-156-130.kc.rr.com) 04.46.49 # hey 04.51.13 # hi 04.54.47 Quit diddystar5 ("Leaving") 04.57.31 Quit scott666 ("i'll be back...eventually...") 05.45.41 *** Saving seen data "./dancer.seen" 06.04.19 Quit sagegoku (Read error: 54 (Connection reset by peer)) 06.04.20 Quit Nibbler (Read error: 54 (Connection reset by peer)) 06.09.05 Quit stevenm ("Leaving") 07.21.09 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 07.22.27 Quit ILuvit (Read error: 60 (Operation timed out)) 07.36.05 Join midknight2k3 [0] (~midknight@c-24-18-39-169.client.comcast.net) 07.45.45 *** Saving seen data "./dancer.seen" 08.12.27 Quit Nibbler (Read error: 54 (Connection reset by peer)) 08.24.31 Quit midknight2k3 (Remote closed the connection) 08.26.25 Join midknight2k3 [0] (ZakkRobert@c-24-18-39-169.client.comcast.net) 08.32.59 Quit midknight2k3 (Read error: 104 (Connection reset by peer)) 08.35.04 Join midknight2k3 [0] (~Zakk@c-24-18-39-169.client.comcast.net) 09.01.48 Join monkey666 [0] (monkey@1Cust250.tnt1.mount-vernon.wa.da.uu.net) 09.07.49 # maybe somebody here knows if it is possible to bookmark text files? 09.08.06 # i checked the manual and site and came up with nothing 09.08.32 Join matsl [0] (~matsl@dhcp102.contactor.se) 09.09.10 # bookmark text files? 09.09.11 # no 09.11.37 # darn! thanks tho midknight2k3 09.12.28 # guess i'll to convert wolves of calla to audio 09.12.29 # no problem 09.12.48 # although i suppose it could be done rather easily 09.14.09 # i'm afraid to ask how 09.14.25 # lol i mean by adding it as a feature 09.14.55 # oic 09.15.52 # i could give it a shot tomorrow 09.15.59 # yah i would prefer reading it to hearing MS Mary speak it 09.16.03 # but i'm not promising anything :) 09.16.22 # well i would appreciate it either at any cost 09.16.31 # i assume others would too 09.16.42 # yep 09.16.44 # i'll try 09.16.50 Nick midknight2k3 is now known as midk (~Zakk@c-24-18-39-169.client.comcast.net) 09.16.54 # not that rockbox isnt great already thanks to all you coders 09.17.05 # :) 09.17.46 # thanks i think dark tower 5 can wait one more night 09.18.14 Ctcp Ignored 2 channel CTCP requests in 29 minutes and 35 seconds at the last flood 09.18.14 # * midk feels the pressure 09.18.18 # i think i can do it 09.18.22 # i think i can i think i can 09.18.35 # no no i would just break it up into smaller text files if not 09.18.59 # no biggee just a thing of me being extremely lazy 09.19.41 # i appreciate the effort tho 09.20.43 # night :) 09.20.50 Quit monkey666 () 09.33.52 Quit matsl (truong.freenode.net irc.freenode.net) 09.33.52 NSplit truong.freenode.net irc.freenode.net 09.33.52 Quit Ka__ (truong.freenode.net irc.freenode.net) 09.33.52 Quit midk (truong.freenode.net irc.freenode.net) 09.33.52 Quit elinenbe (truong.freenode.net irc.freenode.net) 09.33.52 Quit adi|home (truong.freenode.net irc.freenode.net) 09.33.52 Quit Ka_ (truong.freenode.net irc.freenode.net) 09.35.38 NHeal truong.freenode.net irc.freenode.net 09.35.38 NJoin matsl [0] (~matsl@dhcp102.contactor.se) 09.36.46 NJoin midk [0] (~Zakk@c-24-18-39-169.client.comcast.net) 09.36.46 NJoin elinenbe [0] (trilluser@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 09.36.46 NJoin Ka_ [0] (~tkirk@pcp261336pcs.howard01.md.comcast.net) 09.36.46 NJoin Ka__ [0] (~tkirk@65.216.194.2) 09.36.46 NJoin adi|home [0] (~adi|home@as5300-9.216-194-23-72.nyc.ny.metconnect.net) 09.41.49 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 09.45.48 *** Saving seen data "./dancer.seen" 10.50.57 Quit midk ("yo yo yo yo yo") 11.08.18 Quit joshn (Read error: 110 (Connection timed out)) 11.45.49 *** Saving seen data "./dancer.seen" 12.11.38 Quit Nibbler (Read error: 54 (Connection reset by peer)) 12.36.53 Join track [0] (74d57721@ACBE26ED.ipt.aol.com) 12.36.56 Quit track (Read error: 54 (Connection reset by peer)) 13.17.42 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 13.38.21 Join amiconn [0] (~jens@pD95D1622.dip.t-dialin.net) 13.45.53 *** Saving seen data "./dancer.seen" 13.55.06 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 14.13.22 Quit AciD (Read error: 54 (Connection reset by peer)) 14.13.22 Quit Nibbler (Read error: 54 (Connection reset by peer)) 14.31.20 Join Sixer [0] (~sixer@psycholicious.net) 14.31.30 # G'day 14.31.42 # g'day 14.32.15 # I've had a problem with RockBoxX since 2.1, where when I play an mp3, I get "Error loading playlist" (Just "Error" under 2.2). Since 2.2, it even refuses to play the mp3 after that. Have got a Jukebox 6000. 14.32.17 # Any clues? 14.32.22 # (FAQ does not seem to cover this) 14.32.42 # The HD is accessible fine, no probs there 14.32.58 # I have a feeling that the jukebox is looking for a playlist I've never created 14.32.59 # are you playing a plylist or an individual mp3 ? 14.33.10 # An individual mp3, I don't have any playlists 14.33.42 # behind the scenes you are actually playing a playlist 14.33.45 # but.. 14.33.49 # ok. 14.34.00 # you have a .rockbox folder ? 14.34.00 # I've done an rm -rf .rockbox, to no avail 14.34.42 # rm - that's linux huh ? 14.34.52 # osx 14.35.08 # ahh, anyway.. 14.35.11 # you have a .rockbox folder ? 14.35.18 # rm -rf == remove recursively by force 14.35.23 # So nope I have deleted that folder 14.35.35 # you must have .rockbox 14.35.44 # interesting 14.35.47 # otherwise bad things might happen 14.36.16 # reinstall the .rockbox folder from the ZIP file 14.36.34 # Is there originally any content in that folder? 14.36.53 # yes. stuff like fonts etc 14.36.59 # fook 14.37.01 # ok 14.37.18 # when you play an mp3 it'll try and create a file in .rockbox to keep track of the playlist 14.37.34 # no .rockbox = no play 14.39.58 # You've been very helpful, cheers 14.40.24 # working ? 14.41.07 # yep 14.41.14 # good o 14.44.14 # heh funny, my jukebox6000 appears to have a newer firmware than mentioned on the archos website 14.44.36 # have you flashed ? 14.44.43 # nope 14.44.49 Join guest [0] (~joe@k3-507b.kn.vutbr.cz) 14.44.54 # hmm - 6000 is old now 14.44.58 # sure is 14.45.01 # * c0utta has a 6000 14.45.14 # Their site says 5.07a, my jukebox says 5.08 on boot 14.45.16 # now a 60000 14.45.44 # whoa, they did an iTunes plugin 14.46.11 # i think archos stopped updating their site for the 6000 14.46.30 # you mac guys love itunes, don't you ? 14.46.35 Part guest 14.46.38 # Yeah, sure do 14.46.51 # thought you'd have an ipod 14.47.07 # Well I got this thing as a xmas present from where I work 14.47.18 # good present! 14.47.22 # yeh definitely 14.47.27 # got an xbox this year ;) 14.47.35 # ( http://psycholicious.net/xbox ) 14.51.25 # good network 14.51.30 # heh cheers 14.52.13 # 4096! 14.52.59 # uh? 14.54.46 # 4096/256 14.55.21 # internet connection 14.56.59 # oh, yah 14.58.02 # 8192 later this year 14.58.57 # whoa, Archos' iTunes plugin for this is bloody excellent 15.02.30 # what page is this on ? 15.03.04 # bottom of http://archos.com/download/list_firmware.html 15.04.43 Join cjnr11 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) 15.06.32 Part cjnr11 15.17.59 Join mecraw_ [0] (~mecraw@65.211.151.3) 15.18.24 Part mecraw_ 15.20.45 Join sethians [0] (~jirc@200.87.85.81) 15.21.02 # hello 15.21.15 # hekki 15.21.15 # de 15.21.16 # de 15.21.24 # hello 15.21.36 # Hello, my HD has die 15.22.25 # what HD can I put in my jukebox (recorder 15.22.28 # :( 15.22.42 # any 9.5mm laptop drive 15.23.27 # mmm and wha about RPN ? 15.24.12 # RPM 15.39.22 Nick c0utta is now known as c0utta{zzZZ} (~c0utta@146.cust46.nsw.dsl.ozemail.com.au) 15.40.11 # sethians: there's no requirement i think 15.43.43 Part amiconn 15.43.44 Quit sethians (Read error: 104 (Connection reset by peer)) 15.45.57 *** Saving seen data "./dancer.seen" 15.55.18 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 16.13.29 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 16.21.56 Join methangas [0] (methangas@0x50c61d34.virnxx10.adsl-dhcp.tele.dk) 16.36.08 Join amiconn [0] (~jens@pD95D1622.dip.t-dialin.net) 17.34.07 Quit Nibbler (Read error: 54 (Connection reset by peer)) 17.34.22 Join mecraw__ [0] (~mecraw@12.106.130.3) 17.36.24 Join mecraw___ [0] (~mecraw@65.211.151.3) 17.36.44 Part mecraw___ 17.46.01 *** Saving seen data "./dancer.seen" 17.52.03 Join pfavr [0] (pfavr@t4o902p29.telia.com) 17.53.19 Quit mecraw__ (Read error: 110 (Connection timed out)) 18.14.49 Join stevenm [0] (~stevenm@pcp04424903pcs.nrockv01.md.comcast.net) 18.26.17 Join KnivesOut [0] (jirc@isu162155.ilstu.edu) 18.26.31 # hey guys 18.27.06 # i just read about the NEC battery that charges in 30 seconds 18.27.38 # i'm anxious to see this in my archos 18.29.41 Quit KnivesOut (Client Quit) 18.39.43 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 19.17.33 Join Nibbler [0] (~nibbler@port-212-202-73-124.reverse.qsc.de) 19.29.04 Join mattzz [0] (~mattzz@c231002.adsl.hansenet.de) 19.42.10 Join midknight2k3 [0] (ZakkRobert@c-24-18-39-169.client.comcast.net) 19.46.04 *** Saving seen data "./dancer.seen" 19.59.36 Quit stevenm (Remote closed the connection) 20.00.07 Quit MT ("changing servers") 20.12.36 Quit mattzz ("Client exiting") 20.13.19 Join _aLF [0] (~alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) 20.14.00 # <_aLF> hi 20.18.29 Quit matsl (Remote closed the connection) 20.20.55 Join cjnr11 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) 20.20.57 Part cjnr11 20.25.00 Quit pfavr (Read error: 110 (Connection timed out)) 20.34.00 Join cjnr11 [0] (dfd@bobillot-5-82-224-193-23.fbx.proxad.net) 20.34.04 Part cjnr11 21.27.35 Part Sixer 21.44.35 Join scott666 [0] (scott666@c-24-245-58-245.mn.client2.attbi.com) 21.46.05 *** Saving seen data "./dancer.seen" 21.52.39 Join Frosh [0] (~frosh@rrcs-midsouth-24-199-152-33.biz.rr.com) 21.54.19 # On the Archos website it says that the USB cable used with their players is specific to the device. Is it true that I can't just use any old USB cable? 21.54.55 # i think ne cable should be fine.... 21.55.06 # (as long as its usb 2.0 for usb 2.0 devices...) 21.55.17 # thats why it is "usb" 21.55.27 # That's what I was thinking, too. UNIVERSAL serial bus, you know? 21.55.40 # ;-) 21.56.21 # I'd much rather get a spare 99-cent generic cable than purchase one of those overpriced "proprietary" ones from Archos. :P 21.58.39 # Frosh: model? 21.58.46 # Studio. 21.59.57 # any will work 22.00.27 # Good. Thanks. :) 22.03.55 Quit Frosh ("Yeah, it's like that.") 22.08.36 Quit midknight2k3 (Read error: 104 (Connection reset by peer)) 22.11.17 Join midknight2k3 [0] (~midknight@c-24-18-39-169.client.comcast.net) 22.12.56 Join ricII [0] (~ricv@lindad.demon.nl) 22.12.57 Quit Dogger (Read error: 104 (Connection reset by peer)) 22.13.25 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 22.20.29 Quit Dogger (Read error: 104 (Connection reset by peer)) 22.20.41 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 22.22.02 Quit Dogger (Read error: 54 (Connection reset by peer)) 22.22.38 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 22.33.28 Quit AciD (Read error: 104 (Connection reset by peer)) 22.33.46 Join AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) 22.34.31 Quit methangas (" Like VS.net's GUI? Then try HydraIRC -> http://www.hydrairc.com <-") 22.52.54 Join [IDC]Dragon [0] (~idc-drago@pD9FF8F96.dip.t-dialin.net) 22.53.09 # hi Jörg! 22.53.39 # <[IDC]Dragon> Good evening Jens, for a short one today. 22.53.58 # <[IDC]Dragon> (Have to leave again soon) 22.54.06 # I'm almost done with my grayscale framework :-)) 22.54.15 # <[IDC]Dragon> how does it work? 22.54.48 # (only one missing graphic primitive) Looks nice now, although it was harder than I thought at first. 22.54.48 Quit Dogger (Read error: 104 (Connection reset by peer)) 22.55.12 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 22.55.20 # <[IDC]Dragon> purely plugin, or some IRAM code for dithering? 22.55.21 # yo 22.55.43 # idc: by the way, what sort of data does lcd_blit accept? 22.56.53 # proprietary format 22.56.53 # ? 22.56.53 # [IDC]Dragon: 100% pure plugin. 22.56.53 # <[IDC]Dragon> the physicaldisplay format 22.56.53 # <[IDC]Dragon> bmp2rockbox 22.56.57 # The biggest problem was, that if you have a sequence of frames that are cycled, every pixel is represented by a bit sequence within these. 22.57.14 # idc: the same type of data that comes out of bmp2rb? 22.57.23 # <[IDC]Dragon> midknight2k3: yes 22.57.33 # but then how would it know what was gray and not? 22.57.35 # If the "phase" of these sequences is eual for all pixels, you get evil flickering. 22.57.47 # or is that integrated into the output too? 22.58.04 # <[IDC]Dragon> midknight2k3: this is pure b/w 22.58.04 Quit Dogger (Read error: 104 (Connection reset by peer)) 22.58.11 # OH right 22.58.19 # flickers between them 22.58.30 # <[IDC]Dragon> amiconn: you have to seed with a random phase 22.58.32 # * midknight2k3 is somewhat confused 22.58.34 # If you shift the phases by a regular pattern, you get moire. 22.58.46 # you can flicker between two frames right? 22.58.56 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 22.58.58 # <[IDC]Dragon> midknight2k3: or more, yes 22.59.17 # So I have to set _every_ pixel individually with a random phase. This is what I do now. 22.59.42 # <[IDC]Dragon> amiconn: I had the same pronlem with the stills 22.59.57 # <[IDC]Dragon> looks bumpy on the boundary 23.00.27 # idc: so then, blit accepts one array of data. how would you give it two frames? 23.00.57 # <[IDC]Dragon> midknight2k3: you have to swich them 23.01.07 # midknight2k3: If you want grayscale for a plugin, wait for my grayscale framework. I will post a plugin to the patch tracker which will contain that and some simple example calls. 23.01.08 # so keep changing what's in the array? 23.01.22 # amiconn: grest, thanks 23.01.24 # it's a possibilty 23.01.44 # <[IDC]Dragon> amiconn: do you switch pixels as often as possible? 23.01.54 # The framework allows 2..33 scales of gray 23.02.13 # [IDC]Dragon: I switch frames at 67 Hz. 23.02.31 # <[IDC]Dragon> e.g. 50% gray is not 4 times black, then 4 times white 23.03.16 # <[IDC]Dragon> but alternating every time 23.04.31 # Yes, 50% gray alternates every time. The patterns are calculated in a way that the bit values that is needed less does never appear twice in a row. 23.04.51 # <[IDC]Dragon> aha. 23.05.26 # <[IDC]Dragon> I have an inteper implementationof my halftoning algorithm, as I've "advertized" to you before. 23.05.46 # E.g 25% gray = 11101110..., 50% gray = 1010..., 75% gray = 10001000... etc. 23.05.57 # is it ever going to be possible, do you know, to be able to simply play bitmap files? 23.06.08 # <[IDC]Dragon> how do you calculate these? 23.06.36 # <[IDC]Dragon> midknight2k3: I have a half-done JPEG viewer 23.06.44 # ooh! 23.06.49 # that could work fine! :) 23.06.51 # unsigned long pattern = 0; 23.06.51 # int value = 0; 23.06.51 # for (j = 0; j < graybuf->depth; j++) 23.06.51 DBUG Enqueued KICK amiconn 23.06.51 # { 23.06.51 # pattern <<= 1; 23.06.52 *** Alert Mode level 1 23.06.52 # value += i; 23.06.54 # if (value >= graybuf->depth) 23.06.56 # value -= graybuf->depth; 23.06.58 # else 23.07.00 # pattern |= 1; 23.08.13 # Btw: i runs from 0 to graybuf_depth and is the desired brightness. 23.09.16 # <[IDC]Dragon> I'll wait for the final version, don't understand this. 23.09.49 # midknight2k3: With my grayscale framework it should be possible to write a bmp viewer. It would even be possible to view pictures while the music is playing if it is done clever. 23.10.01 # ooh! 23.10.04 # yayaya 23.10.08 # go idc and amiconn 23.10.08 # <[IDC]Dragon> you have i and j ? 23.10.51 # <[IDC]Dragon> guess I have to implement that timer function soon, to prevent hardware banging in plugins 23.11.11 # Yes, this routine is for precalculation of the patterns for all possible brightnesses. It is executed when you call get_graybuf(). 23.11.49 # I'm using timer 4 (the same as you in your video plugin). 23.11.58 # <[IDC]Dragon> later you need to collect 8 pixels again to get a screen byte 23.11.58 Quit Dogger (Read error: 54 (Connection reset by peer)) 23.12.10 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 23.12.35 # <[IDC]Dragon> (afk for a minute) 23.12.44 # The problem is, that all bits that correspond to a screen pixel are scattered across different bytes. 23.13.26 # So there is a lot of bit masking and wild addressing of the different planes. 23.14.08 # To get this reasonably fast, the core function graypixel() is assembler optimized (what did you expect from me?). 23.15.25 # It takes ~1.3 sec to set 3/4 of the screen pixel by pixel. 23.16.53 *** Alert Mode OFF 23.18.54 # <[IDC]Dragon> phew 23.19.05 # phew? 23.19.35 # <[IDC]Dragon> a strenuous operation 23.19.51 # <[IDC]Dragon> so 1.3 sec for haltoning ang re-arranging? 23.19.58 # <[IDC]Dragon> and 23.21.57 # This is for calling gray_drawpixel(int x, int y, int brightness) for a total of 5376 pixels (3/4 of the screen). 23.22.46 # (When using the maximum number of 33 scales of gray. When using less grayscales it get faster) 23.23.15 # *gets 23.23.21 # <[IDC]Dragon> a function call for each pixel? 23.24.12 # Yes, necessary even for rectangles, becauses the phase of the bit pattern has to be shifted randomly for every pixel. 23.24.38 # <[IDC]Dragon> are you using rand() for that? 23.24.43 # yup. 23.24.51 # <[IDC]Dragon> I heared it's slow 23.25.15 # <[IDC]Dragon> but a high-end random generator 23.25.22 # My observation is that rand() cosumes about 1/2 of the total time it takes. 23.25.26 # <[IDC]Dragon> very random ;-) 23.25.47 # <[IDC]Dragon> maybe you should do your own 23.26.17 # Btw: The timing figures I gave were takes while the interrupt was running. This consumes ~50 % CPU time. 23.26.27 # *taken 23.26.29 # <[IDC]Dragon> I know, yes 23.27.02 # <[IDC]Dragon> you can use one rand() to get bits for several pixels 23.27.15 # So if you have to draw a lot and don't care about the display, you can switch it off while drawing. 23.28.04 # No, I can't. This way the phase of these pixels would be equal -> flicker 23.28.47 # <[IDC]Dragon> you didn't get me, i think. 23.28.53 # <[IDC]Dragon> if you do rand(), you get 16 (?) bits 23.29.04 # rand() gives 31 bits. 23.29.09 # <[IDC]Dragon> for each pixel, you need up to 5 23.29.57 # <[IDC]Dragon> so you can split the result and use fractions for several pixel. 23.30.39 # But this way I would have to calculate the bit pattern for the pixel from these bits, which is slower than precalculating the patterns and using the rand() result only for shifting. 23.32.11 # <[IDC]Dragon> all I mean is buffering the Rand() result, since you don't need all the digits, and instead call it only every 4 times or so. 23.32.35 # Oops, perhaps this is nevertheless a good idea: I could have a "random bits reservoir" which I shift by 5 bits to get my random value and refill only every 5 calls. 23.32.50 # <[IDC]Dragon> In the meantime, shift the results to get your next bits, until consumed. 23.33.05 # <[IDC]Dragon> That's what I meant. 23.33.05 Quit Dogger (Read error: 104 (Connection reset by peer)) 23.33.19 # Ok, will try this. 23.33.22 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 23.33.54 # <[IDC]Dragon> you rotate your bit pattern, right? 23.34.18 # No, I don't rotate beforehand. 23.34.41 # <[IDC]Dragon> I mean rotate by the random phase 23.35.09 # I decide from the random value in which bit plane I shoud start, then go up to the last and finally do from the first to the one before my starting point. 23.35.36 # <[IDC]Dragon> so the "seam" will be on different planes for each pixel? 23.35.51 # yup. 23.36.08 Join LinusN [200] (~linus@labb.contactor.se) 23.36.18 # hi LinusN! 23.36.25 # <[IDC]Dragon> you can as well rotate your pattern by random, then walk from plane 0 to n. 23.36.35 # <[IDC]Dragon> Hi LinusN 23.36.40 # yo 23.36.49 # <[IDC]Dragon> I was just about to leave... 23.37.26 # <[IDC]Dragon> You do this on purpose, so I'm tired at work, and you've weakened germanies economy 23.37.37 # of course 23.37.51 # <[IDC]Dragon> very subtle 23.38.03 # [IDC]Dragon: Rotating would take longer (this was what I considered first) because you have to shift out while setting the planes anyway. 23.38.17 # <[IDC]Dragon> OK. 23.38.19 # i work at the DOEP, Department Of Evil Plans 23.38.42 # <[IDC]Dragon> together with Dogbert? 23.39.02 # Catbert!? 23.39.02 Quit Dogger (Read error: 104 (Connection reset by peer)) 23.39.02 # he's my boss 23.39.24 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 23.39.29 # <[IDC]Dragon> you're on vacation? 23.39.51 # yup 23.40.03 # yup 23.40.09 # laptop + shitty v.90 modem 23.40.29 # <[IDC]Dragon> on some remote place, with a notebook and a satellite dish? 23.40.38 # nope 23.41.06 # <[IDC]Dragon> fast enough for IRC 23.42.05 # i'm on an island on the west coast of Sweden 23.42.45 # <[IDC]Dragon> what are you doing in here then? 23.42.51 # <[IDC]Dragon> Go fishing! 23.43.25 # in the middle of the night? it's damn dark and cold :-) 23.43.40 # LinusN! 23.44.17 # <[IDC]Dragon> Don't they bite better then, easy to attract with light? (I'm no expert) 23.44.43 # we usually catch salmon in the night, with a net 23.44.53 # it's not really season yet 23.44.59 # <[IDC]Dragon> If we can't persuade you, you'll have to anwer stupid questions: 23.45.19 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 23.45.19 # * LinusN goes to the boat 23.45.33 # LinusN, for some rason bmp2rb is seeing my bitmap inverted 23.45.35 # any ideas? 23.45.38 # reason* 23.45.41 # yes 23.45.46 # <[IDC]Dragon> 1) any particular reason against recursuve directory deletion? 23.45.57 # [IDC]Dragon: 1) no 23.46.05 # <[IDC]Dragon> I miss that 23.46.05 # LinusN, do you know why? 23.46.08 *** Saving seen data "./dancer.seen" 23.46.14 # "yes" to me or to idc? 23.46.19 # midknight2k3: your pallette is inversed in the bitmap 23.46.38 # the bitmap itself is in the correct way 23.46.55 # <[IDC]Dragon> 2) how about sorting dirs by date? 23.47.05 # 2) Sure, why not? 23.47.15 # midknight2k3: you mean it looks correct in Paint? 23.47.21 # <[IDC]Dragon> we don't store it yet, right? 23.47.23 # well gimp at this point 23.47.32 # but i did save it in paint yes 23.47.40 # [IDC]Dragon: i don't think so 23.47.46 # <[IDC]Dragon> so the dircache will grow 23.48.06 # midknight2k3: just invert the bitmap before you convert 23.48.13 # [IDC]Dragon: probably 23.48.15 # do you know why it's doing this? a bug? 23.48.34 # midknight2k3: no, it's not a bug 23.48.54 # the pain application can define the palette in any way it wants 23.48.57 # just made tha way? 23.48.59 # paint 23.49.17 # um, do you how know i can invert it in the gimp? 23.49.25 # the bmp2rb tool doesn't care about the palette 23.49.32 # midknight2k3: nope 23.49.34 # aha 23.49.36 # got it 23.49.39 # good 23.49.40 # well anyhow 23.49.42 # <[IDC]Dragon> LinusN: can your delete function wipe (empty?) directories? 23.49.46 # i've got a huge clock update 23.50.16 # [IDC]Dragon: it won't free the fat entries for the files in it 23.50.48 # <[IDC]Dragon> so the dir has to be empty, that's what I meant 23.50.52 # you'll have to recursively delete each file 23.50.55 # yes 23.51.00 # <[IDC]Dragon> np 23.51.13 # would be great if you implemented that feature 23.51.18 # been missing for so long 23.51.43 # <[IDC]Dragon> yes' I'd like to delete unworthy albums 23.51.51 # gah! 23.52.59 # <[IDC]Dragon> soon Rockbox will hit the 200k barrier again 23.53.43 # <[IDC]Dragon> maybe we can do an option cleaning day 23.54.54 # i'm about to move the VBR fixer to a plugin 23.54.54 Quit Dogger (Read error: 54 (Connection reset by peer)) 23.54.58 # <[IDC]Dragon> when I did the voice menu and saw all the options and their granularity, I couldn't believe it 23.55.40 # <[IDC]Dragon> is VBR fix large? 23.55.52 Join Dogger [0] (~jimmy@cpc3-colc1-5-0-cust240.colc.cable.ntl.com) 23.55.53 # not really 23.56.29 # <[IDC]Dragon> a table-driven config load/save could save substantially, I guess 23.56.37 # absolutely 23.56.57 # LinusN: I did my overnight test recording (a whopping 742 MB recorded in over 10 hours at q=7, f=44.1kHz, stereo). I did not find a single error in the frame structure. 23.57.14 # amiconn: good for you :-) 23.57.32 # <[IDC]Dragon> sarcasm? 23.57.39 # nah 23.58.14 # amiconn: you want some logic analyzer traces? 23.58.28 # Btw: mp3fixer doesn't work correctly! It reports errors where there are none! Verified myself by looking into the given position with a hex editor. 23.58.49 # <[IDC]Dragon> Well, at 200k the game is as follows: anybody who wants to implement a feature has to optimize the rest such that the new stuff fits. 23.58.51 # oh