--- Log for 18.10.104 Server: burroughs.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 13 days and 23 hours ago 00.17.18 Part scott666_ 00.17.24 Quit _aLF ("Leaving") 00.20.06 Join Lurkski [0] (~Miranda@24.30.163.142) 00.22.41 Part Lurkski 00.58.30 *** Saving seen data "./dancer.seen" 01.03.51 # <[IDC]Dragon> my Ondio tuner works! 01.04.03 # woo! :) 01.04.13 # great work.. sounds like it's progressing quite well 01.04.22 Quit AciD (Remote closed the connection) 01.04.29 # curious, what haven't you got to work yet? 01.04.49 # <[IDC]Dragon> we got it pretty much complete now 01.05.44 # <[IDC]Dragon> the keyboard screen is missing, tuner presets found no button 01.09.12 # great 01.24.40 # <[IDC]Dragon> 'night! 01.24.45 Quit [IDC]Dragon () 01.54.44 Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 01.57.06 # hey bc 01.57.11 # hey mk 01.57.32 # anything in the works lately? 01.57.47 # been writing a book 01.58.14 # on what? 01.58.22 # linguistics 01.58.40 # primarily neuro linguisitc programming 01.58.52 # neuro what? :) 01.58.58 # but variations and adaptations based on it 01.59.02 # lol ;) 01.59.47 # do you plan to publish it or anything? 01.59.57 # probably, yes 02.00.11 # awesome 02.00.35 # ty 02.01.22 # appropriate("Good luck!")?say():shutUp(); 02.01.32 # lol 02.01.37 # he has mastered the ? 02.01.58 # not really sure if it would work or not.. last time i tried something like that i got an error 02.02.12 # i stuck to switch(case) or if(x) 02.02.14 # :) 02.02.39 # often fixed by adding paren's everywhere 02.02.48 # ()?():(); 02.03.46 # good idea 02.04.54 # especially if you have them nested, when it becomes almost essential ...not sure why - poor compilation imho - but then I may be lacking the vital piece of information that makes everything clear 02.05.57 # i never liked that style much anyhow.. i prefer something a little more readable like if-else 02.06.14 # they are good when used sensibly, i think 02.06.33 # if there's more than 3 or so if/else statements i use a switch 02.07.17 # theory has it that the compiler should do that anyway 02.07.38 # you should make two compiles, one with, one without, and see if there is any filesize difference on the .rock 02.07.55 # simpler to read is all 02.08.13 # most of my programming now takes place at linav 02.08.55 # printf("%d file%s copied", n, (n==1)?"":"s"); 02.09.24 # looks right to me 02.09.35 # to make it shorter: 02.09.41 # i suggest that would be a beneficial way to use ? 02.09.43 # printf("%d file%s copied", n, (n>1)?"s":""); 02.09.44 # :) 02.09.53 # 0 file copied ??? 02.10.03 # oh. 02.10.05 # :p 02.10.06 # HAHA. 02.10.07 # lol 02.10.08 # ;) 02.10.33 # rephrased: 'to make it shorter but less functional:' :) 02.10.40 # lol 02.10.43 # :D 02.10.51 # now..... 02.11.03 # how many times have *I* done that in my life? 02.11.07 # lol 02.11.46 # mmm.. probably 0 :) 02.11.53 # i wish 02.12.06 # did you read my post on the database idea yet? 02.12.21 # nope 02.12.25 # i used to do that for a living, you can be sure I cocked up more than one of those in my life 02.12.59 # 'id3 database browsing'? 02.13.06 # indeed 02.14.31 # aaaaaaaaaahhaha 02.14.34 # "Adding itunes support sounds like a clincher to me." 02.15.03 # I was actually referring to my most recent post 02.15.16 # on database structuring 02.15.18 # i'm looking 02.15.23 # that just make me laugh 02.15.33 # glad to be of service 02.16.12 # "PS. What is a "cluebie"?" 02.16.14 # HAHAHA funnier 02.16.34 # still don't know ...is it "have a vague clue" or "all clued up" or something else? 02.17.09 # no idea 02.17.56 # it's creator did not reply :( 02.18.36 # http://static.userland.com/userLandDiscussArchive/msg015585.html 02.19.15 # aha 02.19.39 # I'm a newbie - LMAO 02.20.16 # :)) 02.20.50 # as far as iTunes, i think being a cluebie is worse ;) 02.21.20 # LOL 02.21.28 # * Bluechip giggling 02.22.51 # :) 02.23.53 # we need a util to pull the id3 tags out of an mp3 file 02.24.15 # i need a util to gimme a c array from a 1bit bmp 02.25.03 # you can get the header data by copying my win32sim code and changing the fwrites to freads 02.25.50 # fread? HAHA 02.26.12 # i just need to modify bmp2rb for it.. but whenever i run bmp2rb i get a segfault anyways 02.26.36 # is your bmp saved in the "correct" format? 02.26.47 # 1bit.. should be 02.26.55 # i was thinking that may be it, i need to try again soon 02.27.17 # WINE can run notepad but not paint :( 02.27.45 # weird 02.45.05 Join DJBaz [0] (~baz@80.229.144.229) 02.56.07 # bagder? 02.56.20 # Bagder_, i mean :) 02.58.33 *** Saving seen data "./dancer.seen" 03.29.14 # bc? 03.29.24 # mk! 03.29.31 # <3 03.30.09 # any idea what the problem is? 03.30.10 # icons.c:27: parse error before `linavLogo' 03.30.10 # icons.c:27: warning: excess elements in scalar initializer 03.30.10 DBUG Enqueued KICK midk 03.30.10 # icons.c:27: warning: (near initialization for `linavLogo') 03.30.47 # Whats on that line? 03.31.16 # BITMAP linavLogo = {(unsigned int) linav_logo, 65, 10, 0, 0}; 03.31.22 # confusing, it works in a different .c 03.31.26 # .c file* 03.32.10 # i think i got it.. just a bit of tweaking 03.32.27 # i always do that.. i try to fix something for 20 minutes, then ask, then immediately figure it out 03.32.31 # apologies :) 03.32.43 # I do that in Tesco 03.35.30 # tesco? 03.36.06 # a store? 03.37.28 # your not the only one, sometimes you just need to talk to someone before you can figure it out, even if they have nfc of what your saying, heh 03.39.21 # haha :) 03.39.32 # actually that was sort of it 03.40.16 # i realized that you wouldn't know what BITMAP was -- i'm quite sure it's a standard C variable type -- and then i remembered i'd probably forgotten to include something 03.41.01 # s/quite sure it's a/quite sure it's not a 03.41.56 # I was about to suggest that. 03.42.11 # But its always better if you figure it out on your own :) 03.42.46 # next time i've got a problem i'll just paste it in a text editor as if i were pasting it to you, then come up with the answer right away :) 03.43.24 # Or ask the wall your question & the answer will come to you. 03.43.47 # seems less convenient. 03.44.11 # Oh, you don't talk to the walls? 03.44.23 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 03.44.23 # * Sebulba02 must just be weird then. 03.44.31 # I talk to the trees, but they don't listen to me - LOL 03.44.35 # i generally attempt to refrain from the practice... 03.44.38 # haha :) 03.48.03 # * Sebulba02 goes back to star gazing. 03.49.00 # Bluechip: Well, trees have other things to worry about, like not losing leaves.. or producing fruit. A wall has nothing real to worry about, it'll listen, heh. 03.49.16 # Anyways. 03.49.17 # hmmmmm 03.49.22 # a good point 03.54.07 # * Sebulba02 thinks Cygnus is above him. 03.55.07 # Is it a split decision? 03.55.08 # lol 03.56.19 # * Sebulba02 looks lost. 03.56.43 # Doesn't Cygnus link to the Gemini twins? 03.57.10 # Maybe my mythology and/or astrology is off 03.57.35 # I thought that was somehow a gemini thing, but I can't really tell based on this map. 04.01.04 # Ah, a square chart helps. 04.04.00 # Which oddly doesn't have gemini on it. 04.04.08 # LOL 04.04.24 # evil twin wins again 04.04.55 # heh, hey.. I'm one of those :P 04.05.02 # LOL 04.05.18 # 3/4ths of my family is 04.05.22 # weird 04.05.52 # statistically very unlikely 04.05.59 # Theres only 4 of us. 04.06.04 # ah 04.06.20 # But it is weird, yes. 04.06.33 # then what is the occasion celebrated by your parents three months after your birthday? 04.07.59 # Nothings in August, really. 04.09.00 # I was surprised by the number of people who realised they were "birthday presents" 04.09.57 # heh 04.10.08 # Not in my case. 04.10.16 # me neither (fwiw) 04.10.36 # It was made clear a long time ago I was a mistake. 04.10.44 # but who isn't? 04.12.27 # My mother was on the pill (although now knowing that the 21yr test results are in, it would seem ...not taking it as prescribed) 04.13.00 # heh 04.13.08 # Oops. 04.13.14 # lol 04.19.42 # kick arse, Stargaze works in WINE 04.53.43 Quit DJBaz ("Leaving") 04.55.47 Quit midk (Remote closed the connection) 04.57.39 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 04.58.34 *** Saving seen data "./dancer.seen" 05.20.15 Quit Bluechip () 06.58.37 *** Saving seen data "./dancer.seen" 07.02.25 Join LinusN [0] (~linus@labb.contactor.se) 07.11.13 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 07.19.46 Quit AciD (Read error: 104 (Connection reset by peer)) 07.20.06 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 08.35.26 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.42.17 Join [IDC]Dragon [0] (~idc-drago@pD95123A5.dip.t-dialin.net) 08.43.05 # <[IDC]Dragon> 'morning! 08.45.04 # <[IDC]Dragon> LinusN: r u there? 08.48.43 # i'm here 08.49.05 # <[IDC]Dragon> that's nice ;-) 08.49.20 # yeah, isn't it? 08.49.26 # <[IDC]Dragon> how did you like my hacking? 08.49.37 # you've been busy this weekend 08.49.50 # <[IDC]Dragon> mostly with our house 08.50.17 Join Zagor [242] (~bjst@labb.contactor.se) 08.51.07 # <[IDC]Dragon> another good morning seem in order 08.51.17 # i haven't looked that much at your radio stuff, but so far it looks good 08.51.22 # <[IDC]Dragon> seems, hi Zagor 08.52.04 # <[IDC]Dragon> I replicated the i2c for now, credited it back to you 08.53.13 # ah, i see that 08.53.32 # <[IDC]Dragon> dunno if multi-instance is beneficial, passing a struct to it, with the port addresses and bit masks 08.53.49 # it will be on the iriver 08.54.02 # it has separate i2c busses for each device (!!!) 08.54.42 # <[IDC]Dragon> the port banging code would grow quite substantially, not using the short and_b() and or_b any more 08.55.03 # yup 08.56.09 # <[IDC]Dragon> the iriver folks had either ports to waste, or want to independently do their i2c from various contexts 08.58.41 *** Saving seen data "./dancer.seen" 08.59.22 # their programmers probably didn't know about locking :-) 08.59.54 # <[IDC]Dragon> :-) ...or do I2c in interrupts 09.00.05 # maybe 09.05.44 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 09.06.57 Join kurzhaarrocker [0] (~knoppix@p50877AEF.dip0.t-ipconnect.de) 09.07.17 # Moin. 09.07.18 # Hello Kurzhaarrocker 09.07.29 # A feature Implementor? 09.07.48 # :D That's what I crave for! 09.08.26 # Ah... Less work for us Humans, if a plugin like that would exist... ;) 09.20.38 Join ey [0] (~knoppix@p508771E9.dip0.t-ipconnect.de) 09.21.28 # :( I stole my nick 09.21.28 # * ey slaps kurzhaarrocker 09.22.17 Mode "#rockbox +o LinusN " by ChanServ (ChanServ@services.) 09.22.34 # who shall i kick? 09.22.44 # that kurzhaarrocker - ghost 09.22.52 Kick (#rockbox kurzhaarrocker :LinusN) by LinusN!~linus@labb.contactor.se 09.23.11 # that felt good 09.23.17 # :D 09.23.28 # Still the nick is claimed to be in use 09.25.17 # LinusN: I updated the trigger code to the current cvs 09.25.37 # saw that, great! 09.25.37 # ey: Can't Nickserv do something for you? 09.25.59 # you should register kurzhaarrocker 09.26.08 # yes I should 09.26.59 Nick ey is now known as langhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) 09.27.32 Nick langhaarrocker is now known as kurzhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) 09.27.36 # btw, kurz, is there a reason why splitedit uses the currently playing file instead of being invoked from the "open with" menu? 09.28.09 # Not really but there are many reasons why the spliteditor should be reprogrammed from scratch :) 09.28.18 # :) 09.28.33 # feel free to do it :-) 09.28.48 # And I'm convinced that I started the spliteditor before there was the open with stuff 09.28.54 # yup 09.29.55 # yeah, I was just curious if you'd looked at it and dismissed it, or just hadn't looked at it 09.31.35 # Well there in fact _is_ a reason: by pressing pause during playback you can preselect the coarse split position. Doing that within the split edtior is not very comfortable. It's merely for finetuning the split. 09.32.03 # ok. we could have it both ways. 09.32.10 # yes 09.32.49 # do you have any ambition to do more work on splitedit? 09.33.40 # I cant guarantee to have enough time this century. Otherwise I have many ideas about it. Fell free to do whatever you like with it :) 09.34.04 # ok, just checking 09.47.09 Nick Bagder_ is now known as Bagder (~daniel@1-1-5-26a.hud.sth.bostream.se) 09.55.08 Part kurzhaarrocker 10.01.18 # curl release day 10.01.25 # wooo 10.01.43 Join kurzhaarrocker [0] (~knoppix@p508771E9.dip0.t-ipconnect.de) 10.02.54 # so now I deserve some coffee 10.03.21 # what do you guys say, should we release rockbox today too? 10.03.37 # Is the recording bug squished? 10.03.40 # Zagor: are you nuts? 10.03.52 # hehe 10.04.05 # kurzhaarrocker: it appears to be a hardware bug 10.04.21 Join Headie [0] (~hehe@fsto6.sto.sema.se) 10.04.28 # Bagder: i heard that wget is better than curl :-) 10.05.03 # Zagor: do we know that? i haven't had any feedback from paul yet 10.05.25 # --> appears <-- 10.05.26 # :( No triggered recording in the next rockbox release 10.05.32 # and paul definitely has problems with the asm ATA optimizations 10.05.52 # LinusN: :-P 10.06.14 # he can't run the dailies without removing the ata optimizations 10.06.43 # neato. do we have his hardware info logged? 10.06.53 # think so 10.08.20 # I recorded two hour-long sessions myself this weekend. the archos mic is quite impressive, for the price. a bit noisy, but very sensitive. 10.08.53 # Concerning that recording bug: Why not turn off that crc check if it causes trouble? 10.09.08 # we might add an option for it 10.09.25 # but the stereo mode affects it as well 10.10.48 # Sensitivity without sacrificing the s/n ratio is the hard and expensive part. 10.11.07 # yeah 10.15.11 # well I propose we disable crc, zip it up and release 2.3. all this waiting benefits noone. 10.15.25 # I agree 10.15.35 # * kurzhaarrocker cries 10.15.51 # Zagor: another release without a manual? 10.16.00 # there is one 10.16.30 # yes, we have the preliminary that christi started writing, but it is far from finished 10.16.38 # if needs be, yes. we can't just sit around and wait forever. 10.16.50 # well, no one writes docs then let's skip it 10.17.05 # <- wrote docs for triggered recording :) 10.17.11 # she specifically waited until we froze the features 10.17.21 # * Bagder slaps the "good contributor" sticker on kurzhaarrocker 10.18.26 # I don't want to freeze now, it just takes more time and halts current work. we've got a pretty good state right now, let's ship it. 10.18.55 # Zagor: i assume you have tested the new fm radio code and found it allright? 10.19.45 # if it bugs terribly, we release a 2.3.1 10.19.52 # I'm confident jörg and jens have. and if it's not working well, I'll be happy to release a new version tomorrow 10.20.12 # i really don't like this 10.20.21 # I know. you never like to release :) 10.20.28 # thanks 10.20.33 # we need a "release manager" 10.20.38 # honestly 10.21.21 # LinusN: well speak up, what exactly is it you want to wait for? 10.21.50 # i want the recording issue resolved 10.22.04 # <[IDC]Dragon> I want the keyboard for the ondio 10.22.05 # and i want a manual 10.22.21 # I want world peace 10.22.26 # :-O 10.22.45 # <[IDC]Dragon> me too 10.22.54 # And I want triggered recordings - but I know I'm the only one who wants that. 10.23.00 # how many people are bitten by the recording issue? 10.23.11 # kurzhaarrocker: I want it too, but I don't want to delay the release for it 10.23.24 # we don't know how many that suffer from the recording bug 10.23.25 # <[IDC]Dragon> the ondio is almost ready... 10.23.26 # this isn't the last release you know ;-) 10.23.33 # I know, Zagor, just nagging. 10.23.49 # LinusN: how many have reported it? 10.24.12 # paul is the only one who has put the finger on it 10.24.15 # * kurzhaarrocker has lost recordings 10.25.39 # so we're waiting for a bug that has bitten one or two persons? and the only clue we have is that crc introduced it. 10.25.56 # qoute from the forum: 10.25.57 # Quote from: pcspecialist on October 14, 2004, 09:38:34 PM 10.25.57 # I've had no luck getting stability out of any of the daily builds so you'll want to stay away from them. 10.26.22 # right, and how many bug reports have we seen from him? 10.26.38 # ok, go ahead, release it 10.27.21 # how many bug reports do you want to believe that there really is a bug? 10.27.27 # Why not first try to disable crc, let paul and me try and then release in two days or so? 10.27.58 # kurzhaarrocker: paul got a test build over a week ago. linus can you send the same build to kurz? 10.28.04 # i sent paul a test version weeks ago 10.29.03 # http://linus.haxx.se/paul_rectest1.ajz 10.29.07 # I have a practice session tonight anyway. A good opportunity for a 4 h recording. 10.29.15 # that is 2.2 with CRC check enabled 10.29.45 # if our theory is correct, the recording will be seriously corrupt 10.30.02 # I'll try and report tomorrow 10.30.06 # ok good, I'll wait 10.31.32 # [IDC]Dragon: how much work would you say is left on the ondio port? 10.31.52 # i think we should announce a feature freeze, like we used to do 10.33.27 # for instance, we should make the recording file name generation algorithm an option 10.33.42 # why? that's a new feature. 10.33.42 # "regular" recorder users want that too 10.33.59 # we've tons of feature requests for that one 10.34.03 # we've had 10.34.04 # many people want a lot of new feaures 10.34.05 # <[IDC]Dragon> do we? 10.34.33 # <[IDC]Dragon> Zagor: a few days would be OK to brush it up, I'd say 10.34.35 # Zagor: since the ondio does it, the regular one could do it as well 10.35.21 # <[IDC]Dragon> I'm a big fan of releases, but not like announcing them for tomorrow 10.35.39 # * kurzhaarrocker wants directories generated by date and files named by time and my mind consists of many split personalities. Does that count extra? 10.36.28 # <[IDC]Dragon> give us some timline horizon to implement against, but no "snapshot release" 10.37.37 # <[IDC]Dragon> if I know a scheduled release is due, in, say a week, I can stabilize things well better 10.40.59 # <[IDC]Dragon> bbl 10.41.05 Quit [IDC]Dragon () 10.46.30 Join ashridah [0] (ashridah@220-253-119-176.VIC.netspace.net.au) 10.48.36 # clamav uses libcurl now 10.48.48 # c00l 10.49.16 # what a pity it doesn't use wget. 10.49.16 # * kurzhaarrocker hides 10.49.21 # haha 10.49.32 # libcurl is quite a different beast than wget 10.53.14 # * Bagder 's daughter is right now sitting on the floor and rips toilet paper into very very tiny pieces 10.53.15 # The only one time I wanted to use curl yet I had to realize my provider doesn't allow that. 10.53.54 # ;-) 10.54.02 # you mean the php module then? 10.54.07 # yes 10.57.53 Join amiconn [0] (~jens@pD95D1099.dip.t-dialin.net) 10.58.07 # G'morning 10.58.16 # yo 10.58.34 # ghurt 10.58.44 *** Saving seen data "./dancer.seen" 10.59.21 # amiconn: we are discussing the recording issue 10.59.30 # Yup. (log peeking) 10.59.42 # aha, a peeker! 11.00.02 # That reminds me of good old C64 basic 11.00.08 # I like to remind you that I cannot test the radio code; no box with a radio :( 11.00.32 # LinusN: which feature did you say ondio has that "regular" doesn't? 11.00.55 # generating recording file names, "file0001.mp3" etc 11.01.05 # or is it "rec0001.mp3"? 11.01.09 # Ondio seriously lacks the keyboard :( 11.01.40 # yeah, because it doesn't have a clock 11.01.41 # (But I already have some idea how to do that with the limited keys) 11.02.03 # amiconn: if the crazy player people could do it, so can you ;) 11.02.11 # Zagor: yes, but people have been bugging us for years about not doing that for the regular recorder :-) 11.02.30 # yes, and I agree it would be a nice option. but it's not a release-stopper. 11.02.58 # * Bagder is off 11.03.08 # surely not, but i thought we could very well add it, since the code is there 11.03.43 # Zagor: The player keyboard is rather unintuitive (imho, now that I could test it with my Studio) 11.03.58 # amiconn: i agree completely 11.04.12 # however I don't think it *can* be made intuitive 11.04.17 # the player keyboard design is really silly 11.04.47 # I think it can, maybe that will become a by-product of the Ondio keyboard 11.05.03 # sounds good 11.05.07 Join Lurkski [0] (~Miranda@24.30.163.142) 11.06.40 Join edx [0] (edx@p54879108.dip.t-dialin.net) 11.09.46 # so is everyone happy with a week-long freeze instead then? 11.10.12 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 11.11.01 # yup 11.11.16 # Zagor: I don't like freezes :( The plugins need quite some rework... 11.11.40 # amiconn: that's not adding features, is it? 11.12.46 # * [IDC]Dragon just steps back in, reading logs 11.13.04 # <[IDC]Dragon> a week grace period sounds fine 11.13.22 # LinusN: Not quite, but it sometimes means to change how things work 11.13.47 # that's why I wanted to do a snapshot release, to avoid hindering current work 11.13.57 # <[IDC]Dragon> amiconn: what else have we got left for the ondio? 11.14.10 # <[IDC]Dragon> did I forget something? 11.15.22 # Most lacking is keyboard. Then we need dual-volume and howswap 11.15.40 # <[IDC]Dragon> the latter 2 can wait, I'd say 11.15.51 # <[IDC]Dragon> those are big features 11.16.05 # why is keyboard essential? 11.16.18 # file renaming etc 11.16.36 # <[IDC]Dragon> you're prompted with that in various places 11.16.47 # <[IDC]Dragon> e.g. .cfg saving 11.17.38 # <[IDC]Dragon> and I'm missing FM presets, found no button for that 11.17.53 # <[IDC]Dragon> maybe Jens has an idea 11.18.35 # file renaming is hardly essential on a flash player. config saving is nice, but could probably just as well use a couple of predefined names. 11.19.21 # Zagor: I would have needed file renaming already several times 11.19.39 # but if you think you can have keyboard code running in a short time, that's ok with me 11.20.05 Join mrelwood [0] (~d5f38ec0@labb.contactor.se) 11.20.11 # fm preset handling should work too imho 11.20.11 # amiconn: yes, it's a nice feature. but hardly essential. lots of players (most, I would bet) lack it 11.20.30 # <[IDC]Dragon> I need to work a bit more on the tuner 11.20.34 # [IDC]Dragon: I can't test FM :( ... but, to overcome the small number of buttons, context menus would be rather handy... 11.20.54 # so now you're saying we should wait until the ondio is Release Quality 11.21.15 # <[IDC]Dragon> amiconn: but you can think about it ;-) 11.21.20 # I have massive respect for Jens and Jörg, but I doubt it will be done by next monday 11.21.26 # Hey guys! Don't know if it's my english or understanding, but FAQ and forums didn't enlighten me. Is the Rockbox already working on a iRiver iHP-120? 11.21.33 # mrelwood: no 11.21.41 # okay. 11.21.51 # <[IDC]Dragon> Zagor: it will be like 1.0 for rockbox 11.21.51 # is it still under developement? 11.21.53 # I wanted to ask whether it is desired to rewrite the text viewer a bit. Today, it uses a heapload of non-intuitive key combos to cycle through various settings. It should have a config menu instead, with save function. 11.22.16 # <[IDC]Dragon> I wodn't worry about that 11.22.18 # mrelwood: we have only begun with the iriver port 11.22.23 # [IDC]Dragon: yes, that's how I feel it should be. and 1.0 didn't have file rename. 11.22.29 # (for example) 11.22.30 # <[IDC]Dragon> the main thing is to scroll up and down 11.22.57 # [IDC]Dragon: bookmarking would be nice 11.23.03 # cool! are the options and possibilities going to be the same as in the current for Archos? 11.23.11 # (but that's something else) 11.23.13 # mrelwood: yes 11.23.17 # mrelwood: that's the plan 11.23.17 # <[IDC]Dragon> kurzhaarrocker: it does 11.23.36 # so, input level metering for recording, and no recording time limits? 11.23.37 # * kurzhaarrocker is astonished 11.23.52 # mrelwood: yes 11.24.01 # <[IDC]Dragon> all Rockbox features are in Ondio as well, since it's the same code 11.24.04 # o-oh, the metering. That will be interesting stuff to port 11.24.22 # oh my! those are the only things that has kept me from getting the iHP! 11.24.31 # kurzhaarrocker: yes, we need a basic sound energy algorithm 11.24.39 # <[IDC]Dragon> Except for a few places where the buttons are too few and we had to explicitely cut features 11.25.02 # but the recording formats and bitrates will be the same as they are in the iRiver originally? 11.25.14 # LinusN: i guess we need an rb lunch :) 11.25.32 # But once we have that metering code it will probably precise in contrast to the archos hardware crap. 11.25.51 # +be 11.26.22 # mrelwood: not necessarily. we will focus on mp3 first, and then add other formats after that. 11.26.37 # but it will be able to do 320kbps mp3? 11.26.44 # [IDC]Dragon: What is the current button assignment in radio screen (both JB FMR and Ondio FMR)? 11.27.32 # mrelwood: hopefully, yes 11.28.09 # mrelwood: we honestly don't know much about the limitations in the original iriver firmware 11.28.32 # lunch, see you later 11.28.33 # lunch time 11.28.35 Nick Zagor is now known as Zagor|lunch (~bjst@labb.contactor.se) 11.28.58 # The original can rec up to 320kbps and 44.1kHz wav. But if the 320kbps is available, I'll surely wait instead of getting some other poor excuse for a DAP. Thanks guys! 11.29.51 # What is DAP? 11.31.04 # <[IDC]Dragon> amiconn: FMR is tuning on left/right, volume on up/down, menu on F1, presets on F2, recording on F3, stop recording on Off, screen freeze on Play, exit on On 11.32.01 # Digital Audio Player 11.32.08 # ok 11.32.12 # thx 11.32.21 # <[IDC]Dragon> OndioFM currently is same for direction, menu on long Menu, recording on short Menu, stop recording on Off, screen exit on long Off 11.32.58 # american forums use it alot. like www.dapreview.com. mostly meaning mp3 players with a HD. 11.33.12 # <[IDC]Dragon> see radio.c, line 55 ff. 11.33.46 # [IDC]Dragon: two qns: (1) "exit" (On) brings you where? (2) Presets is a menu, or a cycle-through? 11.34.21 # <[IDC]Dragon> (1) exit goes back into the main menu where you came from 11.35.16 # <[IDC]Dragon> (2) presets is a menu 11.39.13 # Why do you exit from radio with "On" and not "Off"? Off would be much more logical... 11.40.22 # It would be the same as with the recording screen: 1st "Off" stops the recording, 2nd "Off" exits 11.40.45 # (no long hold necessary) 11.44.13 # <[IDC]Dragon> yes, with some slight code modifications we may do so 11.45.04 # <[IDC]Dragon> but how to call the presets menu? 11.45.31 # <[IDC]Dragon> unless we do very unintuitive combos with the menu button 11.45.32 # You can use some Menu+xxx combos 11.45.52 # Yes, that is not very intuitive :( 11.47.14 # <[IDC]Dragon> what are your ideas for the keyboard screen? 11.48.04 # <[IDC]Dragon> like, arrows move across the pickboard, menu arrows move within the string? 11.48.56 # <[IDC]Dragon> or, a 1-D pickboard instead of 2-D? 11.49.02 # with menu being a "toggle" or a "shift" (combos) 11.51.48 # No, arrows move cursor around the screen (up/down/left/right), with a 4-row pickboard as it is now, but the cursor is also allowed to move outside the pickboard into the filename line, and move the insert position there. Menu+Left would be backspace there, and Menu+Right delete. 11.52.21 # Menu button inside pickbaord inserts character under cursor, long press accepts file name. 11.52.36 # ok, got understood. 11.53.22 # <[IDC]Dragon> sounds good 11.53.30 # Moving the cursor across the left or right border of the pickboard selects previous/next pickboard 11.53.55 # (Perhaps with an alias on Menu+Left/Right for direct pickboard selection) 11.54.19 # Off button = cancel (same as now) 11.54.34 Part Lurkski 11.55.35 # Some of these changes might be useful for recorders too, and the ideas could be re-used for a better player pickboard (1-line only, of course) 11.56.38 # <[IDC]Dragon> d the nice thing is that tis code can be tested on the simulator, for a change 11.57.21 # <[IDC]Dragon> (oops, I fail with this PC keyboard already) 11.58.08 # btw: When I tried to build with target = recorder a dummy rombox is build. When I do the same with target = FMRecorder building rombox fails. Is that difference intensional? 11.58.52 # kurzhaarrocker: You need the updated uclpack for proper rombox. For FMR it fails because of too little flash space 11.58.58 # <[IDC]Dragon> you probably have no up to date uclpack 11.59.28 # <[IDC]Dragon> amiconn: for OndioFM, it now fails again, too 11.59.32 # ok I'll test that tomorrow with current uclpack 12.01.09 # [IDC]Dragon: Radio is working properly now, or does it need some more polishing? 12.05.00 # I have to admit that I almost never use the simulator 12.34.14 Join webguest64 [0] (~5149bab3@labb.contactor.se) 12.43.19 Nick Zagor|lunch is now known as Zagor (~bjst@labb.contactor.se) 12.49.54 Join thedude02 [0] (thedude02@pm477-42.dialip.mich.net) 12.50.58 Part thedude02 12.51.31 # amiconn: u there 12.51.32 # ? 12.58.48 *** Saving seen data "./dancer.seen" 13.00.54 # LinusN: Now I am. 13.01.02 # <[IDC]Dragon> me too 13.01.09 # <[IDC]Dragon> (just got back) 13.02.07 # <[IDC]Dragon> amiconn: the radio needs a better "tuned" detection for the search mode, ans I need to suspend it after use 13.04.17 # Doesn't the philips tuner have an autotune feature? Just use this... 13.04.47 # <[IDC]Dragon> it has, but the generalization would go overboard 13.05.29 # <[IDC]Dragon> right now, the radio screen doesn't know which tuner it is talking to. 13.06.23 # Why? You could implement the autotune feature as a tuner api function. For philips, it would use the chip's autotune feature, and for samsung it would do it the same way as now 13.07.14 # <[IDC]Dragon> possible, then the samsung implementation needs a task 13.07.43 Quit mrelwood ("CGI:IRC (EOF)") 13.08.09 # There's a bug in recording.c that can be fixed easily: When you enter quickscreens from the recording screen the blinking red led might stay switched on. Very irritating when there's neither disk access nor a recording in progress 13.08.19 # Want a patch file? 13.14.15 # [IDC]Dragon: Why would it need a thread? The current system does the autotune in the main thread, right? 13.16.45 # <[IDC]Dragon> if we want a common interface, you either (1) say: tune to xx MHz, then tell me if this is a station. You iterate until a good one is found. 13.17.24 # <[IDC]Dragon> or (2) you say "search upwards" to the tuner interface, sit an poll until tuned 13.18.22 # <[IDC]Dragon> for (2), and a tuner without a search feature, the tuner wrapper has to autonomously tune and test, to emulate it 13.19.02 # <[IDC]Dragon> so it would need a thread, unless you do something crappy like a tick function 13.19.29 # <[IDC]Dragon> e.g. the polling from the top level could be used to advance 13.22.08 # Iirc, the current tuning works that way, or can't you auto-search upward, but only tune in steps by hand? 13.23.25 # <[IDC]Dragon> ?? The samsung tuner need to be set each time, the Philips has a search enable and a direction bit, plus a readback if the search stopped 13.23.28 # In that case, I think a thread would be needed, for philips as well. Then the thread could report the "station found" back to the main thread via an event - no polling 13.23.48 Nick kurzhaarrocker is now known as kurzhaarrocker|l (~knoppix@p508771E9.dip0.t-ipconnect.de) 13.24.13 # My question was: Can you auto-tune in the current radio screen, or not? 13.24.20 # <[IDC]Dragon> the radio screen has nothing to do anyway 13.24.45 # <[IDC]Dragon> the screen does have a search, if that is what you mean 13.25.18 # <[IDC]Dragon> it advances the tuner by 100kHz, checks for tuning, and so on 13.25.37 # No I mean (like I would expect from it): short press of left/right would tue down/up by 50 kHz, while a longer press would start a search for the previous/next station 13.26.50 # <[IDC]Dragon> exactly, yes 13.27.33 # And the tune/check/tune.. is currently done within the main thread? 13.27.40 # <[IDC]Dragon> yes 13.28.15 # Hmm. Then I think we should go for an additional thread. 13.28.43 # <[IDC]Dragon> I try to keep it simple, if we can 13.31.06 # I think the auto-tune by the chip might work both faster and better than a hand-implementation. If this needs a thread for non autosearch capable tuners to be properly wrappable, then let's do it 13.31.49 # <[IDC]Dragon> LinusN: reading? 13.35.20 # <[IDC]Dragon> Or like I wrote above, I use the poll interval of the screen as a tick to try the next frequency 13.41.14 # The samsung tuner probably needs some time until it tuned to a new frequency, right? Des it report back when done, or is there a fixed delay time? 13.42.24 # <[IDC]Dragon> sleep(1) 13.45.13 # what is the problem? 13.45.27 # <[IDC]Dragon> no problem 13.45.40 # then why are we talking about separate threads for tuning? 13.46.38 # <[IDC]Dragon> ok, (so far) the tuning is not detected, the search is failing 13.47.14 # <[IDC]Dragon> right now I don't remember if it always stops, or always carries on 13.47.25 # <[IDC]Dragon> I think it stops 13.47.44 # <[IDC]Dragon> Jens raised the autosearch of the Philips 13.49.18 # <[IDC]Dragon> but first I'd like to check what the IF counter really returns 13.52.52 # absolutely 13.52.57 Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) 13.53.16 # i prefer the "manual" tuning, because it makes the API simpler 13.58.40 # Why not use a feature already present in the chip? 13.59.50 # use a callback to avoid the need for a thread 14.00.00 # because it forces us to emulate it on the other chip and 14.00.33 # i think it's better to use the common feature set 14.00.47 # why is the autotuning feature better? 14.00.55 # is it more accurate? 14.01.13 # <[IDC]Dragon> if it works and the other doesn't, it is better ;-) 14.01.35 # we already emulate it, don't we? 14.01.39 # I think it will be both faster and more accurate, because the chip decides when to advance the frequency 14.01.41 # i doubt that the semi-manual methos doesn't work 14.01.45 # <[IDC]Dragon> let's rather call it autosearch 14.02.20 # Zagor: yes, but we'd have to emulate in on the API level, if we want the interface "clean" 14.02.46 # <[IDC]Dragon> then please change the subject until I found out 14.03.31 # LinusN: is that so bad? if both use a callback for screen updates, the api would be nice and clean 14.03.41 # <[IDC]Dragon> (the discussion is premature) 14.04.02 # well we can still discuss the principle 14.07.14 # <[IDC]Dragon> ok, my $0.02 then: in terms of code size, it probably doesn't matter much if the stepping is done in the screen or in a tuner thread. The latter architecture pays off if you have a search-capable tuner, then you can drop that ( little bit of) code 14.07.42 # <[IDC]Dragon> right now, I tried not to turn everything upside down 14.07.45 Part oxygen77 ("Cho") 14.07.45 # why a thread instead of a callback? 14.08.01 # <[IDC]Dragon> who does the stepping? 14.08.31 # since we are talking in the context of a single thread, the answer is: the code 14.08.54 # <[IDC]Dragon> so you tick the lower tuner layer? 14.09.03 # i.e. tuner_autosearch(up, &search_callback) 14.09.28 # <[IDC]Dragon> as a blocking call, you mean, now I get it 14.09.31 # yes 14.09.59 # <[IDC]Dragon> hmm, might not be so friendly to all the other button handling 14.10.05 Join edooo [0] (~edooo_188@82.129.244.5) 14.10.32 # sure it would. the callback can check the button queue and order the search function to abort 14.10.54 Quit edooo (Remote closed the connection) 14.11.07 # (via its' return code) 14.11.09 # <[IDC]Dragon> then the callback ticks the app? 14.11.17 Join edooo [0] (~edooo_188@82.129.244.5) 14.11.21 Quit edooo (Remote closed the connection) 14.11.43 # the callback handles screen updates and maybe button checking to see if user wants to stop searching 14.11.56 # app-level stuff 14.12.08 # <[IDC]Dragon> this is very upside down now 14.12.20 # if the callback returns false, tuner_search aborts and returns 14.13.41 # <[IDC]Dragon> I don't like to overuse callbacks, they revert the normal layer hierarchy 14.14.23 # i don't think this is overuse. it's a simple way to add user feedback to a long blocking function without having to add a dedicated thread 14.15.01 # sort of like a progress indicator callback 14.15.32 # <[IDC]Dragon> but a big one, which contains all the event-driven code of the screen 14.16.25 # what it does is up to the application. the tuner code just contains the option. 14.16.36 # how do you mean all event-driven code? 14.16.59 # the callback would not start new functions 14.17.19 # (other than lcd_drawstring etc) 14.17.50 # <[IDC]Dragon> it has to do all the work the screen usually does. Check buttons, invoke actions 14.18.31 Join edooo [0] (~edooo_188@82.129.244.5) 14.18.33 # no, the only button check is to allow the user to abort searching. 14.18.49 Quit edooo (Remote closed the connection) 14.19.03 Join edooo [0] (~edooo_188@82.129.244.5) 14.19.06 # <[IDC]Dragon> and if we simply want to adjust volume during the search? 14.19.11 # you can't 14.19.26 Quit edooo (Remote closed the connection) 14.19.41 Join edooo [0] (~edooo_188@82.129.244.5) 14.19.53 # maybe i'm misunderstanding everything, but surely while searching there is no actual sound? 14.19.53 Quit edooo (Read error: 54 (Connection reset by peer)) 14.20.20 # <[IDC]Dragon> not nice. Then I have to exit the search, remember the condition, later adjust the volume and kick off a new search 14.20.49 # exit the search? doesn't the search exit automatically when you find a channel? 14.20.54 # <[IDC]Dragon> what piece of code were we trying to save, btw? 14.21.36 # we want to be able to use the hardware search 14.22.03 # <[IDC]Dragon> I know. At quite some cost, it seems now. 14.22.04 Join edooo [0] (~edooo_188@82.129.244.5) 14.22.30 # ? 14.22.47 Quit edooo (Remote closed the connection) 14.23.02 Join edooo [0] (~edooo_188@82.129.244.5) 14.23.37 # <[IDC]Dragon> I mean, if we start to workaroud setting up an interrupted search, to allow things like volume set 14.23.41 Quit edooo (Remote closed the connection) 14.24.01 # granted, I don't have an FM unit so I'm probably in the blue here. but doesn't it work just like a normal car radio: press SEARCH+ to search for a channel at a higher frequency. the display shows the increasing frequency and the sound is muted. when a channel is found, the display stops and sound is turned on again 14.24.14 # why would you want to adjust volume while searching. there is no sound! 14.24.15 Join elinenbe [0] (~elinenbe_@65.115.46.225) 14.24.25 # bonjour 14.24.42 Join edooo [0] (~edooo_188@82.129.244.5) 14.24.46 Quit edooo (Read error: 54 (Connection reset by peer)) 14.24.58 # <[IDC]Dragon> there is sound, and it may be interesting information to you, because you e.g. just went over that weak station you're looking for 14.25.18 # it's like adjusting volume while fast-forwarding an mp3 file 14.25.39 # but, sure, we can adjust volume in the callback if that is a desired function 14.26.22 # <[IDC]Dragon> please let me try to use "Samsung mode" first 14.26.42 # i.e. not use the hardware feature? 14.26.55 Join edooo [0] (~edooo_188@82.129.244.5) 14.26.58 # <[IDC]Dragon> for the time being, yes 14.27.29 # <[IDC]Dragon> the Ondio needs to support both tuners anyway, decided at runtime 14.27.56 Quit edooo (Remote closed the connection) 14.28.34 # <[IDC]Dragon> and you want to release in a week ;-) 14.29.02 # i wanted to release today... 14.29.05 # For getting it to work, I agree (like not using DMA was useful for me to get MMC to work at all), while once it works, using the chip's autotune would be desired. 14.29.40 # amiconn: agreed 14.29.52 # If there is a feature in one chip and not in the other, it is imho better to implement the feature in software for the chip lacking it, instead not using the feature just because the other chip doesn't offer it 14.30.04 # if practical, yes 14.30.26 # <[IDC]Dragon> but imagine you have to use the non-DMA for the other anyhow, then it's tempting to not utilize it 14.31.13 # <[IDC]Dragon> assumed if there is no practical drawback 14.32.02 # <[IDC]Dragon> guys, I'm happy the tuner works at all today 14.32.14 # Imho the auto-tune in software should not need much code, but it needs either a thread, or a tick-task 14.33.28 # why? 14.34.07 # <[IDC]Dragon> I gree that I prefer the tick over the callback. 14.34.13 # In order to get the same behaviour as for the autotune-capable chip, without adding extended callback mechanisms 14.34.52 # a callback is MUCH more simple than adding tick tasks or threads 14.35.24 # <[IDC]Dragon> this callback loop would be an emulation for the autotuning, because naturally it could return right away 14.36.05 # the callback has nothing to do with tuning, it only handles the user feedback 14.36.17 # <[IDC]Dragon> else you would fire off the search, then query it once in a while how it is doing 14.37.39 # ...which requires a state machine in the user interface code, PLUS a whole thread just to create user feedback 14.38.03 # <[IDC]Dragon> no 14.38.28 # <[IDC]Dragon> case 1, autosearching tuner: 14.38.58 # <[IDC]Dragon> the user holds e.g. Right to start search 14.39.22 # <[IDC]Dragon> the app call search(up, 95.5 MHz) 14.39.50 # <[IDC]Dragon> which returns after setting the frequnecy and search dir 14.40.22 # <[IDC]Dragon> the app periodically updates the screen, so it calls get_search_state() 14.40.57 # <[IDC]Dragon> which returns current frequency, stopped, strenght, whatever 14.41.17 # what happens when the user holds right again, during searching? 14.41.21 # <[IDC]Dragon> case 2, Samsung tuner: 14.41.51 # <[IDC]Dragon> it may start a new search at the current frequency 14.42.35 # <[IDC]Dragon> which is probably no harm and no difference 14.42.50 # <[IDC]Dragon> it definitely has to start anew if the user holds Left 14.43.01 # <[IDC]Dragon> ready for case 2? 14.43.15 # i don't need it 14.43.42 # i still think adding a thread is much more unneeded complexity than just running a callback each .25 MHz or whatever 14.44.24 # plus that we don't have these types of asynchronous calls anywhere else in rockbox 14.44.38 # <[IDC]Dragon> my dummy approach for Samsung wound be to do the first tuning on search(up, 95.5 MHz) 14.45.07 # <[IDC]Dragon> the next on each get_search_state() call 14.46.52 Nick kurzhaarrocker|l is now known as kurzhaarrocker (~knoppix@p508771E9.dip0.t-ipconnect.de) 14.49.54 # question: how is tuner_search different from jpeg_decode? 14.50.12 # * Bagder gets bored by the db thread on the list 14.51.04 # <[IDC]Dragon> Zagor: because you found a callback there? 14.51.08 # I actually tried to make a db according to the TagDatabase wiki page 14.51.53 # [IDC]Dragon: it appears to be a callback that does pretty much want I'd like the callback in tuner_search to do 14.53.30 # <[IDC]Dragon> that callback doesn't run the whole UI 14.53.48 # neither would the one in tuner_search. i don't know where you got that from. 14.54.32 # let me explain my view: 14.55.21 # if user holds right, app calls tuner_search(up, 95.5, &callback) 14.56.09 # tuner_search() starts searching upwards from 95.5, either using hardware search or software search. each 0.25 MHz it calls callback(some,info) 14.56.51 # <[IDC]Dragon> for HW, I can't assure a certain frequency interval 14.57.03 # ok, at some interval then 14.57.53 # callback() redraws the screen with the new info, and checks if user pressed an abort button. if so, it returns false 14.58.12 # tuner_search() checks the return code from callback(). it it is false, it stops searching and returns to the app 14.58.43 # if we want to be able to adjust volume during search, callback() can check for those buttons too 14.58.52 *** Saving seen data "./dancer.seen" 14.59.13 # <[IDC]Dragon> I was afraid this redraw and button handler would replicate a lot of the normal UI 14.59.31 # it can call the same draw function as the normal ui loop 15.00.15 # but the abort search button is a search-specific ui, so it has to be done separately 15.01.00 Join pillo [0] (~trillian@navlab03.dei.unipd.it) 15.03.01 # <[IDC]Dragon> my thinking was that the search runs more or less in the background, decoupled from the screen 15.03.55 # yes, but I don't think the user sees it that way so there is no need for the code to do that either. searching is a pretty active action. 15.09.59 # Using a thread or tick task would enable setting the volume etc. independently whether a seach is running or not, with no additional code 15.10.20 # a new thread is no additional code? :) 15.10.55 # Plus, the thread/task would only needed to be started if a samsung tuner is found. 15.11.59 # why do you want to use a thread when it's not needed? 15.12.08 # i didn't follow the discussion 15.12.21 # do we know for a fact that we need to use the auto-tune funcion? 15.13.08 # it's not a question of "needs", we're discussion on the assumption that autotune will bring a benefit 15.14.03 # in any case, i fail to see the need for a separate thread 15.14.30 # With the callback approach you would have to account for whether a search is running or not in the ui code. With a thread/task you don't 15.14.41 # yes you do 15.14.47 # the user wants the feedback 15.15.34 # Yes, but that is much easier (imho) than different button checking in a large callback function 15.15.34 # amiconn: quite the opposite. with a callback you *don't* need such state information, since everything is a single thread and thus call tree 15.15.49 # for the 98th time, it's not a large callback function 15.16.26 # it could be the same function that the radio code uses for the screen update 15.16.41 # You need to distiguish whether the ui code is called via callback or directly, or you have to duplicate the ui code 15.17.01 # no we don't. both functions can call radio_drawscreen() 15.17.34 # but the button polling might be slightly different in the callback context 15.18.00 # yes, because it is different functions. when not searching, you naturally don't have a button to abort it... 15.18.06 # yup, that's what I mean 15.18.12 # (btw, this is exactly what i want to avoid by not using the autotune function) 15.18.17 # sort of like you can't stop ffwd in pause mode 15.19.03 # but the extra complexity in the button handler is nothing compared to adding a new thread 15.20.10 # just imagine all the nice cleanup code. "oh, do we have a search running? we need to stop it before exiting radio screen" 15.21.11 # how do you stop a search? are some buttons conditional depending on if you are in search state or not? 15.22.43 # currently, you stop the search by clicking left or right 15.22.53 # i.e tune manually 15.23.00 # iirc 15.32.50 # LinusN: how is the iriver progress coming? anything on the drawing board right now? 15.34.34 # which is the better win32 program: eac or cdex? 15.35.47 # btw, Bagder: i tried upgrading my plextor firmware but it still freaks out on bad disks. 15.35.52 # Depends on wether you prefer emacs or vi? :) 15.35.56 # Zagor: ok 15.36.29 # kurzhaarrocker: emacs. doesn't everyone? ;) 15.37.39 # apropos thread: I'd still favor a thread to read out the peak meter registers :) 15.38.28 # concerning eac vs cdex: I used both and both worked to my satisfaction. I don't prefer either over the other. 15.38.39 # so they're pretty much the same? 15.38.52 # At least the result is pretty much the same. 15.39.54 # elinenbe: will probably work on it this evening 15.40.08 # timers and LCD driver is next 15.40.26 # LinusN is our lonely worrier at the iriver front. 15.40.54 # i'm looking at the mp3 encoder right now 15.41.18 # Shine 15.41.34 # yeah 15.41.43 Join JoyOfDuck [0] (~d98680b3@labb.contactor.se) 15.43.12 # Hello - Can anyone spare a minute to shed light on a mis-behaving Jukebox Studio 15.43.23 # shoot 15.43.55 # thankyou - My little box of tricks just stopped working 15.44.07 # It only powers on when the USB cable is conmnected 15.44.25 # Appears to work fine in USB mode, but not at all in play, or battery charge mode 15.44.34 # Thought it might be a hardware issue 15.44.54 # Are the batteries really fully charged? Might they be old and broken? 15.45.14 # I thought it might be the batteries, so changed them for new ones 15.45.42 # what happens when you try to turn it on? 15.46.07 # The green LED flicks on once - no disc motor, no backlight 15.46.26 # does it charge the batteries? 15.46.35 # Appears not 15.46.46 # my guess is that the IRF7416 is broken 15.46.49 # I took it apart and checked voltages 15.47.01 # Got les than three volts across the battery terminals 15.47.06 # what heppened when it stopped working? 15.47.26 # 3 volts 15.47.34 # that's nearly nothing 15.47.38 # have you checked the battery terminals themselves? 15.47.42 # I left it charging for a few hours and noticed that it wasn't warming up 15.47.49 # Tried switching it on and it was dead 15.47.51 # the connections to the small PCB:s 15.48.02 # Or maybe you checked the wrong terminals and measured only two batteries? 15.48.15 # I checked the battery termansl at the top 15.48.26 # ok 15.48.27 # Also checked the two solder tabs at the top end of the board 15.48.34 # then your batteries are discharged 15.48.48 # They are brand new, so I expect that they are discharged 15.49.35 # Is the IRF7416 the battery chargin component? 15.50.21 # I was prepared to lose my favourate toy, but then noticed it worked fine with a USB cable plugged in 15.50.32 # Thought that might indicate a simple hardware problem 15.52.02 # Oh well, that looks like it. Thanks for your time - I'll start saving for an iRiver 15.52.04 # To start charging you have to leave them for serveral minutes in the jukebox 15.52.26 # Oh yes - I have left them variously for several hours 15.52.45 # If you have an external charger you might want to try charging them separately. 15.53.02 # Good idea - I'll try and borrow one 15.53.24 # Might be able to limp along until Christmas :-) 15.54.24 # If anyone thinks of anything, my addy is "joy at beyond2000.co.uk" 15.54.27 # Thanks again 15.54.59 # you're welcome 15.55.53 # gotta go now, cu guys 15.55.57 Quit webguest64 ("CGI:IRC (EOF)") 15.55.59 Part LinusN 15.57.20 # kurzhaarrocker: Iirc he said he has a Studio - Players charging is hardware 16.02.56 Join Lynx_ [0] (lynx@134.95.189.59) 16.05.31 # right, amiconn, stupid me. 16.05.50 # Helo are we still thinking about my Studio 20 issue? 16.15.40 # JoyOfDuck: I'd try the following things: 16.15.52 # Hello 16.16.18 # (1) Take a set of 4 new batteries, charge them externally and put them into the box. Does it start? 16.16.40 # If yes, the charging circuit in the box is most likely broken. 16.17.50 # Thanks - I plan doing this first point following the earllier suggestion 16.18.19 # If it does not start, (2) measure the voltage across the battery contacts, both at zero load (box off) and while trying to start. 16.19.12 # If the voltage drops below ~4.5 V while trying to start (with fully charged cells) the battery contacts are broken 16.20.26 # Anyone here who knows which of the 4 contacts are the ends (can't check myself atm) of the 4-cell circuit? 16.21.53 Quit Zagor (burroughs.freenode.net irc.freenode.net) 16.21.53 NSplit burroughs.freenode.net irc.freenode.net 16.23.15 NHeal burroughs.freenode.net irc.freenode.net 16.23.15 NJoin Zagor [242] (~bjst@labb.contactor.se) 16.24.14 # I see a photo on the Rockbox site at http://www.rockbox.org/docs/solderjoints.jpg 16.26.05 # I also had the second symptom of broken contacts: Reboot when the bumpers are compressed 16.26.10 # hmm, the "fixed point" implementation of Shine uses double, log and sqrt... 16.27.06 # JoyOfDuck: The pictures are for a JB recorder, but the problem most likely also exists for players. 16.27.20 # Ahah! 16.27.37 # Thanks again for the help - I'll report back once I have a working player :-) 16.47.11 # Well the peak meter code contains some log too, Zagor :) 16.53.36 # :) 16.54.14 # see you 16.54.15 Part Zagor 16.55.22 Quit ashridah ("sleep") 16.58.53 *** Saving seen data "./dancer.seen" 17.01.09 Join gromit``` [0] (~gromit@ALagny-151-2-2-244.w82-121.abo.wanadoo.fr) 17.06.27 Join methangas [0] (methangas@0x50a476bc.virnxx10.adsl-dhcp.tele.dk) 17.18.22 Quit gromit`` (Read error: 110 (Connection timed out)) 17.22.03 Join mecraw__ [0] (~lmarlow@69.2.235.2) 17.25.59 Quit [IDC]Dragon ("CGI:IRC") 17.34.20 Part pillo 17.36.26 Part kurzhaarrocker 18.03.52 Quit einhirn (Read error: 54 (Connection reset by peer)) 18.15.44 Quit edx (Read error: 54 (Connection reset by peer)) 18.21.48 Join elinenbe_ [0] (~elinenbe_@65.115.46.225) 18.39.39 Quit elinenbe (Read error: 110 (Connection timed out)) 18.39.39 Nick elinenbe_ is now known as elinenbe (~elinenbe_@65.115.46.225) 18.42.18 Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) 18.58.57 *** Saving seen data "./dancer.seen" 19.54.44 Join schnauz [0] (zazz@dh051-118.chem.sunysb.edu) 20.13.04 Quit Headie (Read error: 110 (Connection timed out)) 20.29.17 Quit _Lucretia (Connection timed out) 20.29.49 Join [av]bani [0] (~goemon@washuu.anime.net) 20.29.59 Part [av]bani 20.29.59 Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) 20.42.27 Join Headie [0] (~hehe@fsto6.sto.sema.se) 20.59.00 *** Saving seen data "./dancer.seen" 21.01.06 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- IRC has never been so cool") 21.07.56 Join edooo [0] (~edooo_188@82.129.244.5) 21.11.24 Quit JoyOfDuck ("CGI:IRC (Ping timeout)") 21.13.17 Quit edooo (Read error: 54 (Connection reset by peer)) 21.15.47 Nick _Lucretia is now known as _Lucretia_ (~munkee@abyss2.demon.co.uk) 21.28.37 Join edooo [0] (~edooo_188@82.129.244.5) 21.32.10 Quit edooo (Read error: 54 (Connection reset by peer)) 21.34.55 Join edooo [0] (~edooo_188@82.129.244.5) 21.35.47 Quit edooo (Read error: 54 (Connection reset by peer)) 21.49.51 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.54.17 Join gmb [0] (~441ae028@labb.contactor.se) 21.55.34 Quit gmb (Client Quit) 22.23.42 Join dropandhop [0] (~43646aab@labb.contactor.se) 22.23.47 # hey all! 22.23.53 # iriver user here 22.23.57 # was wondering how i could help 22.24.01 # i can't code tho! 22.34.20 Quit elinenbe (" Try HydraIRC -> http://www.hydrairc.com <-") 22.41.14 Join [av]bani [0] (~goemon@washuu.anime.net) 22.41.22 Part [av]bani 22.46.53 Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 22.59.01 *** Saving seen data "./dancer.seen" 23.26.25 Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) 23.36.56 Quit dropandhop ("CGI:IRC") 23.38.57 Join gromit` [0] (~gromit@ALagny-151-2-2-244.w82-121.abo.wanadoo.fr) 23.38.57 Quit gromit``` (Read error: 104 (Connection reset by peer)) 23.52.20 Join iRiverMan [0] (~acca5915@labb.contactor.se) 23.52.26 # hey people 23.52.59 # can someone help me regarding an iriver please? 23.53.12 Quit Hadaka (No route to host)