--- Log for 21.09.105 Server: herbert.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 20 days and 17 hours ago 00.00.23 # webguest59: use bleeding edge builds? 00.00.43 # Yes I use 00.00.50 # It's a balance act. I'd go with releasing as-is, but it's amiconn's call. 00.01.08 # but I think much to feature freeze :( 00.01.21 # amiconn, have the release button? 00.01.35 # the power :) 00.01.54 # Well, right now it's the only bug being serioiusly worked on. I think the rest are going to be left. 00.02.17 # wooooot 00.02.21 # ok 00.02.25 # h120 arrives tomorrow 00.02.43 # but why don't release if all is good 00.03.00 # Because it'd be nice to get this bug fixed first. 00.03.12 # yes indeed 00.03.37 # it will be fixed in the daily builds 00.04.27 # and tell to user that there is 1 bug left, please wait the bug will be fixed in the daily builds or still one release 00.04.47 # *new one 00.05.26 # Yes. That is one solution. 00.05.30 # Better would be to get it fixed. 00.06.00 # yes but the time run fast 00.06.10 # webguest59: Everyone is still hacking away at Rockbox - there will be a _lot_ of changes committed to Rockbox when the feature freeze is over. Development hasn't stopped. 00.06.36 # in the rockbox. org Bagder's said release around 5 septembre :) 00.06.52 # linuxstb: ok 00.07.04 # bye! 00.07.11 # ciao 00.07.12 # webguest59: that was the plan 00.07.39 # plan have changed? 00.07.55 # you can modify this message no 00.08.02 # the plan was to "attempt" to release it at sep 5 00.08.08 Quit Dma-Sc ("http://dma-sc.atari.org/") 00.08.22 # optimistic way? 00.09.14 # not really 00.09.27 # just not many people involved in the bug fixing process 00.09.37 # and this recording bug being a lot meaner than expected 00.09.38 # I'm curious if amiconn has any other ideas lined up. If not, I'm of the opinion that the release should go ahead. 00.09.46 # rasher: I am too 00.09.52 # have you got one limit time, exemple, if the bug not fixed the X sept, october...? 00.10.01 # release 00.10.16 # webguest59: No. Time limits don't work well for stuff done on people's free time. 00.11.18 # (as has been demostrated brilliantly) 00.11.20 # yes indeed, I thought about administration way of rockox 00.12.00 # I thanks everyone here again for all the free works done 00.12.14 # I'm not complaining, just wondering 00.12.27 *** Saving seen data "./dancer.seen" 00.15.40 # rasher: for the WPS gallery wiki section, maybe you could add message in forums gallerys for the owner will can add them again to the wiki 00.15.52 # *owners 00.16.22 # I guess I should 00.16.33 # very good effort you did everyone can thank you for this 00.16.59 # assume a lot of hours at restored :( 00.18.14 # you lot are gunna love helping me get rockbox setup tomorrow 00.18.18 # cant wait 00.18.20 # cya 00.18.21 # LOL 00.18.25 Quit Dan () 00.22.26 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 00.24.07 # bye all 00.24.14 # bye 00.24.25 # and I hope realese coming soon ;) 00.24.30 Quit webguest59 ("CGI:IRC") 00.37.58 Quit ender` (Read error: 113 (No route to host)) 00.39.11 # Haha, good one Febs. (on the mailing list) 00.43.36 Join thegeek_ [0] (n=thegeek@s057b.studby.ntnu.no) 00.47.26 Quit thegeek (Read error: 113 (No route to host)) 00.47.56 Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) 00.48.43 Join ashridah [0] (i=ashridah@220-253-123-98.VIC.netspace.net.au) 00.49.34 Quit Moos ("Parti") 01.02.48 # about time as well 01.03.31 # Long due 01.05.46 Quit thegeek_ (Read error: 110 (Connection timed out)) 01.06.12 # Interesting stuff, this Neuros talk 01.06.31 # what/where? 01.06.32 # indeed 01.06.50 # preglow: in #haxx 01.06.51 # #haxx, you missed by a few hours though.. still going on though 01.07.09 # oh, right 01.07.13 # didn't know it was today 01.07.16 # There's preglow long-awaited ARM platform! 01.07.19 # log will be available 01.07.38 # rasher: No, preglow's going to buy an ipod. 01.08.03 # Yeah, mostly joking 01.08.15 # mmm, rockbox on ipod. 01.08.23 # rasher: Me too. 01.09.04 # _200_ mhz arm9? 01.09.10 # then what the flaming hell do they need the dsp for 01.09.15 # video 01.10.05 # * preglow starts on the ti toolset woes 01.10.27 # but basically the idea is to not use the DSP on the audio players 01.10.54 # they want the same CPU for several models 01.11.01 # ahh, i see 01.11.05 # oh well 01.11.15 # adapting existing code for dsps is a nightmare anyway 01.11.32 Join edx [0] (i=edx@p54A87B9F.dip.t-dialin.net) 01.15.19 # so... i've heard you had problems with TWiki, right? 01.16.15 # We did, yeah 01.16.27 # neuros-firmware.sf.net uses TWiki also, anything i should know? 01.16.43 # make sure you applied the early-september security patch 01.16.50 # which is mysteriously not mentioned anywhere on their front page 01.17.30 # http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithRev 01.17.34 # that one 01.17.57 # and check your server for alien processes 01.18.33 Join elinenbe [0] (i=elinenbe@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.18.34 # grep apache logs for "?rev=.*% HTTP" 01.18.46 # "?rev=.*%.* HTTP" even 01.18.56 # what sort of cunt destroys a free open source project. 01.19.08 # sorry for the language... 01.19.12 # but what an ass. 01.19.28 # probably someone randomly scanning for twiki installs via google or something, to be honest 01.20.09 # That's my guessing too 01.20.11 # fuzzie: yes 01.20.28 # I fail to understand the reasoning behind this 01.20.35 # as for dsp chips and gcc support: are there any? 01.20.42 # has Linus worked anymore on the H320? 01.20.42 # i know blackfin's god gcc support 01.20.51 # preglow: not really 01.20.52 # but blackfin isn't exactly a typical dsp 01.21.07 # and it's 16 bit 01.21.32 # to get the most out of your typical dsp chip, you need to use asm 01.22.33 # well.. it's hosted on sf.net 01.22.40 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 01.22.46 # DeepB: then you're probably safe 01.22.52 # you can easily check it 01.23.02 # so i don't have to worry about the server 01.23.04 # there's a sample URL in that alert 01.23.10 # but i appreciatte my data 01.23.31 # the sample url is harmless 01.23.37 # just make sure you're patched 01.23.40 # thank you for the pointers guys, i'll check it right on 01.23.48 # but, to be honest, you should be backing up stuff from sourceforge regularly 01.24.10 # there's nothing to stop other sf users from damaging anything apache-writable, afaik. 01.24.33 # unless they run suexec 01.25.13 # they didn't when i was last hosting web stuff there 01.25.23 # [i've long since deserted them, cvs is unusable] 01.25.23 Quit matsl (Remote closed the connection) 01.25.37 Quit [IDC]Dragon () 01.25.44 # yes, I've abandonded them too for almost everything 01.25.47 # * Zagor has painful memories from when rockbox had cvs at sf. 01.26.24 # Now someone write that SF > Bojira migration script 01.26.50 # So we can ditch the patch/bug tracker 01.26.55 # It's vile. 01.27.39 # I agree very much. 01.27.47 # but I've never heard of Bojira :-) 01.27.51 Quit ashridah ("Leaving") 01.27.57 # bojira being bugzilla :) 01.28.00 # Oh, Bugzilla 01.28.07 # aaah 01.28.13 # fuzzie: i know, i'd like to get rid of that can of worms as soon as i can 01.28.25 # hm, mojira.org doesn't point at the right pages any more 01.28.44 # fuzzie: crikey 01.28.48 # http://www.rockbox.org/Neuros-chat-20050920.txt 01.29.09 # excellent :) 01.29.22 # I'm having problems registering on their mailing list (and another sf.net list) 01.29.34 # I managed just now 01.29.49 # Maybe SF is just slow. 01.29.55 # Who am I kidding, SF *is* slow. 01.29.56 # oh, right, they can turn off the power on the DSP, that's useful 01.30.34 Quit linuxstb_ ("Leaving") 01.30.36 # rasher: slow as in four days? 01.31.06 # sure your mail server isn't blocking them? 01.31.18 # i signed up to the neuros442linux-main thing and it only took a few minutes 01.31.18 Quit paugh (Excess Flood) 01.31.37 # yes. I get the confirmation mail, but when I confirm I don't get the welcome mail. 01.31.54 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 01.31.55 # I bet they enabled the Zagor filter 01.31.59 # I use it all the time ;-) 01.32.03 # they too? gaah 01.32.35 # now, less than 5 hours to get-up time, I better sleeeeep 01.32.42 # night 01.32.45 # night 01.32.45 # well, i've managed to get both, total time between them 3 minutes or so, so i guess they might well have done :) 01.32.48 # night 01.33.06 # I'm feeling discriminated. ItProbably 01.33.07 # I haven't got my confirmation mail yet. 01.33.24 # It's probably because I'm.... uh... tired. 01.33.34 # But then, I think some server along the way to me is doing greylisting and not being very smart about it 01.34.14 # * preglow ponders the possibilities of having a proper dsp core... 01.34.58 # preglow: the possibilities are great, if you have some way of programming it. doing it all in assembler is not too fun... 01.35.24 # depending on your idea of fun 01.35.24 # i have somehow gotten used to assembler since starting to code for rockbox... 01.35.30 Join void [0] (n=void@ool-18b89646.dyn.optonline.net) 01.35.33 # preglow: hehe 01.35.38 # heya guys 01.35.48 # was wondering if there's a site or area I can download wps files from? 01.36.03 # it's for the archos recorder 01.36.06 # void: you're out of luck, our wps page is broken after being hacked 01.36.12 # gah 01.36.14 # void: http://www.rockbox.org/twiki/bin/view/Main/WpsGallery 01.36.20 # Ah, for the recorder it should be up to date 01.36.25 # ooh 01.36.25 # or.. 01.36.26 # goodness, then 01.36.27 # preglow: the WPS:es are in the text, not as attachments 01.36.44 # http://rasher.dk/rockbox/WikiRescue/WpsGallery-r1.282%20-%2009-08.html 01.37.57 # That's linked at the top of the page anyway 01.38.01 # cool thanks a ton :) 01.44.09 Join linuxstb_ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 01.44.53 Quit hicks (Remote closed the connection) 01.53.38 # hrmph 01.55.39 Quit paugh ("Leaving") 01.55.44 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 02.07.30 Part stripwax 02.10.21 Quit preglow ("leaving") 02.12.32 *** Saving seen data "./dancer.seen" 02.48.33 Quit tvelocity ("Leaving") 02.51.41 Join lee_ [0] (n=lee@67-42-194-6.eugn.qwest.net) 03.09.03 Quit ze (Read error: 104 (Connection reset by peer)) 03.13.41 Join bitshift [0] (i=lock@CPE000c6e94cf09-CM001225d870de.cpe.net.cable.rogers.com) 03.21.05 Join dropandho [0] (n=dropandh@cpe-24-193-36-91.nyc.res.rr.com) 03.21.12 Part bitshift 03.21.16 # rasher- u rock 03.21.20 # thanks for all your work 03.21.26 # do you need any help? 03.21.34 # I think it's mostly done 03.21.39 # wow 03.21.45 # and how much do you get paid for this?! 03.21.47 # hehe 03.21.53 # The WPS gallery is left - leaving that for people to fix by themself 03.22.04 # yeah- that is a good call 03.22.07 # dropandho: I've been paid one pice of excellent firmware 03.22.20 # do you wanna announce your progress on the front page 03.22.25 # hehe- i hear ya 03.22.50 # Hm, maybe there should be something 03.23.20 # just so folks know whats up 03.23.30 # especially the wps people 03.23.48 # I've marked the WPS page quite heavily 03.23.59 # got it 03.24.26 # maybe just about the success 03.24.32 # what is missing and what isnt? 03.24.40 # plus, you need to get props 03.24.40 # ! 03.25.17 # Hah, I'll do fine without.. but let me add something.. 03.25.37 Quit paugh ("Leaving") 03.25.39 # Now I know the wiki quite well after this.. 03.26.20 # no kiddin 03.26.25 # intimately 03.26.47 # and also maybe something about if the hole was patched up 03.26.52 # * rasher checks out www 03.26.55 # Oh, it was 03.27.03 # and the progress on fixing a regular backups 03.27.06 # Before going online again 03.27.11 Part DeepB 03.27.15 # i dont know...just thinking about what inquiring minds might wanna know 03.27.45 # Fair enough.. I'm going to add a note 03.27.49 # in.. uh.. a while, it seems 03.28.53 # fair enough 03.28.57 # so no help is needed? 03.29.20 # Not outside the WPS gallery really 03.29.28 Quit lee_ ("Leaving") 03.29.35 Join bagawk [0] (n=lee@unaffiliated/bagawk) 03.29.40 # impressive...thanks again 03.30.43 # Well, I didn't do it all alone. Probably did most of it though I guess 03.31.26 # yes, get some sleep now! 03.31.35 # haha 03.32.06 # ok- have a good night 03.32.13 # thanks and take care rasher 03.32.29 # night, thanks for the appreciation 03.32.31 Quit dropandho () 03.37.51 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) 03.37.55 Quit ze (Read error: 104 (Connection reset by peer)) 03.42.30 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) 03.42.37 Quit ze (Read error: 104 (Connection reset by peer)) 03.43.31 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) 03.43.36 Quit ze (Read error: 104 (Connection reset by peer)) 03.44.41 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) 03.44.43 Quit ze (Read error: 104 (Connection reset by peer)) 03.45.41 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-81.snbrca.adelphia.net) 03.45.44 Quit ze (Read error: 104 (Connection reset by peer)) 03.53.15 Join ze [0] (i=ze@ca-dstreet-cuda1-c6a-130.snbrca.adelphia.net) 04.06.08 Join QT_ [0] (i=as@madwifi/users/area51) 04.12.36 *** Saving seen data "./dancer.seen" 04.13.31 Quit bagawk ("Leaving") 04.16.00 Quit QT (Read error: 110 (Connection timed out)) 04.28.07 Join Mirthoneist [0] (n=mirthypo@c-66-177-213-74.hsd1.fl.comcast.net) 04.28.07 Quit Mirthoneist (Client Quit) 04.30.41 Join Mirthoneist [0] (n=mirthypo@c-66-177-213-74.hsd1.fl.comcast.net) 04.50.47 Quit cYmen ("zZz") 05.05.40 Join Yono [0] (n=Yono@69-169-174-248.bflony.adelphia.net) 05.07.19 Quit Yono ("Download Gaim: http://gaim.sourceforge.net/") 05.13.39 Quit rasher (Remote closed the connection) 05.48.57 Quit Mirthoneist () 06.00.46 Join Tomas_ [0] (n=Tomas@ip503c08d1.speed.planet.nl) 06.12.39 *** Saving seen data "./dancer.seen" 06.15.33 Quit t0mas (Read error: 110 (Connection timed out)) 06.15.33 Nick Tomas_ is now known as t0mas (n=Tomas@ip503c08d1.speed.planet.nl) 06.20.14 Join cheriff [0] (n=davidm@cheriff.ken.nicta.com.au) 06.20.27 Quit edx () 06.33.33 Join LinusN [0] (n=linus@labb.contactor.se) 06.36.53 # Morning 06.39.27 # LinusN: Did you check http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo ? Your work done for soft poweroff and panic is missing; I just changed the xing header status 06.39.59 # didn't look, i'll fix 06.43.39 # i was thinking about the bit shift 06.44.21 # are there occasions where we disable the interrupt for a long period? i think not 06.44.32 # None that I know of 06.45.01 # This bitshifting has some really puzzling properties 06.48.12 Quit Mxm`Pas`Bien (Read error: 104 (Connection reset by peer)) 06.48.44 Join amiconn_ [0] (n=jens@p54BD42C2.dip.t-dialin.net) 06.48.55 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 06.52.00 Join amiconn__ [0] (n=jens@p54BD414E.dip.t-dialin.net) 06.53.32 # amiconn_: puzzling properties? 06.57.24 Quit amiconn (Nick collision from services.) 06.57.24 Nick amiconn__ is now known as amiconn (n=jens@p54BD414E.dip.t-dialin.net) 06.57.29 Quit amiconn_ (Nick collision from services.) 06.58.08 # LinusN: Yes. First, the probability of a bitshift happening depends on the transfer speed used. 06.58.33 # that suggests performance problems 06.58.52 # For the cvs C loop (and my local, slightly more optimised C loop) it happens after 2..4 hours 06.59.28 # With my highly optimised asm loop (better than what was in 2.3 and 2.4) it happens after 30 min .. 1 hour 07.00.07 # This is strange, since it would suggest that it would happen really often when the MAS is connected to a real DMA controller 07.01.13 # These time periods are rather long compared to the amount of data transferred - one shift after millions of bytes 07.01.43 # Second, the shift seems to always happen at a frame boundary, which is not necessarily a DMA block boundary 07.02.09 # (although I'm not 100% sure about the frame boundary) 07.03.03 # no, that's not easy to tell 07.03.39 # so maybe it is a reverse performance problem 07.03.52 # that the mas can't cope with out fast transfer speed 07.06.26 # Oh, and third, the probability depends on the quality setting and the recording level 07.07.14 # also suggesting a mas performance problem 07.07.46 # I derived the frame boundary rule from my simple restore method. As it's not easy to tell the exact point, I presumed it was at the frame boundary, and undid the bitshift accordingly with my tool 07.08.18 # When playing the recording, there were no audible glitches at these points 07.09.06 # I suspect archos might know some more about the mas recording init than what the datasheet says 07.10.40 # I don't think it's a simple performance problem. (1) The mas tells us when it's ready to transfer a block, by raising EOD. Why would it do that before it's really ready for transfer? 07.11.21 # (2) The bitshift isn't temporary for one block or one frame, it stays for hours until another shift happens eventually 07.12.01 # I even had one test recording sequence where the next shift brought the bit order back to normal.... 07.13.00 # It seems that the mas tends to shift forward, the most observed shift values are +1 ... +3 bits (i.e. to the right) 07.13.30 # Although I had one case of -1, I believe this really was a +7 shift 07.14.35 # ...derived from the fact that I also had one case of a +8 shift, which of course didn't destroy the recording, but there was a stray byte in the stream... 07.18.02 # so perhaps the internal transfer from the DSP to the dma buffer inside the MAS is serial 07.18.43 # morning all :) 07.19.15 # morning 07.24.50 # i see rasher has completed the wiki update ... 07.28.47 # LinusN: I don't know whether it's only a rumour, but didn't archos make the mas recording at 192 kbps cbr is some later product? 07.29.07 # haven't heard of it 07.29.40 # 192 kbps cbr means more load than q=7 (which goes up to 192 kbps frames, but is ~170 kbps on average) 07.31.15 # hmmm, i see we poll EOD 07.31.45 # http://www.rockbox.org/irc/rockbox-20040809.txt around 12:30 07.32.08 # according to the data sheet, EOD might not go inactive until after 8us 07.33.37 # Yes, and that's what the timeout loop for /rtw is for 07.34.04 # As EOD might still be high when the DMA buffer is empty, we raise PR as we expect another byte 07.34.14 # A real DMA controller would do the same 07.34.50 # http://www.archos.com/download/firmware/AV300_OS_History.txt 07.34.59 # "New Feature: MP3 encoding can now be done in 192kbit/s CBR for sample rates of 32, 44.1 and 48kHz" 07.35.03 # Then we wait for /rtw to signal the next byte is ready. If it's not (after a much longer timeout than 8µs) we lower PR again 07.35.42 # The archos recording loop does the same, with an even longer timeout 07.35.53 # (which doesn't make a difference; I tried) 07.37.08 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 07.39.32 # i suspect a real dma controller would wait for _RTW before polling EOD 07.40.10 # morning 07.40.14 # morning 07.40.44 # seen the neuros chat log? 07.40.50 # B4gder: no 07.41.06 # (i fell asleep ans missed the meeting, sorry) 07.41.19 # http://www.rockbox.org/Neuros-chat-20050920.txt 07.41.49 # LinusN: Nothing guarantees that EOD goes low before the final /rtw -> inactive transition (according to the datasheet) 07.42.07 # no? 07.43.50 # No. If we lower PR after t3, EOD might still be high because teod may be up to 8 µs 07.44.06 # Perhaps a rather unusual approach would work - keeping PR high by default (!) 07.47.45 # yes, if we lower PR after t3, EOD might still be high, but i doubt it would still be high when RTW goes up again 07.49.47 # Iirc the very old loops had that (in rockbox 2.2), but I'll do a test 07.53.23 # Test running, gotta hurry now... 07.57.33 Join Febs [0] (n=Febs@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) 08.01.16 Join ender` [0] (i=ychat@84.52.165.220) 08.12.43 *** Saving seen data "./dancer.seen" 08.14.53 # Bagder? 08.14.57 # yes 08.14.58 # (and LinusN and Zagor) 08.15.03 # reading the logs about neuros... 08.15.13 # me too 08.15.20 # maybe it's a good idea to register rockbox as a company 08.15.34 # or isn't it possible to register a non-profit organisation in your country? 08.15.40 # yes it is 08.15.48 # might be a good idea to do that? 08.16.07 # perhaps, I don't think it'll change much 08.16.15 # setup a contract where you three are the owners and delegate the copyright to the writers 08.16.29 # but add a part explaining that you are the last right holders 08.16.45 # well, it doesn't work in quite that way 08.17.04 # it does if you ask everybody with cvs write access to agree to it 08.17.30 # yes, but they would have to agree to sign over their copyright to us 08.17.47 # and I don't think we need that 08.17.49 # in holland it can be done different... 08.17.56 # I doubt that 08.18.20 # each author owns their own work 08.18.28 # well... we have some system here... making it possible for all authors to have the rights, but at the same time giving 1 company the right to sell it etc... 08.19.16 # and if they do... the authors still have the copyrights on the version at that point... but the new version is free for the next company to do whatever they want with it afaik 08.19.41 # in this case, no one can forbid any company to sell rockbox 08.19.56 # (don't think it's GPL compatible... it's used in universities a lot) 08.20.31 # I don't see how we have a problem, so I don't see anything to fix ;-) 08.20.47 # well... you can't contact Ti now for example... 08.20.57 # ? 08.21.04 # as said in the logs? 08.21.08 # no one can get any sense out of TI 08.21.12 # ghehe 08.21.21 # Neuros been trying for years 08.21.36 # and for hosting contracts etc... it's 1 of you 3 who's the contractee... 08.21.56 # and afaik you have to pay taxes on the gifts to rockbox? 08.22.03 # it is that free in your country? 08.22.33 # it is free 08.22.44 # donations are 08.23.18 # ah ok 08.23.29 # that makes it a lot easier 08.23.56 # well.. maybe it's different there then... in holland we have some regulations madness... 08.24.03 # so you have to register almost anything 08.38.46 # t0mas and JoeBorn raise some interesting points about the legal status of Rockbox. 08.39.45 # I don't think it is primarily a legal problem 08.41.32 # other than perhaps a question about who owns the name and the logo etc 08.41.39 # Well, for example, who has authority to sign a contract on behalf of Rockbox, should a contract need to be signed? 08.41.49 # hm, no not the logo 08.42.07 # Actually, the logo is a good example. Who designed the logo? 08.42.16 # the logo is owned by its creator 08.42.22 # it's pretty much the same using rockbox or linux. who signs contracts for linux? nobody does. 08.42.31 # Febs: nobody can sign anything on behalf of rockbox now 08.42.37 # because rockbox legally doesn't exist 08.42.46 # That isn't necessarily true 08.42.54 # rockbox does exist. it's just not a company. 08.42.58 # Zagor: Linus (torvalds) started some holding company for linux... 08.43.01 # an informal team exists 08.43.06 # even in the eye of the law 08.43.22 # it doesn't here... 08.43.23 # afaik 08.43.37 # * B4gder is involved in talks about exactly this in a very high-stake open source project 08.43.43 # you can register some legal entity for informal non-profit things like sportsteams etc 08.44.13 # intresting how this is done different all over europe... 08.44.29 # ... and here on the other side of the pond! 08.45.10 # the point is the law isn't blind. nobody is allowed to railroad over us just because we're not a company. individuals have the same rights as companies. 08.45.39 # yes, we have... but we can't do anything (like getting a hosting contract for the website) as rockbox... 08.45.51 # that has to be done as some individual... who is responsible for it then 08.45.51 # I'd say that the biggest problem would be our international nature 08.46.06 # yeah, that is a problem I guess 08.46.19 # we'll simply don't sign contracts as "rockbox" 08.46.46 # at least, not until we have a formal org for it 08.46.47 # t0mas: I don't see that as a problem (contracts). in the end single individuals *are* responsible. 08.46.55 # we wouldn't be better off having "rockbox" responsible 08.46.56 # wait a moment 08.47.03 # client fucking up again 08.47.12 # Zagor, yikes! 08.47.16 # ah, back 08.47.35 # Zagor: got to run 08.47.44 # ok 08.47.47 # Do you want to be individually responsible if, for example, Rockbox bricks a large number of players? 08.47.58 # Febs: yes 08.48.07 # yes, if you sign a personal contract that you are, then sure 08.48.07 # Really? 08.48.20 # (sorry... have to work now) 08.48.45 # however we put pretty strong disclaimers on the firmware that says "works for us, might not for you". 08.50.56 Join aga [0] (i=svann@01-057.032.popsite.net) 08.51.47 # hey does rockbox 2.4 supposed to display a 'charging' screen when you have the charger plugged in 08.52.42 # i just got a used archos and am trying to determine if its got a fault 08.54.10 # aga: which model? 08.54.22 # jb recorder 20 08.54.45 # the battery icon will have a question mark sometimes, then after a while it says 40% or so 08.55.04 # with the charger plugged, the battery icon should at least animate 08.55.14 # and ive changed the batteries to ones that i know are good 08.55.55 # ok so i have either a bad unit or a bug i guess 08.56.32 # could be a broken dc/dc regulator. that's not entirely uncommon. 08.57.09 # does that workaround with the F1 have anything to do with this? 08.57.36 # oh you mean the charger might be bad, or the connecting pin 08.58.11 # an IC in the archos. it breaks if you insert a charger with wrong polarity or such. 08.59.26 # * Febs has been thinking about Zagor's point and disclaimers and B4dger's point about personal contracts. 08.59.37 # i saw that faq in the forum, i guess you get the IC from archos 09.00.13 # anyway to quickly tell if that is the problem besides disassembling 09.00.28 # aga: it's a pretty standard part you get from an electronics shop. 09.00.30 # The whole nature of an open source project raises some really interesting legal questions. 09.00.43 # Perhaps more interesting to me than to you folks. 09.01.09 # Febs are you a lawyer ? ;) 09.01.16 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 09.01.19 # I am quite interested in the legal parts as well 09.01.54 # i didnt understand that 'press F1 ON' sequence then plug in the charger bit. does that relate to my problem? 09.02.25 # aga: no, that just makes you boot the archos firmware instead of rockbox 09.03.12 # ok thanks, ill check the faqs and see whats up 09.04.05 # Febs: start at the other end. since when are commercial software companies responsible for their bugs? microsoft software bugs causes billions of damage every year, for instance. 09.05.26 Part aga 09.06.37 Part cheriff 09.07.58 # Zagor have you read the M$'s EULA ? 09.08.12 # I have 09.08.28 # well, a few of them. different products use difference eulas 09.08.33 # yeah 09.09.11 # from "diagonal" reading, afaics, they wash away their hands ... 09.09.27 # about responsibility 09.09.43 # oh yes, every way they can (and some they can't) 09.09.54 # :) 09.10.49 Join aga [0] (i=svann@01-057.032.popsite.net) 09.11.01 # I forgot one thing 09.11.32 # when you boot up, are you supposed to see the firmware 1.8, *Then the rockbox logo afterwards? 09.11.41 # on the jb recorder 20 09.11.52 # aga: if you are not flashed, yes 09.12.15 # oh ok, so that is normal, not a conflict between programs 09.12.34 # no. the archos firmware boots and then finds rockbox and loads it. 09.13.12 # dang, i thought that would be it 09.13.19 # ok 09.13.25 # * aga slogs off 09.13.28 Quit aga (Client Quit) 09.14.32 # Bger, yes. I am a lawyer. (A lawyer with insomnia at the moment.) 09.14.46 # hehe :) 09.14.53 # that's not good 09.16.25 # Yeah, it's 3:14 AM here in the eastern U.S. 09.17.41 # I'm also a working musician. 09.17.57 # wow:) interesting combination 09.18.19 # Yeah. Not always easy to balance. 09.18.52 # Bger: the GPL (and pretty much every other license) contains such No Warranty clauses too, however not quite as far-fetched as the MS EULAs. 09.19.26 # and at least in most cases you pay for support, not for the product itself ... 09.20.14 # that's an issue too: even if authors were liable, how much warranty does your $0 buy you? 09.21.09 # requiring overreaching liability from authors would completely kill free software 09.22.01 # Can you tell I too am interested in the legal angles? ;) 09.22.32 # Like I said before, many interesting questions ... 09.23.51 # ... which I've been very careful not to answer. ;) 09.24.04 # hehe. you ARE a lawyer! :-D 09.24.25 # :-D 09.28.32 # In all seriousness, as I'm sure you can appreciate, I *do* need to be careful not to give legal advice in a public forum. 09.28.39 # absolutely 09.31.43 # Let's just say if free software liability would become an issue, Rockbox is pretty far down the list of prominent projects getting in trouble. 09.32.18 # (Heck, half the Internet would probably shut down... ) 09.33.38 Join bobTHC [0] (n=bobTHC@62.34.136.111) 09.33.44 # mornin' folks ! 09.33.53 # howdy 09.34.25 # i'm fine and u ? 09.34.31 # It's good night for me. Time for some sleep ... 09.34.41 # Febs: good night 09.34.46 # bobTHC: just peachy 09.35.03 # nice ;) 09.35.18 Quit Febs (" HydraIRC -> http://www.hydrairc.com <- Go on, try it!") 09.43.16 Join Dma-Sc [0] (n=Dma-Sc@LAubervilliers-151-11-60-200.w193-251.abo.wanadoo.fr) 10.02.39 Quit linuxstb_ ("Leaving") 10.08.07 # *yawn* 10.12.47 *** Saving seen data "./dancer.seen" 10.26.37 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 10.37.27 Join ashridah [0] (i=ashridah@220-253-121-53.VIC.netspace.net.au) 10.43.08 # joke of the day: http://www.google.com.super-fast-search.apsua.com/check.htm haha 10.43.17 # don't try it in IE 10.44.57 # btw, i gave up translating rockbox to bulgarian. The system font doesn't have cyrillic (cp1251) chars, so i can't do it as it should be 10.45.18 # apparently my system language is "undefined" 10.45.31 # snax and your processor ? :) 10.45.34 # which I speak quite fluently, I might add 10.46.16 # your processor family is "undefined" 10.46.41 Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 10.46.42 # and it uses ActiveX for displaying explorer window 10.46.47 # apparently I also live in Bellevue, United States 10.47.08 # I must have missed it when that city (which I don't live in, by the way) became a state in the union 10.47.33 # yeah 10.48.40 # words such as "boy" "father" and "child" were found in my system records 10.48.59 # scandalous 11.09.09 Join zeekoe [0] (i=HydraIRC@prac063.ewi.utwente.nl) 11.10.56 Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) 11.15.41 Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) 11.28.55 Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) 11.38.55 # can anyone tell me whether rockbox will play audio from an mpeg2 file? 11.39.48 # depends 11.39.56 # mpeg2 allows for aac audio as well 11.39.57 # on..? 11.40.02 # and that we can't play 11.40.05 # aha 11.40.09 # but we can play mpeg2 layer 3 streams 11.40.25 # but if i have an mpeg2 video file 11.40.34 # will it take the audio stream? 11.40.45 # depends on what it is 11.40.53 # not quite sure, let me check 11.48.03 Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 11.52.36 # * HCl taps his foot while mplayer compiles 12.10.10 # long-whinded, is it? 12.10.57 Join Vladoman [0] (n=Vladoman@p54A7E1B9.dip.t-dialin.net) 12.10.59 # was it on dual xeon 500 or sth similar ? 12.11.28 # amiconn, you still there? 12.11.42 # he is offline atm 12.12.15 # anybody here working on the "bit shift" problem 12.12.49 *** Saving seen data "./dancer.seen" 12.13.11 # only hiom 12.13.13 # him 12.13.21 # k 12.14.02 # why? 12.14.19 # cause I can give some info on it 12.14.34 # just shoot it 12.14.42 # log ;) 12.14.45 # there are irc logs, and he'll see it 12.15.38 # btw, see http://irc.rockbox.org/irc/current.txt 12.17.52 Quit zeekoe (" HydraIRC -> http://www.hydrairc.com <- Try something fresh") 12.17.55 # yep, I just mailed him anyway 12.41.12 Nick QT_ is now known as QT (i=as@madwifi/users/area51) 12.48.47 Join am1conn [0] (n=c1af49c9@labb.contactor.se) 12.49.29 # am1conn how was the test 12.50.37 # Still running @home, can't check atm 12.51.19 # k 12.51.42 # Vladoman: still here? 12.59.18 Quit Dma-Sc ("Wow! What a great client! Bersirc 2.2 [ http://www.bersirc.org/ - Open Source IRC ]") 13.11.28 Join linuxstb_ [0] (n=d556da1b@labb.contactor.se) 13.11.56 # HCl: If you use mplayer to extract the audio from an MPEG2 file (I'm guessing it's a "program stream"), then Rockbox should play it. 13.12.11 # It's most likely either MP2 or AC3 audio. Use "mplayer -dumpaudio" 13.13.49 # yeah, can't say i've ever seen aac in an mpeg2 stream 13.14.29 # any chance of seeing dts support in rockbox? ;) 13.14.41 # what is dts? 13.14.54 # I read on misticriver that someone played DTS via the optical out on the H1x0. 13.15.07 # LinusN: It's a compressed multi-channel format. 13.15.12 # Similar to AC3 13.15.17 # oh 13.15.54 # "DTS in WAV" is a common format - the player treats it as a normal WAV file, and passes the bitstream to an external decoder via S/PDIF 13.16.01 # well 13.16.07 # to say it's similar to ac3 isn't exactly true 13.16.09 # not internally, at least 13.17.07 # I just meant that it's a lossy compression format designed for multi-channel audio. Is that not true? 13.17.27 # oh, yes 13.18.10 # but they're pretty different codecs, i don't think dts is a transform codec at all 13.18.25 # whereas ac3 is more or less just an mdct and some magic 13.18.44 # i think i've seen some libdts some place 13.19.59 # "mdct and some magic", pretty much covers it all :-) 13.20.24 # you really make it sound simple ;-) 13.21.18 # I wouldn't know - I just treat codecs as black boxes. 13.22.07 # what, 'magic' isn't a professional term? ;) 13.23.42 # but no, dts is an adpcm like codec, i think 13.24.07 Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) 13.31.52 # Moos: Yes 13.32.11 # Vladoman am1conn is (was) here 13.32.42 # thx 13.33.21 # the MAS bit shift is a comfirmed bug (by Micronas), there is no "fix" that they know of (AFAIK) 13.33.33 # oh 13.33.51 # then how come the archos firmware can record for quite a while with no shift? 13.34.19 # maybe by working around it? 13.34.58 # maybe 13.35.08 # a lot of factors play in, apparently 13.35.15 # like transfer speed 13.37.07 # maybe they're scanning the stream from mas realtime while recording (sorry if i'm talking bullsh*ts)) 13.39.32 # well, they are 13.39.48 # but i don't know how that helps them in detecting a shift 13.39.55 # hmm 13.40.07 # perhaps it is possible to detect a shift in the sync bits 13.40.24 # i wonder that also 13.40.28 # i wonder if the bit shift can happen anywhere in a frame or at a boundary 13.40.55 # amiconn said that he observed the bitshift *only* at frame boundaries 13.41.01 # see the irc logs 13.42.03 # if the bits are shifted, the sync words would not match any more, no? 13.42.38 # indeed not 13.42.50 # so it can be detected 13.43.00 Join tuco [0] (n=81b17b04@labb.contactor.se) 13.43.03 # unless the bit shift is eight bits 13.43.17 # in which case the only thing you can see is a skipped byte 13.43.23 # Is this the same bit shift as amiconn is investigating? http://www.rockbox.org/twiki/pub/Main/DataSheets/mas3587f_1ais.pdf 13.44.35 # yes, but a skipped byte can also be detected 13.44.54 # yes, sure 13.45.09 # the workaround they describe here isn't very nice, though 13.45.13 # and the workaround described doesn't work? 13.45.15 # will probably mean some lost recording time 13.45.27 # ok, probably :) 13.45.31 # amiconn has considered this workaround 13.45.38 # don't know about the parity checking, though 13.46.00 # I suppose he have. 13.47.17 # tuoc: this SPDIF issue is known, it's not the same thing 13.47.27 # Vladoman: ok 13.47.51 # preglow today 13.48.01 # 's log, 07.01.43 13.48.30 # 07.07.46 13.48.40 Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) 13.50.18 # Have to say amiconn goes through this issue thoroghly 13.51.11 # yes he does 13.51.25 # which is good 13.51.38 Part crash3m ("Leaving") 13.53.11 Part tuco 13.53.33 Quit tvelocity ("Leaving") 13.57.06 Quit Bger ("BitchX-1.1-final -- just do it.") 14.09.32 Join Bger [0] (n=Bager@83.222.160.88) 14.12.46 Join [IDC]Dragon [0] (n=d90a3255@labb.contactor.se) 14.12.52 *** Saving seen data "./dancer.seen" 14.12.59 # <[IDC]Dragon> Hi Vladoman ;-) 14.13.14 # hi mighty Dragon 14.26.19 Part Vladoman 14.28.41 Quit am1conn ("CGI:IRC (EOF)") 14.31.52 Quit B4gder ("time to say moo") 14.33.13 # hehe good quit msg :) 14.36.35 Part LinusN 14.43.21 # <[IDC]Dragon> ping 14.43.26 Join LinusN [0] (n=linus@labb.contactor.se) 14.43.42 # pong 14.45.23 Part LinusN 14.45.52 Join am1conn [0] (n=c1af49c9@labb.contactor.se) 14.46.12 # <[IDC]Dragon> Jens? 14.46.17 # yup 14.46.32 # <[IDC]Dragon> you got some info? ;-) 14.47.01 # Yes I did 14.47.28 # However, there's no quick way to implement that in rockbox 14.48.07 # <[IDC]Dragon> yes, we need Luke Framewalker 14.48.13 Join LinusN [0] (n=linus@labb.contactor.se) 14.48.32 # am1conn: have you read what i said about detecting bitshift in a frame? an hour ago or something 14.48.47 # <[IDC]Dragon> could do some good on playback, too (audible FF/FR) 14.48.52 # indeed 14.49.29 # <[IDC]Dragon> LinusN in Germany \o/ 14.49.47 # leaving tomorrow 14.52.04 Join tvelocity [0] (n=tony@ipa221.7.tellas.gr) 14.54.06 Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) 15.01.54 # rasher congrats for the work yesterday 15.02.44 # Why, thanks.. there were not that many pages with big changes left 15.03.34 Join crash3m [0] (i=crash3m@unaffiliated/crash3m) 15.03.46 # hm, at least IriverInstall :) 15.05.42 # Yeah, that took a while 15.06.24 # trivial commit time 15.06.34 Part crash3m ("Leaving") 15.07.10 # hm, it seems that the new wiki doesn't allow to create attachments without comment 15.07.23 # yes, we're aware of that 15.07.26 # silly indeed 15.07.32 # yep 15.07.47 # and the "view raw" is horrible 15.07.56 # yes 15.08.24 # it's horror to read bigger pages 15.08.51 # Shouldn't take much to fix 15.09.43 # i'll look at both issues in a bit 15.10.58 # Zagor: it seems you'll have to change the wiki source code 15.11.11 # you did that the last time too? 15.11.32 # yes, but I'd like to avoid it this time since we're using auto-updated packages 15.11.39 # we'll see 15.11.58 # it doesn't seem to be configurable, from what i saw in the code 15.16.47 Join atubbs [0] (n=atubbs@ool-435634a8.dyn.optonline.net) 16.05.42 Quit am1conn ("CGI:IRC (EOF)") 16.10.30 Join Rori [0] (i=MO-Pants@deadman3000.plus.com) 16.10.35 # hi. anyone awake? 16.10.56 Quit Moos ("Parti") 16.11.07 # Could be 16.11.26 # I have a couple of problems with latest builds of h120 rb 16.11.39 # no, you're lying 16.11.49 # there is noooo problem in rockbox :-) 16.12.03 # * LinusN looks away 16.12.52 # 1. I get a dir buffer full error when accessing a directory with over 1000 files in it. 2. I can't get wps to display correctly anymore. It shows the bmp path and fonts don't change. Also it seems to crash on occasion 16.12.54 *** Saving seen data "./dancer.seen" 16.13.08 # Rori increase dir buffer size 16.13.11 # I did 16.13.14 # makes no difference 16.13.17 # 1) Adjust the "Max files in dir" setting 16.13.25 # I set dir limits to 10,000 same prob 16.13.28 # you need to reboot for it to have effect 16.13.39 # let me try reboot 16.14.13 # that worked 16.14.26 # 2) Reset your settings and adjust the wps to the current specification 16.14.47 # wuh? you mean it's all changed? 16.14.51 # the wps format has changed a bit, especially for bitmaps 16.14.58 # bleh 16.14.58 # LinusN iirc there were problems with max files in dir > 5000 or so 16.15.06 # Bger: really? 16.15.26 # i didn't know that 16.15.31 # maybe i'm wrong, but i remember something about this 16.15.32 # player crashed again 16.15.50 # crashed how? 16.16.00 # hmmm 16.16.04 # as in locked up solid with light on 16.16.08 # wow 16.16.17 # i suggest you reset your settings 16.16.26 # preglow: my mpg has an internal mp3 stream, so rockbox would be able to play it even though its a video? 16.16.45 # HCl: probably not 16.17.12 # the mp3 decoder will bail out if it encounters many sync errors 16.17.12 # who would i have to talk to to change it so you can play audiostreams from video mpeg2s 16.17.24 # HCl: yourself :-) 16.17.26 # maybe the wps that now needs redoing is causing the crashes when I try to load them 16.17.32 # mk 16.17.40 # Rori: yes, reset your settings 16.18.32 # yeah did. I need to fix the wps now....where is the info for changing to the new commands? 16.19.00 # in the "documentation" section on rockbox.org 16.19.11 # surprisingly :-) 16.19.19 # heh 16.19.28 # LinusN see http://www.rockbox.org/irc/rockbox-20050801.txt , 18.12.47 16.20.08 # it is a known problem??? 16.20.24 # i just remember seeing it ... 16.20.30 # wow, i didn't know that :-) 16.20.36 # :) 16.20.38 # OK this is my current fave wps I fiddled with. Any idea what is wrong with it? 16.20.39 Join Mxm`Pas`Bien [0] (n=flemmard@fbx.flemmard.net) 16.20.40 # It's one of those known unknowns 16.20.47 # oh crap can't paste it 16.20.49 # maybe it'll be better to ask amiconn for details 16.20.50 # anyway 16.20.53 # i gotta go 16.21.02 # %x1|wps/edan/e_logo.bmp|116|117|%x2|wps/edan/e_artalb.bmp|0|60|% 16.21.20 # gimmie a clue on that line and I can adjust from there 16.21.40 # btw, regarding this 16.22.09 # i think it's better to search for wps images in the dir where the .wps file is 16.22.35 # so you can make /.rockbox/wps1/1.bmp ... 2.bmp 16.22.52 # bye 16.22.53 Quit Bger ("BitchX: now in non-drowsy formula too!") 16.23.41 # Rori: it is no longer 1-9 for images, it's a-z 16.24.06 # ah crap 16.24.07 # %x|a|pic.bmp|x|y| 16.24.44 # so %x1|wps/edan/e_logo.bmp|116|117| becomes %x|wps/edan/e_logo.bmp|116|117| 16.25.08 # hmm ok will give it a shot 16.25.13 # no, %x|a|wps/edan/e_logo.bmp|116|117| 16.25.21 # k 16.25.30 # and %x|b for the next and so on 16.27.02 # that works thx 16.27.09 # damned syntax crapola 16.27.23 # sorry for that 16.27.30 # heh 16.28.38 # HCl: you'll need a proper mpeg stream parser 16.29.03 # there isn't just one long mp3 stream in the file 16.29.08 # it's segmented over the entire file 16.29.08 # afaik 16.30.52 # we *could* adapt the mp3 codec to accept multiple sync errors so it skips the video data and syncs on the audio data 16.31.24 # provided it is segmented on frame boundaries... 16.31.33 # which i doubt 16.32.05 # haha 16.32.14 # or we could make a demuxer 16.32.18 # and do the job properly 16.32.30 # sure, would be somewhat cool 16.32.38 # but how useful is it? 16.32.43 # not at all, actually 16.32.44 # heh 16.32.46 # but would be cool 16.33.24 # in fact, one could do a demuxer as a plugin 16.33.34 # for the fun of it 16.34.35 # hmm 16.34.47 # it would fit into my scheme of allowing the codecs to load their own data 16.35.09 # LinusN: what would be cool would be allowing plugins to load a codec 16.35.20 # absolutely 16.35.30 # LinusN: then we could make a demuxer as a plugin, then just having it load a codec 16.35.53 # but this is all talk on my side, i'm not too interested :) 16.35.53 # transcode.rock :-) 16.35.55 # haha 16.35.55 # yes 16.36.00 # that would be nice 16.37.53 Quit Maxime (Read error: 110 (Connection timed out)) 16.39.58 # hmmm 16.39.59 # I've written various MPEG demuxing tools (but mainly for transport streams). But it would have to be done outside the codec - we don't want to waste memory buffering video that we will just be discarding later. 16.40.12 # 'course 16.40.25 # But I would very much like to see Rockbox do that. 16.40.28 # we'll need to allow codecs to load their own data sooner or later 16.40.31 # for streaming codecs 16.40.41 # and there's nothing wrong in allowing a codec to have several loaders 16.40.50 Join leftright [0] (n=d4406110@labb.contactor.se) 16.40.57 # ehh, non-streaming codecs 16.41.25 # linuxstb: how's sudoku coming on ? :) 16.41.40 Join noC|andY`fRa [0] (i=andy@dsl-084-058-141-169.arcor-ip.net) 16.41.52 # leftright: It's about ready to commit - I'll have a final clean up when the feature freeze is over. 16.42.04 # LinusN: is there some way to force a struct to appear as the first thing in a binary image? 16.42.10 # can't wait, love the game 16.42.19 # LinusN: perhaps stuffing it in a separate section on forcing that first? 16.42.24 # preglow: yes 16.42.31 # that's how 16.42.40 # simple way of extending the plugins 16.42.47 # and still having it be a binary image 16.43.01 # or you can force the linker to use a specific section from a specific .o file first 16.43.34 # any plans to make the .cfg files more accessable ?, i.e. quick menu ? 16.43.48 # no 16.43.50 # no plans 16.44.04 # thats a shame, 16.44.13 # that doesn't mean that it won't happen 16.44.26 # seeing as cfg files are used frequently to change settings 16.44.31 # if a patch pops up, we might just as well commit it 16.44.45 # linuxstb_: how hard is demuxing? 16.44.59 # in fact, there are very few real plans in rockbox in general 16.46.38 Join Pieter__ [0] (i=Pieter@pieter.student.utwente.nl) 16.46.48 # hello 16.46.54 # I need to find a bribeable coder :) 16.47.13 # did anyone else notice the ondio swapping the left and right channels when recording? 16.47.18 # yes 16.47.20 # amiconn did 16.47.22 # ok 16.47.35 # just noticed - recorded a piece where there were lightbulbs thrown on the left side 16.47.40 # it's a general archos issue 16.47.42 # they appeared on the right when listening back :) 16.47.48 # i'll just swap the channels back 16.48.05 # many archos devices have the line in channels swapped in the connector 16.48.13 # good engineering 16.49.01 # especially the recv1, where the connector is soldered by hand with two wires 16.49.08 # eh 16.49.21 # guess there's no way to add a 'swap channels when recording' feature? ;) 16.49.25 # nope 16.49.27 # no 16.49.28 # not without hacking the mas 16.49.58 # hehe, thought so.. ok 16.50.53 # i'll just swap the channels so people will stop wondering why they hear the light bulbs on the wrong side :) 16.51.20 # (those things make wonderful noises when thrown at the floor ;)) 16.51.37 # gotta go, cu all 16.51.39 Part LinusN 16.52.09 # preglow: Demuxing isn't hard. Seeking in the file will be hard. 16.53.02 # how's that handled, then? 16.53.56 # Like VBR MP3 files I think - i.e. you guess. DVD program streams have extra seek infomation (so-called navigation packets) inserted in them. But "normal" MPEG programs streams don't. 16.54.20 # bah 16.54.24 # what were people thinking 16.54.29 # One advantage of program streams is that audio stream is encapsulated into "PES" (packetized elementary stream) packets - each with a timestamp in the header. 16.56.38 # The demuxing software I've written has just been for off-line extraction of the elementary streams - not for use in a player application. So I haven't had to worry about seeking. 16.57.21 # oh well 16.57.26 # all i want is a wav writer :P 16.59.42 # brb 16.59.42 # hmm, audacity doesn't like big recordings :( 16.59.49 # audacity doesn't like being used 17.00.00 # no, so it seems 17.00.04 # can't open a 2 hour mp3 file in it 17.00.15 Quit ashridah ("sleep") 17.00.22 # or i can, but it takes an hour, then clicking anything produces nothing but lots of swapping :p 17.02.03 Join webguest46 [0] (n=53afb0c2@labb.contactor.se) 17.04.40 # audio editors that can't handle large files without loading them all into "ram" are pretty much unusable 17.08.19 # yeah, so it seems.. i haven't had the problem before, but i've never used this big files 17.08.31 # usually i could at least half way create a new file 17.09.22 # by the way, is there an easy fix for the ondio battery life problem thing? mine gets rather hot and doesn't last very long on it's batteries :( 17.10.23 Part leftright 17.19.25 Quit webguest46 ("CGI:IRC") 17.22.09 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 17.32.14 Quit Rori () 17.38.28 # <[IDC]Dragon> Pieter__: only changing the LTC3440 helps 17.39.20 # [IDC]Dragon: Still wanting audible ff/rw? I don't care about that feature... 17.39.41 # i'd love it 17.40.18 # but do you think it's possible to find out whether a bit shift has occured in a frame by looking for the sync bits in the mpeg frame? 17.46.05 # The sync bits alone aren't very reliable 17.46.36 # how come? 17.46.37 # We'd need to walk the data stream and check all headers 17.47.01 # We know which parameters are fixed and so we know which bits must be fixed 17.47.01 # you'd need to check everything coming out of the mas, yes 17.47.14 # No, not everything 17.47.25 # depends on when a bit shift error can occur 17.47.50 # but the header should suffice 17.48.03 # We just have to search for the first frame header. Then we know how long that frame is and here where the next frame header should occur 17.48.04 # but why isn't just the sync bits enough? they're constant 17.48.32 # Yes, but chances are high you won't notice a single bit shift by just the sync bit 17.48.35 # +s 17.49.11 # <[IDC]Dragon> Luke Framewalker, as I said 17.49.16 # why not? 17.49.22 # Well, perhaps it would be reliable enough, but we'll need to find the first header anyway 17.49.26 # they'll all be displaced 17.49.40 # yes, and that's done by checking for the sync bits 17.49.51 # We have an advantage - the mas gives us the last header it decoded/encoded via i2c, so we know what to search for 17.49.58 # <[IDC]Dragon> my rvfmux tool has a frame walker 17.50.36 # amiconn: yeah, but there's no point in looking for all that when you can save cpu in only looking for sync 17.50.42 # preglow: You can't find a header just by looking for the sync bit sequence. There are sometimes sequences of 0xFF bytes within frames 17.50.59 # amiconn: that shouldn't be, that's the entire point of the sync bits 17.51.09 # It's definitely the case 17.51.12 # ahh, yes 17.51.17 # ff bytes are ok 17.51.23 # sync bits are eleven bits 17.51.27 # Believe me, I've looked at megabytes of mp3 data with my hex editor 17.51.32 # not eight 17.51.41 # and can be distributed however they like among two bytes 17.52.03 # as long as they're in sequence, of course 17.52.07 # If no bitshift occured, they are aligned always the same way 17.52.18 # yup 17.52.31 # However, that still doesn't help because sequences of 0xff can occur within frames 17.52.40 # 0xff doesn't matter, that's just eight bits 17.52.54 # *sequences* of 0xff 17.53.03 # that's extremely weird 17.53.13 # It's not 17.53.15 # can't possibly imagine why they bothered with sync bits if that's the case 17.53.32 # do you know where in a frame those sequences are located? 17.53.35 Join R-S-W [0] (n=R_S_W@84-245-190-38.bpool.celox.de) 17.53.51 Join paugh [0] (n=kickback@2001:5c0:8fff:ffff:8000:0:3e03:6822) 17.54.19 # That's why all mp3 tools that don't know the exact frame header in advance check for several consecutive frames (usually >=3) if they found a maybe-header whether it is really a frame header 17.55.40 Join Sucka`away [0] (n=NNSCRIPT@81.156.157.185) 17.56.23 Nick Sucka`away is now known as Sucka (n=NNSCRIPT@81.156.157.185) 17.56.53 # [IDC]Dragon: Any ideas how to integrate such a framewalker into the rockbox architecture? 17.56.54 # well, that does indeed defeat the entire purpose of the sync bits 17.57.04 Nick Mxm`Pas`Bien is now known as Maxime (n=flemmard@fbx.flemmard.net) 17.57.08 Nick Maxime is now known as Maxime` (n=flemmard@fbx.flemmard.net) 17.57.35 # preglow: I opened the first arbitrary mp3 file, looked at the first frame - there's a 0xff 0xff sequence in it 17.57.47 # then you'll indeed need to look for the entire header 17.58.22 # [IDC]Dragon: i can't do that.. oh well :P 18.00.50 # amiconn: but are you going to try to fix this before 2.5? 18.02.42 # I don't think this can be implemented quick enough to justify holding back 2.5 18.04.00 # Interesting... waiting for /RTW to become high before entering the loop again made the error occur earlier... 18.04.24 # amiconn: btw, you sure that 0xff 0xff sequence isn't the sync bit sequence? 18.04.33 # Yes, definitely 18.04.39 # amiconn: you'd see a 0xff 0xff sequence in all frames for quite ordinary files 18.04.49 # The sync can't be 0xff 0xff 18.05.00 # The second byte must be != 0xff 18.05.10 # no, but sync bits + layer 1 + mpeg version 1 + not protected file == the two first bytes of nearly all mpeg files 18.05.22 # or mpeg frames, i mean 18.05.31 # The mas only records layer 3 18.05.31 # and that equals 0xff 0xff 18.05.37 # ahh, i mean layer 3, sorry 18.06.21 # Layer 3 is 01 18.06.26 # Layer 1 is 11 18.06.29 # yes, quite 18.06.30 # ignore me 18.06.41 # http://www.rockbox.org/docs/mpeghdr.html 18.06.51 # i know, i'm just confused 18.06.54 # i'll go attend to my baking again 18.07.21 Quit R-S-W () 18.08.02 # Archos recorded frames always start with 0xfffa or 0xfff2 18.08.08 # (we do enable crc protection) 18.08.35 # but you don't know which part of the frame you find the 0xff 0xff sequence in? 18.09.04 # I don't know much about the internals of a frame. It was around the middle 18.09.27 # hrmph 18.10.52 # This is a 192 kbps frame which is 626 bytes long. 0xffff occurs there at position 382 18.11.07 # (position 0 being start of header) 18.11.28 # * [IDC]Dragon got back 18.11.57 # <[IDC]Dragon> I can confirm the mpeg audio suffers from so-called start code emulation 18.12.29 # <[IDC]Dragon> meaning, the payload may (by chance) look like a frame header 18.12.48 # <[IDC]Dragon> [17:56] [IDC]Dragon: Any ideas how to integrate such a framewalker into the rockbox architecture? 18.12.56 *** Saving seen data "./dancer.seen" 18.12.58 # <[IDC]Dragon> perhaps as a state machine? 18.13.15 # <[IDC]Dragon> we're touching the bytes anyway 18.13.27 # [IDC]Dragon: is this thanks to bad planning from the mpeg people or bad implementations? 18.13.48 # <[IDC]Dragon> the scpecification allows it 18.14.05 # marvelous 18.16.46 # [IDC]Dragon: Where are we touching the recorded bytes? (except for saving them) 18.17.22 # And how do you mean as a state machine? I'm thinking about the way to integrate it. 18.17.31 # Should the mpeg thread do the check? 18.17.40 # Do we need a separate thread? 18.18.40 # And finally, for your beloved feature, the framewalker would need to run for playback as well. That won't work with the current approach of swapping the main buffer 18.19.58 # <[IDC]Dragon> I know 18.20.03 # Audible ff/rw will still be hard even with a frame walker. It's only simple to walk forward, backward is tedious 18.20.21 # <[IDC]Dragon> that, too 18.20.23 Nick solexx_ is now known as solexx (n=jrschulz@d155158.adsl.hansenet.de) 18.20.24 # And for ff, it has to be fast enough to cope with the speed 18.20.45 # <[IDC]Dragon> well, Archos does it 18.21.00 # Yes, and I don't know why (for playback) 18.21.17 # <[IDC]Dragon> stop mobbing that feature! 18.21.21 # haha 18.21.23 # I prefer silent ff/rw over unidentifiable twittering noises 18.21.36 # how does archos ffrw compare to irivers? 18.21.42 # iriver's audible ffrw sounds pretty nice 18.21.50 # and very nice for vorbis files 18.21.54 # <[IDC]Dragon> the first config option I'm voting for, instead of against 18.22.12 # preglow: I never tried it 18.22.23 # <[IDC]Dragon> how to implement: yes, I ment the byte saving 18.22.31 # <[IDC]Dragon> meant 18.23.13 # I think we would need to walk directly behind the mas writing. When saving it is too late 18.24.01 # Perhaps we could even do that within the transfer isr 18.24.08 Quit bobTHC ("Smoke Weed Every Day !") 18.24.08 # (for recording) 18.25.11 # It could also count the frames if it walks them anyway 18.25.45 # No resort to estimation from the recording time if the mas counter saturates 18.26.07 # Hmmmmm 18.26.33 # <[IDC]Dragon> yes, that's what I mean, process the header while grabbing the bytes off the hardware 18.26.50 # <[IDC]Dragon> but better have v2.5 released first 18.26.55 # There won't be a header within every DMA block 18.27.12 # we'll need a byte counter for the position within the frame 18.27.13 # <[IDC]Dragon> that's what the state machine is for 18.29.05 # <[IDC]Dragon> we'll have a performance peak during the header, else we're ust counting for the next header 18.29.29 # Today's test recording got a +1 bitshift after ~90 minutes. That's with the check for /rtw going inactive before looping 18.31.02 # <[IDC]Dragon> hm, my state machine code is not in rvf_mux, but in the DirectShow filter 18.31.16 # <[IDC]Dragon> which is closed source 18.31.45 # Is there a special reason for the directshow filter being closed source? 18.31.50 # (just wondering) 18.32.04 # <[IDC]Dragon> anyway, it should be much simpler for the MAS 18.32.17 # <[IDC]Dragon> yes, too much overlap with my work 18.36.43 # I guess that a frame walker could actually simplify many other parts of the recording engine 18.37.02 # <[IDC]Dragon> now we're talking ;-) 18.37.08 # Today, we search for frame boundaries when splitting etc 18.37.20 # <[IDC]Dragon> I gotta leave 18.37.23 # The frame walker would store the last frame boundary position 18.38.30 Quit Bagder (Read error: 104 (Connection reset by peer)) 18.38.34 # <[IDC]Dragon> the state machine in essence works like this: 18.38.57 # <[IDC]Dragon> - you present it with an arbitrary amount of bytes 18.39.12 # <[IDC]Dragon> - the state decides what'll happen next 18.39.38 # <[IDC]Dragon> e.g. at the init state, you just memchr for an 0xFF 18.39.55 # <[IDC]Dragon> when found, you're in the next state 18.40.08 # <[IDC]Dragon> and verify byte 2 of the header 18.40.30 # <[IDC]Dragon> if no match, go back into scan state 18.40.58 # <[IDC]Dragon> then verify byte 3, processing the relevant bits 18.41.25 # <[IDC]Dragon> and so on, until the distance to the nect frame is known 18.41.45 # <[IDC]Dragon> then you're in a "skip payload" state 18.41.57 # <[IDC]Dragon> counting off until the next header 18.42.06 Quit linuxstb_ ("CGI:IRC") 18.43.03 # We don't even need to search for the first header at the start of the recording. We know it must be the first thing 18.43.18 # <[IDC]Dragon> an extra ontop condition would be to only changed from an "unsynced" to a "synced" state when seen eg. 3 headers with the right spacing 18.43.37 # ...and if we loose sync, we need to restart recording anyway 18.43.41 # <[IDC]Dragon> well, that was the general case. 18.43.54 # ...meaning we do again know where our first new header must be 18.43.55 # <[IDC]Dragon> simplifications apply here 18.44.12 # <[IDC]Dragon> and we know sample rate, etc 18.44.20 # <[IDC]Dragon> no need to extract that 18.44.29 # We don't know the sample rate in case of s/pdif 18.44.44 # <[IDC]Dragon> oh 18.44.55 # <[IDC]Dragon> well 18.45.14 # When recording from s/pdif the mas auto-syncs to the input, and ignores the setting 18.45.26 # <[IDC]Dragon> perhaps we can assume it being constant 18.45.41 # We know a lot of things, and we can get the header template from the mas itself 18.45.45 # <[IDC]Dragon> taking that I2C header 18.45.45 # (via i2c) 18.45.51 # :) 18.46.14 # <[IDC]Dragon> just for a start, I woudn't use it while running 18.46.28 # <[IDC]Dragon> most likely it is outdated 18.46.28 # Why not? 18.46.37 # Yes, it's only a template 18.46.45 # <[IDC]Dragon> we don'tknow which frame it really belongs to 18.46.56 # bitrate and mode extension can change 18.47.19 # <[IDC]Dragon> but then a restart probably woudn't hurt 18.47.39 # <[IDC]Dragon> bitrate changes all the time 18.47.58 # <[IDC]Dragon> I rather meant sample rate 18.48.13 # Version, layer, protection, channel modecopyright, original bit, emphasis, padding and private bit are fixed 18.48.36 # Sample rate should be fixed too 18.48.43 # (within one recording) 18.49.00 # padding is simple - *all* mas encoded frames are unpadded 18.49.39 # <[IDC]Dragon> V said the MAS has an undocumented feature, doing CBR 18.49.56 # <[IDC]Dragon> but in a dumb way: it pads like crazy 18.50.29 # Yes, I read that note about the AV3x0 firmware update enabling cbr 18.50.43 # I wonder how this mode is enabled... 18.50.45 # <[IDC]Dragon> a waste of diskspace 18.51.11 # * [IDC]Dragon really gotta leave 18.51.16 # <[IDC]Dragon> cu 18.51.25 Quit [IDC]Dragon ("CGI:IRC") 19.22.03 Quit dpassen1 (Read error: 110 (Connection timed out)) 19.23.08 Join Dan [0] (i=Bollocks@tredwell.plus.com) 19.23.11 # hey 19.23.42 # is there a max volume setting on rockbox? 19.24.08 # because rockbox is a hell of allot quieter than the iriver firmware4 19.30.40 # just turn bass / treble down, rockbox doesn't limit them like iriver firmware does 19.32.28 # hmm 19.32.35 # still really quiet 19.32.37 # :/ 19.46.36 Join Lear [0] (n=chatzill@h36n10c1o285.bredband.skanova.com) 19.48.39 Quit markun () 20.01.04 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.12.52 # Dan: replaygain on? _completely_ certain bass and treble is zero? 20.12.58 *** Saving seen data "./dancer.seen" 20.19.23 Quit Dan (Read error: 110 (Connection timed out)) 20.31.50 Part nibbler ("Leaving") 20.33.09 Join tomal [0] (n=tomek@155-moo-7.acn.waw.pl) 20.35.50 Join solexx_ [0] (n=jrschulz@d098198.adsl.hansenet.de) 20.41.07 Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) 20.42.52 Join Seed [0] (i=ben@l192-117-115-168.broadband.actcom.net.il) 20.47.50 Quit solexx (Read error: 110 (Connection timed out)) 20.58.20 Join Yono [0] (n=Yono@69-169-174-248.bflony.adelphia.net) 20.59.08 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 21.12.41 Quit tomal ("leaving") 21.22.10 Quit Maxime` () 21.25.13 Join Maxime [0] (n=flemmard@fbx.flemmard.net) 21.32.41 Quit tvelocity ("Leaving") 21.34.30 Quit Yono ("Download Gaim: http://gaim.sourceforge.net/") 21.46.04 Quit t0mas (Read error: 104 (Connection reset by peer)) 21.46.18 Join t0mas [0] (n=Tomas@unaffiliated/t0mas) 21.47.04 Quit t0mas (Read error: 104 (Connection reset by peer)) 21.55.50 Join t0mas [0] (n=Tomas@unaffiliated/t0mas) 22.01.53 Quit t0mas (Read error: 104 (Connection reset by peer)) 22.13.02 *** Saving seen data "./dancer.seen" 22.14.03 Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4/undefined]") 22.25.34 Join travis [0] (n=travis@ACC20E81.ipt.aol.com) 22.25.42 # freenode-connect is being nosey! 22.26.13 Quit travis (Remote closed the connection) 22.27.01 Join travis95 [0] (n=travis95@ACC20E81.ipt.aol.com) 22.27.05 # freenode-connect is being nosey! 22.27.52 # Zagor is being nosey! 22.28.06 # with all right, since you are acting like a bot 22.31.08 Quit travis95 (Client Quit) 22.51.24 # horrible 22.56.36 Quit dpassen1 () 22.59.17 Quit matsl (Read error: 104 (Connection reset by peer)) 23.00.51 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.16.47 Join unL33T [0] (n=8e9c01df@labb.contactor.se) 23.17.10 Quit unL33T (Client Quit) 23.17.22 Join Moos [0] (i=DrMoos@m50.net81-66-159.noos.fr) 23.17.24 Join unL33T2 [0] (n=8e9c01df@labb.contactor.se) 23.18.22 # hey i have a problem when trying to use the regular iRiver firmware on my iRiver HP-120 ... anyone wanna try to help me with it =) 23.19.43 # basically if I select a song through the artist or album or one of the other sorted menus it just doesn't play it and just closes the menu and goes back to whatever was there before but if I go through the folder browser menu anything I select works fine.... I've tried rebuilding the database with MoodLogic a couple times ... last I'm thinking is a reformat of the player but I'd rather not as it is also my primary music storage 23.20.23 # rockbox still works normally but I'm still not sure if I like it better than the regular firmware so I'm still switching between both 23.21.24 # i think there was a bug in the bootloader causing something like that. are you using the latest version? 23.23.30 # I downloaded the 1.65 firmware from the links provided in the faq and ran the patching program ... unless the bootloader is something other than the hacked firmware... 23.23.47 # I'm new to using so kind of dumb 23.24.08 # or does the bootloader depend on the version of rockbox I have? 23.25.03 # no. but the bootloader has been updated since the bug was found. try grabbing the 1.65 firmware and patch it again. 23.25.32 # I wonder whether it would be a good idea to display the bootloader version within rockbox 23.25.44 # (somewhere in the debug menu) 23.25.55 # might be a good idea, yes 23.26.00 # i just downloaded and patched it two days ago 23.26.12 # unL33T2: ok, doesn't sound like that then 23.26.35 # There's an orphaned "View HW info" menu item in the iriver debug menu... 23.27.01 # and what should that tell me? 23.27.19 # That was directed to Zagor (and other devs) 23.27.29 # oh sorry :P 23.28.10 # hmm I just noticed that when I turn on my iriver it says H-100 series (which I think it always said) but the player is an iHP-120 ... I dunno if that is significant. 23.30.39 # you didn't use the wrong model firmware, did you? 23.31.11 # positive I didnt but I'll verify the filename 23.31.49 # oh, my 140 says "H-100 series" too, so don't worry 23.31.56 # ok 23.32.27 # I've tried reflashing to the stock firmware as well ... both 1.63 and 1.65 and have the same problem 23.32.50 # which is why i suspect that it is a problem with the database but I dont know how to fix it 23.32.53 # Seed: still no news as to fixing libmpcdec for rockbox, i imagine? :P 23.33.26 # iriver firmware is dumb... it told me "low battery" when I wanted to check what it says on boot. Rockbox still runs happily... 23.33.51 # all my firmwares I have are all ihp_120.hex 23.34.05 # well, iriver firmware has a safety check to avoid angry users... 23.34.14 # * amiconn wonders what this mpeg frame checker is doing with his ram... 23.34.16 # which is perfectly understandable 23.35.11 # unL33T2: what version bootloader do you have? it says so first thing when you turn the unit on 23.35.24 # preglow: I'd rather like to use the full capacity of the battery... 23.35.51 # "rockboot version 2" 23.36.22 # is there a way to pause it during boot so I can see all that info it provides? 23.37.55 # Oh, that's old... current bootloader is v5. 23.38.04 # Hmm, the wiki contains v2 - argh! 23.38.04 Quit noC|andY`fRa (Read error: 104 (Connection reset by peer)) 23.38.39 # Excellent 23.38.44 # that is probably where I got it 23.38.48 # I have v5.. hang on 23.39.00 # ok thanks 23.39.22 # is it the same process to install it? just patch the firmware with a newer program? 23.39.34 # Yes 23.40.04 Join DrMoos [0] (i=DrMoos@m50.net81-66-159.noos.fr) 23.40.06 # cool 23.40.09 Quit Moos (Read error: 104 (Connection reset by peer)) 23.40.15 # amiconn: sure, but i bet iriver doesn't trust their ordinary userbase to do so 23.40.29 # oh shit 23.40.31 # i didn't think of that 23.40.35 Nick DrMoos is now known as Moos (i=DrMoos@m50.net81-66-159.noos.fr) 23.40.45 # preglow: ? 23.40.50 # wiki and old fwpatcher 23.40.58 # which is kind of nasty 23.41.26 # Obviously google didn't like the IriverBoot page 23.42.10 # v5 should work perfectly for you 23.42.28 # cool I just have to get it =) 23.43.13 # Hrm, is the last one "20050722? 23.43.16 # (v5) 23.43.44 # gimme a sec 23.44.09 # Hrm.. how do I delete an attachment again? 23.44.46 # what the hell? 23.44.53 # suddenly the bootloader uses 10 seconds to get going 23.44.58 # i have to stop booting the iriver fw 23.45.30 Join ashridah [0] (i=ashridah@220-253-122-152.VIC.netspace.net.au) 23.46.09 # rasher: By moving it to Trash/TrashAttachment, but why do you want to delete it? 23.46.22 # well, what do I call the bootloader.bins ? 23.46.27 # h120 / h100 23.46.41 # ccurrently there's just "bootloader.bin" 23.47.35 Join DrMoos [0] (i=DrMoos@m50.net81-66-159.noos.fr) 23.47.56 # Ah, that problem... 23.48.24 Quit Moos (Read error: 104 (Connection reset by peer)) 23.50.41 # What do I do? 23.53.01 # dunno 23.53.13 # I haaaave the file... where to put it? 23.56.17 # I dont even know what .bin files are used for .... 23.56.27 # fwpatcher.exe updated 23.57.39 # so this link should be to the correct one: http://www.rockbox.org/twiki/pub/Main/IriverBoot/fwpatcher.exe ? 23.57.40 # think I'll leave it to Linus to upload the .bins 23.57.42 # yes