--- Log for 16.09.105 Server: herbert.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 15 days and 18 hours ago 00.04.09 # Looks like I was wrong 00.04.55 # http://www.davechapman.f2s.com/rockbox/radio.c.patch.txt 00.06.13 Join StrathAFK [0] (n=mike@dpc674681214.direcpc.com) 00.07.16 Quit Strath (Nick collision from services.) 00.07.52 Nick StrathAFK is now known as strath (n=mike@dpc674681214.direcpc.com) 00.10.00 *** Saving seen data "./dancer.seen" 00.18.52 Quit ender` (Read error: 110 (Connection timed out)) 00.22.58 Join stripwax [0] (n=stripwax@i-83-67-214-206.freedom2surf.net) 00.23.05 # hey 00.24.49 # so today the iriver went back to iRiver Europe, lets hope they can fix it. I managed to get it to turn on one more time before it went out for the count, and took the opportunity to reflash with an iriver firmware just in case ;-) 00.26.16 # heh 00.26.30 Quit ashridah ("damn. uni.") 00.28.28 Quit Mojito () 00.29.05 Part stripwax 00.34.58 Join jonash [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) 00.35.11 Join Sucka [0] (n=NNSCRIPT@host81-156-208-141.range81-156.btcentralplus.com) 00.35.27 Quit rasher (Read error: 110 (Connection timed out)) 00.36.25 Quit Sucka (Client Quit) 00.51.15 Quit webguest84 ("CGI:IRC (EOF)") 00.54.28 Quit AliasCoffee ("bbl") 00.54.42 Join bagawk [0] (i=1000@unaffiliated/bagawk) 00.55.20 Part ep0ch ("Kopete 0.10.3 : http://kopete.kde.org") 00.59.26 Quit Moos ("Parti") 01.05.56 Quit cv_ (Read error: 110 (Connection timed out)) 01.07.11 Quit markun () 01.15.50 Quit matsl (Remote closed the connection) 01.16.04 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.36.01 Nick jonash is now known as rasher (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) 01.36.17 # linuxstb: so why wasn't the iriver-radio change submitted? 01.38.39 # rasher: No-one said yes. 01.38.59 # I'm happy to wait until 2.5 is released. 01.39.17 # Ah 01.39.21 # Should be RSN 01.39.57 # Yes - it's been RSN for the last couple of days. But amiconn and LinusN have the final say - they are doing the work. 01.40.41 # RSN?? 01.40.46 # Real Soon Now 01.40.54 # (as in, not really, but it might be!) 01.41.01 # ah thx 01.41.15 # I suspect it's in the jargon file 01.41.26 # The radio change for iriver isn't really a new feature 01.42.33 # But the general opinion (rightly or wrongly) seems to have been to leave the iriver port alone and not commit anything that isn't a strict bug-fix. 01.42.57 # Ah yes, http://www.catb.org/~esr/jargon/html/R/Real-Soon-Now.html 01.43.58 # linuxstb: I think that was the initial opinion. Mostly to not give people ideas. But when it came to actually deciding, the policy was less strict. 01.44.02 # linuxstb: It's a feature freeze, not a code freeze. Many things I've done aren't strictly bug fixes, but optimisations 01.44.08 # Nobody vetoed... 01.44.51 # I think the freeze has been fairly well handled. 01.45.00 # Somebody please explain gcc's opinions about code placement... they're sometimes strange... 01.45.17 # * amiconn is currently investigating a new recording transfer loop for archos 01.48.56 # Doesn't sound like my idea of fun. (at least if gcc is getting in the way) 01.49.17 # Meh, I *hate* acoustic feedback :( 01.52.55 # rasher: It doesn't get in the way, but I wanted to check what gcc produced from my C code. One snippet puzzled me, it even looked like unreachable code. 01.53.35 # Turned out gcc "displaced" this code into a gap outside the normal flow 01.55.01 # Interesting 02.08.43 Quit gromit` (Read error: 104 (Connection reset by peer)) 02.08.47 Join gromit` [0] (i=gromit@ras75-5-82-234-244-69.fbx.proxad.net) 02.10.02 *** Saving seen data "./dancer.seen" 02.12.14 Quit gromit` (Read error: 104 (Connection reset by peer)) 02.14.39 # Maybe it just made more sense from the compiler's viewpoint 02.16.11 # And isn't some clever plot 02.20.52 Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 02.21.23 Join gromit` [0] (i=gromit@ras75-5-82-234-244-69.fbx.proxad.net) 02.29.26 Quit bagawk ("Leaving") 02.32.50 Quit lImbus (Read error: 110 (Connection timed out)) 03.30.35 Quit rasher ("Ex-Chat") 03.37.20 Quit cYmen ("zZz") 04.05.59 Join QT_ [0] (i=as@madwifi/users/area51) 04.10.03 *** Saving seen data "./dancer.seen" 04.17.04 Quit QT (No route to host) 06.10.07 *** Saving seen data "./dancer.seen" 06.54.02 # pfletg 06.54.20 Quit preglow ("g") 07.03.31 Join LinusN [0] (n=linus@labb.contactor.se) 07.10.25 # Morning 07.15.43 # *yawns* 07.15.44 # morning 07.18.11 # shalom 07.19.28 # LinusN: Did you read the log? If not, http://www.rockbox.org/irc/rockbox-20050915.txt , starting 20:21 07.20.06 # saw that 07.20.27 # I wonder what we're doing wrong... :( 07.20.42 # i have no ida 07.20.44 # idea 07.21.37 # we could try without the peak meter 07.21.59 # Archos also has a peakmeter 07.22.16 # i know... 07.22.26 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 07.23.19 # The question is how often they peek, but then we already had a low peek rate for a while 07.24.27 # I also tried a modified transfer loop. Same result, recording gets shiften after a while 07.25.19 # 2 bits to the left after a little more than 30 minutes this time 07.25.57 # really annoying 07.26.35 # a bit shift sounds like a glitch on a serial bus 07.26.41 # inside the mas 07.29.42 # hmmm 07.30.53 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 07.32.07 # LinusN: It would be really interesting what happens at the point of failure transfer-wise, but afaik logic analyzers aren't capable of long-term recording (?) 07.32.38 # With transfer-wise I mean both the parallel port DMA and I²C 07.33.05 # they are, but myine is a cheap one, with limited triggering capabilities 07.33.09 # mine 07.34.00 # What we would need here would be capturing everything during a long recording. YOu'll never know in advance at which point the glitch will happen 07.34.11 # true 07.34.12 # long recording means at least 2 hours 07.35.49 Quit linuxstb (Read error: 113 (No route to host)) 07.39.08 # amiconn: do you have disk poweroff activated? 07.39.29 # i can imagine that a voltage dip could cause a clock slip in the mas 07.44.50 # I have disk poweroff enabled all the time... 07.45.53 # Could be interesting to logf() the spinup/-down times 07.46.10 # ...and compare that to a glitch point in a test recording 07.46.27 # I should do tests on the Ondio as well... 07.47.57 # Hmm, but how does that match the pattern that the probability of the glitch depends both on quality setting and recording level? 07.50.49 # perhaps more power is drawn/needed by the dsp? 07.52.05 # or the internal serial bus is faster at higher q levels 07.52.21 # recording level will surely affect the voltage 07.53.39 # Hmm, but archos also spins up/down the disk. I would think the voltage dip from spinup is "harder" than the one from drive poweron? 07.53.56 # i suspect the opposite 07.54.22 # i thought the archos didn't spin down the disk... 07.55.03 # It does 07.55.21 # Why do you suspect the voltage dip from poweron being harder? 07.55.44 # Idle current of the disk is around 10 mA, spinup current can easily exceed 1 A... 07.56.19 # the entire drive is powered on instead of just the motor and some other stuff 07.57.01 # Hmm. Can we measure that somehow? 07.57.14 # guess so, with an oscilloscope 07.57.25 # Btw, all my test recordings are done with the charger connected 07.57.26 # we could measure the voltage and see if it dips 07.58.10 # My next test recording will probably be without code modification, but disk poweroff disabled 07.58.17 # afaik, archos uses STANDBY instead of SLEEP 07.58.28 # ...perhaps in parallel with an Ondio test recording 08.00.26 # * LinusN heads off to the lab 08.10.08 *** Saving seen data "./dancer.seen" 08.28.22 # * B4gder reads "Efficient programming techniques for ARM.pdf" - nothing's like the smell of assembler in the morning 08.34.07 # sounds freaky 08.37.15 # arm is slightly more advanced than coldfire 08.39.52 # which makes it even more... freaky? :) 08.41.55 # hehe, I guess so 08.56.07 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 09.07.51 Nick Lynx_awy is now known as Lynx_ (n=lynx@tina-10-4.genetik.uni-koeln.de) 09.35.40 Join ashridah [0] (i=ashridah@220-253-121-215.VIC.netspace.net.au) 09.43.30 # * B4gder reads ipodlinux source code 09.43.47 # anything fun? 09.44.01 # they're not making it easy for us 09.44.17 # * since the interrupt vectors at 0x0 are now installed 09.44.17 # * we can wake up the COP safely 09.44.17 # */ 09.44.17 DBUG Enqueued KICK B4gder 09.44.17 # outl(0xce, 0xcf004058); 09.44.47 # haha 09.44.48 # using fixed numbers in the code with no real descriptions 09.46.41 # and almost everything is more than 14 months old 09.47.02 # which seems wrong 09.47.21 # yes, surely there has been some work the last 14 months? 09.48.01 # not committed in the linux area 09.48.26 # I guess they focus on apps 09.50.07 # LDFLAGS=-elf2flt 09.50.14 # what's that for? 09.52.12 # I also noticed that they don't have usb working 09.52.19 # on any model 09.53.27 # B4gder: Are you thinking about buying an ipod as well? 09.53.37 # I do 09.53.49 # for Rockboxing 09.54.16 # Mine should hopefully arrive tomorrow morning. 09.54.21 # :-) 09.54.47 # a 4g one? 09.55.28 # Yep - a 60GB Photo. 09.55.40 # aha, color... 09.55.42 # PP5020 based I hope. 09.55.52 # That seems the most widely used processor. 09.56.09 # yes 09.56.38 # Bagder: elf2flt seems to just be a convoluted way of avoiding using objdump 09.57.26 # aha 09.57.33 # can't say I understand why. really. source at: cvs -d:pserver:anonymous@cvs.uclinux.org:/var/cvs co elf2flt 09.59.33 # and http://cvs.uclinux.org/cgi-bin/cvsweb.cgi/elf2flt/ for web access 09.59.50 # ah 10.08.49 # Any idea if the iPod has a hardware OFF or reset button? 10.09.57 # I think its hw somehow, since ipodlinux's progress page says they don't have power management 10.10.09 *** No seen item changed, no save performed. 10.10.25 # maybe they just mean cpu throttling 10.10.29 # I've never seen nor touched one in real life actually ;-) 10.10.37 # Nor have I :) 10.10.46 # The blind leading the blind... 10.11.11 # brace for itunes barrage... 10.11.50 # you guys are working on rockbox for ipod? 10.11.51 # nifty 10.12.02 # Zagor: you can avoid that 10.12.14 # there are open source hacks that write the db format 10.12.23 # yeah, i know 10.12.31 # but then, rockbox doesn't need itunes ;-) 10.13.07 # I'm sure Rockbox will only appeal to people who don't use itunes. 10.13.28 # most probably, yes 10.16.01 # otoh we'll get someone working on itunes support in no time if we start making ipod noises 10.16.21 # people love that program, for some reason 10.16.57 # Yes, I think developers for the apps/ side of the project will be plentiful, once Rockbox is working. 10.17.13 # so, do we hold 2.5 for it then? ;) 10.17.18 # hehehe 10.19.31 # Reading the logs for #ipodlinux, it seems they are having problems with some of the latest colour LCDs... 10.20.29 # I wonder where they have the driver 10.20.34 # http://cvs.sourceforge.net/viewcvs.py/ipodlinux/linux-2.6/drivers/video/ 10.20.49 # There's also some code in the bootloader - to display Tux. 10.20.58 # "first cut iPod port" doesn't sound like the all-covering lcd code 10.24.10 # yes, here: http://cvs.sourceforge.net/viewcvs.py/ipodlinux/tools/ipodloader/tools.c?view=markup 10.24.56 # but that doesn't seem to be adjusted for the color lcds 10.26.37 # just look at that code: 10.26.45 # outl(inl(0x6000d014) & ~0x10, 0x6000d014); 10.27.09 # hehe 10.27.15 # and no comments at all 10.27.21 # gotta love it 10.31.35 # B4gder: our code isn't *that* much better 10.31.41 # no 10.31.49 # but we have a lot more docs 10.32.02 # on the hardware 10.32.10 # port pin maps etc 10.34.25 # LinusN: At least we use macros for most of the port addresses, which tell the purpose 10.37.50 Join amiconn_ [0] (n=jens@p54BD5543.dip.t-dialin.net) 10.40.48 # amiconn: yes 10.42.26 Quit amiconn (Nick collision from services.) 10.42.26 Nick amiconn_ is now known as amiconn (n=jens@p54BD5543.dip.t-dialin.net) 10.45.34 # B4gder: Have you found any references to which version of gcc the ipodlinux people are using? 10.45.43 # no 10.45.47 # just arm-elf 10.46.31 # why not just ask them? 10.47.07 # they recommend 2.95.3(!) for the kernel build 10.47.15 # From what I can tell, I think they use a special gcc required for uclinux 10.48.04 # but I believe that is a kernel requirement and not really required by others 10.48.15 # the gcc on arm has been really bad for kernel builds 10.48.34 # the gcc situation I should say 10.50.44 # Yes, it's a patched version of 2.95.3 - it's all in this script: http://uclinux.org/pub/uClinux/arm-elf-tools/tools-20030314/build-uclinux-tools.sh 10.51.04 # huh? 10.51.48 # I recently built an arm linux system mostly from scratch with gcc 3.4.something 10.52.14 # including a kernel 10.52.15 # yes, they've sorted out most of the things in the 3.4 branch 10.52.47 # just because it worked for you doesn't mean there aren't any problems left you know ;-) 10.53.09 # (I used to hang out on the arm-linux-kernel list) 10.54.35 # they even use a binutils patch, against 2.10 10.55.09 # linuxstb_: you sure they still use this? 10.55.09 # Gotta go now. See you later. 10.55.28 # It's what's listed in the Wiki: http://ipodlinux.org/Toolchain 10.55.32 # ok 10.55.57 Quit linuxstb_ ("Leaving") 11.01.57 Join ender` [0] (i=ychat@84.52.165.220) 11.05.11 Part gromit` 11.23.33 Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) 11.39.05 Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) 11.58.00 Join linuxstb [0] (n=linuxstb@213.86.218.27) 12.01.02 Quit Maxime (Read error: 110 (Connection timed out)) 12.10.12 *** Saving seen data "./dancer.seen" 12.35.58 Join webguest35 [0] (n=d5ee4f7b@labb.contactor.se) 12.54.49 Join pengo [0] (n=xtofu@60.240.136.82) 12.55.15 # just installed rockbox on my iriver ihp120 for the first time.. wow. 12.55.48 # welcome to rockbox world! 12.56.25 # thank you 12.56.56 # the site says it can't do flac in realtime but it seems fine to me ..? 12.57.34 # I believe there are some problems with some specific compression levels or similar 12.57.41 # or perhaps they've been fixed as well 12.58.19 # ah k 12.58.31 # i haven't tried a wide range of files 12.58.50 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 12.58.50 # * B4gder has never tried flac at all ;-) 13.01.32 # B4gder: Supporting the ipod will be "fun". Two different filesystems. Happy HFS+ing 13.01.41 # fat32 13.01.47 # and scrap the rest 13.02.36 # until some lunatic writes hfs support ;-) 13.04.32 # the good part about ipod is that no flashing is involved 13.07.04 # i guess it'd be non-trivial to take an hfs+ driver from linux 13.07.11 # * amiconn is curious how long the apple firmware on ipod needs to boot, and how ipodlinux compares to that 13.07.11 # yes 13.07.33 # pengo: linux code is generally a lot more complicated than the rockbox version 13.07.47 # yah 13.07.49 # comparing for example the fat32 code 13.07.51 # I don't like the disk boot. It has an inherent boot speed limit 13.08.06 # amiconn: yes, but it makes hacking the unit so much safer 13.08.11 # Even rockbox on H1x0 boots a little slow for my taste 13.08.39 # * amiconn wants firmware_flash.rock supoort for H1x0 13.09.05 # how big is the (flash) rom? 13.10.23 # 2MB iirc 13.10.32 # in the h1x0 13.17.11 # Hmm. Supporting ipods will be loads and loads of work with all the differing hardware across generations 13.17.55 # sure 13.18.45 # ipodlinux seems to do everything using run-time hardware detection. 13.19.26 # is it possible to record from FM on the h120 ? (in actuality or in theory?) 13.19.37 # both 13.19.41 # cool 13.19.51 # wasn't there some interference issue 13.19.52 # ? 13.19.58 # from the harddrive or something 13.21.18 # Mac users can definitely use FAT32 ipods - but they obviously need to do the initial setup from a PC. 13.21.25 Quit edx (Read error: 110 (Connection timed out)) 13.29.50 # Rick: perhaps, but you can still record 13.34.33 Quit Lynx_ (Read error: 110 (Connection timed out)) 13.38.28 Join Lynx_ [0] (n=lynx@tina-10-4.genetik.uni-koeln.de) 13.43.36 Quit ashridah ("Leaving") 14.10.15 *** Saving seen data "./dancer.seen" 14.18.44 Join datadevil [0] (n=maartens@datadevil.demon.nl) 14.18.46 # hi 14.19.13 # hey datadevil :) 14.19.33 # i'm considering getting a new mp3 player, and like the H10 so far. I know it doesnt do rockbox yet, so is there any support coming up or are there alternative players with approx the same price to get that do support it? 14.20.33 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 14.21.07 Nick QT_ is now known as QT (i=as@madwifi/users/area51) 14.21.22 # no H10 support is planned 14.22.45 # rockbox currently does not run on any player still in production... :-) 14.23.07 # old mp3 players rock :) 14.23.18 # but as it seems to have PortalPlayer chipset.. 14.23.29 # or is there no work on the iPod either? 14.23.49 # datadevil: no. there's some talk about it, but noone has even bought an ipod yet. 14.24.30 # hi! 14.24.50 # i was reading a report about the new nano player from apple. what a nice gadget :-) 14.24.51 # someone buy someone an ipod already 14.24.51 # portalplayer is a pain, since their chipset docs are secret 14.25.41 # zagor: i thought ipods were selling by the millions ;-) 14.25.57 # well, not to rockbox users (or developers) 14.26.01 # ahh ;-) 14.26.38 # I've just bought an ipod - I should receive it tomorrow or Monday. 14.27.25 # linuxstb, you a rockbox devver? 14.27.36 # i'm still in doubt as to wether to buy the h10 or the nano 14.27.41 # leaning towards the h10 14.29.25 # pengo: Yes. 14.29.45 # I think I could be called that. 14.30.03 # linuxstb: you are the ipod pioneer ;) 14.31.45 # hehe. I think it just needs someone to make a small start, and that's my plan. Hopefully others will follow. 14.31.47 # there seems to be a lot of code in something simple like chessclock.c 14.33.21 # linuxstb: which one did you buy? 14.33.36 # i still have a 2G ipod with 20GB, but i hardly use it 14.34.10 # is it too impatient to ask about the release date? ;-) 14.34.31 # nahh 14.34.34 # one can always ask 14.34.51 # the ID Software reply might be the one you get; 'when its done' 14.35.28 # yeah, that's right. i know this answer when asking for the release date of Debian Stable :) 14.37.06 # "when it's done" is sometimes better than "real soon now" 14.38.32 # QT: A 60GB color model. 14.38.59 # what would you guys recommend when buying an mp3 player for around 200 euros/dollars 14.39.31 # So it's a 4G model. It's seems there are now two types of color LCDs in use on iPods, one is understood by the ipodlinux people, one is not (yet). 14.39.59 # So the first task will probably to get the new type of LCD working (assuming my iPod has the new type of LCD). 14.40.31 # datadevil: depends on your needs I'd say 14.40.37 # linuxstb: sounds nice 14.42.10 # i find it a pain to have an ipod without dock connector as all the accessoires are now made for this 14.42.42 # QT: my needs are ease of use with linux, and maybe hackability 14.42.55 # I'm completely new to the ipod world, so I guess I'll find out about the annoyances. 14.43.13 # datadevil: hmm, sounds like you want an iriver H1x0 series 14.43.42 # datadevil, get one off ebay :) 14.45.05 # i just wish i could plug my iRiver into my car radio and control it via the radio headunit and via the steering wheel control buttons 14.46.37 # but this is just available for iPods with dock connector :-/ 14.48.50 # the H1x0's seem to be hard to get by on ebay 14.49.15 # i was going to sell mine 14.49.20 # but now i have rockbox 14.49.26 # i can understand that. i would never give mine away :) 14.49.59 # it is a lovely device even though a bit bulky and heavy 14.50.10 # yeah 14.50.54 # no other brands that have nice devices for around 200? 14.51.32 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 14.51.43 # iPod nano 2GB for 199 EUR 14.52.07 # QT: yeah, that one i myself mentioned already 14.52.15 # would it be better to buy then an H10 tho.... 14.53.19 # QT: make a little protocol converter box. you'd sell hundreds, methinks. 14.54.02 # Zagor: what converter box do you mean? 14.55.09 # ipod accessory -> iriver accessory convertor 14.55.18 # exactly 14.56.15 # that's probably a great idea for somebody who is able to handle with soldering. so definetely not me :-) 14.56.23 # thanks for the suggestion though 14.56.26 # :-) 14.56.39 # is there a lot of usb code in rockbox or does it rely on existing firmware? 14.56.49 Quit markun () 14.57.05 # as my car head unit is able to process MP3 files from DVD media I rather stick to this method even though it is a bit odd 14.57.06 # neither, it relies on hardware usb 14.57.33 # Zagor, ah k.. what about file "serving"? 14.57.47 # how do you mean? 14.58.05 # the interface between usb and hard drive when you plug it in 14.58.57 # all currently supported players have a hardware USB/ATA bridge 15.00.05 # ah k 15.00.44 # i hadn't thought about what was/wasn't involved 15.02.01 Join edx [0] (i=edx@p54A8574A.dip.t-dialin.net) 15.10.27 # so is it possible to do other stuff while usb is connected? 15.14.08 # theoretically, yes. but nothing that uses the disk. 15.20.35 Join tucoz [0] (n=81b17b04@labb.contactor.se) 15.21.49 # Is the 2.5 release just a keypress away, or are there still issues needed to be taken care of before that will happen? 15.22.58 # The release todo has a lot of green. I see there are some yellow issues left. 15.24.35 # there are some issues with recording 15.26.55 # LinusN: ok, seems tricky that one. Good luck with it anyway. 15.27.14 # i wish amiconn good luck with it :-) 15.27.30 # * amiconn wonders how the archos firmware obtains the exact frame count 15.27.35 # *obtains 15.27.44 # amiconn: luck :) 15.27.52 # * amiconn can't read his own stuff 15.28.06 # afk 15.28.34 # I suspect that it scans the whole recorded data 15.33.49 # maybe the SYNC pin works when encoding too? 15.40.24 Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) 15.42.47 # LinusN: Hmm? The sync pin isn't connected to the CPU according to http://www.rockbox.org/twiki/bin/view/Main/PortPinAssignments except on the player 15.42.54 # Did I overlook something? 15.43.35 # probably not 15.44.17 Join ashridah [0] (i=ashridah@220-253-121-215.VIC.netspace.net.au) 15.47.25 Quit ender` (Read error: 104 (Connection reset by peer)) 15.53.42 Join [IDC]Dragon [0] (n=d90a3255@labb.contactor.se) 15.55.17 # <[IDC]Dragon> amiconn: I'm confident that Archos is parsing the mp3 data 15.55.29 # hi 15.55.33 # What leads you? 15.55.39 # <[IDC]Dragon> the log 15.55.41 # <[IDC]Dragon> ;-) 15.56.05 # No, I mean what leads you to believe that archos is parsing the data? 15.56.09 # <[IDC]Dragon> since they do so on playback, why not on recording 15.56.40 # hello 15.56.48 # Didn't know that they do that on playback either 15.57.03 # <[IDC]Dragon> for audible FF/FR, they have to 15.57.25 # <[IDC]Dragon> my favorite missing feature 15.57.37 # I don't miss that 15.58.46 # <[IDC]Dragon> maybe one day, when we do on-the-fly bitswap 16.01.46 Join Humpaholic [0] (n=3d0b1344@labb.contactor.se) 16.02.04 # heyloooo?? 16.02.22 # anyone home??? 16.02.49 # yes 16.03.03 # hey.. hows u doin? 16.03.11 # da room seems kinda quiet 16.04.05 DBUG Enqueued KICK Humpaholic 16.04.05 # 15? 16.04.18 # it's not, it's just not chatty. see log for previous discussion. 16.05.05 # hmm.. so wat are we supposed to do? 16.05.22 # wait quietly :) 16.05.39 # Humpaholic: do? please do whatever you want. 16.06.08 # <<-- waitinnn,,....... 16.06.15 # hehe ... 16.06.28 # err.... 16.06.30 # um.. 16.06.35 # hmm..... 16.06.46 # Humpaholic: what are you waiting for? 16.06.46 # how may I help you? 16.06.47 # am i makin a lot of noise?? 16.07.05 # i duno wat im supposd to do.. i thought this was a chat room 16.07.08 # like three sounds at once :) 16.07.20 # what movie was that line from? Hmm ... 16.07.21 # lol.. hump likes blue bro 16.07.51 # Humpaholic: this is the development channel for the rockbox firmware. it's not a random chatroom. 16.08.09 # huh!! 16.08.13 # <<-- Stumped 16.08.24 # :D:D:D:D:D 16.09.23 # lol.. lemme leave u guys to develop sum good things for da wrld.. 16.09.24 # bye 16.09.30 Quit Humpaholic ("CGI:IRC") 16.09.32 # bye 16.09.40 # <[IDC]Dragon> phew 16.09.43 # hehe 16.10.02 # <[IDC]Dragon> just ignoring a troll helped, how unusual 16.10.18 *** Saving seen data "./dancer.seen" 16.10.40 Join _DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 16.11.12 # not really a troll then :-P 16.12.06 # One is experienced if one is able to catch a troll in an early state. Guess the troll-lingo can give some clues though. 16.14.19 # wonder what will happen when the release is a fact. It seems there are some iriver features in the commit-pipeline. 16.15.37 # i want my h10 :-P 16.15.53 # have you ordered one? 16.15.57 # hmm. Would be nice to see the features waiting in the pipeline. 16.18.52 # Directory caching sound nice. Then again, it might not be. 16.24.18 # <[IDC]Dragon> Archos WAV rec/play! 16.24.35 # cool 16.26.16 # so rockbox for archos is a multi-codec jukebox nowadays. cool. 16.26.41 Quit DangerousDan (Read error: 110 (Connection timed out)) 16.27.30 # you only had mp3 play/rec earlier on right? 16.27.50 Join webguest82 [0] (n=41732ee1@labb.contactor.se) 16.27.59 Nick webguest82 is now known as elinenbe (n=41732ee1@labb.contactor.se) 16.31.59 Part LinusN 16.32.09 # tucoz: mp2/mp3 playback and mp3 recording 16.33.01 # oh, ok. forgot about mp2 16.36.17 Quit pengo ("Leaving") 16.36.29 # well, good luck on the recording issues. bye 16.36.35 Quit tucoz ("CGI:IRC 0.5.4 (2004/01/29)") 16.39.24 Quit elinenbe ("CGI:IRC (EOF)") 16.40.26 Quit Zagor ("Client exiting") 16.52.41 Quit Lynx_ (" reboot") 16.52.55 # Ability to emulate an ipod for purposes of itunes synching :P 16.55.27 # [IDC]Dragon: pm... 17.07.38 Join ender` [0] (i=ychat@84.52.165.220) 17.12.00 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 17.20.45 Quit datadevil ("leaving") 17.24.02 # <[IDC]Dragon> amiconn: yes 17.24.57 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 17.25.34 Join elinenbe_ [0] (n=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 17.40.31 Join Lynx_ [0] (n=lynx@tina-10-4.genetik.uni-koeln.de) 17.48.13 Quit B4gder ("Lämnar") 17.48.18 Quit ashridah ("Leaving") 17.55.42 Quit HCl (Read error: 110 (Connection timed out)) 17.59.42 Join HCl [0] (i=hcl@titania.student.utwente.nl) 18.10.21 *** Saving seen data "./dancer.seen" 18.15.14 # [IDC]Dragon ... 18.19.06 Quit HCl (Read error: 110 (Connection timed out)) 18.20.30 Quit linuxstb ("Leaving") 18.40.59 Nick strath is now known as Strath (n=mike@dpc674681214.direcpc.com) 18.47.38 Nick Lynx_ is now known as Lynx_awy (n=lynx@tina-10-4.genetik.uni-koeln.de) 18.50.13 # Interesting result from my latest test recording... 18.50.52 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 18.50.52 # * amiconn has a suspicion for the cause of the unexpected shutdown of the archos firmware during recording... 18.54.17 # With my new transfer routine, recording broke down later than it did with the old one (on average). Over 5 hours intact recording at q=7 with high level 18.55.36 # Perhaps this is wild speculation, but I suspect that the archos recording does in fact suffer from the same problem. Under the assumption that they monitor the mp3 data stream, this monitoring would then detect "no data stream", and the unit shut down 18.58.24 Join HCl [0] (i=hcl@titania.student.utwente.nl) 18.59.32 # The interesting thing with the bitshifted recordings is that the mas itself can play them (though stuttering), but no PC software player I tried can do that 19.02.03 Quit Nilisco (Client Quit) 19.08.40 # <[IDC]Dragon> shutdown on error condition is very harsh... 19.08.58 # The suspicion is that it doesn't detect the error 19.09.00 # <[IDC]Dragon> I doubt it, they could end the recording, worst case 19.09.28 # What I think is that there is a rather simple implementation of idle timeout 19.10.39 # It would shutdown if (1) the timeout is reached after the last activity and (2) no mp3 transfer is running 19.11.03 # (2) becomes true in case of a corrupt stream.... 19.11.35 # <[IDC]Dragon> hmm, vague 19.12.06 Join Nilisco [0] (n=Nilisco@wrath.shellfx.net) 19.15.07 # * amiconn needs a way to power the Ondio for long-term recording 19.15.32 # <[IDC]Dragon> a power supply? 19.16.06 Quit Nilisco (Client Quit) 19.17.44 # Hmm... 19.23.43 # <[IDC]Dragon> I used a wire, clamped under the battery spring from the side 19.33.59 # [IDC]Dragon: pm... 19.34.32 Join Nilisco [0] (i=nilisco@wrath.shellfx.net) 19.43.36 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 19.48.12 # * amiconn hopes that the wire construction is reliable enough for ~12 hours of recording 19.53.44 # *boom* :) 19.54.20 Join webguest80 [0] (n=d9baffbb@labb.contactor.se) 19.54.35 # hi there 19.55.05 # can anybody tell me if rockbox is running on an archos av140 ? 19.56.25 Join gromit` [0] (i=gromit@ras75-5-82-234-244-69.fbx.proxad.net) 19.58.54 # Hello somebody can help me out here ? 19.58.58 Join webguest08 [0] (n=81b17b04@labb.contactor.se) 19.59.12 # webguest80: it's not. http://www.rockbox.org/daily.shtml 19.59.28 # there are the now supported platforms 20.00.44 # webguest08 > thanks i hust wann know before i screw up my 14oer :-) 20.01.31 # 14oer? 20.02.23 # webguest08> my AV140 :-) 20.03.06 # ok, maybe this is for you. http://linav.free.fr/ 20.03.29 # but that seems to only support the av3xx series 20.03.37 # webguest08> hey thanks ill check 20.03.51 # ok, bye 20.03.56 Part webguest08 20.04.41 # thanx fpr supporting me 20.05.16 Quit webguest80 ("CGI:IRC") 20.07.00 # Hmm, interesting. One of (Recorder v1, Ondio FM) must have the line input channels flipped 20.07.29 # * amiconn is recording the same source on both devices in parallel 20.08.06 # Judging from the peakmeter... 20.10.24 *** Saving seen data "./dancer.seen" 20.14.50 # bah!, the peakmeter, that lowlife piece of scum. You should know better than to trust it by now amiconn. 20.15.56 # haha 20.16.13 # good engineering by: archos 20.17.22 # don't insult french things :p 20.19.33 # There's the very slight chance that my cabling is wrong though. Can't test atm without interrupting the recording test. 20.31.23 # <[IDC]Dragon> amiconn, my pm responses didn't make it? 20.31.40 # Hmm, bleh 20.31.56 # Forgot the new policy of freenode that unregged users can't send pm 20.32.02 # <[IDC]Dragon> testing 20.32.09 # You're unregistered... 20.32.14 # <[IDC]Dragon> I should be registered now 20.32.24 # <[IDC]Dragon> since yesterday 20.32.56 # Did you identify with nickserv? 20.33.22 # <[IDC]Dragon> I did "/msg nickserv register " 20.34.10 # Yes, and you have to /msg nickserv identify everytime after joining 20.34.21 # <[IDC]Dragon> bah 20.34.36 Join solex [0] (n=jrschulz@d128211.adsl.hansenet.de) 20.34.57 # I have that in my client's OnLoggedIn command profile 20.35.07 # <[IDC]Dragon> The nickname [[IDC]Dragon] is already registered 20.35.16 # <[IDC]Dragon> ? 20.35.24 Quit webguest35 ("CGI:IRC (Ping timeout)") 20.36.02 # [IDC]Dragon: identify, not regsiter 20.36.15 # <[IDC]Dragon> sorry 20.36.17 # YOu register once, then you identify each time when joining 20.36.29 # * amiconn can't type :( 20.43.48 # Just looked up the option to allow messages from unregistered users... 20.44.00 # . /msg nickserv set unregistered on 20.44.20 # Erm, /msg nickserv set unfiltered on 20.46.45 Quit solex_ (Read error: 110 (Connection timed out)) 20.47.35 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 20.54.11 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 20.59.40 Quit linuxstb (Read error: 104 (Connection reset by peer)) 21.00.02 Join linuxstb [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 21.01.35 Join noC|andY`fRa [0] (i=andy@dsl-084-058-118-207.arcor-ip.net) 21.03.53 Quit linuxstb_ (Read error: 110 (Connection timed out)) 21.21.47 Join muesli- [0] (i=muesli_t@Bc1f1.b.pppool.de) 21.22.03 # re 21.30.26 # * [IDC]Dragon waves 21.30.36 # bye Jörg 21.30.41 Quit [IDC]Dragon ("CGI:IRC") 21.32.40 # hi jens ;) 22.10.27 *** Saving seen data "./dancer.seen" 22.15.11 Quit muesli- (Read error: 110 (Connection timed out)) 22.35.35 Join Domonoky [0] (n=Domonoky@p549AE4B6.dip.t-dialin.net) 22.36.16 # Hi.. rockbox should update the twiki, it has a big bug.. 22.36.26 # sample url: http://www.rockbox.org/twiki/bin/view/Main/TWikiUsers?rev=2%20%7Cless%20/etc/passwd 22.36.56 # bad, bad :-) 22.40.17 Join muesli- [0] (i=muesli_t@pD9FCD4D2.dip0.t-ipconnect.de) 22.43.19 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 22.44.06 Join rasher [0] (n=rasher@62.135.195.147) 22.51.53 Join zhilik [0] (n=zhilik@ppp85-140-97-24.pppoe.mtu-net.ru) 22.58.29 Quit zhilik ("http://www.zhukovsky.net") 23.11.20 Quit muesli- (Read error: 110 (Connection timed out)) 23.15.43 Join |D4ni31| [0] (i=tka@dsl-084-056-219-181.arcor-ip.net) 23.16.11 # <|D4ni31|> hi 23.16.15 # <|D4ni31|> is there anybody? 23.16.33 # <|D4ni31|> i got a question about the wps 23.18.31 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.19.12 Quit bluebrother^ (Read error: 110 (Connection timed out)) 23.27.48 Quit |D4ni31| ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 23.29.19 # What about it? 23.31.16 Join |D4ni31| [0] (i=tka@dsl-084-056-219-181.arcor-ip.net) 23.32.11 # What about the WPS? 23.32.18 # <|D4ni31|> i need some help.. i can't load an preloaded image in an WPS... http://www.rockbox.org/twiki/bin/view/Main/CustomWPS#Images <<< this isnt working 23.32.57 # <|D4ni31|> %x|n|filename|x|y| doesn't work.. but %xn|filename|x|y| works 23.33.17 # Are you using %xl and %xd? 23.33.18 # <|D4ni31|> %xl|n|filename|x|y| and %xdn doesn't work, too 23.33.23 # and you use a recent daily build? 23.33.44 # <|D4ni31|> ive got rockbox-h120-20050829 23.33.51 # <|D4ni31|> 29.08.05 23.33.54 # then it doesn't work 23.33.57 # <|D4ni31|> oh 23.34.02 # <|D4ni31|> its a new feature? 23.35.05 # Yeah, the syntax changed about a week ago 23.35.14 # <|D4ni31|> aah k, thx a lot 23.35.31 # <|D4ni31|> so how do I upgrade? delete the .rockbox folder and put the new one over it? 23.35.52 # Yup 23.35.55 # <|D4ni31|> do i have to save some files? like *.cfg 23.36.11 # And overwrite rockbox.iriver 23.36.24 # <|D4ni31|> k 23.36.37 # Just leave the dir and overwrite everything 23.36.53 # <|D4ni31|> k 23.36.56 # <|D4ni31|> thx 23.37.21 # Bagder: any news on release-status? 23.37.55 # the ball is amiconn's and LinusN's 23.38.03 # in my view they are too picky 23.39.18 # I guess it's all about whether or not delaying will be worth it. 23.39.24 # recordings tests in process, no? amiconn? 23.39.35 # Yes, two tests in parallel 23.40.23 # I'm putting Linus' idea about hard disk poweroff disturbing the mas to test 23.40.46 # I'm recording on the v1 and the Ondio FM in parallel, same source 23.41.03 # I've disabled disk poweroff on the recorder, and the Ondio has no disk at all 23.41.49 # ...but MMC, so no spinup at all 23.43.05 # how many time recording now? 23.43.05 # I think that it is possible to rescue important user recordings with this failure 23.43.49 # Much better than irreversible damage, that.. 23.43.50 # It just takes some in-depth analysis with a hex editor, and my bitshifter program 23.44.17 # Moos: Already running for 4 hours 23.44.32 # ok 23.44.46 # what it was the max? 23.45.02 # without problems :) 23.45.07 # This is time consuming... Latest recording glitched at >5 hours 23.45.27 # oh ok 23.45.55 # It got somewhat better with my tweaked transfer loop 23.46.25 # congrates :) 23.46.38 # Before that I had glitches after 1..3 hours 23.46.49 Join BoD[] [0] (n=BoD@JRAF.org) 23.46.53 # Helloooo 23.47.02 # hi 23.47.28 # Hey what do you guys know about the commodore player ? :) 23.47.34 # So i wasn't lying when I wrote thu 2.5 lowers the risk of corrupted recordings significantly.. 23.48.16 # Definitely 23.48.20 # s/thu/that/ 23.48.38 # Even current cvs does that, since 4th of June 23.51.03 # The recording transfer loop in 2.4 was asm optimised, but worked rather bad.... 23.51.11 Join CheeseBurgerMan [0] (n=BurgerBo@tc2-225-101.altelco.net) 23.51.24 # It was coded by me back then ... :-/ 23.51.51 # 2.5 sure has a lot of changes 23.52.18 # Yes, especially since it's waay off schedule 23.52.40 # By quite a bit 23.52.41 # This seems to be standard with the latest rockbox releases 23.53.18 # Every release we say "The next release shouldn't be that far in the future, a 2-month schedule would be good" 23.53.25 # 9 months is too long :-\ 23.53.31 # Already 9 months have passed... 23.54.49 # IMHO, 2 months is too little though.. You'd start thinking "release" quite quickly after the last one.. 23.55.34 # I can't say that much about older releases though, joined after 2.2 ... 23.56.18 # I'm only here after 2.4, so.. 23.56.55 # you newbies ;-) 23.57.07 # Today I found a rather interesting day in the irc logs - http://www.rockbox.org/irc/rockbox-20020920.txt 23.57.11 # Oh yes. 23.57.32 # That was way before I joined. Already talks about featuritis etc. Sounds familiar? ;) 23.58.19 # Before the 1.4 release...